Passage from developer to QA: how can it be interpreted from a potential recruiter?

Question

For about a year, I have worked as a developer in the same company. I have worked with many different technologies, in the web development area: this means that I have worked essentially with J2EE but also with front end technologies, like Javascript, HTML, jQuery. Sometimes, I operate also on DBs, writing stored procedures, as an example. In a nutshell, I could do all the main activities related to web development, even if my strong point is the Java language.

From some months, the company in which I work has grew up, and it required a reorganitazion. This means that a QA team needed to be created, among with other new roles. More than that, and due to our projects' state, we recently had a massive workload for front-end developers (skilled developers with Javascript, CSS, jQuery...) and Java developers like me suddently had less to work on.

In this scenario, I have been moved from the developer role to the QA one. It is not a trivial task: I have to define the various test cases and apply them in the best way, and also "train" a couple of others, less experienced, coworkers. I like my new role, but I'm afraid about the possible interpretations a potential recruiter could find. I see two possible interpretations here:

• The first is the "good" one: that is, as a developer who got a little experience, I got "promoted" to another role, that doesn't lack of responsibilities and attention required. In a certain way, even managers stop to code for the need of following other tasks.
• The other is the one that worries me: a transition from developer to QA could even be interpreted as a inadequancy to the former role, translatable in a "recycle" of my figure. If this interpratation takes place, it could even block a possible opportunity in the future.

So, my question is: should I specify this change of role in my CV, if I'm searching for another job as a developer? Or it can be interpreted negatively from a potential recruiter? Thank you for all your thoughts, and sorry for my English, I know it's not perfect.

Answer 1

Or it can be interpreted negatively from a potential recruiter?

Yes, at least in the locales I've worked, QA roles are very often populated by CS grads who are not competent programmers. Many recruiters will see QA as a sign that you could not cut it as a developer. Worse, many recruiters will see the QA work as a "gap" in your development career - a time where you let your programming skills atrophy. Right or wrong, QA is a "lesser" role to many people.

This is backed up by salary data. QA Engineers make ~$10k less than software engineers on average. If people were capable of doing both jobs, it stands to reason that they would do the software engineering job, unless you really think there's that much difference in desirability of the work in QA's favor. The alternative is that software engineers are valued more than QA engineers, driving their salaries more than candidate supply.

Either way, you're in a spot where QA roles will be devalued by recruiters, either because they think you possibly are less capable or because they value the development role more.

If you're looking for a developer role, then I would tailor your resume to list your developmer title, but have the QA work as bullets in the work experience.

Answer 2

I am going to completely disagree with any of the answers here who claim that "QA is where incompetent programmers go".

Testing in the industry is a rapidly evolving beast. There was, perhaps, a time when Quality was solely the realm of folks who clicked on things or manually tested(though I think the attitude that QA is 'failed' devs is still inaccurate.) Today the industry is moving towards test automation but job titles and expectations haven't really caught up.

Automated testing, in it's variety of forms, is in some ways more challenging than software development. Depending on the type of testing being done, QA(or QE as is often being called now) typically must have a really good understanding not only of the product(s) they test, but the products that those targeted products integrate with AND the infrastructure and use cases for all of those products.

When I dev I have a product and a feature to implement(in a very simplistic way.) When a QE is working they have a feature to be tested - but this means they need to consider all of the ways that feature might be used, edge cases, integration points and potential future directions that feature might be used. Additionally they need to keep, in some way, an understanding of their current regression suite(s) and know where this new feature and it's changes should go and what changes need to be made in the regression suite(s) in order to facilitate that. Additionally they need to know the code and environment(infrastructure/platform/etc) well enough to provide useful, meaningful feedback. TL;DR - QE(and much of QA) is no longer pushing a button and saying "Herf Derf this didn't work". Rather QE is writing the frameworks, expectations and doing the ground work to make testing that lets the Devs and Product Owners test stuff themselves.

So QA vs QE. QA is Quality Assurance which is where any of the remnants of manual testers would be. But it's blending with Quality Engineering - where the focus is on developers who can automate complex system interactions in order to provide a health check for any changes in code, any environmental changes or for systems in general. I think there is definitely a stereotype against QA, as evidenced in answers about QA on 'The Workplace' and that may be something you don't want to fight against. In which case, especially if you are implementing automated testing, I would recommend talking to your supervisors about the role 'Quality Engineer' as it tends to convey the technical aspects of the job a bit more.

That being said. Yeah, there are some folks, again as demonstrated any time QA comes up in the various Stackexchange communities, that will think less of you for having anything to do with QA. These often, but not always, are the same folks that think having a separate Quality team test or inspect their code is useless("Because devs can write unit tests!") To be honest, good companies and good people to work for should be interested in what you did rather than a title. If you were training others, doing testing plans and strategies and creating a Quality org from the ground up in your company(or played a part in doing that) and you were working to automate test coverage, triaging, reporting and tools to support that then you've got some serious chops to add to your resume.

Consider, for a moment, the Big 4. They all have pretty serious quality organizations within their company. At least two push to have 2:1 or 1:1 ratio of Dev to QE for all of their products. The other two, from what I know, go with the rough 'rule of thumb' of 4:1(dev:QE). This shows in what they do. They aren't going to look down on you for having 'QA' on your resume especially when it's paired with the work you are doing(which isn't easy by any stretch of the imagination.)

To leave aside my obvious gripes with how folks like to talk about QA. QA is just another role that brings with it challenges that companies are very interested in solving. Having experiences doing that makes you more valuable. Having a background in development(as many QA have and all QE have) means that you are better poised to bring automated solutions to these challenges. QA expands your pool of opportunities, it will only limit it with companies that are uninterested in Quality as a metric for their products and who, thus, place QA experience at a lower 'rank' than developer positions.

Answer 3

There are a lot of people who would think you're not a good programmer if you were moved to the position of rocket scientist. In a perfect world, people who know how to program well, would get hired as programmers. Many people don't know how to spot talent, so they accumulate all sorts of notions about what makes a good or bad programmer.

You are right, being in QA will be held against you by many people. You need to over-come some of the poor assumptions in your cover letter to spin this in your favor.

1. You went to QA by choice because you don't like programming. Let them know you did what was best for the team/project because you're willing to cooperate and pitch-in where needed even if it means not having your preferred position. Maybe you had no choice.
2. You were moved from a programming position because you were the worse programmer and/or not capable. Explain your situation. Maybe the choice to move you was purely based on amount of time with the company and you were the latest hire. Let them know you were a programmer in good standing.
3. Since you haven't been programming, your skills declined. Make sure you emphasis that you were still writing code. Maybe you code on your own time and contribute to an open source project.

Also include what you learned by being on the QA side that makes you a better programmer. Did it help you think about requirements differently? Does your QA experience carry-over when writing unit tests?

Another area to point out is the training of others. Not all programmers are prepared to be a team leader, but with this experience, you could be a future candidate.