BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Testing Heuristics - Thinking like a tester

by Shane Hastie on Oct 12, 2009 |

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

http://en.wikipedia.org/wiki/Heuristics

 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?
 

 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT