ISO/IEC TR 29119-6:2021
(Main)Software and systems engineering — Software testing — Part 6: Guidelines for the use of ISO/IEC/IEEE 29119 (all parts) in agile projects
Software and systems engineering — Software testing — Part 6: Guidelines for the use of ISO/IEC/IEEE 29119 (all parts) in agile projects
This document provides guidance for the application of ISO/IEC/IEEE 29119 (all parts) in agile life cycles. This document is intended for (and not limited to) testers, test managers, business analysts, product owners, Scrum masters and developers involved in agile projects. The mappings provided in this document are designed to benefit any team or organization that is either moving away from traditional/waterfall life cycles and into agile or vice versa as well as new organizations that are commencing agile as their chosen life cycle. It is designed to be understandable regardless of the reader's familiarity with ISO/IEC/IEEE 29119 (all parts).
Ingénierie du logiciel et des systèmes — Essais du logiciel — Partie 6: Lignes directrices pour l'utilisation de l'ISO/IEC/IEEE 29119 (toutes les parties) dans les projets agiles
General Information
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/IEC TR
REPORT 29119-6
First edition
2021-07
Software and systems engineering —
Software testing —
Part 6:
Guidelines for the use of ISO/IEC/IEEE
29119 (all parts) in agile projects
Ingénierie du logiciel et des systèmes — Essais du logiciel —
Partie 6: Lignes directrices pour l'utilisation de l'ISO/IEC/IEEE 29119
(toutes les parties) dans les projets agiles
Reference number
ISO/IEC TR 29119-6:2021(E)
©
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC TR 29119-6:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 29119-6:2021(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Concepts . 1
4.1 Agile practices and artefacts . 1
4.2 Mapping of agile practices to ISO/IEC/IEEE 29119-2 test processes . 2
4.2.1 Overview . 2
4.2.2 Acceptance criteria . 3
4.2.3 Acceptance test-driven development (ATDD) . 3
4.2.4 Amplify learning . 3
4.2.5 Backlog management . 3
4.2.6 Behaviour-driven development (BDD) . 4
4.2.7 Build integrity in . 5
4.2.8 Burn-down and burn-up charts . 5
4.2.9 Co-located teams . . 6
4.2.10 Collective code ownership . 6
4.2.11 Continuous delivery and deployment. 6
4.2.12 Continuous integration and continuous testing . 7
4.2.13 Cross-functional team . 7
4.2.14 Daily stand-up . 8
4.2.15 Definition of done . 8
4.2.16 Definition of ready . 9
4.2.17 Eliminate waste .10
4.2.18 Empowered team .11
4.2.19 Emergent design .11
4.2.20 Epic .11
4.2.21 Fast user feedback .11
4.2.22 Feature-driven development (FDD) .12
4.2.23 Feature toggle .12
4.2.24 Frequent interaction with product owner .12
4.2.25 Increment .12
4.2.26 Informal defect management .12
4.2.27 Iteration backlog .13
4.2.28 Iteration goal .13
4.2.29 Iteration planning .13
4.2.30 Iteration review .13
4.2.31 Iteration zero .14
4.2.32 Just in time .14
4.2.33 Limit work in progress .14
4.2.34 Mood chart .14
4.2.35 Occasional test iterations .15
4.2.36 Pair programming .15
4.2.37 Parallel test iterations .15
4.2.38 Planning poker.15
4.2.39 Product backlog .16
4.2.40 Product owner .16
4.2.41 Refactoring .16
4.2.42 Relative estimation .16
4.2.43 Release planning .17
4.2.44 Retrospective meeting .17
4.2.45 Scrum master .17
© ISO/IEC 2021 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 29119-6:2021(E)
4.2.46 Self-organizing teams .17
4.2.47 Short iterations .17
4.2.48 Simplicity .18
4.2.49 Story mapping .18
4.2.50 Story testing .18
4.2.51 Sustainable pace .18
4.2.52 Task board .18
4.2.53 Team charter .18
4.2.54 Team room .18
4.2.55 Team-based estimation .19
4.2.56 Technical debt .19
4.2.57 Test-driven development (TDD) .19
4.2.58 Timebox .20
4.2.59 Transparency .20
4.2.60 User story .20
4.2.61 User stories – INVEST mnemonic.20
4.2.62 User story format – role/feature/rationale .20
4.2.63 Velocity .21
Annex A (informative) Mapping of The Scrum Guide to ISO/IEC/IEEE 29119-2 test processes .22
Annex B (informative) Mapping of ISO/IEC/IEEE 29119-2 (test processes) to agile practices
and techniques covered under Clause 4.24
Annex C (informative) Example mapping of typical agile test artefacts to
ISO/IEC/IEEE 29119-3 test documentation .37
Annex D (informative) Example agile test artefact .39
Bibliography .45
iv © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 29119-6:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives or www .iec .ch/ members
_experts/ refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html. In the IEC, see www .iec .ch/ understanding -standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC1, Information technology,
Subcommittee SC 7, Software and systems engineering.
A list of all parts in the ISO/IEC/IEEE 29119 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html and www .iec .ch/ national
-committees.
© ISO/IEC 2021 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC TR 29119-6:2021(E)
Introduction
The purpose of ISO/IEC/IEEE 29119 (all parts) is to define an internationally agreed set of standards for
software testing that can be used by any organization when performing any form of software testing.
This document facilitates understanding of how ISO/IEC/IEEE 29119 (all parts) applies to agile life
cycles.
ISO/IEC/IEEE 29119-1 introduces software testing concepts and vocabulary. This document uses the
concepts and vocabulary of ISO/IEC/IEEE 29119-1.
ISO/IEC/IEEE 29119-2 comprises test process descriptions that define the software testing processes
at the organizational level, test management level and dynamic test levels. It supports dynamic testing,
functional and non-functional testing, manual and automated testing and scripted and unscripted
testing, and can be utilized within any lifecycle model, including agile lifecycles and methodologies.
ISO/IEC/IEEE 29119-3 defines software test documentation. The requirements specified for templates
and examples of test documentation defined in ISO/IEC/IEEE 29119-3 can be met in standard or
tailored agile lifecycles and methodologies.
ISO/IEC/IEEE 29119-4 defines test design techniques, which can be utilized in any lifecycle, including
agile.
ISO/IEC/IEEE 29119-5 addresses the use of keywords to support automated testing.
This document provides a mapping of agile concepts to ISO/IEC/IEEE 29119-2. It also explains how
ISO/IEC/IEEE 29119-2 can be adopted under specific agile methodologies and demonstrates how the
test documentation templates defined in ISO/IEC/IEEE 29119-3 can be implemented in agile lifecycles.
Clause 4 maps agile practices and artefacts to corresponding clauses of ISO/IEC/IEEE 29119-2.
[6]
Annex A provides a mapping from The Scrum Guide to ISO/IEC/IEEE 29119-2 clauses. Annex B
provides a mapping from all clauses of ISO/IEC/IEEE 29119-2 to the agile practices and artefacts
covered under Clause 4. Annex C provides an example mapping of typical test artefacts used in agile to
ISO/IEC/IEEE 29119-3. Annex D provides examples of agile test artefacts and explains how they comply
with ISO/IEC/IEEE 29119-3.
vi © ISO/IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 29119-6:2021(E)
Software and systems engineering — Software testing —
Part 6:
Guidelines for the use of ISO/IEC/IEEE 29119 (all parts) in
agile projects
1 Scope
This document provides guidance for the application of ISO/IEC/IEEE 29119 (all parts) in agile life
cycles. This document is intended for (and not limited to) testers, test managers, business analysts,
product owners, Scrum masters and developers involved in agile projects. The mappings provided
in this document are designed to benefit any team or organization that is either moving away from
traditional/waterfall life cycles and into agile or vice versa as well as new organizations that are
commencing agile as their chosen life cycle. It is designed to be understandable regardless of the
reader's familiarity with ISO/IEC/IEEE 29119 (all parts).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
NOTE For terms and definitions in the field of systems and software engineering, see ISO/IEC/IEEE 24765,
which is published periodically as a “snapshot” of the SEVOCAB (Systems and software Engineering Vocabulary)
database and is publicly accessible at www .computer .org/ sevocab.
4 Concepts
4.1 Agile practices and artefacts
This document explains how ISO/IEC/IEEE 29119 (all parts) can be adopted for testing in products,
projects, teams or organizations that have adopted agile methodologies (referred to in this document
as “agile testing”). The aim is to assist users of the processes and documentation templates defined in
ISO/IEC/IEEE 29119-2 and ISO/IEC/IEEE 29119-3 in agile life cycles.
Agile is an approach to software and systems development whereby requirements and systems evolve
over time via the collaboration and communication of self-organizing cross-functional teams, with
regular feedback from end-users, supporting a rapid and flexible response to requirement change.
Example agile methodologies include Scrum, SAFe and eXtreme Programming (XP), within which a
wide variety of agile practices and artefacts exist. The agile practices and artefacts listed in Table 1
are covered in this document. These agile practices and artefacts include many that are utilized during
testing. Some of these practices and artefacts might not be part of a specific agile methodology such
© ISO/IEC 2021 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC TR 29119-6:2021(E)
as Scrum. This document explains how each practice and artefact maps to the concepts covered in
ISO/IEC/IEEE 29119-2 and ISO/IEC/IEEE 29119-3.
Table 1 — Agile practices and artefacts covered in this document
Acceptance criteria Feature toggle Retrospective meeting (a.k.a. Sprint
retrospective)
Acceptance test-driven Frequent interaction with product
development owner Scrum master
Amplify learning Increment (a.k.a. product incre- Self-organizing teams
ment)
Backlog review (a.k.a. backlog Short iterations
maintenance, backlog refinement) Informal defect management
Simplicity
Behaviour-driven development Iteration backlog (a.k.a. sprint
Story card
(a.k.a. specification by example) backlog, sprint catalogue, iteration
backlog) Story mapping
Build integrity in
Iteration goal (a.k.a. sprint goal) Story testing
Burn-down and burn-up chart
Iteration planning (a.k.a. sprint
Sustainable pace (a.k.a. 40-hour
Co-located teams
planning) and release planning
week)
(a.k.a. phase planning, stage plan-
Collective code ownership
Task board (a.k.a. Scrum board,
ning)
Continuous delivery and deploy- Kanban board)
ment Iteration review (a.k.a. demo, sprint
Team charter (a.k.a. project charter)
review, iteration review)
Continuous integration and continu-
Team room
ous testing Iteration zero (a.k.a. sprint zero)
Team-based estimation
Just in time (a.k.a. decide as late as
Continuous process improvement
possible)
Technical debt
Cross-functional team
Limit work in progress (WIP)
Test-driven development
Daily stand-up (a.k.a. daily Scrum,
frequent stand-up) Mood chart (a.k.a. niko-niko) Timebox (a.k.a. timeboxed itera-
tions)
Occasional test iterations
Definition of done
Transparency (a.k.a. visibility of
Definition of ready Pair programming
project progress)
Eliminate waste Parallel test iterations
User stories – INVEST mnemonic
Planning poker
Empowered team
User story
Emergent design Product backlog (a.k.a. backlog)
User story format – role/feature/
Epic Product owner rationale
Refactoring
Fast user feedback Velocity
Feature-driven development Relative estimation
Explanations of how these agile practices and artefacts can be used in the test processes of
ISO/IEC/IEEE 29119-2 are provided in 4.2. An example mapping of each concept to Scrum is provided in
Annex A. A mapping of Scrum to ISO/IEC/IEEE 29119-2 is provided in Annex B.
Some of the same test documentation artefacts that are created as in traditional projects are also often
created in agile, such as test policy, organizational test practices and test plan, though typically with
significantly less detail and sometimes in an alternative format. An example is provided in Annex C
demonstrating how test documentation that is often used in agile maps to ISO/IEC/IEEE 29119-3.
4.2 Mapping of agile practices to ISO/IEC/IEEE 29119-2 test processes
4.2.1 Overview
This subclause demonstrates how the agile practices and artefacts listed in Table 1 map to the test
processes defined in ISO/IEC/IEEE 29119-2. Each mapping is presented in Tables 2 to 27.
2 © ISO/IEC 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 29119-6:2021(E)
4.2.2 Acceptance criteria
Acceptance criteria are the conditions that a user story needs to satisfy for it to be considered "done"
(e.g. accepted by the product owner, customer, user or other stakeholders).
Table 2 — Mapping to ISO/IEC/IEEE 29119-2
Agile concept ISO/IEC/IEEE 29119- Mapping details
2:— clause
Acceptance criteria 8.2.4.2 Create test model Acceptance criteria would be created as a test model that
lists atomic requirements to be met before a user story can
be accepted as “done.”
4.2.3 Acceptance test-driven development (ATDD)
Acceptance test-driven development (ATDD) is a test-first approach whereby an agile team creates
acceptance tests, to verify that acceptance criteria of each user story are met, before the code that
passes those tests is written. ATDD is a form of test-driven development (TDD) at the acceptance testing
level.
Table 3 — Mapping to ISO/IEC/IEEE 29119-2
Agile concept ISO/IEC/IEEE 29119- Mapping Details
2:— clause
Acceptance test-driven All clauses When conducting ATDD, all clauses of ISO/IEC/IEEE 29119-
development 2 apply. The requirement to conduct ATDD can be included
in the test policy, and the chosen approach to ATDD would
be described in detail in the organizational test practices.
The requirement to use ATDD on a given product would be
mentioned in the test plan for that product. Tests can be
designed and executed under the test design and execution
process, and the environment and test data requirements
would be covered under the environment and data man-
agement process. Testing can be monitored, controlled and
reported on under the monitor and control activity. Defects
detected during testing can be raised under the incident
reporting process. Once testing is complete, assets can be
archived, and the outcomes of testing reported, under the
test completion process.
4.2.4 Amplify learning
Amplify learning is a concept of creating a team environment that encourages learning through various
approaches including through trial and error (i.e. accepting and learning from failure), highlighting
the fact that systems development is a continual learning process. Although this can be supported
by implementing ISO/IEC/IEEE 29119-2 iteratively (which is supported by the standard), there is no
specific concept in the standard that maps to this.
4.2.5 Backlog management
It is common for all members of the agile team to regularly review user stories, including testers. This
can include reviewing acceptance criteria to ensure they are complete and testable. Backlog reviews
are also referred to as "backlog maintenance" and "backlog refinement." During backlog management,
it is common for testers to review the backlog from a testing perspective, to estimate testing effort for
each user story and to prioritise testing efforts on each user story.
© ISO/IEC 2021 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC TR 29119-6:2021(E)
Table 4 — Mapping to ISO/IEC/IEEE 29119-2
Agile concept ISO/IEC/IEEE 29119- Mapping details
2:— clause
Backlog management 8.2.4.2 Create test model Acceptance criteria would be created as a test model that
lists atomic requirements to be met before a user story can
be accepted as “done.”
7.2.4.4 Identify and ana- Project and product risks can be considered during user
lyse risks story prioritization, would be identified via the identify and
analyse risks activity.
7.2.4.8 Record test plan Test estimates are refined during each iteration (e.g. during
> task a) iteration planning or backlog refinement sessions) via the
record test plan activity, task a).
8.2 Test design and im- The priority of ea
...
TECHNICAL ISO/IEC TR
REPORT 29119-6
First edition
Software and systems engineering —
Software testing —
Part 6:
Guidelines for the use of ISO/IEC/IEEE
29119 (all parts) in agile projects
PROOF/ÉPREUVE
Reference number
ISO/IEC TR 29119-6:2021(E)
©
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC TR 29119-6:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 29119-6:2021(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Concepts . 1
4.1 Agile practices and artefacts . 1
4.2 Mapping of agile practices to ISO/IEC/IEEE 29119-2 test processes . 2
4.2.1 Overview . 2
4.2.2 Acceptance criteria . 3
4.2.3 Acceptance test-driven development (ATDD) . 3
4.2.4 Amplify learning . 3
4.2.5 Backlog management . 3
4.2.6 Behaviour-driven development (BDD) . 4
4.2.7 Build integrity in . 5
4.2.8 Burn-down and burn-up charts . 5
4.2.9 Co-located teams . . 6
4.2.10 Collective code ownership . 6
4.2.11 Continuous delivery and deployment. 6
4.2.12 Continuous integration and continuous testing . 7
4.2.13 Cross-functional team . 7
4.2.14 Daily stand-up . 8
4.2.15 Definition of done . 8
4.2.16 Definition of ready . 9
4.2.17 Eliminate waste .10
4.2.18 Empowered team .11
4.2.19 Emergent design .11
4.2.20 Epic .11
4.2.21 Fast user feedback .11
4.2.22 Feature-driven development (FDD) .12
4.2.23 Feature toggle .12
4.2.24 Frequent interaction with product owner .12
4.2.25 Increment .12
4.2.26 Informal defect management .12
4.2.27 Iteration backlog .13
4.2.28 Iteration goal .13
4.2.29 Iteration planning .13
4.2.30 Iteration review .13
4.2.31 Iteration zero .14
4.2.32 Just in time .14
4.2.33 Limit work in progress .14
4.2.34 Mood chart .14
4.2.35 Occasional test iterations .15
4.2.36 Pair programming .15
4.2.37 Parallel test iterations .15
4.2.38 Planning poker.15
4.2.39 Product backlog .16
4.2.40 Product owner .16
4.2.41 Refactoring .16
4.2.42 Relative estimation .16
4.2.43 Release planning .17
4.2.44 Retrospective meeting .17
4.2.45 Scrum master .17
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 29119-6:2021(E)
4.2.46 Self-organizing teams .17
4.2.47 Short iterations .17
4.2.48 Simplicity .18
4.2.49 Story mapping .18
4.2.50 Story testing .18
4.2.51 Sustainable pace .18
4.2.52 Task board .18
4.2.53 Team charter .18
4.2.54 Team room .18
4.2.55 Team-based estimation .19
4.2.56 Technical debt .19
4.2.57 Test-driven development (TDD) .19
4.2.58 Timebox .20
4.2.59 Transparency .20
4.2.60 User story .20
4.2.61 User stories – INVEST mnemonic.20
4.2.62 User story format – role/feature/rationale .20
4.2.63 Velocity .21
Annex A (informative) Mapping of The Scrum Guide to ISO/IEC/IEEE 29119-2 test processes .22
Annex B (informative) Mapping of ISO/IEC/IEEE 29119-2 (test processes) to agile practices
and techniques covered under Clause 4.24
Annex C (informative) Example mapping of typical agile test artefacts to
ISO/IEC/IEEE 29119-3 test documentation .37
Annex D (informative) Example agile test artefact .39
Bibliography .45
iv PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 29119-6:2021(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives or www .iec .ch/ members
_experts/ refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/ patents) or the IEC
list of patent declarations received (see patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html. In the IEC, see www .iec .ch/ understanding -standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC1, Information technology,
Subcommittee SC 7, Software and systems engineering.
A list of all parts in the ISO/IEC/IEEE 29119 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html and www .iec .ch/ national
-committees.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE v
---------------------- Page: 5 ----------------------
ISO/IEC TR 29119-6:2021(E)
Introduction
The purpose of ISO/IEC/IEEE 29119 (all parts) is to define an internationally agreed set of standards for
software testing that can be used by any organization when performing any form of software testing.
This document facilitates understanding of how ISO/IEC/IEEE 29119 (all parts) applies to agile life
cycles.
ISO/IEC/IEEE 29119-1 introduces software testing concepts and vocabulary. This document uses the
concepts and vocabulary of ISO/IEC/IEEE 29119-1.
ISO/IEC/IEEE 29119-2 comprises test process descriptions that define the software testing processes
at the organizational level, test management level and dynamic test levels. It supports dynamic testing,
functional and non-functional testing, manual and automated testing and scripted and unscripted
testing, and can be utilized within any lifecycle model, including agile lifecycles and methodologies.
ISO/IEC/IEEE 29119-3 defines software test documentation. The requirements specified for templates
and examples of test documentation defined in ISO/IEC/IEEE 29119-3 can be met in standard or
tailored agile lifecycles and methodologies.
ISO/IEC/IEEE 29119-4 defines test design techniques, which can be utilized in any lifecycle, including
agile.
ISO/IEC/IEEE 29119-5 addresses the use of keywords to support automated testing.
This document provides a mapping of agile concepts to ISO/IEC/IEEE 29119-2. It also explains how
ISO/IEC/IEEE 29119-2 can be adopted under specific agile methodologies and demonstrates how the
test documentation templates defined in ISO/IEC/IEEE 29119-3 can be implemented in agile lifecycles.
Clause 4 maps agile practices and artefacts to corresponding clauses of ISO/IEC/IEEE 29119-2.
[6]
Annex A provides a mapping from The Scrum Guide to ISO/IEC/IEEE 29119-2 clauses. Annex B
provides a mapping from all clauses of ISO/IEC/IEEE 29119-2 to the agile practices and artefacts
covered under Clause 4. Annex C provides an example mapping of typical test artefacts used in agile to
ISO/IEC/IEEE 29119-3. Annex D provides examples of agile test artefacts and explains how they comply
with ISO/IEC/IEEE 29119-3.
vi PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 29119-6:2021(E)
Software and systems engineering — Software testing —
Part 6:
Guidelines for the use of ISO/IEC/IEEE 29119 (all parts) in
agile projects
1 Scope
This document provides guidance for the application of ISO/IEC/IEEE 29119 (all parts) in agile life
cycles. This document is intended for (and not limited to) testers, test managers, business analysts,
product owners, Scrum masters and developers involved in agile projects. The mappings provided
in this document are designed to benefit any team or organization that is either moving away from
traditional/waterfall life cycles and into agile or vice versa as well as new organizations that are
commencing agile as their chosen life cycle. It is designed to be understandable regardless of the
reader's familiarity with ISO/IEC/IEEE 29119 (all parts).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
No terms and definitions are listed in this document.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
NOTE For terms and definitions in the field of systems and software engineering, see ISO/IEC/IEEE 24765,
which is published periodically as a “snapshot” of the SEVOCAB (Systems and software Engineering Vocabulary)
database and is publicly accessible at www .computer .org/ sevocab.
4 Concepts
4.1 Agile practices and artefacts
This document explains how ISO/IEC/IEEE 29119 (all parts) can be adopted for testing in products,
projects, teams or organizations that have adopted agile methodologies (referred to in this document
as “agile testing”). The aim is to assist users of the processes and documentation templates defined in
ISO/IEC/IEEE 29119-2 and ISO/IEC/IEEE 29119-3 in agile life cycles.
Agile is an approach to software and systems development whereby requirements and systems evolve
over time via the collaboration and communication of self-organizing cross-functional teams, with
regular feedback from end-users, supporting a rapid and flexible response to requirement change.
Example agile methodologies include Scrum, SAFe and eXtreme Programming (XP), within which a
wide variety of agile practices and artefacts exist. The agile practices and artefacts listed in Table 1
are covered in this document. These agile practices and artefacts include many that are utilized during
testing. Some of these practices and artefacts might not be part of a specific agile methodology such
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 7 ----------------------
ISO/IEC TR 29119-6:2021(E)
as Scrum. This document explains how each practice and artefact maps to the concepts covered in
ISO/IEC/IEEE 29119-2 and ISO/IEC/IEEE 29119-3.
Table 1 — Agile practices and artefacts covered in this document
Acceptance criteria Feature toggle Retrospective meeting (a.k.a. Sprint
retrospective)
Acceptance test-driven develop- Frequent interaction with product
ment owner Scrum master
Amplify learning Increment (a.k.a. product incre- Self-organizing teams
ment)
Backlog review (a.k.a. backlog Short iterations
maintenance, backlog refinement) Informal defect management
Simplicity
Behaviour-driven development Iteration backlog (a.k.a. sprint
Story card
(a.k.a. specification by example) backlog, sprint catalogue, iteration
backlog) Story mapping
Build integrity in
Iteration goal (a.k.a. sprint goal) Story testing
Burn-down and burn-up chart
Iteration planning (a.k.a. sprint
Sustainable pace (a.k.a. 40-hour
Co-located teams
planning) and release planning
week)
(a.k.a. phase planning, stage plan-
Collective code ownership
Task board (a.k.a. Scrum board,
ning)
Continuous delivery and deploy- Kanban board)
ment Iteration review (a.k.a. demo, sprint
Team charter (a.k.a. project charter)
review, iteration review)
Continuous integration and continu-
Team room
ous testing Iteration zero (a.k.a. sprint zero)
Team-based estimation
Just in time (a.k.a. decide as late as
Continuous process improvement
possible)
Technical debt
Cross-functional team
Limit work in progress (WIP)
Test-driven development
Daily stand-up (a.k.a. daily Scrum,
frequent stand-up) Mood chart (a.k.a. niko-niko) Timebox (a.k.a. timeboxed itera-
tions)
Occasional test iterations
Definition of done
Transparency (a.k.a. visibility of
Definition of ready Pair programming
project progress)
Eliminate waste Parallel test iterations
User stories – INVEST mnemonic
Planning poker
Empowered team
User story
Emergent design Product backlog (a.k.a. backlog)
User story format – role/feature/
Epic Product owner rationale
Refactoring
Fast user feedback Velocity
Feature-driven development Relative estimation
Explanations of how these agile practices and artefacts can be used in the test processes of
ISO/IEC/IEEE 29119-2 are provided in 4.2. An example mapping of each concept to Scrum is provided in
Annex A. A mapping of Scrum to ISO/IEC/IEEE 29119-2 is provided in Annex B.
Some of the same test documentation artefacts that are created as in traditional projects are also often
created in agile, such as test policy, organizational test practices and test plan, though typically with
significantly less detail and sometimes in an alternative format. An example is provided in Annex C
demonstrating how test documentation that is often used in agile maps to ISO/IEC/IEEE 29119-3.
4.2 Mapping of agile practices to ISO/IEC/IEEE 29119-2 test processes
4.2.1 Overview
This subclause demonstrates how the agile practices and artefacts listed in Table 1 map to the test
processes defined in ISO/IEC/IEEE 29119-2. Each mapping is presented in Tables 2 to 27.
2 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 29119-6:2021(E)
4.2.2 Acceptance criteria
Acceptance criteria are the conditions that a user story needs to satisfy for it to be considered "done"
(e.g. accepted by the product owner, customer, user or other stakeholders).
Table 2 — Mapping to ISO/IEC/IEEE 29119-2
Agile concept ISO/IEC/IEEE 29119-2:— Mapping details
clause
Acceptance criteria 8.2.4.2 Create test model Acceptance criteria would be created as a test model that
lists atomic requirements to be met before a user story can
be accepted as “done.”
4.2.3 Acceptance test-driven development (ATDD)
Acceptance test-driven development (ATDD) is a test-first approach whereby an agile team creates
acceptance tests, to verify that acceptance criteria of each user story are met, before the code that
passes those tests is written. ATDD is a form of test-driven development (TDD) at the acceptance testing
level.
Table 3 — Mapping to ISO/IEC/IEEE 29119-2
Agile concept ISO/IEC/IEEE 29119-2:— Mapping Details
clause
Acceptance test-driven All clauses When conducting ATDD, all clauses of ISO/IEC/IEEE 29119-
development 2 apply. The requirement to conduct ATDD can be included
in the test policy, and the chosen approach to ATDD would
be described in detail in the organizational test practices.
The requirement to use ATDD on a given product would be
mentioned in the test plan for that product. Tests can be
designed and executed under the test design and execution
process, and the environment and test data requirements
would be covered under the environment and data man-
agement process. Testing can be monitored, controlled and
reported on under the monitor and control activity. Defects
detected during testing can be raised under the incident
reporting process. Once testing is complete, assets can be
archived, and the outcomes of testing reported, under the
test completion process.
4.2.4 Amplify learning
Amplify learning is a concept of creating a team environment that encourages learning through various
approaches including through trial and error (i.e. accepting and learning from failure), highlighting
the fact that systems development is a continual learning process. Although this can be supported
by implementing ISO/IEC/IEEE 29119-2 iteratively (which is supported by the standard), there is no
specific concept in the standard that maps to this.
4.2.5 Backlog management
It is common for all members of the agile team to regularly review user stories, including testers. This
can include reviewing acceptance criteria to ensure they are complete and testable. Backlog reviews
are also referred to as "backlog maintenance" and "backlog refinement." During backlog management,
it is common for testers to review the backlog from a testing perspective, to estimate testing effort for
each user story and to prioritise testing efforts on each user story.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 9 ----------------------
ISO/IEC TR 29119-6:2021(E)
Table 4 — Mapping to ISO/IEC/IEEE 29119-2
Agile concept ISO/IEC/IEEE 29119-2:— Mapping details
clause
Backlog management 8.2.4.2 Create test model Acceptance criteria would be created as a test model that
lists atomic requirements to be met before a user story can
be accepted as “done.”
7.2.4.4 Identify and ana- Project and product risks can be considered during user
lyse risks story prioritization, would be identified via the identify and
analyse risks activity.
7.2.4.8 Record test plan Test estimates are refined during each iteration (e.g. during
> task a) iteration planning or backlog refinement sessions) via the
record test plan activity, task a).
8.2 Test design and im- The priority of each user story would be used to prioritize
plementation process: test
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.