Playing the blame game

Aug 20, 2014

Sogeti Labs

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.

About the author

Sogeti Labs

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Comments