TMAP Quality Engineering workshop on A4Q congress by Rik Marselis

© 2021 Sogeti Nederland B.V.. All rights reserved.
Academy
TMAP quality engineering
16 April 2021
Workshop

Academy
TMAP: Quality engineering
- Built-in quality & VOICE model
- Quality engineering & cross-functional teams
- Unit testing, mutation testing and path testing
Three-hour workshop based on the TMAP certification scheme
Presented by: Rik Marselis – Principal Quality Consultant
Friday 16 April 2021 14:00 – 17:15 (including 2 short breaks)
TMAP: the body of knowledge for
quality engineering in IT delivery

3
This workshop is based on training material
from the TMAP certification scheme.
Created by
Exam provider
There are local training providers in multiple countries.
Agenda:
- built-in quality, the VOICE model and quality engineering topics
- code coverage types for unit testing and mutation testing
- path testing
+ 17:15 end (we will have breaks at logical moments in the workshop)
At the end 3 people will win a free download of the ePub of our book➔
Welcome to this workshop!!
Bookshop:
www.ict-books.com
(or on your own bookshop e.g.
amazon.nl or bol.com)

4
Amstelveen
Where are you from? ➔ put your country & city in the chatbox

5
Rik Marselis
Principal Quality Consultant
2007 2012 2012
2008 2014
2009
2018
1980 2020

6
Built-in quality and VOICE model

7
Challenges of today’s high-performance IT delivery
The business demands:
• Deliver business value
• Deliver quality at speed
The team challenges are:
• Quality engineering is everyone's responsibility
• QA & testing is integrated in process and people
The focus is:
• Organize high-performing cross-functional teams (you build it, you run it!)
• Automate everything
Using
AI ?

8
Waterfall V-model Scrum DevOps Demand-Supply SAFe®

9
High-performance IT delivery
Definition:
High-performance IT delivery is an approach that enables cross-functional teams to continuously
improve the products, processes and people that are required to deliver value to the end users.
To achieve this continuous improvement quality must be built-in in not only the product but also
in the process (activities) and the people (individuals and the team as a whole).
Quality
Product People
Process

10
Built-in quality
Built-in quality is one of the key principles in the Lean approach.
Built-in quality, continuously improved, leads to right-first-time, and
where the outcome of the process meets the expectation: fit-for-purpose.
Quality of the product is strongly linked to the quality of the delivery
process and the people.
Any deviation of the expected product quality should lead to
improvement,
not just fixing the fault
but also changing the process and people
to prevent such faults from occurring again.
Source of picture: book “The PointZERO vision” 2012

11
Continuous quality engineering is a team responsibility
Quality engineering needs many activities to take place.
TMAP defines the QA & Testing topics to group all quality engineering activities.
These topics should be applied by all cross-functional (such as Agile or DevOps) team members.
Definition:
Quality Engineering is about team members and their stakeholders taking joint responsibility to
continuously deliver IT systems with the right quality at the right moment to the businesspeople
and their customers. It is a principle of software engineering concerned with applying quality
measures to assure built-in quality.

12
Quality engineering topics
Aimed at: orchestrating, arranging, planning,
preparing and controlling
Focus of multiple teams.
Aimed at: the operational QA & testing activities
Mainly focused on the scope of one team. Note: The division in topics is not black-and-white, some
topics may be relevant for both groups, but the emphasize
is on one or the other.

13
Put your ideas in the chatbox
Fundamental
DevOps
activities
How would you map the Quality engineering topics to DevOps?
Organizing
topics
Performing
topics

14
Business value
Organizations want to deliver business value to their customers.
Today’s organizations expect that their IT systems will enable them to generate business value.
So first the organization must be clear what business value they pursue.
This may be financial value but also value in any other quantitative or qualitative way.
The focus on business value helps people remember that IT delivery itself is not the goal.

15
Objectives
To support the business delivery there is IT delivery.
How the pursued value can be achieved is detailed in objectives that drive IT delivery.

16
Indicators
Indicators define a way to get insight into specific objectives.
Measuring these indicators is done by testing and other quality and value measuring activities.

17
Confidence in pursued value
Measuring the indicators results in information based on which the people involved can form an
opinion and determine to what extent they are confident that the pursued value can be achieved.

18
Experience the real value
When the people involved have enough confidence, they can decide to start using the (new or
changed) (parts of) the IT system.
The organization (the users and/or their customers) can now experience the real value.

19
Value improvement loop
Based on the experience of the real value the people involved will get new ideas to further
improve the business value which results in the value improvement loop of the VOICE model.

20
Supply information
based on
measuring indicators
The VOICE model for delivering business value
Measuring indicators
=
(mainly) Testing

21
The VOICE model relates to any IT delivery model.
The VOICE model is used to structure the work that
the team must do.
Quality engineering is one of the many task-groups
that need to be structured.
The use of the VOICE model is not limited to
structuring quality engineering, but is it not fully
worked out to all other task-groups.

22
Translating Business Value to IT delivery objectives
The defined business value is the starting point for quality assurance and testing. It's important to
understand the purpose of an IT system and how to create maintain it. Therefor there must be
quantifiable objectives with an adequate level of detail.
high quality is not necessarily high value

23
Exercise
What indicator(s) would you use in your current project/organization
to measure if you are reaching the IT-objectives
for the pursued Business-Value?
Put your answer in the chatbox

24
This is section 4.1 of the book “Quality for DevOps teams”

25
Unit testing and mutation testing

26
Code coverage for unit testing

27
Code coverage
Code coverage indicates what part of the code is being tested
Code coverage is measured while running tests (manual check = labour-intensive!)
Degree of code coverage depends on the type of coverage you want to achieve:
1. Line Coverage every line of code is executed
2. Statement Coverage every statement in the code is executed
3. Decision Coverage all possible conditional branches are tested
4. Branch coverage all possible branches (conditional and unconditional) are tested
5. Path coverage every path or path combination in a flow is tested
Worst coverage
Best coverage

28
Code coverage – Line coverage
Process-oriented
• Every line is exercised
• Not every statement is necessarily exercised
Testdata
nop = 1
lop = 250
Result
100% line coverage
Although MOVE lop TO lsp is not exercised the line counts
Application code
DECLARE nop NUMERIC
DECLARE lop NUMERIC
DECLARE lsp NUMERIC
READ nop FROM input-screen
MOVE 250 TO lsp
DO nop TIMES
READ lop FROM input-screen
IF lop < lsp THEN MOVE lop TO lsp ENDIF
ENDDO

29
Code coverage – Statement coverage
Process-oriented
• Every statement is exercised
• Not every outcome is necessarily tested
Testdata
nop = 1
lop = 110
Result
100% statement coverage
An IF-statement has a true and false outcome.
But only the true is exercised
Application code
DECLARE nop NUMERIC
DECLARE lop NUMERIC
DECLARE lsp NUMERIC
MOVE 250 TO lsp
DO nop TIMES
ENDDO

30
Code coverage – Decision/Branch coverage
Condition-oriented
The two are very similar, Branch coverage is typically for low level languages
• Every outcome is tested
• Not every path is necessarily tested
Testdata
nop = 2
lop = 110 (test case 1)
lop = 150 (test case 2)
Result
100% decision/branch coverage by running 2 test cases
Application code
DECLARE nop NUMERIC
DECLARE lop NUMERIC
DECLARE lsp NUMERIC
MOVE 250 TO lsp
DO nop TIMES
ENDDO

31
Code coverage – Path coverage
Process-oriented
• Every outcome is tested
• Every path is tested
Every path or combination of paths in the flow are tested.
Path coverage with test depth level-1 all decision-outcomes are tested at least once.
Path coverage with test depth level-2 some decision-outcomes are tested multiple times.
Path coverage gives the best coverage!
(and therefore later in this workshop we will practice with path testing ☺)

32
Code coverage – Final remarks
Advanced coverage types
• Conditional Decision Coverage
• Modified Conditional Decision Coverage
• Multiple Condition Coverage
➔ More information on tmap.net
High code coverage ≠ meaningful testing!
Always check if actual result meets expected result, otherwise a test is useless!

33
How many test cases would you need as a minimum to test this piece of pseudo-code?
Give:
• LC (line coverage)
• SC (statement coverage)
• DC (decision coverage)
As a bonus question:
Give the test case(s) you would use.
Put your answers in the chatbox
Exercise code coverage
READ VAR_A(numeric)
READ VAR_B(numeric)
IF VAR_B > 100 PRINT “B is big” ENDIF
UNTIL VAR_A > VAR_B
DO
ADD 1 TO VAR_A
END-DO
END-UNTIL

34
LC (line coverage)
Can be done with 1 test case:
A = 10
B = 10
The IF is executed (the are statements are not)
Until is executed
Do is executed
Add is executed
End-do is executed
End-until is executed
ALL lines are executed, but not all statements.
Solution line coverage
READ VAR_A(numeric)
READ VAR_B(numeric)
UNTIL VAR_A > VAR_B
DO
ADD 1 TO VAR_A
END-DO
END-UNTIL

35
SC (statement coverage)
Can be done with 1 test case:
A = 110
B = 110
The IF, Print & Endif statements are executed
Until is executed
Do is executed
Add is executed
End-do is executed
End-until is executed
ALL lines are executed, but not all statements.
Solution statement coverage
READ VAR_A(numeric)
READ VAR_B(numeric)
UNTIL VAR_A > VAR_B
DO
ADD 1 TO VAR_A
END-DO
END-UNTIL

36
DC (decision coverage)
Can be done with the 2 previously shown test
cases
A = 10 and A = 110
B = 10 and B = 110
These test cases execute both
outcomes of the decision.
See further explanation on
the previous slides.
Solution decision coverage
READ VAR_A(numeric)
READ VAR_B(numeric)
UNTIL VAR_A > VAR_B
DO
ADD 1 TO VAR_A
END-DO
END-UNTIL

37
Mutation testing - tests the tests

38
Mutation testing
At its core, mutation testing is the practice of executing a test, or a set of tests,
over many versions of the software under test—the so-called mutants.
Mutants are automated source code changes only during the test phase of development.
Mutation testing is a useful way to check if common faults would be detected by the test set and
this way helps to improve a test set in case the injected faults would not be detected.
Examples of Mutation testing tools are:
pitest (https://pitest.org/) for java
stryker (https://stryker-mutator.io/) for javascript

39
Examples of possible mutations of source code
Examples of mutations (this is not an exhaustive list)
<  <= +  -
>  >= /  *
&  | !=  ==
|  &
Advanced mutation testing tools can also change return values,
or remove conditions in conditional statements.
if(length > 120 & age > 18) {
accessAllowed();
} else if (length <= 140 | age == 20) {
extraValidation();
} else {
noAccess();
}
Example mutated code 2
if(length >= 120 & age > 18) {
accessAllowed();
extraValidation();
} else {
noAccess();
}
Example original code
if(length >= 120 | age > 18) {
accessAllowed();
extraValidation();
} else {
noAccess();
}
if(length >= 120 & age > 18) {
accessAllowed();
} else if (length <= 140 | age != 20) {
extraValidation();
} else {
noAccess();
}

40
Mutation testing in Action
Original code
IF length >= 120
THEN MOVE “admitted” TO status
ELSE MOVE ”not admitted” TO status
ENDIF
Testcases – Using boundary value analysis
TC1: length = 119 -> Expected outcome “not admitted”
TC2: length = 120 -> Expected outcome “admitted”
Code - Mutation 1
IF length > 120
ENDIF
Testcases
TC2: length = 120 -> Expected outcome “admitted” -> FAIL
Code – Mutation 2
IF length = 120
ENDIF
Which test case would catch the
mutant?

41
Mutation testing in Action
Original code
IF length >= 120
ENDIF
Code - Mutation 3
IF length < 120
ENDIF
Testcases
TC1: length = 119 -> Expected outcome “not admitted” -> FAIL
Code – Mutation 4
IF length != 119
ENDIF
Which test case would catch the
mutant?

42
For this piece of pseudo-code we have the following test cases:
B = 100, expected result “no print”
B = 101, expected result “B is big”
What mutation can you do in the code
that would not be found with these 2 testcases?
Put your answers in the chatbox
Exercise Mutation testing
READ VAR_B(numeric)
IF VAR_B > 100
PRINT “B is big”
ENDIF

43
We need the extra test case:
Solution: Mutant 1
READ VAR_B(numeric)
IF VAR_B != 100
ENDIF

44
We need the extra test case:
The total of 4 test cases is known as “4-value Boundary Value Analysis”
Solution: Mutant 2
READ VAR_B(numeric)
IF VAR_B = 101
ENDIF

45
Test design and Path testing

46
Test design – Introduction

47
Test approaches: experience- and coverage-based

48
Experience-based testing approaches
Contribution of a large group of people with
many different skills, insights, insights and
experiences.
Testing based on a charter, using test ideas and log.
Is done in pairs (2 people) or mob (whole team)
A largely intuitive and ad hoc approach to testing → unstructured
Relevant experience brought together.
Can be used separately or as a tool in another approach.
Checklists
Error guessing
Exploratory
testing
e.g. mob testing
Crowd
testing
Experience-
based
testing
Checklist-based testing
Crowd testing
Error guessing
Exploratory testing

49
Experience-based testing approaches work iteratively

50
Coverage-based testing ➔ up-front structured test design
This figure shows how test design is related to the test basis (pursued value, requirements and
risks) and that it results in test situations and/or test cases and test data which is combined in
test scenarios and test scripts.

51
Coverage-based testing with test design techniques
A test design technique is a standardized method of deriving test cases from a specific test basis
that will achieve a certain coverage. Applying a test design technique results in test situations,
logical test cases and/or physical test cases.
Our investigation has shown that there are about 25 to 30 test design techniques in literature.
All test design techniques can be categorized in the four coverage groups mentioned below.
In this training course we will practice with at least one technique for each group.
Keep in mind that you don’t have to
know all existing test design
techniques.
Knowing a few techniques for each
coverage group makes that with just
about 8 techniques you can handle
any testing challenge.

52
Condition-oriented test design – overview of test design techniques
Testing of a program flow
Test individual decision points with multiple conditions
Test multiple decision points that together form a process
(this brings higher coverage than path testing)
Test all combinations of all conditions (regardsless of
decision points)

53
Condition-oriented test design
These coverage types all
can be applied to each of
the test design techniques
on the left.
In this training course we
will use the Decision Table
test design technique

54
Data-oriented test design – overview of test design techniques
Uses the classes of a data item (= parameter) to identify
what to test.
Uses the boundaries between classes of data items to
identify what to test.
Combines values for multiple data items in test cases.
Uses the Creation, Retrieval, Update and Deletion (CRUD)
of data items to create tests.
Uses the way data flows through an IT system to create
tests.

55
Appearance-oriented test design – overview of test design techniques
Testing the syntax of e.g. user interface
Performance testing based on a model of the load
Test multiple versions of software on different
audiences
Specifically focus on how a system can be
misused (by mistake) or abused (on purpose)
There are many non-functional quality
characteristics for which techniques exist.

56
Process-oriented test design
➔ Path testing

57
Process-oriented testing – overview of test design techniques
Tests transitions between states.
Tests the path-combinations in a process flow or
algorithm (program flow)
Tests the flow in a computer program.

58
Link between code coverage types and the coverage groups

59
What coverage does path-testing give?
Path-testing ensures a certain level of coverage by measuring the
number of consecutive paths that has been covered.
Test-depth-level-1 means: all individual paths are covered by one or
more test cases.
Test-depth-level-2 means: all combinations of 2 consecutive paths have
been covered by one or more test cases.
Test-depth-level-n means: all combinations of n consecutive paths have
been covered by one or more test cases.
TDL-1 & TDL-2 are most used, we will explain these on the next slides.

60
What exactly is a path?
How many paths do you see?
How many test cases do you need
for 100% coverage?
Put your answer in the chatbox
Start
Do you like
testing?
End
Go to the testing theatre Go visit the magic boat ride
No
Yes
You are in
TestLand

61
A path is a line between one decision point and
another decision point,
or a line from the start to the first decision point,
or a line form the last decision point to the end.
To determine the paths,
first simplify the graph,
get rid of everything other than
decision points, lines, start and end.
Start
Do you like
testing?
End
Go to the testing theatre Go visit the magic boat ride
No
Yes
You are in
TestLand

62
So this flowchart has the following paths:
Start
Do you like
testing?
End
No
Yes
1
2
3

63
Testcases
To cover this simple flowchart 100%
We need two test cases:
TC1: path-1 – path-2
TC2: path-1 – path-3
Start
Do you like
testing?
End
No
Yes
1
2
3

64
Example: Entering the mini-scooter-bumper-cars (for age < 10 years)
Start
How many
drivers?
End
Enter age driver 1
Enter age driver 1
Enter age driver 2
Is anyone
over 10
years?
No
Yes Find another driver that’s the
right age
Have fun riding the
mini-scooter-bumper-cars
one
two

65
Example: Entering the mini-scooter-bumper-cars (for age < 10 years)
How many test cases
would you need for
100% coverage of
this process?
(put answer in chatbox)
Different possibilities
for 100% coverage
Depending on the
“Test Depth Level”
Start
How many
drivers?
End
Enter age driver 1
Enter age driver 1
Enter age driver 2
Is anyone
over 10
years?
No
right age
Have fun riding the
one
two

66
Step 1: determine the paths
How many paths are
in this process flow?
Put your answer in
the chatbox
Start
How many
drivers?
End
Enter age driver 1
Enter age driver 1
Enter age driver 2
Is anyone
over 10
years?
No
right age
Have fun riding the
one
two

67
Step 1: determine the paths, simplify the chart
Start
How many
drivers?
End
Is anyone
over 10
years?
No
Yes
Let’s first simplify
the process flow,
only start, end, lines
and decision points.
How many paths are
one
two

68
Step 1: determine the paths, number them
And letter the decision points
A path starts at a decision point and
goes to the next decision point.
Or a path starts at a startpoint.
Or a path ends at an endpoint.
Start
A
End
B
No
Yes
Path
2
Path
4
Path
1
Path
3
Path
5
one
two
Note: Step 1 applies to TDL-1 and TDL-2

69
Step 2: determine the test situations
TDL-1: every path is a test situation.
First define the paths from start and
from each decision point:
Start: 1
A: 2, 3
B: 4, 5
Start
A
End
B
No
Yes
Path
2
Path
4
Path
1
Path
3
Path
5
one
two
Test
situations
Test
situations
Test
situations

70
Step 3: create test cases
TDL-1: every path is a test situation.
Create test cases by combining paths
from start and from each decision
point:
Start: 1
A: 2, 3
B: 4, 5
TC1: 1, 2, 4
TC2: 1, 3, 5
Start
A
End
B
No
Yes
Path
2
Path
4
Path
1
Path
3
Path
5
one
two

71
Introduction of the excel template
1
2, 3
4, 5
1, 2, 4
1, 3, 5

72
Step 2: determine the test situations
TDL-2: every combination of
incoming and outgoing path
is a test situation.
Make a table with 3 columns:
Dec.Pt. IN OUT Path-combinations
A: 1 2, 3 1-2, 1-3
B: 2, 3 4, 5 2-4, 2-5, 3-4, 3-5
Start
A
End
B
No
Yes
Path
2
Path
4
Path
1
Path
3
Path
5
one
two
Test
situations

73
Step 3: determine the test cases
TDL-2: Combine path-combinations
into test cases.
A: 1 2, 3 1-2 1-3
B: 2, 3 4, 5 2-4, 2-5, 3-4, 3-5
TC1: 1, 2, 4
TC2: 1, 2, 5
TC3: 1, 3, 4
TC4: 1, 3, 5
Start
A
End
B
No
Yes
Path
2
Path
4
Path
1
Path
3
Path
5
one
two

74
Introduction of the excel template
1 2, 3
4, 5
1, 2, 4
1, 3, 4
2, 3
1-2, 1-3
2-4,2-5,3-4,3-5
1, 2, 5
1, 3, 5

75
So: The the number of test cases depends on “Test Depth Level”
(= the number of consecutive paths that are tested.)
TDL-1:
TC1: 1, 2, 4
TC2: 1, 3, 5
TDL-2:
TC1: 1, 2, 4
TC2: 1, 2, 5
TC3: 1, 3, 4
TC4: 1, 3, 5
Start
How many
drivers?
End
Enter age driver 1
Enter age driver 1
Enter age driver 2
Is anyone
over 10
years?
No
right age
Have fun riding the
one
two

76
One coverage type
Two test design techniques
So we are talking about
“Path coverage”.
If you are testing a business
process, the technique used is the
Process Cycle Test.
Start
How many
drivers?
End
Enter age driver 1
Enter age driver 1
Enter age driver 2
Is anyone
over 10
years?
No
right age
Have fun riding the
one
two

77
One coverage type
Two test design techniques
So we are talking about
“Path coverage”.
If you are testing a business
process, the technique used is the
Process Cycle Test.
If you are testing a program flow,
the technique used is the
Algorithm Test.
But actually the technique is
exactly the same, the only
difference is the test basis.
Start
IF NR-PEOPLE
= 1
End
True
False
READ AGE-1
READ AGE-1
READ AGE-2
IF AGE-1 >
10 OR AGE-2
> 10
False
True
CALL subroutine-other-drivers
ENTER THE RIDE

78
Recap of the Process Cycle Test and Algorithm Test techniques
Step 1: Determine the paths
Simplify the chart by removing everything else than decision points, start, end and lines.
Number the paths and letter the decision points
Step 2: Determine the test situations
For TDL-1 ➔ list the paths and where they originate
For TDL-2 ➔ list the decision points, the INcoming and OUTgoing paths,
create path-combinations
Step 3: Combine the test situations into test cases
From start to end combine test situations into test cases
Tips:
Process Cycle Test is very well suited for preparing acceptance tests and end-to-end tests.
Algorithm Test is very well suited for preparing unit tests, TDL-1 also assures Decision Coverage.

79
Exercise path testing
➔ use the excel template
Determine the paths
and the test cases
for TDL-1 and TDL-2
Start
Decision A
End
Action 2
Action 3
Action 4
Decision B
No
Yes
Action 5
Action 6
two
three
Action 1
one

80
Solution path testing
Path numbers
1
4
2
3
5
6

81
Solution path testing TDL-1
Solution with
excel template
TDL-1
1
4
2
3
5
6

82
Solution path testing TDL-2
1
4
2
3
5
6

83
Now we add a loop in the flowchart
Step 1: determine the paths
How many paths are
Start
How many
drivers?
End
Enter age driver 1
Enter age driver 1
Enter age driver 2
Is anyone
over 10
years?
No
Yes
Have fun riding the
one
two

84
Step 1: determine the paths, simplify the chart Start
How many
drivers?
End
Is anyone
over 10
years?
No
Yes
Let’s first simplify
the process flow,
only start, end and
decision points.
How many paths are
one
two

85
Step 1: determine the paths Start
How many
drivers?
End
Is anyone
over 10
years?
No
Yes
There are 5 paths in
this process flow
How many test cases
do you need for 100%
coverage
TDL-1 ?
And TDL-2?
one
two
Path
2
Path
4
Path
1
Path
3
Path
5

86
Step 2 and 3:
determine test situations and test cases
Start
How many
drivers?
End
Is anyone
over 10
years?
No
Yes
one
two
Path
2
Path
4
Path
1
Path
3
Path
5
TDL-1: every path = test situation
First define the paths from start
and from each decision point:
Start: 1
A: 2, 3
B: 4, 5
The paths can be combined in one
test case:
TC1: 1,2,4,3,5

87
Step 2:
determine test situations
Start
How many
drivers?
End
Is anyone
over 10
years?
No
Yes
one
two
Path
2
Path
4
Path
1
Path
3
Path
5
TDL-2: every combination of
incoming and outgoing path
is a test situation.
Make a table with 3 columns:
A: 1,4 2,3 1-2, 1-3, 4-2, 4-3
B: 2,3 4,5 2-4, 2-5, 3-4, 3-5

88
Step 3:
determine test cases
Start
How many
drivers?
End
Is anyone
over 10
years?
No
Yes
one
two
Path
2
Path
4
Path
1
Path
3
Path
5
TDL-2: Combine path-combinations
into test cases.
A: 1,4 2,3 1-2, 1-3, 4-2, 4-3
B: 2,3 4,5 2-4, 2-5, 3-4, 3-5
TC1: 1, 2, 5 (zero times through the loop)
TC2: 1, 3, 4, 2, 5 (one time through the loop)
Now we need to cover 2-4, 4-3 and 3-5
TC3: 1, 2, 4, 3, 5 (one time through the loop)
To improve your coverage (and confidence) do this:
TC3’: 1, 2, 4, 3, 4, 3, 5 (two times through the loop)

89
Recap of the Path testing
Step 1: Determine the paths
Simplify the chart by removing everything else than decision points and start & end lines.
Number the paths and letter the decision points
Step 2: Determine the test situations
For TDL-1 ➔ list the paths and where they originate
For TDL-2 ➔ list the decision points, the INcoming and OUTgoing paths,
create path-combinations
Step 3: Combine the test situations into test cases
From start to end combine test situations into test cases
When there’s a loop, for good confidence create test cases that go through it:
zero times (= not through the loop)
one time through the loop
multiple times (= 2 or more times through the loop)
For progression testing: create many different short test cases (easier investigation of anomalies)
For regression testing: create fewer longer test cases (easier execution)

90
Exercise path testing with loop
➔ use the excel template
Determine the paths
and the test cases
for TDL-1 and TDL-2
Start
Decision A
End
Action 2
Decision B
No
Yes
Action 3
two
one
Action 1

91
Solution path testing with loop
Path numbers
Start
Decision A
End
Decision B
No
Yes
two
one
1
2
3
4
5

92
Solution path testing with loop TDL-1
Start
Decision A
End
Decision B
No
Yes
two
one
1
2
3
4
5

93
Solution path testing with loop TDL-2
Start
Decision A
End
Decision B
No
Yes
two
one
1
2
3
4
5

94
Closing

95
TMAP training courses and certification scheme of
Exams provided by
TMAP: Quality
for cross-
functional teams
TMAP: High-
performance
quality
engineering
TMAP:
Organizing built-
in quality
at scale
Performing
people
3-day training course
including
exam of 30 questions
3-day training courses
with separate
exams of 40 questions
All people
involved in
cross-
functional
teams
Organizing
people
Do you want to learn more about TMAP?
https://pages.isqi.org/tmap-2020/
https://tmap.net/page/tmap-devops-teams
https://academy.sogeti.nl/2020-tmap

96
And visit the renewed
body of knowledge
on www.tmap.net
Who wins the ePub of my TMAP book?
and if you don’t win, find it on www.ict-books.com
or download the free preview-version on:
https://tmap.net/book/quality-devops-teams
Find the excel template for path testing also
on www.TMAP.net :
https://tmap.net/page/download-templates

97
About Sogeti
Learn more about us at
www.sogeti.com
This message contains information that may be privileged or
confidential and is the property of the Capgemini Group.
Copyright© 2018 Sogeti. All rights reserved.
Sogeti is a leading provider of technology and engineering services. Sogeti
delivers solutions that enable digital transformation and offers cutting-edge
expertise in Cloud, Cybersecurity, Digital Manufacturing, Digital Assurance
& Testing, and emerging technologies. Sogeti combines agility and speed of
implementation with strong technology supplier partnerships, world class
methodologies and its global delivery model, Rightshore®. Sogeti brings
together more than 25,000 professionals in 15 countries, based in over 100
locations in Europe, USA and India. Sogeti is a wholly-owned subsidiary of
Capgemini SE, listed on the Paris Stock Exchange.
Good luck with quality engineering !!!
Thank you for your participation
Contact me on: rik.Marselis@sogeti.com
Or on twitter: @rikmarselis

TMAP Quality Engineering workshop on A4Q congress by Rik Marselis

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to TMAP Quality Engineering workshop on A4Q congress by Rik Marselis

Similar to TMAP Quality Engineering workshop on A4Q congress by Rik Marselis (20)

More from Rik Marselis

More from Rik Marselis (20)

Recently uploaded

Recently uploaded (20)

TMAP Quality Engineering workshop on A4Q congress by Rik Marselis