My “elevator pitch” for Session Based Exploratory Testing

At this moment I´m actively promote Session Based Exploratory Testing in the organization I work. The reason is, that I see opportunities that this approach can be beneficial for the some projects I´m currently working on. Some of the stakeholders are convinced, it for sure adds value.

Below some strong points regarding Session Based Exploratory Testing you can use in your story.

With scripted testing you determine your test set in advance. It is done during the test preparation phase. You must be finished with this when you start with the test execution. At that moment the set of test cases are fixed based on the information known at that moment. No room for improvement is allowed, because the beast of progress measurement kicks in and take over control. If you want to make a side step in your test execution (in other words, explore an unsuspected behavior) there is no room. You are doing something which can not be measured. You make no progress. This can be used against you.
Session Based Exploratory Testing gives you this room. You determine your test sessions at that moment you start to execute a test. When new information evolves, you can adjust. You just make a new test session. The beast of progress measurement can be controlled. Every day you perform 3 `normal´ sessions of 90 minutes of testing. You can do the calculations yourself how many sessions you can do e.g. for one tester in three weeks. The tests are done in areas within the application under test where the new things are installed and existing functionality has been changed. There you can expect the most important bugs.

With a test script you are following a predetermined path on your way to an expected outcome. You don´t write down any thing unless you see something unexpected. Than you have to write a bug report, report the test script as failed and continue with next test case.
With Session Based Exploratory Testing, when you are busy with a test session, you observing the behavior of the application under test. You write down what your experiences are, which steps you have executed, the test data you have used. When something unexpected occurs, you can investigate further. You can ask questions to developers, to architects, to the stakeholder or even to the application under test. This will trigger new test ideas you can use in your next test sessions. The tester is allowed to think.

Each test session you have completed is a test report. Each test report contains valuable information. You write down what you have done, the areas you have covered, the time invested in the session. Each session creates new information to continue with you investigation to find the bugs. This make Session Based Exploratory Testing structured and organized.

While telling this story to your stakeholders, make sure you have a small project in mind where you can try out Session Based Exploratory Testing. This is additional ammunition in your conquest to make Session Based Exploratory Testing a success.

More information can be found at Lessons Learned in Session Based Exploratory Testing.

7 Comments Add yours

  1. Very good, but there’s another important point that you could add. Session-based testing includes tracking how much time you spend on setup, how much time you spend on bug invesigation and reporting, and how much time you spend on test design and execution. This is very important, in that it’s easy for our testing clients to fall into the “lumping problem”; all of the activities that testers perform get lumped into this single thing called “testing”. Yet only the last of those three categories generates new information and test coverage; the former two categories interrupt learning about the product. This can lead to the illusion that the product has been well covered and well tested, when we might have spent most of our time trying to get things running and documenting problems.

    1. Michael, Thanks for your response.
      Your statement is an add on to the my blog. It makes the blog more complete. Only we can not call it an “elevator pitch” anymore.

  2. Unless this is a building with 1000 floors, you may need a shorter elevator pitch.

    My elevator pitch FOR exploratory testing is as follows: While it is great for FUNCTIONAL testing to be performed incrementally along with development, other aspects of quality need to be tested also. End to end usability, data integrity, security, and performance are among the areas of quality that don’t fit neatly within a “story”. Exploratory testing is one of the techniques we use to test risk to the product that goes beyond the code, and is one way that we find requirement gaps, race conditions, and produce create test cases to give us more quality data to balance out our functional testing.

    Thank you for helping me solidify my position on this area! Great idea for all of us to understand and clearly explain why we believe as we do, and professionally recommend one technique over another. 🙂

    1. Lanette, Thanks for your response.
      My pleasure for helping you. I like the elevator pitch on exploratory testing.
      Note that the elevators are not that fast in The Netherlands and if I talk fast enough, I can manage it in time ;o)

  3. Lou says:

    What rule says you cannot add/change/delete a script once it’s written? You use the word ‘must’ frequently, so I’m curious what process/methodology you are referring to that makes that statement. If your organization forces this, I really doubt a change in methodology will fix what I view to be a “common sense” problem.

    1. Lou, Thanks for your response.
      I use “must” in the sentence `You must be finished with this when you start with the test execution´. “This” refers to “test set”, which has to defined before we start with test execution. So, to start with the test execution, the test preparation has to be finished. Passing this mile stone makes the test set fixed. It can not be changed. Note that this is a statement in the company business process.
      Recently, I was assigned to test a solution with my team where time constraints were very tight. I stated that creating a test set cost time and due to that, we were not able to meet the deadline. I explained how Session Based Exploratory Testing (SBET) could benefit in this context. They where convinced and gave me the benefit of the doubt.
      Further, your doubts may be correct, but I keep trying. I already have some new opportunities where I can introduce SBET, because SBET in this context adds value.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s