How do you prepare yourself for a testing position?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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!

Answer 8

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