There are many similarities in the mindset and skillset needed by a QA Engineer and a developer. A career change from the former to the latter can be a truly win-win-win situation: a fresh challenge for you as an employee; benefits for your employer and a quality boost for its products. Gustavo Mitsuichi explains why he’s so glad he made this switch at Nmbrs.
Any QA specialist thinking of making the move to developer will be well advised to keep reading this. It’s a move that I made recently, and I certainly have no regrets. I joined Nmbrs at the beginning of 2018 and spent 18 months as a QA Engineer, which combined manual and automated testing and developing. The work appealed to me because it focused on making a quality product and made what, for me, was the all-important connection between how and why such a product is created.
Starting the process to change my career
This period coincided with an on-going transition process in Nmbrs from manual to automated QA. Together with other QA Engineers, I had to create tooling and processes from scratch and provide the necessary training. It was an amazing experience, but once it was accomplished, I missed having a challenge in my work and I felt the time was right for a career change. Fortunately, at Nmbrs if you would like to try a different challenge there are plenty of other opportunities in other positions inside the company! Especially since our culture is one of no managers and vertical growth, Nmbrs encourages employees to grow by providing training opportunities, new roles and the possibility of switching teams.
The obvious move for me was a switch from QA to developer. There are clear similarities in the necessary skills, particularly on the automated side. It varies per company, but at Nmbrs we use the same programming language and tooling for QA and developing. As a developer I now use between 80 and 90 per cent of the same tooling and structure that I did as a QA.
The main difference between QA and developing is the focus. As a QA, the focus is mainly on how the end-user perceives the application or module as a whole. And while developers also have to bear this in mind, they must think in much greater detail, about specific parts and components and how everything functions together.
We are free to reach out to anyone in the company. It helps us to understand more about what our colleagues do.
Applying QA skills as a developer
My transition from QA to developer was relatively easy. As a QA you already have a deep understanding of the product and you are aware of the connections between modules. This really eased and accelerated the onboarding process, to the extent that a colleague and I were fully productive developers after just a few weeks. I also had previous experience with Software Development, which, of course, helped a lot.
So many things that you learn and do as a QA can also be applied as a developer. For example, as a QA you must have a lot of attention for detail, so you soon learn to identify shortcomings in a developer’s work. If you then make the career change to developer yourself, you’ll instinctively know which pitfalls you need to avoid. And how to avoid them if they are product- or business-logic related.
During the transition to developer you need to familiarise yourself with the various processes followed by your company. In Nmbrs, for example, we have Code Review, in which a colleague critically assesses your work. There are, of course, other skills to learn, such as how to code and, if you lack the necessary development experience, how the tooling works. For me, it helped that I was already familiar with some of them.
The impact of the company culture
The Nmbrs company culture also made the transition much easier for me. At Nmbrs we work in multidisciplinary teams of product owners, QAs and developers. As a QA you are stimulated to be very involved in the product and share your ideas and suggestions. If you find a bug, for example, the team encourages you to investigate further so that you can give the developer as much information as possible. It gives the developer a head start in solving the issue and teaches the QA a lot about the application. All this gives a QA an intrinsic knowledge of the product. Moreover, there is no barrier between the disciplines. Barriers only serve to make things less clear and transparent between groups. And, of course, working in small teams gives you a better understanding of each other’s roles.
For QAs and developers alike, creativity plays a key role. As a QA, creativity extends to dreaming up unlikely scenarios that the user might encounter with the application and testing how secure it is when used and misused in different ways. As a developer, creativity is even more important and you rely on it more frequently. We do, of course, have to work within a framework of specifications, but we have the freedom to be innovative in the ways we use coding and tooling to tweak a product or module to improve its security, performance and maintainability.
As a QA you already have a deep understanding of the product and you are aware of the connections between modules.
Go for it!
I am still passionate about QA and I can look back fondly at my time spent as a QA. But now I can look forward with relish to the opportunities and challenges that await me as a developer. My advice then, for anyone who is thinking of making the tech career change from QA to developer, is to: “go for it.”
Perhaps fittingly, the developer chapter in which I currently work is focusing on increasing the level of quality in the product. Perhaps, like me, if you have experience in QA that you could apply as a developer, you too might find yourself to be the right person, in the right place, at the right time!
