ISO/IEC/IEEE 29119: ISO/IEC/IEEE 29119 – Tutorial (about 60 minutes)

ISO/IEC/IEEE 29119 is an international family of software testing standards. It gives organisations a shared vocabulary, a generic set of test processes, templates for test documentation, a catalogue of test design techniques and an approach to keyword-driven test automation. Test managers, testers, developers, quality leads, auditors and buyers of software use it to plan, run and judge testing in a consistent and risk-based way. After this tutorial you will be able to explain what each part of the series covers, apply its process model and design techniques to a real product, and decide what a sensible conformance claim would look like for your own organisation.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ISO/IEC/IEEE 29119 is not a single document but a series of separately published parts, developed by ISO/IEC JTC 1/SC 7 Working Group 26 (Software Testing) together with the IEEE Computer Society. The current core parts are Part 1 General concepts (second edition, 2022), Part 2 Test processes (second edition, 2021), Part 3 Test documentation (second edition, 2021), Part 4 Test techniques (second edition, 2021) and Part 5 Keyword-driven testing (second edition, published December 2024). Three guidance documents, published as Technical Reports (TR), complete the family: ISO/IEC TR 29119-6:2021 on agile projects, ISO/IEC TR 29119-11:2020 on testing AI-based systems and ISO/IEC TR 29119-13:2022 on biometric systems. All of these are published and current; none of the core parts is withdrawn or replaced by a newer edition. The 2013 and 2015 first editions of Parts 1 to 4 and the 2016 first edition of Part 5 have been superseded. Working Group 26 continues to work on further parts and revisions, so check the ISO catalogue for the status of any part before citing it in a contract. This tutorial teaches the current editions listed above. Verified 2026-10-29 against the IEEE Standards Association record for Part 1 and the working group's information site.

Who it is for: testers and test leads who want to understand the standard their contracts or auditors mention, developers who write automated tests, quality and process people who define how an organisation tests, project managers who must approve test plans, and buyers or regulators who need to judge whether a supplier's testing is adequate.

Prerequisites: none. Some experience of building or using software helps, because every concept is linked to everyday testing work such as writing test cases, reporting defects and deciding when to stop testing.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why the 29119 series was created, what it replaced and why parts of the testing community criticised it.
You will be able to use the core vocabulary correctly, including test item, test basis, test model, test coverage item, test case and test procedure.
You will be able to describe the parts of the series and the three layers of the Part 2 test process model.
You will be able to apply the test design and implementation process with techniques such as equivalence partitioning, boundary value analysis and state transition testing.
You will be able to explain what full and tailored conformance mean and how test process capability can be assessed.
You will be able to position 29119 next to related standards and models such as ISO/IEC/IEEE 12207, ISO/IEC 20246, ISO/IEC 25010 and TMMi.

Lesson 1 – Origins, purpose and scope

Why a testing standard was needed

Testing is one of the most expensive activities in software development, yet for a long time teams around the world used different words for the same things and the same words for different things. One company's "test script" was another's "test procedure"; a "test plan" might be a two-line email or a two-hundred-page document. When a bank bought software from a supplier, or a regulator reviewed a medical device, there was no common reference that said what reasonable testing should include. Several older documents tried to fill the gap. IEEE 829 described test documentation, IEEE 1008 covered unit testing, and the British Standards Institution published BS 7925-1 (a testing vocabulary) and BS 7925-2 (component testing techniques). Each was useful, but they covered different pieces, came from different bodies and had aged.

In 2007 ISO and IEC started work on a single international family of testing standards. Because no existing working group had enough testing expertise, a new one was formed: Working Group 26 of subcommittee SC 7, which deals with software and systems engineering. IEEE joined as a partner so that the result would supersede its own older testing standards rather than compete with them. That is why the name carries three acronyms: ISO/IEC/IEEE.

What the series tries to achieve

The aim is not to dictate one "correct" way of testing. The aim is to provide agreed definitions, a generic process framework that can be adapted to any lifecycle, documentation templates whose content can be packaged in any format, and well-defined techniques with measurable coverage. Running through all of this is one key idea: risk-based testing. Because exhaustive testing of any realistic system is impossible, testing must be prioritised. The series asks you to identify what could go wrong, how likely and how harmful it would be, and to focus test effort accordingly.

Scope

The series applies to any organisation, any project or product, and any software development lifecycle, from a traditional sequential project to a team releasing several times a day. It covers functional and non-functional testing, manual and automated testing, and scripted and unscripted (for example exploratory) testing. Its processes concentrate on dynamic testing, where the software is executed. Static testing, such as reviews and static analysis, is recognised as part of testing in Part 1, but the working group did not reach consensus on a detailed static test process; reviews are covered by a separate standard, ISO/IEC 20246.

Editions and evolution

Parts 1, 2 and 3 were first published in 2013, Part 4 in 2015 and Part 5 in 2016. Feedback from users led to second editions of Parts 2, 3 and 4 in 2021 and of Part 1 in 2022. The most important change was in how test cases are designed: the first editions relied on "test conditions", a concept many readers found confusing, while the second editions use "test models" instead (explained in Lesson 2). Part 5 received its second edition at the end of 2024. Over the same period Technical Reports were added for agile projects, AI-based systems and biometric systems, showing how the core parts are applied in those contexts.

The controversy

A fair introduction must mention that the series was not welcomed by everyone. In 2014 a group of testers, supported by organisations such as the Association for Software Testing and the International Society for Software Testing, started a "Stop 29119" campaign. Their concerns were that the standard lacked real consensus among practising testers, that it encouraged heavy documentation instead of thoughtful testing, that it sidelined context-driven approaches, and that it might be used by buyers and regulators to force a single way of working. The convenor of Working Group 26 responded that the series is tailorable, supports exploratory and agile testing, and does not mandate any document format. The debate is still useful today: it reminds you to use the standard as a thinking framework and a common language, not as a checklist that replaces judgement.

Figure 1 – How the parts of the 29119 family build on each other: concepts underpin processes, processes produce documentation and use techniques, and Technical Reports apply the whole set to specific contexts.

Lesson 2 – Key concepts and vocabulary

Much of the value of 29119 comes from precise words. When a test manager in Pune and a supplier in Berlin both say "test procedure", they should mean the same thing. The definitions below are paraphrased; the standard's own wording is longer and more formal. The series also points readers to ISO/IEC/IEEE 24765, the general software engineering vocabulary.

Testing – a set of activities carried out to discover information about a test item, for example whether it meets its requirements, where it fails, or how good its quality is. Testing provides information; it does not by itself improve quality.
Static testing – evaluating a work product without running it, for example by review or by a static analysis tool.
Dynamic testing – evaluating a test item by executing it and observing its behaviour.
Test item – the work product being tested (also called test object): a component, a whole system, a requirements document or a user guide.
Test basis – the information from which tests are designed, such as a requirements specification, user stories with acceptance criteria, a design, or even an undocumented shared understanding of how the product should behave.
Test model – a representation of the test item that lets the tester focus on particular characteristics, such as a set of equivalence partitions, a state transition diagram, a decision table or a control flow graph. It is built from the test basis and shaped by the coverage that is required.
Test coverage item – a measurable attribute derived from the test model that a test should exercise, for example one equivalence partition, one boundary value, one state transition or one branch in the code.
Test coverage – the percentage of the chosen test coverage items that executed tests have exercised. Coverage is always relative to a specific model and technique.
Test case – a set of preconditions, inputs and expected results designed to drive the test item towards a test objective. It is the smallest unit of test specification.
Test procedure – an ordered sequence of test cases plus any set-up and wrap-up actions needed to run them; when documented it is often called a test script.
Test oracle – the source used to decide the expected result and whether an actual result is correct: a specification, a previous version of the system, a calculation or an expert.
Test level – a stage of testing with its own objectives and risks, such as component, integration, system, system integration and acceptance testing.
Test type – testing focused on a particular quality characteristic, such as performance, security, usability or functional suitability.
Test design technique – a defined way to create a test model, identify coverage items and derive test cases. Practices such as exploratory testing or model-based testing are not techniques in this sense; they use techniques.
Test policy – a short executive-level statement of why the organisation tests and what testing should achieve, without describing how.
Organizational test practices – the organisation-wide description of how testing is normally done (in the first edition this was called the organizational test strategy).
Test plan – the description of test objectives for a given item or project and the means and schedule for achieving them; it contains the test strategy chosen for that context.
Incident – any unexpected event or result that needs investigation. An incident report records it; after analysis it may turn out to be a defect, a test error or a misunderstanding.
Regression testing and retesting – retesting (confirmation testing) checks that a fix really removed a fault; regression testing checks that the change did not break anything that previously worked.

Why "test model" replaced "test condition"

In the first editions, testers were asked to derive "test conditions" (testable aspects of the item) and then coverage items. Many users struggled to tell a condition from a coverage item, so the second editions replaced the step with the more concrete idea of building a model. If you are testing a field that accepts ages 18 to 65, the model is the set of partitions "below 18", "18 to 65" and "above 65" plus their boundaries. Each partition and boundary then becomes a coverage item, and each coverage item is exercised by at least one test case. The word "test condition" still appears in the standards, but only to explain that the series no longer uses it for design.

Risk at the centre

The series distinguishes product risks (the product could be faulty in some function or quality attribute) from project risks (the testing work itself could fail, for example through missing staff, late environments or changing requirements). Product risks drive which features are tested, how deeply and with which techniques. Project risks drive staffing, scheduling and contingency in the test plan. A risk that is rated high for both likelihood and impact receives more testing, stronger techniques and earlier attention than a low-rated one.

Testing within verification and validation

Part 1 places testing inside the wider activities of verification (did we build the product right, according to its specification?) and validation (did we build the right product for its users and intended use?). Testing contributes to both, alongside reviews, analysis, demonstrations and simulations. It also discusses test independence: the more separated the tester is from the author of the work, the more likely they are to see problems the author is blind to, although independence costs communication and time. Knowing these ideas helps you explain why a developer's own unit tests are valuable but not sufficient for a high-risk feature.

Lesson 3 – Structure of the series

This lesson walks through each part. Remember that the parts are designed to be used together but can also be adopted one at a time: many teams start with Part 4 techniques or Part 3 templates long before they consider the full process model.

Part 1 – General concepts

Part 1 is informative: it explains rather than requires. It introduces testing in the context of verification and validation, the difference between static and dynamic testing, why exhaustive testing is impractical and testing is therefore a sampling activity, the role of test oracles, the value of independent testing, and how risk-based thinking shapes test strategies and plans. It also explains how the generic processes of Part 2 are instantiated in a real project, for example as several test levels and test types running in parallel. If you read only one part to understand the philosophy of the series, read this one.

Part 2 – Test processes

Part 2 is normative: it contains requirements that an organisation claiming conformance must meet. Each process is described with the same generic template used across SC 7 standards: purpose, outcomes, activities and tasks, and information items (the documents or records it produces). The processes are arranged in three layers, often called the multi-layer test process model:

Organizational test process – one generic process used to create, maintain and monitor organisation-wide test specifications, typically the test policy and the organizational test practices.
Test management processes – test strategy and planning, test monitoring and control, and test completion. These are applied to a whole project, to a test level such as system testing, or to a test type such as performance testing.
Dynamic test processes – test design and implementation, test environment and data management, test execution, and test incident reporting. These are where test cases are actually created and run.

The layers are connected by feedback. Organisational documents guide planning; monitoring and control steer the dynamic processes; results and progress flow back to monitoring; and lessons learned at completion can update the organisational practices. Informative annexes relate the test processes to other standards, such as the software lifecycle processes of ISO/IEC/IEEE 12207.

Figure 2 – The multi-layer test process model of Part 2: organisational specifications guide test management, which steers the dynamic test processes and receives their results.

Part 3 – Test documentation

Part 3 defines templates for the information items produced by the Part 2 processes. They are grouped by layer. At the organisational level there are the test policy and the organizational test practices. At the management level there are the test plan, the test status report and the test completion report. At the dynamic level there are the test model specification, test case specification, test procedure specification, test data requirements, test environment requirements, test data readiness report, test environment readiness report, actual results, test result, test execution log and incident report. Annexes give worked examples for both traditional and agile projects. A crucial point, often missed: the standard is about the information content, not about producing sixteen separate Word files. A test plan can live on a wiki page, test cases can live in a test management tool, and a status report can be a dashboard, as long as the required information exists and is maintained.

Part 4 – Test techniques

Part 4 defines test design techniques in three families and, for each, how to measure the coverage it achieves.

Specification-based (black-box) techniques derive tests from the required behaviour: equivalence partitioning, the classification tree method, boundary value analysis, syntax testing, combinatorial techniques (such as pairwise testing), decision table testing, cause-effect graphing, state transition testing, scenario testing, random testing, metamorphic testing and requirements-based testing.
Structure-based (white-box) techniques derive tests from the internal structure of the code: statement, branch, decision, branch condition, branch condition combination, modified condition/decision coverage (MC/DC) and data flow testing.
Experience-based techniques use the tester's knowledge of typical failures; the standard defines error guessing.

For every technique Part 4 explains how to create the test model, identify coverage items and derive test cases, and gives a coverage formula. Long informative annexes provide worked examples for each technique and relate the techniques to the quality characteristics they help to test. Because coverage is defined precisely, a test plan can state measurable completion criteria such as "100 % of boundary values" instead of vague promises.

Part 5 – Keyword-driven testing

Keyword-driven testing describes tests as sequences of reusable action words, for example login, enterAmount or checkBalance, each with parameters. Testers who are not programmers can write tests in this vocabulary, while engineers implement each keyword once in automation code. Part 5 explains the approach, defines layers of keywords (low-level keywords that interact with the interface, and higher-level keywords that combine them into business actions), gives guidance on when to use hierarchical rather than flat keywords, and states requirements for frameworks and tools, including a common data exchange format so that keyword-based test assets can move between tools.

Technical Reports

Technical Reports give guidance but contain no requirements. TR 29119-6 shows how to use the series in agile projects, for example how a test strategy fits into release planning and how documentation can be lightweight. TR 29119-11 discusses the special challenges of testing AI-based systems, such as non-deterministic behaviour and the quality of training data; more recent AI testing guidance is being developed in the ISO/IEC 42119 series. TR 29119-13 shows how the series can be used when testing biometric systems.

Conformance options

Parts 2, 3 and 4 each define two ways to conform. Full conformance means that all the requirements of the part (or of the processes, documents or techniques you claim) are met. Tailored conformance means that you deliberately omit or adapt some of them and record which ones and why. Tailoring is expected, not a failure: a small team whose automated tests create their own data on every run may decide that separate test data readiness reports add nothing, and record that decision.

Lesson 4 – How it works in practice

Starting at the organisational level

Most organisations begin by writing down what they already believe about testing. The test policy is usually one or two pages signed by senior management: why testing matters to the business, what it aims to achieve, how test independence and professional development are handled, and how testing is improved over time. The organizational test practices then describe the normal way of testing: typical test levels and types, standard techniques, entry and exit criteria, required documentation, tools, defect management and metrics. Large organisations may hold several practice documents, for instance one for mobile apps and one for safety-related systems. The organizational test process keeps these documents alive: it establishes them with stakeholder input, checks that projects actually use them and updates them when feedback shows they no longer fit.

Strategy and planning for a project or product

For each project, product team or test level, the test strategy and planning process produces a test plan. In practice this involves understanding the context and the stakeholders, identifying and analysing product and project risks, choosing how to treat each risk through testing, designing the strategy (test levels, test types, techniques, completion criteria, the degree of independence, environments and data), estimating staff and schedule, and agreeing the plan with the people who depend on it. The completion criteria are particularly important: they turn "we tested enough" into measurable statements tied to risk, such as coverage targets, no open critical incidents and an agreed residual risk.

In an agile team the same thinking happens at different moments. The overall strategy may be agreed at the start of a product or release, while sprint-level decisions about which stories need which tests are made during refinement and planning. The plan might be a page in the team's wiki that evolves with the backlog. TR 29119-6 gives examples of this mapping.

Monitoring, control and completion

Test monitoring and control runs throughout. The test manager or team collects measures such as executed versus planned tests, coverage reached, incidents found and their severity, and progress against risks; compares them with the plan; and issues control actions when reality differs, for example adding exploratory sessions on a feature that is failing more than expected, or re-prioritising when a deadline moves. Status is communicated through test status reports, which in many teams are dashboards generated from tools. When testing for the scope ends, the test completion process archives reusable test assets, cleans up or hands over environments, records lessons learned and produces the test completion report so that stakeholders can decide whether the residual risk is acceptable.

Designing and implementing tests

The test design and implementation process is the heart of Part 2 and the place where Part 4 techniques are used. In the second edition its first three activities are, in order: create the test model, identify the test coverage items and derive the test cases. Afterwards the test cases are grouped into test sets (for example by test level, by who executes them or by whether they are automated) and ordered into test procedures with their set-up and clean-up steps. Traceability links each test case back through its coverage item and model to the test basis, so that when a requirement changes you know which tests to update.

Figure 3 – The test design and implementation flow: a model built from the test basis and the required coverage yields coverage items, test cases and procedures, whose execution produces results and incident reports.

Environments, data, execution and incidents

The test environment and data management process makes sure that the environment and the data each test needs are ready and stay correct: it turns environment and data requirements into reality and reports readiness. Many delays in real projects come from missing environments or unrealistic data, which is why the second edition gives data the same weight as infrastructure. The test execution process runs the procedures, records actual results, compares them with expected results and logs what happened. The test incident reporting process analyses each unexpected result, decides whether it needs action and reports it to those who can fix it; after a fix, retesting and regression testing follow. In a continuous delivery pipeline these processes are largely automated, but they still exist: an automated suite running on every commit is test execution, and a failed build that opens a ticket is incident reporting.

Scripted and exploratory testing together

A frequent misunderstanding is that 29119 requires every test to be written in advance. It does not. Exploratory testing, in which the tester designs and executes tests at the same time while learning about the product, is recognised as a valid practice. A common pattern is to cover high-risk, well-specified behaviour with scripted and automated tests derived by formal techniques, and to use time-boxed exploratory sessions guided by charters for areas that are new, poorly specified or prone to surprises. Session notes, with the incidents found, then serve as the actual results and execution log.

Roles

The series does not prescribe job titles, but the processes imply responsibilities: someone sponsors and owns the test policy; someone (a test manager, test lead or the whole team) plans, monitors and reports; test analysts or developers design tests; someone prepares environments and data; testers or pipelines execute; and stakeholders such as product owners accept the residual risk at completion. In a small team one person may play several roles; in a regulated programme each may be a separate group.

Lesson 5 – Assessment, certification and compliance

Conformance is a claim, not a certificate

There is no official ISO certification scheme for 29119 comparable to accredited management system certification for ISO 9001 or ISO/IEC 27001. ISO, IEC and IEEE publish the standards but do not certify anyone against them. An organisation that follows the series makes a conformance claim, either full or tailored, and should be able to support it with evidence. Some consultancies and training providers offer their own assessments or certificates; these are private schemes, and anyone relying on them should ask what was checked, against which part and edition, and by whom.

Making a defensible claim

A defensible claim states exactly what it covers: which parts (for example Part 2 processes and Part 3 documentation), which scope (a product line, a project, the whole organisation) and whether conformance is full or tailored. For tailored conformance the claim lists the requirements that were not applied and the justification for each. Evidence includes the test policy and practices, test plans with risk analyses, status and completion reports, traceable test specifications, execution logs and incident records. A buyer may make conformance a contract condition and then audit this evidence; regulators in sectors such as finance, health or public administration sometimes reference the series as an example of good practice.

Figure 4 – From scope to claim: an organisation decides between full and tailored conformance, keeps evidence and may add a formal process capability assessment.

Process capability assessment

Where an organisation wants an independent and repeatable view of how well its test processes work, it can use the ISO/IEC 330xx family of process assessment standards. ISO/IEC 33063 provides a process assessment model for software testing based on the processes of 29119-2. It is used together with the measurement framework of ISO/IEC 33020, which rates each process on capability levels from 0 (incomplete) to 5 (innovating) by judging process attributes, such as whether the process is performed, managed, established, predictable and continuously improved. The published edition dates from 2015 and was written for the first edition of Part 2, so assessors map its indicators to the renamed and restructured 2021 processes; check the ISO catalogue for any newer edition. An assessment produces a capability profile: for example, test execution may be well managed while test completion is barely performed. That profile, not a single badge, is the useful output.

Maturity models

Many organisations also use TMMi (Test Maturity Model Integration), an independent five-level maturity model for test processes with its own accredited assessment scheme. TMMi and 29119 are complementary: TMMi describes what to improve in what order, while 29119 provides definitions, process descriptions, templates and techniques that help implement those improvements. Organisations sometimes say "our processes conform to 29119-2 and we are assessed at TMMi level 3"; these are two different statements that should not be confused.

People

No personal certification is issued by ISO, IEC or IEEE for 29119. Testers typically learn the standard through vendor or university courses, and many testing qualifications teach compatible concepts. When a job advertisement asks for "29119 knowledge", it usually means familiarity with the process model, documentation and techniques covered in this tutorial.

Lesson 6 – Worked example

This example follows a fictional organisation, Northwind Lending, through its first year with the series. Northwind has 140 staff and builds a web and mobile application through which customers apply for personal loans. Two incidents prompted the change: a production fault that approved loans above the legal maximum, and an auditor's comment that nobody could show how the release decision had been made.

Step 1 – Policy and practices

The head of engineering sponsors a one-page test policy. It states that testing exists to give management reliable information on product risk before each release, that test effort is driven by risk to customers and to regulatory compliance, that every release decision is based on a test completion report, and that the test approach is reviewed twice a year. The quality lead then writes organizational test practices on the company wiki: the standard test levels (component, integration, system, acceptance), the default techniques for different risk ratings, the definition of done for testing in each sprint, the tools in use and the rules for incident severity. Writing these down reveals that two teams use different severity scales, which is fixed before any project work begins.

Step 2 – Risk-based test plan

For the next release, which adds a new eligibility engine and an application tracking feature, the team holds a one-hour risk workshop with a product owner, two developers, a tester and a compliance officer. Product risks with high ratings include wrong loan amount limits, wrong eligibility decisions and applications stuck in an incorrect status. Project risks include a single tester for the release and a late-delivered credit bureau test service. The plan, a wiki page linked from the release epic, sets the strategy: formal specification-based techniques for the high risks; branch coverage of the eligibility rules module at component level; exploratory sessions for the new mobile screens; performance smoke tests for peak application hours; and a second person reviewing high-risk test designs to compensate for having only one tester. Completion criteria are stated as numbers: 100 % equivalence partition and boundary coverage for amount and term, 100 % of decision table rules, every valid state transition, at least 90 % branch coverage of the rules module, and no open critical or high incidents.

Step 3 – Designing tests with Part 4 techniques

Loan amount. The requirement says that amounts from 1,000 to 50,000 are accepted. The tester builds a model of three partitions: below 1,000 (invalid), 1,000 to 50,000 (valid) and above 50,000 (invalid). Each partition is a coverage item for equivalence partitioning. For boundary value analysis using two values per boundary, the coverage items are 999 and 1,000 at the lower boundary and 50,000 and 50,001 at the upper one. Five test cases cover everything: 999, 1,000, 25,000, 50,000 and 50,001, each with an expected result (rejected or accepted with the right message). The fault that reached production last year, approval of amounts just above the limit, would have been caught by the 50,001 case.

Eligibility. The rules combine three conditions: applicant age band, employment status and credit score band. The tester models them in a decision table. After collapsing combinations where one condition makes the others irrelevant, eight rules remain; each rule is a coverage item and gets one test case. At component level a developer adds unit tests until the coverage tool shows the branch target is reached, and finds one branch that can never execute, which is removed.

Application status. The tracking feature is a natural fit for state transition testing. The model below shows the states and allowed transitions. Every valid transition becomes a coverage item; the tester also adds tests for invalid transitions, such as trying to withdraw an application that has already been approved.

Figure 5 – A state transition test model for Northwind's loan application: each arrow is a coverage item, and invalid transitions are tested as well.

Step 4 – Implementing, preparing and executing

Test cases for amount and eligibility are automated at the API level using keyword-style steps (createApplication, setAmount, submit, checkDecision), so that the business analyst can read and extend them. The state transition tests are grouped into a procedure that walks one application through a realistic path plus separate short procedures for the invalid transitions. Test data requirements list anonymised customer profiles for each credit score band; the environment requirements include the stubbed credit bureau service. A readiness check two days before execution finds that the stub returns only one score band, which is corrected before it can block testing.

Execution runs in the pipeline on every merge, while the tester runs four ninety-minute exploratory sessions on the mobile screens with written charters. The automated run produces execution logs and results; the exploratory sessions produce notes and three incidents, one of them high severity (the status label does not refresh after "more documents needed").

Step 5 – Monitoring, control and completion

A daily dashboard shows coverage against each criterion and incidents by severity. When branch coverage stalls at 82 %, the test lead asks the developers to pair on the missing branches and moves one exploratory session to the following day; this is a control action recorded in the plan's change log. At the end of the release the completion report summarises what was tested, coverage achieved against every criterion, open incidents (two low ones, accepted by the product owner) and residual risks. The release decision references this report, answering the auditor's earlier concern. The team also archives the reusable automated tests and notes a lesson learned: risk workshops should include customer support staff, who know the most common complaints.

Step 6 – The conformance statement

After two releases, Northwind writes a short statement: its testing for the loan platform claims tailored conformance with 29119-2 and 29119-3. Tailoring decisions are listed with reasons: separate test data readiness reports are replaced by a checklist within the environment readiness report, and the readiness of the third-party credit bureau sandbox, which Northwind does not control, is not managed by its own environment process but checked through the supplier's status page. A year later the company commissions an ISO/IEC 33063-based assessment, which rates test execution and incident reporting highly but shows that the organizational test process is weak because nobody checks whether teams follow the practices. That finding becomes the next improvement goal.

Lesson 7 – Relationship to other standards and frameworks

29119 sits inside a large landscape of software engineering standards and testing models. Knowing the neighbours helps you avoid duplicate work and explain to others which document answers which question.

Standard or model	Main focus	Relationship to 29119
ISO/IEC/IEEE 12207	Software lifecycle processes, including verification and validation	Defines the overall lifecycle processes, including verification and validation; 29119 elaborates the testing side of them, and Part 2 relates its processes to 12207.
ISO/IEC 20246	Work product reviews (static testing)	Covers the reviews that 29119 does not describe in detail; together they span static and dynamic testing.
ISO/IEC 25010	Product quality model (characteristics such as security, performance efficiency, usability)	Provides the quality characteristics that test types target; Part 4 relates techniques to these characteristics.
ISO/IEC 33063 with ISO/IEC 33020	Process assessment model for testing and the capability rating framework	Used to assess the capability of the Part 2 processes in a repeatable way.
TMMi	Five-level test maturity model with an accredited assessment scheme	Defines an improvement path; 29119 supplies definitions, processes, templates and techniques for implementing it.
IEEE 829 and BS 7925-1/-2	Older test documentation, vocabulary and component testing standards	Superseded; their content was absorbed into Parts 1, 3 and 4, and the series includes mappings from them.
IEEE 1012	System, software and hardware verification and validation	Defines V&V activities by integrity level; testing under 29119 provides much of the V&V evidence it calls for.
ISO/IEC/IEEE 15289	Content of lifecycle information items	General rules for documentation that Part 3 specialises for testing.

Domain safety and security standards

Sector standards such as IEC 62304 for medical device software, ISO 26262 for road vehicles or DO-178C for airborne software require specific verification and testing activities, sometimes including particular coverage criteria such as MC/DC. They do not tell you how to describe test processes or techniques in detail. Many organisations in these sectors therefore use 29119 vocabulary, templates and technique definitions to implement the testing that the sector standard demands. When the two disagree, the sector standard (and the regulator) takes precedence.

Agile, DevOps and certification syllabi

The series is lifecycle-neutral, and TR 29119-6 shows how its processes map to agile ceremonies and artefacts. In DevOps settings the dynamic processes are largely automated in pipelines, while test management becomes continuous monitoring of quality signals. Popular tester qualification syllabi share much of the same vocabulary and techniques, but they are training programmes, not standards, and their definitions are not always identical. When precision matters, for instance in a contract, cite the standard and its edition.

Common pitfalls and best practices

Pitfalls to avoid:

Treating Part 3 as a list of mandatory documents and producing paperwork that nobody reads, instead of making sure the required information exists in whatever form suits the team.
Skipping risk analysis and then testing everything with the same depth, which wastes effort on low-risk areas and leaves critical behaviour under-tested.
Claiming "full conformance" without being able to show evidence for every requirement in scope, or tailoring silently without recording the reasons.
Stating completion criteria in vague terms such as "sufficient testing", which makes it impossible to decide objectively when to stop.
Confusing high code coverage with good testing: 100 % statement coverage can still miss wrong requirements, missing features and boundary faults.
Believing that the standard forbids exploratory or unscripted testing, and therefore losing one of the most effective ways of finding unexpected problems.
Copying another organisation's templates without adapting them to your product, lifecycle and risk profile.

Best practices to adopt:

Start with vocabulary and techniques that solve today's problems, then introduce processes and documentation step by step.
Run short, cross-functional risk workshops and link each high risk to specific test levels, techniques and completion criteria.
Keep traceability from test basis to model, coverage item, test case and result in your tools, so that changes and audits are easy.
Combine formal techniques for well-specified, high-risk behaviour with charter-based exploratory sessions for new or uncertain areas.
Automate repeatable execution and reporting so that test status is visible continuously rather than assembled manually at the end.
Write tailoring decisions down with a one-line justification each; it costs little and makes any conformance claim credible.
Review organisational practices regularly using lessons from test completion, and consider an independent capability assessment once processes are stable.

Summary and key takeaways

ISO/IEC/IEEE 29119 is a family of testing standards: concepts (Part 1, 2022), processes (Part 2, 2021), documentation (Part 3, 2021), techniques (Part 4, 2021) and keyword-driven testing (Part 5, 2024), plus Technical Reports for agile, AI-based and biometric systems.
It replaced IEEE 829, IEEE 1008 and BS 7925-1/-2 and gives the industry a common vocabulary for testing.
Risk-based testing runs through the whole series: risks decide what to test, how deeply and with which techniques.
Part 2 arranges test processes in three layers: organisational, test management and dynamic, connected by feedback.
Test design builds a test model from the test basis, identifies measurable coverage items and derives test cases, which makes coverage and completion criteria objective.
Part 3 cares about information content, not document format; wikis, tools and dashboards are acceptable.
Conformance is full or tailored and is claimed by the organisation; there is no official ISO certification, but process capability can be assessed with ISO/IEC 33063.
Use the series as a shared language and thinking framework that supports, rather than replaces, professional judgement.

Reflection questions

Pick a feature you tested recently. What was its test basis, what test model could you have built from it, and which coverage items would that model produce?
Where in your organisation do the three layers of the Part 2 model already exist informally, and which layer is the weakest?
Which three product risks in your current product deserve the strongest testing, and what measurable completion criteria would you set for them?
If a customer asked you tomorrow to state your conformance to 29119-2, would you claim full or tailored conformance, and which tailoring decisions would you need to document?
How would you answer a colleague who argues that following 29119 will turn testing into paperwork and stop the team from exploring?