A Testing Career in 3-D

Software testing is becoming a cool job. I've heard from several people lately who are working in perfectly respectable and highly technical jobs, but they want to know how to get a chance to do testing instead.

I frequently receive questions about how to break into a career as a software tester or how to learn how to test after getting a testing job and no instructions on how to do it. I'll offer a framework for figuring out how to get started and how to grow.

First, the bad news
It's a tough job market out there, at least in the places I've been monitoring. On the swtest-discuss mailing list, consultant Rex Black recently said: "Given the commoditization of technical work these days, I would be loath to recommend to anyone not living in India or China that now was a good time to pursue entry-level software testing work."

You should take a very careful look at the job market before you decide you want to become an entry-level tester, given the number of experienced testers and other software professionals who also are looking for work now. If you're still determined to stick with it, read on and I'll offer a plan B, too.

Three dimensions
Another thing we can learn from Rex comes from chapters eight and nine in his book Critical Testing Processes. He presents the management perspective on hiring and growing testers. Here, I'll discuss it more from the tester's point of view.

Rex talks about three categories of skills that hiring managers should look for (plus some very important "general qualifications"). The skill levels in the three categories vary widely between candidates, and it's often hard to find someone who's strong in all three. You can make yourself more marketable by improving in one or more of these dimensions:

Testing skills
It's common for people who are strong in the other two skill areas to find themselves in a testing position, even though they know very little about testing. They can find bugs using only common sense, but they could be far more effective if they learn some of the vast amounts of available information about testing that has accumulated over the last several decades.

There is no universal standard set of testing skills that will always be beneficial on a project. If you are currently working as a tester, or if you can learn about the places you might want to work, you can assess which skills you need to polish. Otherwise, read about different kinds of software development processes and decide which ones you'd most like to work with.

For example, you might want to learn how testing is done on low-process agile development projects. Or maybe you'd rather learn the rigors of testing in a safety-critical, military, or regulated environment, where standards are more likely to be important. Maybe exploratory testing is useful in the companies you want to work for. Or perhaps it's better to first become an expert in test design techniques and writing detailed, step-by-step test procedures. System testing or functional testing? Automated or manual? Process improvement? You can't learn it all at once, so be sure to prioritize based on the needs of the types of places where you want to work.

Domain knowledge
How well can you relate to the people who will buy and use the software? Do you understand the problems they're trying to solve and how they will use the software to solve them? Ideally, you've been an end-user yourself. You can fake it sometimes, learning on artificial problems, but you can't beat having been in the trenches doing real work. You might have to be a CPA to have domain knowledge of financial software or a graphic artist to understand graphics software.

I recently tested a peer-to-peer application. I hadn't used that type of program before, so I really can't say how well it solved the problem at hand. I did know some tricks that work on just about any application, and I had a general idea of usability, so I managed to find several bugs. But the testing won't be complete until a domain expert also takes a look.

Technical expertise
Debates are raging in the testing community about how technical a tester has to be. One particular sticking point is whether a tester must learn a programming language in order to advance. Given the right environment, testers who can't program can be effective. But a tester who understands a scripting language or the language that the system under test is built with has a big advantage. In a competitive job market, you need that advantage.

Other technical skills to build include user-level knowledge of a variety of operating systems, as well as system administration skills.

A flanking maneuver
What if you can't land that testing job you want? Pick the parts of the three dimensions that are most interesting to you, and find a job that helps you build those skills. You may have an opportunity later to use those skills as a tester.

You can build your technical expertise by doing programming, system administration, or technical support. Or build your domain expertise by working in the trenches in the domain that you like or perhaps in the marketing department of a software company that serves that domain.

Along the way, you can build testing skills by volunteering on an open-source project. You can target a project that's in a problem domain that you want to work with. When you work with open source, you're more likely to learn about bug reporting, exploratory testing, and unit testing than writing test plans or detailed manual test procedures. So keep reading to fill in the gaps, like you're doing now.

Whatever you're seeking, I wish you a successful quest.