EuroSTAR

Software Testing

Community

Playing Around with Risks

by Jurgen Cleuren

Situational Leadership
Styles on Test Approaches

EuroSTAR

by Wim Decoutere &

Michael Pilaeten

In this special edition EuroSTAR eBook, you will find two papers presented
at the 19th annual EuroSTAR Software Testing Conference, which took
place from 21 24 November 2011 in Manchester.

Special Edition EuroSTAR eBook:

Contents
1. Playing Around with Risks
Introduction

Texas Holdem Poker

Backgammon

Monopoly

Conclusions

References and further reading

10

Biography

10

2. Situational Leadership Styles on Test Approaches

PAGE

Mapping your Test Approach onto Leadership Styles

11

1. Introduction

11

2. Kolbs Theory

11

3. Hersey and Blanchards Theory

14

4. Kolb & Hersey and Blanchard

16

5. References

17

Biographies

18

w w w. e u ro s t a rc o n f e re n c e s . c o m

Special Edition EuroSTAR eBook: Playing Around With Risks

Playing Around with Risks

by Jurgen Cleuren

PAGE

Introduction

Dealing with risks is not something that

is exclusive for the testing world. Other
business segments also have their way of
doing risks management. A trader on Wall
Street for example, or a Fireman, who is
about to enter a building in flames. Dealing
with risks is even not only something
professionals do; some people do it for fun.
They play serious or less serious board or
card games where you need to handle risk
management. And every type has its own
risk management system. But there is a
common starting ground. You have a world
with incomplete information or parameters
that can change over time and you need
to find the best way of dealing with those
uncertainties. In this paper, we will look at
some games and their winning tactics in
order to translate these tactics into lessons
for our testing world. Maybe we can learn a
thing or two, in any case its worth the risk.

Texas Holdem
Poker

1. Rules of the game

Texas hold em is a variation of the standard
card game of poker. The game consists of
two cards being dealt face down to each
player and then five community cards being
placed face-up by the dealera series of
three (the flop) then two additional single
cards (the turn and the river), with players
having the option to check, bet, raise or fold
after each deal.

Betting may occur prior to the flop, on the

flop, on the turn, and on the river. The
interesting part is that the board changes 3
times. The first time is the biggest change.
On the flop, 3 community cards are turned
over. The turn shows another card and the
final change is made on the river with the
last card. In the end, the player with the
best 5 cards of those 7 cards (2 private + 5
community cards) wins the hand.

2. The analogy with risks in a

testing project
If we look at a general testing project, we
can also identify phases in which the risks
change. In the test preparation phase, a
Feature to Test tree and risk matrix is created
and all test items are given a priority based
on their risk. The priority is based on the
likelihood and the impact of test case. When
this process is done and the SUT (Software
under Test) is delivered, we start testing
based on this FTT tree (highest priority test
cases first, then the medium ones and finally
the ones with low priority, if time permits it).
After the first test run, defects are found and
the software needs fixing.
After the code correction, a new version is
delivered and the test process starts again.
This time however, we dont start testing
with the high priority test cases, but we start
testing with the test cases that failed in the
previous release. When those test cases
are done, we continue with the high priority

Special Edition EuroSTAR eBook: Playing Around With Risks

test cases, followed by the medium priority
ones and the low priority ones. If all goes
well, we should find fewer defects than in
the previous version. Some defects are still
expected to be found. The software is again
sent back to development for fixing.
A final version is delivered and the testing
starts following the same protocol as the
previous test run. First the defect retesting,
followed by high priority test cases, then the
medium priority test cases and finally the
low priorities test cases (when time permits
it). If all goes well, no more defects are found
and the software is successfully tested.

PAGE

As you can see, the SUT changes 3 times (the

same the board changes 3 times in poker).
The first change is the biggest. Most defects
are found in the first test run. In poker, the
board changes the most after the flop (since
3 cards are added to your hand of 2). After
that the board has 2 small changes (a single
card every time) which are almost the same
as the SUT.

3. What poker can teach us

a. Adapt the FFT tree and risk matrix after
each test run
In Poker, you have to re-evaluate your hand
and risks with each change of the board. If
you had 2 aces before the flop and you were
unbeatable, it doesnt mean that you are still
unbeatable after the flop has shown 2 Kings.
Your risk of losing has changed. And it will
change again after the turn and after the
river. Each time, you have to re-evaluate your
hand. Of course, your hand can also change
in a positive way. If you had a 5 and an Ace
and on the flop there are 2 5s, your chance
of winning has increased drastically and you
should adapt your play style accordingly.
In most test projects, the FTT tree or risk

matrix is never adapted after it is designed

and approved. Almost no one changes the
priority of risks after a first test run. I can
agree that the impact has not changed but
the likelihood has. That is why you test the
failed test cases first. The likelihood of finding
a defect there is increased since you know
that there was a defect there the last run. But
what about the other test cases? Is it really
true that there is still a high likelihood in test
cases of pieces of software that have been
tested last run and no defect has shown up?
Shouldnt the likelihood be adapted to low
if nothing has changed in the code at that
place? Shouldnt those test cases be moved
down in the execution priority list?
We got extra information from the last run
and I think we should use this information to
adapt our FTT tree and our risk matrix. If the
print module has no defects since the last
run and nothing has changed on that code,
all test cases should have priority Medium
at maximum (since Low likelihood and
High impact still give Medium as
outcome). On the other hand, all test cases
with defects should have priority Medium
at the minimum. We have to re-evaluate our
risk strategy after each test run, because we
got more information after each run.
b. A project needs justification after each
test run
In poker, you need to re-evaluate your risk
at certain points in the hand. These points
are every time you have to make a bet. At
these points either the board has changed
or someone else has made a bet and the pot
size has changed. You need to justify that
you are still in this hand. If you cannot justify
that you should still be in the hand, then you
need to fold your cards and wait for the next
hand. Its not always easy to make such a
decision, especially when you already put a
lot of money the pot. But you have to realize

Special Edition EuroSTAR eBook: Playing Around With Risks

that that money is already gone. It is not
your money anymore, it belongs to the pot.
The justification of staying in the hand can
never take into account how much money
you already invested in the hand. If someone
would asked you to bet money on a losing
hand, you would also say no. You should cut
your losses and move on the next hand.

PAGE

A project in general also needs justification

between the project phases. In most project
methodologies, like Prince2[1] for example,
this is done at the several project gates.
But when we look at poker, we should do a
justification every time the project changes,
or when we get more information about the
project. After each test run, we get more
information on the delivered software. If we
updated our risks after each test run, we
should have a more clear view on the project.
This is the perfect opportunity to check if
the project is still feasible. Justification in
the test phase of a project should be done
after each test run. If it is no longer justified
to continue the project, the project should
be closed. Again, earlier investments should
not be taken into account when making
this decision. You should never invest more
money in a failing project. Simply close the
project and move on to the next. Cut your
losses.
c. Ask the right questions!
There is a quote from the American author
Tony Robbins Successful people ask
better questions, and as a result, get better
answers.[2] In the gaming world, the most
frequently asked question is How did I lose
this game? And the most stories that are
told start with: This is how I won the game.
But if you look at the questions asked by the
world champions and the stories they tell
you will rarely find the word HOW in any
of them. The word they most use is WHY.

Why? Because the why question gives better

answers.
In poker, you can tell the bad and the good
players apart by the way they tell their bad
beat stories. The bad player will always tell
you how he lost and blame bad luck. The
good player will tell you how he lost and ask
you why it happened and what he could have
done differently. On the other hand, the why
question should also be answered when you
win a hand. This is needed in order to prevent
that you learn the wrong lesson when you
played badly but simply got lucky.
In projects, the most important question is
why things have happened. The how can
help in the search for the answer, but the
answers to the why questions will help the
most in understanding what went wrong
and how the process can be improved. Even
when nothing went wrong, the why question
can help you understanding what the critical
factors for success were.
d. Change your way of thinking
In poker, it is an important skill to figure out
what your opponent is holding and how he
will react to your actions. Sometimes you
want him to call and sometimes you want
him to fold. Knowing what your opponent will
do when he is holding certain cards can give
you much information. To figure this out, you
need to think like your opponent. And that is
where most players make a mistake. They
dont think like their opponents, they think
like themselves in their opponents situation.
What would I do when I have these or those
cards? This question is irrelevant. It gives
you the wrong information. You are not your
opponent. He is a different player with a
different style and his action will also differ
from yours given the same situation. What
you need to do is figure out how each of

Special Edition EuroSTAR eBook: Playing Around With Risks

your opponents think, and act accordingly.
If you are a team manager or test manager,
you need to motivate your team members
from time to time. Instead of thinking what
would motivate you in a certain situation,
lets say a new software fix comes at 5 pm
and needs to be tested ASAP, you should
think about what motivates them. You might
be motivated by the fact that if the software
is tested by the next day, you can present the
results to the project board. But your team
members might be more motivated by having
a free dinner or half a day off on Monday. You
will get better results by giving something
that motivates them than at convincing them
to give in to your motivation.
e. Be prepared to get lucky

PAGE

No one will deny that a poker player needs

luck from time to time. But the good players
take advantage of that luck. They calculate
the odds precisely and when they need to
get lucky, they try to take a big pot. The best
example is when you are holding 2 cards
of a suit and the third and the fourth are
on the flop. If a fifth card of that suit shows
up on the next 2 cards, youre winning the
pot. That chance is somewhere around
33%. But it will only be profitable if you have
enough money in the pot and when it doesnt
cost you a lot of money to play on to see the
next 2 cards. And that is only when a lot of
players are in the pot. So a good player will
only take these kinds of risks when he can
get enough out of it. If you hit your card and
there is not much money in the pot, you got
lucky but you didnt get much out of it. Its
like hitting your lottery numbers when you
didnt buy a ticket.
In most projects plannings, there is a
best case scenario, a worst case scenario
and something in between. Most project

managers take the scenario in between as

their realistic one and base their release
plannings on that scenario. But sometimes,
a best case scenario does happen. Suppose
you find few defects and you finish testing
2 weeks ahead of planning. You can only
gain time if your release planning and your
marketing planning are also prepared to
launch 2 weeks earlier. Otherwise you just
got lucky, but you cant take maximum
advantage of it.

Backgammon

1. Rules of the game

Backgammon is one of the oldest board
games for two players. The playing pieces
are moved according to the roll of dice,
and players win by removing all of their
pieces from the board. The pieces are called
Checkers

The game uses 2 6 sided dice to determine

how many spaces a checker or checkers
may be moved. For example, if you throw
6+3, you can choose to move one checker
9 spaces or you can choose to move 2
checkers, one checker 6 spaces and the
other 3. When you throw a double, there are

Special Edition EuroSTAR eBook: Playing Around With Risks

PAGE

special rules for moving the checkers, but

for the analogy, this is not important. In the
course of a move, a checker may land on
any point that is unoccupied or is occupied
only by a players own checkers. It may also
land on a point occupied by exactly one
opposing checker, or blot. In this case, the
blot has been hit, and is placed in the middle
of the board on the bar that divides the two
sides of the playing surface. A checker may
never land on a point occupied by two or
more opposing checkers; thus, no point
is ever occupied by checkers from both
players simultaneously. For our analogy it is
important that a checker can be removed by
our opponent and that it has to get back into
play at our starting position, thus setting us
back in developing our board and reaching
our goal. The farther the checker was on the
board, the bigger the setback is when it gets
captured.

2. The analogy with risks in a

testing project
In this analogy, our own checkers represent
the risks in our project. When we look at a
backgammon game in progress, there are
checker at the starting position, checkers in
the middle and checkers in the end position.
These checkers represent respectively the
low, medium and high risks in our project.
Losing a checker in the end position has
more impact on our game, than losing one
in the starting position. This is the same for
high and low risks.
The checkers of our opponent represent
causes. Each time when a cause hits a risk
that is not mitigated, we have to spend extra
resources to get the project back on track.
In backgammon, this is the same. Each time
one of our checkers is captured, we have to
spend one or more turns to bring the checker
back in play and at the same position as it
was before it got captured.

Since a checker can only gets captured

when it is standing alone on a point and a
risk can only gets hit by a cause when its
not mitigated, we consider a risk mitigated
when 2 or more checkers are standing on the
same point. A concrete example of a project
risk would be that the test manager gets ill.
A mitigation would be that the most senior
tester is backup test manager. So as long as
these persons are present at the same time
(checkers at the same point), there is no risk
that a cause (the flu) can hit the role of the
test manager.

3. What Backgammon can teach

us
At certain stages in a project, opportunities
may rise to remove the causes of certain
risks or do a responsive action to a certain
risk. When there is no visible disadvantage,
there is no doubt we should remove the
cause. But what if there is a disadvantage?
What if removing a cause means we are
putting something else at risk? What should
we do then? Should we play it safe or just go
for it and face the possible consequences?
For a concrete example, I go back to the test
manager and his backup. At a certain time in
the testing project, there may be a possibility
that the most senior tester is more useful
doing overtime in testing to get all test cases
tested each release. This means he cannot
do his backup job as test manager to the
fullest. Should he do it?
In the backgammon game there are situations
where you can capture an opponents checker,
but by doing this you leave one of your own
checkers at risk. When we look at the plays
of the world champions, they will always go
for it unless it involves one of their checkers
being alone in the final position on the board.
They always prefer to certainly remove a
cause and possibly face consequences over
defensive play. However, a checker that has

Special Edition EuroSTAR eBook: Playing Around With Risks

already completed his journey and is in the
end zone is protected at all costs. Its too
time and resource consuming to bring him
back from the beginning.
We can conclude that in these situations, we
should always go for the option to remove
a cause or take the responsive action, even
when it means putting something else at
risk, unless it means we are opening up a
high risk. High risks should stay mitigated at
all times. But if we have the choice to take a
responsive action to a risk or remove a cause
and therefore creating a low or medium risk,
we should always do it.

PAGE

The second thing is that checkers in the first

zone are never protected. World champions
prefer to move forward instead of wasting
time and resources on protecting these
checkers. If they are captured, the cost to
bring them back is minimal compared to the
moving forward of the other checkers. If we
take this thought back to risks in testing,
we can learn that low risks should not be
mitigated. Its more efficient to pay the
correction cost when the cause actually hits
the risk.

Monopoly

1. Rules of the game

A monopoly board consists of 40 spaces
and a player moves his avatar clockwise
around the board by using 2 dices. Players
take turns in order, with the initial player
determined by chance before the game. A
typical turn begins with the rolling of the dice
and advancing their piece clockwise around
the board the corresponding number of
squares.If the player lands on an unowned
property, whether street, railroad, or utility,

he can buy the property for its listed

purchase price. If he declines this purchase,
the property is auctioned off by the bank to
the highest bidder. If the property landed
on is already owned and unmortgaged, he
must pay the owner a given rent, the price
dependent on whether the property is part of
a set or its level of development. If a player
rolls doubles, he rolls again after completing
his turn. Three sets of doubles in a row,
however, land the player in jail. During his turn
a player can develop his property by buying
houses and hotels on it, and by doing this he
can increase the rent he receives when other
players land on it. A Player can only develop
property if he owns every property of that
color group. The prices of the property and
the rent he receives varies from color group
to color group. The ones closest to Start
are the cheapest, which means they are the
cheapest ones to obtain and to develop, but
they also give lowest rent. The ones who
are clockwise the farthest from start are the
most expensive ones (they cost most to
obtain and develop but give the highest rent
in the game).

2. The analogy with risks in a

testing project
In monopoly, every color group has likelihood

Special Edition EuroSTAR eBook: Playing Around With Risks

and an impact. The Orange Color group
for example has the highest likelihood to
land on. The Dark Blue color group has the
highest impact on the game. The rent you
will have to pay or receive is the highest of all
the color groups in the game. To determine
the priority of a risk in testing, we also use
the likelihood and the impact. Once we know
these 2 parameters, we use MOSCOW[6]

second highest likelihood of the game). The

Dark Blue color group is not completely
ignored, but is it rather a backup plan if the
first 2 color groups become unavailable.
This means that in monopoly, impact is less
important than likelihood. I checked with
other games that have the same setup in
likelihood and impact and the conclusion is
the same. Strategies that go for likelihood
rather than impact are the winning ones.
If we look at these results, we might
conclude that also for testing likelihood is
more important than impact. That means
that weight of likelihood should be more
than 50% and the weight of impact should
be less than 50%.

PAGE

9
or some other prioritization technique to
determine the priority of the risk. But in most
of the prioritization techniques the weight of
impact and likelihood are the same. But is
this correct?

3. What Monopoly can teach us

In monopoly, there are color groups that have
a medium impact and a high likelihood (the
Orange group) and there are color groups
that have a high impact and a medium
likelihood (the Dark Blue color group). If
we would use MOSCOW or some other
prioritization technique, it would seem that
both color groups are equally important.
But if we look at the winning strategies from
world champions, we get a different story.
The best strategy is to complete Orange
group as a first priority. Even trade down
if you must. [3][4] As a second priority try
to complete the Red color group (it has the

Conclusions

In conclusion we can summarize that these

3 games taught us some valuable lessons.
Poker taught us:
Adapt your risk matrix after each

test run
Justification is needed after each

test run
Ask better questions
Change your way of thinking
Be prepared to get lucky
Backgammon taught us:
Dont mitigate low priority risks
Always mitigate high priority risks
Always remove a cause, unless

you create a high priority risk
And finally Monopoly taught us:
Weight Impact <> Weight likelihood
Likelihood >>>> Impact
When we look at those 3 games we can
conclude that there can be many lessons

Special Edition EuroSTAR eBook: Playing Around With Risks

learned from the gaming world. These 3
games are only 3 games out of thousands
of games that deal with risk management.
Those games are played by millions of
people, so there a lot of ways dealing with risk
management, prioritization and mitigation.
Its definitely worth the time to look into these
strategies and try to find similarities that can
be used to improve our testing process.

PAGE

10

References and
Further Reading

[1] www.prince2.com
[2] Awaken the Giant Within, Tony Robbins
[3] http://www.amnesta.net/other/
monopoly/
[4]http://en.wikibooks.org/wiki/Monopoly/
Strategy
[5]www.pokerplace.co.uk/PokerRulesTexasHoldEm/
[6]http://en.wikipedia.org/wiki/MoSCoW_
Method
[7] The Poker MBA: Winning in Business No
Matter What Cards Youre Dealt, Dinkin &
Gitomer

Biography

Jurgen Cleuren is an
experienced Test Manager
for 7 years. He mostly
worked in large projects
within the Telecom world
and is hooked on risk
based strategies, both in his
professional as private life. When he is not
working or entertaining his wife, you can find
him gaming with his friends or playing cards
in Vegas.

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

Situational Leadership Styles on Test

Approaches by Wim Decoutere & Michael Pilaeten

PAGE

11

Mapping your
Test Approach
onto Leadership
Styles

David Kolb describes four learning styles:

experiment, discovery, observation and
planning. Hersey and Blanchard have
provided us a model to describe how we can
guide others. In this presentation, well dive
into both theories to find out why a certain
(test) approach might or might not work for
you, and if there exists a best management
approach for each test style. Can we draw
any lines between David Kolbs learning cycle
and the different test approaches? What is
the role of the test manager in all this? Can
we influence the testing style of our testers
by changing the way we guide them, using
Hersey and Blanchards model of leadership
and guiding? And what guidance fits which
testing approach best?

1. Introduction

In this paper on test approaches and

management styles, we use the models from
Kolb and Hersey & Blanchard to answer
the following questions: (1) Does there
exist a testing cycle, like Kolbs learning
cycle, including all test approaches and
thus indicating that none of them is best?
(2) Which management style fits which
testing approach best? (3) Can we draw
any lines between the learning cycle and
the different management styles? (4) Why
are the theories of Kolb and Blanchard &

Hersey useful for a test manager? We start

with a brief introduction on David Kolbs
theory on experiental learning, followed by
its application to the field of testing. We then
continue with Blanchard and Herseys theory
on management styles and apply it to the
world of testing. Finally we try to merge both
theories application to testing to extract
some conclusions.

2. Kolbs Theory

David Kolbs theory from 1984 on experiental

learning is considered as one of the most
influential theories in the field of educational
studies. This theory does not explain how
we learn in a school environment, but how
we learn from the things we do. Some
academics refuse to accept this theory
since it has never been formally proven.
We are aware of these objections, but we
prefer not to take a position in this academic
discussion. This theory being widely spread
and known to all working in the field, makes
us feel comfortable using this theory as a
basis for this paper.
In short, the theory states that all experiental
learning happens in a cycle. You are unaware
of this learning process and it doesnt matter
where you enter the cycle. Whenever we
perform a certain task or action, we might
discover something during the execution of
this task. What we discover will depend on
the situation and can be different for each
individual involved. We might find a problem
which blocks the further execution of the task,
we might notice that certain people dont
feel comfortable with how things happens,

etc. We gather some information to reflect

on what happened and try to generate ideas
on how we can explain, avoid or improve
the situation we came into. We put our ideas
into practice and discover how this affects
what we are doing, feeling, etc. The cycle
never ends. (See figure 1)

think about what actions to take and adapt

their methods. The trial-anderror group (B)
is Doing. They just do whatever comes to
their mind. Their last resort is the manual to
help them back on track. Those that need
an example (C) are Perceiving. They start
by gathering information from the manual,
a friend or even Youtube. Once they know
what to do, they start building the bookshelf.
From those that look for their tools and
create some room first (D) is said that theyre
Thinking or Planning. Nothing can stop
them once theyve set up their strategy. (See
figure 2).

When you busy trying to

(B) Doing

(C) Perceiving

figure out what set off a

certain defect by playing

Figure 1: Kolbs Learning Cycle

12

with different parameters,

you are considered to be

PAGE

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

2.1 Example
+ theory
in the Doing
phase.

s give an example
to make
things
clearer. Sayto
formake
example
that youve
bought the well known
Lets
give
an example
things
clearer.

(A) Applying

y bookshelf fromSay
Ikea. for
Once
youve opened
box, you
need to put
the pieces together.
example
thatthe
youve
bought
theallwell

ny people would start

on the Billy
first pagebookshelf
of the manual,from
folllowing
the manual
known
Ikea.
Oncestep-by-step (A).

(D) Thinking /
Planning

Figure 2: Kolbs Learning Cycle

ers know what toyouve

do and they
just try tothe
fit everything
together
opened
box, you
needbytotrial-and-error
put all without any help

guidance (B). Some people might read the manual completely before starting (C). Other may

the pieces together. Many people would start

2.2 Kolb in testing
on the first page of the manual,
folllowing

job (D). As you can see, every person has an own preferred style on how to start this task.
the manual step-by-step (A). Others know
Why is this theory so important? First of
ne of these approaches can be called best.
what to do and they just try to fit everything
all, it provides us with a framework on how
Why
is
this
theory
so
important? Firstlearning
of all, it provides
us with
a framework
on how experi
together by trial-and-error without any help
experiental
occurs.
More
important
important
to remember
that every
personhas
has an
preferred st
or guidance (B). Some people learning
might occurs.
read Moreto
remember
is thatis every
person
anown
own
ople that follow the manual step-by-step (A) are Applying because theyre following a plan.
learning new
things. Ifpreferred
we want people
to learn,
we shouldnew
give them
the opportunity
the manual completely before starting
(C).
style
of learning
things.
If we to ma
en they get stuck, they think about what actions to take and adapt their methods. The trial-andthings
in their own way,
providing
a perspective
fromwe
different
angles,
using
different appro
Other
may
the boards
andmind.
screws
people
to learn,
should
give
them
or group (B) is Doing.
They
just order
do whatever
comes to their
Theirand
last resortwant
is the manual
the
tools
while
making
thebyopportunity to master things in their own
elp them back onlook
track. for
Those
thatnecessary
need an example
(C) are
Perceiving.
They start
room ato
finish
theYoutube.
job (D).
way,do,providing
a perspective from different
hering informationenough
from the manual,
friend
or even
OnceAs
theyyou
know
they
Hereunder
we
will what
applytoKolbs
learning cycle to two completely different test approaches t
can see,
person
own
preferred
angles,
t building the bookshelf.
Fromevery
those that
look forhas
theiran
tools
and
some
(D) isusing different approaches.
thatcreate
both have
a room
similarfirst
backbone.
styleoron
how toNothing
start this
task.
None
these
d that theyre Thinking
Planning.
can stop
them
once of
theyve
set up their strategy.
approaches
can
be
called
best.
Hereunder we will apply Kolbs learning cycle
e figure 2)

to two completely different test approaches

People that follow the manual step-byto prove that both have a similar backbone.
This cycle applied to a V-model based testing process could lead to the following cycle. In
step (A) are Applying because theyre
Perceiving phase, you are most likely gathering the information and specifications needed
following a plan. When they get stuck, they

er the boards and screws and look for the necessary tools while making enough room to finish

the application. During the Planning phase, you are preparing the execution of your tests,

test scenarios, automated tests and a planning of the tests to be executed. While in Apply

mode, you are executing your test cases, running your automated tests, retesting fixed de

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

PAGE

13

2.2.1. The V-model

This cycle applied to a V-model based testing
process could lead to the following cycle. In
the Perceiving phase, you are most likely
gathering the information and specifications
needed to test the application. During
the Planning phase, you are preparing
the execution of your tests, creating test
scenarios, automated tests and a planning of
the tests to be executed. While in Applying
mode, you are executing your test cases,
running your automated tests, retesting fixed
defects and so on. When you busy with error
guessing or trying to figure out what set off
a certain defect by playing with different
parameters, you are considered to be in the
Doing phase. In most structured testing
processes, this phase is rather short due
to time and/or budget constraints. After all
these steps, you will gather some metrics to
be able to give a Go/NoGo advice. During
the evaluation of your test process, you
might come up with points of improvement
for a next test run or phase. You will use this
information in the planning of your next test
run, phase or project and so this cycle of
continuous improvement goes on.
2.2.2. Agile testing
In the Perceiving phase, an agile tester is
gathering his story points, which he will use
for a game of planning poker later on during
the Planning phase. This Planning phase
is also used for creating some automated
regression tests. The planned tests are run
together with the automated tests during the
Applying phase. Exploratory testing can
be done during the Doing phase. You may
discover that youve improved your testing
heuristics which you will put into practice
during the next run. Again the cycle goes
on.

2.3 Question 1
Does there exist a testing cycle, like Kolbs
learning cycle, including all test approaches
and thus indicating that none of them is
best?
To create this cycle, we start from Kolbs
original cycle, which goes from gathering
information over the creation of a concept or
a plan to the execution and evaluation of this
plan. For the ease of lecture, we ignore the
fact that you can enter the cycle at any step,
since this has no impact on our conclusions.
In the very first step, during the perceiving
phase, we are creating for ourselves an
image of the application under test. We try
to gather as much information as needed,
be it story points or formal specifications
and mockup screens or whatever we can
get our hands upon. In the next step, the
Planning phase, we prepare and plan our
test run. This can be done by a game of
planning poker, by a formal test plan which
little people will actually read, by creating
the automated (regression) tests needed,
etc... Once this is done, we will execute the
tests weve foreseen in our test plan, run the
automated test set or do whatever weve
planned to do during the Apply phase.
Defects will be logged, fixed and retested,
reports created, read and discussed. In the
next step, the Do phase, we will experiment
with the application, hunting for defect, using
our skills and knowledge to find those tricky
defects that make our day as a tester. This
step is followed by the phase we started
from. During the Perceiving phase, we
will evaluate our test metrics, secure our
experiences and newly gained heuristics and
so on.
It seems easy to conclude that Structured
testing is described by the Planning and
Applying phase, that Exploratory testing

Professor Paul Hersey and leadership expert Ken Blanchard came up with their theory

situational leadership in 1970. Even though this theory is over 40 years old, it still hasn
its power. According
to their Styles
theory someones
style is characterized by the
Special Edition EuroSTAR eBook: Situational
Leadership
on Testleadership
Approaches

task behavior and relationship behavior provided by the leader. The more focus you pu

and the outcome, the more task oriented you are. The importance of a good relation be

Relationship focus

covered by your relation behavior. Task and

covers the Do phase and that Agile is more
and your team members is covered by your relation behavior. Task and relation behav
relation behavior are no opposites. In figure 3
about the Do and Perceive phase.
opposites. In figure 3 both characteristics are placed in a matrix.
both characteristics are placed in a matrix.
We advise not to make this conclusion
since we believe its better to say that every
test approach follows the same cycle. In a
structured waterfall or V-model based testing
process, we have (preferably) a lessonslearnt step and an exploratory tester will
use his knowledge to improve his testing
heuristics over and over again while an agile
tester still needs his regression tests and
planning, to avoid doing useless work.
Our first conclusion is that we should and
could not put the different test approaches
in a certain order, neither can we conclude
that one of them is better.

PAGE

14

Task focus

Figure 3: Hersey & Blanchards

Situational Leadership Styles

Based on this 2x2 matrix, they identified four

different leadership styles.
Our second conclusion is that even
1. Telling (Directing): The manager takes all
though agile and structured testing seem
the Styles
decisions
and tells his people by
different, they
all follow the same cycle,
6
Situational Leadership
on Test Approaches
one-way communication what to do and
implying that the process of perceiving,
how to do it. This is my solution
planning, applying and doing is the basis
2. Selling (Coaching): The manager uses
for each approach.
two-way communication, allowing his
people to come with ideas and
suggestions. The final decision is still
taken by the manager though. This is
my proposal
3. Participating (Supporting): The manager
still participates in discussions to guide
his people into taking a shared decision.
Professor Paul Hersey and leadership
What is your proposal?
expert Ken Blanchard came up with their
4. Delegating: Responsibility is given
theory on situational leadership in 1970.
completely to the followers. The
Even though this theory is over 40 years old,
manager trusts completely on the skills
it still hasnt lost any of its power. According
and motivation of his people. Can you
to their theory someones leadership style is
solve this please?
characterized by the amount of task behavior
and relationship behavior provided by the
Hersey and Blanchard state that none of
leader. The more focus you put on the task
these four styles can be called best. Dont get
and the outcome, the more task oriented
tricked into believing that instruction and thus
you are. The importance of a good relation
telling people what to do, should be avoided,
between you and your team members is
even though most people dont likes to be

3. Hersey and
Blanchards
Theory

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

told what to do all the time. Every manager
has an own preferred management style. To
be a good manager, they should be able to
adapt their leadership style depending on
the situation. This situation is determined by
the task that should be done but also by the
motivation and the skills of the people that
should execute the task. A certain individual
may benefit more from one approach than
his coworkers, whom may need a different
approach. In another situation, that same
person may need yet another approach so
flexibility in your management approach is
required.

PAGE

15

People who dont have the correct skills (yet)

and are not motivated or unsure about their
own abilities benefit the most from being
told what to do. People that have some
skills but are not that motivated need to be
convinced that the bosss way, is the best
way. Those that have the skills but dont feel
comfortable yet using them, should be given
the opportunity to show themselves under
the bosss wings. Those that are confident
and have the necessary skills can be trusted
with any of the assigned tasks.

3.1. Hersey and Blanchard in

testing
If we apply this theory to the world of testing,
we can say that instruction works fine for
inexperienced testers or offshore testers on
which you have little direct control. The test
manager plans the entire project and does a
close follow-up by using his dashboard full
of metrics. When there is little time to test,
like for emergency updates and hotfixes,
and the team does not have the required
experience, its better when someone
takes the lead in getting the job done in the
available timeframe, telling everyone what to
do.

When the test manager needs to convince

the project manager of his test plan, hes
obviously trying to Sell his work. When
resources are small, the manager may need to
Sell his priorities to his team members. UAT
testing, second, third and further releases
and a more experienced testing team benefit
more from a Selling approach.
Sprint planning meetings or team evaluations
on how the testing process can be improved
are good examples of a Participating style.
If you, as a test manager, are new in an
already existing team, this style might also
work for you to get to know the team and
the application.
Delegation works best for an testing team
with senior experience or when the testing
task is clear to the person(s) that needs to
execute it. It might frustrate an experienced
tester if you would hold him by the hand,
impacting your personal relation which
could end with lesser results. When you
are overwhelmed with projects you need
to follow-up, delegation will be the style
youll need to use, to keep your head above
water.

3.2. Question 2
Which management style fits which testing
approach best?
Why not map some testing approaches
onto the scheme Hersey and Blanchard
provided? Structured testing seems to be
more formal, so maybe the focus should
be put on task behavior meaning that the
Telling and Selling strategies seem a good
fit. Agile and exploratory testing seem less
formal thus maybe these strategies should
not be applied and Participating and
Delegation seem better. But how do you
assist your agile newbies? What about your

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

can combine both theories. In table 1 both
theories are compared to each other.

experienced testers in a structured testing

environment? As already mentioned, there
is no ideal strategy that works each time for
every person. You need to be flexible with
your management approach, depending on
the who, what, when, where and how of your
testing team.
Our third conclusion is that there exists
no one-on-one mapping of test and
management approaches. You should
modify your leadership style depending
onthe situation. What worked once, might
not work a second time.

4. Kolb & Hersey

and Blanchard

Both theories are situation and task

dependent. Every individual has an own
preferred learning style and management
approach, be it as a teacher/manager or
as a student/team member and there exist
no fixed starting points nor best practices.
The only difference is the way these models
should be applied. In the learning cycle you
will pass through each step, even if its for
a split second, before you can go to the
next step. You cannot skip a step. For the
leadership approaches, you can jump across
the matrix and theres no order you have to
follow.

4.1. Question 3

Having explained both theories and having them applied to the testing domain, it might become

PAGE

16

Can we draw any lines between the learning

Having explained both theories and having
interesting to explore if we can combine both theories.
table
1 both
theories
are compared
to
cycleInand
the
different
management
styles?
them applied to the testing domain, it
each other.
might become interesting to explore if we
It should be clear by now that mapping test
Kolb

Hersey and Blanchard

Theory on learning/mastering new things

Theory on management styles

(self-improvement)

(task and or team-improvement)

Cyclic

Flexible use

Individual perspective

Manager perspective
Every person has an own preferred style
No fixed starting point
No approach is best
Job/task (situation) dependant
Table 1: Kolb compared to Hersey and Blanchard

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

management approaches to the different
steps in the testing cycle has no use. Weve
already proven that we cannot map any
test approaches on either one of them.
Management approaches should be applied
flexible in contrast with the learning cycle
which cannot be interrupted.
Our fourth conclusion is thus that there is no
ideal management approach for each of the
different steps in the testing cycle.

4.2. Question 4
Why are these theories useful for a test
manager?

PAGE

17

Blanchard and Herseys theory states that

The most successful leaders are those that
adapt their leadership style to the maturity of
the individual or group they are attempting
to lead and A good leader develops the
competence and commitment of their
people so theyre self-motivated rather
than dependent on others for direction and
guidance. But how do you get there? The
answer lies in Kolbs theory: step by step.
Starting from your own personal style, you
can try to use a different approach on one or
more of your team members (experiment).
By evaluating (reflection) of the results of
your approach (discovery), you will plan your
next steps (planning) which you will assess
after putting it into practice and so on The
cycle grows as you master the necessary
skills. You will see your team members
benefit from the personalized approach,
which will result in better outcomes of your
project.
What other approaches are there to apply
to get more commitment from my team
members? Just keep in mind that everybody
has an own preferred style of testing and that
not everybody likes the same tasks. Appliers

will prefer executing existing test cases while

Planners might prefer to write automated
test cases, Doers might prefer exploratory
testing and Perceivers may love to create
a test scenario based on the requirements
or user stories. You will get the most out of
your team if everybody can do what he or
she is best in and by stimulating them to try
to enlarge their skill set step-by-step.
Our final conclusion is that you should be
aware of your own preferences and those
of your team members. Based on this
knowledge, you can adapt your approach to
improve the outcomes of your team. Theres
nothing wrong with trying something new, as
long as you dont forget to check for lessons
learnt.

5. References

1. Wikipedia on David Kolb (http://

en.wikipedia.org/wiki/David_A._Kolb)
2. Business Balls on Kolbs Learning
cycle (http://www.businessballs.com/
kolblearningstyles.htm)
3. Scouts en Gidsen Vlaanderen. Gilwell
Reader. Antwerp, 2009
4. Wikipedia on Hersey and Blanchard
(http://en.wikipedia.org/wiki/Hersey
Blanchard_situational_theory)
5. Hersey, P. and Blanchard, K. H. (1977).
Management of Organizational Behavior
3rd Edition Utilizing Human Resources.
New Jersey/Prentice Hall.

Special Edition EuroSTAR eBook: Situational Leadership Styles on Test Approaches

Biographies

Wim
Decoutere
is
a
master
in
informatics
and an experienced test
coordinator. Wim is a
veteran youth instructor
with a passion about
learning theories and people
management. He is always actively seeking
opportunities to combine these into practice.
At his current assignment, hes making sure
all car parts work nicely together.

PAGE

18

Michael Pilaetens career in

testing began 7 years ago
when, after graduating as
an IT specialist, he found
himself challenged by the
other side working on
getting the defects out of
the system. Today, he is still bug-bitten
and is a very active test consultant with a
strong focus on the people aspect within
testing teams and how to improve his and
their performance, motivation and skill.

05 08 November 2012 | RAI Amsterdam

The EuroSTAR Conference
attracts testers from
around the globe who
come to learn, network &
discuss all things testing.
Attendees experience

intensive tutorials, track

sessions & inspirational
keynote speakers, & can
visit Europes largest
Software Testing
Exhibition. Return to
the office inspired,
motivated, and
full of new ideas!

www.eurostarconferences.com

Join the EuroSTAR Community

Access the latest testing news! Our Community strives to provide test
professionals with resources that prove beneficial to their day-to-day roles.
These resources include catalogues of free on-demand webinars, ebooks,
videos, presentations from past conferences and much more...

Follow us on Twitter @esconfs

Remember to use our hash tag #esconfs when tweeting
about EuroSTAR 2012!

Become a fan of EuroSTAR on Facebook

Join our LinkedIn Group

The EuroSTAR Blog

Contribute to the EuroSTAR Blog

Written by Testers for Testers

Check out our free Webinar Archive

Download our latest ebooks

w w w. e u r o s t a r c o n f e r e n c e s . c o m