Around The World With 80 Software Testers

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-05-25
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
Egypt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
The power of trust and questions in testing . . . . . . . . 14
England, UK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Take responsibility for our testing . . . . . . . . . . . . . 18
What I have learned (the hard way) in testing and in life 21
The day I fell in love with testing . . . . . . . . . . . . . 24
Finland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Fighting Against Automation Isn’t Doing Anyone a Favor 28
France . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Testing is about sharing . . . . . . . . . . . . . . . . . . . 35
Can Software Testing be a calling? . . . . . . . . . . . . . 37
Germany . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CONTENTS
Be the change you want to see . . . . . . . . . . . . . . . 42

Optimize for learning . . . . . . . . . . . . . . . . . . . . 46
Trust in you, your team and QA community . . . . . . . 49
Being lucky . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Gran Canaria, Spain . . . . . . . . . . . . . . . . . . . . . . . 62

Top testing tips . . . . . . . . . . . . . . . . . . . . . . . . 63
Greece . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Be an Asker and Explorer. Be a Tester. . . . . . . . . . . . 68
Hungary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Grow by helping others grow - like a badass. . . . . . . . 72
India . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
From a newborn to a grown-up in QA world . . . . . . . 76
Japan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Reaching “Zero Customer Dissatisfaction” . . . . . . . . 83
It all began with “Space” . . . . . . . . . . . . . . . . . . . 87
Lithuania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Power in authenticity: Being yourself is your superpower 93
Netherlands . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A glimmer of hope . . . . . . . . . . . . . . . . . . . . . . 97
New Caledonia . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Am I where I’m supposed to be? . . . . . . . . . . . . . . 102
New Zealand . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Learn through teaching . . . . . . . . . . . . . . . . . . . 106
Romania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Letter to my fellow tester . . . . . . . . . . . . . . . . . . 112
Scotland, UK . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Don’t limit yourself - focus on growth . . . . . . . . . . . 116
CONTENTS
Serbia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
#10yearschallenge - what I wish I knew before . . . . . . 120
Singapore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Quality is a Team Responsibility . . . . . . . . . . . . . . 124
South Africa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Pushing your own boundaries! . . . . . . . . . . . . . . . 129
Spain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
My software testing journey and involvement with the
testing community . . . . . . . . . . . . . . . . . . 133
Sweden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Journey from dev to tester . . . . . . . . . . . . . . . . . . 140
Tunisia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Starting your journey as a tester . . . . . . . . . . . . . . 145
Turkey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
A drawing compass, a multi-sport athlete, and a multi-
skilled tester . . . . . . . . . . . . . . . . . . . . . . 152
A Collection of Soft Skills for a Tester . . . . . . . . . . . 155
Ukraine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Making test automation better . . . . . . . . . . . . . . . 160
United Arab Emirates . . . . . . . . . . . . . . . . . . . . . . 164

Technological Excellence . . . . . . . . . . . . . . . . . . 165
United States of America . . . . . . . . . . . . . . . . . . . . 168

Improving & learning in small steps . . . . . . . . . . . . 169
Wales, UK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
The art of critical thinking . . . . . . . . . . . . . . . . . 174
You can do it! . . . . . . . . . . . . . . . . . . . . . . . . . 181
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
Egypt
Egypt 14
The power of trust and questions in

testing
Anwar El-Wakil - Egypt
As a software quality control engineer

should you trust a developer?
Short answer, Yes! Now let us dig deeper into why trusting develop-
ers could lead to higher quality and faster delivery. A developer is a
craftsman, a skilled individual driven by passion. Most developers
enjoy what they do for a living. To the extent that a lot of developers
choose coding as their secondary hobby in their free time. They are
proud of what they develop and set high-quality standards for their
work. Nothing feels better than releasing new code that works well
and meets the expectations of the user. The user here could be the
customer, another software, or the developer who developed the
code themselves. This is important to realize. This sets the intention
of the developer as someone who wants to produce high-quality
results.
Egypt 15
A policed process and mistrust results in loss of passion for both

sides. Passion is a crucial ingredient for quality. Our role as QC
is not to police the developed work or be an indicator of the
developer’s efficiency and level of performance. Our role is more of
a support function. We are there to support the developer to deliver
better results. The QC member is on the developers’ side and not
on an opposing side. Together the developer and the QC share the
same goal to deliver high-quality software on time. The intentions
and motivation to do so is equal.
What can you do as a QC member to

capitalize on this mindset?
Well, relax, a relaxed environment with less sense of urgency helps

reduce panic. Panic never benefited quality. Be curious and develop
questions early on. Remember your role is to support the developer.
Your curiosity is needed to open up the horizon in front of the
developer before they write a single line of code. Ask questions
and dive into technical discussions to find answers and eradicate
ambiguity. Unanswered questions and ambiguity are the main
sources of issues and low quality. Trusting the developer to open
up and take part in the discussions with pure intentions adds great
clarity and transparency. Use this transparency to develop better
questions and find answers. You will know that you have achieved
your goal when you have no more questions to ask and that the
work that needs to be done now seems simple to implement.
Leave plenty of space for creativity within an acceptable risk factor.
Letâ€™s agree that if we do not want the loss of quality the best
thing we can do is stop developing altogether. Yet, the main goal
is to keep developing with a lot of passion. Be open and flexible to
new ideas and give the developer the space to be creative. Again
our role is to support the developer to code with confidence. We
are successful in our role when the developer is free of constraint
and can do what they do best. Deliver Quality Code.
Egypt 16
Accept that there is a risk with change and work on reducing the
risk by understanding the change and asking more questions. Next
time you are on a project team up with the developer and use trust,
curiosity, and questions to achieve your goal.
England, UK
England, UK 18
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 19
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 20
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 21
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 22
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 23
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 24
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.
The day I fell in love with testing
Mark Winteringham - England, UK
The day I fell in love with testing
One of the things I love about being a Software testing trainer and
consultant is hearing about how people ‘fell’ into testing. Through
my travels, I have met testers who used to be physicists, nurses,
England, UK 25
Navy engineers, BBQ salesmen and musicians. It’s more the norm
that testers fell into testing than actually taking an academic course
in testing! I’m no different. As I’ve often joked in the past, I wasn’t
supposed to become a tester, I was supposed to become a rock star!
As I was finishing up at university studying music, I had a plan. Get
a job testing games and work my way into the industry so that I
could connect with others and end up writing music for games. Not
the most detailed of plans, and one that was proving to be harder to
implement than I first thought. I struggled to find work as a games
tester as I lacked testing experience, so I took another direction and
started my career as a tester by testing music software. So the plan
was on track, get some experience as a tester, move into games
testing, become a composer. Simple!
However, it all changed one day when I was working in that role
as a junior tester when I was tasked with finding a particularly
thorny bug. The software that I was tasked with testing was a music
notation application, like a word processor for music, that a lot of
respected composers used. One day, we received word from one
of these composers that when they played back their score in our
software, the whole application crashed! Something in the notation
was causing an issue. So the challenge was set and the whole team
was set to discover the issue (this was a high priority fix): find out
what was causing the crash, reproduce the bug. All well and good,
until we were given the score which contained 20 instruments and
was over 10 pages long!
It was overwhelming, to begin with, but I found very quickly that
I got into an analytical flow. Slowly testing the score in different
ways, removing elements and adding them back in to reproduce
the score. After a half-hour, I had managed to discover the source of
the crash. A trill, one of the smallest pieces of notation you can find
in a score was causing the crash as our player couldn’t process it
for playback, thus causing the crash. I was ecstatic! I had found the
elusive bug, and not only that I got my extremely positive feedback
from our developers.
England, UK 26
That was the moment I fell in love with testing. I got to experience
everything that makes testing so fun and rewarding. The desire to
learn how the crash worked, the analysis to discover the problem,
the feeling of being a valued part of my team and earning the
respect of my peers, and helping an end-user with their problem.
Testing is such a varied and interesting role, and that day I got a
taste of all of it all for the first time! I was hooked, and I’ve not
looked back since then. I love testing as much now as I did that day
I found my favourite bug.
Finland
Finland 28
Fighting Against Automation Isn’t

Doing Anyone a Favor
Maaret Pyhäjärvi, Finland
Fighting Against Automation Isn’t Doing

Anyone a Favor
With 25 happy testing years behind me, I can’t help but to reflect
on what I learned about testing after spending two years as an
engineering manager. I learned that while a testers work never
drove me to boring and stupid clicking work, the manager work
surely did - there was little space of variation you can introduce to
approving people’s hour reports and still get the outcome the people
need.
Testing is about variation. Identifying things that could be different,
and intentionally making them different. Keeping your eyes open
when you do so, and when keeping at it, enjoying the gift of
serendipity - lucky accident that brings you the observation of
Finland 29
things that were broken even you did not anticipate! Variation
shows as fast forwarding a year of production, all the different
kinds of uses and scenarios to the short timeframe you spend on
testing. Users stumble on bugs, testers simulate the masses to find
bugs intentionally.
With the love towards spending time with the application, I would
always find the reasons why I did not have time to automate some
of the testing I was doing. After all, I wasn’t repeating the same
things, and automation would force flows that are repeatable. For a
long time, I did not work on implementing automation, but I always
had an opinion that it wasn’t perfect, it wouldn’t do all the things
we aspired for it to do.
Being Vocal Against is Time Away from

Supporting
Given a chance, I would look at metrics showing how little proper

testing automation was doing. I would look at how bugs were
found either without automation or while creating automation (and
testing manually because that is what we need to do to create
automation). I would look at people spending weeks and months
in creating tests that did little to no testing.
Being vocal, I would find myself explaining how it is not all we
hope it would be, and how it never would be all that. I would
spend significant time ensuring that people were aware that 100
% automation was not a worthwhile goal.
Surely, automation did not flourish. I wasn’t helping it, I was
hindering it. I was eating away motivation from people given
the task of figuring out automation. And I was depriving those
people away from the ideas of what and how we could test using
programming that was beyond repeating automatically the same
tests we had run with humans attending them before.
Finland 30
Even though I, an exploratory tester, knew the idea of opportunity

cost - time used on something is time away from something else
- I could not stop myself from investing in the negative, warning
agenda. And I was not alone with this choice of how I invested my
time.
The Best Thing That Happened Was That I

Left (and Returned Later)
Where I work now, we have a really great combination of attended

and unattended testing. Just as we are releasing, we run our test
automation and watch one run with human eyes while automation
is ongoing, to spot things that require human elements. We can
always stop the execution, and move to having manual execu-
tion continue where the automation left off. Automation ticks off
200,000 tests a day, inviting us to explore if it fails and making
space for exploring things where we don’t think automation serves
us best. Automation covers multiple environments and allows a
human to only check the details where it is failing and inviting
exploration.
We’re very happy with the way we do exploratory testing, using
automation as the way of extending our reach by being a platform
of fast-forwarding us to where we need to get, handling masses that
would be hard for people without preprocessing, and doing both
unattended and attended testing. It enables us to make hundreds
of changes fairly quickly, and deliver those changes to production
where they improve the experience of use for millions of our
customers. It’s not that we couldn’t analyse and target testing that
was completely manual, It is that we can use that energy on other
things when automation does some of the harvesting for us.
With what we have now that I have helped build in the last 3,5
years through enabling a team approach to all this, we would not
have if I still used my time against automation. The way I look at it,
Finland 31
one of the best things that happened to this organization is when I

left it earlier in my career while I was still using a cautionary tone,
and allowed for people to freely discover the foundation we built
on when I returned for my second round in the company.
Moving to Automation, the Whole Team

Way
Allowing automation to exist does not mean everyone does au-

tomation the same way. The whole team, together does the testing
that needs doing. There is still room for identifying risks, creating
ideas on how those risks could be targeted in testing, finding new
formulas to test over following existing ones. There’s still work that
requires attending an aspect of testing, even if the execution part
of it was automated. And with software systems as our external
imagination, we need time on the software to think how, beyond
simple bugs, we can make our software better.
Automation has been one part of our transition, another one has
been our attitude to bugs. We don’t prioritize them, we just fix
and forget them. Documenting in automation allows for forgetting.
Again opportunity cost is at play: our users will be happier with a
fix (or a decision not to fix), than us using the same amount of time
on deciding on the right time for fixing.
Your move?
Perhaps you are an automation specialist. Grow better at con-

necting the programming you do for testing purposes into testing
purposes. While automating, you are also exploring. If you allow
yourself to work from a scripted mindset, you miss some of the
power you have at your fingertips with programming for testing
purposes. Work closely with developers, because unit tests can
Finland 32
cover ground you try to cover with your automation. See the whole
picture, not just what you got assigned.
Perhaps you are a manual exploratory tester. Start reading code and
recognizing patterns around how it changes, and how that is related
to what you are testing. Don’t deny yourself the understanding of
what has changed. Start reading automation logs. Start reading test
case names in automation. And most of all, start speaking up about
what you’d like to test and how your programming colleagues
could benefit from what you know about the application we are
testing and the risks of the domain.
Perhaps you are a developer. Spend time with your application and
your users’ problems, and care. Remember you are not alone. The
other developers work with you. The testers work with you. There
is always a second pair of eyes available so that you don’t need
to be left alone with big responsibility. The business opportunity
of having people specializing in testing is that they’d blame the
developer and point out mistakes. It is that together we can con-
dense schedules and achieve a higher level of quality than you could
alone.
Back to My Purposes in a Team
For the last few years, I have been realizing that personally as a
tester, I serve my team in many different ways.
I am a catalyst that enables things that wouldn’t happen without
my presence. For the last two jobs, I have found myself working
with developers who can test, and sometimes what they needed for
that was to look at me and say “You’d want me to click here”.
I am working against inertia and entropy. Inertia is the idea that
we don’t need to change, but just keep ticking away as the process
defines. Entropy is the idea that without continuous effort, things
turn messy. Neither one works in favor of great software.
Finland 33
I raise others, by in addition to reporting bugs, I report achieve-

ments. If there’s something I am proud of, it is the new positions
and raises people around me have received for this work.
But above all, I am a tester. I take joy in finding bugs, finding
information, and getting us together to make good use of that
information. For great products, and for great team productivity.
France
France 35
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 36
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 37
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.
Can Software Testing be a calling?
Stéphane Colson, France

France 38
Can Software Testing be a calling?
Like most of us, I wasn’t born a tester. Even at school, I never

said I wanted to be a tester. As a child, I probably wanted to be
an astronaut or maybe a professional cyclist (the Tour de France
caught up with me). So I started as a land surveyor, making maps
(not mental maps) and preparing land for future airports, sports
buildings, roads, mainly in French Polynesia.
Then I decided to go back to school and learn computer science. My
first job was as a software developer, where I built user interfaces
in C++/Qt. At that time, nobody was testing what I was doing, not
even the code by examining a piece of code. I’d better not check
that code today, which is definitely very crappy! But apparently
the product worked well. It’s magic!
First steps as a tester
After 5 years as a developer, I joined a small team of checkers.

Yes, we were checkers, I don’t say testers or a quality assurance
team, we were just checking. While waiting for the features to be
realized, our main goal was to give a Go or a No-Go by checking
if the product met the specification or not. Of course, this causes
a lot of back and forth and huge problems in production because
our brains were not really used (except that it was a very technical
product, understanding how it worked was very demanding).
What happened next was revealing. Agile methodologies were born
and came into the company and it really helped everyone to do a
better job. Checkers are now starting to be testers, getting involved
earlier and looking for better ways to help and test not only at the
end. New test methodologies were mandatory, new interactions
were needed.
France 39
Am I the only tester in the world?
But it wasn’t enough, I felt very alone in my quest to be a better

tester. I left this company for another one and I was again the only
tester. I felt as if I still couldn’t really master the subject. How
can I find out more about this field? Am I alone? I tried to find
other testers to interact with. In France, I felt really alone. Yes, I
attended the only French “Testing” conference (JFTL) but it was not
a trigger event. This conference was very business oriented, some
topics were interesting but I really felt like I was missing something.
What I did afterwards may seem stupid. I opened a Twitter account
and decided to follow all the testers I could find in the world.
And it was a huge relief, I could find a lot of people and a lot
of communities, blogs, magazines talking about Testing. We were
legion and we started to interact, especially through Ministry Of
Testing and the different Slacks, and still on Twitter. Every topic
was an opportunity to question and learn! Yippee, let’s master the
subject!
Can testing be a calling?
Well, why not, but we can say that this is not the case for most of
us who have many years of experience. At least in France, testing
is just beginning to be taught in some universities and engineering
schools. A few books exist (most of them in English) but they are
nothing in the middle of development books. Training providers
all now have courses on testing, but the content is not always
satisfactory. Most of the time, it will contain the same things as the
ISTQB courses and will offer you to pass (or not) the certification
at the end of it.
Knowing that the goal is certification, the content will be fully
compliant with it, it’s a pity: these “testers” may not have the
necessary state of mind to be a good tester, they will most of the
France 40
time follow recipes and will not adapt to the context. Fortunately,
as I said before, I am not alone anymore (and probably never was,
I was just biased) and most of us are now aware of this. There is
a real community of dynamic testers (this book is a proof of that),
always ready to put themselves in danger to learn and it is clear
that the profession is evolving enormously fast, which makes it
exciting. And in saying this, I’m not just talking about the trend
towards automation: there is still a lot of room for exploratory
testing, security, performance, user, accessibility and the products
being tested are becoming more and more complex and constantly
evolving.
Is there a single tester who gets bored in this business? I don’t think
so, and if there is, it’s probably because they are not in the right
place and just need to move.
Germany
Germany 42
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 43
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 44
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 45
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 46
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 47
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 48
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 49
stay curious and optimize for learning.
Trust in you, your team and QA

community
Mariia Hutsuk - Germany
Trust in you, your team and QA community

Let’s go back in time and space to Kyiv, Ukraine 2011. You would see
me there studying Software engineering in the university. I already
understood that my vocation is testing and started looking for my
first job. After several interviews I got my first job offer. It was
an opportunity to become the QA in that company. I rejected the
job offer because I had a fear of not being able to handle it alone.
I thought that developers from the team may not help me on QA
topics.
What advice do I want to give me back to that time? Trust in you,
your team and QA community.
Germany 50
Trust in you
• Be brave.
It is better to regret something done rather than lose opportunities.

Start learning by doing and don’t allow your fear to limit your
possibilities.
• Look for a job based on potential, not experience.
When applying for a new position always be open to new things

and select the role with some space for growth. Being an overqual-
ified specialist you can become bored and no longer passionate
about what you are doing. By leaving this space, you leave some
uncertainty. However you would have an opportunity to grow by
taking this risk.
• Stretch yourself
Set ambitious goals in areas, which you like and want to evolve.
Everything is possible if your work becomes your hobby and you
enjoy it. Just allow yourself to think big and you can achieve really
incredible goals.
Trust in your team

• You can not know everything, your team would help
Being a lone QA in a cross-functional developmental team is very

common in the modern Agile world. If you are starting your
journey as QA you may have a lot of open questions. The same
challenge is faced even by experienced QAs after changing business
domain or the technology stack. Don’t be afraid, your team will
help you with any challenges.
Germany 51
• Share the quality responsibility with a team
One of the most important features of a good QA is being responsi-

ble, but not hyper responsible. You can be surrounded by specialists
in the domain being tested. The team collaboration effort would
make the product more reliable and testing more efficient.
• Give and receive the gift of feedback
Learn to give actionable feedback respectfully. Start receiving feed-

back with a curious mindset. The motivational and developmental
feedbacks are very powerful tools. They would help to grow.
Trust in QA community
• Become part of QA community
Jim Rohn said that we are the average of the five people we spend
the most time with. What if we would be surrounded by passionate
quality specialists? Attend Meetups and conferences. You also can
become part of the QA community by following different speakers
and coaches on Linkedin, Medium, Twitter or by regularly checking
some blogs. By becoming part of the QA community you would get
a lot of inspiration and knowledge.
• Network ethically
The people around you can support you and inform you about
something new in the industry - connect with proper specialists.
However the ethical networking is not self serving, it is about
giving. Invest in your education to become interesting and useful
to others. If you only read one article about some topic, it’s very
difficult to network with famous speakers about it. Maybe you
Germany 52
may have luck and the specialist in that area can give you an
informational interview. However this is not networking. Find
people at your level and start helping each other.
• Find a mentor and become a mentor
Very often you will need to do completely new tasks. You can
struggle even with what to do first. Try to find a mentor in
your network or in the organisation you work. Some people are
mentoring others on a volunteering basis or to get their own
experience of mentorship. Don’t hesitate to become a mentor as
well on the topics you know.
Would I really give this advice?
If I really had met me in the past, I would not advise anything to

break the space time continuum. My life experience has made me
who I am. Thanks to that job offer decline I have learned a lot. In
2015 I had another great opportunity to relocate to Germany, again
in a startup as a first QA in a company. I did not allow my fears
to make me reject this opportunity because I started to trust in me,
my team and QA community.
What about the future? We are owners of the future. Let’s be brave,
set ambitious goals and start collaborating with people all around.
It truly takes a village to raise children. Let’s build our village.
Germany 53
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.
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.
Germany 54
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.
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.
Germany 55
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 56
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 57
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 58
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 59
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 60
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 61
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 63
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.
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
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.
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.
Greece
Greece 68
Be an Asker and Explorer. Be a

Tester.
Plakogiannis Petros, Greece
Be an Asker and Explorer. Be a Tester.
I suppose my passion for testing started back in the ’80s when I was
a child with my first computer that was the legendary Amstrad 6128
CPC.
I remember I wanted to rip open the computer monitor and see
what’s inside. I guess this was my first time exploratory testing.
When I was out of university, I had no idea what testing was. I still
remember my first interview in one of the most famous companies
in the world (with a 3-letter logo) that I rejected a position in
because I said, “Software Testing? What is it? No, thanks.”
The next month I got my first job as a tester in a different company.
Since then, I have worked as a Software Tester. To be more precise,
I have been working as a professional software tester for over a
Greece 69
decade, and I have tried during these years to learn something new
every day. However, I have to mention that the journey from being
a junior manual tester to someone who can set up an automation
framework from scratch was long.
In Greece, back in the late 2000s, software testing was not so
popular. It was hard to find information sources if you wanted
to learn a new testing technique or an automation tool. This
was an issue because, as testers, we all should improve our work
continuously.
A lesson that I learned is that teamwork and collaboration are
essential. I do recall the day when a software developer told me
about cross-site scripting (XSS) attacks. I injected a script into the
login form of a web-page, and magically the page crashed! It was
enlightening to see it. When I went back home, I stayed up all night
trying to crash all the pages with XSS attacks. I found so many bugs
that the next day I received recognition from my manager for doing
good work.
So my first piece of advice is as a software tester, you have to dare
to ask questions, try to find a mentor that can inspire you, ask for
feedback and help.
My second piece of advice is that you should not worry about
failures, and believe me in the beginning you probably would have
a lot. The first time that I set up an automation framework, my code
was just ugly.. spaghetti code. Try to learn from your failures and
mistakes, gain experience so you can be better in the future.
In the first years of my career as a junior tester, I always had in my
mind how I can improve my skills. I kept asking why there is not a
community or a support network of people in Greece that can help
you and encourage you regarding software testing?
The years have passed, and one day I said to myself that I couldn’t
sit back. I had to do something about it. I found out about the
Ministry of Testing in the Selenium Conference in London in 2016.
When I arrived at the venue, I saw the banner of the Ministry of
Greece 70
Testing. After some short talks with the guys there, I found myself
longing for making more and more people in Greece aware of this
community. The decision to run the local meetup was taken.
Now there is a Greek community that we all share knowledge and
experience to teach and learn about software testing. If I have a
question, I go to the slack channel and ask.
So my third piece of advice is the following one. Try to find a testing
community. Go to meetups. Community is not an ideal; it is people.
Meetups are about members of the community rooting for each
other, learning together, searching for opportunities, and helping
each other find them.
Hungary
Hungary 72
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 73
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 74
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
India
India 76
From a newborn to a grown-up in

QA world
Nithin SS - India
What I learned as a Newborn:
When I finished my studies and started looking for a job, it was

really a dilemma which one to choose, to be a Dev or QA or Support
or something else in the so-called IT industry which was unknown
to me at that time.
I won’t really say that it was I who chose QA as my career, it
happened. Before the job interview, I was also totally blank on what
QA does!!! All I knew was some programming languages and OOPS
concepts.
It was my second interview, I attended along with a few others.
Nervousness was at its peak which increased twice after knowing
that they all came for the interview after completing a Software
testing course(certified one). I really felt like an odd one out! And
India 77
they were discussing a lot about Blackbox, Whitebox, Decision

coverage, etc. I was like, am I supposed to be here for this. All I knew
was just a few questions I googled the day before for a beginner QA
engineer interview.
After a couple of assessments and a written test, they called me
in. It was the last round and the interviewer was the CEO of that
company. And, it went quite well (As he asked more around logical
and analytical questions). I was asking him more than what he did
to give better clarity on my responses (which I came to know later,
as one of the important traits of a good tester: Always ask for
clarity & Questioning mindset)
So from the initial thoughts: a QA is either a frustrated developer or
one who doesn’t like coding. As my career progressed, I was able
to learn a lot and realize all these were just MYTHS which I had
during the initial days. Today I will say, whoever still repeats this,
has no idea what it is like to be an agile QA within a team.
However, now the focus is on passing on my knowledge to others
and acting as a quality ambassador to let everyone know that QA is
beyond the usual phrase of “Pass it to the QA column then I will
test it”
During the initial days, we were going through the documents and
understanding the application. I still remember, for all standup’s
we new joiners had the same status “Exploring the Application”
(Which is quite important for a tester).
As days progressed, I was slowly getting into more ice-breaking
activities and glued to the team. Then, it was the phase of knowing
the unknowns: Agile, Scrum, Functional Tests, Test Documenta-
tion, Bug Reporting, Exploratory Tests, Process, and the Blackbox
and white box concepts. It was really a good phase for me and my
peers were all helpful in guiding me well. Actually, that’s what
helped me to be what I am today.
‘A building without a strong foundation is always weak’, likewise
you should always be strong on the basics, then only you can
India 78
flourish in your career. So in your early stages of career journey

try to learn as much as possible.
One of the biggest challenges of a QA is to make the team feel like
you are a member of the team, not a separate person who always
comes with bad news. To change this attitude is a huge challenge
and really involves dealing with people a lot, which is not always
easy. You need to have a match and show the real value of you
within the team. In other words, pass on the quality mindset you
have to the rest of the team.
Today if someone asks me how a QA should progress in the initial
stage then I would say:
• Understand the architecture of your platform

• Understand the application targeted users
• Know how your platform works
• Keep your basics strong
• Know the breakdown of systems
• Guide for each platform
• Understand Workflows, User Journey documents, etc
• Know about the project life cycle
• Learn the difference between functional & non-functional
tests conducted
• Pay attention to unexpected events while testing.
So then came my first transition. Involving more than what I

was doing before. I won’t say it’s manual to automation. It was
learning something new to help our testing activities or career
growth.
At first, I did automation with record and playback using Selenium
IDE. And I thought that automation was just that simple and no
coding. But later I realized that it was just my baby steps.
The first task was to import the IDE script to Java Selenium in a
linear flow(which was literally a mess). Then arrange it to a page
India 79
object model. Then came data-driven and then came hierarchy,

reusability, and reporting, etc. My curiosity increased as my scripts
were passing the test and showing green color. Then I learned to
fix the scripts and progress. Without failures, we never learn. So,
when you automate something don’t always expect for green/pass.
Let it fail, we can analyze why it failed and then we fix it. Cool!
Failures are the building blocks to your success!!!
Also, challenge yourself to be a better version of yourself every
day.
Learning automation helped me a lot to improve my technical
skills. I used to pair with my developer friends as well to improve
my coding skills. But it is very important that both of you realize
that you work as a team and that the combinations will make a
difference in the final product.
Therefore, in this relationship, there must be a partnership, one
helping the other so that we can perform our work in the best
possible way. That’s the spirit. Collaboration & Communication!
Working collaboratively with different teams, that is, being mul-
tidisciplinary
Because, when you win, the team wins, the company wins.
What I learned when I stepped into

adulthood:
It was time, I wanted to explore new business domains in testing.

My eagerness made me look for new opportunities, where I got
a chance to work with several projects, the latest technologies,
and even was involved in the panel which worked for CMMI for
the organization (Actually that was my first task after joining).
It was a new learning for me, other than the testing skills I got
to learn about industry standards, processes, workflows, CMMI
guidelines, etc. I would like to highlight a few domains which I
India 80
worked on those days, AI-enabled content management platform,

where I was working and collaborating with a fully remote team (It
was the basics from where I learned how important collaboration
is when working remotely, which helps during these lockdown
days). Another one was a VOD platform for kids, where I had to set
the benchmarks and guidelines to test the VOD platform. It really
taught me how we should think as real end-users while testing. And
in one project I could learn reverse engineering to understand the
codebase/flows and to be a hybrid tester(PM+BA+QA).
We QA’s are not real end-users, but we need to know our
targeted audience to deliver a better product to the customer.
So the newborn stage helped me to strengthen my basics and mold
me as a tester. And then when I stepped into adulthood in QA, I
gained more technical skills along with being a hybrid version of
myself.
Being an adult:
When we become an adult, we always try to go beyond our comfort

zone right? So, it was my turn to do the same. I decided to try
something beyond my comfort zone and shifted to Malaysia. And
this phase helped me to shape myself to wear a modern QA cap by
extending my knowledge in risk based testing, personas, oracles, etc
to also evolve into a Quality Advocate rather than being a tester.
Also, I got more involved in the community. I believe that this phase
is trying to bring out the best in me.
New beginnings happen when you step out of your comfort
zone…
I know that there are a lot of QAs who are still not active in any
community, who are afraid to move out of their comfort zone, who
are confused to express their feelings. I tried to think beyond my
normal job scope or profile and started an initiative by creating a
India 81
blog platform for the community with a vision: Learn, Share, and
Grow Together.
I am still learning, and I do believe that known is a drop and
unknown is an ocean. Try to explore the unknown, and find the
inner you…
Finally, believe in yourself and always seek improvements!
Japan
Japan 83
Reaching “Zero Customer

Dissatisfaction”
Fumikazu Fujiwara - Japan
Why am I a tester
Ever since I was a child, I had a vague idea that I wanted to do a
job that would help a lot of people.
I started working in an internet service company as a new graduate
and was a web developer for E-Commerce service.
One day when I got to work, I faced big system trouble, I logged
on to a server and saw the logs flowing through the terminal at an
alarming rate.
There were two things in my mind:
1. In spite of this situation I thought my dreams had come true

because the terminal said you have a massive number of
users.
Japan 84
2. I’m doing a very responsible job, a small quality issue will

cause a big problem.
After all, why did I choose to work in testing and quality?

This has a lot to do with the environment of Japan.
“Made in Japan” means that “Japan QA” is more Quality Con-
trolled.
There are many communities that actively create technology inside
and outside the company.
The term “quality circles” and many other activities are also from
Japan.
From the environmental point of view, this is the best choice to
grow myself to reach the career goal.
That’s why I am a Tester and QA in a Japanese Internet company
Rakuten, Inc. which has tens of millions of users.
3 important things for testers from my

experience
I think ultimately a testers mission is “Zero Customer Dissatisfac-

tion”. I do not stick to any particular method to achieve this goal.
People may think “QA = Quality Test Work”. However, actually QA
has a wider range of work.
I approach it by breaking it down into the following 3 parts.
No Broken, No Downtime and No Struggle
No Broken
The following are examples of things that shouldn’t be.

Imagine that in a golf course booking service the user is unable to
Japan 85
book a golf course correctly, or the booking result shows a different

course which is not the booked one, or maybe in a hair salon
booking the search result shows a different list of salons which
don’t match the search conditions.
With such kind of issues, we might lose a user’s satisfaction and
trust easily. These are basic things but QA is a very important task
not only for users but also for protecting your product brand.
No Downtime
Even if it’s not broken, you might face trouble during downtime.
For example, in a gambling betting service, the server might be
overloaded every time when the voting deadline is closed and
people cannot buy a ticket, or the screen might be slow due to
unexpected access because of some big campaign and so “No down
time” is one of the key missions that should be accomplished by
QA.
No Struggle
The final one is preventing user struggles (stress).

For example, if there is an element which appears to be a button on
your page, and the user wants to click it, but unfortunately it’s not
a button so nothing happens when it’s clicked. The button-like UI
confuses users.
We analyze user behavior which is recorded by logs and data to find
out the struggle point in our product, and then give some feedback
to the Product owners based on the analytics. It’s also one of the
essential tasks for QA.
Japan 86
Conclusion
I believe that “Zero Customer Dissatisfaction” can only be achieved

if all the three points are met.
We don’t hesitate to use various methods in order to achieve our
mission.
The reason why “Made in Japan” good quality products are recog-
nized around the world is not only because of their function, but
also because of their quality.
This concept can be adopted for software products as well.
I would be very happy if this article can give you some guidance or
let you take some action as a tester.
In Japan, also there are exciting communities of testers called JaSST
(Japan Symposium on Software Testing), and many people who are
actively creating various testing technologies.
Why don’t you take this opportunity to take a look at our Japanese
testers?
Japan 87
It all began with “Space”
Sahithi Gundu - Japan
It all began with “Space”
Those were the days, I joined as a Fresher. We attended a “Freshers

Seminar on Testing” conducted by QA Head of the organization,
Mr. Labani. He asked us a rapid question at the end of the session
- “How do you create a strong password thats hackers feel hard to
crack ”.
Responses like “alphanumeric”, “alphanumeric+special characters”
etc are heard from participants. Mr. Labani listened but wasn’t
happy with those answers yet. Meanwhile I was keen to examine
the keyboard and analyze what keys would make a strong pass-
word. And then..,
“Space” I responded. “Adding a space in the password could make
hacking hard” I added. He was very impressed and appreciated
my reasonable opinion. I expressed an interest in moving into the
Japan 88
Testing field. He accepted and brought me to his team, which is to

build a new “xAFT” test automation tool.
My career began there as a Software Automation Test Engineer.
Unique approach matters:
I’d say, “The more you come-up with unique user perspective
scenarios, the best quality deliverables would be”
Every tester will follow the workflow which the product is built
for. I accept since this is a simple prerequisite. But I strongly believe
that the best quality product can be built once the tester cerebrates
out of the box. Testers should be able to think both from an end-
users perspective and also what users would do in this particular
workflow? Is there any other possible way users use the product,
other than the developed basic workflow.
Lets say: e-commerce domain application - Account Signup.
E.g. 1. User fills out all the necessary Sign-up fields & clicks
“Submit”
This is the basic workflow which the Dev team developed. Here
anyway testers will test with techniques such as: Boundary Value
analysis, Equivalence Class Partitioning, State Transition Criteria,
Blank / Null value inputs etc..; these are the fundamentals to be
observed by testers. Now let’s see other instances that users usually
experience during this workflow.
E.g. 2. User fills appropriate fields of Sign-up & clicks “Submit”.
Scenario: Suppose the user manually clicks the back button while
the page is loading, or clicks force refresh, or the cancel button, or
if the network failure occurs during submission.
In this case of interference, we need to check whether the user’s
submitted data is registered in the database or not. These are just
several possible scenarios that might arise at the users end.
Japan 89
Testers need to think differently by estimating test possibilities and

checking them appropriately.
Each form of Testing has its own Value:
Some have the impression that in the current situation automation

testing is the most preferred Testing type. Yes at the moment as
the need for precision increases automation is coming into effect.
Nevertheless, when it comes to practice, I believe that - “Every form
of testing has its own shine.”
Manual Testing is the basic and initial testing practiced while
testing an application. Whereas in testing few applications, Manual
testing could be the “Only” prefered testing method rather than
automation testing. The same strategy applies to API, Security and
Performance testing. In fact, businesses such as e-commerce would
prefer performance testing to make the application user friendly.
Companies such as the Bank and the Financial Sector rely primarily
on security testing along with other forms of testing.
Hence the key summary I’d like to project here is - “Every type of
test has its own preference and shine”. So I recommend that testers
need to have a basic knowledge of all forms of testing, so they can
determine which form of testing they want to pick and dive deep
into.
Experience is Knowledge:
Testing helps us to learn from our own experience. The more we test
& dig in, the more it improves the quality of the end product. When
we work on different projects and clients, “Testers need to regard
any obstacle encountered, as the next move toward their milestone”.
Create the test scenarios with all your experience and implement
new scenarios thinking out-of-box.
Japan 90
A tester must thoroughly understand the requirements of the client,

and evaluate how the specification will be tested. What are the tools
we should use to test the application & which implementation will
be beneficial.
Precision:
The tester will usually find issues while testing an Application.

Often these identified Issues could be denied by the dev team
when reported. If you are positive that this particular issue will
impact the application in one or another way, be precise !! when
communicating with your boss or client regarding the issues you’ve
found.
“Since few bugs are often not found until we implement

a range of test scenarios within the customer needs”.
So testers must be precise with bug logs and screenshots explaining

more specifically about the issues found.
Failure is Learning
There is no perfect imaginable product. Once the product is tested

and is flawless, its released. After the product is released, we still
notice some issues that consumers or users face.
At the end of the day, users will use the application in “n” number
of ways. Therefore, these issues raised must be treated as the un-
covered testing zones from a tester’s perspective. We must consider
this as learning and bring what we have learned into action in the
following test builds.
This “nth” issue once fixed & tested, then we can call the product
as a complete Quality Deliverable.
Japan 91
I’d finish by saying - “Quality Assurance plays the major role in

building a product. In this tester’s Experience and Learning is the
key towards a successful career. Keep going”.
Lithuania
Lithuania 93
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 94
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 95
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 97
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 98
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 99
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 100
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 102
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 103
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 104
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 106
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 107
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 108
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 109
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 110
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!
Romania
Romania 112
Letter to my fellow tester
Mihaela Sfat - Romania
Letter to my fellow tester

Don’t be shy. Let your voice be heard.
Why? Because your voice is valuable and your opinion matters.
I worked a lot during the past few years trying to empower you,
to help you let your voice be heard. But some of you still preferred
to remain quiet, as if opening your mouth to say your opinion was
the last thing in the world you would do.
Do you think you’re an impostor in the software development
team? Don’t worry, we all feel that at certain points in our careers,
no matter if we’re developers, project managers, business analysts,
designers, you name it.
The impostor syndrome can affect anyone.
But why you, my fellow tester, why do you pick the silence when
your voice would make such a difference if heard?
Romania 113
Well… Maybe due to misconceptions?
Misconceptions
It is well known that some people and companies are seeing your
relationship with the developers as a continuous battle, as the
developers are the ones working to build something and you to
break it. More than that, you, my fellow tester, might get to be
marginalised by the fact that you are the “breaker of the system”
and your role is not as important as the constructor’s (developer)
is.
Not even it’s a bad approach and an unhealthy way of looking at
the tester - developer relationship, but might give you a poor self
esteem, making you avoid giving an opinion as you might think
you are not good enough or you are not having the power to speak.
Wrong!
Misconceptions are affecting your voice as a tester.
Since you’re afraid to speak as you’re considering yourself as not
being as good or as valuable as a developer is, you’re prone to end
up making the following mistakes.
Let’s have some examples.
• You’re in the middle of the planning meeting and everyone

is talking about estimations, developers are throwing some
numbers based on complexity considerations, but you are not
saying anything. Why? Because someone said at some point
that testers should not evaluate the complexity of the work
that needs to be done, that is a developer’s role to do that.
Well, it is not only developers’ role, but an estimation should
also contain the effort that is made by both developers and
testers to deliver a certain piece of work.
• You’re not asking questions as you are afraid of looking stupid
as you are not as technical as a developer is. So? That’s the
Romania 114
beauty of having diverse roles in a team, great things might

be revealed exactly by those non-technical questions that you
are asking. And in the end, why is it so bad to ask a question
to make things more clear to you? For me, it is a sign that you
want to evolve, to learn more, to do more to help your team.
At certain points in time, everybody is asking a question to
which the rest of the team is already knowing the answer.
• The go-live is approaching, you’re still having things to be
tested and you are pressed by your superior to give the green-
light so the features to be released. Nothing fancy, this is
happening frequently. But you are not saying anything about
the risks that you’re seeing, being afraid of not being able to
justify your concerns of postponing the release for a bit. Well,
my dear tester, in this situation it is more dangerous to remain
silent than to speak up loud about your concerns.
• You’re receiving the features to be tested when there is not
enough time left until the end of the sprint and you are not
complaining about it. Pointing the finger or making a drama
out of this situation is not ideal, but ignoring it and making
everything possible to finish your work in a time record is not
helping you. Talk to your team, find together some ways to
avoid having the features given to you to be tested so late in
the delivery process.
• Specifications are not clear and you have to test the fea-
tures based on these. Don’t make assumptions with regards
to specifications. Rather than making assumptions, get the
courage to ask all the questions, with the risk of you looking
vulnerable, just to be sure you’re testing what is needed to be
tested.
This letter is for you, my dear tester, and for the silent tester I used
to be too, years ago.
Scotland, UK
Scotland, UK 116
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 117
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 118
to learn and continue to grow.

Serbia
Serbia 120
#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 121
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 122
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!
Singapore
Singapore 124
Quality is a Team Responsibility
Lavanya Mohan - Singapore
Quality is a Team Responsibility
Heaving a sigh of relief after deploying a hotfix, Maira and Rob step
out of the “war-room” - a meeting room in their office dedicated
for people who are dealing with production outages and issues.
As they walk back to their desks, Kayla, the Product Manager, calls
for a quick meeting to brainstorm ways of avoiding such issues in
the future.
Rob starts by explaining details about the issue and what he
did to fix it. He continues, “Maira tested my fix on the staging
environment sometime back and she gave a sign off. So I went
ahead with the deployment to production. She also verified the fix
on production post deployment. So the issue should be resolved
now”.
“When and how did we detect the issue?”, asks Kayla. “The cus-
Singapore 125
tomer support agents received a lot of complaints from our users

this morning shortly after our service deployment. They escalated
the issue and then we started looking at it”, replies Rob.
“But why was this not caught in the regular testing that we do
before every deployment?”, asks the curious Amisha. “Isn’t this one
of the most important regression testing cases that the QAs should
cover?”
“We weren’t aware of this particular change that went in today. It
wasn’t planned. So, we did not check that part of the system as we
thought it was unchanged”, justified Maira.
“My suggestion to avoid these types of issues in the future is for
QAs to look at commits in the project so that they understand the
areas that are changed. Also, this critical case should be tested by
the QAs before every deployment”, says Amisha.
Everyone agrees and the meeting ends.
Is this a good solution to prevent such problems in the future?
Let’s look at some of the problems in this team which are
potentially relatable to us on our projects too.
Unplanned and Untracked Changes
Many times, the engineering teams or some of the “more helpful

team members” directly get unplanned change requests that are
urgent and critical in nature. When some of the low risk changes
seem easily doable, the helpful team members may go ahead and
make the changes without checking whether the key stakeholders
are informed about it.
Such unplanned or untracked changes, irrespective of how small or
important, have a potential to cause great damage.
In small teams, having processes to track changes might feel like an
added overhead. Irrespective of how the teams decide to manage it,
it is imperative that all the stakeholders are aware of the changes
Singapore 126
being done and the risk areas are assessed before the changes are
made.
Testing Critical Features Late in the

Feedback Cycle
Most teams understand the importance of ensuring that new changes

do not cause unexpected behaviours in the older functionality.
But not everyone sees the importance of receiving feedback about
unexpected behaviours early.
Even today, some teams rely solely on their QAs to verify the
correctness of the entire systems before every release. This causes
not only a considerable amount of back and forth and delay in
releases; but also immense strain on the wellbeing of team members
in the long run.
We, as a team, should ensure that unexpected behaviours are caught
as early as possible. Whenever an issue is found in a particular layer
of the Test Pyramid, we should assess whether it can be detected at
a layer below and then take appropriate action.
Getting good feedback about the systems as early as possible should
be the team’s responsibility.
Lack of Effective Monitoring and Analytics
Products are complex and users use them in unexpected ways.

Due to this, we might discover some new issues or failures in
production. How quickly we detect and react to the issues is crucial
for businesses. Does our team detect some issues ourselves or do we
always need customer support agents to inform us?
Monitoring and alerting systems, analytics data which give insights
into potential issues are important for the entire team.
Singapore 127
QAs being the sole owners of quality
“Why was this not caught in your testing?” is a question that

QAs get asked often in some teams. This causes core underlying
problems to often get overlooked.
If an issue was not detected during testing, it was also not detected
by any automated tests or during code reviews. It was not men-
tioned as a risk area by anyone in the team during requirement
discussions.
Doesn’t this mean the problem lies in multiple places and not just
with the QAs who didn’t test a scenario?
For overall quality of the product, the teams need to ensure quality
in all different stages - quality of discussions and meetings, quality
of code, quality of automated tests, quality of exploratory tests,
quality of monitoring and alerting systems, etc.
Quality is a team’s collective responsibility.
South Africa
South Africa 129
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 130
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 131
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.
Spain
Spain 133
My software testing journey and

involvement with the testing
community
Trisha Chetani, Spain
My software testing journey and

involvement with the testing community
I took my first job as a software tester. Because it was my first job,

I did not know how to work and what software testers should do.
Since I was inexperienced, my first goal was to learn about software
testing, which I achieved by allowing my manager and teammates
to help me gain a better understanding on how to research, learn
and apply the concepts required to do my job.
Because I was learning to test software better, I found online classes
and attended.Sessions took place online, led by Ajay Balamuru-
gadas and conducted over Skype. This was among one of the best
Spain 134
things I did to this day in pursuit of my software testing career

goals.
I started joining the morning sessions where Ajay helped various
testers to learn the concepts of software testing and how to perform
and report test activities. Ajay usually asked, “Who is the least
experienced person in a team?”. He went on to instruct the morning
session group to have the least experienced tester organize every-
thing in the team and send the report back to him. Considering I
was the least experienced person, I got the opportunity to be more
involved and engage more.
During this time I got introduced to Srinivas Kadiyala who helped
me learn how to organize the test team. Srinivas also helped me to
correctly report back to Ajay.
After joining a couple of sessions by Ajay, over time these sessions
started slowing down. However, having met and worked with
Srinivas, he introduced me to “Weekend testing India” sessions.
At the very beginning, I was very afraid, seeing so many experi-
enced people discussing the same concepts. But eventually, I started
to find they were all very encouraging to newcomers like myself
and invited me to join discussions and share my opinions. The
facilitators were very nice and ensured everyone got engaged. More
and more, I got involved in the conversations, and it was a great
opportunity to collaborate with so many people and learn from
them.
Later, I explored ‘Weekend testing Europe’, ‘Weekend testing Aus-
tralia’ and ‘Weekend testing America’. This was how I got to
interact with so many passionate testers around the globe, all
coming together to share their knowledge and experiences on any
one topic presented each week. With so many different topics from
so many regions, it was so much fun learning along with them.
Test automation and Selenium was the hype at the time. Week-
end testing sessions enabled me to learn about test automation
by having Dwarika Dish Mishra as a presenter. With a strong
Spain 135
interest, I approached Dwarika post-session asking him for help.

I have learned a lot from Dwarika about test automation and this
enabled me to get started with test automation at that particular
time of time. I have gained deep knowledge of mobile testing
from Ajay Balamurugadas and Jean Ann Harrison. We had several
online sessions with some exercises. I got the opportunity to learn
about performance testing from Mark Tomlinson. Mark helped me
understand the basics and develop the performance pipeline for a
team.
I received selenium conference tickets from Richard Bradshaw with
the help of Srinivas Kadiyala. Attending the conference was super
helpful and enabled me to meet many automation experts around
the globe. I attended sessions and workshops and they were super
helpful. I got the opportunity to participate in a competition. I also
attended and facilitated a bug bash session with the help of Jyothi
Rangaiah. Though it was my first time being in a conference, I got
the opportunity to contribute by facilitating the bug bash.
The Weekend testing sessions allowed me to learn about more
places. I could collaborate with more testers. From there, I joined a
Skype group named 24x7 Software Testing, along with Women in
Testing. Again, it was fun seeing so many passionate testers being
so open and helpful.
I started asking questions in all my sessions to learn more from
them, and they were so open and understanding, providing the
whole context of their experiences along with their opinions. This
is where I took the opportunity to engage further by having
many 1 on 1 conversations along with group conversations that
included testers from around the globe. As a result, I cannot name
everyone from these sessions and conversations, everyone was so
very helpful. I started getting recognition from the community and
got the honour of being named in the “Next 125 Awesome Testers”
featured in the Agile Testing Days blog. Maaret Pyhäjärvi led this
initiative which included several other community members.
Spain 136
I have received the help from Michael Bolton. He helped me

understand the roles of a software tester and that they are not
gatekeepers. Because my focus was on how, when, and why to do
the test I started to expand my knowledge. Anna Royzman offered
me help to develop the test strategy for a team.
Skype groups have been shifting into Slack groups, as Slack has
more functionality for better collaboration. My Slack groups in-
clude the Ministry of Testing, Women in Testing, and Rapid Soft-
ware Testing to name just a few. Now every meetup has its own
Slack and Facebook group to enable collaboration with more and
more people. It is really fun to be with the same people for such a
long time and learn from them. I see a lot of open conversations
from various testers that gives me more opportunities to continu-
ously learn. I enjoy being a part of a great community of software
testers. I have so much gratitude for being involved and a part of
the community.
I was introduced to Twitter by Souvik Ray. Twitter is a platform
which has always been there for software testers. I started following
software testers on twitter. I have been reading their tweets on and
off. Over a while following testers and reading their tweets has
also helped me to develop my knowledge on testing skills. Having
conversations hosted by the Ministry of Testing has been a very
good platform to collaborate with a lot of testers.The tweets that
engaged me the most on twitter were those from testers who shared
their learning and experiences in order to help others. It helped me
to be more engaged on twitter seeking the information relevant to
my interest. I also started sharing about the event by doing live
tweets and sharing my learnings. I also help testers whenever I see
tweets seeking help where I can help them.
Being involved with the community I have not only learned about
software testing and test automation. I have gotten the opportunity
to identify most recommended books and read the same books and
blogs, learn how to communicate better, build relationships, write
abstracts, and to speak at conferences. Gratitude to Ashley Huns-
Spain 137
berger for motivating me to do public speaking. Ashley encourages

new speakers to submit the abstract by offering help. Software
testers who mentored me on public speaking were Kristine Cor-
bus(@tech_voices), Richard Bradshaw, Mike Lyles and Matthew
Heusser. They were so helpful and inspirational. Everyone in the
community was so approachable to review my slides and offer
feedback even though I was getting feedback from Richard Brad-
shaw and Kristine Corbus. Richard Bradshaw helped me to learn
how to write an abstract, how to transition from abstract to slides,
how to speak it as a story and how to practice. I presented the
same talk at a meetup to get feedback from the audience at the
meetup group. Richard appreciated the feedback and helped me to
incorporate the feedback. I have learned from Kristine sharing ‘be
yourself’, how could I share the same story with 5 mins, 10 mins,
15 mins, record yourself and test yourself. I asked for help from
Maaret Pyhäjärvi and Elisabeth Hocke and they accepted it. They
gave me their valuable time watching me practising and sharing
their feedback. Angie Jones and Ashley Hunsberger helped me with
abstract reviews, Lisa Crispin and Ajay helped me with slides. I
found conference organizers were so nice and approachable. I spoke
at CAST 2019, and Maria Kedemo being a conference organiser was
so helpful with her suggestions. Mike and Matthew are helping me
with the abstract now.
I also developed a habit of listening to podcasts. I even got a solution
for a problem from the by@perfbytes podcasts for a question I
posted. I am also learning how to facilitate groups by being involved
in so many. I am learning about leadership skills from Michael
Ruderman since he likes teaching and he is open to helping people
around the world.
I would like to share some improvements where the software
testing community helped me to be more aware by giving open
feedback. I got feedback from my mentor to be more credible. I
started reflecting and realized I was not credible enough. I started
being convincing to people whenever they offer help and this
Spain 138
encouraged the community to collaborate more. At the beginning

of my journey, some of my questions were very broad. As I learned
to narrow them, my credibility increased. I am paying it forward by
helping testers currently. Testers are enjoying receiving help from
me.
Gratitude to Abby Bangser for motivating me to contribute to this
book by Viv. Gratitude to Janet Gregory, Ajay, Jyothi, Viv to offer
me the help with reviews and suggestions. It helped me to unlock
one more milestone.
I am leaving you all with an attitude that constant learning and
being involved in the community can constantly help you in
identifying and developing so many skills.
Sweden
Sweden 140
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 141
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 142
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 143
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.
Tunisia
Tunisia 145
Starting your journey as a tester
Emna Ayadi - Tunisia
Starting your journey as a tester

When Viv Asked me to contribute to this book about something
during the past 5 years, I realised that 5 years ago I was student,
that’s why I wanted to talk about my first step as a tester and how
my passion to testing is growing day after day.
My first Step as a Tester

I started testing just after graduation in August 2015. To be honest
I got this job proposal randomly because I have some knowledge
on finance with a computer science engineering background and
without knowing in depth what the tester as a career look like. In
deed, the functional field motivated me the most at that time and I
was curious to explore such a position from scratch.
That very first job was about testing mobile trading platforms.
Tunisia 146
I really enjoyed working as a tester and I started exploring and

discovering new things step by step.
Skills you Need to have to be an Excellent

Tester
My second and third experiences as a tester in different projects

allowed me to discover that being a tester is all about having the
tester mindset and it doesn’t matter which kind of applications you
are working on.
However, it doesn’t matter if you have a background completely
different from computer science, what you mostly need to start and
grow your career as a tester is an ability to learn and to have good
communication skills.
I asked people on Twitter via this Twitter Thread⁶
“What was your career before joining testing.”
I was blown by their different answers, I never expected so muhc

diversity from people have lead them to become testers!
This diversity makes the testing career unique and awsome espe-
cially if you think about the strength of your previous field and you
find a link to apply it for testing activities.
Add to that, we are living in an age where Artificial intelligence (AI)
is capable of performing routine and repetitive work but human
skills matter the most which cannot be replaced by robots. So for
me I consider that those human skills are really crucial and good to
have to be a great software tester. Technical knowledge nowadays
is not sufficient!
Different skills that you need to build your tester mindset:
⁶https://twitter.com/emna__ayadi/status/1214810439005155334
Tunisia 147
The four C’s:

It’s also referred to as 21st Century Skills:
The Four C’s
image source : http://www.synergyined.com/the-4-cs.html

1). Critical thinking: The ability to look at problems in deeper and
different ways by evaluating the possibility of failure also, finding
gaps between expectations Vs. reality, between assumptions Vs.
expectations, having an analytical mind and linking learning across
your testing steps..
James Bach says that “Testing is an infinite process of comparing
the invisible to the ambiguous in order to avoid the unthinkable
happening to the anonymous.”
2). Collaboration: Testing is not a single step in the process, it’s
a whole team task shared between all the development team and
business side. In fact teams of people have a collective intelligence
independent from the individual one and greater than the total of
these parts.
3). Communication: Sharing your opinions regarding the software
you are testing, be curious asking questions about the software,
proposing your ideas and solutions
4). Creativity: The ability to come up with new and useful ideas
while exploring the software and innovation is the successful im-
plementation of creative ideas, this includes both incremental and
radical change in systems and products to deliver better quality.
Tunisia 148
• Curious learning and exploring: A mandatory skill for

every tester because in todays world where technology and
tools of today are different from the ones of tomorrow that’s
why you shouldn’t stop learning and exploring.
• Empathic thinking: The ability to think like an end user and
the evaluation of possible risks
• Systems thinking: The ability to evaluate How does the
system under test interact with other systems.
• Flexible: the ability to switch between the big-picture (which
could also be called business-oriented) and detailed analytical
mindsets at need to test different levels in the software.
• Good memory: The ability to memorize different informa-
tion about your testing activities within the team to be more
dynamic and for good exploration of the software to avoid
being lost in the software.
Join testing communities around you or

create yours
When testing becomes your passion and your world, it will be more
than exciting !
Joining different testing communities around the globe is also a
great way to share your thoughts and learn more from other like
minded people.
Attending conferences and testing meetups around you is also an
opportunity to meet and talk to passionate people about what they
are doing in their careers in software testing. Try to get inspired
from them and apply your new learnings with your team.
Inspired by my talk about CoP “Why it’s important to build com-
munities of practice in your agile organization”
Starting a community is relatively simple, but keeping it running
over time is much more complicated.
I suggest in just a few steps how you can build your community
Tunisia 149
from scratch in case you didn’t find one near to you or you’d like
to introduce it in your organization:
Community Levels
One of the practices is to build 3 different levels related to the

community, the first one called the community kernel where we
have at least one or two persons who are super active by bringing
new ideas. Find a place to run the event, seek for sponsors. In fact,
they represent the driving force behind the community and they
will push things to come and last in the long term.
The second level represents also a kernel but less stronger than the
first one, those are people who attend frequently, they will help the
community with their participation and effective communication.
Tunisia 150
In the third level we should encourage everyone who is interested

to participate in order to enlarge the community.
My passion for traveling and testing
I’m passionate about traveling and discovering the world and I

wanted to combine it with my testing passion! A possible way to
achieve this was travelling to conferences around the world.
True! I attended only one testing conference in 2018 as a participant
and I extremely enjoyed it, just after that conference I fixed an
objective to speak at international conferences about my testing
stories.
For me, It was extremely hard to get the first notification of accep-
tance in international testing conferences after dozens of rejections,
but what motivates me to overcome this barrier and work hard to
deliver a talk is that I’m going to discover new places, learning new
topics, and meeting the global testing community around the world.
My first acceptance was in 2019, and I spoke at 6 conferences about
agile and testing. I encourage every tester to find a link between
their passion and testing and try to make fun things even outside
of your working hours. It could be a great motivational factor to
enlarge your skills and grow your mind as a software tester.
Turkey
Turkey 152
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 153
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 154
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 155
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
A Collection of Soft Skills for a Tester
Mesut Durukal - Turkey
A Collection of Soft Skills for a Tester
When I refresh my memory and consider my whole testing life,

I again realize that life is full of lessons. Whenever I think about
this, I come up with a saying by John W. Gardner: “Life is the art
of drawing without an eraser.” We are all making mistakes and it
Turkey 156
is not possible to manage each single piece of processes perfectly.

Still; what we can remember is, with additional brush strokes, those
mistakes can evolve into nice colors inside the big picture. Besides,
in the next run, we may take precautions against possible mistakes.
In short, after a quick review of my career, I decided that I can
collect the required soft skills for a tester. Of course, I do not claim
to be the super person who carries all those, but at least they
are the ones which I realized to be the most prominent from my
experiences.
Not to be boring, I will describe the start of my testing career as
a “serendipity” instead of an “accident”. I guess one, who reads
testing stories, has already seen lots of accidentally starting testing
careers. I had an offer in front of me and I decided to give it a
chance. That is the start of adventure.
In my first position as a test engineer, I had difficulties. That
moment, I understood that the tester of the project is the one who
stands out against audits and other questionnaires. When I was
asked about why I had not created some documents, the answer
for me was simple: Because I didn’t know that I was supposed to
do that. I was slowly getting used to rules. Instead of trying to find
ways to run away from the truth, clearly stating the situation with
reasons would help: Self-expression (1) It is obvious how difficult it
is to keep the balance. Sometimes, when trying to express yourself,
you may be misunderstood. This is the power of Communication (2).
Another difficulty that I faced in my early testing life, was the
responsibilities such as presenting in front of managers. I was
attending meetings in which I was the youngest. I had to have long
travels abroad, when I had not had any before! All these remind
me: Self-confidence (3). On that project, I learnt working regularly
over well-organized documents, which is another skill: Tidiness &
organization (4).
I was involved in long durational environmental tests such as
thermal-cycles, lasting for days. You have to put a commitment
Turkey 157
(5) and you present the product in the name of company, namely
embracement (6).
From another aspect, testers may face different challenges. Unlike
a developer, you are not a domain expert. You switch to various
products/domains and should quickly understand it. When I was
first involved in the project, some of my colleagues had concerns
about if I could make it. In this point, stress management (7) is the
key skill to overcome. Since we already discuss domain switches, it is
worth mentioning innovation (8) because you can apply what you
learnt in different studies to others. I remember that sometimes I
had to take decisions, which refers to: Bravery (*9).
After learning much in the Defense industry, I wanted to take my
chance in Industrial Automation. I was closely following the latest
methodologies and management approaches. Being aware (*10) of
what is going around can help you to take correct actions.
When I moved to software automation, I was surrounded with SW
experts around me. For a moment, I felt that I should immediately
quit there! No chance to be successful there. But 3 months later, I
was one of the guys who were leading the process. At this moment,
I am still not a software expert, but I strongly believe that there
is nothing that I can’t learn. In this kind of situations, not losing
motivation (11) is the key. Yeah, there is nothing that I cannot learn,
but there is too much to learn on the other hand: Learning (12).
Greeting Bob Marley: No ask, no get. You have to be Proactive (*13)
to learn much.
I was one of those, who individually experienced the transition
from waterfall to agile. I confess: I resisted at first. But now that
resistance created another principle for me: Flexibility (14) Changes
did not include only the methodology, but also products, teams, tools
and location, referring to Adaptation (15). Going through all these,
sometimes you have to convince team mates, Influence (16), but
you will not be accepted for all cases! You have to wait until the
correct time: Patience (17).
Turkey 158
After I had a team lead position, I had more issues to be solved. But,
from the beginning you have to have: Problem solving (18) skills. To
find bugs, you have to think the unexpected! You have to be creative
( 19). Besides, you have to try each single detail: Determination (20).
But you can not do everything on your own: You have to be a team
player (21).
I experienced that taking initiative (22) eliminates waste of time.
Otherwise, you may have to wait for a long while for someone else to
act! About time: Another important aspect is prioritization of tasks,
namely: Time Management (23).
Last but not least, you may always face naysayers or people who
underestimates testing: Stay focused (24) and share (25) everything.
It can be a conference speech, a little chat or anything else. World is
beautiful with different colors & opinions. That is why I am writing
now!
To sum up, I have collected 25 principles for myself over my own
story. Of course no one should memorize any of them. My advice
would be making your own observations and continuously learning
from lessons.
Ukraine
Ukraine 160
Making test automation better
Oleksandr Romanov - Ukraine
Making test automation better
The first automated test is eventually written. The script opens a

product’s page, makes a few clicks, and makes some assertions. It
looks easy to write. It looks like “magic”!
But the main question is how to take it further: how to move
from one automated test to a scalable automation solution, which
provides value and is reliable, usable, and fast?
Here are a few things which I might say to myself in the past for
making test automation better.
Determine goals and expectations
Gather all visions and requirements about automation from man-

agement, developers, fellow testers, and other people involved in
Ukraine 161
your product.
Why do they want to introduce automation? Is it just “hype” or a
well-established plan of transformation?
What do they want to optimize? What do they want to save (time,
money)?
How do they see the usage of automated tests on a daily basis?
Tip: Test automation is not a “write once, execute forever” solution.
Maintenance is included.
Research technology stack and architecture

of the product
Learn about product architecture - it will help to plan which

automated tests bring more value.
If you are the first person to start with automation - choose the
stack which is close to your developers: they can help you in the
future.
Try a few tools from the market: from codeless solutions to au-
tomation libraries and compare the pros and cons. Keep in mind
the goals during comparison: the tool may be helpful at the start -
but it will be hard to maintain as the number of tests will grow.
Tip: stable and fast integration or API tests can bring more value
than thousands of flaky UI tests.
Get necessary skills
Learn programming language fundamentals and go through a few

automation-related courses. Do not hesitate to ask for help and
advice in testing communities - we all start from the beginning.
Ask fellow developers for mentorship and code reviews. They can
also teach your local coding standards and approaches.
Ukraine 162
Tip: Consider comments in a code review as points for improve-

ment.
Move small
Start with a small smoke suite of the most critical cases. Make them
stable and usable.
Automate 100% of tests that can be automated, no more.
The best way to plan testing is a mix of automated and manual
exploratory testing.
Tip: Five cases, which are executed on each developer’s code
change is way better than a hundred failed tests that are executed
from time to time.
Always show value and visibility
Execute automated tests from day one. Integrate it into the devel-
opment process.
Continuously show the value from automated tests: how much time
do they save, how stable or fast are they, what is the automated test
coverage?
Tip: Think outside of tests - where automation can help and speed
up the delivery. It can be the scripts for preparing test environments,
generating test data, setting up complex preconditions.
Engage the community of users
If you show value and visibility of automated tests - try to find

users and supporters within your team and other engineers. Their
feedback are the point for improvements.
Tip: Automation does not live in a vacuum. Do not use it alone -
make other people use it and get benefits from it.
Ukraine 163
As a conclusion
Be ready to maintain and fix the tests in a continuous manner.

Be ready to resolve complex errors especially in a distributed
environment (e.g.during parallel test runs).
Be ready to optimize test code in terms of complexity, readability,
and speed.
Be ready for software engineering in automation.
And of course - be ready to help the team to test the product faster
and reliable.
United Arab Emirates
United Arab Emirates 165
Technological Excellence
Ali Khalid - United Arab Emirates
The question that became my quest
When I started off my career in testing many years ago, I was told,
or had the impression, testers are not supposed to be technical. We
don’t worry too much about product’s design and code. We’re more
concerned with how the product behaves and just test it like the
‘end user’ would.
That never sat right with me and I always thought, in other
industries you start as a technical person, once your experienced
you are put in validating others work and guide them, a different
way of saying you ‘test’ their work. Then how is it in software
testing we divorce ourselves from technology and all we care about
are requirement documents (this was before even Agile was a big
thing).
Finding home
Over the years I realized the importance of having technical skills

as a tester from my personal experiences. Having the ability to
understand the product design and production code, I was able to
unearth way more risks in the product than others. That allowed me
to also contribute in helping to fix issues as well. When automation
came along that was a game changer for me, and I finally found a
home. Not that testing wasn’t my home, rather the beautiful blend
of testing and technical skills was.
Do I really need to be technical?
With the kind of technology and product architecture modern

applications are dealing with today, having no understanding of
what’s under the hood will severely limit your ability to highlight
risks as a tester. At the minimum an in-depth understanding of
how the technology stack for your product works, which will be
hard without some basic programming skills.
The team that can deliver a product from an idea to a releasable
version in the hands of the customer first will always win. In this
new world, speed of delivery is key. You need to have the ability
to very quickly test new ideas in the market. For that to happen,
releasing at pace is paramount, which in turn requires a lot of
automation.
Don’t give up
You might have tried and failed a few times at making peace with
programming. I’m here to tell you from my experience & others
around me, the pain you’ll suffer from not trying will be far more
than trying and failing again and again. There is so much help and
content out there now, I believe any individual can develop decent
programming and architectural understanding of the tech stack. All

you have to do is put your mind to it.
United States of America
United States of America 169
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
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
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
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 174
The art of critical thinking
Graham Ellis - Wales, UK
Introduction
Any team that follows an agile approach is probably cross-functional.
If you’re lucky, you will work alongside developers, business
analysts and UX specialists. They are specialists in their own
right. The expectations of Developers are the implementation and
optimisation of the code they create, if you’re very lucky, they will
create unit tests alongside the implementation. A business analyst
will focus on the requirements of the system to be implemented,
they will act as the prime interface between the stakeholders and
the team as a whole. A UX specialist is expected to be concerned
about workflows, look and feel and colour palettes.
So what of the QA? One of the expectations of a QA is the ability
to think⁸; the ability to evaluate information using a systematic
and deliberate approach separate from the mechanistic ritualistic
⁸https://www.merriam-webster.com/dictionary/think
Wales, UK 175
thinking employed in day-to-day activities, as evidenced by group

nodding in many team discussions. Critical evaluation of informa-
tion can provide the team with information⁹ which allows for a
greater understanding of the ‘thing’ being developed which will
lead to more informed decisions on the ‘thing’ being developed.
Skilled application of critical thinking doesn’t need to be overt if it
is undertaken correctly, it won’t be a visible effect. It will just ‘be’.
A QA has a responsibility to identify, communicate and mitigate
issues which impact quality.
‘They can, and should, act as a voice of reason’
They can coach other specialisations in quality techniques, they can
assist in ensuring that the product adheres to quality standards,
they can inform the team and stakeholders of risks, they help in
improving the product so that it is fit for purpose.
History
Socrates was probably the world’s first QA. He created a method

of questioning known as Socratic Questioning¹⁰. He promoted a
line of questioning that attempted to differentiate beliefs that are
reasonable and logical from beliefs that are comforting, egocentric,
without adequate evidence or lack a rational foundation to support
them.
In 16th Century England Thomas Hobbes adopted a naturalistic
view of the world in which everything was to be explained by
evidence and reasoning.
The Foundation for Critical Thinking gives a brief definition here¹¹:
‘Critical thinking is the art of analyzing and evaluating thinking
with a view to improving it.’
⁹http://www.businessdictionary.com/definition/information.html
¹⁰https://en.wikipedia.org/wiki/Socratic_questioning
¹¹http://www.criticalthinking.org/pages/critical-thinking-where-to-begin/796
Wales, UK 176
This ties in neatly with the QA’s expectation of ‘improving the

product’
What it is
Critical thinking takes time and effort to apply correctly. It is

distinctly different from normal, everyday thinking. In fact, it is
the antithesis of normal, everyday thinking. Everyday thinking
happens by default, you just aren’t aware of it, it is a product of
repetition and experience. Walking employs thinking. Maneuver-
ing around obstacles employs thinking. Making a drink employs
thinking. Driving a vehicle employs thinking. All take place with-
out a targeted, conscious effort.
The advantages of employing critical thinking are numerous. With-
out employing critical thinking, decisions can be made that can
cause adverse effects on your team, and by extension, your product.
Each facet of critical thinking can have a marked effect on your
team mindset and the testing efforts employed throughout the
development of the product. It can be employed at any time but in
my experience, there is a marked effect when used in group settings
such as a daily stand-up, 3 amigos or refinement. It can, and should,
be used when interacting on an individual basis. Care is needed
however to not isolate or otherwise distance the other individual.
This in itself is a skill.
Components of critical thinking
Clarity - Can it be illustrated via examples?

Accuracy - Can it be verified?
Precision - Is it specific?
Relevance - Is the problem in question being addressed?
Depth - What makes this a question?
Breadth - Are there alternative points of view?
Wales, UK 177
Logic - Is this supported by evidence?

Significance - Is this the core idea to focus on?
Fairness - Are people conscious of their own bias?
Or simply, who, what, when, where, why and how
How to apply
In my experience, there are two main approaches to conducting

a standup. Your experience may vary Critical thinking can, and
should, be employed in both approaches:
Standup number 1: Robotic statements; Yesterday, Today, Blockers,
focused on individual contributions.
Standup number 2: Walking the board¹²; Natural conversation flow,
focused on completion of a particular story by the team as a whole.
The application of critical thinking in the first instance is inherently
more difficult as the sequential format tends to inhibit natural
conversational flow and questioning is directed at an individual
which discourages further interaction at a team level.
The application of critical thinking in the second instance is easier
as there is a constant stream of information from multiple sources in
real-time, each with a particular viewpoint that can open up more
possibilities for questioning and clarification. At the beginning
it may seem quite daunting but the more you employ it the
easier it becomes. There is a distinct and beneficial side-effect of
employing critical thinking in that you can articulate your method
of questioning to other members of your team.
For this reason, the methods will concentrate on a ‘walking the
board’ scenario..
‘Over time they will subconsciously adopt these methods in relation
to their own statements.’
¹²https://www.agile42.com/en/blog/2012/05/29/revive-your-daily-standup/
Wales, UK 178
Real-life scenarios
Let’s run through some typical group scenarios that often occur
in cross-functional agile teams (using a stand-up as the reference
activity):
Developer Jenny states that implementation of the API is almost
complete but she believes that it doesn’t require much in the way
of testing:
• Ask for reasons for that position

– Are they logical?
• Ask the team whether they agree.
– Does everyone agree with this point?
– Is there anyone who does not agree?
• Query their approach and how they arrived at the conclu-
sion(s) they did
• Is the approach based on fact, supposition or confirmation
bias?
Developer George is about to pick up a task to write stubs to support

the automation of a particular test effort, he’s done this type of work
before and he appears quite comfortable with his approach:
• Ask whether he will undertake research?

– Further information may enhance the implementation,
even given his past success
• Ask whether his previous efforts have been consistent with
the team’s standards.
– Is this evidenced?
• Can he provide the rationalisation for his confidence?
– Is it well-reasoned?
– Is it logical?
• Ask whether his approach could be improved
Wales, UK 179
– Can team members suggest alternatives?

• Ask if the team can suggest abstract ideas
– There may be underlying assumptions in play
Tester Gwen states that the vehicle selection screen story can now
be considered done, BA Bob disagrees.
• Ask Bob why he disagrees

– Can they provide a rational reason for the disagreement?
– Do they have information that isn’t apparent to Gwen?
– Ask whether his disagreement is valid in the context of
the story?
• Ask if the tasks that make this story up have been verified
– Can she solicit agreement from the team for her conclu-
sions?
– Does Bob suggest an offline discussion to resolve the
differences?
New Developer Alana picks up a task to implement form validation

she appears a little unsure on?
• Ask if she can articulate the task within the context of the
story?
– Does her understanding reflect the team’s understand-
ing?
• Ask if the card is accurate in intent and accurately reflects
the actual task?
– Ask if the the card requires rewording
• Ask the team if Alana’s understanding is correct
– Does the team employ empathy to address any confu-
sion on Alana’s part?
• Articulate your understanding of the problem
– Are there opposing views?
Wales, UK 180
– Are there questions that arise from your understanding?

– Is there agreement from the team?
• Is there information missing that would enhance understand-
ing?
• Is Alana comfortable with speaking in the stand-up
• Is undue influence being applied
You articulate progress you made on a task you completed just

before standup, the team appear unsure as to the actual status:
• How do you know that what you’ve done is completed?

• Can you provide alternative phrasing?
• Can you provide an analogy?
• Can you provide evidence?
• Can you ask a colleague to paraphrase your explanation?
PO John queries the status of the sprint as a whole but devolves

into a discussion about another sprint
• Question the relevance of the other sprint

• Ask them to reframe the question
• Ask if this is the most important thing to discuss right now
Summary
As previously stated, this will take time. No-one thinks critically
100% of the time. Critical thinking is a tool. You can consciously
practice on your own reasoning. Don’t attempt to inject every
type of question into every situation.. Learn to read your team.
Make a conscious effort to observe how individuals respond to
different stimuli, increase your awareness of body language. These,
combined with critical thinking skills will make you a far more
effective quality advocate than any amount of code knowledge.
Wales, UK 181
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 182
“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 183
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?

Around The World With 80 Software Testers

Uploaded by

Copyright:

Available Formats

You might also like

Around The World With 80 Software Testers

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Around The World With 80 Software Testers

Uploaded by

Copyright:

Available Formats

Around the World with 80

This version was published on 2020-05-25

This is a Leanpub book. Leanpub empowers authors and

This work is licensed under a Creative Commons

Be the change you want to see . . . . . . . . . . . . . . . 42

Gran Canaria, Spain . . . . . . . . . . . . . . . . . . . . . . . 62

New Caledonia . . . . . . . . . . . . . . . . . . . . . . . . . . 101

New Zealand . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

South Africa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

United Arab Emirates . . . . . . . . . . . . . . . . . . . . . . 164

United States of America . . . . . . . . . . . . . . . . . . . . 168

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

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

Keys to effectiveness as a software

Ivo Dimitrov, Bulgaria

Keys to effectiveness as a software tester

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

Detail orientation and Perseverance

meaning that without a significant upgrade in skills, an engineer

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

Know your simple tools

Janet Gregory, Canada

Know your simple tools

1. Flow charts (data, process)

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

The power of trust and questions in

Anwar El-Wakil - Egypt

As a software quality control engineer

A policed process and mistrust results in loss of passion for both

What can you do as a QC member to

Well, relax, a relaxed environment with less sense of urgency helps

Take responsibility for our testing

Alan Richardson - England, UK

Take responsibility for our testing

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

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

What I have learned (the hard way)

Dorothy Graham - England, UK

What I have learned (the hard way) in

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

Be open to the unexpected.

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

Working in a great team is wonderful.

Managers don’t know everything.

Working for yourself is scary, hard work

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

Technology is always changing, but people

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

The day I fell in love with testing

Mark Winteringham - England, UK

The day I fell in love with testing

Fighting Against Automation Isn’t

Maaret Pyhäjärvi, Finland

Fighting Against Automation Isn’t Doing

Being Vocal Against is Time Away from