Switch role from QA to developer
After wearing the hat of developer for a year, recently I officially switched my role at Thoughtworks from QA to developer. Having worked and thought about QA for 7 years, I still think QA is an important role, but practically it’s much easier to work as a developer.
In the field of physicians, there is a category named preventive medicine. Compared to clinical medicine, preventive medicine doesn’t treat patients directly, nor are they usually licensed to treat patients. In fact, preventive medicine is designed to take all ought measures to prevent diseases, instead of curing diseases. In theory, this would be an integral part of the healthcare system and compliment with clinical medicine very well. However, practitioners of preventive medicine often face embarrassing situations, such as no doctor license, unable to measure the success, and hardship to actually find a job. This good-looking subject in design eventually becomes not worth the candle.
The same goes to QA. I find the concept of built-in quality fascinating. Bugs and bad user experience can happen from any part of the SDLC (Software Development Life Cycle). Better scrutiny of design (shift-left quality) would mostly help building better software, but the problem also lies here. If most issues are avoided at the beginning, how could QA prove their value?
In an ideal world, people strive for what is right to do. In reality, these practices usually require high trust from stakeholders. In my seven years of experience, I was sometimes able to exercise those good practices as I wished, but none of them was easy, and there were still many cases where regulatory requirements or lack of trust simply turned me into a traditional tester working with Excel or Jira Xray.
In my most recent client engagement, I shifted from one team to another, and that’s also my shift from QA to developer. My previous team worked on an API service, but we only produced the code. We didn’t have the permission to manage the infrastructure and deployment. Infrastructure and deployment were managed by the second team. As a QA, I wanted to test the fallback logic to handle exceptions, as I discussed with the team; for example, our API heavily relies on Salesforce, if Salesforce goes down, our API shouldn’t simply just break, but a user-friendly error message should appear instead. If I would like to test this behaviour in a deployed environment instead of my local computer, I would have to mock Salesforce in that environment. I raised my requirement to the second team at that time, and was rejected. Later I moved to the second team myself as a developer. I raised this scenario again, and managed to influence the team to deliver this mocking capability. This is probably a problem of the team separation itself, but it also revealed a heartbreaking fact: it is indeed easier to deliver something as a developer than a QA. Imagine that I were still a QA in the second team, someone else would have to do it for me, and that would make the negotiation more difficult than how it was.
Thoughtworks has kindly made the compensation transparent too. As I have never thought about it, at the same seniority, developers get paid higher than QAs. I have heard a few companies also converting their QAs to developers. Perhaps it would be an easier choice to be a developer everywhere anyway.
Moving on, even though I have officially transferred to the developer role, I would bring a lot of valuable learnings while being a QA with me:
- Quality is built, not tested. Think about it before any line of code is written. Think about it when we have the first thought of any idea;
- Correctness of the delivery of a feature doesn’t necessarily mean good quality. The specification itself can lead to low quality. Only measure the user experience as the quality measurement;
- Tests are also costly. Plan what to test and how to test are important. This is an advanced topic which requires great experiences and broad consensus. Consult the expert and make it a team activity.
As I shift my focus from QA to developer, a lot of learning focuses are also changing. In the past a few years, I have figured out how Selenium works, how Cypress is different. I expect soon I will need to explain how Tailwind CSS works, why Kubernetes Gateway API is designed, and so on. Stay tuned if you are interested, as they are very likely to be my future write-ups.