Entry and Exit Criteria For Software Testing

1. The requirement should be completely covered.
2. The Sev2 and above issues must be fixed.
3. The documentations must be done for that application and so on.

Exit criteria will include what all required to end the test cycle as follows:

• Deadlines (release deadlines, testing deadlines, etc.)
• Test cases completed with certain percentage passed
• Test budget depleted
• Coverage of code/functionality/requirements reaches a specified point
• All defects are fixed or closed
• Closure reports are singed off
• All the test cases have been executed and passed
• Beta or alpha testing period ends
• Budget allocated for testing is exhausted
• The risk in the project is under acceptable limit.

Practically, we feel that the decision of stopping testing is based on the level of the risk acceptable to the management.

As testing is a never-ending process we can never assume that 100% testing has been done; we can only minimize the risk of shipping the product to the client with X testing done. The risk can be measured by Risk analysis but for a small duration / low budget / low resources project, risk can be deduced by simply:

• Measuring Test Coverage
• Number of test cycles
• Number of high priority bugs

One of the most important mechanisms is the use of exit criteria to set specific goals for an activity. Exit criteria can be used to define success at the end of any activity, test level or project, so this concept has multiple uses within software testing projects.

Entry criteria can also be used where it is necessary to decide entry to an activity based on factors other than the success of a previous activity.

Benefits of managing testing projects by making use of entry and exit criteria

There are two important advantages to managing testing projects by making use of objective entry and exit criteria.

1. The criteria for successful completion are set at the beginning of the project, well before the pressures associated with delivery are felt, and can be based on a consensus of all the stakeholders.
2. Decisions are visible and simple at the transitions from one test level to another and at delivery.

These advantages do not, in themselves, provide any guarantee of a successful project. What they do achieve, however, is to make the decision-making process more open throughout the project. Every stakeholder can see how well the project is progressing against its quality criteria and if any decisions are required to authorize progress beyond a milestone for which the criteria has not been met; the implications are clear to all.

At the point of delivery a final release decision will be based on criteria that are met, nearly met or not met. Where the criteria are met the release is straightforward. Where the criteria are nearly met a risk-based decision can be made based on the gap between the criteria and the actual achievement. Where criteria are not met the decision may be more tricky, but even here the existence of objective criteria can help to quantify the level of risk and select the best action plan.