From a pile of requirements to an evidence-based release decision.

A SaaS team is approaching release 2.4: a new role model, Stripe payments, reporting. Five working days later, opinions have been replaced by a quantified risk profile. This is what a Qelivia Audit looks like from the inside.

Sector · SaaS project managementEngagement · Audit, then SprintAudit · 5 working days12 requirements22 test cases

Fictitious sample project: the way of working, artefacts and deliverables reflect the structure of a real Qelivia engagement. It shows one use case, a software release; the same approach applies to cross-system undertakings such as service transitions and multi-provider environments.

The starting position

The TaskFlow team releases every two weeks, faster than its own test structure can keep up with. Release 2.4 brings three high-risk blocks of functionality: a new role and permissions model, payment integration via Stripe, and a reporting module. Testing has so far relied on the developers' experience, and no one can show which risks are actually covered. Meanwhile, the largest client announces a supplier audit.

There is no budget for a permanent test-management role, and no time to recruit one before the release. Qelivia was asked whether a sound basis for the go-live decision could be established within a week.

The approach: five days, four steps

Days 1–2

Structured review of the existing documentation: 12 requirements extracted, organised and checked for gaps, with minimal demand on the client's calendar.

Days 2–3

Risk assessment for each requirement (likelihood × impact). Result: four high risks (payment journey, dunning, role model, SSO) determine the test depth.

Days 3–4

Condensed test plan structured to the ISTQB test process, a risk heat map and a prioritised test backlog: where testing is needed, in what order, and who is responsible for it.

Day 5

Handover: a one-page management report with a recommendation, residual risks and clear conditions. That concludes the Audit; the basis for the decision is in place.

The team then commissioned the Sprint, which produced the full test plan, the requirements traceability matrix and a catalogue of 22 test cases written jointly to the Qelivia authoring standard. Test execution was carried out by the team itself in the Qelivia Test Runner. The artefacts below come from both phases.

By day five, the decision was no longer based on opinion: the team had a quantified risk profile, a recommendation and a clear list of actions required before go-live.

The results in figures

12/12requirements with demonstrable test coverage

4high risks identified in the Audit, each with a blocker rule

22test cases including negative paths, co-produced in the Sprint

1 pagemanagement report for the release decision

The artefacts in full

Every deliverable from this sample project can be downloaded, exactly as a real client receives it.

Management report from the sample project: recommendation, test progress, risk coverage and open defects on a single page — **Management report · PDF** The single page that carries the release recommendation: the recommendation and its conditions, test progress, risk coverage and open defects. Open the report

Page from the sample test plan: introduction, objectives, test object and scope — **Test plan · Word** Sets out before the first test what the outcome will be measured against: test strategy, scope, entry and exit criteria in line with the ISTQB test process. Open the test plan

Requirements traceability matrix from the sample workbook: twelve requirements with risk, scenario, test cases and coverage — **Test workbook · Excel** Requirements traceability matrix, risk heat map, test backlog, scenarios and test cases in a single file. It answers the first question in any audit: how do you know that? Open the workbook

See what a Qelivia engagement can deliver.

The TaskFlow case uses a fictitious sample project to show how requirements, risks and test results become a reliable basis for a release decision.

Explore Test Management as a Service →