Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm looking for advice on the best way to move from software engineering to quality assurance type of jobs.

Let's imagine a middle aged developer who is not up to date on all the current technologies and is having hard time finding a software engineering jobs because he's not really senior/principal engineer type and all the non-managerial positions seem to be taken by younger folks.

He has some decent scripting background in Perl/Python/Shell. I would think that he might be very useful on a QA team as a QA/scripter. Does this make sense? Is it possible to find a QA job like that with no pure QA experience on the resume? What's a good way to write a cover letter explaining this?

Looking for ideas/good sounding phrases for the cover letter/general feedback on the direction I'm thinking about.

share|improve this question

closed as off topic by MichaelT, Bart van Ingen Schenau, Jalayn, Dynamic, Martijn Pieters May 10 '13 at 0:59

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

you seem to be implying that QA is somehow a "lesser" job requiring fewer skills. I switched to QA not because I'm middle aged or because I'm not a "senior/principle engineer type". I moved to QA because it's a very challenging field. Writing software to test software presents a unique set of challenges. Plus, there are generally very few deadlines, and production problems can usually wait until Monday :-) –  Bryan Oakley Dec 5 '11 at 11:59
@BryanOakley I didn't mean it that way. More of less pressure to learn new technologies way. –  MK01 Dec 5 '11 at 16:25
Might also consider IT / SysAdmin. –  rwong May 9 '13 at 16:23
Also, no one will ever be up to date on all the current technologies. Pick a field. Web dev, network security, embedded, desktop, distributed, DBA, windows, linux, mainframes, ARM, DO-178, Agile, source control, static analysis, debuggers, profiling, the list goes on and on and each have their own shenanigans. There's a lot of overlap and everyone should know some sort of source control and what a buffer overflow is, but no one will be an expert in them all. –  Philip May 9 '13 at 16:56

3 Answers 3

Being a senior can be a big advantage due to the experience a senior developer has. The main concern is being up to date with the current trends, things which younger developer have advantage. It is important to be up to date with the current trends and practice, just as a guitarist has to make sure his guitar is tuned.

As a QA you have to put yourself in the shoes of the users and search for problems and usability issues they might encounter. The best advice I can give is to you is to search for a product he uses or would use with passion.

Things HR look in a QA is the ability to analyze, report, diagnose validate and troubleshoot. A senior developer usually has the advantage that he/she can provide mentoring and has a solid understanding of the development life cycle.

On the cover letter be sure to give them an insight of your passion for their product (if you have) and how your experience would benefit them. Write about a problem you have come across and you had to use one or more of the abilities mentioned above to overcome it, don't forget to maintain the cover letter relevant to what the company is searching for.

share|improve this answer

As someone who is doing more or less the same thing, I asked the same sort of question on the QA stack exchange site, and got some fruitful answers:


I haven't been successful with finding work so far. The Christmas period is always quiet so I'll only really get to search properly again now that things are ramping up in the new year.

But I think it's basically as they said in the answers to my post (and I've heard similar advice elsewhere):

  1. Don't make it sound like you're "downgrading to an easier job".
  2. Show passion for Testing and QA itself rather than talk negatively about why you want out of programming.
  3. Focus on what you can bring to the table with your development background.

Good luck!

share|improve this answer
Thank you! I'm not thinking of it as a downgrade. I think closer analogy is going from writing code to pure management -- nobody talks about that as a downgrade, right? –  MK01 Jan 4 '12 at 15:11

There's different types of QA jobs, and it depends on the company that you're looking at (the same title, in 2 different companies, can mean completely different types of work).

I'm an SDET (Software Development Engineer in Test). My job is functionally equivalent to an SDE, but my focus is to write things like...

  • Automation infrastructure
  • Automated integration tests (unit tests, etc. and the like would be written by SDEs)
  • Live service monitoring infrastructure and monitors
  • Training others to do the same

For this kind of role, you should consider the requirements to be equal to that of an SDE. The timelines are the same (or worse). The only upside that I could see for yourself is that you can get into the position where you've been writing tests and monitoring code for long enough that it becomes easy. However, if you're good at it and more than slightly ambitious, you'd probably get promoted or laterally transitioned before that happened.

I'm aware of some companies that have split this role into two similar roles where one writes and maintains the test infrastructure and the other writes all of the tests.

Neither of these positions, however, don't require you to stay as current as the developers.

There is also the STE (Software Test Engineer). I haven't worked specifically as an STE but I have helped perform those duties during crunch time before a heavy deliverable in the past. This role is usually comprised of:

  • Writing test plans (ie. all of the test cases)
  • Performing test cases manually (click x, observe y. type "abc", observe z)
  • Possibly/potentially record the manual tests and re-run them after changes
  • Some exploratory testing (good test plans usually negate the vast majority of exploratory testing)

In my experience, it's basically a manual testing role. All of your development experience and expertise will all be definite plusses for this kind of role.

As usual though, remember that pay generally scales with the difficulty of the position, and programming is often hard work. That said, the time I spent manual testing was heaven. I had just quit from a position where I had been ridiculously overworked, and it was nice to just "work" for a couple of months, where I knew exactly what I had to do, how to do it, what tools I could use and it was all laid out.

share|improve this answer

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