Why I Moved from QA to Developer

I recently made the switch from Quality Assurance to Development. It’s been awesome. Thanks Credit Karma! It feels great to learn something new, and to work in an environment that encourages learning and growth. I’ve never had a job that made the day go by so quickly. I’ve also never had a job be so challenging. They say time flies when you’re having fun, but as much fun and excitement that comes with a change of career I’ve discovered it to be even more difficult than I originally thought.

The joy of breaking things

I fell into a Quality Assurance (QA) position years ago because the software that company built was a Remote System Administration tool. My Army job was in Electronic Communications and my college degree is in Information Systems and Security, and that is what I thought I wanted to do until I discovered a company was willing to pay me to break stuff. Every little kid’s dream job, right? I picked up the QA process very quickly, mostly because I thought it was fun and loved my job. Every project was a contest, challenging any engineer to create a product that I couldn’t find bugs in. After a couple years I knew I wanted to move on and expand my skill set, most likely to automation and eventually development, even though I often joked that the only thing I learned in my college programming courses was that I would probably never be a programmer.

The humility of being tested

Fast-forward a few years, after I joined Credit Karma on the Quality Engineering team, I was encouraged to think about career growth and what would be an exciting challenge. Career growth looks different for everyone, but for me the ultimate challenge was software engineering. We get $5,000 per year as part of our Learning and Development benefits, which I used for an online class and a development conference. Now, the switch is complete. Officially a Software Engineer. It's an interesting feeling being the person on the other side, writing code and having another QA Engineer testing my work. All the times I challenged a developer and now another person is challenging me. It just feels...backwards.

My first full project was a relatively simple user multi-variant test implementation. It had multiple layers of tests that made it harder than a typical UMT, but overall was much more difficult to test than it was to write the code. I tested extensively myself before handing it off, but the QA Engineer was still able to find a couple bugs. Since I’m bringing a tester’s mentality to my code, I thought it would be in perfect working order. It wasn’t because even though I know what I’d test for as a QA engineer everyone thinks about the problem differently, and I now have even more respect for what the previous software engineers I worked with do on a daily basis.

The value of progress towards perfection

Speaking of perfection, as a QA Engineer I knew there was no such thing as perfect software. There were always bugs, or something that could be improved in the usability, or design improvements. The tester’s mentality is exactly that: strive for perfection. Let the developer know what can and should be improved to try to make it perfect next time. As a software engineer still in a testing mindset, I’ve found it difficult to not try to make it perfect from the beginning. To try to skip an iteration by testing it myself and making it better right away.

From a quality perspective it’s a huge positive to be a developer with a QA background. In my experience, many developers will test their work to verify “it works!” but not necessarily to ask “how else could it work?” or “how can I break it?” For better or worse, I ask those questions every time. From a time standpoint it can be a negative, because trying to test every possible case can force a project to go over the original time estimate. Finding the balance when only a portion of my time is applied to testing should help me become a much better engineer. In the meantime I can challenge my team to become better testers by discussing additional test cases in test plans, assisting in test user creation or configurations for specific test cases, and always challenging the processes in our retrospectives.

The joy of building things

For anyone thinking about making the switch, understand that it’s going to be more challenging than you think it is. Learning syntax and solving logic problems online are great for learning, but it’s different than jumping into a maze of code from a real-world application. Even how you initially test will be a 180° change in thought process. In QA, I found testing is best when coverage goes end-to-end. In development, testing starts at unit tests. Thinking about testing only a single function at a time seems a little strange at first, but it is incredibly important to the end product. I wonder how many less bugs QA Engineers would find if every product had complete unit tests?

Prepare to be humbled knowing you are going from being “good” at your job to “not so good” at your job. It takes longer to find the solutions when it’s a new challenge every day. Know you’re going to fail, learn from your mistakes, and ask questions. Finally, know that being a software engineer is fun, rewarding, and completely worth the struggle. It’s great to look at a feature and think “I built something that will help people.”

About the Author

Jeff is a software engineer building a better credit ecosystem for Credit Karma's 60 million members.