A testing phase is not a spare period added after development. It is a planned sequence of checks, fixes and retests that provides evidence for the decision to launch or accept a release. The plan should be agreed early enough to influence requirements, environments, data and delivery dates.
The objective is not to prove that the application has no defects. It is to verify the agreed behaviour, expose material risk and record what the business is accepting.
Define the release and the risk
State exactly what is being tested: the release version, included features, integrations, environments and excluded items. Identify the processes whose failure would have the greatest effect on customers, operations, data or revenue. Testing effort should reflect that risk rather than giving every screen equal attention.
A critical approval, payment or data-import workflow needs more evidence than a low-impact content change.
Map requirements to test coverage
Every important requirement and acceptance criterion should have a corresponding test or review. Create traceability before the phase begins so omissions are visible.
| Source | Testing question |
|---|---|
| Business process | Can the user complete the end-to-end workflow, including handoffs and exceptions? |
| Functional requirement | Does the system perform the agreed action and record the expected result? |
| Permission rule | Can authorised roles act, and are unauthorised roles blocked? |
| Non-functional requirement | Does the release meet the agreed performance, recovery, accessibility or audit condition? |
| Integration requirement | Is the correct data exchanged, reconciled and recovered after failure? |
| Acceptance criterion | Is there evidence for a consistent pass or fail decision? |
Separate the testing layers
Plan who is responsible for each type of evidence. A typical sequence includes:
- developer checks during implementation;
- quality-assurance testing against the specification;
- integration and end-to-end testing;
- specialist checks for performance, security, accessibility or recovery where required;
- regression testing of existing critical functions;
- user acceptance testing by authorised business users.
Do not send an unstable build to UAT and expect business users to perform the supplier’s basic quality control.
Prepare an appropriate environment
The test environment should represent production closely enough for the planned evidence to be meaningful. Document differences in configuration, services, data volume and integrations. A test against a developer’s local machine does not establish that deployment, permissions or external connections will work in the live environment.
Control access, changes and release versions. Participants need to know which build they tested and whether it changed during the session.
Create representative test data
Prepare data for different roles, statuses, volumes, boundary values and exception cases. Protect personal and commercially sensitive information. If live data is considered necessary, obtain appropriate review and apply controls rather than copying a production database by convenience.
Test data should include:
- valid ordinary cases;
- missing and invalid values;
- duplicates;
- minimum, maximum and threshold values;
- records owned by different teams or regions;
- historical and future dates;
- failed and partially completed processes.
Write scenarios around real journeys
A scenario should follow the work from trigger to outcome. For a document workflow, that may include upload, validation, review, rejection, resubmission, approval, notification and audit evidence.
Include interruptions and recovery: refreshing the page, leaving and returning, a service timeout, another user changing the record or a scheduled process running late.
Plan the schedule around fixes and retesting
Running the tests is only part of the phase. Allocate time for:
- environment and data preparation;
- execution and evidence capture;
- defect triage;
- supplier investigation and correction;
- deployment of fixes;
- retesting the defect;
- regression testing affected areas;
- acceptance review and decision.
A launch date that leaves no room for correction is a deadline for discovering defects, not a testing plan.
Define defect severity and ownership
Agree a small severity scale based on business impact. Record each issue with the affected scenario, evidence, environment, owner and status. Separate defects from requirement gaps and enhancement requests.
| Finding | Decision needed |
|---|---|
| Blocking defect | Fix before launch or formally change the launch decision. |
| Material defect with workaround | Assess operational burden, risk and correction date. |
| Minor defect | Decide whether to fix now or place in the controlled backlog. |
| Requirement gap | Agree scope, impact and revised acceptance criteria. |
| Enhancement | Prioritise separately from acceptance unless genuinely essential. |
Set entry and exit criteria
Entry criteria prevent testing from starting before the release, data and people are ready. Exit criteria prevent the phase from ending merely because time has run out.
Exit criteria may require:
- all critical requirements covered;
- blocking defects resolved and retested;
- remaining findings documented and accepted by the authorised owner;
- critical regression scenarios passed;
- specialist evidence completed where required;
- UAT and operational readiness decisions recorded;
- known limitations and post-launch actions assigned.
Include deployment and rollback evidence
A release can pass functional tests and still fail during deployment. Test the installation or deployment process, configuration, data migration and recovery steps. Confirm what happens if the release must be paused or rolled back.
For a new system with no previous live version, the fallback may be delaying launch or returning temporarily to the existing process. That decision should be prepared before the launch window.
Retain a reusable regression set
The testing phase should leave behind a small, maintained set of critical scenarios for future releases. Focus on core journeys, permissions, calculations, integrations and failure handling. Decide which tests are suitable for automation and which still require human judgement.
Questions to put to a supplier
- Which tests are included in the estimate, and which require separate specialists?
- How are requirements traced to test results?
- How close is the test environment to production, and what differences remain?
- Who prepares and protects the test data?
- How are defects, requirement gaps and enhancements distinguished?
- How much time is reserved for fixes and regression testing?
- Which test evidence and reusable scenarios will be handed over?
Practical next step
Build a coverage table for the ten highest-risk requirements: the test type, environment, data, owner, evidence and retest rule. This will expose missing preparation more reliably than choosing an arbitrary number of “testing days”.