- Applicationpassed
- Integrationpassed
- Infrastructurepassed
- Service Deskpassed
- Providerpassed
- Gaps between responsibilitiesowned by no one
Schematic illustration of a typical status picture. No client data.
Every status is green. But is the service really ready end to end?
Each team tests its own area and reports a pass. The gaps sit between responsibilities: handovers between systems, process steps across provider boundaries, access rights and incident routing.
Your teams run the tests. Qelivia manages the end-to-end test effort across them. Business, technology and provider teams retain responsibility for execution; Qelivia provides the overarching test management.
Cross-system test management
Your teams and providers hold the business, process and system knowledge. Qelivia does not replace it. We connect the requirements, risks, responsibilities, coverage and evidence from the tests they perform.
- Test strategy and scope across all parties
- Risk, prioritisation, coverage targets
- Allocation of test responsibility
- Traceability and auditable evidence
- Service readiness recommendation
- BusinessBusiness process, acceptance
- ApplicationApplications, releases
- IntegrationInterfaces, data flows
- InfrastructurePlatform, network, data storage
- IAMIdentities, roles, access rights
- OperationsOperational processes, monitoring
- Service DeskIncidents, requests
- ProviderExternal services, SLAs
Whether it is a major release, system migration, provider transition or service transition, once several systems and providers are involved, the deciding factor is not an individual system test but coverage across the boundaries between them.
The test levels that support a release decision
Test levels aligned with ISTQB terminology. Component testing remains with the development team; Qelivia starts at system level.
Q5 Test Lifecycle Framework
Five phases that govern every engagement, aligned with the ISTQB test process and compatible with the ISO/IEC/IEEE 29119 series. Your teams execute the tests between phases four and five.
Review
ISTQB: test analysis · establishing the test basisObjective: establish the test basis and scope: which requirements, systems and documents form the foundation, and what is explicitly out of scope.
What we do
- Review and structure the test basis, and examine it for gaps and contradictions
- Record the system landscape, the interfaces and the providers involved
- Establish who tests which part today, and define the test scope (in / out of scope)
What you receive
- Scope and test basis overview
- Map of responsibilities, with open points and testability findings
Entry and exit criteria for this phase
Entry criteria
- Engagement awarded and NDA signed
- Project and requirements documentation made available
- Business point of contact nominated
Exit criteria
- Test basis confirmed as sufficiently complete, or gaps documented
- Scope approved by the client
Assess
ISTQB: risk-based prioritisationObjective: a quantified risk profile: where the greatest release risk lies, and therefore where the test effort belongs.
What we do
- Risk model per requirement or component: likelihood × impact
- Prioritise test areas by risk
- Derive coverage targets
What you receive
- Quantified risk profile and risk heat map
- Prioritised list of test areas, with the rationale
Entry and exit criteria for this phase
Entry criteria
- Approved scope from phase 1
- Business assessment of commercial impact available
Exit criteria
- Risk assessment agreed with the client
- Prioritisation approved as the basis for the test plan
Design
ISTQB: test planning & test plan · ISO/IEC/IEEE 29119Objective: the auditable test plan: the agreed basis for how testing is carried out, with what, and how far it goes.
What we do
- Test strategy: test levels, test types, test techniques, coverage targets
- Define the entry and exit criteria for execution
- Set out the division of roles: who tests what, against which criteria
- Define test data, environments, tools, metrics and reporting
What you receive
- Auditable test plan (master test plan), including entry and exit criteria, coverage targets and test data and environment requirements
Entry and exit criteria for this phase
Entry criteria
- Confirmed risk profile and prioritisation from phase 2
Exit criteria
- Test plan signed off by the business
- Entry and exit criteria and coverage targets agreed
Enable
ISTQB: test design & test implementationObjective: your team is ready to test: every test asset is prepared, imported and available for use.
What we do
- Turn the test conditions into end-to-end scenarios that cross system boundaries
- Produce the prioritised test backlog and the traceability matrix
- Specify the test data, hand the assets over into your tool and brief the team
What you receive
- Test case and test scenario catalogue, prioritised test backlog
- Requirements traceability matrix, test data specification
- Import-ready files (Excel/CSV) or artefacts already loaded into your tool
Entry and exit criteria for this phase
Entry criteria
- Signed-off test plan from phase 3
- Access to the test management tool, if assets are to be loaded into it
Exit criteria
- Test assets handed over and available in your tool or in the Qelivia test environment we provide
- Client team briefed; execution can begin
Your team then carries out the testing in line with the test plan and records results and defects in the tool. Execution itself lies outside our engagement.
Evidence & Control
ISTQB: test monitoring & test closureObjective: the evidence-based release decision, supported by documentation that stands up in audit and review.
What we do
- Evaluate test progress, coverage, pass rate and defects from all parties against the exit criteria
- Assess the residual risk and give a recommendation on service readiness (go / go with conditions / no-go)
- Produce the management report and file the evidence in auditable form
What you receive
- Management report (test closure) with key figures, residual risks and the service readiness recommendation
- Auditable evidence and traceability documentation
Entry and exit criteria for this phase
Entry criteria
- Test execution completed by your teams and providers (in full or to an agreed milestone)
- Result and defect data available from the tool
Exit criteria
- Exit criteria evaluated and the release recommendation presented
- Evidence filed in full and in a traceable form
A release decision you can substantiate.
Evidence, not confidence.
What supports a release decision
Ultimately, someone has to be accountable for the release decision. They need a reasoned recommendation and the evidence to support it.
Images of the actual sample files from the fictitious TaskFlow 2.4 project, marked as samples within the documents. Sample project report with all files
Senior-led, from the first conversation through to the readiness recommendation.
Senior experience in international IT programmes, including service and provider transitions, cross-system test management, governance, reporting and go-live readiness.
“A release decision should rest on evidence, not confidence. Our role is to make that evidence visible and traceable.”
The person you speak to at the outset remains accountable for the engagement. No consulting pyramid and no handover to junior consultants after the contract is signed.
- Certainty
- Data rather than instinct, ahead of every release decision.
- Traceability
- Every piece of evidence auditable, in line with ISTQB terminology and ISO/IEC/IEEE 29119.
- Independence
- Neutral towards teams and providers, and no verdict written to please anyone.
- Confidentiality
- NDA up front, GDPR-compliant processing within the EU, no disclosure to third parties. Privacy
The Qelivia Audit is a defined starting point.
Assessment completed in five working days · scope agreed in advance
Based on the documentation you already have: who tests what today, where the risks lie, which paths no one tests at all. Time required from your team: two to four hours.
- Days 1–2Analysis
Review the documentation on requirements, systems and interfaces, and record responsibilities.
- Days 2–3Risk profile
Assess the risk per requirement and per path, and prioritise the test areas.
- Days 3–4Assessment
Condensed test plan, risk heat map and prioritised test backlog.
- Day 5Handover
One-page management report with the recommendation, residual risks and conditions.
The Audit fee is credited in full against a subsequent Sprint.
From there, the Sprint establishes the test-management model and Care provides ongoing test management. Scope, timeline and fee are agreed and confirmed in writing before work begins. The three engagement formats in detail
Discuss your project.
Planning a complex release, transition or provider change? Tell us where the test-management challenge lies.
Or call us on +49 175 3322868
No obligation. We usually respond within 24 hours.