This model evolved from discussions on Dan Ashby’s and Del Dewar’s similar models. Both have great testing blogs that are worth checking out.
As humans we are generally humble enough to recognise our own fallibility. We know we can make mistakes or miss things and we also know that there is always stuff we do not know entirely and even things we have just not thought of yet. This applies to equally to software development as it does to life.
In software development there are a lot of questions being asked and decisions to be made and making those decisions highly informed is where testing comes in.
For example one of those big decisions is ‘can we release to production?’
We want to make that decision as informed as possible as that decision can really impact the entire success model of your business. But it’s not just those big decisions that are important as there is a continuous flow of product related questions throughout an application’s lifecycle.
‘What harm could this feature do?’, ‘Will this add or detract from customer enjoyment?’, ‘Can the application handle a 3rd party update?’ and so forth. Testing helps answer those questions and in doing so helps empower development to stay on track and progress at pace.
As our diagram suggests this model requires a curious and investigative mindset which our second tester analogy covers well.
“The detective: CSI and highly technical Sherlock Holmes type tester”
Testing just like a detective’s investigation always begins with questions, our testers will use these questions to build out a list of risks, ideas and even plain old hunches that they feel merit further investigation.
Every product has its own set up risks but here is a fairly generic starting list that our testers have used productively on mobile apps, it should provide insight into what we mean here by a list of risks and ideas for investigation.
A testing session would involve selecting some risks or ideas from their list and investigating those. Like Sherlock Holmes that can often involve a lot of experiments and following clues to find the things that could be really harmful to the product or worse to the users of the application.
As we investigate we discover new risks or things that we add to our taxonomy of risks.
Once we have done our investigation we now as a team know a lot more and that risk can move into our known risk field where it can be regularly covered with automation.
Overall as our diagram shows its a very cyclic model of investigation, discovery and confirmation.
Our next section takes this holistic and team owned element a step further.