Friday - March 20, 2009

QA, Testing and Testers

The StackOverflow question included the following "mathematically proven that its cheaper to have QA staff (or Testers) do QA than having developers do QA".

This question implies that QA is testing and QA people are responsible for testing.   (Comments from the author bear this out.)  This is a very limited view of QA; a view that I think leads to numerous problems.

Quality Assurance isn't merely about testing.  QA has to include all of the quality features (performance, maintainability, adaptability, cost of ownership) and also has to cover the whole software development life-cycle from inception through operation.

If QA has such broad responsibilities, it can't be isomorphic to testing.  Testing should be just a small subset of QA's activities.

Who Writes Tests?

The question was hard to follow, but I think that it was really about the "balance" between testers writing tests and developers writing tests.

Somehow, the questioner felt that there was some balance point there.

Clearly, I've been doing TDD for too long.  How can there be a "tester" who isn't the developer?  Who is this mysterious person?

Then I remembered back 30 years ago when we had developers who didn't code.

Second-Class Citizens

These developers who didn't code wrote test plans, test scripts, and the like.  They created test data, set up test databases, created sample input and output files.  They did everything a developer does except check code into the repository.

Somehow these developers who weren't coding were supposed to help produce a higher-quality product. I'm not sure how this was supposed to happen, but it was -- for a while -- a pretty standard thing.

These second-class developers got the same requirements as the primary developers.  However, since they were second-class citizens, they couldn't do very much to fix or correct the requirements.  Think about it.  The tester finds a problem; talks to the users; initiates change control.  The primary developer now has a schedule change imposed on them by testers.  Unacceptable.

The second-class coders can wind up interpreting the requirements differently.  "That's not supposed to happen with good requirements."   If your QA doesn't happen until testing, what makes your requirements so good that they're beyond interpretation?

Because the second-class coders will interpret the requirements differently, they are in a position of arguing with the "real" developers.  Not testing, but disagreeing.  Who's right?  The developer can't get a test to pass, and the tester can't understand the requirements?  That will turn out well.

QA is Process

If QA is more than testing, then testing is clearly the job of the developers.  QA's job is one of audit and monitoring the entire SDLC.  Every deliverable (requirements, design, code, training, etc.) needs a quality plan, and QA needs to measure to see that the plan is being followed.

A requirements quality plan probably doesn't involve "testing".  The development quality plan probably involves many levels and types of testing.  Indeed, the development plan probably involves lots of different kinds of skills, and writing tests is only one of many skills.

Development is Testing

Since learning about TDD, I find I'm spoiled by writing my own tests and then writing code that passes the tests.  

When problems are found at integration time or (worse) operational turnover time, we have a really handy approach.  First, fix the tests to reproduce the problem.  Then fix the code to pass the tests.  

I think that QA == "testers" is dangerously limiting.  I think all developers must be testers.

Author: Steven Lott
Technorati Tags: QA Testing Developers
Technorati Cosmos:
Technorati Watchlist:
Add this entry to: