This post is the first out of three on where to use the Session Based Test approach with the goal to convince management that this is a good and perhaps the best approach in its context.
I use the Session Based Test approach for :
- the test of a bug fix for the production environment
- the test of a (small) feature improvement on an existing application or solution
- the test of a single project (different in size)
In this first post I will focus on why using the Session Based Test approach is a good (perhaps the best) approach for testing a bug fix for the production environment.
Using The Session Based Test Approach For Testing A Bug Fix
You probably have heard it more than once. ‘There is a bug fix coming and it needs to go to production as soon as possible’, the manager shout. ‘Okay’, you said. ‘What is the problem exactly? Where are the specifications. I need to read the documentation. I have to write test cases’. These are all legitimate remarks and questions in a “waterfall managed” environment. ‘Don’t give me a hard time, test the bug fix. Just do it’
This is the moment where you can decide to test the bug fix using a Session Based Test apporach. Why? You need to collect information about the bug. Who has this information, is it documented? Where? What is the problem exactly? Can I get input data to perform my tests to recreate the problem on the test environment? Can I have access to the production environment to recreate the problem there too?
All these question you have need to be answered. So, write them down. Then go find the person(s) who can help you with answering these questions. Write this down. Guess what? You just have written a session report. At least the notes for the session report, you only have to put it in “the correct format”.
When you have collected all the information, you are going to perfom for sure two tests. You test the situation before the bug fix. This is the reference. Write down the steps you exectuted. Collect the output results and store it. Install the bug fix. Execute the same test again with the same input data and collect the results of this test too. Check if the output shows weather the problems is solved or not. All these actions are collected in your second session report.
If needed, you will do some regression test to see if the bugfix did not introduce other problems. These tests and the results are collected in a third session report.
All the test are executed with success, so the final verdict is; the bug fix can be shipped to production. You write your final session report where you write down your recommendation and where mention the other session reports. These session reports will support your results of the test execution you did for testing the bug fix.
Some very important things can now be said. First, you have done it fast. In this example 4 session reports, that is approx. 4 hours of work. Second, the tests are executed in an orderly fashion, a structured apprach. Third, your work can (and will) be reviewed if needed.
In my perception some rock solid Session Based Testing of the Exploratory kind. You gathered infomation. You questioned the product in order to evaluate it, to learn from it. With the results, you made an informative decision. In this case; ship the bug-fix to production.
So if encounter such a situation where you are asked to test a production hotfix quickly, follow this approach. The magic words were spoken. “Just do it”. I did it several times, with success.