and epiphanies by the tester all can cause a change in test volume. It's also important to map these events back to the changes they caused, so fluctuations can be accounted for and those changes avoided-or at least understood-in the future.
The Pass and Executed tests are added to help chart changes in those values. Fail and Not Executed aren't important enough to transfer, since the most significant information needed is the Pass % (If the Pass % isn't approaching 100%, there's a problem). Executed % and Executed & Pass % are transferred to see how they trend over the course of the project. Graphing all this data makes it a bit easier to analyze.
Figure 4 summarizes all the data that we've discussed up to this point graphed for quick reference and comparison to the project progress. The Pass % for each area is displayed as well as the overall values for Total Pass % and Executed & Pass % . As you can see, tremendous progress was made at the beginning of the project. It then took half of the project timeline to pass the last 10% of the tests! It turns out that this was a pretty typical observation. We can also see that the test results for Dialing on 12/6 were lower than the last report on 11/29. This is important to the part of the team working on Dialing, but the volume of tests in the Regression area of the project had more weight on the total project progress and pushed the Total Pass % up.
Metrics can help explain project progress. You now should have enough information to begin some basic test project tracking. In Part 2, we'll discuss applying what we've learned to future projects.
Click Here to Read Practical Test Reporting--Part 2