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.