Confirmation and Exploration: two testing cultures

Over the last year or so, I’ve been thinking about the different cultures that emerge in testing teams and in organisations, and working on ways to explain these. This image is a visual representation of some of the differences that can exist between a culture of Confirmation and a culture of Exploration. You can read more about my thoughts on Confirmation Culture in this post.

169CE78C-61DE-42FD-8237-152D32F61F07.jpeg


There are many influences and sources that have helped shape this view. Among the most significant are:

  • Elisabeth Hendrickson’s work and particularly the book ‘Explore It!
  • James Bach, Jonathan Bach and Michael Bolton’s work and articles on Session Based testing, and the subject of ‘Testing and Checking’
  • Nicola Owen and Patrick Prill who were both kind enough to review and comment on an earlier version of this representation

I would welcome comments, responses, agreements / disagreements and suggestions on how to improve this view. I hope it will be useful for others, especially those who are looking to make a change in the testing culture in their team or organisation.


7 thoughts on “Confirmation and Exploration: two testing cultures

  1. In my view, you need both, especially if the application under test is going to be offered for sale. The confirmation model is a part of the production process. It demonstrates that the product is compliant with the advertising claims made for it, the requirements of the client (if the product has a bespoke element) and that it conforms to legal and regulatory requirements. The process of writing and executing scripted tests creates a body of knowledge about the operation of the application which will be useful to technical authors responsible for writing manuals and help files.

    The Exploration process is important at different stages in the development process. It is the mindset required at the requirements gathering stage, testing the application before it is even built in terms of exploring and probing the specification and expected functionalities. And it is also the mindset required in the prototyping phase, testing a finished product – preferably pre-production – to explore whether it meets the requirements and what the limits of system performance are.

    The problem is that in many commercial settings, that prototyping phase is collapsed into as short a time as possible to get the product into the marketplace and earning back its development costs. Establishing the system’s performance limits and exploring the different ways users will interact with it then takes second place to giving business managers assurance that the application does what it says on the tin and ticks all the boxes, legal, regulatory and client-oriented, that it is required to. I’ve seen instances where applications which have been undergoing exploratory testing have ben rushed into deployment because the box-ticking confirmatory testing has influenced the business to the extent that they think that to be the whole story and even that the application is “bug-free”. It all fended in tears.

    Liked by 1 person

    1. Hi Robert – I absolutely agree that both can be valuable and the extent to which they are valuable depends on a host of factors, perhaps most importantly the business context and the need for information to support business decisions

      The mindset you describe of ‘checking that it does what it says on the tin’ is one that I encounter regularly and whilst understandable, it really does limit the value which testers can provide. Incidentally I think its also a common misconception that checking is always quick or easy, whereas exploration is likely to take longer. In my view, exploration can often provide useful information about risks more efficiently and earlier in the ‘project’, as you allude to when you talk about probing the specification and requirements.

      This might be of interest; a view on phased versus threaded testing from Aaron Hodder which I think neatly explains some of the difficulties which organisations and teams can encounter and a different way of looking at testing activities:

      View at Medium.com

      Like

  2. Hi Richrtesting,

    A nice graph showinh the key points on each side.
    The only thing I would suggest to change is, use an exclamation mark on the left (confirmation) side and stick with the question mark for the explorative side.
    Isn’t the confirmation teating rather “a statement of status” than “questioning the software” (explorative testing)

    Would it be possible to send me a pm link or file of the picture that I could use in my trainings?

    Liked by 1 person

    1. And sorry for the typos… that’s what happens when writing on a tiny phone with fat fingers…😳😉

      Like

    2. Hi Joerg, the exclamation mark is an interesting idea. I suppose my thinking was that in a culture of Confirmation, testers are still answering questions, perhaps not always the most useful questions but questions all the same. Certainly worth consideration to differentiate the two sides of the graphic though.

      On the subject of the picture, I’m happy for you or anyone else to make use of it but please do reference this site on any slides or material you produce. You should, in theory at least, be able to take a copy of the image from here, but if the resolution isn’t up to scratch you can email me at richrtesting@gmail.com and I’ll send another version across.

      Like

Leave a comment