Around the World with 80

Software Testers
Viv Richards
This book is for sale at
http://leanpub.com/AroundTheWorldWith80SoftwareTesters

This version was published on 2020-03-24

This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean Publishing is
the act of publishing an in-progress ebook using lightweight tools
and many iterations to get reader feedback, pivot until you have
the right book and build traction once you do.

This work is licensed under a Creative Commons

Attribution-NonCommercial-NoDerivatives 4.0 International
License
Tweet This Book!
Please help Viv Richards by spreading the word about this book
on Twitter!
The suggested tweet for this book is:
Reading Around the World with 80 Software Testers
https://leanpub.com/AroundTheWorldWith80SoftwareTesters
#80SoftwareTesters
The suggested hashtag for this book is #80SoftwareTesters.
Find out what other people are saying about the book by clicking
on this link to search for this hashtag on Twitter:
#80SoftwareTesters
Thank you to the amazing software testing community all around
the world who have contributed to and supported this book,
without you this simply would not exist.
Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Argentina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Big shots are also humans . . . . . . . . . . . . . . . . . . 3

Bulgaria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Keys to effectiveness as a software tester . . . . . . . . . 6

Canada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Know your simple tools . . . . . . . . . . . . . . . . . . . 10

England, UK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Take responsibility for our testing . . . . . . . . . . . . . 14
What I have learned (the hard way) in testing and in life 17

France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Testing is about sharing . . . . . . . . . . . . . . . . . . . 22

Germany . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Be the change you want to see . . . . . . . . . . . . . . . 26
Optimize for learning . . . . . . . . . . . . . . . . . . . . 30
Being lucky . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Gran Canaria, Spain . . . . . . . . . . . . . . . . . . . . . . . 42

Top testing tips . . . . . . . . . . . . . . . . . . . . . . . . 43

Hungary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
CONTENTS

Grow by helping others grow - like a badass. . . . . . . . 48

Lithuania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Power in authenticity: Being yourself is your superpower 52

Netherlands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
A glimmer of hope . . . . . . . . . . . . . . . . . . . . . . 56

New Caledonia . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Am I where I’m supposed to be? . . . . . . . . . . . . . . 61

New Zealand . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Learn through teaching . . . . . . . . . . . . . . . . . . . 65

Scotland, UK . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Don’t limit yourself - focus on growth . . . . . . . . . . . 71

Serbia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
#10yearschallenge - what I wish I knew before . . . . . . 75

South Africa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pushing your own boundaries! . . . . . . . . . . . . . . . 79

Sweden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Journey from dev to tester . . . . . . . . . . . . . . . . . . 83

Turkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
A drawing compass, a multi-sport athlete, and a multi-
skilled tester . . . . . . . . . . . . . . . . . . . . . . 88

United States of America . . . . . . . . . . . . . . . . . . . . 92

Improving & learning in small steps . . . . . . . . . . . . 93

Wales, UK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
You can do it! . . . . . . . . . . . . . . . . . . . . . . . . . 98
 Preface
Around the World with 80 Software Testers draws upon the knowl-
edge and experience from both experts and new voices from around
the world involved in software testing.
The contributions within this book are ordered alphabetically by
country. Neither each chapter nor country is ordered with the
intention that there is a natural flow throughout the book. This
is a book created both by and for the software testing community.
This book contains reflections and thoughts based on many peoples
own personal experiences, some of which you may agree with, and
others you may well not. There is no overarching narrative, this
book is for you to absorb, link what you read together, evaluating
it based upon your own meaning, knowledge and experience.
This book will continue to evolve. When new contributions are
received they will be reviewed, added to the book and then a new
version of this book will be published. This process will continue
until the book contains 80 software testers from all around the
world.
Thank you to everybody who took the time to contribute to this
book as well as give feedback on each of the released versions of
the book.
I hope you enjoy reading this book as much as I have bringing it all
together.
Argentina
Argentina 3

Big shots are also humans

Nadia Cavalleri - Argentina

Big shots are also humans

From the moment you decide to start working as a tester, you

should know that you have to train continuously. At the beginning
to learn the fundamental testing topics and then to follow the
innovations that the industry permanently keeps doing..
In both cases, to learn and to keep us updated, we usually do it by
reading books, articles, blogs or watching videos of people who are
benchmarks in the field.
Even though today there are many ways to interact with the au-
thors, this is still a one-way channel on which the author produces
and we consume those contents. We can agree or disagree with
those contents but there is not usually a close feedback with the
author beyond a comment on a blog, on You Tube or on a twitter
thread.
Argentina 4

As we start consuming those contents we find that there are people

who are points of reference in the matter: they write books, articles,
they are keynotes of international conferences and are respected by
the community. Just to mention a few of them, Janet Gregory, Lisa
Crispin and Michael Bolton could be good examples of what I want
to express.
When I started going to international conferences, I started meeting
these personalities. Bridging the gap, for me it was like meeting a
famous actor.
For those of us who are not extroverted, this situation can cause us
anxiety, fear, shame … We usually think How am I going to start a
conversation with this guru? Why would he/she spend time with
me? How do I personally tell him/her the idea that I had at that
time? With a tweet or a comment was much easier, but of course,
less valuable as any possibility of interaction is lost.
I must tell you that, after a conference on which I missed the
opportunity to speak to one of them, I told myself “this cannot
happen to me again”. And that was my motivation to get involved
in personal or group conversations with these personalities on the
next congresses I attended.
Surprisingly, I had all positive experiences. They were always very
open, willing to help, share knowledge and even learn from your
experience. From a distance, it could sound quite logical. After all,
we all go to congresses, among other things, to learn and to build a
professional network. So there is no reason for this not to happen.
In summary, my advice is not to be shy and feel free to interact with
TIP (Testing Important People) because you will learn a lot from
them, you will spend a good time and you will have an anecdote to
tell.
Bulgaria
Bulgaria 6

Keys to effectiveness as a software

tester

Ivo Dimitrov, Bulgaria

Keys to effectiveness as a software tester

People involved in testing need basic professional and social qual-
ifications such as:

• literacy,
• the ability to prepare and deliver written and verbal reports,
• the ability to communicate effectively,
• and so on.

Good communication
A tester must be frank enough to ask questions to find out what
needs to be done. A good tester can’t afford to be shy. They
Bulgaria 7

must be able to interact even with unknown persons, frankly &

pleasingly. Communication here refers to a dialog or both way
communications. A good tester need not be talkative, but must have
a great stamina to be a good listener as well. During discussions
with others they should be able to capture all the requirements as to
what needs to be done, and should be able to extract all the project
requirements. This requires a great deal of listening skills.

Detail orientation and Perseverance

A good tester is the one who has a lot of perseverance & who
doesn’t give up. A successful tester is the one who develops an
attitude of proving that the system does not work. A a person who
remains hungry for bugs & doesn’t get satisfied after finding 3 or 4
bugs.
Sometimes the tester may be engaged in some boring / repetitive
task, while all of a sudden they can face great pressure to meet some
project related important deadline. Hence for a success in the career
as tester, the tester must be able to develop an attitude of a thorough
professional who doesn’t get moved under odd circumstances what
ever it may be.

Self-education
The software engineering field is relatively new (compared with
most other forms of engineering) and new technologies appear with
a speed that would astonish those not familiar with software.
Great software testers must have an ingrained propensity to be
ongoing learners and consistently spend part of every week, and
maybe even part of every day, dedicated to upgrading their skill
sets.
(the research was performed a couple years ago that suggested that
a software engineer’s “skill set half-life” is about 18 months —
Bulgaria 8

meaning that without a significant upgrade in skills, an engineer

will be obsolete and not hirable (for leading edge systems develop-
ment activities) in 36 months.)

Team Player

If a defect is found in software, the software author may see this

as criticism. Testers need to use tact and diplomacy when raising
defect reports. Defect reports need to be raised against the software,
not against the individual who made the mistake. The mistake may
be in the code written, or in one of the documents upon which the
code is based (requirement documents or system specification).
When we raise defects in a constructive way, bad feelings can be
avoided.
Software testing is only a small division of a larger part of the
organization and testers wanted to be able to understand this and
act accordingly. Testers will need to be able to work together with
other stakeholders in the best interest of the overall company.
The ability to see the larger picture of a company’s overall business
strategy. The ability to see the big picture enables a great software
tester to actively participate at a level higher than just an individual
contributor — instead of merely finding a Priority 2 / Severity 2
bug, a great software tester can identify strategic strengths and
weaknesses of a software system that can ultimately lead to a
business competitive advantage.
Canada
Canada 10

Know your simple tools

Janet Gregory, Canada

Know your simple tools

When I first started reading about testing fundamentals, I learned
some basic tools to help think about quality, prioritization and to
plan my testing.
I still find some of these tools useful to me, although I don’t
use them very often. These include pareto charts to see what the
highest value problem to solve is, fish bone (Ishikawa) diagrams so
show cause and effect, and control charts to see if the variance of
something is within pre-defined limits.
I want to focus on how I use three basic tools I use regularly which
I find are unknown to many new testers. They are:

1. Flow charts (data, process)

2. Relationship (context, state) diagrams
3. Affinity diagrams
Canada 11

Flow Charts

https://en.wikipedia.org/wiki/Flowchart
Process flow: My favorite way to visualize a new feature is using
a flow chart to map a feature especially when the whole team
is involved. Once you have it visualized, it is much easier to see
how to break it up into small testable stories. You start with the
simplest thing that could possibly work, and then add complexity
with each new story until you have the feature complete. Each of
these flows becomes scenarios you can test. (You can read more in
Agile Testing: A Practical Guide for Testers and Agile Teams)
Data flow: Another way to look at a story or feature is to examine
how the data flows. Where does it come from, where does it end
up, and how did it get there? Did it transform along the way? It
gives you clues about what kinds of data you might need, as well
as where to test.

Relationship Diagrams

There are many very specific types of diagrams that show relation-
ships between objects/entities. Here, I’ll talk about only two.
Context diagram: A high level context diagram shows the rela-
tionships and system interfaces within your application or system.
Does it talk to other systems, or to people or a database? Does
it interact with the cloud? What kinds of messages does it pass
between modules? Assumptions can be easily dispelled and lets the
team see the system as a whole.
State diagrams: This tool shows the different states of an object
and the transitions it makes to get from one state to another. What
triggers the change? These states and transitions are great places to
tests.
Canada 12

Affinity Diagrams

https://en.wikipedia.org/wiki/Affinity_diagram
There are many uses for this tool which is a mechanism for
categorization of ideas. Individuals write ideas or topics – one per
sticky note, and then put them on a wall or table and look for
patterns. For example, I use it during retrospectives to group “like”
ideas together to make it simpler to vote about which problem we
want to solve first. I also use it after brainstorming ideas during a
workshop to decide what is the most important topic.
Three other simple tools I still use, and are easy to learn but you
can read about them yourself are:

1. Truth tables¹
2. Decision trees²
3. Check list³

There are many other tools in my toolbox such as Ellen Gottesdi-

ener and Mary Gorman’s “7 Product Dimensions” or Matt Wynn’s
“Example Mapping”. But…. sometimes we forget the simple ones.
¹https://en.wikipedia.org/wiki/Truth_table
²https://en.wikipedia.org/wiki/Decision_tree
³https://en.wikipedia.org/wiki/Checklist
England, UK
England, UK 14

Take responsibility for our testing

Alan Richardson - England, UK

Take responsibility for our testing

A lesson that I wish I had learned earlier than any other in relation
to Software Testing. And which, when I learned it, I wish I had
embraced and enacted more fully and more quickly; was to take
responsibility for my approach to Testing.
When we don’t have our own experience to back us up, it is far
too easy for most of us to believe other people, and trust that they
know how to do things better than we do.
For example, when you are on a project and things aren’t going
well, and you are not convinced that the particular approach being
used is working. What do you do? Very often, we keep doing it
because the more experienced staff, or the people in charge, or the
book we are told is gospel, tell us that this is the ‘right’ way to do
it. But it feels wrong. The results we are getting are not what we
were told we would get.
England, UK 15

This is an important signal. Your observation that things are not as

they should be. Your gut feeling that “there has to be a better way”.
Pay attention to this signal, and take action.
But what can you do? You are part of a team. You are a junior
member. You don’t actually know what the better way is, you just
feel that there has to be a better way.
What can you do? You take responsibility for your part in the
process. You experiment with your part of the process until you get
an improved result. You read more widely to identify the solutions
that people put in place, rather than to learn the edicts that people
tell you.
On your Agile project, you don’t assume that because you are hold-
ing “3 Amigos” sessions, that everyone involved will have a shared
understanding of the story. Instead you take responsibility for your
part in the “3 Amigos” to ask questions, challenge all ambiguity,
clarify the limits, identify the gaps. Change your approach to your
involvement in the “3 Amigos”.
If you spot consistent things that go wrong, and you spot small
actions you can take that might help, then implement those small
actions, particularly those small actions which help you. Our aim
is not to fix everyone else’s process, our aim is to make the process
work better so that we can work better.
For example, if people say one thing in a “3 Amigos” but later
implement something else, or forget something that was agreed.
Then you might decide, after a “3 Amigos” session, to write down
your understanding of what was said. And this will help you. You
are not doing it to hold people to account. You are doing it so
that you don’t mis-remember something. You can use it for your
testing, and you can refer to it later if it seems that understanding
has diverged.
You will encounter resistance. People will tell you not to write
things down because you are “Agile”. People will tell you not to
England, UK 16

add it to the Story because it is more documentation that needs to

be maintained. Fine. Do it anyway. Track it in a light weight system
that boosts your work: create a set of subtasks to track your work
and make notes there, create a set of text files for each Story that
describe your testing. You are taking responsibility for your process,
not theirs.
In general terms. Look at what is going wrong. What small actions
can you experiment with, ensuring that they help you, rather than
provide more work. Communicate in terms of Actions and Results,
rather than “but we need to do it this way”.
Bruce Lee is quoted as saying “Research your own experience.
Absorb what is useful, reject what is useless, add what is essentially
your own.”
By taking responsibility for your Testing, you will act to improve
your experience of your environment, and as a side-effect, you will
change the environment around you.
England, UK 17

What I have learned (the hard way)

in testing and in life

Dorothy Graham - England, UK

What I have learned (the hard way) in

testing and in life

When Viv asked me to contribute to this book, he talked about

looking back over 5 years. What I’d like to do is to give you a few
of the lessons I have learned over the past 50 years!

Be open to the unexpected.

Like many people, I got into testing (and test automation) by

accident, hired in 1970 as a programmer at Bell Labs (USA) to write
a test execution program and a test results comparison program.
This was nothing like what I thought my life would be - I was
planning to be a secondary school Maths teacher, and decided to see
England, UK 18

first what “the real world” was like. But getting into computing, as
well as testing and automation, gave me an amazing and wonderful
career, totally unexpected, and much better. Somebody up there
had a much better plan for my life than I did!

Working in a great team is wonderful.

After emigrating to the UK, I worked as a programmer for Ferranti.
I was on a small team writing software for Police Command
and Control Systems. This was a great team and a wonderful
experience. Yes, there was teasing and some competitiveness, but
there was help and support when needed, and lots of laughter.
Many years later, I had similar experience when I set up Grove
Consultants. There is nothing better than working within a great
team, and perhaps nothing worse than the opposite. A good work-
ing atmosphere, a healthy work culture, is worth far more than a
salary. If you are in such a team now, enjoy it. And if not, perhaps
it’s time to move on.

Managers don’t know everything.

One day at Ferranti, my team leader was away, and I was sum-
moned to my first executive meeting in his place. At one point in the
meeting, the Big Boss (of whom I was terrified) said, “I hear there’s
been a problem in this project with Post Office communication.”
I knew that 6 months earlier, we did have this problem but it
had been resolved after a few weeks. But did I say that? No, I
started thinking, “Oh no, this must be a new problem, and I’m
supposed to know about it and I don’t. Obviously, the Big Boss
knows everything…” Of course, I should just have Asked a Question
instead (that’s another lesson), such as, “Is that the problem we
solved 5 months ago?”. This taught me that managers don’t know
everything. In fact, their view is wide, not deep, and has to be
because they are overseeing many projects. They don’t know - and
England, UK 19

shouldn’t know - the details. That’s why it’s important how you
communicate with managers!

Working for yourself is scary, hard work

and great fun.

I became self-employed after leaving NCC (The National Com-

puting Centre) when my daughter arrived. I knew nothing about
running a business, so this was another unexpected turn in my life.
Jerry Weinberg’s book The Secrets of Consulting was very helpful,
especially about the business side. It’s easy to look only at high-
paying rates for contractors and compare it to a salary, but there’s
more to it than that. Jerry’s Rule of 5 (days) says it best: One day you
earn money (and have to earn enough for the week). One day you
invest in yourself - read, study, take a course, go to a conference,
etc. One day you market yourself - it’s no good having great ideas
but no customers. One day you do admin - accounts,
invoices, tax etc., i.e. do the business side. The fifth day is holidays
and sickness averaged over the year. It was scary at first, and when
I became the “bread-winner“. Working for yourself seems to be
either feast or famine - too much work so you don’t know how
you’ll fit it in (if an employer had me working that hard, I would
have quit), or no work on the horizon and how will we pay the
mortgage? However, I’m really pleased that I did go out on my own
- we survived financially, it was the best thing for my career, and
immensely rewarding overall.

Technology is always changing, but people

are still people.

We think of ourselves as “technical people” but sometimes forget

the most important part - that we are people, whatever technical job
we are doing. The most important thing for a tester is not what tools
England, UK 20

you can use, what techniques you know, or what latest technology
you understand, but the Tester’s Mindset - questioning everything,
thinking what could go wrong. What is more important in life is
not the technical side, it is your relationships with people.
Looking back over 50 years in software testing, what is most
important to me is that I have been able to help people (through
training, consultancy and books), and the relationships I have with
the people I have known over the years. I wish you an fulfilling and
possibly unexpected career, working with wonderful people
France
France 22

Testing is about sharing

Benjamin Butel - France

Testing is about sharing

When I started my career as a tester, I was out of school and had

no knowledge about testing. I had no idea what adventure I was
embarking on.
My beginnings were focused on software integration testing. I
discovered testing by force of circumstances and I remember my
manager at the time, Sébastien. He gave me rigor, a sense of detail
and the quest for excellence, all in a very challenging and caring
team context. These are the first values that I developed on contact
with them and which, with hindsight, seem important to me as a
tester.
It was also in my early days that I met Grégory, my testing mentor
and friend today, without whom I would be nothing. He passed
on to me his passion for software testing. Testing is an art and I
France 23

can say that Grégory inspired me a lot. At his contact, I developed

curiosity, the desire to learn and the desire to share in turn. It was
he who made me want to take the ISTQB certifications. I will not
enter into the debate around these certifications. I’m just sharing
my own experience with you. Passing several ISTQB certifications,
self-taught and in English (I’m French as a reminder and English is
not my specialty) allowed me to not only increase my knowledge
of testing in general but also to develop a capacity of assimilation
and restitution of information.
My experience and my love for test are not limited to Sébastien
and Grégory. All the people I have met have brought me a lot
to step back, improve and grow in our profession. I am thinking,
among others, of Dorothée, Stéphane, Frédéric R. and Frédéric C.
who have given me their confidence and have always supported
me in developing my projects. And it is thanks to them that I was
able to share my knowledge. I became a trainer to support young
testers to pass ISTQB certifications but also on good automation
practices. And I became the leader of a testing community in my
company at the time. This experience has been very rich. I shared
my knowledge with the community but in the end, it was I who
learnt a lot.
I learnt new test methods, new tools, discovered new sources of
inspiration with Martin Fowler, Jean-Pierre Lambert, Angie Jones,
Kent Beck, Michael Bolton, Richard Bradshaw, Rosie Cherry, James
Bach, Ango Philip , Lisa Crispin, Dan North, Olivier Denoo and
many more.
It was also around this time that Marc Hage Chahine reached out
to share my vision of testing in the most popular French testing
blog, “La Taverne du testeur”. What a fascinating and rewarding
experience to write articles!
It forced me to structure my ideas, document myself and develop
writing skills. Beyond sharing, I particularly appreciate the ex-
changes that this provokes. Accepting to be criticized is part of
France 24

sharing. Disagreeing is extremely stimulating and is clearly part

of learning.
This is also one of the reasons that make me want to go even further
today by helping with the organization of events in France or by
organizing meetups myself with the Ministry of Testing. I have no
doubt that I will learn and share a lot in the future.
It’s a certainty : I would not test tomorrow as I tested yesterday.
I invite you to contribute at your own level. Share on social net-
works, write articles, and make videos, meetups and conferences.
Share again and again and come and contribute to our beautiful
and large family of software testing.
So, I’m waiting for you.
Testing is about sharing.
Germany
Germany 26

Be the change you want to see

Lalitkumar Bhamare - Germany

Be the change you want to see

Time is changing. Like it always does.
Ever since Agile has become a thing in the software field, I believe
the methodology has always emphasized on treating quality as a
team effort.
Considering my experience as a professional tester for over a
decade, I believe that our industry tried to minimize the efforts
(and cost) on testing by investing in automation in testing. I
acknowledge that over these years, tools and frameworks that
support automating the checks have evolved in terms of ease of use,
speed, easy maintenance and so on. But considering our industry
at large, I feel that we are still nowhere close to making quality as
a team effort. To the best of my knowledge, trying to replace the
skilled professional testing with a massive number of automated
checks has not worked out great towards achieving that goal.
Germany 27

The way I look at the current state of software testing profession

(or software development in general), the realization, the need and
the demand for involving non-tester roles in testing and related
activities, is increasing like never before.
Keeping the faster development of software without compromising
on the optimum quality in mind, I see this as a welcome change.
And that indeed has added a new dimension to the role of the
dedicated tester in the team.
What does it mean?
The way I look at it, the role of a dedicated tester is evolving
from the quality analyzer, assessor to a quality advocate and
quality enabler role. While this scenario has created new exciting
opportunities for testers, it has come up with its own challenges
too.
To be great at testing and to be equally great at teaching others how
to test like a professional tester, are two different things.
I have observed, discussed and witnessed that testers are willing to
take on this changing role, they are making an effort but some of
them seem to be struggling with onboarding others for supporting
them in testing. I did too. I tried, I struggled, I failed but I learned
and then I succeeded.
Where is the problem?
Perception. From my experiments, I learned that the problem is
with how non-testers perceive the testing role/profession/activity
to be. Even today!
I hate to admit it but the mundane, repetitive, mere script-based
checking of the software (performed by humans with a highly
capable and creative brain who could do better otherwise) and
calling it testing, has caused the industry more bad than good.
The way I understand it, the majority of non-testers see this (so-
called) “manual testing” (which is bad testing in plain sight) as
something tools could easily do instead and I tend to agree with that
Germany 28

perception. Bad testing is bad testing. And bad testers are equally
responsible for this broken perception of testing that non-testers
have even today. Period!
Change their perception of you as a tester
If some non-testers do not want to get involved or associate
themselves with testing (for they have this negative perception
about testing), I won’t hold it against them. How do we still onboard
them and enable them to test when they have to?
A simple yet difficult answer is, by changing their perception of you
as a tester. I suffered from this perception problem too and below
are some things I did that helped me change others’ perception of
me as a tester.
Speak their language and show respect for their craft:
Want them to understand you better and engage with you in
meaningful work-related conversations? Then please start speaking
their language (hint- interactional expertise)

• Demonstrate your understanding of the code, the business,

the product.
• Discuss and challenge the technical implementation at least
take part in the discussion
• Propose alternate solutions if you can
• Try Session Based Programming⁴, Pair Testing, Mob Testing
• Consider giving feedback on the testability of the code/solu-
tion
• Discuss programming, product development concepts
• Involve devs in an automation strategy, solutions
• Use defects/bugs/problems as an opportunity to pair and fix
rather than as a way to point flaws in their code
• Join them in Developer, Product conferences
⁴https://www.talesoftesting.com/blog/session-based-programming-10
Germany 29

Take over activities that you do not traditionally own as a

tester:

• Participate in code reviews, unit test reviews, reviews of user

stories.
• Review unit tests and automated acceptance checks
• Participate in code deployments, rather own the responsibil-
ity for deployments
• Take over or participate in production logs monitoring and
production telemetry
• Do not just report a bug but debug, drill down, even fix it if
you can (pair with devs if you like)

Correct their false understanding of your craft:

• Testing and QA are not the same things

• Testing is an activity and a test is a performance, not a phase,
not an artifact
• Testing is also about finding information, advocating quality
concerns and not just about finding bugs

Introduce them to your craft:

• Show them how big, smart and active software testing com-
munity is
• Introduce them to various resources to learn, read more about
testing
• Share interesting articles/blogs/discussions with them sur-
rounding testing and quality
• Discuss test strategy with them, involve them if possible

The damage bad testing has caused to the reputation of testers over
the decades is not easy to fix but certainly not impossible.
If you want to stay relevant with your testing skills in changing
times and contexts, I beg of you, be the change you want to see!
Germany 30

Optimize for learning

Lisi Hocke, Germany

Optimize for learning

We can never know everything, yet everything we know will help

us learn more. Only by learning we can discover more questions,
and by asking more questions we can again learn more. Just like
it is with testing. As a tester I explore a product for unknowns, in-
vestigate to find more clues, experiment with different approaches,
use tools to gather more information, and do many more activities
- all with the intent to learn more. The more we learn, the better
we understand the system, the better we can test, the more we will
discover. We want to make informed decisions, and yet whatever
information we end up with, it’s incomplete by nature so we have to
continue learning. Going in small steps and fostering fast feedback
loops throughout will speed up our learning and help us go in the
right direction earlier. With everything we do, let’s optimize for
learning - and that applies to us as humans, too.
Germany 31

1. Develop a growth mindset. We all can learn and develop our

abilities through dedication and effort. Sometimes we need to
allow ourselves to stumble, even to fall, and then get back up
on our feet with new knowledge. Learning is our gateway to
everything! No matter in which direction you would like to
go, learning is the only way to get closer. What helped me
is to include learning in my everyday routine and make it a
habit so I wouldn’t have to think of it anymore. Even if it’s
just a tiny bit - if it’s every day, I will know more every day.
Also, it’s never too late to learn something. Never. No really,
it isn’t.
2. Don’t let fear hold you back. Is there something that would
help your personal growth but scares you? Then give it a real
try. For me this was public speaking, I was terrified by the
mere thought. Finally tackling this challenge has brought me
very far. I discovered the benefits of speaking at conferences,
like getting access to even more knowledge; and at the same
time, I learned how to overcome and cope with my fears.
What helps me is to write things down. What is my actual
challenge? What experiment do I want to run to tackle it?
What’s the outcome I expect? How will I measure it, and
when? Whenever I’m afraid of failure, I remind myself of
the following to help me make that first step of phrasing my
challenge.

• Let’s see “fail” as an acronym of “first attempt in learning”.

• “Ever tried, ever failed, no matter. Try again, fail again, fail
better.“ My favorite quote of Samuel Beckett, an Irish novelist.
• We don’t learn in our comfort zone, so let’s be brave and step
out of it.
• If something is scary, do it more often! Things will become
less scary as you learn more with every step.

3. Get a learning partner. Why not pair up with someone who

faces the same challenge, or even a completely different one?
Germany 32

A learning partner can keep you accountable on what you

committed to do. They can act as a sounding board, mentor,
and more. You can celebrate your achievements together!
You can exchange your experiences and learn from each
other. You even have access to a larger network together.
This approach worked amazingly well for all my personal
challenges - I simply don’t want to disappoint my partner.
Even better, knowing that someone is having my back let me
dare to dare more. (Huge shout-out to Toyer Mamoojee here!)
Or what about starting a learning group?
4. Collaborate in synchronous ways to learn with everyone.
If there’s one skill I think everyone should learn in their
career, it’s pairing. Starting out as a strong individual con-
tributor, it took me time and courage to pair up with people,
and then lots of practice to learn how to do it well. Whatever
activity you choose, by pairing you combine your different
experiences, backgrounds, knowledge, skills, and approaches
to accomplish your task. Even better, when you have the
chance to extend a pair to a group - you can multiply your
learning further. This way I realized that I can learn so much
from everyone, no matter their seniority level, role, areas of
expertise, or any other aspects. The more diverse we are, the
greater the learning opportunity for all of us.
5. Ask for feedback. As testers it’s often us who give feedback
on someone else’s work. As humans, however, we all need
feedback to grow, so ask for it. Get your own work reviewed
as well, be it the strategy you came up with, a talk abstract,
your curriculum vitae, the helper tool you wrote, your blog
concept, or anything. It can be scary, and yet we need this
information to make it better. In the end it’s all about practice
and feedback. We don’t have to do things perfectly from
the start; let’s rather dare imperfection and get feedback to
improve.

Just like testing, our personal growth is all about learning - so let’s
Germany 33

stay curious and optimize for learning.

Being lucky

Stephan Kamper - Germany

Being lucky

Some years ago, I chatted with another attendee after a conference

and she noticed that I seem to be particularly lucky in life.
I didn’t think much about this at that moment and yet, I started to
observe whether I am lucky or not.
Let’s start with a definition of ‘luck’. The Cambridge Advanced
Learner’s Dictionary defines ‘luck’ as

the force that causes things, especially good things, to

happen to you by chance and not as a result of your
own efforts or abilities.
Germany 34

Note, that the definition mentions chance. In other words: There

is some kind of randomness involved. Also note, it states that we
can’t affect luck.
I am interested in the kind of luck, I experience personally, at the
place where I am, at the time when it happens.

A Story About a Car Crash

In early 2018, I went to a standard medical check-up. The results

weren’t brilliant, but OK.
A few weeks later I was on a business trip and took a taxi from
the train station to the hotel. At a crossroads, another car crashed
into the taxi, damaging the two cars significantly. An examination
at a hospital showed nothing too serious: Two ribs were damaged,
but not broken. A neck bone was slightly dislocated. Nothing pain
killers, some physiotherapy and a good amount of rest couldn’t fix.
After the accident, tiredness kicked in. Badly. I saw my doctor
again. More blood samples were taken and the result was alarming:
I was loosing blood! More examinations followed. A colonoscopy
brought the diagnosis. I suffered from colon cancer and it had to be
treated as soon as possible.
Life came to a complete halt.
In hospital, a computer tomography showed that the tumour had
strayed into the liver. In two surgeries a good part of the liver and
the affected part of the colon were removed and a ½-year chemo
therapy followed. I call this my personal debugging.
A surgeon told me that it’s very likely the tumour had been
damaged in the car crash. This caused internal bleeding which in
turn caused the cancer to be diagnosed. I was extremely lucky, as
it was diagnosed just in time to be treatable. As far as medicine &
science can tell I am now (March 2020) cancer free! So, it’s likely
that the car crash saved my life.
Germany 35

Tip № 1 Good news may be hidden in bad news.

Tip № 2 Listen to your body. Go to medical check-ups.
It can save your life, and your life is worth saving.

Aspects Related to Luck

During my therapy, I contemplated a lot about whether I am lucky

or not. Four aspects are particularly important to me:

1. Persistence: If you want to be lucky in a particular context,

put yourself in that context often. — Be where you want to
be lucky.
2. Opportunity Cost: I had a ‘tea bag fortune text’ once, that
said: “Accept that you can only to one thing at a time”. You
are where you are now, and you can’t be elsewhere. This
is obvious, and still important. And there is a price to pay.
If you’re at a conference listening to a talk, you can’t be in
the theatre with your friends at the same time. Note, that
there’s also a price to pay for ignoring this: You may leave
the talk half-way through, and rush to the theatre in time for
the second act. There’s a price to pay for this, too.
3. A Caring And Welcoming Community

• A Caring Community: In 2018, the year I couldn’t attend the

Agile Testing Days due to my cancer treatment, I received a
huge inflatable unicorn, covered in messages from attendees,
speakers & organisers. That’s the biggest and greatest get-well
card I ever received.
Germany 36

Agile TD

Here are 3 of these messages:

• Marianne Duijst wrote: “All the best! Our community is

rooting for you.”
• Someone from Portugal: “Fique melhor logo” (“Get well soon”,
in English)
• Gitte Klitgaard said: “Hugs & Glitter for you”

This is a prime example of a caring community. It still means a lot

Germany 37

to me and it helped immensely to get through chemo therapy.

• A Welcoming Community

My heuristic is this: When you can embarrass yourself by ac-

cidentally misbehaving and you’re still welcome, well, that is a
welcoming community. Here’s my example for this. In 2009, I
arrived at the venue of the Agile Testing Days the evening before
the conference. Trying to find someone to have dinner with, I
tweeted about it, and a super-friendly Canadian answered. I joined
his group and had a great night.
The next day, I tried the same, but a tweet. So I went down to the
hotel lobby. The same friendly Canadian told me his group was
about to leave for dinner and that I could join, which I did. Food
was fantastic!
Later that night, Lisa Crispin turned to me from another table,
asking what I was talking about. I told her what we were discussing
at my table, but that wasn’t what she wanted to know. She clarified:
“No, your session, what are you presenting in your talk.” Me: “I’m
just an attendee, I don’t give a talk.” In that moment Elisabeth
Hendrickson turned over to me and asked: “But you do know, that
this is the speakers dinner, right?” I said: “No!?” Embarrassment
kicked in, blushing, too. I wanted to disappear there and then.
But I also noticed that everybody else seemed entertained. If I
remember correctly, the organisers started laughing.
I was still welcome in the community!
4. Helping & Getting Help: My journey at the Agile Testing Days
continued. In 2013 Lisa asked me, if I could help her and Janet
Gregory with their keynote. I agreed immediately. — Little did I
know, what I was embarking on.
They had prepared a small theatre piece for the beginning of their
keynote and I had to play the role of Super Agile Person! I panicked.
Germany 38

This looked like a good opportunity to ruin a keynote, without being

a speaker. But again, it went well and people were entertained. Go
to YouTube and search for ‘SuperAgilePerson’ (no spaces).
A short time later I had the chance to contribute to their second
book ‘More Agile Testing’.
Imagine this: WHAT IF … I had denied playing SuperAgilePerson?
Apart from all the good things that happened to me by helping
people: Helping feels good!

Tip⁵ № 3 You can’t possibly predict the strange ways of

luck.

At this point I started looking for something better than anecdotes,

something scientific.

A More Scientific Way

Richard Wiseman studied lucky and unlucky people for about 10
years. He found four principles that can help to lead a luckier life,
which I will only mention

1. Maximise Chance Opportunities

2. Listen To Lucky Hunches The Cambridge Advanced Learner’s
Dictionary defines a hunch as ‘an idea that is based on feeling
and for which there is no proof’. In other words: Trust your
gut feelings. By the way, as far as I can tell, gut feelings still
work, even if you have part of them removed.
3. Expect Good Fortune
4. Turn Bad Luck Into Good

For more details I recommend his paper in the Skeptical Inquirer

(Volume 27, No.3, May/June 2003) and his book ‘The Luck Factor’
(See https://richardwiseman.wordpress.com/books/ for details).
⁵I’m not sure whether this should be a tip or a warning.
Germany 39

Revisit The Definition

Luck is the force that causes things, especially good

things, to happen to you by chance and not as a result
of your own efforts or abilities.

My my opinion some parts of the initial definition of luck can be

removed: First of all, it seems that luck can be affected and is not
all about chance and randomness. This leaves us with this:

Luck is the force that causes things, especially good

things.

Second of all, I’ve learned that there’s ‘bad luck’, too. With that part
removed, the definition now looks like this:

Luck is the force that causes things.

There’s not much left and talking about the force doesn’t explain
that much. I’m sure Obi-Wan Kenobi would approve this:
Germany 40

Obi-Wan Kenobi - Wars

In my experience, there’s no such thing as luck. – Obi-

Wan Kenobi, Star Wars Episode IV – A New Hope
(photo taken at OUTPOST ONE)

With That Said … Am I Lucky?

To me, the answer is a loud and resounding ‘YES!’.

Having survived cancer literally by accident and having received a
tremendously positive feedback from so many people, I am lucky,
indeed.
Can you be lucky, or luckier than before? Likely. Try to answer this
question:
What are you trying this week to be luckier?
Germany 41

Take a moment to think about it, then answer the question, make a
plan and do it.
GOOD LUCK! — AND MAY THE FORCE BE WITH YOU!
Gran Canaria, Spain
Gran Canaria, Spain 43

Top testing tips

Laveena Ramchandani - Gran Canaria, Spain

Top testing tips

When I started as a software tester, I was a part of a waterfall

project, then a big transformation happened. I started working for
a transport firm, in an Agile team. Agile was very new for me
coming from a consultancy where I was working in a waterfall
methodology.
Tip numero 1 - be adaptive, don’t respond negatively to change,
changes can be positive too. So being a part of an Agile team it
seemed great to being able to implement and deploy implementa-
tions sooner rather than later.
Top tip numero 2 - bugs were found sooner, therefore less costly
and a better-quality product. Now the roller coaster didn’t just stop
at Agile methodology, I started to automate tests which was a fun
experience as all I did before this job was test manually.
Gran Canaria, Spain 44

Top tip numero 3- manual testing is required, everything cannot

be automated human intervention is vital. Think of automation as
your own personal team who is helping you test repetitive tasks
in a speedy way, but your mini team might also need to check the
look and feel of a product too which your team cannot fulfil but
your testing knowledge and eyes can resolve that. I mentioned bugs
above, bugs are evil little/big things which break the functionality
of your product. Therefore, to meet good quality and make sure the
client’s requirements are met we need to do some black box testing
as well as white box testing and catch the bugs sooner.
Top tip numero 4- it’s a good thing to find bugs, never be put off
that you couldn’t complete your testing tasks due to a bug. Bugs
are a blessing in disguise, find it, report it, retest it.
Top tip numero 5- Raised a bug? Well done, what information did
you add on it? Vital information on your bug is a MUST. I have come
across bugs which say one thing, so one tends to test it accordingly,
but the person who raised it meant something else! I know all of
us in software testing have our own special ways to raising a bug,
but few things I think I found useful were; Where it was found?
(environments), steps to reproduce it, screenshots so that developers
know exactly what went wrong in terms of coding and lastly the
severity of it, is it a blocker? Or a low priority bug? These small
details will help you always in the long run and your team.
The team, they are basically like a work family therefore a new tip
numero 6 - always collaborate or pair within your team. It’s a good
idea to sit with a developer and understand what they have coded
for a particular feature coming in. It refreshes your mindset rather
than doing your day to day job and helps you understand the logic
a bit better. Furthermore, something I found useful is to do some
research on the side and write blogs about software testing.
So top tip numero 7 - write write write, some interesting blogs or
follow bloggers who may share their opinions which could always
help you explore more testing techniques out there in the world as
Gran Canaria, Spain 45

well as encourage you to share your experiences within testing too.

Also, tip numero 8 - attend some testing conferences as its quite
interesting to hear what fellow testers have to share and it’s
encouraging to try new techniques when testing, who knows you
could be speaking at a testing conference soon too! Id like to also
focus on strategies in testing and test plans. I was a part of a very
new team where the only testing that existed was unit testing. This
is good but we need to be able to have more testing in place. Being
part of a data science team, I had to come up with strategies and
get some testing plans in place to test a statistical model.
Tip numero 9 - the best way to tackle such a situation is to have
some meetings with the team, understand the product and think
of the best ways to test it. I would say keep some time to do
exploratory testing and with the help of your team have a good
test plan to test a new feature. Use tools to help planning, such as
mind maps or even taking good notes could help. Pairing with a
developer again could help come up with a viable test plan too.
Lastly I’d like to also add tip numero 10 - its OK not to know ev-
erything, do not ever feel disheartened that you do not understand
a product fully. It’s a part of your journey on the job to slowly
get to know the product. As testers we learn about a product when
testing it too, therefore just focus and test away and meet the clients
requirements and quality standards.

What advice do I wish I’d received earlier

before learning the hard way?

I wish I had known more about the testing community around

the world, joined testing channels, attended conferences or even
written a blog and follow bloggers.
Gran Canaria, Spain 46

What advice do I wish I’d received when

starting out?

I wish I knew more about automation back in the day, when it

did exist too! I just feel I could have helped my team have quicker
results and focused on improving the product more. I also think
it’s vital that at universities now they should share more about
software testing as it would be nice to know the world of testing.
I genuinely enjoy testing and feel it’s a great balance of being a
technical individual as well as having good business awareness.
Hungary
Hungary 48

Grow by helping others grow - like a

badass.

Maria Kispal - Hungary

Grow by helping others grow - like a badass.

What motivates me in software testing is the necessity of everlast-

ing self-development. Continuous learning is a badass thing.

Badass. /ˈbadas/ Adjective

US INFORMAL: super cool.

If only I had realized earlier how important it was to make

connections with the testing community.

“What life have you if you have not life together? There
is no life that is not in community”.
T.S. Eliot
Hungary 49

Sharing stories and experiences is not only a perfect possibility to

grow, but it deepens your own knowledge about the subject too.
There is something in each and every story that can teach a lesson
and everyone has a story to tell. Technology you can learn. Best (or
worst) practices you can share.
If there is no local testing community which is a safe-place to you,
build one up. Yes, building up a community is demanding, but what
you get in return is a scene where you can connect with people with
similar interests. Quite a journey!
People join the community because they share the interest, and stay
because they feel they can contribute or benefit from being part of
the community.
But what the badass thing in building a local testing community is
that you help growing others! On these events people get heard, are
inspired and they eventually grow.
If only I had realized earlier how I could have helped others to
get into tech.
Many tester positions are unfilled, albeit more and more people are
getting interested in getting into tech. Why not help them?
Inspire people from all backgrounds interested in technology to fall
in love in it, make it approachable, and help them in becoming
badass testers, offering a safe and friendly environment.
Colleagues with different backgrounds, creates such a diverse
environment that stimulates me.
If only I had realized sooner that it was not only technology I
should put focus on.
It’s not only the growth of technology you should keep up with.
It’s not only the “soft skills” you should be more familiar with. You
have to discover yourself as well. Why?
You gain a radically different sense of perspective on yourself.
Experimenting opens your world up, opens your mind, which
Hungary 50

brings new perspective in your way of thinking and can help in

breaking down your biases.
What are your biases? What are your strengths and weaknesses?
What makes you tick?
To get the answer go out and learn something completely different
from software development, something that seems to be completely
irrelevant to the job. You would be surprised by what the world can
offer you and how you can apply these experiences in work.
Do you know what you can learn from psychology or economics
that you could use in your testing strategy? Do you know what
studying a new foreign language or a new dance can give you in
your job?
Be thoughtful when it comes to the hype train. Be careful when you
follow the masses. Stay true to yourself.

Only those who will risk going too far can possibly find
out how far one can go.
T. S. Eliot
Lithuania
Lithuania 52

Power in authenticity: Being

yourself is your superpower

Lina Zubyte - Lithuania

Power in authenticity: Being yourself is

your superpower

We all want to be good at our jobs. As the prime directive states

“…we all did the best job we could with the information we had at
hand”. Yet what we often put aside is the power in authenticity. In
just being ourselves and not doing the job “by the book”. Sometimes
seeking to become extraordinary, we forget that there are a lot of
extraordinary features in our ordinary selves.
I put all my heart into the job I do, so when I started my testing
career, I made sure to grow rapidly. What are the best practices?
What are the books recommended? I’d read it all, I’d try to do
it all. I even changed jobs, so I could have more challenges. So
I could have more rapid growth. And I did. I went from being
Lithuania 53

a manual tester to someone who built an automation framework

from scratch, to someone who fell in love with observability and
data-driven context testing. After a while, though, it never seemed
that I was good enough, I wanted more. At some point, I faced
a burnout at my job. I questioned what value I’m bringing, and
maybe tech is not even for me? Do I know enough?
There is a certain level of stigma talking about pain, failure, and
doubts. Only talking to other people I realised how common it was,
and how much we should actually talk about it in order to grow.
I was not alone feeling burnt out. It’s an extremely human thing
to feel terrible especially when we try to be someone else, compare
ourselves to others, and keep losing ourselves. I loved testing from
the start because I felt like I belong, but chasing the next best thing,
trends, and pushing myself all the time to be like one of the testing
influencers/experts - I lost myself a bit on the way. I had to get
myself back and I did, but it was not easy. Authenticity, being
yourself, being vulnerable makes us the greatest at our jobs.
Testing is the field where we have to learn to value diversity,
creativity, innovation. We have to bring our true, daring, authentic
selves to the job, because every bug where someone tells you “Oh, I
haven’t thought of that” is found because of your skillset, your in-
terests, your passion. As testers we have to learn to manage biases,
and, appreciate the differences and uniqueness of our colleagues,
and acknowledge ours. So how do we do that?
1. Embrace your interests
One of the strangest bugs I found was because while testing I was
practising my Swedish skills - I wrote a specific word in my testing,
which actually helped me find some shortcut issues I wouldn’t have
found with our typical data set. Your test data can be a canvas
for you to actually use what you think matters, and what you
enjoy. This way you’ll be not only happier at work, but also more
productive and may find some unexpected bugs.
2. Admit vulnerability
Lithuania 54

It’s okay to say that you don’t know something. What it shows
most is not the weakness, but power. Showing your vulnerabilities
shows your strength. You have to get weak in order to get strong.
Working closely with all other roles and having an open growth
mindset together with honesty will help you grow even more.
3. Listen to your heart
If you feel that the product is not ethical, maybe it actually is
not ethical. Especially nowadays we as testers may have a good
intuition - products should be more accessible, secure, and in
general fairer. In the age of concepts like artificial intelligence
gaining speed, we are the ones to question it and make sure AI
is more inclusive.
Chase less trends and best practices, you are already bringing in
great ideas because… they are your ideas. Embrace them. Embrace
your power of being you and your testing will blossom, too.
To end in an authentic manner, I just have to embrace my love for
poetry:
Finding Power in Authenticity
And there may be times when you say to yourself
“I’m not good enough, why do I even try?”
It may continue day after day, even in the middle of the night
Wondering how everyone has their careers going so fine.
But everyone is not you, and that’s… okay
We fear to be different but knowing thyself is the only way
To learn, improve, and even help each other grow
To train a growth mindset and reach the flow.
And, hey you!
If something is hard to do - do it more often, and remember
You are good enough and you can even get better
If you accept others and yourself for who you are
Embrace your inner strange & keep an open heart.
Netherlands
Netherlands 56

A glimmer of hope

Sander Hoogendoorn - Netherlands

A glimmer of hope

In September 2003 I visited the friendly city of Arhus in Denmark

to deliver a talk at the JAOO conference. At that time, JAOO was
an established software development conference, with well-known
speakers such as Martin Fowler, Kent Beck, Linda Rising, and Erich
Gamma. And me.
When I arrived at the venue, one of the organizers offered to
give me a guided tour of the building. While we strolled through
the conference center, she enthusiastically pointed out the major
rooms where the conference would take place. Then all of a sudden,
the organizer stopped at a wooden door in a small hallway. She
opened the door respectfully and we looked in. An ill-lit room with
furniture stacked to the walls. “Do you know what happened in this
room?” she asked me almost whisperingly. I shook my head. Of
course, I had no idea. She continued mysteriously. “This is where
Netherlands 57

during JAOO last year, Kent Beck and Erich Gamma conceived
JUnit.”
I guess that was my first introduction to unit testing.
The impact of JUnit on the industry of software development was
huge. It was the first viable unit testing framework out there. Still,
unit testing took a long time to gain traction. Even today in 2020,
when I ask audiences at talks for a show of hands about who
actually writes unit tests, most people do not raise their hands. And
that’s a shame really.
Recently, I was coaching a development team that had come to
a complete standstill. They didn’t dare to change another line
of code, afraid the codebase would break. Not a single feature
had been delivered to their clients in over ten months. When we
investigated their codebase, we found few unit tests, extremely
low code coverage, high cyclomatic complexity and many untested
paths in the code. And still, when I stressed the importance of solid
unit testing for maintaining quality and speed of development, the
developers stared at me with long faces and asked if writing all
these tests was really, really necessary.
It is.
To be totally honest, it took me quite some time to get convinced of
the effects and benefits of unit testing and test-driven development.
For authors Kent Beck and Erich Gamma, the number one goal for
creating JUnit was “to write a framework within which we have
some glimmer of hope that developers will actually write tests.”
They built JUnit with already existing, familiar tools so that there
was little new to learn. As they said: “It has to require no more
work than absolutely necessary to write a new test.” Gamma and
Beck made writing unit tests as simple as possible.
So why is it so hard to start writing unit tests?
From my own experience, despite the simplicity of the tooling, with
Jest being my current poison to test my TypeScript and JavaScript
Netherlands 58

code, one problem I think lies in the fact that writing unit tests still
requires skills and understanding. It takes time to learn. And time is
something we are always short of in software development. There
is continuous pressure from stakeholders, managers or product
owners to add and improve features in our products. We never seem
to have time available to work on the quality of our architecture and
code. Hence, we tend to skip writing unit tests.
Another challenge is that the benefits of having good unit tests are
reaped in the long run. People are not really good at preparing for
long term benefits. Not unit testing is like smoking. We all know
smoking is bad for us. Nonetheless, people find it extremely hard
to stop smoking. This is because the drawbacks of smoking are
usually not felt until years later. With unit testing, this is quite
similar. Having unit tests for everything pays back in the long run.
It pays back after six months when you notice you can change
your code without pain. And it pays back after one year when you
can still change the code. And even after multiple years, your code
remains stable and has even become more robust than it ever was.
Unfortunately, too many people postpone writing unit tests until its
late, and the consequences of not having tested code have become
huge.
And it becomes worse when you work with modern software archi-
tectures, such as microservices or serverless, where you usually do
not have a single codebase, but rather work on a vast collection of
small codebases. With one of my recent clients, the total landscape
consisted of around forty micro-applications, fifty microservices,
and about the same number of serverless functions, each of which
with their own codebases, pipelines, and infrastructure. In environ-
ments like these, it becomes even more vital to keep your codebases
in good health. Unit testing is essential.
As an example, while writing this post, my teams and I are looking
at a small, but a rather delicate change in the core library of my
client’s landscape. This library contains around fifteen hundred
lines of code. Around thirty applications and microservices running
Netherlands 59

in production depend on it. Without even giving it a second

thought, we made the change; we ran the three-hundred-eighty-
five unit tests on the library; saw that these all turned green; we
checked in the code. No pipelines broke in the process.

With proper unit testing, we would not have had the trust and guts
to make this radical change. We would just let it slide. And we
would just let it slide over and over again. Until we would not be
able to guarantee the quality of our codebases anymore.
My advice? Stop whining about the effort and time it takes to
start writing unit tests. Or even complain about it being boring.
Even though unit testing might not seem to deliver on its promises
immediately, it will in the long run. For sure. Don’t wait until
your code becomes unmaintainable. Just like you can better stop
smoking today than to wait for your package to be empty, or until
the first of January of next year. There is no excuse to postpone.
It is always better to start writing unit tests today. Actually? Stop
reading now, start unit testing.
New Caledonia
New Caledonia 61

Am I where I’m supposed to be?

Zoé Thivet - New Caledonia

Am I where I’m supposed to be?

“So, Zoé, why should we pick you for this software testing job?”
“Well, my five-year goal is to become a software developer, and
I think beginning with software testing would be a great way to
achieve this.”
… Oops, right? I feel a bit queasy when I think of this answer I
gave to my very first employer on my very first job interview.
By this time, I was about to graduate in social sciences, and the
standard path for me would have been to become a documentalist,
an archivist or an editor, but I wanted to venture into something
else. I had been learning some development skills at home, coding
some little video games in Javascript and a goofy essay generator
in Perl. Khan Academy and OpenClassrooms had been helping me
a lot, as well as regular Meetups that I enjoyed attending back then
in Lyon, France.
New Caledonia 62

So here I am, sitting in front of my future boss, and he doesn’t seem

very pleased by my answer. As we continue to talk, I realize I know
nothing about software testing, I realize I really don’t know if I
want to have this job after all, and I ask myself, “Wow, am I where
I’m supposed to be?”
Surprisingly enough, I got the job, and I took it. “Am I where I’m
supposed to be?” became a personal jingle that played in my head
quite often. It meant “Am I a real software tester?” And I’m sure
I was a pretty bad tester, because I didn’t dare to ask too many
questions. I was aiming to cover everything I understood, but it
wasn’t much. I felt unconfident and didn’t fit very well in the team.
I had a goal to set up on my own a test automation project for the
core product of the company, which I failed: all I delivered was
brittle spaghetti code, and I still blush when I think about it. I still
wonder why nobody ever told me my code was crap! And I think I
should have asked for help and feedback since day one.
An economic lay-off made me switch into a new company in less
than a week. There, I had the chance to meet a person that became
a real mentor to me. She made me discover what a proper test
automation project was, and I found it fascinating. It may seem
funny to read, but OOP (Object Orientated Programming) felt like
a revelation to me. She also helped me develop my core testing
skills, she inspired me in many ways. This is when I feel I became
a real tester. The little jingle “Am I where I’m supposed to be?” did
not leave me, but turned into something more interesting. Is this
what I’m supposed to test? Is this what I’m supposed to do? Where
does my work begin, and where does it end?
These questions are not easy to handle, and they are the most in-
teresting. They lead me to be creative and to focus on what’s really
important. I’ve kept them in mind since then. I believe mastering
software testing isn’t about getting confident about anything, but
becoming able to question everything.
I now live and work as a software testing consultant in New
New Caledonia 63

Caledonia and enjoy situations where I feel a bit lost. I believe

there are many ways to test effectively, and appreciate discovering
untrodden paths.
New Zealand
New Zealand 65

Learn through teaching

Mike Talks, New Zealand

Learn through teaching

When I was at University studying Physics and Astronomy at

Sheffield University, I had a very charismatic tutor named Doctor
David Hughes. In one memorable session he issued a challenge to
us all.
“If you really want to test yourself sometimes, try and teach some-
thing you know to someone else,” he told us. “And if you really want
to take on the trials of Hercules, try teaching a five-year-old. No one
on Earth will challenge what you know like a five-year-old.”
There is truth to this. Gather a group of respectable physicists
together and collectively they will all respect that the universal
speed limit is the speed of light.
A child isn’t party to the same level education, so they will
innocently ask, “But why can’t we go faster than the speed of light?”
New Zealand 66

This will cause the group of physicists to look down at their feet,
and shuffle about awkwardly. They all respect the speed limit.
Some have forgotten the exact reasons. Most have it conceptually
in their head why. But few can actually explain it.
Okay, well I don’t teach five-year-olds to test, but coaching about
testing is a big part of my role. And he had a really good point.
In our testing career, we can go through one project after another,
and we can follow a copy-and-paste, rinse-and-repeat formula to
what we do. This was very much me in the early 2000s.
You took what you’d done on your last project, and you copied
it over to the next one because it ‘kind of worked’. Everyone is
okay with that because it ‘kind of looks like’ something they did on
another project.
So everyone’s happy, and going along with everything until a
graduate tester is assigned to the project and asks, “Why do we do
it this way?”
You look around your team who’ve been doing this for two years
and they are all blank looks. The best response you can come up
with is that, “Well, we’ve always done it like this!”
Erm … erm …
As human beings, we love routine. According to Daniel Kahne-
man’s Thinking Fast And Slow, routine means we’re saving mental
bandwidth for other things. And that’s great, but sometimes when
routine is no longer serving us, we do need to fire up those neurons
and think again.
Doctor David Hughes was right, in order to challenge ourselves and
reconnect with the important whys around our subject we need to
explore through teaching. As such I’ve taught bootcamps on testing
as well as mentored a few graduates in their first testing position,
as well as more senior testers.
For an example, I’m working with a group of testers on an appli-
cation which originates from the 90s (it’s said one of our senior
New Zealand 67

managers worked on the code originally as a graduate). The testers

have worked on this project over ten years, and it’s been very
waterfall using manual regression testing.
The software is going to be replaced by a new web-based applica-
tion, and it’s going to be evolved through a series of sprints until
it’s ready to replace the old system.
This obviously is turning the lives of these testers upside down.
All this involves a radical shift in behaviours. Although ironically
because we’re creatures of routine, our first instinct if often that ‘I
know we’re transforming, but surely what we do stays the same,
but everyone changes to feed us?’
It’s from such assumptions you often hear of teams where develop-
ers create done stories in one sprint, that the testers will test in the
following sprint – creating a mini-waterfall.
To help them avoid going down that track, I’ve been talking them
through the typical approach I’ve used on the last few projects.
Although I’m very aware that there’s a danger there of just using
our template over theirs, copy and paste.
Last week I worked them through our transformation – how things
used to work when we were waterfall, how we evaluated where
the areas of value were, and ensured we maintained that value in
different ways.
You can’t just lift-and-shift the strategy over – we had a different
customer, demands, technology. But it’s a good start point – in some
ways they have the potential to do more than us, in other ways
there are limits on some of their activities.
Sessions always involve challenging questions – sometimes things
I haven’t contemplated before, and sometimes things I don’t know
the answers for. Sometimes I need to research, sometimes it’s a
great example to give for homework for them to explore.
Most often the best way to show a concept is by an exercise or a
game. I’ve ended up putting a lot of material I’ve developed in the
New Zealand 68

form of,

• Testing aids such as my test plan dashboard or Oblique

Testing ideas generator
• Mock specs for systems such as Project Balto or Project
Glinda or the Panther aircraft fuel calculator
• Working web apps like guessing game, aircraft fuel calculator
or the basic calculator

Often these tools form a great focus for a session – we might explore
how to test them as they are, or how we’d handle testing a change to
the system. Most of these resources have been used as the backbone
for international conferences I’ve attended.
So, although I’m supposed to be teaching them, you’ll notice that
doing teaching will stretch me as an individual, there will be items
I need to think about deeply, but also I get better at anticipating and
dealing with questions.
That later part is important – because of course it’s not just
graduates and testers I coach. Testing is something which isn’t
really well understood – it’s seen as the strange, Charlie Brown
child of the software development lifecycle. I’ve also coached whole
teams, and seen developers themselves realise ways they could
build systems which have testability baked in from the get-go rather
than something the testers feel they have to accept.
As a senior agile tester, it’s also been necessary to coach managers
and stakeholders on what we’re trying to achieve – especially
against the difficult question of ‘why can’t we test it all?’
And this later group are our equivalent of 5-year-olds to a physicist.
It’s not that they’re children, it’s that they come from a different
background, so don’t hold the same things as us sacred and unchal-
lengeable. Being able to better engage with this group will allow us
to share our world view and avoid being overlooked or considered
a final piece of the puzzle.
New Zealand 69

Building up resources and collateral in testing helps make the job of

selling and educating testing easier. My book ‘How To Test’ started
from my teaching, as did the many resources I use as part of a
conference submission.
Challenge yourself – find some time to mentor and teach!
Scotland, UK
Scotland, UK 71

Don’t limit yourself - focus on

growth

Ali Hill - Scotland, UK

Don’t limit yourself - focus on growth

It’s important as testers that we don’t limit ourselves based on our

job title. I’ve seen a number of testers fall into the trap of becoming
stuck in the silo that they believe their employer wishes them to
remain. It’s up to us to push the boundaries of what a software
tester is. We need to continue to learn new skills and techniques in
order to continuously improve and evolve.
My career began testing video games. I ran through the same test
cases on a daily basis and found myself adding the same type of
bugs into our bug tracking software. I began wondering whether
this was all that a testing career was meant to be? Surely there was
more to testing than this? It was this train of thought that led me
to finding the online testing community and discovering all of the
Scotland, UK 72

wonderful different roles that testers can perform.

Throughout my career, I’ve taken inspiration from the different
blogs, Tweets, webinars, conference talks etc that other software
testers have produced. If I was to summarise what I’ve taken away
from this wealth of knowledge it would be ‘don’t limit yourself’. At
first, this was intimidating. Listening to testers talk about security,
performance, monitoring etc triggered my imposter syndrome. But
then I found it inspiring. If those testers can learn these skills, then
why can’t I?
I decided to grow in order to move away from running test cases
continuously. I learned how to code by pairing up with developers
on my team. At first, this was with the aim of being able to
write automated tests, but it quickly grew into something more.
I began to utilise my coding skills to assist our team with carrying
out exploratory testing. I could now create tools, such as a data
generator, which allowed us to discover more unknowns in what
we were developing at the time.
I then decided to focus on learning more about Agile and Lean and
found myself performing a coaching role. These skills allowed me
to assist the team I was working in to deliver quality software by
focusing on improving our processes. These are just a couple of
examples of the skills I’ve learned in order to push the limits I’ve
seen placed on testers in the past.
Ask yourself; what you can start to learn today in order to push
the boundaries of what a software tester is? What can you learn in
order to grow?
I now find myself in a development position, developing security
controls for the cloud. Is it strictly a testing role? Definitely not. Do
I still identify as a tester? Absolutely! Software testing, for me, is
about adopting a quality focused mindset. I’ve found throughout
my career that this mindset can be applied to any role within
software development.
Don’t let your software testing role limit you - learn what you want
Scotland, UK 73

to learn and continue to grow.

Serbia
Serbia 75

#10yearschallenge - what I wish I

knew before

Mirjana Kolarov, Serbia

#10yearschallenge - what I wish I knew

before

When you reach that figure of 10 years in your testing career, it

makes you think: Are there any things I wish I did differently? What
would have happened if I chose another option back then?
Approximately two years ago, I reached that point. Initial over-
whelming feeling when realising I have a two-digit number long
career was quickly outshadowed by an internal retrospective - it
made me think back.
Like the majority of the people in the testing community, I got in to
testing by accident. I had almost zero knowledge about what testing
is, and applied for two jobs in the same company: developer and
tester. The interviewer found it odd I had applied for two positions.
Serbia 76

After explaining that I was curious to learn what they meant by a

testing role, and that I think I had a clue what a development role
would look like, they made a clever decision by offering me a test
job. And I accepted. That was my first good choice.
I love coding, but I always knew I wanted to do more - to explore,
learn, understand the product, and support the team. Now I know
those are all the things that are important in a testers role. Back
then, it all came naturally. Thinking about that critically - I wish I
knew how important that was, and to cherish it more and also to
coach others.
The thing I wish I did more is coding. In the first few years of my
career, I didn’t have enough opportunities at work to do the actual
coding. If I could turn back time, I would do more pet-projects in
my spare time (creating apps, games - whatever so that my Java or
.Net coding skills would not go rusty). Maybe even start learning
a new programming language. After 2-3 years of manual testing,
I started coding again, and it was not any trouble at all, but I was
not as confident as I was when I finished university. I’m glad it
didn’t stop me from creating the first set of UI automated tests in
my company.
The thing I regret is not using Twitter more. I found such a treasure
there, lots of valuable resources, thoughts, ideas… It is still my go-to
place to look for motivation. I live in a small country (Serbia) and
our testing community is not that big. Twitter opened up a world
testing community to me. There I can see that others have the same
pain as I do, are struggling around similar things - it makes me feel
I’m not alone. Luckily I realized it a couple of years ago, although
I wish I was using it even as a student.
A big change happened in my career after 6 years. I needed to try
something else, go to an unknown environment and prove how
good I am (or prove it to myself that I’m wrong). It was one of
the best decisions I made. Not because the previous company was
bad, actually the complete opposite (which I proved by returning
Serbia 77

back to the company later on, and I am still there). This change
was good because I met awesome people and great mentors. Two
of them shared the same vision with me, we therefore founded the
first testing community in Serbia.
Around that time, they also inspired me to apply for my first time
as a conference speaker. Speaking of courage - I had never been to
a conference before, I had no idea what one looked like! I was lucky
to get accepted. I had the best time on stage, and have loved doing
presentations and workshops ever since. What I absolutely adore
about conferences is that you get a chance to meet a lot of inspiring
people, have great conversations, discussions and have fun. Also, I
met my power learning group friends, with whom I have regular
learning and sharing sessions over Skype. I will never be alone in
the testing world since I found my support.
After the retrospective I realized I was not happy about the fact
that I reached a two-digit number of years in testing, but I was
so happy by all the experience I gained, about the opportunities I
seized, challenges accepted and people who I’ve met. I was happy
with who I am, after doing the thing I love for 10 years. Happiness
is my main driver to grow and learn. Are you happy? If not, change
something!
Oh and my advice, if I need to put it in one sentence - nurse your
coding skills, use Twitter, go to conferences, be brave to speak at
different events (remember, everyone has an interesting experience
to share - their own experience!), create your own community (it
could be virtual) and find people from whom you can learn and the
ones who support you. And yes - don’t forget to be happy!
South Africa
South Africa 79

Pushing your own boundaries!

Toyer Mamoojee - South Africa

Advice for the past me

Over the last 4 years or so I started diving into the world of Testing
conferences, test community, social media and being bold enough
to voice my opinions across different platforms. If I had to look back
at my 5 year ago self or even my 10 year ago self I would have told
‘me’ to not hold back and get involved in the testing community
sooner.
When my career started I always felt I needed to not just focus on
my job but focus on a career. I wanted to be part of something big
and at various points I felt the need to give back and share learnings.
My feeling is usually that even though every work environment is
unique there are definitely common and generic aspects of a role
that can be extracted and shared. This in turn would be able to
help and assist anyone who would find themselves looking for an
answer which my experience sharing could potentially resolve. I
South Africa 80

think the element of boldness stepped in over the last few years
and I wish I could have done it sooner. I personally felt I made
some positive strides over the last 3 years which I hardly thought
was ever possible.
Something that has pushed my career to new heights has been
pairing with an international group of people who I value and have
utmost respect towards. From my detailed pairing with my learning
partner Elisabeth Hocke to the co-forming and interactions of the
amazing, informative Power Learning Group all whom hail from
different countries across the globe. With all these pairings we
have created a platform where knowledge sharing takes the centre
stage. Contributing and learning is the key focus for these awesome
partnerships, the benefit of which is priceless and rewarding in
many ways.

Set yourself focused goals

Some advice that I always share with my teams is on setting
personal focused goals, in today’s challenging world where there
are tons of technologies, systems, concepts, terms etc around you,
yet how do you manage to be effective in most of them without
being overwhelmed or even just being able to hold your own when
discussions arise.
Something I tried over the last 6 years or so has been setting myself
a single themed yearly or 6 monthly goal. This way I could give
enough focused attention to learning or mastering an area without
jumping around too much. For example there were years where
I focused on learning as much business context as possible at the
company I worked for. I dedicated my time to sit with business
users, understand key financial concepts and even try to deep
dive in finding out the historical context of a business problem.
Then in another year I would totally switch my focus on trying
to learn more detail around a specific programming language like
Javascript.
South Africa 81

Some of my other focus areas that I recall include Performance

Testing, Leadership and Agile. This way I know that I had given
enough attention to a specific area, that way making myself ver-
satile enough to meet today’s versatile world. Even though it is
also possible to attain a cross-functional versatile knowledge base
around concepts by regularly switching between all of them, a
longer focused time gives you dedicated space and time to explore
all avenues on a given topic without the distraction of other
concepts.

Be unique, build your own personal brand

As your career progresses it is key to ask yourself who you are, this
is true in both a personal and a professional context. If you look
specifically on the professional context I started to believe that each
person brings a uniqueness and its key to display this uniqueness
so that at any given point in time your presence spoke for itself.
Whether that presence is a physical presence or a virtual/social
media presence. The passion for what you do should be clear, this
ties in closely with your values, your knowledge, your experience
and your drive. Find ways to determine your uniqueness within
the Testing and Agile space then put all your effort in bearing it to
fruition.
Keep pushing your own boundaries, after all you only have yourself
to impress.
Sweden
Sweden 83

Journey from dev to tester

Lena Pejgan Wiberg - Sweden

Journey from dev to tester

As I was asked to contribute to this book, I took inspiration from

a talk I did called “My journey from developer to tester”. I had a
pretty long career in development before I took the leap into full
time testing and with 10 more years of different testing roles, here
are some of the lessons I´ve learned:

Developing software is hard

Often testers lament that developers don´t care about quality, focus
too much on building and not enough about understanding what
they are building. And I have agreed more than once. But there are
so many things a developer (and a tester) needs to know about that
it´s impossible to think of everything all the time.
Sweden 84

One should know about domain standards, coding standards, UX

standards, architectural standards, accessibility, security, legal re-
quirements (directly or indirectly applicable), the psychology of
user behaviour, the company business model and not least: other
similar software. And the list could be made a lot longer.

Consistency is key
The older I get the more weight I put on this. It´s easy to brush
off inconsistent behaviour as “not important”, but this ties in with
understanding UX Standards and the psychology of user behaviour.
I suggest looking into things like Jakob´s Law: “Users spend most
of their time on other sites. This means that users prefer your site
to work the same way as all the other sites they already know.”
Meaning your edgy new interface needs to have a very good reason
for breaking standards.
Consistency has a lot of facets, know about them! Look for in-
consistencies within your product, with your purpose, with your
users´ expectations, with claims you make about your company
or product, with rules and regulations in play and again: against
comparable products on the market.

Learn what motivates the people who

matter
People are motivated by very different things. Knowing the person
who will choose if/when/how to solve what you want solved will
make you much more likely to get it. Some things we learn about
in almost every training, such as how many people are or how big
of an impact it has on the user and/or business, but there are many
more!
Some like to pick “low-hanging fruit”, meaning they will prioritize
things that are easy to fix, have low risk or have a thorough analysis
Sweden 85

already done.
Some are more likely to pick something that seems to be an
interesting problem to solve, meaning they might prioritize things
that look less straight-forward, maybe a tough race condition that
is hard to replicate. Make sure you tell the story of things you have
tried.
Others are motivated by pride, only delivering high quality soft-
ware. They will most definitely not want embarrassing or obvious
problems to show up in production.
And of course, there are some who will do only what someone
“higher up in the food chain” tells them to do. In those cases, you
have to find the people making the decisions and motivate them.
If you work with someone motivated by emotions (oh they are more
than you might think…) it is more important than ever to tell a
compelling story. Who is affected, how will it affect them and what
might the consequences be?
And then of course: relationships. Do not underestimate the impor-
tance of this! Build trust and strong relationships and you will be
much more successful. We want to help people we like and we tend
to like people who like us.
While you are at it: learn what objections different people will
use and prepare to overcome them. Usual objections are “Can´t
replicate”, “This is an unrealistic scenario”, “This is not a bug!”,
“This was not in the requirement”, “This is too hard to fix” or “This
is not important right now”.

Pick your fights, let the rest go!

Remember the story about the boy who cried wolf? Yeah, it works
the same way being a tester. If you always fight to the bitter end
for every bug, or every test you want to run, you find people will
start ignoring you. Find a good balance between what is worth
Sweden 86

championing for, and what you can let go without lying awake at
night worrying will happen in production.
The same goes the opposite way: The more people see that your
work is well thought-through and that your judgement is good, the
more they will start to listen to you.
The same idea can be used to consider how much effort should be
put into planning your tests, analysing your findings and how to
report. Sometimes it´s crucial to be able to show later on what you
did and/or what you found. Sometimes it is only waste. Sometimes
it will save the team a lot of time if you do a thorough analysis of
a problem, sometimes it will just be wasteful.
It ties back with knowing legal requirements, knowing your do-
main, having strong relationships and being very good at doing
risk analyses. The more you know about different aspects of your
domain, the better you get at analysing risk and how to mitigate
them: The more value you will bring, and the more people will
value you.
Quality is a team sport, not a race, so make sure neither you nor
your team-mates measure your value in how many bugs you find
or miss.
Turkey
Turkey 88

A drawing compass, a multi-sport

athlete, and a multi-skilled tester

Koray Yitmen - Turkey

A drawing compass, a multi-sport athlete,

and a multi-skilled tester

The information technology (IT) world is evolving rapidly, along-

side unprecedented customer needs, a competitive working envi-
ronment, and new software development trends. As a newcomer to
software testing, you may feel anxious about how to survive and
prosper in this ever-changing playground. In this article, I provide
you with a framework rather than a concrete formula with which
to overcome this challenge. This framework involves acting as a
drawing compass which draws value circles around itself.
As we all know, one leg of a drawing compass is fixed and focused
on the surface, while the other leg can visit all the coordinates of a
drawing ground. This manner of being both in a static and flowing
Turkey 89

state at the same time gives the compass a great advantage. Without
losing its focus and control, a compass can change and adapt as
much as it wants. This same dual competency is also important in
the ever-changing IT world. Any new software tester must also be
skilled in software development and human relations, as software
testing does not exist in isolation. A multi-level investment in these
skills both enhances your testing skills by allowing you to learn
from other disciplines and enables you to stake your position within
the bigger picture of the IT ecosystem.
Proof of the effectiveness of this framework comes not only from
my 20 years of IT experience, but also from being a sports fan.
For example, most of the round picks in the NFL draft have been
multi-sport athletes. The combination of different challenges, skill
sets, viewpoints, coaching experience, leadership skills, and cross-
training know-how add value to the athletes’ competencies, giving
them competitive advantage in their profession.
In addition to the competitive advantage, experience in a variety of
sports allows athletes to become well-rounded people. By nature,
such people tend to be more agreeable. With the high adoption
rates of Agile frameworks in software development, self-organized
teams are now much more prevalent than in the past. Being
a self-organized team requires team members having agreeable
personality traits. Without this skill, it is almost impossible for team
members to reach consensus, take initiative, or move forward.
Having defined the objective of new software testers, let’s examine
the ways to achieve this objective. Becoming a multi-skilled tester
requires acting as a drawing compass, with one fixed leg placed
firmly on the ground and the other leg drawing value circles on
different levels around itself.
In order to stand firmly on the ground, one should first begin
learning and practicing the fundamentals of software testing. These
include: defining the risk; recognizing different risk types; assessing
product risks; using different test design techniques such as black-
Turkey 90

box, white-box, experience-based, and defect-based; generating

tests from test designs and prioritizing them according to risks;
executing the tests; and finally reporting clear results.
After you are anchored to the ground, you are now able to draw
multiple levels of value circles around yourself. The first value
circle, which I refer to as the “testing” circle, should touch the ver-
ticals of software testing. This circle includes the fundamentals of
functional testing, the fundamentals of non-functional testing (such
as usability, security, and performance testing), test automation,
test data management, and test environment set-up.
The second value circle is the “IT” circle, which touches the
verticals of software development. This circle includes: the fun-
damentals of project management and different project manage-
ment approaches such as sequential models, iterative models, Agile
frameworks, as well as business analysis, system analysis, database
design, network design, coding, UX design, DevOps, Continuous
X, and soft skills such as negotiation, conflict resolution, time
management, and communication.
The third and final value circle is the “human” circle, which
touches the verticals related to science, psychology, sociology, and
parenting.
Depending on your project and your purpose, the moving leg
of your compass should visit each vertical on each value circle,
learning from each as much as you need. In doing so, you can
become a multi-skilled tester, increase your competitiveness, and
be a successful team player.
Along the journey, you may change your mind or feel that you
are stuck in the coordinate at which your compass’ static leg
stands. Perhaps you want to make a career move or move on, for
example, to pursue a career in test automation. In that case, you
only need to change the coordinates of your compass’ static leg
to test automation and begin drawing new value circles around
it. Whether you follow a career in test automation, performance
Turkey 91

testing, or any other vertical throughout your multi-dimensional

journey, you may experience a metamorphosis from being an I-
shaped professional to a T-shaped one, followed by a Pi-shaped and
finally a Comb-shaped professional. At this point, you will now
be ready to maintain focus while handling ambiguity in this ever-
changing IT world.

Tip: Deepen and widen your horizons of knowledge

United States of America
United States of America 93

Improving & learning in small steps

Lisa Crispin - Vermont, USA

Improving & learning in small steps

I could write a whole book on what I’ve learned from Linda Rising⁶.
I’m going to share the one thing that I feel has helped me the most.
I wish I had learned this much earlier!. I encourage you to go find
YouTube videos of Linda’s conference talks, and her books with
Mary Lynn Manns.

Small, frugal experiments

I’m lucky to have mostly worked in Unicorn Land, on high perform-

ing agile teams, for most of the past two decades. Even so, my teams
and I experienced some frustration in our quest to continually
improve. Every retrospective, we could list dozens of obstacles in
our way.
⁶https://lindarising.org
United States of America 94

Thanks to Linda, I learned that we needed to identify the ONE

biggest blocker that prevented us from achieving our main goal.
Once we had that, then think of ways to make that problem a little
smaller - say, 20%. Set a measurable goal around that, design an
experiment, commit to doing it, time box it to a couple of weeks to
see if it’s helping the team move towards the goal.

Designing a measurable hypothesis

My specialty is testing, and I have other skills, including facilitating

retrospectives. When I get the chance to facilitate one, I advocate
for designing an experiment to make our biggest problem smaller.
Once we’ve agreed on the biggest blocker to address, I use this
hypothesis template:
We hypothesize by <implementing this>
We will <improve on this problem>
Which will <benefits>
As measured by <measurements over a specified time period>
Here’s an example. My team’s problem was a long cycle time – from
when we started on a story to when it was released in production
– as well as a high rejection rate by the product owner. We thought
we knew what to do after each iteration planning meeting (IPM),
but about half the time when we delivered a story, the PO said,
“That isn’t what I asked for”.
I suggested we try Three Amigos meetings (a term coined by
George Dinwiddie, for a practice that Janet and I call Power of
Three). We would have a meeting a day or two before our IPM.
This would include a tester, the developer pair who would work on
the story, the product owner, and sometimes a UX designer (it was
four or five amigos). We would structure our conversations with
example mapping, a technique from Matt Wynne.
Our hypothesis was something like this:
We hypothesize by having pre-IPM meetings with amigos using
United States of America 95

example mapping
We will build shared understanding of stories
Which will reduce rework
As measured by cycle time being reduced by 25% and rejection rate
reduced by 50% after two iterations

Run the experiment

Example mapping is easy to learn, and we had no trouble orga-

nizing our pre-IPM meetings and inviting the right people. During
the “amigos” meetings, we set a goal for each story - why is it
valuable to the customer? We asked the PO for business rules.
For each business rule, we asked for concrete examples of desired
and undesired behavior. We noted down questions that couldn’t be
answered right then. We example mapped an iteration’s worth of
stories in 30 minutes. We captured this information in the stories
in our online project tracking tool.
In the subsequent IPM, the whole team could read the goal, business
rules and examples for each story. We had further discussions, but
they were much shorter than in the IPMs before we started the
Three Amigos sessions. We cut the time for IPMs in half, while
sharing a much better understanding of the behavior for each story.
As we started work on each story, we used the examples to create
executable acceptance tests.

Evaluate results

We reviewed our cycle time and rejection rate metrics during

the next retrospective, and they had gone down dramatically! We
continued the experiment, and achieved our desired goal quickly.
We decided to keep the amigos meetings with example mapping as
part of our normal routine. Cycle time and rejection rate were no
longer our biggest problem, so we moved on to the next one.
Not every experiment achieves the expected results, but they are
United States of America 96

all successful in that we always learn something. If, after a week

or two, the experiment isn’t moving you towards the goal, it’s not
a big deal - you haven’t invested much time and effort in it yet.
Tweak the experiment, or talk about what you’ve learned and try
another experiment.
Wales, UK
Wales, UK 98

You can do it!

Viv Richards - Wales, UK

“One more year and I’ll be ready..”

Whenever I’ve previously thought about working for myself or

have spoken to others about it, quite often you’ll hear people say,
“one more year and I may try it, but only once I’ve brushed up on x
or y”.
The fact is Nobody knows everything and everybody has their
thing that they are good at. The truth is that if you keep putting
things off, you’ll never feel ready to take the leap. Each year
even after brushing up on ‘x’ that caused you doubt you may still
probably find that you have doubts about ‘y’ and may still suffer
from a little imposter syndrome.
The truth is you may never feel ready but life’s about risks, and
very rarely there’s little reward without taking some.
Wales, UK 99

“I need a degree or qualification in ‘z’ in

order to get that job..”

Sure having a degree or a qualification can help you when applying

for a job and getting through a job application form sift, but once
you get an interview most of the time I’ve found that employers
expect people to also have ‘n’ amount of years’ experience in that
role or with a specific language, tool or framework.
Having experience, I have found can be much more valuable than
spending time gaining qualifications, obtaining certifications and
building up debt along the way. A good friend of mine (Sander
Hoogendoorn) once said in one of his talks - “Sure you can sit a two
day course, pass an exam and become a ‘Scrum Master’, but does
that really make you a master of Scrum?”. It’s practise which really
helps you to master something and can help to set you apart from
others.
Just by having a good attitude, investing in yourself (time – not
always money) it goes a long way and you will find this can open
doors which previously may have been closed or maybe not even
there in the first place. Having the right attitude and investing in
yourself goes a long way.
Once you reach a certain point in your career, from personal
experience I’ve found to a certain extent it has tended to be not
so much what I knew but who I knew which really helped open
doors to new opportunities.
If you do not have experience but are able to attend events try to
network. Show people you’re passionate, you’re there because you
are trying to learn, on your own time, investing in yourself.
Blog if you’re able to, It may seem daunting initially, but if you set
out to blog just even as a self-reference for yourself you’ll be killing
two birds with one stone. That blog post which seems fairly obvious
to you may just help somebody else, or maybe it may help you get
Wales, UK 100

some feedback which may help you learn or change the way you
think about that thing that you shared.
Another way to gain experience may be to consider contributing
to an open source project. If you’re unsure where to start, find a
project on GitHub and start small. Start by making changes to a
README.md file or some documentation. As you become more
confident perhaps help with some code maybe? This is a great way
to gain not only some visibility about what you’re doing in the
community but it’s experience and will help you not only gain
experience but to possible help you get noticed.
It’s also becoming more and more common that employers when
recruiting for jobs in the world of software tend to like to see what
candidates like to do in their spare time. Who do you follow and
what do you post on social media? Do you have a GitHub account?
If so, what pet projects do you have? Do you contribute to any other
projects? Do you have a blog? What books do you read?