Game Development Reference
In-Depth Information
Alternatively, test results could be broken out into separate categories, as shown in
Figure 6.4. These extra categories do not affect the PCE numbers or graphs, but this
could be more convenient for data collection if different systems or categories are used
for different release types. This data
also helps the team understand
whether there will be additional test-
ing activities that could further
reduce the PCE numbers as more
defects are found. In Figure 6.4, no
Beta testing results are available to
add to the table. So, the PCE num-
bers for requirements, design, and
coding only represent the maximum
possible value. New defects found in
Beta testing will be sourced to these
phases and reduce the corresponding
PCEs.
Figure 6.3 Game code phase containment graph.
Figure 6.4 Game code phase containment data with expanded test categories.
If this practice is useful for understanding how well the team is capturing defects in
the game code, it should also be applied to the work produced by the testers. Figure
6.5 shows example PCE data for testing deliverables and Figure 6.6 shows the corre-
sponding graph.
As the test PCE data shows, some faults in the tests don't get noticed until the test is
executed on the game code. The problem might have been recognized as a test defect
by the tester running the test, or it may have started out as a code defect before analy-
sis and retesting uncovered the fact that the test was wrong, not the code. You can
imagine how much more time consuming that is versus finding the defect before
releasing the test.
Search WWH ::




Custom Search