Even in a world where software and system development is preferably done with Agile methods such as SCRUM, there are a lot of systems where these approaches aren’t considered the best or most effective. In Capgemini Technovision, this is described as multi-speed IT (‘From Train to Scooter’). However, even in the most traditional application lifecycle models where development is done using the waterfall approach, agile practices can be adopted to for better flexibility and efficiency; especially--but not limited to--in testing.
By traditional methods, testing is done in the final stages of development. It is often perceived as the stage where some mandatory quality checks have to be done (necessary evil) and it’s not uncommon that the testing phase is cut short for various reasons, with all the consequences it brings. Often times, there is no time to cover even the high risk criteria. Although this seems to be an accepted practice, most testers aren’t comfortable with releasing a product that has undergone minimal testing in the most crucial areas. Using an Agile approach can help both testers and business become more comfortable in effectively completing the testing phase in shortened span of time.
The traditional testing process as described in both TMap® and ISTQB consist of planning, preparation, specification, execution, and closure. This is not very different from SCRUM. Although the SCRUM process focuses on all development activities, including analysis and build, the process can also be applied to one specific activity like testing. When put in practice, I experienced a significant increase in flexibility and involvement of (accepting) parties.
Let’s take a closer, but still general, look into some parts of its appliance. Mind you that I am only using the analogy with SCRUM, but not all parts of testing can be exactly plotted. It should however inspire you to create your own agile testing project. To begin, create “epic”, which has the subject “testing of project…”. Information can be added in the epic itself just as in a traditional test plan, which covers the scope, entry and exit criteria, goals, and high-level strategy. Set up a backlog where you can now add “user stories” and “enablers” (you will need both!) and also add the amount of “points” and the date the project is due on. The enablers are test activities and user stories are specific functionalities or risks you want to cover with tests. You will notice that there’s a difference in traditional test planning here, because there’s no planning on milestones and specific dates, but planning is done on time needed to perform a task.
Add the enablers--it’s the main activity that has to be done as test activities for the project. For example: Set up the test environment, perform test or product risk analysis, create design test cases, execute test cases, automate test cases and (or) deliver test reporting. Each enabler can be broken down into tasks. The actual test cases can be plotted as tasks into the design or execute enablers, but you can also add them to the specific user stories they test. You can choose whichever suits you the best. I like to make an extra, separate burn-down chard for the design and execute enablers to have more detailed information on coverage and progress.
Failed test cases can be transferred to the impediment part of the Kanban board, the bug is of course administered in the defect management system. When you have added a re-test enabler, a test case in impediment can be transferred to this re-test enabler when the corresponding bug is solved.
Enablers are misused as pure testing activities. They enable the actual testing of the user stories, which are corresponding to the build functionality and (or) specific risks you want to cover with tests.
These user stories are also added to the Kanban board. I like to split the board in a top and a bottom section. One section is for the enablers, the other is for the stories. The stories are prioritized on the board. When you do this together with your accepting stakeholders, you can also show in a very easy way that some of the stories might not fit the time box; exactly the same as doing a sprint planning, you cannot commit to stories you don’t have time for. Although this doesn’t solve the problem of parts not covered mentioned earlier in this blog, it helps that the feedback is more direct, decisions are made very early in the testing process, and that--like in much projects--the information on ”this was not tested due to time restrictions” is not given only in the final test report.
Although this blog does not cover all the details of the application of the SCRUM process in the testing process of non-agile projects, it might give you an idea on how to apply your own form of the process into your project. You can also define sprints of one week, when you have, for example, a weekly delivery of a new system-under-test. You may also define sprints that correspond with testing levels. You can tweak the activities so that it will optimally support testing in the software delivery lifecycle.