Testing Heuristics - Thinking like a tester

Posted by Shane Hastie on Oct 12, 2009

Sections

Process & Practices,

Architecture & Design,

Development

Topics

Software Testing ,

Agile

Tags

Testing

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

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.

So even the most cursory Exploratory Testing by someone with testing skill would have been likely to reveal the problem.

 

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

• Older >