[jwplayer mediaid=”1281″]
After the QA cycle there remains one stage that is vital to the test management process. That is a retrospective look at the testing process. Essentially, a retrospective is a post mortem, highlighting the positives and negatives of the testing. This may be useful to forthcoming releases and new projects. The post of this five-part series shows how to perform a retrospective – applying the data collected by Software Planner combined with contributions from your team – and a way you can record this information in a reference document.
The first stage of the post mortem is to analyse the task variances. This is the difference between how long a task is estimated to take and long it actually takes. As long as your colleagues are tracking their hours, Software Planner can show you this difference with the project management features. You can even compile a report based on the task variance. Analysing the task variances should lead to more accurate predictions in the future and develop your scheduling abilities.
Another thing that is worth analysing as part of the test management retrospective is the defects raised between software releases. Using the defect tracking features will allow you to compare releases, which will illustrate if there are more bugs in particular releases. You can also compare the number of defects found to the time spent testing. It is also worth tracking the number of defects that leak into production too, as this will demonstrate whether your techniques are efficient. By investigating the defects you learn where your team can get better and ensure that subsequent work will improve through insightful test management.
As a leader it is paramount that you meet with your team, informing them of the findings of the analysis, and provide them with an opportunity say how they perceived the work went. A democratic way to conduct this meeting is to ask your group to state three positives and three negatives about the testing. From there you can tally the recurring points and prioritise them into action items. By informing your team about your analysis they can learn for future releases. Their perspective will draw attention to the things your analysis may have missed, which is important to making sure your test management approach improves.
After completing your own analysis of the release with valuable input from your team, you should build a report based on that information. The report should consist of an introduction, an overview of the release, release quality statistics, a progress review, a list of action items, and a variances chart. By documenting your findings, you ensure that the lessons learned in this release can be applied to subsequent releases, leading to better test management overall.
Though it may not seem as important as other stages, a little time spent performing a retrospective can save you time and money in the long run. With the tools in Software Planner you can see where improvements can be made thanks to the testing and scheduling features. Speaking with your colleagues will provide further awareness of your team’s strengths and weaknesses, whilst the report is a handy reference document that could improve future working methods. In short, a retrospective is an efficient way to develop both your test management skills and future releases.
