PLAYING THE BLAME GAME

From time to time the testers (feel that they) get the blame for delays in projects. The impression is that we have not tested well enough and/or are delayed. Sometimes it is true – we are not prepared before the test period. Maybe we “guestimated” and not estimated the work needed to be done by the testers, and then copied old (not updated) test scripts with the approach test everything all over again. Quite often we even try to test systems with poor quality until (hopefully) the quality improves, and that can be a rather expensive approach (with low success rate).

Playing the blame game is actually not that interesting in itself, but more information about what actually happened can be very interesting. Some companies are so well established with their development and test process that they continue to create the same problems year after year. Everyone knows what’s going to happen, and they run the project with “open eyes” – waiting for the expected catastrophe.

So Dear Tester (and others who are interested); here is a list of possible reasons why the test team is delayed or not able to deliver:

• Activities in earlier phases (eg in requirements, design, development) was not completed before the next (test) phase started up.
• The code is not delivered to test according to agreed schedule.
• Deliveries from earlier phases were handed over to the test phase with poor quality.
• The test team receives a delivery with defect(s) that make it impossible to start the test execution, and/or a lot needs to be tested again when the rest of the delivery comes later.
• The test environment is not delivered according to the agreed schedule.
• The test environment is not complete with subsystems, configuration management, databases etc and / or unstable.
• The test environment does not contain complete and coherent test data.
• Test resources are not delivered according to agreement (often key resources from business).
• Other projects change the code integrated with the code under test.
• Other projects disturbing with their activities in the test environment.

Stop playing the blame game. Get over it! Find the bottlenecks and improve the development and test processes instead. Testers can start by doing a test process improvement assessment and document the maturity level on the test process. If you use the TPI NEXT® model it will also provide a better understanding of the correlation between the test process and adjacent processes. It will help discussing and addressing issues for improving the overall software process. Read more about TPI NEXT on http://www.tmap.net/en/tpi-next.

More Information

Gro Rognstad has a passion for Testing and Quality. She is Chief Technology Officer in Sogeti Norway and responsible for bringing our testing services and innovations to customers and employees. She is a senior advisor with a broad background and 27 year in IT – the last 17 years focusing on Testing and Quality. She advises organizations on innovation and Quality Transformation projects. Gro is active as a course trainer and speaker at seminars. In 2007 Gro was in the management team starting up Sogeti as a company in Norway. Gro is leader of Testing Services Community in Global Service Line Testing at Sogeti Group. She is also member of Global Testing Leadership Community in Cap Gemini group. In addition to that she is engaged as a board member of the Norwegian Computer Society, Community for Software Testing.