I updated the first part of my write-up about RST a little. You can find that post here.

Heuristic test strategy model

An important part of the RST course is the heuristic test strategy model. Teaching us the mnemonics. It is fun learning how these can be remembered easily: the dumber the mnemonic, the more memorable it is…

HICCUPPS (Oracles)
Nothing to explain here I think
SFDPOT (Product Elements)
Still not very funny, just meaning San Francisco Depot.
CIDTESTD (Project Environment)
Kid Tested and mother approved! From a cereals commercial we don’t know in the Netherlands
CRUSSPIC STMPL (Quality Criteria)
The Eastern European hockey player, rocket scientist, ballet dancer, poet and politician.
FDSFSCURA (Test Techniques)
The cry of roman soldiers storming into battle: “My sandals hurt!”

If you want to know what the letters mean, just watch this video I shot during class.

Test Strategy and test plans

After the impressive part on the heuristic test strategy model, test strategy and test plans were discussed some more. With a nice defintions of a (test) plan:
Plan (set of ideas that guide your test proces) = Strategy (set of ideas that guide your test design) + Logistics (set of ideas that guide your resources to fulfill the strategy)

“Usability is often a testability problem.”

Of course I have thought of testabilty before. I also can remember several occasions where I have asked developers to help me with scripts or tooling to do my work more efficient and more rapid. On the other hand are testers asking for testabilty enough? Testers can make their work far more efficient by collaborating with developers. Ask yourself the question: “how often do I discuss testing with developers?” In agile development this is becoming common practise more and more, but shouldn’t all testing be facilitated by good tooling? It will help testing become more Rapid. Let the computer do the counting (in logging)!

The faster we can test, the more chance we have to find bugs. Bad testibilty gives bugs a chance to hide and therefore it is a serious issue. RST gave me insight in the importance of testability and while studying the appendices of the course material, I found some nice heuristics (Heuristics of Software Testability by James Bach, Satisfice, Inc.) testers can use to gain insight in testabilty: Controlability, Observability, Avalability, Simplicity, Stability and Information. While reading I realized that this is an obvious list, but I can’t remember a single project I did or have seen where testers were aware of all these factors that influence their work.

Safety language

Another eye opener was safety language! Testers tend to be very precise. Results are compared in detail, using 5 decimals if possible. And after a couple of tests we say: it works! Since I attended Michael’s TestFraming tutorial at TestNet in July, I already knew the importance of telling the good stories:
1. The product story, about how the product works, what fails and what might fail.
2. The testing story, about how we have tested the product, what we want to test and what we won’t test at all.
3. The story about how good testing was, the testability of the product and the risks and costs.

This subject also came up during the intervision session we had last week at work, where 6 colleagues who went to EuroStar last year shared their experiences and take aways. One of the topics discussed were “elevator pitches”, the importance of presenting and effective communication.

Accuracy verus precision

“Sometimes we testers spent to much time to find precise answers as accurate answers would do.” The difference between accuracy and precision is nicely demonstrated on wikipedia. I like the target analogy very much. Another thing I took away as an open door, but very true and not applied too often: in testing we should let the risk define the level of accuracy and precision needed.

A quote to finalize this post: “Testing is about questioning and learning under conditions of fundamental uncertainty“.