Test Execution Model - updated

This is a follow on to the post I recently did about the automation pyramid that Richard Bradshaw gave at MEWT.

Following on from this some in the testing Twitterverse asked if Richard and I would do a video for the new initiative created by Richard called Whiteboard testing.  Instead of one video we decided to do two.  The first looked at the history of the test automation pyramid and you can watch it here: A look at the test automation pyramid.  The second video was a chance for me to present my own model which I have called the test execution model and can be seen here: - John Stevenson Test Execution Model.


After the video was posted I had a message from Dan Ashby who wanted to discuss more with me about the  test execution model and what he felt was missing.  We arranged a chat and discussed the model and broke down a few assumptions we were both making.  The outcome from this chat was the need to add a few extra parts to complete the test execution cycle.  With thanks to Dan I would like to present the next generation of the model.

The changes that Dan suggested for the model are as follows:

• As you test you turn some of your tacit knowledge into explicit knowledge which then can be added to your checks and become known known information.  This is represented by the flow from the testing arrow to the checking arrow at the top of the diagram.
• As you create more checks these in turn become oracles which you can use as heuristics for your future tests.  This is represented by the flow from the checking arrow to the testing arrow.

This then gives a cycle of test execution were the testing feeds into the checking which in turn can feed back into the testing.  It should be noted that is model is for test execution which does not only apply to only testing the product deliverable.  Testing is carried throughout the development cycle and as such testing activities can occur during artitecture & design discussion and during coding. Testing activities can and should occur anywhere during the development and deployment of the product and this model should be used in that context with regards to test execution.

Testing Skills #9 - Differentiating between wants and needs

One common discussion that keeps cropping up from testers saying that their managers are telling them that they 'want' this and that they 'want' that.  Normally in connection with 100% test automation or some other new shiny testing discussion point. A crucial skill a tester can have is the ability to separate what some one wants and what they really need.

It is common for people to not see the huge difference between these two words but having the ability to do so can improve your testing skill set.

The difference between the two is easy to explain with the following scenario.

Imagine that you have decided that you to be fitter and to do so you decide you want to be able to swim ten miles in one session.

Now ten miles is a lot and since the average human swims at about  two mph that is going to take about five hours to complete. You may never get around to meeting this want but you may come close.

Now one day you decide that you want to go sailing off the coast of Britain, you sail out to ten miles from the coast when suddenly the boat is hit by a huge wave and destroys it.  You are ten miles from the coast and if you do not make it back within five hours you will die due to the exposure to the cold water.  You now need to swim 10 miles in a single session.

This is the difference between wants and needs.  What people want is not necessarily what they need.

As a tester you should try and uncover what people need when they say they want this or that.  In the test automation example  it is useful to probe deeper and ask what is the problem they are trying to resolve.  By doing this you can get to the needs rather than the wants.

When the manager says "They want to automate all the testing" delve deeper to understand the problem the manager is trying to solve.  Ask "Why do they want to try and automate all of the testing?", "Uncover the needs so that you can understand what is being asked.

** The story about swimming is not my own and I cannot recollect where I first heard this.  If any of the readers can let me know where it is from I will add the correct attribution.