Blog post series about testing development projects, part 9/11

Articles about planning software testing and managing it.

Point of views:

• Business critical development projects, where IT plays a strong role.
• One or more outside vendors.
• Client’s business personnel as testers. They are business professionals, not software testing professionals.
• Goals for testing:
  1. Make sure that the implemented solution supports the needs of the business.
  2. Make sure the implementation doesn’t endanger the business.

The need for reporting in development projects

Reporting needs vary from project to project. The better the project is progressing the more general the reporting can be. If the project is in trouble, more detailed reporting is needed. Data is required to pinpoint and solve problems and to make informed decisions. Conclusion: if you want easier reporting, keep your project on schedule and budget.

I have heard someone say that, nothing can save a project that is progressing perfectly. If everything is going too well, the problems just haven’t manifested yet. You need to be able to predict the future too, and, as we don’t have crystal balls, it’s not so easy.

Here are a few of my favourite reports to help with quality assurance in development projects.

Project’s ability to solve problems

If you want quality testing that stays in schedule you also need to be able to fix defects quickly. They need to be fixed as soon as they are found so they can be retested and closed. If the amount of open defects keeps piling up, testing can’t progress.

I keep an eye every day on open defects and how soon they are fixed from Quality Gate Dashboard. This is a great tool to measure the project’s problem solving ability. If the amount of open defects starts growing, it’s time to react to it.

Here is an example:

People’s current workloads

A good tool for management is a report on what people are working on right now and how many activities they have waiting.

I like agile testing. I only release the next few test cases to be tested, the rest I keep on hold. Only when the testers start running out of activities I add more. This way I can prioritize what to do next and everyone has something to do the whole time.

Status reports

Traditional status reports are always mandatory to see where we are. These should be familiar to everyone.

Prediction versus current state

This is definitely my favourite. This report shows how the project is progressing when compared with my prediction. Your steering group will love it!

Since prediction based reporting might not be familiar to all readers, my next post will concentrate on how to make predictive reporting.