Following my wrap-up of the talk of Sami Söderblom given at the Agile Testing Days 2013.
Sami started his talk with telling about the monkey banana and water spray experiment done by G. R. Stephenson in 1967. He states that this is the way how company cultures are build: Everybody is following the rules he´s told by the others, but no one is questioning the rules anymore.
He also states that your work gets cluttered by a lot of waste, which originally is supposed to help you, but in fact it´s just waste, or noise, and the signal (your work) itself is being lost and because of that you´re becoming a zombie!
The cure to this is „Sapient Testing“ which is a combination of sapient and testing and can be described as „Thinking over Solutions“, where everything you´re doing should be guided by thinking.
He then refers to Thinking, Fast and Slow by Daniel Kahnemann, asking the audience to come up with different brands of chocolate bars in 10 seconds. Then asking the audience about how many brands they could come up with in 10 minutes. This, he states, are examples for fast and slow thinking.
Sami´s using the exact same thing to build test ideas & architectures, which he structures in a mind map (which is also used for test session reporting). This mindmap is also used to be compared with the 10,000s of existing test cases to remove the unused ones.
Sami says, that if you have to test for some sort of compliance (e.g. FDA), usually it is just being asked for what has been tested, but not how it has been tested. Usually these kind of tests are only covering ~ 10 % of the tests, the other 90 % are covering the underlying stuff.
If you then attach these mindmaps to your test mangagement tool (e.g. Quality Center) people notice that you don´t need this tools anymore and get rid of it.
Another step into direction of sapient testing is to remove the „expected result“ from test cases, e.g. for junior testers then „the digging“ (= thinking) starts.
Next step would then be to remove the steps from your existing test cases, allthough here junior testers will need some guidance in the beginning. A good way to describe tests is to use the template described by Elisabeth Hendrickson in her book Explore It!:
to discover [information]
According to Sami, this can be done on every level of testing.
You should remove little things and replace them by something smarter and always show how you think.
An important thing when doing bug hunting is to not hunt for effects, because there are much more effects then causes. Also your bug reports should not be based on effects.
Instead you should always discuss your findings with your team & stakeholders.
Sami closed his session by saying that you should not use any meaningless curves or diagramms, such as the Weibull distribution, which can become a self-fulfilling prophecy which then dictates your testing (see e.g. Cem Kaner for more details on this).
Find another useless graph in the top left corner of the following screenshot(*)
(*) Leave your guess about what this graph is representing in the comments. 😉