Lesson 2 of 6
Entry criteria: are we ready to test?
8 min
Listen to this lesson
Entry criteria are the conditions that must be true before a test phase starts. The ISTQB Foundation syllabus describes them as preconditions for undertaking an activity. They exist for a practical reason: starting a test cycle that is not ready wastes testers' time, fills the defect log with noise, and produces results nobody can trust.
Typical entry criteria on an SAP program
| Area | Entry criterion | Contoso example for integration test cycle 1 |
|---|---|---|
| Environment | Test system and client available, refreshed and stable; integrations connected or simulated as planned | QAS client 100 refreshed; EDI to Great Lakes Fleet Services connected to the partner's test system |
| Build baseline | All planned transports imported; unit and string tests completed and recorded | Build 7 imported; string tests for order to cash and procure to pay signed off by functional leads |
| Data | Master and transactional test data loaded and checked against test case needs | Business partners, products CMC-ALT-100 and CMC-RTR-200, condition records, opening stock in plants 1710 and 1720 |
| Test cases | Test cases written, reviewed and approved, with expected results; assigned in the test plan | Test plan in SAP Cloud ALM with all integration cases assigned to testers |
| People and access | Testers trained and given users with the right business roles | Maria's team trained; test users with production-like roles |
| Process | Defect process, triage schedule and reporting agreed | Daily triage at 09:00 chaired by Priya |
| Exit criteria | Exit criteria for the phase agreed and published | Signed by Grace, Dan and the sales process owner |
Entry criteria by area. Write them per test phase in the test plan.
Notice the last row. One of the most important entry criteria is that the exit criteria are agreed. If the team starts testing before agreeing what done looks like, the goalposts will move once results are known, usually in whichever direction the schedule prefers.
Make entry criteria checkable
"Environment ready" is not checkable; "QAS client 100 refreshed from production copy on 3 March, build 7 imported, interface connection to the partner tested successfully" is. Every criterion should be something a person can verify with a yes or no, and someone should be named to confirm it. A short readiness checklist, completed and shared the day before the cycle starts, is enough.
- Before planning endsExit criteria agreedThe people who will sign agree what done means before any results exist
- One to two weeks beforeEnvironment and build baselineQAS client 100 refreshed from a production copy; build 7 imported
- Week beforeData, test cases and accessMaster data and condition records loaded; test cases approved; testers have their roles
- Day beforeReadiness checklist sharedEach criterion marked yes or no by the named person who confirmed it
- Morning of day oneSmoke test, then startA few logons, one sales order, one purchase order, one goods movement per plant
- Are all entry criteria met?Yes → start the phase as planned · No → go on
- Do the unmet criteria block all testing?Yes → delay the start and fix them · No → go on
- Can the unaffected tests run with useful results?Yes → start a partial cycle; record the waiver, owner and date for each unmet criterion · No → delay the start
How weak entry criteria waste cycles
A classic SAP failure pattern: integration testing starts on schedule, but half the master data is missing and two key transports are still in DEV. Testers spend the first week logging defects that are really data gaps and missing imports. Triage drowns, real defects are buried, and by the time the environment is fixed the cycle has lost a week. A one-day delay to meet entry criteria would have been cheaper.
| Start on schedule, not ready | Delay one day, then start | |
|---|---|---|
| First week | Testers log data gaps and missing transports as defects | Testers execute real test cases |
| Defect log | Noise buries the genuine defects | Defects reflect real solution problems |
| Triage team | Overloaded sorting setup issues from defects | Focused on fixes that matter |
| Business testers | Released from their day jobs to find no data or access | Arrive to a working system and keep their goodwill |
| Net schedule effect | About a week lost | One day lost |
Entry criteria also protect the people being asked to test. Business users released from their day jobs for UAT have limited time. If Maria's team arrives to find no data and no access, the program loses their goodwill as well as their hours. Treat UAT entry criteria with particular care.
What would you do?
It is the Friday before Contoso's integration cycle 1. The readiness check shows build 7 imported and test cases approved, but condition records for fleet pricing are not loaded, and testers' users lack the billing role. Grace wants to start Monday regardless. What should Priya recommend?
- Entry criteria are preconditions for starting a test phase.
- Cover environment, build baseline, data, test cases, people and access, process, and agreed exit criteria.
- Make each criterion checkable and assign someone to confirm it.
- If criteria are not met: delay, or start a partial cycle with recorded waivers.
- Weak entry criteria turn the first week of testing into data and setup triage.
Check your understanding · not graded
Lesson check
1. Which is an entry criterion rather than an exit criterion?
2. Why should exit criteria be agreed as part of entry?
3. Which entry criterion is written in a checkable way?
4. Some entry criteria are unmet but affect only one process. What is a sensible response?