Development has to include verification of the work being delivered. Selling independent QA does not mean a build arrives unchecked. The useful distinction is the scope and perspective of assurance: agreed launch checks for the build, or a broader programme examining the product and its release risks.
Included checks establish whether the agreed build works
The proposal should identify the user journeys, supported browsers and devices, accessibility and performance checks relevant to the project. Engineers review implementation and verify the agreed behaviour before handover. The evidence should state what passed, known limitations and checks that could not run.
For a business website, this could include navigation, the enquiry journey, responsive layouts, keyboard access and important loading behaviour. For an application, include the agreed roles, state transitions and integration errors. The exact checklist depends on the written scope; do not assume every possible platform or scenario is covered.
- Acceptance criteria define the expected result.
- Verification records name the tested build and important environment assumptions.
- Unresolved findings remain visible to the release owner.
Additional assurance answers different questions
| Work | Primary question | Additional scope |
|---|---|---|
| Development launch checks | Does the delivered build meet the agreed requirements? | Included verification of the scoped implementation and supported journeys |
| Independent QA | What risks or behaviours have the builders missed? | Broader exploration, regression, platform coverage, prioritised findings and release support |
| Maintained automation | Can important checks run repeatedly with useful failures? | Framework, fixtures, CI gates, reporting and ongoing suite ownership |
| OWASP assessment | Where are application and API security weaknesses? | Defined assessment surface, findings, remediation guidance and agreed re-testing |
Independent QA can help when multiple suppliers contribute, requirements are changing, or a release needs a separate risk assessment. Its value is a different testing perspective and explicit coverage, not simply repeating the development checklist with another person.
Automation is a maintained asset
A few project tests do not necessarily constitute a regression programme. A maintained suite needs isolated data, execution environments, failure triage and someone responsible when the product changes. Additional automation scope should name the protected journeys and how the team will extend and operate the suite.
Use test automation strategy to decide what is worth automating. For generated tests, the AI E2E guide explains why assertions need independent expectations.
Security assessment has an explicit surface and limit
Basic implementation review should consider permissions and data handling, but it is not a separately scoped OWASP assessment. An assessment needs authorised targets, account roles, exclusions and a reporting format. It does not become a certified penetration test or a compliance guarantee because a scanner ran.
The distinction is explained in OWASP assessment versus penetration testing. Choose the assurance your buyer, risk owner or release actually requires, rather than using the labels interchangeably.
Make the boundary reviewable before work starts
- List included launch checks and supported platforms.
- Name any independent testing, automation or security deliverables separately.
- Agree the handling of findings and who accepts remaining release risk.
- State the included support window, defect-fix scope and maintenance owner.
- Clarify access, test-data restrictions and dependencies that may prevent checks.
For example, a build can include validation of an enquiry form while additional QA investigates all supported integrations, duplicate handling and a wider browser matrix. A maintained CI suite for the same flow is another deliverable with recurring responsibility. The distinction prevents both double charging and an assumption of unlimited coverage.
Explore web development, independent QA, automation and security assessment. Describe the release and risk to agree the appropriate combination.
