Problem
In many programmes, testing is a phase at the end. By the time testers see the software, the deadline is close, and anything they find is expensive to fix. Effort goes on checking everything a little, instead of checking the risky parts well.
Outcomes
- A test approach matched to the real risks of the service.
- Testing that starts in the first sprint, alongside the build.
- A clear split between automated and manual testing.
- Quality visible to sponsors through agreed measures.
- An independent view of delivery when the sponsor needs one.
Scope
In scope
- Risk assessment for the service and its users.
- Test strategy and approach, by level and type of testing.
- Automation strategy.
- Quality measures and reporting.
- Test environment and data planning.
Not included
- Running all the testing itself. That sits with the other capabilities in this service, or with your own team.
Independent delivery assurance
Sponsors and boards sometimes need a view of a programme from outside the delivery team. We review the plan, the evidence and the risks, and report plainly on whether the programme is likely to deliver what it promised, and what would change that.
- Review of plans, progress evidence and risk logs.
- Interviews with the delivery team and stakeholders.
- An assurance report with findings and recommendations.
Approach
Discovery
We agree what could go wrong and how much it would matter. We then choose what to test at each level and what to automate.
Delivery Planning
We plan test environments with safe test data, and agree the quality measures sponsors will see.
Build and Test
We produce the strategy, the automation approach and the reporting template, and check that every major risk has a matching test approach. Where you want an independent view, we review the plan, the evidence and the risks, and report plainly.
Operational Readiness, Hypercare and Closure
We hand the strategy over to your team, and agree how quality will be reported and reviewed as the service changes. We then close the work with your sign-off.
Deliverables
Technologies
Controls
Frequently Asked Questions
When should testing start?
In the first sprint. Testing alongside the build finds problems while they are cheap to fix.
Should we automate all our testing?
No. Automate the checks you repeat on every release, and keep people for exploratory testing and for judging what users experience.
What is independent delivery assurance?
A review by someone outside the delivery team of whether a programme is likely to deliver what it promised, based on the evidence.
Can you work with our in-house testers?
Yes. The strategy is often delivered by your own team, with our support where it is needed.
Testing left until the end?
A Technical Audit reviews your delivery, testing approach and release risks in 10 to 15 working days and gives you a prioritised remediation plan.