Recent conversations have reinforced to me the idea that a lot of people still don’t “get” QA or software testing. They seem to think that “anyone can test” and it takes no special skills or qualifications. How wrong they are. I’d like to see just “anyone” pick up a confusing, poorly-written user experience document and somehow turn it into a set of clear, concise test cases that trace back to, and verify, the underlying requirements. That’s just what I’ve been doing for the past week or so. Sometimes my brain wants to explode from frustration, but this is my job, and I think I do it rather well. After eight-plus years of experience, a master’s degree in information systems, and countless training courses and QA books devoured, I think I’m pretty well qualified too.
So what is QA? Why can’t “anybody” be a tester? I’ll leave for another day the discussion of what kind of personality it takes to be a good software tester (hint: being extremely picky and very detail-oriented helps), but let’s look at what QA and testing are. Here’s a page that, while not very pretty to look at, had some good ideas about what it means to do QA or testing. The definitions of QA and testing are, I think, quite good:
What is ‘Software Quality Assurance’?
Software QA involves the entire software development PROCESS – monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to ‘prevention’.
What is ‘Software Testing’?
Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, ‘if the user is in interface A of the application while using hardware B, and does C, then D should happen’). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ‘detection’.
There, that’s pretty straightforward. Note there are lots of other good questions and answers on that FAQ, including a pretty enlightening list of major system failures that were caused by software bugs. There’s lots more detail one can get into, and we could throw around terms like “verification” and “validation” and “white box vs. black box” and so on. But I think the bottom line, what I’d really like people who are unfamiliar with QA/testing to understand, is that it’s more than simply pressing buttons and something that “anyone” can do.
Software testing is:
- Controlled, planned, and carefully documented. It is (usually) not random.
- Repeatable. See the reference to planning and documenting above.
- Not always amenable to automation. Yes, automated testing can be helpful when used correctly, but it is not the end-all be-all solution to testing. Good manual testing has a place too and in fact, you have to be able to manually test first, before you can automate any tests.
- Carefully monitored and measured to provide useful statistics, defect reports, and lessons learned, which can help us develop better software in the future.