QA vs. Testing - Part 2: What is the role of testing?

Answering this question may be where the core of the ambiguity lies. If I were to ask ten random testers (or “QA” folks) what the role of testing was, chances are good I’d get ten different answers. Since I don’t have time for any interviews this afternoon, let’s see what some of my favorite (and not-so-favorite) web sites, blogs, and search engines say.

The software testing wiki says that testing is “a process of executing a program and comparing the results to an agreed upon standard called requirements.” It goes on to say that “the goal of software testing should always be to find as many faults as possible.”

Wikipedia says that software testing “is a process used to help identify the correctness, completeness, security and quality of developed computer software”

In the software test engineering blog, chappell says the role is “to be an advocate for our users.”

My web searches show a lot of votes for “proving that software doesn’t work”, finding errors, and proving faults don’t exist. I didn't post all of the links, but I trust that my 19 readers know how to use msn search.

In Lessons Learned in Software Testing, (and also in Pettichord’s Context-driven school), the role of testing is simply to provide information to the key stakeholders (I’m paraphrasing because I’m too lazy to walk over to my bookshelf and look it up, but I’ll gladly edit this if I’m too far off the mark).

What this tells us is obvious. Software testing can mean almost anything. My opinion is in line with that of Pettichord – the role of software testing is to provide information. The information is comprised of test plans, test design specs, test cases, code coverage data, thread model analysis, data from static analysis tools, data from runtime analysis tools, data from performance, stress, load and mttf tests, data from formal inspections, defect data, and anything else that helps stakeholders make good business decisions regarding the planning and release of a software product.

I’ve said the following statement for years, and it’s worth saying again in this context. It is not the role of test to find defects – in fact; it’s merely a side effect of providing adequate information. When testers begin to think this way, the quality of their testing, and ultimately the products they are testing get better.

What does this have to do with the topic? The activities above are not quality assurance activities – they are quality control activities. Sure, it’s a heck of a lot more than merely test execution, but it's still "just" testing.