Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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!

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).

share|improve this question
add comment

6 Answers 6

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 candid 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 toward software differ from a developer's?. (If you search SQA, you will find others, too.)

share|improve this answer
    
+1 Thanks. I'm definitely not phased about the salary and prestige aspects, but I can see what you mean about the taking responsibility issue. I should note though: this one is massively magnified by being the actual front-line creator of something (rather than an analyser who is a step removed). –  Bobby Tables Sep 9 '11 at 0:30
1  
+1 Sound advice –  Bruce McLeod Sep 9 '11 at 3:49
    
@user246 re: your edit + links: Thanks. Those were very insightful. Mostly in a good way (as in confirmed that I'm far more cut out for testing than for development). –  Bobby Tables Sep 11 '11 at 23:04
add comment

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!

share|improve this answer
    
+1 Thanks. I should clarify: taking responsibility is only really an issue for me in the context of directly working on something and creating it (making direct changes to the concrete object of the work) myself. It doesn't come up when the work consists of analyzing something from a step back. I suppose part of this is confidence: I'm just much better at stepping back and seeing details than seeing them when I'm buried in them - and being good at something equals being more confident to take charge of it. By no means is this a totally generalized issue of not wanting responsibility. –  Bobby Tables Sep 9 '11 at 21:42
add comment

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.

share|improve this answer
    
+1 Thanks. See my comment on Joe Strazzere's post re: responsibility. As far as prestige and pay goes, I'm not at all phased there. –  Bobby Tables Sep 9 '11 at 21:48
add comment

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.

share|improve this answer
    
+1 Thanks. Good points. :) I was going to use the term "seeing the forest for the trees" too. I think all my problems with development have this same root, which is why it was hard to make separate points without referring to "meta knowledge work" constantly. I really can't explain why I have a problem with details when I'm directly involved in creation/changes of the knowledge capital, but not when I'm one step removed. But this is the key to the whole thing. :) –  Bobby Tables Sep 9 '11 at 21:52
add comment

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 :)

share|improve this answer
1  
It may be useful for you to clarify how you believe testing and QA are different. In some software organizations, the terms are used interchangeably. –  user246 Sep 11 '11 at 17:30
    
I should clarify: I love tracking down bugs, I just don't like being the one who has to fix it, or being the one who risks breaking something else with those changes. There's just something about being the "direct doer" of something instead of a pure analyser that really doesn't work for me. It's hard to explain, but very real. And yes, re: user246's question, what's the actual difference between Testing and QA? It's always been interchangeable in organisations I've worked with. –  Bobby Tables Sep 11 '11 at 22:06
2  
Testing - you test the product ( ie QC ), QA you define the procedures to make the product. Try this article from Michael Bolton - Testers: Get Out of the Quality Assurance Business - developsense.com/blog/2010/05/… –  Phil Kirkham Sep 12 '11 at 6:57
add comment

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.

share|improve this answer
    
+1 Interesting. Yes, I'm quite aware of the politics of having to release less-than-perfect, etc. I found being on the Development end of this more stressful, because trying to squeeze in last minute changes/fixes often breaks other things, and I hated looking bad because of that. When I was on the testing side of it I didn't find it as bad - I simply documented oustanding issues and noted "don't say I didn't warn you that this defect is still in the release.". But I can imagine in certain environments this would be stressful too. –  Bobby Tables Sep 12 '11 at 23:27
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.