Test management is the planning, estimating, monitoring and control of test activities, usually owned by a test manager. Two reference works describe how it runs: the ISTQB CTFL syllabus v4.0 with its seven test activities, and the ISO/IEC/IEEE 29119 series for processes and documentation. Banks and insurers in the DACH region carry a third obligation on top, the auditable proof that testing happened and how. This guide sorts out the process, the role, the tooling and the supervisory expectations, and points into the four detailed articles of this cluster.

TL;DR: Test management plans, monitors and controls test activities. ISTQB CTFL v4.0 splits them into seven activities from test planning to test completion, and ISO/IEC/IEEE 29119-3:2021 governs test documentation, having replaced IEEE 829. In a Capgemini vendor survey, only 8% of organizations run a fully established, KPI-driven test strategy (Capgemini World Quality Report 2025-26, 2025).

Figure 1: The seven ISTQB CTFL v4.0.1 test activities run iteratively and in parallel, not as a waterfall.

What is test management, and who owns it?

Test management is the discipline that plans, estimates, monitors and controls test activities. The ISTQB Glossary defines it as “the planning, estimating, monitoring and control of test activities, typically carried out by a test manager” (ISTQB Glossary). Its subject matter is scope, resources, risk, criteria and progress.

The role itself has a matching definition. A test manager is “the person responsible for project management of testing activities and resources, and evaluation of a test object”. Evaluating the test object sits on equal footing with running the project, and that is where the release recommendation comes from.

Day to day, the role owns six things:

• Scope, test levels and test types for the initiative

• Risk assessment and the prioritisation derived from it

• Effort, schedule, staffing and test environments

• Entry and exit criteria, often written as quality gates

• The reporting line to project leadership, the business and internal audit

• The recommendation to release or to postpone

For the vocabulary underneath all of this, see our overview of software testing fundamentals.

How does the ISTQB test management process work?

The ISTQB Certified Tester Foundation Level syllabus describes seven test activities in section 1.4.1, and Chapter 5, “Managing the Test Activities”, covers how they are steered. The current reference is version 4.0.1, dated 15 September 2024 (ISTQB CTFL Syllabus v4.0.1, 2024).

1. Test planning defines the test objectives and selects an approach that reaches them within the given constraints.

2. Test monitoring and test control: monitoring checks all test activities continuously against the plan, control takes the actions needed to meet the objectives.

3. Test analysis answers the syllabus question “what to test?” in terms of measurable coverage criteria.

4. Test design answers “how to test?” and produces test cases, test data and test procedures.

5. Test implementation assembles what execution needs: scripts, data, environments, sequence.

6. Test execution runs the tests according to the execution schedule (test runs) and records the results.

7. Test completion happens at milestones such as the end of a test level, an iteration, a project or a release.

These seven are explicitly not a fixed sequence. The syllabus says so itself: “Although many of these activities may appear to follow a logical sequence, they are often implemented iteratively or in parallel.” Nearly every guide online still draws them as a waterfall pipeline. Test monitoring and test control run for the whole engagement, and in iterative delivery, analysis, design, implementation and execution repeat every sprint.

Two points of precision, since both cause real mistakes. First, the second activity has been called “test monitoring and test control” since v4.0; the shorter name from the previous syllabus was retired in that rename. Second, many summaries and AI answers still quote the 2018 syllabus in version 3.1.1. At Advanced Level, CTAL-TM v3.0, released on 30 May 2024, replaces the 2012 syllabus; English exams on the old version were retired on 30 May 2025 (ISTQB, 2024).

What the planning activity looks like as a document is covered in our article on the test plan and its structure.

Which standards govern test management and test documentation?

The governing series is ISO/IEC/IEEE 29119, and IEEE 829 has been superseded since 2013. Part 2 describes test processes that “can be used to govern, manage and implement software testing for any organization, project or testing activity”, and names test managers explicitly among its intended readers (ISO, 2021).

Figure 2: The parts of the ISO/IEC/IEEE 29119 series with their current editions.

IEEE 829 defined the classic test documents up to its 2008 edition, including the test summary report. It was superseded in 2013 by ISO/IEC/IEEE 29119-1, -2 and -3 (IEEE SA). Several well-ranking guides still present IEEE 829 as the live basis for test documentation. Anyone defending a documentation structure to an auditor should cite 29119-3:2021.

What is proven about the 1:10:100 defect cost rule?

The 1:10:100 rule on defect cost has no empirical backing. It traces to Barry Boehm's work from 1976 and 1981 and to a 1981 IBM Systems Sciences Institute training deck that was never published as a study. The multiplier still shows up in test strategies and business cases everywhere.

The strongest counter-evidence comes from Menzies, Nichols, Shull and Layman. Their study of 171 projects from 2006 to 2014 reports: “We found no evidence for the delayed issue effect; i.e. the effort to resolve issues in a later phase was not consistently or substantially greater than when issues were resolved soon after their introduction” (arXiv:1609.04886, Empirical Software Engineering).

The direction still holds, since defects found early are on average cheaper to fix. The multiplier does not hold. For planning purposes: justify test effort by risk, criticality and regulatory duty, and drop the factor that any auditor or CFO can dismantle in two minutes.

For scale, the CISQ report is the better anchor: USD 2.41 trillion in poor software quality costs in the US, of which roughly USD 1.52 trillion is technical debt (CISQ, 2022). Cite it with both caveats: sponsored by Synopsys and Undo, US only.

How do you run test management in Jira with Xray?

Xray is a Jira app that stores test cases, test executions and test runs as native Jira issue types, so requirement, test, execution and defect live in one backlog. Teams that already keep requirements in Jira avoid synchronising two systems.

The data model has few building blocks: Test, Precondition, Test Set, Test Plan, Test Execution and Test Run. A Test Run is the association between a Test Execution and a single Test, and that is the level where defect links and execution logs attach.

Automated results arrive through the REST API in formats such as JUnit XML, TestNG XML, Cucumber JSON or Xray's own JSON. The Requirement Traceability Report then shows requirements across tests, test runs and defects.

One point vendor material rarely states: Xray does not execute tests. It receives results and maps them to requirements. Execution belongs to a framework or an automation platform, and the mapping normally runs through the test key referenced in the automation code.

Setup, the issue-type glossary and the import endpoints are covered in the article on test management in Jira with Xray.

How does a traceability matrix connect requirement, test case and defect?

A traceability matrix is a report that links every requirement to the test cases, test runs and defects covering it. For an auditor it answers two questions: is every requirement tested, and what is the status of the open defects.

Three directions matter. Forward tracing runs from requirement to design, code and test. Backward tracing runs from an artifact back to the requirement that caused it. Bidirectional traceability demands both at once and is the norm in safety-critical domains.

No standards body publishes a mandatory column list for a traceability matrix. A small core has settled in practice: requirement ID, requirement description, test case ID, test case status, defect ID and coverage status. Which columns get added depends on the domain and the purpose of the audit.

The expensive mistake is the spreadsheet. A hand-maintained matrix is out of date from the first change request onward, and nobody notices until someone audits it. Tools such as Xray, Azure DevOps and Polarion build the view at query time from the linked items, which makes the matrix a report rather than a document someone reconstructs afterwards.

What that means in a regulated setting is covered in our article on testing in regulated industries; the dedicated piece on the requirements traceability matrix walks through the column models and worked examples.

Which test management tool fits a regulated enterprise?

A test management tool stores test cases, plans test cycles and reports results; a test automation tool executes tests. The two categories get confused constantly, and the confusion produces RFPs that list Selenium and TestRail side by side.

Figure 3: A test management tool and test automation are two layers, connected by an import format.

The market splits into four groups: Jira-native apps such as Xray and Zephyr, standalone SaaS tools such as TestRail, PractiTest and Testmo, enterprise ALM platforms such as qTest and Polarion, and open-source systems such as TestLink and Kiwi TCMS.

For a Swiss or German financial services buyer, five criteria usually decide the shortlist, in this order:

• Data residency: is there an EU or Swiss region, and can you select it

• Deployment model: SaaS, dedicated tenant or on-premises

• Auditability: change log, role model, documented approvals

• Import formats for automated results, in practice mostly JUnit XML

• Connection to the existing requirements and ticketing system

Data residency alone knocks out half the candidates in round one of a banking evaluation, before any feature comparison starts. Price lists are the least reliable data in this market, since several vendors quote on request and reseller figures circulate that nobody can verify.

Deployment models, regions and the prices we could verify are compared tool by tool in test management tools.

What belongs in a test report?

A test report answers three questions: what was tested, what came out, and what residual risk remains. ISTQB separates two types, the test progress report during execution and the test completion report at the end of a test level, cycle or iteration.

ISO/IEC/IEEE 29119-3:2021 describes the matching document types, including test progress and test completion reports, and marks each information element as mandatory, recommended or possible. That is the structure an auditor expects, and it is leaner than the reports many teams impose on themselves.

Useful metrics are requirement coverage, defect density, defect detection percentage, open defects by severity, and the share of unstable tests. A pass rate without a flaky rate is the most common way a test report lies by accident: a green run after three retries looks exactly like a green run on the first attempt.

Treat code coverage as a quality proxy with care. It shows which code ran, not how well it was checked. Our article on test coverage goes through the evidence.

Which metrics earn their place, how Allure reports are built and what CI systems produce on their own is covered in detail in test reporting.

What do supervisors and auditors in DACH expect?

Financial regulation prescribes no specific tool, it prescribes a demonstrable testing programme. DORA, Regulation (EU) 2022/2554, requires financial entities other than microenterprises to “establish, maintain and review a sound and comprehensive digital operational resilience testing programme” as an integral part of the ICT risk-management framework referred to in Article 6 (EUR-Lex, Article 24(1)). The regulation applies from 17 January 2025.

Figure 4: Test strategy maturity according to the Capgemini World Quality Report 2025-26.

Article 24(6) gets more concrete: financial entities other than microenterprises must ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. For those entities, the ISTQB test completion activity acquires a fixed cadence and a named audience.

In Switzerland, the reference point is FINMA Circular 2023/1 on operational risks and resilience at banks. It was published on 7 December 2022, entered into force on 1 January 2024 and replaced Circular 2008/21 (FINMA). It addresses ICT risk management at banks in general terms and prescribes no report template for software testing.

In practice both regimes agree on one expectation: retained, dated, traceable test evidence with a clear link to requirements and approvals. Assembling that evidence only after an audit has been scheduled costs weeks and leaves the gaps for the auditor to find.

How do automated test results reach the management layer?

Through an import interface. Automation runs the tests in the pipeline, produces a machine-readable result format and writes it into the management layer, where it attaches to a requirement and an approval. This seam is under-described in most test strategies and is the most common break point in audits.

Autemos sits on the execution side of that seam. The platform runs web, mobile, API and desktop tests, produces Allure reports and reports results into Jira/Xray and into pipelines such as GitLab, GitHub Actions and Jenkins. Autemos is not a test management tool, and that is the honest boundary: test case libraries, cycle planning and approval workflows stay in the management layer. The test workflows overview shows what the execution side looks like.

The Capgemini World Quality Report 2025-26, a vendor survey, puts 47% of organizations on the way to an enterprise-wide test automation strategy, with only 8% at a fully established, KPI-driven strategy and 60% reporting trouble with secure test data at scale (Capgemini, 2025). The numbers come from a vendor with its own testing business and should be read that way. How results feed quality gates continuously is covered in our article on continuous testing.

Which article answers which question?

The four spokes of this cluster each cover one part of the management layer:

Frequently asked questions

What is the difference between test management and test automation?

Test management plans, monitors and controls test activities and documents results; test automation executes test cases technically. A test management tool stores cases and cycles, an automation platform drives browsers, API calls or mobile devices. Import formats such as JUnit XML connect the two layers.

Which standard governs test documentation?

ISO/IEC/IEEE 29119-3 in its 2021 edition. It supersedes the 2013 edition, which had already replaced IEEE 829-2008 (IEEE SA). Naming IEEE 829 today as the basis of a documentation structure means citing a withdrawn standard.

How many test activities does ISTQB define?

Seven: test planning, test monitoring and test control, test analysis, test design, test implementation, test execution and test completion. The list comes from section 1.4.1 of the Foundation Level syllabus v4.0.1, dated 15 September 2024 (ISTQB, 2024). Sources still quoting version 3.1.1 from 2018 are out of date.

Does DORA require a test management tool?

No. DORA Article 24(1) requires an established, maintained and reviewed digital operational resilience testing programme inside ICT risk management, naming no product. Article 24(6) adds an at-least-yearly test cadence for systems supporting critical or important functions. Scope, execution and follow-up must be auditable, whichever tool produces the evidence.

Does every project need a dedicated test manager?

No, the tasks need an owner. In small teams the product owner or a senior tester picks them up. Regulated initiatives normally name a person, since the release recommendation and the reporting line have to sit with someone who can answer to internal audit.

Conclusion

Test management comes down to three checkable pieces: the seven activities from ISTQB CTFL v4.0, the documentation structure from ISO/IEC/IEEE 29119-3:2021, and the evidence you hand to supervisors and internal audit. The rest is tool choice. Removing numbers like the 1:10:100 rule from your test strategy and arguing from risk and regulatory duty instead will serve you better in an audit conversation.

The seam between execution and the management layer decides how much manual work remains at the end. Automated runs that write their own results into Jira/Xray remove exactly the clerical work that otherwise costs weeks before an audit. To see what that connection would look like in your environment, talk to our team.