What developer skills would translate well into doing QA? [closed]

Question

I'm an intermediate-senior developer who got burned out severely with programming last year and I've been exploring possibilities of a career change into Testing/QA (among others such as Technical Writing). I hope this question isn't off topic here. I already asked it on the Programmers site and got directed here by a mod.

Here are some reasons why I think I would be better for QA than Development:

"Meta Knowledge Work" vs "Knowledge Work"

I'm naturally much better at analysing things that already exist (from a step back) than actually being in the thick of them, right at the grindstone and working on them. For example, I'm great at analysing and pulling apart a topic of interest and writing a blog post on it, but I'm terrible at creative writing - where I have to come up with all the content myself.

Blinders on problems in own work

This is a near-universal human problem (which is why writers need editors and developers need independent QA), but I think I have a very bad case of it: I'm simply very bad at stepping back and seeing problems in my own work (ie In terms of development: bad initial pre-checkin testing). Throughout my programming career, I've always had an above average rate of stupid obvious bugs checked into source control. Stepping back and finding issues in my own code is very difficult.

On the flipside, I'm very good at spotting bugs and usability issues in other people's code. For example, I'm often the first to notice some weird change in behaviour when getting latest changes in code when someone else broke something.

This is related to the first point re: "meta" knowledge work. I'm just much better at analysing something from a step back, and that I wasn't in the thick of working on myself.

Problem solving as a challenge

I really don't enjoy the challenge of dealing with fiddly problems (such as obscure, hard to trace bugs) when I have to take direct creative/modifying ownership of them. This comes down to "meta" knowledge work again - I easily get frustrated and impatient (and thus unfocused and unproductive) when I'm right in the thick of something and have to fully deal with it myself. But it doesn't happen when I'm outside and looking in - eg. Analysing a problem that I'll ultimately simply have to document thoroughly and pass on to someone else.

I'd be intellectually dishonest if I didn't admit that part of this is simply wanting to pass the buck instead of being the one ultimately responsible for something. But it works well with my analytical skills, which are much better for stepping back and analysing than getting right into the details and doing.

Tolerance for repetition

This is a somewhat negative point, but I want to cover it anyway, because a lot of developers have the opinion that Testing/QA is boring and repetitive. So I just want to cover this one before it comes up: I have a very high tolerance for repetitive work which might seem relatively boring. And again, due to the "meta" knowledge work thing, I'm great at noticing a slight change in something after seeing it run differently 1,000 times before. But only if it wasn't code that I wrote myself!

Conclusion

Excuse the length but I wanted to cover the points as clearly as possible. I'd especially like to hear from people who've done both QA and Development before, but also general opinions regrading what I sound like as a potential Tester or QA engineer.

P.S. It goes without saying (as a developer with 10 years experience across various jobs) that I've had a lot of contact with Testers/QA and have a pretty good idea of what they do. And I've done some (relatively informal) QA in the past - in roles where there were no dedicated testers and the developers tested each other's work. For what it's worth, I always enjoyed it more than the development itself!

Question: Will the techniques I have learnt as a developer translate well into doing QA?

EDIT: Just added a few clarifications. I think I overstated the point of not wanting responsibility. It's really more that I'm much better as an analyzer than as a direct creator and modifier of things. Basically it comes down to the difference of mindset described in this post. My aptitude and patience for the specific combination of creation, modification and analysis skills involved in development is not very good. But when I'm a step removed and doing virtually pure analysis, then I shine (and enjoy it much more).

Answer 1

You describe several skills that are advantageous in a tester: analytical skills, the ability to find flaws, and tolerance for repetition. You also seem to be interested in testing.

A potential disadvantage from your own admissions: reluctance to take ultimate responsibility and, to a lesser degree, discomfort with starting something from scratch.

You are accustomed to a developer's salary and perhaps a developer's prestige. Be prepared to relinquish both. While there are testers who are more highly paid than developers, in general a tester makes less. And while there are rock star testers who are highly praised for their role in the organization, as a general rule testers are considered just as necessary but not as valuable as developers. When a product or a project is wildly successful, developers are more likely to get a pat on the back or a mention in the company meeting than a tester. To the extent that this matters to you, set your expectations appropriately. This is not to say that testing is a bad job. It is a good job in the right circumstances, but it is not like being a developer.

The nature of the job depends on the circumstances. In my first test job, I was a test lead. This required being organized, spending a lot of time communicating, dealing with developers who were less interested in testing than I was, tracking a lot of project-level information, and taking responsibility for something big. It also required some light development skills. It was a good, rewarding job, and I was praised for my efforts. This might be a good role for you given your background, but you must be willing to own it.

Edit: Here are some good discussions on QA hiring and the relationship between a development job and a test job: What benefit does having developer experience or background have on the effectiveness of a tester?, How do you prepare yourself for a testing position?, How should you interview for QA positions?, and How does a tester's perspective towards software differ from a developer's?. (If you search SQA, you will find others, too.)

Answer 2

It's always a challenge to change careers. And as a hiring manager, a red flag always go off when someone wants to change careers and get hired onto my team. I see a few here.

You say that you are burned out as a developer. That's understandable. So are you considering QA as "easier"? Less likely to cause burnout? Be prepared to discuss this in depth with an interviewer. I want my QAers to work very hard (sometimes we work a lot harder than the developers, sometimes not). I wouldn't want someone to come in thinking that this was an opportunity to take things easy.

You mentioned analyzing versus being creative. At least on my team, the QAers must very often be creative.

Thanks for being honest about not wanting responsibility. There's a good bit of responsibility required in most QA shops. In some shops, QA is the gatekeeper to production - very high responsibilty there.

I've hired ex-developers into QA before (heck, I used to be a developer). But not very often in the immediate transition from dev to QA. Be prepared for some tough questions about why you chose QA as your goal, and how the hiring manager could know that you won't quickly get burned out there as well.

Are you in a position to switch to QA in your current company? Often, that's the simplest type of transition to make.

Good luck!

Answer 3

I'd be intellectually dishonest if I didn't admit that part of this is simply wanting to pass the buck instead of being the one ultimately responsible for something.

In SQA you are more responsible for a feature than a developer is. When nasty bugs make it to production, all eyes are on you and you must do an RCA or explain how it was missed. If it causes a loss in revenue or accounts, be prepared for more pressure. As was mentioned in another response, you will never get credit for a smooth-running feature, you will only get noticed when something goes wrong.

You mention a tolerance for repetition, a necessary trait. Are you also prepared for bouts of mindless, brain-numbing clicking and typing? Automation is always the goal, but it's doubtful you'll escape long rounds boring manual testing, especially during a full regression.

I'm not trying to talk you out of it--just want to clarify a few points. It sounds like you know your abilities and what you're best suited for. I switched from a front end developer to QA, and haven't looked back. I luckily get to work on a team in the same discipline, so I get the best of both worlds.

Also as noted by another commenter, you lose a bit of prestige and pay, but job satisfaction is more important than pay or respect. I say go for it.

Answer 4

A few years ago I made this same choice. I was a tester, moved into C++ C# development, then moved back to testing. I still like writing code and there are some coding opportunities in testing. The main reason I switched back was that in development I found the thing I got the most enjoyment from was bug fixing. I know that sounds somewhat trivial but I found the problem solving aspects of that much more engaging than coding new features. Testing is very much like bug fix coding rather than feature coding. The problem I had with feature coding is when you are working on adding to existing code base you basically are fitting into that framework. All of the other comments here are extremely valid and you should consider them carefully. Moving to testing is always going to be seen as a step down by any of your colleagues - that is simply the way it is. The other thing to remember is testers are at the end of the line in the cycle, they get the stuff just before it needs to ship. There will be times that quality is a level of quality rather than a absolute (absolute being no defects), just be aware of that. At the end you still have to always be willing to fight for defects to be addressed while understanding that you are not the final say in releasing the product.

Answer 5

Developer for 20 year before switching to testing which I've done for the last 4 years and not regretted the move at all.

Your first point about having to come up with all the content yourself struck a chord - I was great at finishing off programs but not starting them off

Problem solving - you gave the example of being frustrated at tracking down hard-to-repro bugs. Thats one of the things I love being a tester, when that lighbulb goes off and you realise what it is that makes it reproducible

One more point - is it testing or QA you want to do ? Or both ? One thing you really MUST do is stop calling them the same :)

Answer 6

First I want to commend you for an honest and transparent inward examination of your strengths and weaknesses. I don't see it enough.

Blinders thoughts: I see this as a variant of "can't see the forest for the trees" which I suffer from myself occasionally. Both developers and testers must keep a holistic mentality and see the program as a whole, never forgetting there are many different parts (modules) that flow together. This holistic mentality applies to test cases, scripts, scenarios, etc. too. Even the ones you write. As long as you can do this, sounds great. Questions to think on: Would you have a co-worker that will review your testing docs and provide honest feedback with you concerning them?

Problem solving thoughts: You mention getting easily frustrated and impatient. While never being a "doormat" (for lack of a better word right now), a tester does need to have some level of patience. Pointing out a flaw in someone's work, especially if their identity is in that product, can "test" you and your patience. Communication skills must be excellent. Personally, I have to look at a bug from a "selling" angle. What is the best way I can "sell" this bug to the dev? And/or management---- if the dev won't give me time? If you think a bug is high priority, say a security breach (in your eyes), and they say, low priority ("no one would ever do that"), how do you see yourself reacting? I guarantee this situation will happen. Patience grasshopper.

Tolerance for repetition thoughts: Word for word, this part is me. I have been in QA (in one form or another) since 1988 and here's my 2 cents on repetition. The red flag that went up when I read this is: wasted time. The danger here is comfort zone. One has to distinguish between a helpful repetitious test and one that produces no fruit and should be either revamped or tossed altogether. A great tester will always stay flexible and know when to let go.

The only other thing I can add, and perhaps you have already dealt with this as a developer, is a great tester needs to be prepared to stand up for what they believe in and be prepared for (anticipate even) push back. As user246 has correctly mentioned, testers are a rung down on the engineering ladder. Although I am born to test and don't care about that, that fact alone would not settle well with some folks. It would greatly influence their decision on whether to transition from developing to testing.

Edited to add that I have never been a developer so my responses are not from a former dev angle. QA is my passion and always has been.

Answer 7

My two cents, mainly based on one of your points -

Tolerance for repetition

This is a somewhat negative point..........that I wrote myself!

If you do repetitive, boring work, then chances are that your job will be automated or you will be replaced by a low-cost resource from an offshore country.

burned out severely with programming last year

Without going into details, how did that happen ? You have 10 years of exp. If you've survived this long, then you can probably survive longer. If I were you, I would not pick a fancy, technically challenging project. I'd pick the routine stuff in development.