Exit

Unit

Statement coverage meets or exceeds 85 percent.

I prefer to see a standard of 100 percent statement and decision coverage for all new or changed lines of code. I also recommend that automated unit tests, implemented with a specified tool, be deliverables for each unit of code.

Entry

Component integration

Code static analysis complete, no outstanding errors.

I would make static analysis of units an exit criterion for unit testing for all new or changed modules. For entry into component integration testing, I would require two or more communicating units that had exited from unit testing. I would also require an approved integration and integration test plan.

Exit

Component integration

All components of functional areas integrated (interfaces verified to be working correctly).

If you can make this happen, another excellent criterion is to have automated integration tests, built with the same tool as the automated unit tests, be deliverables of integration testing. Together with the automated unit tests, you will have a powerful and maintainable regression risk mitigation tool.

Entry

System

No outstanding blocking defects.

This works, but it does require that earlier levels of testing have some type of defect tracking process. Otherwise, a special sanity or smoke test must be run prior to entering system test, with the results of that smoke test determining whether the product is ready for testing.

Entry

System

All known defects documented.

As with the previous criterion, this requires that sufficient information be collected during the earlier levels of testing. Otherwise, the smoke test can be used to establish the known defects, but that really doesn't address the spirit of this criterion.

Exit

System

All performance requirements met.

I would suggest that, in addition to performance requirements (i.e., resource utilization, response time, and throughput), all functional and nonfunctional requirements should be met. If any requirement is not met, then a cross-functional team including product and project management should be allowed to accept the problem as a known limitation.

Entry

System integration

No outstanding high priority or severity defects open.

Assuming this test level is preceded by system test, it's reasonable to assume that defects are tracked. However, if different groups are involved, integrating and making sense of the information can be an issue if you didn't or couldn't address the issues discussed in the previous sections on communication and merging test efforts.

Entry

Acceptance

All planned testing by the test group(s) has been completed and the testing results meet the specified criteria.

Of course, the "specified criteria" mentioned in the syllabus must actually be written, measurable, and relevant for this to work. Also, you should be careful to define what "completed" means in terms of testing. Ideally, completed testing has the connotation that all important coverage items were tested, all of the tests pass (or known failures have been officially accepted as limitations), and there are no known defects (other than these accepted limitations).

Exit

Acceptance

Sign off by the accepting parties

I suggest that the sign-off occur after a management review where the results and completeness of the acceptance test are evaluated, discussed, and approved.

option to purchase exam for $150