Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Testing Heuristics - Thinking like a tester

Testing Heuristics - Thinking like a tester

This item in japanese

In a blog entry on the Software Education trainers blog Sharon Robson discussed James Bach’s talk at the recent STANZ conference (Software Testing Australia & New Zealand), in which he presented a variety of testing heuristics that can be used. 

Heuristic is an adjective for experience-based techniques that help in problem solving, learning and discovery. A heuristic method is particularly used to rapidly come to a solution that is hoped to be close to the best possible answer, or 'optimal solution'. Heuristics are "rules of thumb", educated guesses, intuitive judgments or simply common sense. Heuristics as a noun is another name for heuristic methods.

In more precise terms, heuristics stand for strategies using readily accessible, though loosely applicable, information to control problem solving in human beings and machines

 Robson reports the 36 Testing Heuristics that Bach spoke about in his talk, and the acronym he presented: cidtestdsfdpotcrusspicstmplfdsfscura which breaks into four groups:
Group 1 – cidtestd = Customers, Information, Developer relations, Team, Equipment & Tools, Schedule, Test Items, Deliverables. These are the high level planning activities, the logistical and the “set-up” focus of the testing. This helps set the context in which the testing will be done.
Group 2 – sfdpot = Structures, Functions, Data, Platforms, Operations, Time. I also heard Karen N Johnson refer to this acronym as San Francisco Depot (SFDPOT). This allows you to understand the environment that you will be testing in, in terms of scope, resources and time – the key arms of the quality triangle. This is a vital part of testing in my opinion and one that we often forget to consider in detail.
Group 3 – crusspicstmpl = Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatability, Supportability, Testability, Maintainability, Portability, Localisability. This is a great list of the quality characteristics of a system. I prefer ISO 9126 (it is shorter!) but this one gives excellent coverage of the key attributes that will need to be considered for any system. I really like the use of the “ity” at the end of almost all of these – keeps me focused on qual”ITY”.
Group 4 – fdsfscura = Function Testing, Domain Testing, Stress Testing, Flow Testing, Scenario Testing, Claims Testing, User Testing, Risk Testing, Automatic Testing. This list of the types of testing that may, could, should be done on a test project allows us to understand and explain that there is more than one way to test something, and to do it better we need to understand WHAT and HOW we are trying to test something.
In a similar vein Elisabeth Hendrickson of Quality Tree Software provides a heuristic checklist of items and areas of an application to test. In a recent blog entry she discusses how thinking like a tester could prevent a major problem from being released into the wild.
So even the most cursory Exploratory Testing by someone with testing skill would have been likely to reveal the problem.

What testing heuristics do you or your team use?


Rate this Article