Goodbye Checker, Hello Tester

Setting the stage;

Software, you know the new feature set for the next release. At some moment you would like to get some information about the quality of your product. This is known as testing.

As I’m based in the Netherlands, the forces of TMAP are strong in my country. “Yeah let’s script everything (unsaid…that we can think of, or we have time/money for) into a test script.” We hire somebody (a.k.a. the tester) to stop thinking and just report whatever the outcome is from those (and only those) scripts.

That strategy always bothered my (it’s expensive, and frequently users find bugs which I hoped could be found earlier…), and then it happened. Last week I joined the Rapid Software Training by Micheal Bolton (great decision of me). He explained the difference between Testing and Checking. (Yes there is a difference!)

Micheal welcomed the class on Wednesday, 09:00, and started of with this;

• “Checking is something that we do with the motivation of confirming  existing beliefs. Checking is a process of confirmation, verification, and validation. When we already believe something to be true, we verify our belief by checking.”
• “Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning.”
• Testing ≠ Test script.

OF COURSE I want to find NEW information. That’s valuable to me; I’m willing to pay money for that! (@Micheal: yes I’m aware this statement is an emotional reaction)

He continued;

• A checker needs specifications, how good AND complete are your specs? Do you really want him to report on that document only? (ouch, no specification is complete by definition)
• Why would you suppress  discovery? (ouch)

It’s been a great course. Too bad it was only 3 days. Great learning experience. I’m looking forward to my next release. I will ask for a Tester instead of a Checker. My clients, project sponsors, users (and hopefully the tester) will appreciate me for this decision.

Recommended reading;
http://www.satisfice.com/blog/archives/856.

Fed up with “Best Practices”

Wiki’s definition;
A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark.

My definition;
A best practice is a marketing term for some idea that consultants find saleable.

Examples of Best Practices:
PRINCE2, Agile (preferably without product owner), TMAP, BISL, ALS, ITIL, Waterfall, Systems Engineering, JSTD-016……so-called “best practices”. Ohh <“shocked consultant”> are you not using <name best practice>? Here is the magic bullet….<name best practice>. Nothing can go wrong anymore.

My reaction;
(shouting, screaming) CONTEXT! Please, reframe Best into good practice, and you will increase your chance of success. It ALWAYS depends on CONTEXT.