I'm a developer. Right now we don't have much in my firm in the way of testers. Whether I do it here, or go to a different firm, I'm very interested in becoming a full time tester.

How would I prepare for a transition like this? I know I can read blogs and articles, but I'm looking for something more substantial.

What applications should I expect to be using (that I might be able to maybe even get a trial license to learn my way around?) Even if I'm not using it at the position I go to, I may find valuable insight from using it.

What sort of things should I study up on (that can be put on my resume, or otherwise dropped in a phone screen or interview? And yes, I plan to research and understand it, and use it in my personal projects, not just win a second round of interviews based on buzzwords.)

9 Answers 9


This answer should be seen as a supplement to Bruce's answer. I wanted to add a few more notes that wouldn't fit well in a comment.

A lot of the tools you already might use for unit testing will likely be useful - NUnit, mocking frameworks, etc.

Books to read: "How we Test Software at Microsoft", "Beautiful Testing", "Lessons Learned in Software Testing", and if you are interested in working with Agile methods, you should also grab "Agile Testing", and maybe even start with that book. I'm not recommending any newbie books for you because I think you already know the basics. Any gaps will probably get filled in while reading the list above.

You should practice manual exploratory testing. This is the most useful skill that you won't already have as a developer. Getting good at manual exploratory testing will make you a better automation tester as well, and I fervently believe it is a skill no tester should be without.

When you are being interviewed, you will generally be asked some form of, "How would you test this?" This will probably be your key interview question. The interviewer is looking for an organized approach. You want to be able to divide the test coverage you need into neat categories, describe a general approach for each (e.g., manual testing; fuzzing; automated regression tests), and then probably pick one group and start writing specific test cases for it.

E.g.: "Well, key things for this product will be functionality, security, usability, and reliability . . ." and so forth. Then you pick a category and go in depth: "Functionality should check the API and the UI, so I'll want some automated tests using fixtures to test the API. For now, we should just test the UI manually . . ." and so forth. Then come back and talk about, say, functionality some more, this time laying out specific test cases, e.g., "Let's start with a 'happy path' test case . . . here are some equivelence class tests we should do. . . some boundary tests . . . some error tests . . . now let's discuss UI manual testing a bit more . . . " etc.

If you are doing this right, your interviewer will have to stop you from listing out ideas for tests, even for a very simple application. This is the tester equivelent of being asked how you would implement [insert well-known software application here]. Just as you couldn't complete your code spec for a software application during the interview, you can't draft your entire test plan during the interview either.

  • 6
    It seems to be sound advice. I would like to clarify one point (and I think you know it, but I want to put it out here for others who might come across this thread.) I would like my appearance in an interview to be a reflection of my actual understanding of SQA. I'm not looking to game an interview. With that out of the way, I'm essentially turning the answers to this question into a draft with some check lists. I have a private project I'm working on, and am going to try to fit some of the advice here into it as a pilot for how to integrate it into the workplace.
    – corsiKa
    Commented May 12, 2011 at 6:16

Firstly, currently being ranked #1 on this site shows that you already have a good idea abou the basics and would get most positions based on what you know already. :-)

The exact tools that you are going to use would vary job-to-job dependent on technology, so I would actually research and find the tools that you want to use, gain experience in those and seek appropriate employment with the toolset of your choice.

For example:

Test automation

What is your language of choice? ... for VBA you would choose QTP, if Ruby then probably Watir or Selenium 2 , if C# then WatiN or Selenium 2, if Java then Selenium 2.

Test Management

Commercial tools: Probably HP Quality Centre ($$$) or TFS using Microsoft Test Manager ($), maybe TestLink (free).

Defect Tracking and metrics

As for Test Management but add Jira into the mix, and remove TestLink.

For the last 2, I would be learning how to customise the tools to suit process that you want to use, and produce the metrics that you want to see.

If it was me, I would focus on test automation first, then the others equally second.

  • +1 for OP having a good idea of the basics - I was trying to figure out from glowcoder's questions and answers if (s)he was already an SDET or a really savvy dev. Commented May 12, 2011 at 5:25
  • 5
    He is just a regular developer who just wants to be making the best software he can. He's frustrated with his current environment and wants to make it better. He also seems to be talking about himself in the third person... which is a little awkward. He's gonna stop that. Probably...
    – corsiKa
    Commented May 12, 2011 at 6:12
  • 2
    @glowcoder rotfl :-) Commented May 12, 2011 at 7:22

I would think that one thing you'll need to work on is changing your mindset. I have never been a coder/developer, but I do realize we think & approach a project in different ways.

As Carmi said, be curious & ask questions, but remember it isn't our job to fix the problem. We can provide suggestions and ideas but ultimately the decision on what and how is oustide our responsibilities.

Also, you have to be willing to push and ask about things that developers may not like. If you stay at the same company and begin testing the code of people you used to work next to, it could add an extra level of challenge. Not that it isn't possible, but something to keep in mind.

That said, having been a coder/developer gives you an inside track. You know where you struggled, skimped or took shortcuts, which means you know where to look first when testing software.

  • 2
    +1 Good answer. As someone currently considering moving from development to testing/QA, this really struck a chord: "be curious & ask questions, but remember it isn't our job to fix the problem. We can provide suggestions and ideas but ultimately the decision on what and how is oustide our responsibilities." - this is pretty much what's driving out of development and into testing. My mindset has always been better for testing than development this way. Commented Sep 11, 2011 at 22:39

I would suggest: test stuff, chat with testers, gain experience. Participate in WeekendTesting. This should help with any interview.
Have you heard about TopCoder? Try to do testing competition (when it is available - not that often).

I don't think that tools should be an issue for you. Coming from development, you should't have problems with TestAutomation/Performance testing tools. Other supporting tools, will be piece of cake. Besides most of the time, it's not about the tools, and not so much about terms and definitions (unless going for test management position). It is about creativity, approach, mindset, communication, asking questions, breaking the rules, thinking outside the box...

  • +1 for the links. I'm going to give that weekendtesting a shot (just as soon as my wife thinks it's a good idea for me to spend 8 hours on a weekend testing an application. Hmm.... well I'll give it a shot when I can!)
    – corsiKa
    Commented May 18, 2011 at 17:44
  • @glowcoder - it's not 8 hours, it's usually just 2 hours for a session. Not sure you're in the right timezone, but there are people doing weeknight sessions too now.
    – testerab
    Commented May 28, 2011 at 23:41
  • @tester - hmm I'll consider it. Although I've got a new project for my weekends: tinyurl.com/glowcoder1 :-D
    – corsiKa
    Commented May 29, 2011 at 0:10
  • Ahh... good old dice rolling. Unfortunately I don't do that anymore. I just fill the void with PC substitutes...
    – yoosiba
    Commented Jul 7, 2011 at 13:59

I used to be a developer and now I'm a tester. The automation part of the job will probably be easy for you. I assume you do test automation now in your developer position; if so, you should mention that on your resume.

In a test lead position, you may also need to write test cases and test plans, put a schedule together, track the project's status, deal with changing priorities, and work with/help other testers on your project. In that context, it might help for your resume to show that you can work with a team.

Finally, you should decide how you feel about doing manual testing. Some former (or aspiring) developers like automation but refuse to do manual testing. That's not a show-stopper but your hiring manager may want to know whether they can rely on you to help out with manual testing in a pinch.

  • 1
    Your assumption is a safe one to make. Unfortunately, it's incorrect. As another question of mine states, 1.5 million lines of code, 0 automated tests. I'm trying to get something rolling, and anticipate that I will end up transitioning into a testing position if it does roll.
    – corsiKa
    Commented May 18, 2011 at 17:46

In my opinion (not that humble, sorry), "knowing" QA isn't about the tools any more than "knowing" development is about how to use which editor. When you know what you're doing as a developer, you'll pick up the particularities of any programming language and any development environment easily as you go. QA is much the same, it's not about the tools you use, but how you use them. Unfortunately, these are not the things that go on a CV, but they do show in an interview.

The big things to know in QA are the different types of tests there are, and where they most effective. When to use black-box versus white-box tests; when to automate; when usability becomes an issue; benchmarking and performance metrics etc.

Most of what makes a good tester is really how their brain works. It helps to always be curious about how the code works, or where the data flows, and then to wonder what would happen if you dropped an unexpected input there, or whatever.

All that is for the interviews, for actually working at it, QA is only about 40% about testing. The rest is about constantly improving the process, from inception to release. Where I work, which has a very enlightened approach to QA/Dev, we actually have a report that details every bug found at customer sites, why it was missed in QA and what steps are being taken to ensure that similar bugs will not be missed. QA also has a say in the build process, we appoint an integration chief for a new project that doesn't let dev drive QA crazy with half-baked builds. There are a lot of sides to this, but it is the constant improvements in the process that make the big difference. Think Kai-Zen, but for knowledge work rather than manufacturing.


Being a good tester is so much more than knowing the tools that are available for automated testing or knowing the best "techniques". It is about knowing how software can be broken. It is about being able to think beyond the normal / expected usage of a feature. It is about thinking outside the box. It is about asking "Why is it this way?" for everything. To be a good tester you have to able to question everything you see and think about the things you don't see. As the previous poster says, it is a different mindset. As a developer you are thinking about how to create something. As a tester you will be thinking about how to tear it down. You will be doing the same thing over and over again expecting different results each time. Sometimes testing can be tedious - of course, this is when you start asking yourself if that task can be automated. The mechanics of being a tester are easily documented - being able to actually do them is another story. I believe that if a developer can change the way they think to become a tester they (we!) make the best testers!

  • I see. This does great about explaining what I need. I'm curious, how do I get it? What can I do to get myself into that mindset?
    – corsiKa
    Commented May 18, 2011 at 17:43
  • 1
    How do you get yourself into a "thinking outside the box" mindset? Hmm. Read Edward De Bono - and do the exercises. Read interesting material outside the field that's relevant to testing - about how we make decisions, heuristics, perception and biases. Try mindmapping, or other ways of getting info into visual form. Every time you run a test - ask yourself, can I think of at least 3 different ways to achieve this task? Do I know which ones the user will pick? Learn about heuristic test oracles like HICCUPPS and use them. Practice test katas. Get hold of Elizabeth Hendrickson's Cheatsheet.
    – testerab
    Commented May 30, 2011 at 3:12

Sign up for an account with utest. It's a great way to get started testing in the real world. There's no job interview, and you're paid entirely on the basis of results. You can set your hours and participate how much/little you want. You'll end up with real-world experience in testing, and you can keep your day job at the same time.

(Ok, I guess that all sounds like a marketing pitch!)


Software testing has a lot of tools/technologies which tester should know.The most of them are really useful. But the key idea to be most appropriate to company's technical requirements.

For instance, you open a vacancy of "A" company and see something like that: "to have experience in continuous integration (TeamCity, Bamboo, Hudson)", "Mmmm, what is it? Oh, okay, I should learn about it((",-you are telling yourself.

How is it going? Yes, a lot of tools require licenses, but there's YouTube with video-views, there are a lot of tutorials to any frameworks - I recommend to read technical documentation on needed tools because it is so necessary for tester to can understand technical documentation.

I want provide a set of common tools for tester which will be really useful in your tester's work:

-Bug trackers: Jira, Redmine, Gitlab, Phabricator.
-Test Case Managers: Zephyr, TestTrail, TestLink.

-API testing tools: SoapUi, Fiddler, Postman, jMeter, Runscope, Advanced REST Client.
-Debugger: Firebug Test automation tools: Selenium, Watir

-And books: Software Testing: A Comprehensive Approach - Bill Laboon, Agile Testing: A Practical Guide for Testers and Agile Teams - Lisa Crispin, Janet Gregory, A Practitioner’s Guide to Software Test Design - Lee Copeland

But when I was looking for a job as a software tester I met the one real problem - my resume. I considered I provided all of skills that completely match with hiring managers needs but I didn't get feedback until I rewrote my resume. It is easy to tell (and actually do): write a readable, informative, catch-eyeing, good formatting resume but I had to read a lot of literature to realize how many problems I had with my resume. I tried to combine my knowledge in the one place and now I want to share it with you. I pretty sure if you use this advice you can get a software tester position.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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