This is the third and last post 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 already discussed how to use the Session Based Test approach in case of testing a bug fix for the production environment and how to use the Session Based Test approach in case of testing a (small) feature improvement
In this post, I will focus on why using the Session Based Test approach is a good (perhaps the best) approach for testing a single project (different in size). Here we talk about applications of serious sizes or even solutions containing multiple applications.
Using The Session Based Test Approach For Testing A Single Project (different in size)
This situation is different compared to the previous two examples. Here you have to deal with a project of a significant size. Projects which are a part of a major release or program are most of the time under control of a steerco (steering committee) and managed by counting test cases for progress. Therefore focus on a project which are not part of a major release or program.
As a test manager I was successful in introducing the Session Test Based approach for migration projects. I worked on a migration project that took 2 months of test effort and another migration project of 20 months of test effort. Both had one thing in common. A comparison with an oracle was needed to determine if the migration could be executed or not. So I told the involved project manager that I had 1 test case (perhaps it is a check). Compare the output of the old system and new system and see if they are equal.
Saying that does not mean that it was an easy job. A lot of ground needed to be covered. The test team had a lot of knowledge of the system to be migrated so a mind map on functionality and test areas could be easily determined. We used the mind maps to generate test ideas, so we could almost directly start with the test execution. With the information gathered, we could continue with our test ideas or we adjusted (learning moment). Note that we worked with a “definition of done”. Our test ideas were focused on that, but opportunities to do some off track testing were not neglected. Hence, this information also needs to be described in your session report. It is all useful information. When we got the notion that our test ideas provided the information that we needed, we invited the project manager and some stakeholders to present our recommendation to ship, in other words migrate the application/solution.
During the test period, the team generated a serious amount of session reports to cover the areas defined in the beginning. I will write another blog about the different types of session reports we used (note that these session report types are discussed in the Session Based Test Management course given by James Bach)