[Jump to start of article]

Home > Testing Documentation > Software Testing Entry Criteria

Software Testing Entry Criteria

Entry criteria for testing are one of the documents required for the “Prepare to Test” step of the Testing Process. They are the necessary conditions that have to be in place before testing is run. Normally they are included in the clause 6 “Approach” of the test plan.

All the criteria are there to prevent testing time being wasted at any stage in development. There is no standard for what should be included in the entrance criteria, but there are a number of items which should be considered for inclusion. They break down into two sets of responsibilities: what the testing, and development teams have to have done.

Testing Team’s Responsibilities

The entry criteria for the testing team involve ensuring everything is in place to enable the testing of the software system to take place. There are three main criteria headings to consider:



An approved testing plan

A testing plan needs to be developed in advance of the start of testing, and crucially agreed to by all the stakeholders. These include the testing, user, and development teams. This way the testing risk is known and shared.

All resources available

Testing is not done using a person normal working environment. Some of the resources which need to be in place are:



All tests developed

All the acceptance criteria, test cases, and test scripts need to have been developed and signed off by key stakeholders before the testing runs start.

Development Team’s Responsibilities

The entry criteria for the development team are to ensure a working version of the software is delivered to the testing team to allow meaningful testing to take place. There are four main criteria to consider:

Documentation is in place

The development documentation required for the next stage of testing, such as the requirements specification, needs to be updated. Often this will not be available, in which case the developers must provide support for any questions that are asked, such as having a senior developer defined as the contact person, and even sitting with the testers.

Test Summary Report is delivered

The Test Summary Report from the previous testing phase outlines what faults have been found and which have been fixed. It gives the state of health about the system from the previous stage. You can then make a judgement call about these known outstanding faults and see how they will affect this stage of testing. The real point about this criteria is the acceptance of the report, and hence the system, by the testers. It is not just about the delivery of the report. In fact it should relate to the previous steps Exit Criteria.



System demonstration is given

A demonstration of the system to show basic functionality works. This is sometimes called a smoke or intake test. This is often the hardest criteria for developers to agree to, due to the problems in running many systems. Nonetheless it should at least be discussed as it gives confidence to the testers that they are not wasting their time.

Test Item Transmittal Report is delivered

The Test Item Transmittal Report, or an equivalent handover document, shows where the system is located, its build, along with what changes have been made. This document should be signed off by an agreed authority on the developer side, which commits them to having delivered a reasonable quality of software.

Entry Criteria Importance

These seven criteria along with the Exit Criteria from the previous stage act as the gate way between stages of development in the testing phases. With them in place much wasted effort can be avoided.

Entry Criteria Relationships