Fixed scope · Three days
A fixed three-day engagement that maps your test suite to the business journeys it is supposed to protect. Independent and risk-ranked, delivered without access to your systems.
See how the three days runDuration
Three days, fixed scope
Fee
Fixed, agreed before you commit
Access
None to your systems
Definition
A test coverage audit, also called a coverage assessment, is an independent review of whether a software test suite protects the business journeys that matter: the flows that move money, support regulatory reporting, or expose data. It measures coverage against business risk and produces evidence a risk function can use. Most coverage numbers are code percentages. A suite can score 80% and still leave every Tier 1 journey unverified. The audit replaces that percentage with a journey-by-journey map.
We rank every critical path, in the interface or behind it, by what a failure would cost the business. Coverage is judged against this map.
Tier 1
Money movement, transaction execution, credit and lending decisions, regulatory reporting, authentication and step-up verification. A failure means direct financial loss or a regulatory breach.
Tier 2
Dashboards and balances, statements and history, notifications, onboarding. A failure is silent data corruption or a collapse in client trust, the tier most easily passed off as covered.
Tier 3
Internal operations views, search, third-party feed integrations. A failure causes operational friction.
The audit applies the journey tiers and scoring model of The Certance Standard, the quality engineering standard Certance publishes for teams where AI writes the code and runs in the product. Each gap is ranked by its business consequence multiplied by how long it would go undetected. Read the Standard
Deliverable
A business-readable report, written for a Head of Risk to act on.
A journey coverage table mapped to Tier 1, 2, and 3 business risk.
The top five gaps ranked by consequence.
An evidence-posture check on whether your test records are retained, traceable to a release, and durable enough for a supervisory look-back.
The assessment is independent, so your risk function can weigh it as a third-party view. Findings are never conditioned on buying anything else: if we recommend closing gaps, the recommendation stands whether or not you engage us to do it, and we hold no referral or revenue-share arrangement with any tool vendor.
Where it matters, the audit goes further: an eight-dimension read of how your team manages quality, with a regulatory overlay for DORA and FCA-regulated environments.
It is scored across Change Capability, Test and CI Health, Knowledge Architecture, Engineering Culture, Dependency Health and Learning Culture, plus Regulatory Alignment and Audit Evidence Posture for regulated teams.
Sample report
The exact artefact a client receives, built on synthetic data: a journey-by-journey map of coverage and where the gaps are.
Process
A fixed, three-day engagement, with scope and fee agreed before you start.
Fixed fee, agreed before you commit. We set the delivery date with you in the statement of work and hold it: the audit is three days of focused work, scheduled to a date that suits both sides, and the date is a commitment.
We interview an engineering lead and someone from product, the people who know which journeys carry the money and the risk, and inventory every test you run, working from an artefact bundle your engineer exports and reviews. Your QA lead joins where useful; the journey map comes from the people who own the business outcomes as well as from the test suite. The audit never touches your systems.
We map your business-critical journeys and score coverage against Tier 1, 2, and 3 risk. Before the day closes we send you a short written checkpoint: how many of your critical journeys look unprotected, and where the single biggest exposure is forming. Findings are still provisional at that point, so nothing in the final report arrives as a surprise.
We walk your engineering team and risk lead through the findings in a one-hour session: the coverage map, the single biggest exposure, and the fixes in priority order. You receive the report as a draft at that walkthrough, then have one business day to correct any fact, a test that does exist or a journey named wrong, before the final version is issued. The judgements are ours and they stand; the facts they rest on are yours to check.
It runs on test artefacts your own engineer exports and reviews before anything leaves your environment: test names and assertions, pipeline configuration, recent run summaries, coverage output. No account provisioning, no production data, no customer data. For most vendor-risk frameworks this is the lowest access tier a supplier can occupy.
If the audit leads to implementation work, access for that is scoped separately under your own onboarding rules, once the audit is delivered.
Regulation
The EU Digital Operational Resilience Act (DORA) has applied since 17 January 2025, and 2026 is the first full year of supervision. Supervisors have moved from asking firms to adopt DORA to checking that they follow it. In 2025, EU financial entities reported 3,383 major ICT incidents, with system failures the single largest category, ahead of external attacks.
We speak the language your risk function already uses: DORA Article 24(6) testing evidence, FCA Important Business Services, test data exposure, and release records that are retained and traceable. Findings arrive as an independent view of regulatory risk the business can act on.
FAQ
Code coverage counts executed lines. The Coverage & Evidence Audit measures whether business-critical journeys are verified through to the business outcome, ranked by what a failure costs, and whether you could evidence that verification to a supervisor. A suite can have high code coverage and zero verified Tier 1 journeys.
No. It runs on an artefact bundle your own engineer exports and reviews before anything leaves your environment. No account provisioning, no production or customer data.
Article 25(1) of the Digital Operational Resilience Act (DORA) lists gap analyses among the methods a firm's testing programme may use, and Article 24(6) sets yearly testing of the systems that support critical or important functions. The audit produces a gap analysis of your test coverage and its evidence. Your compliance function decides what weight it carries in your programme. Read: test evidence under DORA
Three days, fixed scope. Your team's involvement is roughly two hours of interviews and one engineer exporting the artefact bundle.
The report is yours: your team can close the gaps, or Certance can scope implementation work separately under your own onboarding rules. Nothing in the audit locks you in. The audit is the first step in our quality engineering consultancy work.
Ivan Stepantsov, founder of Certance Advisory and a Chapter Lead at a global investment bank, with 13 years in regulated software delivery, building and leading test automation across financial services, life sciences and defence systems.
On a date we agree with you in the statement of work, before the engagement begins. The audit is three days of focused work; we schedule those days and set the delivery date around both sides' availability, then hold the date we agreed. You also see the shape of the findings in a written checkpoint at the end of day two, before the report is written.
You have one business day after the walkthrough to correct any fact: a test that does exist, or a journey we named wrong. The judgements, the tiers and the risk scores, are ours and they stand; the facts they rest on are yours to check. Corrections are made before the final report is issued.
Subscribe to Certance research and the AI Token Efficiency Guide lands in your inbox. The audit is here whenever you are ready: book a scoping call from the menu.