36 Testing Heuristics

17 September

I was able to see James Bach at STANZ  2009 and one of his slides REALLY stood out. He called it the Thirty-Six Testing Heuristics, and he uses it as a checklist or reminder of the key things that need to be considered in testing anything. Sounds good huh? Well here we go:

cidtestdsfdpotcrusspicstmplfdsfscura

Everyone got that? Any problems understanding? LOL – it is just a quick way of listing the following things…a checklist to help focus your thinking:

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.

Why do we care about this stuff? Well….I often find that people struggle to understand the “entirety” of testing…ie, all the stuff that needs to be considered when we do testing. This helps to outline it to people!

I recently presented a paper on Agile Test Estimation – and mentioned this aspect as well. No matter what lifecycle we are using – these things still need to be considered. And having an impressive party trick like this may just be the answer!

This is a great list, and I am going to be trying hard to remember it. If you see me, see if you can get me to repeat it and if I get it right!

 

Posted by Sharon Robson

Thank you!

Your details have been submitted and we will be in touch.

CHAT
CALL