An Exploration of Testers

An Exploration of Testers
Lee Hawkins
This book is for sale at http://leanpub.com/anexplorationoftesters
This version was published on 2021-09-03
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.
© 2019 - 2021 Lee Hawkins

For Ky
Contents
Preface and acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Version history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Tweet this book! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
My mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Background and inspiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Refining my questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Reaching out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
The questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Giving back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Ilari Henrik Aegerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Michael Bolton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Fiona Charles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Anne-Marie Charrett . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
James Christie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Cheryl Downes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Kim Engel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
James Espie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
David Greenlees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Scott Miles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Brian Osman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Rob Sabourin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Paul Seaman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
CONTENTS
Amanda Shankle-Knowlton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Aleksandar Simic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Karo Stoltzenburg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
James Thomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Toby Thompson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
About the author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Preface and acknowledgements
This book is a compilation of the answers to the same set of eleven questions that I’ve posed to
software testers around the world. The software testing community has been very good to me
during my long career and I hope this book will help others looking to learn from a diverse group
of enthusiastic testers from various industries and across various geographies.
This book is dedicated to my wife, Ky. I’ve been talking about writing a book ever since we met back
in 2002 and I’ve finally done it - albeit with quite different subject matter to my original ideas for a
book about the British rock band, Status Quo! Thanks to Ky for pushing me to give it a go and for
her support during the process of putting the book together.
There are a number of other people to thank for their help in making this book possible. Firstly, thanks
to the testers who responded to my request to contribute to this book - without their responses, there
would be no content here. I really appreciate the thought and time that went into answering the
questions. I’ll also take this opportunity to express my gratitude to my long-time friend, colleague
and mentor, Rob Sabourin, for his continued guidance, assistance and critique - this book benefits
from his wisdom in many ways. Thanks also to my good mate, Paul Seaman, for just being there
when I needed to talk through ideas.
Dr Lee Hawkins @therockertester¹, therockertester.wordpress.com²
October 2020
(Cover image: Mundi Mundi Lookout, Silverton NSW, Australia - thanks to Cassie Smart on
Unsplash.com³)
¹https://twitter.com/therockertester
²https://therockertester.wordpress.com
³https://unsplash.com/photos/v7n1oSQzBQw
Version history
Versions
You are reading version 1.1 of this book.
Version 1.1 (published 3rd September, 2021)
Includes additional contribution from Anne-Marie Charrett.
Version 1.0 (published 5th October, 2020)
First edition.
Includes contributions from Ilari Henrik Aegerter, Michael Bolton, Fiona Charles, James Christie,
Cheryl Downes, Kim Engel, James Espie, David Greenlees, Scott Miles, Brian Osman, Rob Sabourin,
Paul Seaman, Amanda Shankle-Knowlton, Aleksandar Simic, Karo Stoltzenburg, James Thomas, and
Toby Thompson.
Tweet this book!

Please help to spread the word about this book on Twitter.
My suggested hashtag for this book is #AnExplorationOfTesters⁴
⁴https://twitter.com/search?q=%23AnExplorationOfTesters
My mission
Background and inspiration
My work has generally seen me travelling internationally several times a year and this means a
lot of time waiting around in airports. During one trip in 2017, my time spent perusing the airport
bookshop resulted in me buying Tim Ferriss’ Tribe of Mentors: Short Life Advice from the Best in the
World⁵. This hefty book hooked me very quickly and his simple concept works brilliantly. He asked
the same set of eleven questions to “130+ of the world’s top performers…from iconic entrepreneurs
to elite athletes, from artists to billionaire investors” and their responses to the questions formed the
content of the book. It was amazing to read some of the similarities and themes in the answers, but
also some of the huge differences between the really diverse group of people who responded.
Then in 2017, I was interviewed⁶ for Johan Steyn⁷’s Careers in Software Testing podcast in which
he asked a very similar set of questions to each of his guests from the testing community.
This got me thinking - would a “Tribe of Mentors” style book with contributions from the testing
community be an interesting read? I thought it would, based on interactions I’ve had with many
different testers I’ve met around the globe during my twenty-odd years in the industry.
In thinking about the name for the book, I reached out to the testing community on Twitter to
look for a suitable collective noun for testers and “exploration” seemed perfect. This book aims to
explore the different opinions of testers around the world and it’s also a nice connection to one of
my professional passions, exploratory testing.
And so the concept and name for this book, “An Exploration of Testers”, was borne!
Refining my questions
Tim Ferriss had eleven standard questions for “Tribe of Mentors” contributors and I decided to go
for the same number. Some of these questions are borrowed from Tim’s work, but most are more
testing-specific with some inspiration from Johan’s podcast questions. Thanks to Rob Sabourin and
Paul Seaman for their help in refining the questions and I hope the final set has allowed for diverse
and engaging responses from the contributors to this book.
⁵https://tribeofmentors.com/
⁶https://therockertester.wordpress.com/2018/09/17/time-for-another-podcast/
⁷https://www.aiforbusiness.net/about
My mission 4
Reaching out
One of the most enjoyable aspects of putting this book together has been the opportunity to reach
out to so many awesome testers around the world.
Some of the contributors to this book are close friends or colleagues from the testing community,
while others are people I’ve enjoyed following or have interesting things to say about testing!
I again thank all the testers who took the time and effort to provide thoughtful answers to my
questions and hence create this collection of great content to share. I am especially grateful for these
contributions since many of them were provided during the difficult times so many people have
faced during most of 2020.
The questions
The eleven questions I posed to testers for inclusion in this book were as follows:
1. What do you think is the most interesting aspect of your path to a career in testing?
2. What is one of the best or most worthwhile investments you’ve ever made in your career?
3. What advice would you give to someone about to enter the IT industry and particularly testing?
What advice should they ignore?
4. What are some of the common recommendations or practices you see in testing that you
disagree with?
5. In the last five years, what new belief, behaviour, or habit has most improved your life and
how?
6. What is it that you know now that you wish you had known when you started your testing
career and how might this have influenced the choices you made?
7. Which factors have influenced how you have tested on different projects? Provide a list of
factors and explain how each factor influenced your choices
8. What book(s) has had the most influence on your work as a tester and what book(s) has had
the most influence on your personal life?
9. How has a failure, or apparent failure, set you up for later success? What was your most
important failure?
10. In the last five years, what have you become better at saying no to? (e.g. distractions, invitations,
etc.) What new realizations and/or approaches helped you to do this?
11. When you feel overwhelmed or unfocused, or have lost your focus temporarily, what do you
do?
Giving back
My desire to write this book was never motivated by personal financial gain and I have deliberately
set a very low minimum price on LeanPub.
My mission 5
I will donate all proceeds from the sale of this book to the Grant Program⁸ of the Association
for Software Testing (AST). This excellent program offers financial and non-financial support for
volunteers and students involved in small local testing gatherings, such as peer conferences and
meetups.
Members of the AST are entitled to a free copy of this book as a benefit of membership.
⁸https://associationforsoftwaretesting.org/programs/ast-grant-program/
Ilari Henrik Aegerter
“One cannot underestimate the power of being connected.”
“I don’t have the need to tidy up past mistakes as they were important in developing my views.”
“I can recommend this as a general rule: Don’t work for free for organizations that draw financial
benefits from your work.”
I’ve enjoyed Ilari’s company at many testing conferences over the

last few years, from Let’s Test in Sweden to CAST in New York,
to Association for Software Testing (AST)⁹ conferences on home
soil in Sydney and Melbourne. I admire his passion for context-
driven testing and his “no nonsense” approach, while his warm
and generous personality mean he is also a natural and excellent
community builder. His dedication to AST board membership and
his advocacy for AST conferences outside of North America gave
me a wonderful opportunity as Program Chair of the CASTx18
event¹⁰ in Melbourne and also led to my chance to co-organize the
Testing in Context Conference Australia 2019¹¹ with Paul Seaman
(and you’ll hear from Paul later in this book). The personality and passion I know and admire in
Ilari certainly shine through in his responses below.
What do you think is the most interesting aspect of your path to a career in testing?
Maybe the fact that I am not really a practitioner of testing. I would call myself a “second-degree
tester”. For almost all of my career, my goal has been to make other people successful in testing.
I have been a line manager and entrepreneur for the past fifteen years, not a hands-on tester. My
understanding of testing is one level removed from the practice of testing. So, in that sense, I am an
enabler.
What is one of the best or most worthwhile investments you’ve ever made in your career?
Becoming a member of the Association for Software Testing. By doing so, I was able to rapidly
expand my network of people and build connections that have been helpful again and again in
the course of my career. One cannot underestimate the power of being connected. The AST has
boosted my connections tremendously, many of the people I most interact with can be traced back
to AST-enabled contacts.
What advice would you give to someone about to enter the IT industry and particularly
testing? What advice should they ignore?
⁹https://www.associationforsoftwaretesting.org/
¹⁰https://therockertester.wordpress.com/2018/03/08/castx18-context-driven-testing-fun-in-melbourne/
¹¹https://therockertester.wordpress.com/2019/03/08/testing-in-context-conference-australia-2019/
Ilari Henrik Aegerter 7
Go out and connect with other likeminded people. Learn from as many sources as you can. Keep an
open mind and be aware that you need to find your own path in testing. Most people will not be
of much help, find those who are. Don’t fall for the certification dealers. Don’t stay in your bubble.
Don’t lose your sense of humour.
What are some of the common recommendations or practices you see in testing that you
disagree with?
There are tons of them, mostly rooted in a misunderstanding of what testing is. The request to
“automate everything” is a particularly ridiculous one as I cannot process what it even means and
neither can the people - usually managers - asking for such a thing. It is one of those asks that seems
to sound good to the incurious ears. On a smaller scale, I have seen consulting companies pulling
additional roles out of their ass in “agile setups”. Artificial roles like “Test Master” make me both
chuckle and shake my head.
In the last five years, what new belief, behaviour, or habit has most improved your life and
how?
Well, the last five years I have spent building House of Test¹² in Switzerland, so entrepreneurial
questions are more in my focus. Building your own thing comes with quite an amount of personal
risk. I think I have learned to be comfortable with the fact that my safety net is less strong than
when I was an employee.
What is it that you know now that you wish you had known when you started your testing
In general, I believe things should develop the way they develop and I don’t have an urge to time-
machine myself to a former self and rearrange items. I don’t have the need to tidy up past mistakes
as they were important in developing my views. If I could rearrange everything and make it perfect
so that there aren’t any obstacles, my life would become incredibly boring. Absolute Perfection isn’t
appealing to me. I am happily floating along.
Which factors have influenced how you have tested on different projects? Provide a list of
I am less of a tester and more of an enabler and guardian of good testing. As a manager I always
focused on encouraging education with my people, treating them as adults and being of service if
there were obstacles that my people couldn’t remove themselves.
What book(s) has had the most influence on your work as a tester and what book(s) has had
Influenced as a tester:
• Lessons Learned in Software Testing¹³ (Kaner, Bach & Pettichord) - for its richness of small
chapters on core questions about testing
¹²https://houseoftest.ch
¹³https://www.wiley.com/en-au/Lessons+Learned+in+Software+Testing:+A+Context+Driven+Approach-p-9780471081128
• Many of Jerry Weinberg¹⁴’s books for their general wisdom

• A combination of Harry Collins¹⁵, Cynefin material and literature on the nature of complex
systems have helped me understand the difference between algorithmic refutation/verification
and heuristic experimental data gathering.
Influenced in personal life:
• Science fiction by Stanislaw Lem¹⁶, Philip K. Dick¹⁷, et.al., and more recently Cixin Liu¹⁸
• Mangas and Gekigas by Osamu Tezuka¹⁹ and Yoshihiro Tatsumi²⁰
• Many deeply technical books on cooking, BBQ, Smoking Meat, Kitchen Tools, etc.
• Everything by Franz Kafka
• Earlier in my life, the French and Italian writers of the Oulipo movement
I generally need to have my bookshelves close to me, there is a radiation emitting from them which
is useful.
How has a failure, or apparent failure, set you up for later success? What was your most
important failure?
My most important failure was not being able to finance studies in Physics, which led me to software
testing by pure chance. I decided to study Sociology and Linguistics instead, which were easier in
terms of combining creating income through work and spending time at the University. Sometimes
at conferences, I tell people that I came to software testing “because I was young and needed the
money”. There is some truth to that flippant description.
In the last five years, what have you become better at saying no to? (e.g. distractions,
invitations, etc.) What new realizations and/or approaches helped you to do this?
I have refined my distinction of finding out whether a request is a commercial or a community
request. I handle commercial requests in a sequence that ends with issuing an invoice, community
requests are free (if I have spare time and if it is something I am interested in). I have become really
good at saying no to people expecting me to do commercial requests for free. I can recommend this
as a general rule: Don’t work for free for organizations that draw financial benefits from your work.
When you feel overwhelmed or unfocused, or have lost your focus temporarily, what do you
do?
Going for a run in the forest has a calming effect on me, especially if I am upset with some stupidity.
I have recently discovered the benefits of binaural beats to keep up my concentration. That doesn’t
mean I am particularly good at it, I still see squirrels everywhere :)
¹⁴https://geraldmweinberg.com/
¹⁵https://mitpress.mit.edu/contributors/harry-collins
¹⁶https://english.lem.pl/
¹⁷https://en.wikipedia.org/wiki/Philip_K._Dick
¹⁸https://en.wikipedia.org/wiki/Liu_Cixin
¹⁹https://tezukaosamu.net/en/
²⁰https://en.wikipedia.org/wiki/Yoshihiro_Tatsumi
Ilari’s bio
Ilari Henrik Aegerter’s formal studies have brought him from General Linguistics and Sociology to
Software Engineering and Software Testing. Coming from the medical software domain at Phonak
AG and progressing to e-commerce at eBay. He is now the Managing Director of House of Test
GmbH, and he believes that there is still a lot of work to be done for excellent software testing. In
2015 he was elected into the board of the Association for Software Testing (AST) where he acts as
Chief of Chapters. He is also a lecturer at the HSR technical university for the post-graduate degree
course CAS Software Testing.
Michael Bolton
“I have almost never regretted buying a book. When I do acquire a bad one, I often learn something
valuable from its badness.”
“You probably have no idea how much asking for help helps other people to learn what they need to
do to help others.”
“Keep doing the things that we love, and the things that bind us all together - which tend to be the
same things.”
Little did I know that an in-house software testing training

course back in 2007 would change the course of my career. I
flew from Melbourne to Ottawa (Canada) to attend Michael’s
Rapid Software Testing²¹ class in Quest’s Kanata office and still
recall vividly those three exhausting days. My mind was well and
truly blown as the realization dawned that there was so much
more to good software testing than I ever knew as a box-ticking,
quality policeman. To say I arrived back in Australia energized
and keen to spread the word would be an understatement (and I
was probably very painful at work for a while!). Since that lucky
break back in 2007, I’ve been fortunate to read enormous amounts
of Michael’s writing²², hear him speak in person many times at conferences around the world, and
also spend time enjoying his company. His passion for our craft remains an inspiration to me and I
consider him a mentor - his willingness to continue learning and sharing his knowledge, his careful
consideration around testing, and his incredible ability to communicate are high bars for me to
aspire to. Michael’s responses below are evidence of these skills in action and I encourage you all to
absorb his written words (both here and elsewhere), learning from one of the true ambassadors for
our craft of software testing.
I get asked this question a lot, and I’m afraid to say it, but to me there isn’t anything particularly
interesting about it. My first career was in theatre, and from there I went from data entry, to
programming, to internal technical support, to tech support, to testing, to program management, to
programming, to consulting, and to teaching testing. I imagine that almost everyone else in testing
has had a very different but similarly meandering path.
But maybe that’s the lesson: that our own backgrounds aren’t interesting to ourselves, but the
diversity of people’s paths make things interesting.
²¹https://rapid-software-testing.com/
²²https://www.developsense.com
Michael Bolton 11
I invested a lot of time and money studying with Jerry Weinberg. Alas, that’s not an option for
people these days; Jerry lives on through his community and through his books. But that points
to the other great investment: my library. I have almost never regretted buying a book. When I do
acquire a bad one, I often learn something valuable from its badness.
Immerse yourself in your craft. Ask for help. Find people who can help you and guide you - and
guide and help them. You probably have no idea how much asking for help helps other people to
learn what they need to do to help others. But it does.
Ignore the advice to get a formal education or a certification “Just Because”. If you want those things,
get them because you want them, not because someone told you to.
disagree with?
We are here to learn about the product on behalf of other people. We are here to help people by
finding problems that matter to them and to their customers. That’s the bottom line. I disagree with
anything that interrupts or interferes with or distracts us from those goals.
how?
I play Irish traditional music for fun; so does Mary, my wife. In the flurry around COVID-19, we
can’t do the usual thing and gather for sessions in pubs. But because of that, we have come to realize
that the most important thing about music, for us, is sharing it with friends on our front porch or in
our back yard. And that far from complaining, the neighbours seem to love it - or at least tolerate
it well into the night. That suggests a larger idea: keep doing the things that we love, and the things
that bind us all together - which tend to be the same things.
I know now more than ever that the deeper you go into studying and observing and teaching and
analyzing and - above all - performing testing, the more depth and richness there is, and the better
we can get at it. I have known this intuitively all along, I think, and it has already influenced every
choice I’ve made. Every new thing affords the opportunity to learn dozens more new things. It’s like
a trip to this fabulous tropical beach.
Here’s my answer for today.
The biggest factor is realizing that no matter what gets put in front of you, some aspect of it will
represent a problem for someone - so it’s a good idea to study the product, and the people who are
Michael Bolton 12
going to use it, and how they are going to use it, and find out how those things don’t mesh. The next
biggest factor is recognizing how little I know about the particular new domain - and realizing that
it’s okay not to know things, and then buckling down and learning them. And the best way to learn
is by encountering the product, by experiencing it, by exploring it, and by experimenting with it.
The other biggest factor is recognizing that because of what I learned today, my answer tomorrow
may well be different.
Jerry Weinberg’s books have certainly been influential. Harry Collins’ too. Outside of testing, I was
a great fan of George Orwell as I was growing up. I was fond of J.D. Salinger too - but the books
about the Glass family, particularly “Franny and Zooey”, and not “Catcher in the Rye” so much.
important failure?
Jerry Weinberg helped me to learn that everything that looks like a failure sets you up for success
and is not a failure if you choose to learn from it. Meanwhile, there have been so many (ahem) setups
for success that it’s impossible for me to identify any one of them as the most important.
I’m not convinced that I’m better at saying No to much of anything… so see my answer to the
previous question. This is an important domain of failure for me.
do?
Roll with it. The universe is leading me somewhere. It would be foolish to resist the whole universe,
wouldn’t it?
Michael’s bio
Michael Bolton is a consulting software tester and testing teacher who helps people to solve testing
problems that they didn’t realize they could solve. In 2006, he became co-author (with James Bach)
of Rapid Software Testing (RST)²³, a methodology and mindset for testing software expertly and
credibly in uncertain conditions and under extreme time pressure. Since then, he has flown over a
million miles to teach RST in 35 countries on six continents.
Michael has over 30 years of experience testing, developing, managing, and writing about software.
For over 20 years, he has led DevelopSense²⁴, a Toronto-based testing and development consultancy.
Prior to that, he was with Quarterdeck Corporation for eight years, during which he managed the
company’s flagship products and directed project and testing teams both in-house and around the
world.
²³https://rapid-software-testing.com/
²⁴http://www.developsense.com
Michael Bolton 13
Contact Michael at michael@developsense.com²⁵, on Twitter @michaelbolton²⁶, or through his Web

site, http://www.developsense.com²⁷.
²⁵mailto:michael@developsense.com
²⁶https://twitter.com/michaelbolton
²⁷http://www.developsense.com
Fiona Charles
“Jump into roles, jobs, or assignments that interest you, and don’t be put off because you don’t know
how to do them.”
“Find mentors who will challenge your assumptions and help to guide your learning and growth.”
“Now I see younger women having to deal with some really staggeringly sexist attitudes, and even
leaving tech because of it.”
My various travels around the world for work and conferences

have often found me in tutorials and keynote talks by Fiona.
I’ve been fortunate to enjoy engaging conversations with her
and sitting sandwiched between James Christie (also featured
in this book) and Fiona at the EuroSTAR conference dinner in
Dublin back in 2014 is certainly a candidate for the best seating
arrangement at a professional event I’ve experienced! I’ve also
enjoyed working closely with Fiona in a volunteer setting through the SpeakEasy mentoring
programme (now known as TechVoices²⁸) she founded with Anne-Marie Charrett (also featured
in this book) and her no nonsense approach to communicating on issues that matter feels especially
important right now as she contributes on the topic of ethics in AI. Fiona’s enormous experience
in our industry and wide-ranging contributions deserve more credit than I can give in this short
introduction, but please settle in for some nuggets of wisdom from her lengthy career in software
testing provided via her answers below.
Luck. Plus a tendency to leap joyously into new things I don’t know how to do. But maybe that’s
true for everyone who has a satisfying career. I also had some terrific managers and mentors.
I dropped out of university after second year. My (almost) first job was as a circulation clerk in a
university library. My manager told me after I’d been there a while that she had known I was the
right candidate because she had seen me trying to outthink the self-assessment questions in the
interview. (Obviously I wasn’t very good at it, or she wouldn’t have noticed!) Liz was a remarkable
boss who gave her junior staff all the responsibility and autonomy they could handle. She told us,
“We are here to serve the students and faculty. The rules are there to back you up if you need them,
but don’t ever get too hung up on the rules. Use your judgement.”
Liz’s advice happened to tap into a natural tendency in me, and that has informed my entire career,
whether taking or giving direction.
²⁸https://techvoices.org/
Fiona Charles 15
I eventually went back and finished a general arts degree, specialising mainly in English language
and literature. As a returning student, I got a summer job as the pioneer technical writer in my
university’s library automation company. Again, I was lucky: to land in my first tech job almost by
accident, but also in my manager and the people I worked with. Charles, my boss, expected me to
invent the job. It was a fantastic learning opportunity and I ended up staying for more than four
years, plumbing the depths of their software to write about it and learning to program with COBOL
and PL/6 (the Honeywell version of PL/1) along the way.
When I started in 1978, most people who developed software hadn’t had formal training in computer
science. Many of my co-workers came with physics degrees, but my arts background was not at all
unusual. One of the senior programmers had a PhD in Egyptology; another was a composer of
electronic music. There was far more diversity than we typically see now, and I think our software
was all the better for it.
That diversity included a substantial number of women in senior technical positions. I didn’t feel
disadvantaged as a woman in tech. It was only much later that I looked around the rooms I was in
and suddenly found myself the only woman.
I’ve rarely experienced overt sexism in my career. Now I see younger women having to deal with
some really staggeringly sexist attitudes, and even leaving tech because of it. But the toxic bro
culture apparently now infesting gaming and even Silicon Valley wouldn’t have been tolerated in
the places I worked, although the product companies were essentially startups. Each had wonderful
camaraderie and opportunities for learning and sharing. Much like in Agile and DevOps today, we
weren’t siloed. We had different skill sets and everyone worked together to produce the best product
we knew how.
It’s been interesting to watch the software development world come back to that much more natural
and productive way of working. Sadly though, we haven’t yet restored the gender balance or
managed to create a representative racial balance.
In 2001 I flew to Albuquerque for PSL, the Problem Solving Leadership workshop²⁹ developed
primarily by Jerry and Dani Weinberg.
I was in the 2nd last class before Jerry shut the program down for several years. (He later revived
it with co-instructors Johanna Rothman and Esther Derby.) Our class became a legend among PSL
grads because 9/11 happened on the Tuesday morning, turning up the intensity of what was always
an intense week, and amplifying the learning. By luck, Jerry Weinberg and Naomi Karten were that
week’s instructors. I couldn’t have wished for better.
I came to PSL with a long-standing interest in the human side of software development. I had read
many of Jerry’s and other people’s books in that vein, plus the extensive material on the PSL website.
But nothing truly prepared me for the revelation - and the feeling of homecoming - that PSL was
for me. It was my introduction to the strengths and depths of experiential learning, and I dived in. I
returned home exhausted and wanting more.
²⁹https://geraldmweinberg.com/PSL_Site/psl.PSL.logic.html
Fiona Charles 16
I immediately found a welcoming community in Jerry’s SHAPE (Software as a Human Activity

Performed Effectively) online forum, where we discussed and explored a multitude of shared
interests. Then the following summer, I went to my first AYE (Amplifying Your Effectiveness)
conference: 3 days of half-day experiential workshops, with a variety of instructors and topics. I
returned annually for several years. I also attended week-long Weinberg workshops on consulting
and on experiential session design.
I can’t begin to assess the value of that initial “investment” in PSL. Now, there are many communities
available for meeting like-minded people, but almost 20 years ago they weren’t so easy to find and
PSL gave me entry to a large one. I learned so much from so many wise and interesting people, and
I continue to learn from sessions and conversations I participated in years ago, some of which are
still going on. I grew my capacity and techniques for paying those gifts forward with coaching and
mentoring others. I began writing and eventually presenting at conferences, which I might not have
done otherwise. I learned how to design and lead experiential workshops. Crucially, PSL set me on
a path that broadened and deepened my outlook. It showed me how to grow the way I work and
had radical impacts on the ways I relate to the humans I work with and for, including myself.
Do
Jump into roles, jobs, or assignments that interest you, and don’t be put off because you don’t know
how to do them.
Learn and practise different modes of thinking: critical, creative, analytical, logical, lateral…
Remember that we are also emotional beings. Don’t neglect your emotional life and growth.
Find a community or communities, but don’t limit yourself to only one group or school of thought.
Find mentors who will challenge your assumptions and help to guide your learning and growth.
Never stop learning. Don’t just learn about software. Volunteer; sing, act, or do improv; walk or hike,
climb mountains; live!
Try to maintain perspective in your work. Cultivate resilience and the knowledge that you can learn,
grow, and recover from bad experiences.
Ignore
The people who think you aren’t “passionate” if you aren’t spending all your waking hours on your
career and craft, or working stupid hours to enrich some tech bro.
disagree with?
I see smart and committed up-and-coming testers who have learned how to do automation and/or
exploratory testing, but have somehow missed learning the fundamentals of test design. I think
that’s bad for them and for testing in general.
Fiona Charles 17
how?
I’d like to say “retirement”, but that’s not it exactly because I haven’t really retired. I still consult
and coach/mentor and I still speak and do workshops. I have given up working on large, stressful
software projects. I loved working on troubled projects and trying to make them work better, but
they are a young person’s game. I miss the camaraderie and the crucible for new ideas that those
projects were for me, but I don’t miss the stress or having to work away from home for months. Now
I have much more leisure and space to read, think, walk my dog, talk to friends, and contemplate
the garden.
Nothing. I don’t do regrets. I learned as I went along: something, and sometimes many things, from
everything I worked on.
That might end up as its own book, because I worked on so many projects in so many contexts, so
I’m going to pass.
I read Jerry Weinberg’s The Psychology of Computer Programming³⁰ in 1978 in my first week as a
new and completely clueless technical writer. It has powerfully influenced all of my work, because
it taught me at the outset of my career to put humans at the centre of software development, as the
makers and as the recipients. It taught me other things too, like the concept of “egoless programming”:
not to centre my ego in my work, but always to seek and value feedback.
Tom de Marco and Timothy Lister’s Peopleware³¹ is another book I value, not really because I learned
much new from it, but because it affirmed my values.
Re: personal influences, I’m not sure I can even answer that. Ursula K. Leguin apparently said
something like, “What book have I read that didn’t influence me?”
Man’s Search for Meaning³² by Viktor Frankl would be one. Leguin’s essays and blog posts, and a
couple of her novels. Rosemary Sutcliff’s Dawn Wind³³, a historical novel that blew me away when
I was 9.
important failure?
My most important failure was as program test manager on a big retail project. I had previously
managed the also big and very messy end-to-end integration test on this client’s e-commerce launch.
³⁰https://geraldmweinberg.com/Site/Programming_Psychology.html
³¹https://www.amazon.com/Peopleware-Productive-Projects-Tom-DeMarco/dp/0932633439
³²https://www.amazon.com/Mans-Search-Meaning-Viktor-Frankl/dp/1568490119
³³https://www.amazon.com/Dawn-Wind-Rosemary-Sutcliff/dp/0192793594
Fiona Charles 18
That had been a troubled project, and my team’s testing was widely credited with saving it and
making the go-live possible.
So I was flattered and eager to jump in when a manager I’d worked with on the previous project,
called me - at home, no less - (I was working for IBM Global Services at the time) and begged me to
come and save his current program. Program Test Manager, woohoo! And I loved troubled projects.
I dived in head first.
It took me seven progressively stressed-out months to admit that this was not merely a troubled
project; it was a doomed project. Nobody could save it - least of all me - though I had thrown
my heart and soul into trying. The software quality was abysmal, almost the worst I’ve ever seen.
System Test was bogged down for months because of all the bugs and I couldn’t persuade the PM
to let the team focus on clearing the catastrophic ones. We couldn’t test the performance or the
data migration, and we couldn’t get close to testing our big system’s integration into the enterprise
supply chain and backend financial systems. We had repeated environmental disasters where the test
data was irrecoverable and had to be reconstructed. The program manager ran around hysterically
demanding the testers work crazy hours, and everyone was exhausted and miserable. Meanwhile,
the software vendor and my client were facing off with daggers as money streamed out the door
daily, and each side blamed the other.
The end began for me when the program manager ordered me to lie about the testing status for his
weekly report to senior management. When I refused, he cut me out of the reporting process and
connived with the project manager to fudge the numbers. He smoothly suggested that System Test
was under control and the project manager could take over running it, allowing me to devote my
efforts to preparing for the enterprise E2E integration test.
I kept trying to get some positive traction for a while, but was appalled to discover one day that the
Program and Project Managers were declaring System Test done and still claiming that the launch
would be in a few weeks, even though we hadn’t started the E2E and couldn’t. I stayed behind
that evening and analysed the raw data they had been obfuscating. Then I pulled together a report
showing that the project was many months behind where they said it was.
I think at that point I wasn’t really in my right mind. I felt that I had failed utterly after trying so
hard to make the project work. I had tried to stay positive at home and with team members, but
was often short-tempered and gloomy. I hadn’t slept properly in weeks and wasn’t getting enough
exercise.
I stayed up late and wrote Jerry Weinberg a long email, headed, “HELP!” We hadn’t corresponded
directly before, but he had told me at AYE that I could reach out to him at any time. He replied
immediately, saying he’d respond at greater length the next day, but meanwhile he was there for
me.
I had to get out. I knew that IBM was chickenshit about customers and might or might not pull me
out, though they wouldn’t want to be associated with outright lies. I sent a quick email to the IBM
project exec and my manager explaining what I was going to do and why. The next day I politely
confronted the program manager with my findings, deliberately walking into the axe, though he
Fiona Charles 19
didn’t actually fire me immediately. We ended with him declaring, “We’re going live in 8 weeks no
matter what.” and me replying, “You can’t. It’s too broken.”
I got home to an email from Jerry with sage advice and an invitation to continue corresponding,
ending with, “You know what to do, right? You don’t need me to tell you.”
Yep, I did know. I had done it. (I wrote a fictionalised account of some of this in my Better Software
article, Sophie’s Choice³⁴.)
That was the beginning of a long correspondence with Jerry, initially with him as my mentor, but
eventually as friends.
What did I learn from this? Everything, really, starting with a visceral understanding of the true
meaning of hubris. I’ve jumped into plenty of difficult situations since, often as the test manager on
project rescue teams, but never again have I let a success go to my head or succumbed to flattery.
My next biggest mistake was to get too emotionally involved and throw any attempt at perspective
out the window. I realised that I hadn’t truly internalised many of the important lessons of PSL,
especially self-care. In Satir terms, by failing to maintain the difficult balance of self, context, and
other, I had been incongruent and sabotaged my effectiveness.
I learned to ask for help when I needed it, rather than trying to absorb a huge burden by myself and
imploding. (I should say rather that I began to learn that. It took me years, and I’ve always found it
difficult.)
I also learned to distinguish “troubled” projects - which we can turn around - from “doomed” ones,
which we need to euthanise. I have since worked on another very large doomed project, but I went
into it knowing that was likely the case, and there were things I could do on it and things I could
learn from it, so it was worth my time and effort. I could maintain perspective.
Finally, that experience reminded me that there’s no shame in ending something that’s not working.
After this, I have always pulled out of assignments when I realised I could no longer be effective.
Another perspective on this miserable gig might be that it was a monumental failure in bug advocacy.
Our worst bug was a mysterious intermittent failure of this retail system to connect to the warehouse.
I knew it would be catastrophic if not fixed, and I suggested to the vendor’s development lead that
we jointly put together a SWAT team to focus on it. When we explained our rationale to the PM, he
thought we were being silly - “It’s a bug. We have lots of bugs!” - and told us to stop work on it.
Of course, they didn’t go live on the program manager’s do or die date. Nine months past it, the
system finally launched in the brick and mortar stores. Within a few days, they had to pull it out
again after a massive uproar from the business. The sales people were outraged that they couldn’t
schedule deliveries for large appliances or often even tell if an appliance was available to sell, because
the system kept dropping its connection to the warehouse. The sales people’s livelihoods depended
on commissions and they were losing big sales.
I know now that bug advocacy wasn’t remotely possible in a chaotic environment like that.
³⁴http://www.quality-intelligence.com/articles/Sophies_Choice.pdf
Fiona Charles 20
do?
That depends on the size of the thing I’m trying to do. If it’s smallish, like a piece of writing or
designing a workshop, I might shift from my desk to the office sofa, or go for a walk, or pull weeds
in the garden. I don’t usually work to music, but if I’m having trouble concentrating I’ll put on Glenn
Gould playing the Bach Goldberg variations. The orderliness of the music calms my mind and helps
me focus. Sometimes, I’ll switch to a different medium: mindmap or sticky notes instead of writing,
or diagramming a narrative arc for a talk. Or I work on something completely different.
When I’m doing client work, I more-or-less routinely spend a few quiet minutes debriefing my day:
noting and reflecting on decisions, accomplishments, unresolved items, and learnings. Reviewing
what worked and what didn’t helps me to see the bigger picture, and I often find solutions occurring
to me overnight or in the shower the next morning.
Typically, my partner and I talk most challenging work through with each other. We work in very
different fields, but frequently find the other has useful insights that can remove a block.
Fiona’s bio
Fiona Charles is an independent coach, consultant, and workshop facilitator specialising in the
human side of software development, quality, and testing. She teaches organizations to manage
their software quality risk, and software practitioners human skills “beyond process” - hands-on
practical skills essential to thrive, excel, and lead on any kind of software team.
Fiona delivers keynotes and conducts interactive workshops at international conferences and in-
house for clients, has recorded several webinars, and published many articles in quality-related
publications. She edited The Gift of Time³⁵ (2008), a book of essays celebrating the work of Gerald
M. Weinberg.
Contact Fiona via her website www.quality-intelligence.com³⁶, and follow her on Twitter @FionaC-
Charles³⁷.
³⁵https://www.amazon.com/Gift-Time-Fiona-Charles/dp/0932633757
³⁶https://www.quality-intelligence.com
³⁷https://twitter.com/@FionaCCharles
Anne-Marie Charrett
“I would encourage people to work on building mentors and sponsors who can help them navigate
their path.”
“A large chunk of my energy has either been spent trying to avoid, outrun, or prevent failure from
happening! What a failure that has been!”
“I’ve become wiser about the people I listen to and seek advice from.”
When it comes to respected members of the software testing

community in Australia, Anne-Marie is certainly up there on the
world stage. Her passion for testing, community-mindedness and
desire for sharing her knowledge are all appreciated well beyond
our Australian shores.
I’ve had the pleasure of Anne-Marie’s company many times, in
both formal and informal settings. And again that table at the
conference dinner at EuroSTAR in Dublin served me another treat,
with Anne-Marie on my table too. It was also great to involve
Anne-Marie in testing conferences I’ve organized in Melbourne
and I’ve appreciated her efforts in running conferences in Aus-
tralia, from CASTx17³⁸ to Let’s Test Oz³⁹ and, more recently, TestBash Australia⁴⁰.
Anne-Marie is also known for her work in improving diversity in the tech industry and I enjoyed
several years working with her in a volunteer capacity on the SpeakEasy mentoring programme
(now known as TechVoices⁴¹).
No-one I know decides to leave school and enter into a career of software testing. Most of us didn’t
know such a role existed. Instead, we fell into it. I was no different so perhaps that’s not so interesting.
Maybe a little more interesting is that I feel software testing chose me, not the other way around.
Having studied electronic engineering at University, my introduction to software testing was
developing automated test scripts that confirmed compliance to IEEE communication protocols. I
quickly discovered that compliance to a standard didn’t mean fit for purpose. At that point, the
philosophical question of “how do we know if a problem is solved?” entered into my psyche and
has never left me since.
³⁸https://therockertester.wordpress.com/2017/02/27/attending-the-castx-conference-in-sydney-21st-february-2017/
³⁹https://therockertester.wordpress.com/2014/09/19/greetings-welcome-to-the-context-driven-testing-community/
⁴⁰https://therockertester.wordpress.com/2018/10/25/er-of-attending-and-presenting-at-the-inaugural-testbash-australia-conference-
sydney/
⁴¹https://techvoices.org/
Anne-Marie Charrett 22
Nothing else I had done previously provided such depth of exploration and fed my curiosity in such
a satisfying way.
Co-founding and taking on a business partner in a tech consultancy has challenged me to grow
in ways I could never have imagined. When you find a business partner that complements and
challenges you, it’s truly a wonderful gift.
I think speaking has to come a close second. The relationships and friends I’ve made along the way
has been wonderful - smart, insightful people who have stayed with me along my journey. Thank
you all!
The IT industry requires the ability to take learning into your own hands. Technology is incredibly
fast-paced and what’s flavour of the month changes quickly. You need to be able to quickly learn
new approaches, technologies, and frameworks and adapt them to the context you’re in. You also
need good communication skills and the willingness to work with others.
In light of this, I would encourage people to work on building mentors and sponsors who can help
them navigate their path. Someone they can look to for advice and support. I’d also encourage people
to take learning into their own hands, don’t wait to be given permission to learn something new -
that power always lies in your own hands.
disagree with?
I’ve grown averse to people who say practices and ideas are good or bad. Developing software is not
easy, it’s not a science and the reality is that what is considered bad practice for many might be just
perfect for your context. The truth is, if it looks like it might work, try it out. That’s the easiest way
to discover if something is going to work for you or not. If you are not in a situation where you can
do this, look for people with open minds and humility to see ideas from multiple perspectives.
how?
The past two years I’ve taken up meditation on a regular basis. It’s given me a broader perspective
on what matters in life, such as the importance of family, friends and working together. I hope I’m
more tolerant of shortcomings within myself and others.
I would encourage people to look for mentorship and advice from many people with diverse ideas. I
write this with hesitancy, as I’m not sure my younger self would have really listened but, if I could
have bent her ear, I would say “ask for help, you don’t have to conquer the world on your own”.
The main factors that have influenced my testing approaches have been to understand what people
want out of hiring me or asking me to assist in their project. Once I understand that, I then look to:
1. Understand the system under test. I analyse and build a model of the system, based on reading,
conversation and by performing tests. I do this to build a rich understanding of what I’m testing.
I then query that model, challenge it and look for flaws, oversights in the model that might
negatively impact how the system operates.
2. Understand any constraints that might impact my testing, with time often the biggest
constraint. I was once asked to test a website that was due to go live in ten minutes! If I hadn’t
asked that question, I would have attempted a totally different testing approach that would not
have delivered on my client’s expectations.
3. I also look to figure out who can help me and what resources are around that can help either
speed my testing up or make my testing better. Test Data and Test Environments are two
classic areas that are good to investigate. But more and more, I look to find people who can
perform software testing too. There’s also nothing like getting support from a systems architect
or software developer or customer support person who can help with your software testing. It
takes your software testing to a different level.
Testing
• Customer Oriented Software Quality Assurance⁴² by Frank P. Ginac

• Lessons Learned in Software Testing⁴³ by Cem Kaner, James Marcus Bach and Bret Pettichord
• Exploring Science: The Cognition and Development of Discovery Processes⁴⁴ by David Khlar
• The Secrets of Consulting: A Guide to Giving & Getting Advice Successfully⁴⁵ by Gerald M.
Weinberg
• Teaching Thinking⁴⁶ by Edward de Bono
• The Coaching Manager: Developing Top Talent in Business⁴⁷ by James M. Hunt and Joseph R.
Weintraub
• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing
Technology Organizations⁴⁸ by Nicole Forsgren, Jez Humble & Gene Kim
• Training from the Back of the Room⁴⁹ by Sharon L. Bowman
• Antifragile: Things That Gain from Disorder⁵⁰ by Nassim Nicholas Taleb
• The Black Swan: The Impact of the Highly Improbable⁵¹ by Nassim Nicholas Taleb
⁴²https://www.amazon.com/Customer-Oriented-Software-Quality-Assurance/dp/0135714648
⁴³https://www.wiley.com/en-au/Lessons+Learned+in+Software+Testing:+A+Context+Driven+Approach-p-9780471081128
⁴⁴https://www.amazon.com/Exploring-Science-Cognition-Development-Discovery/dp/0262611767
⁴⁵https://www.amazon.com/Secrets-Consulting-Giving-Getting-Successfully/dp/0932633013
⁴⁶https://www.amazon.com/Teaching-Thinking-Edward-Bono/dp/0140137858
⁴⁷https://www.amazon.com/Coaching-Manager-Developing-Talent-Business/dp/1483391655
⁴⁸https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339
⁴⁹https://www.amazon.com/Training-Back-Room-Sharon-Bowman/dp/0787996629
⁵⁰https://www.amazon.com/Antifragile-Things-That-Disorder-Incerto/dp/0812979680
⁵¹https://www.amazon.com/Black-Swan-Improbable-Robustness-Fragility/dp/081297381X
• On Dialogue⁵² by David Bohm
Personal life
• Rising Strong⁵³, Daring Greatly⁵⁴ and Dare to Lead⁵⁵ by Brené Brown

• Difficult Women⁵⁶ by Helen Lewis
• The Untethered Soul: The Journey Beyond Yourself⁵⁷ by Michael A. Singer
important failure?
A large chunk of my energy has either been spent trying to avoid, outrun, or prevent failure from
happening! What a failure that has been! Of course, the role of a software tester is to point out failure
in systems. So perhaps we are all intimate with the study of failure.
Still, failure can be painful and hard to endure. It’s not something I actively seek out. While I don’t
enjoy the experience of failure at the time, it does teach me a lot about myself and how to engage
with those around me. Because of failure, I have more empathy, more compassion and more patience
with those around me. I listen more and I don’t always have to be the one with the answer.
Most important failure, eh? One of them has to be when I failed to stop software with a critical bug
from being released. I learned the pointlessness of being a gatekeeper from that experience and that
I didn’t have the power to ‘ensure’ quality without control over all elements of software delivery.
The buck didn’t stop with me - whoot!
I’ve become wiser about the people I listen to and seek advice from. I’ve come to realise that there
are people in your life who will always be there for you, and those who will not - and that’s ok.
do?
The very nature of being overwhelmed can make it hard to know what to do. That’s why they call
it overwhelmed! Over time though, hindsight has helped me give myself space and to allow these
feelings to exist. To also realise that the moment will pass and finally, to try not to beat myself up
too much about it.
⁵²https://www.amazon.com/Dialogue-Routledge-Classics-76/dp/0415336414
⁵³https://www.amazon.com/Rising-Strong-Ability-Transforms-Parent/dp/081298580X
⁵⁴https://www.amazon.com/Daring-Greatly-Courage-Vulnerable-Transforms/dp/1592408419
⁵⁵https://www.amazon.com/Dare-Lead-Brave-Conversations-Hearts/dp/0399592520
⁵⁶https://www.amazon.com/Difficult-Women-Imperfect-History-Feminism/dp/1787331288
⁵⁷https://www.amazon.com/Untethered-Soul-Journey-Beyond-Yourself/dp/1572245379
Anne-Marie’s bio
Anne-Marie excels at creating spaces where quality thrives.
As co-founder of Testing Times⁵⁸ and its principal quality engineer, Anne-Marie is the lead advocate
on quality engineering and how to navigate change and keep quality in the minds of all. Standing
her in good stead is her years of experience as Head of Engineering at Tyro Payments⁵⁹, Quality
Engineering Consultant and Test Automation Engineer. Anne-Marie’s technical background as an
Electronic Engineer has enabled her to speak to both technical and product expertise.
Anne-Marie is an international keynoter having spoken at multiple international conferences. You
can read more about her ideas on her blog, Maverick Tester⁶⁰ and/or catch some of her thoughts on
Twitter at @charrett⁶¹.
⁵⁸https://testingtimes.com.au/
⁵⁹https://www.tyro.com
⁶⁰https://mavericktester.com
⁶¹https://twitter.com/charrett
James Christie
“Retaining a deep interest in testing is worth far more than a fatter bank account.”
“I think that I underestimated the value of my skills and experience and I overestimated the benefit
of formal processes in guiding me.”
“I always thought I’d regret turning down an opportunity to do something difficult just because I was
frightened I wouldn’t cope.”
I first met James at the EuroSTAR conference in Dublin back in

2014 and also had the pleasure of his company during the splendid
conference dinner for that conference held at Croke Park Stadium.
His background in both auditing and testing gives him a unique
perspective on our craft and his blog posts⁶² are always thought-
provoking. When I had the opportunity to choose keynote speak-
ers for the CASTx18 testing conference⁶³ in Melbourne, James
immediately came to mind and it was great to see him on the big
stage (and also give him his first chance to experience Australia!).
Sit back and enjoy his tales of testing, auditing and walking his
dog.
I had worked in IT for 14 years before I entered testing. I was a developer and dev team leader,
business analyst, systems analyst/designer, project manager and IT auditor. I later took three years
out from testing to work as an IT security manager. I was asked to move into that role because of
my experience in audit (especially security reviews) and project management. I had also worked in
an insurance company’s investment division in an accounting role.
All of these roles helped me to improve my understanding of testing. It was extremely valuable to
see the same problems from different perspectives. It also helped my credibility when I was arguing
a controversial point. I had been a dev and development team lead. I had been an auditor. I had been
a security manager. I had worked in the business.
It’s 40 years since I first embarked on a serious career. I’m still fascinated by testing and the challenges
it poses. Maybe I could have earned more if I’d followed a steady career progression in a single
discipline. Maybe that would simply have taken me into a career dead end. What I do know is
that retaining a deep interest in testing is worth far more than a fatter bank account. That deep
⁶²https://clarotesting.wordpress.com/
⁶³https://therockertester.wordpress.com/2018/03/08/castx18-context-driven-testing-fun-in-melbourne/
James Christie 27
interest follows on from the previous question and answer. It has always been worthwhile, for me,
to step sideways into completely new roles rather than insist on staying where I was till there was
an opening that would let me move upwards. These moves into new roles have been challenging
but I think they kept me interested and relevant.
My variety of experience has taught me that the really difficult problems are rarely simple and
always interesting. These complex and fascinating problems almost always involve multiple systems
and affect a variety of people with different roles, and even in different organisations. It’s hard to
gain a good understanding of this wider problem, and people who can offer that are very valuable.
Make sure you get a variety of experience. The trick is to balance the need to build up transferable
skills while also acquiring deep expertise in a couple of areas, whether business or technical.
Don’t believe that certifications will open the door to a wonderful career. In my experience the best
you can hope for is that they will get you hired by companies you’ll probably want to leave within
a year.
disagree with?
For a long time I’ve objected to the idea that software testing is suitable for the sort of prescriptive,
detailed standards that ISO has been pushing. I could write about that at great length. In fact I’ve
done so! ISO’s approach has shown they understand neither the essential nature of testing nor the
way to regulate complex activities.
how?
That’s definitely getting a dog. Having a Labrador has forced me to step away from the keyboard,
get outside and go for a walk, however cold and wet it might be. Life has to be organised around
that simple duty. Apart from the obvious benefit of fresh air and exercise, going for a walk gives
the mind time to reflect on problems and come up with new ideas. Continually attacking a problem
head on isn’t the best way to solve it or come up with creative ideas.
Psychologists recognise that the creative process starts with two stages. First comes the preparation
stage. We familiarise ourselves with a cognitively demanding challenge. We then have to step
away from the problem and perform some activity that doesn’t require much mental effort. This
is the incubation stage, which gives our brain the opportunity to churn away, making connections
between the problem, our stored knowledge and past experience. Crucially, it gives us the chance to
envisage future possibilities. Suddenly, and without conscious effort, the answer can come, as it did
to Archimedes, whose original eureka moment arrived in the bath when he realised that the volume
of irregular objects could be calculated by the volume of water that they displaced.
Walking the dog is a good way of allowing that eureka moment to occur. Once, when I was on
holiday, walking on a beach, I suddenly had an insight about a novel technical approach we could
use to guarantee fast response times for a system I had recently started designing. I wasn’t worrying
James Christie 28
about work, and I certainly wasn’t consciously trying to solve a problem, but the answer suddenly
came to me. I made a few notes back at the cottage and got on with the holiday. When I returned to
work I tried out my idea. It worked beautifully and was built into the system, turning the sluggish
response times we feared we’d get into reliably fast responses.
I think that I underestimated the value of my skills and experience and I overestimated the benefit
of formal processes in guiding me. These processes are important, but they have limits.
My testing approach was based on the context and the needs of the users, but I often felt frustrated.
I felt that I was doing something that happened to work in that context, but which was allowing me
to gain little in the way of what I considered, real, orthodox testing experience. I later realised that
I was doing good, relevant testing for the sort of complex, finance systems I was working on. What
I had considered real testing was only the sort of process driven, cookie cutter approach that was
routinely performed, with indifferent results, on simpler systems.
I don’t think it would have made any difference to my choices if I had realised this earlier, but I
would have felt more relaxed and confident about what I was doing.
I’d recommend James Bach’s and Michael Bolton’s Heuristic Test Strategy Model, the outline of
which they’ve provided for free. However, even before getting into the test strategy there are some
factors I always insist on talking about. Different projects have different factors, but these are the
ones I always want to consider.
People: It’s vital to understand what’s driving the people you’ll be working with. What are their big
fears and hopes? I find it hard to think my way into a project until I have a feel for the people.
It’s remarkable how you can quickly expose fundamental contradictions with relatively gentle
questioning.
The apparently unwavering commitment to high quality can vanish when it becomes clear that
some very important people have staked their reputations on meeting the target dates. On a different
project an insistence on the importance of hitting the dates can feel different when you see the body
language of key users when they are confronted with the possibility of featuring in a press story
about serious defects with the system.
Talking to the right people and understanding them and their concerns can mean the job looks very
different from the way it was envisaged when the testing effort was estimated. It might be much
bigger, but it can also be smaller. On a couple of occasions I have realised that providing the right level
of information and reassurance about the solution can be achieved with an imaginative and cheaper
approach. There was one interesting time when it became clear the client was far less worried about
the technical solution than how users would be able to respond to problems (business problems,
not bugs). We shifted effort from conventional testing to walkthroughs, a form of wargaming to
establish that problems would be handled quickly and effectively. That happened to be much easier
James Christie 29
and cheaper to organize than the original estimates had assumed, and it gave the client all the
reassurance they wanted. That confidence turned out to be justified when we went live.
Another people issue I try to clarify as quickly as possible is whether there will be domain experts
available at the right time to help with test planning and interpreting test results. That’s vital with
deeply complex financial systems. I remember one project where there was a single, key expert.
We would need her for 10 days in November. She already had 10 days holiday booked, and was
committed to another project for 20 days, all in a month with 22 working days. Naturally both
projects were deemed to be business critical, with fixed target dates that had been dumped on them
by senior management. Both projects were late – of course. It was obvious that would happen, but
no-one wanted to admit it.
You can go to the contract market to hire testers with good general skills, but you have to grow deep
domain experts. That’s a very long process and in the short to medium term that’s relevant to the
average project these people are irreplaceable. If they are not available when you want them you
have to plan the testing around when you can get them. It amazes me how often people are reluctant
to say at an early stage, “we can’t do this in the timescales you want because the right people won’t
be available”. To a certain extent you can shape the testing to make it easier to cope with less input
from the domain experts, but that just raises difficult choices. “Are you going to give us more time?
Or accept the testing won’t be as good?” It’s always good to have these questions flagged up and
addressed early, instead of keeping quiet and hoping for the best.
Conway’s Law: This states that the design of systems corresponds to the design of the organisation.
It’s not a normative rule, saying that they should fit each other. It merely says that they generally do
correspond to each other. Traditionally the organisation’s design shaped the technology. Nowadays
the causation might be reversed, with the technology shaping the organisation. Conway’s Law was
intended as a sound heuristic, never a hard and fast rule. It might be less generally applicable today,
but for large, long established corporations I think it still generally holds true. Conway’s Law means
that organizational problems create system problems.
I picked up on the importance of Conway’s Law as an IT auditor. Our audits were always strictly
time boxed, so we had to focus our efforts where we could pick up the most significant problems most
quickly. When we audited live systems we were guided to the low hanging fruit by Conway’s Law.
The worst problems tended to be around the interfaces, the boundaries between different teams.
There we would find last minute, clumsy fixes, hastily lashed together, with inevitable bugs and
unforeseen problems – ready to be exposed by the auditors.
In my experience as a developer, tester and IT auditor I’ve seen the same damaging pattern unfold
when different development teams, or different companies work on different parts of a project. As
a test manager I want to see the project manager being proactive and ensuring that the high level
requirements are clear, complete and consistent before the different development teams get locked
into their delivery schedules, or, to put it another way, that the level of detail in the schedule is
consistent with the level of detail in the requirements. That’s easier said than done, and it may not
be politically possible. However, failing to do so is very risky.
The different teams, especially if they’re in different companies, might base their estimates on
James Christie 30
assumptions that are wrong, or which are inconsistent with other team’s assumptions. Under
pressure to deliver quickly each team might assume they’ll be able to do the minimum necessary,
especially at the interfaces, with other teams picking up the trickier stuff. This can create gaps at the
interfaces, and cries of “but I thought you were going to do that - we can’t possibly cope with that
in time”.
Hence the need for an integrated, coherent, over-arching test strategy. The test manager has to be
involved all the way through and has to be wary about delegating too much responsibility for the
early stages of testing to any suppliers. The easy option is to let the different teams independently
build and integration test their own chunks of the system, then pull them all together for full-scale
integration testing.
That’s much easier to plan and manage, but it’s storing up problems. You have to try and get the
different teams working together, even if it’s only using test data generated from one team’s testing
as input to other teams’ testing. If each team simply makes up the test data that they expect to come
from another supplier then they will do so based on their own assumptions of what they’ll be getting.
Then, when you pull everything together, the interface crashes because the data that arrives from the
other team is completely unexpected. This all requires effort and co-ordination, and there’s a huge
temptation to pretend shit won’t happen. In my experience you never dodge problems by closing
your eyes and hoping they won’t trip you up.
Conway’s Law always guided me as a test manager too, as did another technique I picked up as an
auditor.
The “always” events and the “never” events:
As early as possible I always want to find out what the key people think must always happen, and
must never happen. This was our standard approach as IT auditors planning an audit of live systems.
It wasn’t really a form of risk analysis. We didn’t consider at that early stage the likelihood of bad
things happening and good things failing to happen. It helped us to get a sense of the limits of what
was acceptable, and think about how to test that the system would remain within those limits. We
would always be asking the same questions. “How do we know that the system will do what we
want? How does the system prevent the outcomes that must never happen? How does it ensure we
get the outcomes that must always happen?” That would be the basis for our audit testing, to try
and break the system and shatter illusions about how it behaved.
I carried this forward into testing, and it became instinctive to ask these questions, all the time, but
especially at the start when trying to get my head around the limits of acceptable behaviour.
Predictably the most influential person has been Jerry Weinberg. I read his The Psychology of
Computer Programming⁶⁴ when I was a trainee developer. Perfect Software and Other Illusions
about Testing⁶⁵ has been the most directly influential book I’ve read. I really must read both of them
again.
⁶⁴https://www.amazon.com/Psychology-Computer-Programming-Anniversary-1998-09-03/dp/B01FIW5AS6
⁶⁵https://www.amazon.com/Perfect-Software-Other-Illusions-Testing-ebook/dp/B004J4VVE2
James Christie 31
An influence that might surprise people more is What is History?⁶⁶ by Edward Hallett Carr. This is a
classic attempt to define the academic discipline of history and its methods. It made me think more
deeply and seriously about evidence, facts, and our role in selecting the evidence and facts that we
will use. An event does not become a historical fact merely by happening in the past. It acquires
significance depending on the interpretation we choose to put on it, and that depends on our beliefs,
assumptions and the story we want to tell.
I don’t agree with all that Carr argued, but as with any such serious academic book the act of
disagreeing forces the reader to think through the problem carefully. I found numerous parallels
between the role of testers investigating a system so that they can tell a compelling story to the
people who matter and the role of historians trying to make sense of the past so they can construct
a narrative explaining what happened.
On a personal level, as a Christian I can’t omit the Bible. However, that has also had an impact on
my working life. Once, when I and my testing team were under a ridiculous amount of pressure,
someone commented that she was amazed how little stress I appeared to be suffering. That was at
a time when my father was terminally ill, I was about to get married, and I had some heavy charity
commitments outside work. The simple answer to the apparent lack of stress was my faith. It gave
me the confidence to know that I would cope with it all. I didn’t lose any sleep, and certainly not
over work, and I was able to tackle the project calmly and, in hindsight, with sound judgment.
important failure?
It rankled for years that I got a poorer degree than I should have done. I suffered something of a crisis
of confidence when I was an undergraduate. I expected to do badly and that became self-fulfilling. I
was disorganised and spent too much time reading interesting books I found in the university library
that had no relevance to my course. I don’t think it was a mental health issue. I was too immature.
I took a year out afterwards, working in the stores and mail room of a big insurance company. The
simple discipline of having to get up and be at work for 7 o’clock every morning was invaluable.
After that I went back to university for a postgraduate course and I did very well. I had thought I
wasn’t intelligent enough to succeed at university, but I learned that you don’t have to be particularly
bright to do well. Motivation and organisation are far more important. Since then I’ve had a third
spell at university to do a master’s degree, which taught me a lot about how the IT profession
developed in the way it did. I’ve almost got that poor performance as an undergraduate out of my
system, but to be honest, it does still annoy me.
Working in IT I don’t think I’ve had any big failures as others would see them. I once had the
reputation as a test manager for being too critical, and self-critical, when I wrote the sections of test
completion reports dealing with how we had tested. I always took the line that we could have done
better and should try to learn. Others thought that test completion reports were an opportunity for
self-promotion or at least to defend what they had done. They thought I was naïve in being openly
self-critical. I thought their approach was pointless, and they were also being naïve; an excessively
positive report fooled no-one.
⁶⁶https://www.amazon.com/What-History-Edward-Hallet-Carr/dp/039470391X
James Christie 32
There was one project when I still feel I made some poor decisions. It was a nightmare from start
to finish. It was a big data migration where the developers and testers were all working for an
outsourcing supplier. The client was appalling. They were persistently reckless and irresponsible. It
was clear from the start that they didn’t care about quality, only being able to report to the Stock
Exchange that the promised reorganisation and resulting costs savings following a merger had been
achieved.
The developers weren’t given nearly enough time to do an adequate job. The test window was
laughably short. There would be no iteration to get it right, or phased migration. Everything was to
be converted in one go, with no regard for the consequences.
The requirements for the migration ignored potential problems that were obvious to the domain
and system experts. The inevitable, and predicted, result was that customers’ records were lost;
there were no safeguards to ensure this was either prevented or detected. Client staff continually
bypassed the test team by reporting bugs directly to the developers, then complained when my test
reports were incomplete and inaccurate, which rightly got a terse response (“you didn’t tell us about
these ******* defects, that’s why they’re not in the report”).
Worst of all, in my opinion, client staff even pressured developers to make last minute changes to
code immediately before it was released to production; “it’s a simple change – it doesn’t need to be
tested – we really need you to change the code”. Happily, every time it happened the devs responded
in the correct and approved fashion; “**** off – it’s more than my job’s worth”.
There was some friction between me, as test manager, and development team leads, over the extent
of my authority. The devs were too happy to take instructions from the client at face value, with
the result that some of the conversion routines were written in a way that made testing harder and
undetected mistakes more likely. The dev team leads refused to comply with my requests to make
the routines more testable, arguing that devs take orders from the client, not testers. I should have
fought harder to bring them into line. I didn’t, and still don’t, consider a negligent client as an excuse
for IT people to do poor work. I should also have persisted with my attempts to get client staff to
put unreasonable requests in writing, regardless of whether I was going to comply. I should have
been more careful in ensuring there was a proper paper trail for the inevitable post-mortem.
That project was an unpleasant experience. I don’t feel I was irresponsible and I don’t have any
sense of guilt, but I do wish I had taken a less diplomatic approach with people who were being
cynical and negligent. I thought, wrongly, I needed to maintain a constructive relationship with
these people for the future. I should have confronted them more forcefully, as I had learned to
do anyway as an auditor. The project convinced me that traditional, linear, development practices
(based on the Waterfall) were inadequate when there was a need to move quickly. From then on I
held to the line that if you want rapid development you have to follow a method designed to enable
speed. You don’t do it by cutting corners botching more methodical approaches.
As it transpired, this was my last project as a test manager for a few years. I was approached about
moving to an IT security management role. The timing was good. A break from testing was attractive
so I accepted.
James Christie 33
I don’t think I am any better. It’s not something that particularly worries me. The professional
invitations are usually attractive, and the personal “distractions” are either equally attractive or
things that I know I should be doing, regardless of how enthusiastic I am. On the rare occasions I’ve
turned down the chance to talk or write about something it’s been because I’ve genuinely felt I’ve
nothing to say at that time.
It’s an odd feature of my career that after I started in IT every time I made a big change I didn’t
apply for it – until I decided to go self-employed after 23 years. Up till then I was always approached
first and offered the chance to move. Each time it was a bit scary, but I was never able to resist the
challenge. I always thought I’d regret turning down an opportunity to do something difficult just
because I was frightened I wouldn’t cope. Every few years something interesting would crop up
and I had the choice of going or staying. I’ve seen other people who were far more cautious, who
would never consider jumping unless it was for a promotion and they were convinced they could
do the new job. Otherwise they’d stick where they were, in their comfort zone. It was a good way
to stagnate.
do?
I make a conscious decision to step away. I might spend a day or two on a personal project, or simply
pick up a book to read. I would always go for a walk too. With an active young Labrador, that’s an
easy option. As I explained in my answer to question 5, stepping away from a problem can give the
mind time to address it.
James’s bio
I am a software testing consultant based in Perth in Scotland working under the name of Claro
Testing. My main area of interest is the governance issues associated with testing. My IT career
started in 1982 and I in addition to testing I have worked as a developer, systems analyst, business
analyst, project manager, IT auditor and IT security manager. Most of my experience has been in UK
financial services, but I also worked with a large IT services company before going self-employed.
Cheryl Downes
“I’ve certainly found that the most challenging people and projects I have worked with have been the
ones where I have learned the most.”
“I tend to ignore advice which doesn’t come with evidence, or is too straight.”
“Technical skills are not enough. You will need to evolve and react almost daily to new things. So I
think it’s important to be resilient.”
I used to regularly attend the ANZTB⁶⁷’s “Special Interest Group

in Software Testing” meetings in Melbourne and first encountered
Cheryl via her involvement in organizing and presenting at these
meetings. We would also often cross paths at testing conferences
and I particularly remember spending quality time with her at the
ANZTB’s “Advancing Expertise in Software Testing” conference
in Auckland in 2015. Cheryl’s willingness to share knowledge
and engage with the community has always been inspiring. It’s
especially awesome to have a fellow vegan contributing to this
book (“vegan software testers” is certainly a niche community, but a growing one)!
Perhaps it’s not so much the path but the people and projects. I’ve certainly found that the most
challenging people and projects I have worked with have been the ones where I have learned the
most. Also being thrown in the deep end, but surrounded by a ‘can do’ culture has been interesting.
It has opened up many opportunities for me which I have largely enjoyed - except for that one time
when I wanted to give it all up and join the fire brigade instead.
I find it challenging to say because I’m generally not a fan of certification, but sitting the ISEB (now
ISTQB) certification back in the early 2000s would possibly be the most worthwhile. It’s definitely
worth noting that the value wasn’t in the certification itself, but in the network that it contributed
and the path I continued thereafter. For several years I ran the Melbourne SIGiST and was an
associate board member of ANZTB. Those experiences of running mini conferences every quarter
and working together with such a broad range of people was incredibly helpful to me, and no doubt
helped me professionally.
Two other investments which were significantly valuable for me was my studies in Psychology
(Graduate Diploma in Organisational Psychology) and Computing. I came into testing originally
⁶⁷https://www.anztb.org/
Cheryl Downes 35
with a Bachelor of Arts degree where I majored in Psychology and Data Analysis. Through a series
of events, I found myself working in testing without having any formal education in technology. To
this day, I still believe that psychology degree has given me so much, because I often find that if
you can work out the best ways to work with people, and to get them to deliver their very best and
enjoy doing it, then that’s ‘success’.
As technology evolved, I found myself lacking understanding of some concepts, so I went back to
uni and studied ‘Internet and Web Computing’. The structured learning was valuable, but it’s never
enough, so I’m always reading, listening and tinkering.
Learn and challenge yourself as much as possible. The industry constantly evolves, and if you think
you know it all, you will soon be left behind. Open yourself to experiencing and understanding as
much as possible. Put your hand up for challenges. Work on big projects and work at a startup. Build
your own things and tinker. Take risks and absolutely be ready to fail, learn and do it all over again.
Work with companies and products that you’re passionate about. It makes it easier.
Ignoring advice is an interesting idea. First listen and seek to understand the advice. Take your time
to weigh up the advice before deciding what to do with it and if it truly doesn’t fit, keep it in your
toolkit for another time. I think there are learnings in almost everything. That said, I tend to ignore
advice which doesn’t come with evidence, or is too straight. I like to bend the edges and I’m certainly
a fan of being pragmatic given the context.
disagree with?
I don’t agree with ‘anyone can test and we don’t need testers’. But I also agree with it as well. It’s
contextual. Depending on the maturity and circumstances of individuals and organisations, either
can be true. I honestly try to have an open mind.
how?
It has probably been more than five years, but the ownership of quality and product is shared across
the team and organisations becoming so much more customer-centric in what they’re doing.
Technical skills are not enough. You will need to evolve and react almost daily to new things. So I
think it’s important to be resilient.
Fads are cool and exciting. Sometimes they will fail but it’s still a great learning experience. Work
with your networks and develop your ability to influence others. Testing is not often seen in the
‘maker’ category, so value isn’t inherently linked. Your ability to influence people with data and
stories will be key to your success.
Cheryl Downes 36
Context is probably the single biggest factor. Context can drive conversations about quality. Having
worked in banking and finance, the regulations are significantly different to working at a startup
building social apps. The implications of quality are significantly different as well. I’m not suggesting
that one is more important than the other because in banking, every cent counts, in social apps, a
person’s experience counts.
Lessons Learned in Software Testing⁶⁸ (Cem Kaner, James Bach & Bret Pettichord), Agile Testing⁶⁹
(Lisa Crispin & Janet Gregory) and possibly the first edition of Managing the Testing Process⁷⁰ (Rex
Black). I’m not sure that I would necessarily say they have the same relevance now, but at the time
they validated what I was doing. These days I’m much more inclined to get my reading fix from
meetups, webinars and blogs. If you listen to experiences from other people, you may be able to use
it later.
important failure?
I was too cautious and in my own mind I believe I waited too long. I was waiting for an update to a
COTS app, which would enable it to be tested with an open-source tool that I strategically wanted us
to test it with. If we automated on the current version, I felt we would be wasting company money,
so I held off.
As you can appreciate, the COTS update was out of my hands. The delays pushed out from weeks
to months and eventually close to a year. I lost valuable time in setting us up for automation.
I think with the advent of online meetups, I possibly haven’t said no because I actually find it easier
to connect. I am selective with my time and sign up for quite a lot of meetups, and even if I can’t
attend, with any luck, there’s a recording.
The last time I really said no was when I ‘retired’ from running the ANZTB SIGiSTs. They took a
lot of time to organise. Getting speakers was quite often challenging and the format possibly needed
changing so it was great to have people ready to pick it up and deliver it in their own way.
do?
I tell myself that’s ok and then I go off and do something else with a view to coming back later.
⁶⁸https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124
⁶⁹https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468
⁷⁰https://www.amazon.com/Managing-Testing-Process-Practical-Techniques/dp/0470404159
Cheryl Downes 37
One of the best characteristics I have is that many things interest me, so if one isn’t working, I will
happily go off and do another. Whether it’s writing about women’s football, reading lesbian fiction
or tending to my neglected vegetables, there’s always something to do.
Cheryl’s bio
Enabling teams to deliver quality outcomes through innovation and collaboration
Cheryl has immersed herself in quality and testing for over 20 years, learning and leading the best
way of the day across a range of industries. Cheryl focuses on strategies to develop context-specific
delivery methods for optimal product quality and customer happiness.
Coaching and leading by example is her ‘way of working’ and never resting on the laurels of
yesterday. What is done is done. Focus on what you are doing and will do.
Kim Engel
“It took me a long time to realise that it’s okay to enjoy my role and not push for promotions along a
management career path.”
“I’ve supported my team members in taking mental health leave or other well-being measures when
they need to.”
“I’ve recognised that I should not spread myself too thin across social networks and community
groups.”
Kim and I have crossed paths many times over the years, usually
on the conference circuit. I remember spending quality time with
her at the inaugural Let’s Test Oz conference⁷¹ in the wonder-
ful surrounds of the Blue Mountains, inland from Sydney. She
has been a keen contributor to the testing community and an
advocate for context-driven testing. Kim’s natural empathy and
compassion are evidenced in her human rights advocacy work for
refugees - and these traits are also on show in her answers below.
What do you think is the most interesting aspect of your path
to a career in testing?
I started my testing career 20 years ago, and it was very common
at the time for people to find themselves working in software testing by chance rather than by
design. I initially started working in IT as a graduate programmer, after completing a bachelor’s
degree in commerce with a major in IT. The university degree was heavily theory-based, with the
only practical component being some requirements analysis and programming. After three years of
study, I found myself with a large debt, and the only career path that I felt even remotely qualified
for was programming.
Shortly after I started as a programmer, the Test Manager was recruiting when all external
recruitment was put on hold. She began scouting internally for someone to join her team, and when
she approached me I agreed because I was keen to learn more about the company’s software systems
besides the single application I’d been working on. In my new testing role, I enjoyed thinking about
system quality and risks from a broader perspective, the user-centric approach, and working with
many different people in the organisation.
Working in software testing helped to develop my transferable skills, such as communication,
questioning techniques, relationship building, and adaptability. Having that basic knowledge of
⁷¹http://lets-test.com/?page_id=1863
Kim Engel 39
programming concepts also helped a lot when communicating with developers and investigating
bugs.
A few investments in my career stand out for me as worthwhile, mainly related to investing my
time and effort rather than money.
• BBST Foundations course⁷² - Prompted and supported by Anne-Marie Charrett who was my
manager at the time. This course by Cem Kaner caused me to question everything which I’d
believed about software testing for the previous 10 years and opened my eyes to the more
creative, challenging, and interesting aspects of software testing.
• Rapid Software Testing course⁷³ - James Bach inspired me to think deeply about testing as a
craft and the factors which influence our testing approach. This course has a strong emphasis
on taking a deliberate and risk-focused approach to testing, and adding value with every testing
activity.
• Ministry of Testing community⁷⁴ - Meeting test professionals who continue to support each
other, learn together, and provide advice for new testers.
• AppliTools Test Automation University⁷⁵ - I’m currently working my way through these free,
self-paced coding courses.
If you start a career in IT for the money alone, and you’re not passionate about technology, you risk
always feeling a few steps behind. Instead, jump in with both feet and immerse yourself in your
chosen career:
• Consider taking one of the training courses mentioned in my previous answer.

• Read books such as Perfect Software: And Other Illusions about Testing⁷⁶ (by Gerald M. Wein-
berg), Lessons Learned in Software Testing⁷⁷ (by Cem Kaner, James Bach & Bret Pettichord),
A Practical Guide to Testing in DevOps⁷⁸ (by Katrina Clokie), and Explore It!⁷⁹ (by Elisabeth
Hendrickson).
• Watch videos from the EvilTester - Software Testing channel⁸⁰ on YouTube by Alan Richardson.
• Most importantly, join the Ministry of Testing online community, reach out to people, and ask
for more tips on how to get started.
⁷²https://associationforsoftwaretesting.org/bbst-black-box-software-testing-courses/foundations/
⁷³https://www.rapid-software-testing.com/
⁷⁴https://www.ministryoftesting.com/
⁷⁵https://testautomationu.applitools.com/
⁷⁶https://www.amazon.com.au/Perfect-Software-Other-Illusions-Testing/dp/0932633692
⁷⁷https://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124
⁷⁸https://leanpub.com/testingindevops
⁷⁹https://pragprog.com/titles/ehxta/explore-it/
⁸⁰https://youtu.be/iOA3lxZyFwA
Kim Engel 40
disagree with?
There is a trend towards devaluing testers who have outstanding domain knowledge and limited
technical skills. Technical skills often come through changing roles and working with different
technologies. Domain knowledge comes with staying in the same company or industry for years. A
great software team should have both. The subject matter expert (SME) can be anyone on the team,
but when you combine strong exploratory testing techniques with deep knowledge of the business,
you have a valuable team member who will help reduce wasted time and minimise quality risks.
Another practice that remains common is “playing the blame game” after a production issue is
identified. Regardless of intentions and statements of a blame-free culture, this will always come
down to individual leaders and how they handle stressful situations. Team members can provide
feedback on factors affecting team culture during post-incident reviews, retrospectives, or one-on-
one meetings, to help raise awareness of any issues. Teams that continue to struggle in this area
over time should consider engaging an agile coach. Agile principles have a strong focus on people
and empowerment, and a good agile coach will facilitate open and productive discussions. They can
provide leadership coaching and are experienced in culture transformation. This article⁸¹ explains
more about the role of an agile coach.
how?
“I’m not going to do bad work” - Fiona Charles. This quote was part of a keynote presentation that
has really stuck with me. I think of this quote as a benchmark when I’m asked to work on deliverables
that don’t add value to the project or to the company. It gives me the confidence and encouragement
needed to speak up, to ask more questions, to suggest alternatives, and to make sure that my work
is delivering value.
Visual test coverage modeling⁸² - Aaron Hodder and Adam Howard. A conference talk by Aaron
introduced me to the idea of using mind maps for test planning. I was intrigued and thought about
it often, and I even went to see Aaron’s talk again at a local Meetup event. Finally, I experimented
with using mind maps for my own test planning and I saw instant results. Presenting my plans in
this way encouraged brain-storming and collaboration. Prior to that, when I did receive feedback
on test plan documents the comments were mainly focused on the formatting… I’ve now taught the
theory and practice of using mind maps at multiple Meetup events and encouraged others to adopt
this approach as well. Visual test coverage modeling stands out as the key factor affecting how well
the rest of the team perceives the testers and their work.
Giving back to the community - Catherine Karena. Working with Catherine over the years and
following her progress has encouraged me to pursue challenges that matter outside of work. Even if
we’re not lawyers or doctors, we have skills that we can use to help others. Test-Ed⁸³ is an excellent
example of that principle in practice, along with EPIC Assist and Per Scholas. Staying within the
⁸¹https://www.cio.com/article/3294700/agile-coach-role-defined.html
⁸²https://assurity.nz/archives/part-1-aaron-hodder-on-using-mind-mapping-software-as-a-visual-test-management-tool/
⁸³https://www.test-ed.com.au/
Kim Engel 41
IT space, meetup organisers donate time to their community, as do many conference organisers,
speakers, bloggers, regular forum participants, and more.
I’m not sure if technical career paths (as opposed to management career paths) were popular when I
started my IT career. Even if they were, I definitely wasn’t aware at the time that a technical career
path was an option.
During the first 10 years of my career, I had worked my way up to a senior management position only
to find that the constant meetings, budget adjustments, presentations, buzzwords, poor work-life
balance, and politics are really not what motivates me. Feeling the burnout, I took a long travel break
to recharge, and to rethink my career choices. I realised that I love working with new technologies,
learning, and coaching people. Since then I have chosen only test leadership roles which are at least
partially hands-on. Technology moves fast, and having a hands-on testing aspect to my role allows
me to stay engaged, keep learning and building my skills, and maintain my passion for my work.
It took me a long time to realise that it’s okay to enjoy my role and not push for promotions along a
management career path. Being ambitious by nature, I wouldn’t have heeded this advice even if I’d
been told earlier on in my career! Even after learning the hard way, I still have to regularly remind
myself not to progress towards senior management roles.
I usually work with multiple development teams concurrently across different projects, and there
are differences in my testing approach even within the same company. Here I’ve listed some context
factors which may be overlooked when planning a testing approach. Where these factors introduce a
higher risk of issues occurring in production, the temptation will be for testers to perform additional
testing - but that’s rarely the best solution.
Development processes e.g. unit testing coverage and code reviews - There are still development
teams that don’t write or maintain unit tests, and perform only rudimentary code reviews. The
reliance on testers alone to detect regression issues leads to major production bugs and quality
issues, for which the testers will then be held accountable. I once offered to forgo an open senior test
analyst headcount/budget so that we could instead hire a consultant to train our development team
on better code-quality practices. Hiring another tester would not have improved product quality
nearly as much as a shift-left approach. Unfortunately, the development team manager didn’t take
up my offer. Our test team wasn’t left with many options besides expensive GUI automation, lots
of regression testing and often working long hours. This approach isn’t sustainable and I don’t
recommend it.
Production monitoring - My approach differed for post-deployment checks for the same web
application after production monitoring was implemented. Instead of performing ten minutes of
post-release verification checks, we would complete some basic checks in one minute while watching
the monitors for variations in error rates, response times, and other success factors in real-time. The
feedback from production was faster and more useful, rendering the old process redundant.
Kim Engel 42
Legislation and regulations - At one company our systems were designed so that all regulated code
was in the back-end. Our test results were captured and presented more thoroughly for back-end
systems, including video recordings and live demonstrations for the regulators. Apart from that,
we still used a context-driven exploratory testing approach, backed by automation. The regulators
came into the office for a walkthrough of our processes and agreed that our testing methods were
thorough and our level of documentation was appropriate.
Deployment process - Applications deployed and configured manually require more testing in each
environment. The scope for human error creates a risk that can be mitigated through pairing during
deployments and performing post-deployment checks, and at times I’ve had to include both of those
in my test approach. Ideally, the risk should be mitigated by implementing configuration as code
and automating deployments to each environment.
Professional impact
• The Secrets of Consulting – A Guide to Giving & Getting Advice Successfully⁸⁴ by Gerald M.
Weinberg
• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing
Technology Organizations⁸⁵ by Nicole Forsgren, Jez Humble & Gene Kim
Personal life
• Reasons to Stay Alive⁸⁶ and Notes on a Nervous Planet⁸⁷ (both by Matt Haig)
• No Friend But The Mountains⁸⁸ by Behrouz Boochani
important failure?
Being fired for symptoms that occurred while changing antidepressant medication. Ceasing, starting
and/or switching medication causes a roller coaster of side effects and is something that I definitely
prefer to do while on leave or between jobs. I don’t think that getting fired is necessarily a failure,
but on this occasion, I regret not giving my manager the opportunity to make allowances for the
short time that I was struggling.
I requested a two week leave period which my manager declined due to project deadlines. When I
couldn’t delay the medication change any longer, I realised that I would have to work through it.
To help ease the transition I was prescribed Diazepam (a.k.a. Valium), which has a strong calming
effect. Even on a low dosage it completely knocked me over. I was in a project meeting with 10
⁸⁴https://www.amazon.com/Secrets-Consulting-Giving-Getting-Successfully/dp/0932633013
⁸⁵https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339
⁸⁶http://www.matthaig.com/books/reasons-to-stay-alive-2/
⁸⁷https://www.amazon.com/Notes-Nervous-Planet-Matt-Haig/dp/1786892677
⁸⁸https://www.panmacmillan.com.au/9781760780852/
Kim Engel 43
people each giving me their updates, and I was fighting to stay awake. I started resting my eyes for a
few seconds at a time and I must have fallen asleep in my chair. I can’t remember how the meeting
ended, but I do wonder if everyone quietly left the room and turned off the lights… After that I was
also late to a few meetings. I don’t remember much else but I must have been vague and noticeably
“foggy” or absent-minded.
I was given a termination notice shortly afterward. The stigma and resulting embarrassment of
having a mental illness held me back from explaining the situation to my manager. Looking back,
even if I’d been asked to explain I’m not convinced I would have answered honestly.
This experience set me up for future success as an empathetic leader. I’ve supported my team
members in taking mental health leave or other well-being measures when they need to. I’ve also
been more open about my own mental health⁸⁹. I can’t say that all of my managers have responded
well, but by being honest I’m able to hold my head up high. Every company now proclaims values
of diversity and inclusion but as with many things, a lot depends on individuals in leadership and
management positions. For managers: Lead with compassion, educate yourself and be supportive,
and allow your team members to do their best work.
A few years ago I was using Slack at work for internal communications. When I opened the app at
work I’d still be signed in to other Slack workspaces as well, e.g. one for testers, developers, women
in technology, local IT folks, advocacy groups, and more. It was too much noise and distraction at
work.
I’ve recognised that I should not spread myself too thin across social networks and community
groups. Now I have a small core group of accounts where I’m active, and the rest I’ve left behind. I
have cut down on time spent on Slack overall, and I don’t try to catch up on past threads.
To avoid distractions at work, I regularly book one-hour appointments in my calendar to work on
a specific task. During that time I’m focused - I will not answer calls, respond to emails or group
chats.
do?
Focus on a quick-win, short-term task that will add value, although it may not be the most important
thing on my plate. Sometimes that may be clearing out a desk drawer, responding to an email, or
closing some stale defects. These small, achievable tasks allow me some time to clear my thoughts,
while still being productive. Afterward, I feel more organised, more focused, and less overwhelmed.
When I’m feeling particularly overwhelmed I try to go for a 15-minute walk and call a family member
or friend, which does wonders for perspective and thinking more clearly.
Kim’s bio
⁸⁹https://kengel100.wordpress.com/2014/12/24/anxiety-or-depression/
Kim Engel 44
Kim Engel is a testing specialist with a 20+ year testing career spanning a broad range of industries
and technologies. Through inspiring and coaching others, and leading by example, Kim helps
companies improve their approach to delivering quality products. She is known in the software
community for driving continuous improvement, her dedication to quality and a pragmatic approach
to risk management.
Kim is married with two kind-hearted children and is a human rights advocate for refugees.
James Espie
“I wish I’d known earlier how important quitting a job could be for a career.”
“Volunteering helps me maintain perspective on what really matters.”
“I want to take every opportunity to be kind to people. Be kind, wherever possible, all the time.”
It was a lucky break that led to meeting James when he submitted

a proposal to speak at the CASTx18⁹⁰ conference in Melbourne,
for which I was Program Chair on behalf of the Association for
Software Testing. He not only gave an engaging and interesting
talk, but also displayed his humour - and his cartooning skills
are well worth a look! James also gave me my first experience
of being interviewed for a podcast when I appeared on the Super
Testing Bros podcast⁹¹ to talk about the volunteer project I’d co-
founded (with Paul Seaman) to teach software testing to young
adults with autism. James is committed to community building in
the software testing industry in his home country of New Zealand
and his enthusiasm and humanity shine through in his responses below.
Well, I almost got to go on a free cruise around the Pacific! But I ended up being a software tester
instead.
Once I graduated, my first full-time job was as a support engineer, at a large product company. They
had a reputation for being a great place to work, wild parties and extravagant celebrations. Once,
the CEO had even taken the entire company on a cruise around the Pacific!
Not long after I started, the CEO made an announcement - he was taking the whole company on
another Pacific cruise. There was a catch, though - a certain project had to be delivered on time. If
we made the deadline, the cruise was ours!
We busted our butts to get this project finished in time - eighty hour weeks, that sort of thing. And
we did it. The company was on a high, and people were buzzing. We’re going on a cruise! We were
just waiting for the announcement from management.
We waited, and waited, and waited.
Finally, a company meeting was scheduled. The CEO got up to address the issue.
⁹⁰https://therockertester.wordpress.com/2018/03/08/castx18-context-driven-testing-fun-in-melbourne/
⁹¹https://therockertester.wordpress.com/2018/07/02/another-first-being-interviewed-for-a-podcast/
James Espie 46
Turns out, the company didn’t have enough money to go on the cruise. In fact, the company was
doing so poorly that they couldn’t keep this many staff on.
We were promised a cruise, but given redundancies. Entire teams got cut, and of course, people
left, after having such a big promise broken. (I’ve since learned psychologists refer to this as a
“psychological contract breach”).
With all these people leaving, there was a lot of work that now had to be done by “someone else”.
Turns out the support team - my team - was that someone. We started performing such functions
as release management, environment management, documentation… and of course, testing.
Suddenly, I had this really weird, varied selection of jobs to do. It meant that I got to try out all these
different jobs and see which one I liked best. Turns out, that was testing.
So, I didn’t get to go on a cruise, but I did discover a career path that suited me, and that’s almost as
good, right?
A testing career involves lots of other people. To make this work, I intentionally try to give a lot of
my time and energy to people around me. Doing this has definitely been a worthwhile investment.
It’s one of the best things I’ve chosen to do in my career. I’m an introvert, so it’s been a challenge,
but absolutely worth it.
Here are some of my ‘personal guidelines’ that help me do this.
Guideline 1: Learn who everyone is
I try to learn the first and last name of everyone in my office, and what it is they do. If someone
new joins, I make sure I introduce myself, and welcome them, as soon as possible.
Guideline 2: Always engage
I always say hi to my co-workers if I get the chance. Or start a conversation if we’re in the elevator
together, or at the coffee machine. This applies outside the office too, if I bump into someone while
out getting lunch, or if we’re on the train together.
Guideline 3: Always be available
Wherever possible, I try to say ‘yes’ when someone needs help. Even if it’s an interruption. This can
be work related stuff, or something as ordinary as helping empty the dishwasher.
Following these guidelines has paid off in a bunch of ways.
It means I always know who to talk to when I have a problem, and they’re more receptive to helping
me. It means I can learn about other things that are going on around the business. In wider terms,
building lots of good relationships gives you a good network, and you have lots of contacts that you
can rely on when you’re looking for your next role.
But most importantly, I have gained some amazing lifelong friendships.
James Espie 47
I’m going to share a piece of advice that one of my mentors gave me. That advice was “Stay close to
the poor”. I guess that’s more ‘life’ advice than ‘career’ advice, but bear with me.
At the moment, I heed that advice by volunteering once a week for our local food bank. We run
a ‘soup kitchen’ style dinner every Wednesday. It’s fun, sometimes heartbreaking, occasionally
challenging.
I’ve met the most interesting people, and heard the most interesting stories.
Volunteering helps me maintain perspective on what really matters. Releases going badly, failed
tests, office politics - these problems pale in comparison to the problems of some of the people I’ve
met.
It makes you think twice when building software too. I’ve often caught myself thinking about the
apps I’m building, in relation to the people at our food bank dinner. Will it work on their bottom-of-
the-range phone? Will it suck up all their data? Asking questions like this helps build a better user
experience.
“Stay close to the poor” might not be the right advice for everyone reading this. But, I think there’s
a lot of value in having people that are marginalised, or less privileged in your life. I’d encourage
anyone joining the industry to try and make sure this is the case.
disagree with?
The term QA is usually understood to mean Quality Assurance.
I think it’s fair to say that the testing community, by and large, rejects this. We’re right to reject it -
“Quality Assurance” is not what we do, nobody can ‘assure’ quality.
This often leads to a conversation about releasing software. Testers often get asked if software is
‘ready to release’. Because we can’t assure quality, we’re discouraged from answering this question.
Instead, we’re advised to only provide information. Let a product manager decide whether it’s ‘ready
to release’ or not.
This, I disagree with. There are times when testers can make the decision on whether to release
software or not. Testers are big enough and smart enough to make big decisions. I think telling them
they can’t or shouldn’t make this decision, undersells the value of a good tester.
Context has a big part to play in who makes this ‘should we release it’ decision. There have been
many occasions in my career where I’ve been happy to make this decision.
There have also been times where I’ve been uncomfortable making that call. In these cases, I’ve
deferred it to someone else. Sometimes, this has been to discuss it as a team, and make a joint
decision whether to release or not. Other times, it’s been deferred to a product manager.
To be clear, I don’t agree with the blanket rule that testers can never make that decision. Are we
incapable? That seems wrong. We’re better than that.
how?
James Espie 48
Tidying up!
I’m a messy person. As a tester, I think mess is great. Mess is a result of my creativity - and also
feeds into my creativity. Creativity makes me a better tester.
But, mess can also be draining and overwhelming. If things are too messy - when you can’t find
anything, when your pile of ‘to do’ Post-It notes is too large - it becomes a problem.
So, I’ve found some simple tidying routines have helped me a lot. Of particular importance to me
has been what I call my ‘digital tidy up routine’.
Every Friday afternoon at 2:30, I do the following:
• Post an update in a Slack channel (so my managers can see what I’ve been doing, but also a
great way for me to ‘take stock’ of things too) detailing:
– What I worked on this week
– What I’m going to work on next week, and
– Anything I learned this week.
• Go through everything in my Downloads folder, or on my desktop, and take some action. Either
file it somewhere, finish the piece of work it related to, or delete it. Mostly delete it.
• Go through my email and do the same thing. Everything gets filed away or deleted, and my
inbox should be at zero before I knock off.
• Close all the browser tabs I have open. Often they’ll be articles or videos that I started but
didn’t finish, this is the time to read them and close them.
• Finally - shut the computer down! Like, actually turn it off!
None of this is rocket science. But when I wasn’t doing this, I ended up with an unwieldy Downloads
folder that had hundreds of items in it. My email was exhausting to look at, and I had browser tabs
that would remain open for weeks.
By maintaining this routine, I mentally ‘sign off’ at the end of the week, and come in on Monday to
a fresh start. It’s nice. Maintaining this simple routine has vastly improved my enthusiasm for my
work.
I wish I’d known earlier how important quitting a job could be for a career.
A company I belonged to held a meeting once, where they were handing out service awards. People
got awards for being at the company for ten, fifteen, or twenty years.
Maybe I was having a bad day, but I remember thinking how much I did not want one of those
awards. I was well on my way though, as I’d recently ticked over seven years. The thought of
coming to the same place every day for ten years filled me with dread. I swore that I wasn’t going
to get to ten. Not long after that, I moved on to a new company.
James Espie 49
It’s a realisation I wish I’d made much earlier. Not because it was a bad place to work (on reflection,
it was actually quite good), but I’ve since learned how good it is to work at different places. You get
to meet different people, try out new things, and see and experience so much more.
Quitting a job is scary. I felt like I’d be letting my manager and my team down. But I’ve since realised
that quitting is an important part of career development and growth.
There’s a book called The Alliance⁹² by Reid Hoffman, Chris Yeh and Ben Casnocha. It describes an
‘alliance’ between employee and employer. That alliance includes a “tour of duty” approach to a job.
An employee joins a company with a defined goal or duration in mind - and sets out to achieve that.
Once that’s done, they start another tour - either with the same company, or, somewhere else.
I like this approach, and I try and use this perspective.
There’s value in working at a variety of companies over the course of a career. I built a much broader
skill set. I learned the good (and bad) ways different companies work. If I’d known this earlier in
my career, I would have switched jobs sooner and taken up new opportunities instead of playing it
safe.
Experience is the biggest factor that directs my testing. But that can be broken down into a few
different areas. Here’s what I mean:
Experience as a user of this product or feature
If I’ve used a product or feature extensively, this will be a big factor in how I test it.
I’m already someone that uses this product. So, I direct my testing towards the things that are most
important to my personal user experience. What do I want to do with this application? If I haven’t
used it much, then my testing would include a lot more research and investigation on how people
use it.
Experience testing this product or feature
If I’ve tested this before, I’ve already got some idea of where the risk areas are. I should know what
parts of the product are more fragile, or have been problematic in the past. I would target my testing
towards these areas.
If I haven’t tested it before, then my testing will be less targeted. It will be spread across different
areas of the product, as I explore and discover what the risk areas are. There will likely be more
communication with the development team on how it works.
Experience with this developer or development team
If I work with this developer frequently, I’ll have an idea of what their strengths and weaknesses
are. I can direct my testing according to this information.
If I haven’t worked with them before, well, this is a great chance to get to know them. Ideally, we’re
working in a pair anyway, and can talk through what they’ve done together.
⁹²https://www.amazon.com/Alliance-Managing-Talent-Networked-Age/dp/1625275773
James Espie 50
Experience with this user or set of users

For example, If I know a feature is only going to be used by internal users, I’ll be a lot more forgiving
of some bugs. Or, if I know a feature is being built for a particular strategic customer. In this case, I
would direct my testing to try and simulate their specific use cases.
On both counts, How to Win Friends & Influence People⁹³ by Dale Carnegie.
The “win friends” part more than the “influence people” part. I just find it to be really good advice
on how to build relationships.
important failure?
Content warning: this response talks about suicide. It’s a topic that will upset some people, so please,
if it’s likely to trigger you, skip to the next question.
This has been the hardest question to answer for me. My career has been peppered by lots of little
failures. Most of these failures have been opportunities to learn and grow.
My most important failures - the ones I regret most - have been times when I’ve failed to treat people
well. I’ve had a lot of time to think about how to answer this question, and I can’t get this story out
of my head. I’m not sure it fits the context of this book, but I think it needs telling anyway.
In high school, I had a best friend. For a couple of years, we were inseparable. We were together at
school, after school, even on weekends.
High school is a horrible place. At least it was for me. Social circles were well defined and fiercely
guarded. If you were part of one social group, you couldn’t be part of another.
As time went on, I started making new friends. But, to maintain my new friendships, I had to distance
myself from my old ones. Including my best friend. He wasn’t cool enough for my new friends, I
guess.
It was a terrible decision, on my part. I pushed him away, and by the time school was over, we were
more like acquaintances than friends.
The sad part is, I’m not friends with any of those people now. But I sacrificed a good friendship so
that they would include me.
As we grew older, he reached out to me a few times. We crossed paths, but I never made the effort
to rekindle the friendship. I had plenty of opportunities to be kind to him, and I didn’t take them.
Then, at age 20, he took his own life. I don’t know exactly why. He’d had problems at university,
he’d broken up with his girlfriend. My guess is, he was probably pretty lonely.
My big regret, my failure, is this: I could have been kind to him, and I wasn’t. I had the opportunity,
and I didn’t take it. Maybe if I’d shown him some kindness, he would still be alive. Maybe not, too.
But because I didn’t take the chance when I had it, I’ll never know.
⁹³https://www.amazon.com/How-win-Friends-Influence-People/dp/8189297813
James Espie 51
Workplaces aren’t that different from high schools. There are the popular people and the unpopular
ones. There are people that over-achieve, there are people that are doing the bare minimum. There
are people who don’t ‘fit in’.
I’ve seen lots of excuses for treating people badly at work. We have these phrases we use to justify
bad behaviour. “Office politics”, or “they’re not a good culture fit”, or “it’s not personal, it’s business”.
It’s really easy to be unkind, and sometimes, we convince ourselves that it’s OK. It’s not.
I guess it’s almost twenty years ago since my friend died, and I still think of him a lot.
It’s so important to be kind. There are times when it’s hard, or I don’t feel like it, and I fail at it, but
it’s terribly important. Because being unkind is something I will regret forever.
You never know what someone else might be going through. I want to take every opportunity to be
kind to people. Be kind, wherever possible, all the time.
Please make use of support services in your area if you need help, for example Beyond Blue⁹⁴ in
Australia or Lifeline⁹⁵ in New Zealand.
To be honest, I’m terrible at saying no.
That’s intentional - I mentioned in one of the other answers - life is more interesting if you say yes
to things.
But you can’t do everything, and sometimes you have to say no.
One thing that helps me say no is something I learned when I worked in a department store (many,
many years ago).
If we didn’t stock an item, or we’d sold out of something, we weren’t allowed to say ‘no’.
Instead of “no, we don’t sell those”, we were to say “we don’t sell those, but, there’s a store over the
road that does”. Or, instead of “no, we’re sold out”, we had to try something like “we don’t have any
in stock, but I can call you when more come in”.
I use the same technique today. If I’m swamped and someone needs help with something, “I’m too
busy to help you with that today, but I’ve got some time tomorrow”. Or, “I don’t know much about
that, but I know someone who does - you could try reaching out to them?”.
I find it easier to say no if I can offer some alternative help instead.
That way I’ve still done my best, even though I couldn’t do what the person asked of me.
do?
⁹⁴https://www.beyondblue.org.au/
⁹⁵https://www.lifeline.org.nz/
James Espie 52
I sometimes become overwhelmed when my to do list becomes too big. My head starts swimming
with all the things I need to do. It’s crippling, because it becomes so overwhelming that I can’t
concentrate on any one task, which makes the problem worse.
According to the COPE inventory⁹⁶ (a scale for assessing coping strategies), there are two main
approaches to coping with problems like this. The first is “Problem focused coping” - coping by
concentrating on resolving the problem. The other is “Emotion focused coping”, which concentrates
on dealing with the emotions caused by the problem.
I’ve learned that I’m a “problem focused” person. That is, I work best by taking steps and planning
to resolve my problem. The most valuable thing I’ve found I can do is simply write stuff down. I
write my ‘to do’ list down on paper. Writing it down means it’s out of my head - and it’s still not
going to get forgotten. I don’t need to worry about it now, because it’s captured somewhere else.
One thing I have found is that I need to be specific when writing things down. As I was writing this,
one of my team, Bradley, asked me to take care of a task for him. I agreed, but knew I wouldn’t have
time today, so wrote it on my list to pick up tomorrow.
What I wrote was “Do the Bradley thing”.
If I hadn’t caught myself, I’m quite sure that tomorrow I would be scratching my head trying to
remember what it was. I crossed it out and changed it to “Do the account information updates that
Bradley asked for”. I’m finding I do better if I avoid words like “stuff” and “thing”.
When you write tasks down, you also get the satisfying feeling of crossing them out when they’re
done. It’s the best feeling.
Like right now, as I cross out “answer those questions for Lee’s book”, because I’m now done. I’d
like to finish by saying thank you to Lee for putting this together. Thank you to my friends Toria,
Tago and Rochelle for proofreading and editing for me. Finally, thank you for reading!
James’s bio
James is a software tester, currently helping to build world class Digital Humans at UneeQ⁹⁷.
He’s a big believer in making life better for everyone - by building helpful, easy-to-use software; by
helping other testers get better at their craft; or by taking his friends to the pub.
When he’s not doing the above, you can find him drawing pictures, running around in the forest, or
playing video games with his wife and son.
You can find him as @jamesespie⁹⁸ on Twitter, or check out his ‘sporadically updated’ testing blog
at jpie.nz⁹⁹.
⁹⁶https://novopsych.com.au/assessments/brief-cope/
⁹⁷https://digitalhumans.com/
⁹⁸https://twitter.com/jamesespie
⁹⁹http://jpie.nz/
David Greenlees
“Don’t forget about, or play down, the human element in testing, and software development in general
for that matter.”
“Ever since being introduced to it, I have made use of the Heuristic Test Strategy Model on every
project I’ve worked on, no matter what my role.”
“I really find it much easier these days to align myself to my priorities and not shy away from letting
people know what they are.”
I first met David over a couple of pints in the Sherlock Holmes pub
in the Melbourne CBD back in 2012. We’d been corresponding
online for a while via the context-driven testing community
and he was looking to organize a testing peer conference. We
immediately clicked and it wasn’t too long after our first meeting
that I was heading up to Sydney to take part in the OZWST
peer conference¹⁰⁰ in the Google office. This peer conference
introduced me to some great testers who have become friends and
also now contributors to this book (with the content owner for
this conference being Rob Sabourin). Right after OZWST, David
was also involved in the “Tasting Let’s Test” mini-conference as a
taster of what was to come in 2014 when he co-organized “Let’s Test Oz”. I spent more quality time
with David over in Sweden in 2014 when we both attended the awesome Let’s Test conference¹⁰¹,
where I gave my first conference talk. It was a fun few days and the joint taxi ride out to the venue
is quite a story! Back on Aussie soil later that year, I had a great few days in the Blue Mountains
while attending the inaugural Let’s Test Oz conference¹⁰² and David did a fine job of building an
amazing conference there.
When David left Australia in search of excitement in New York for a while, the testing community
here lost a great source of drive and passion, especially around context-driven testing, so it’s great
to have him back in the country and now co-organizing the annual TestBash Australia conference
in this part of the world.
David’s one of the good guys in testing (well, I have to say that otherwise he might pull one of
his martial arts moves on me!) with a genuine desire to build community and share knowledge. It’s
my incredible good fortune to also call him a friend and I’m grateful for his insightful and lengthy
contribution to this book.
¹⁰⁰https://ozwst.wordpress.com/2013/08/08/ozwst-2013-is-done/
¹⁰¹https://therockertester.wordpress.com/2014/06/29/reflections-on-lets-test/
¹⁰²http://lets-test.com/?page_id=1863
David Greenlees 54
That’s an interesting question (pun intended). Interest in something is very subjective, so I’ll give
my best guess as to what readers may find interesting.
When you peel back the layers of the onion there would be many reasons why I’m here and why I
stayed along the way (and yes, some tears from said onion!). I’ll focus on a couple of the key reasons:
I needed a way out of a call centre environment
My first full-time job out of school was at McDonald’s. I dropped out after completing year/grade
10 (so you can ‘make it’ in tech without a degree) and fell in love with a wage. After a few years
working my way up to being a shift Manager, I decided to look for a more office-based job. I ended
up being successful in applying for a position in a call centre which was always planned to be a
stepping stone, I just didn’t know what to at the time.
After answering phone calls from mostly abusive people for about 18 months, I noticed some people
walking through the centre actively looking to recruit people to be testers. At the time I didn’t know
what that was, but I also didn’t care… at that point I would have done almost anything to get out!
I introduced myself to one of the recruiters and put my name down to be a tester. I didn’t hear
anything for a while so pretty much gave up hope on that being my path out. Whether through divine
intervention or something more scientific, the stars aligned while I was on a houseboat holiday.
These were the dark old ages when mobile reception anywhere out of the city was potluck, and so as
you can imagine getting any reception on a houseboat floating down a river was close to impossible.
It just so happens that I was sitting on the roof of the houseboat one day when my mobile phone
rang! It was the Manager of the call centre letting me know that someone had to withdraw from a
testing project, and they wanted me as a replacement starting the day I returned from my holiday.
It was an initial five-week testing project and it would appear I did OK at it, as I never returned to
the call centre and now I’m writing this more than 20 years later!
I have a young family and a mortgage
It’s fair to say that I’ve had my share of moments where I thought about doing something other than
testing. We all have bad projects, we all get ‘stuck’ in jobs where testing isn’t valued as much as we
know it should be.
During the first 5-10 years of my testing career, I worked my way up the ranks reasonably quickly,
and at the same time bought a house and started a family. So when faced with those moments of
uncertainty, and the thought of starting again in another career path, what I know and what I earn
has kept me here.
That sounds somewhat depressing, but I’ve been lucky enough to also have lots of great moments
where testing has allowed me to really add value and be valued for it. Along with multiple
opportunities to meet wonderful people and travel to various parts of the globe.
I’m here now, and my guess is that I’ll be here for a while longer.
David Greenlees 55
Investing both time and money in self-education.

For the first 10 years of my testing career I worked for one organisation, and really focussed on what
we were doing there, rather than spending any time researching what others were doing elsewhere.
We had consultants come in to sell us ‘best practice’ and while I didn’t know any better, I also didn’t
question things like I would today.
When I was tapped on the shoulder to join one of those consultancies, it sparked something. All of a
sudden, I would be working for multiple organisations all testing in different ways (or so I thought).
I decided that I needed to prepare myself as much as possible to be a grown up in the testing world!
My first client asked if I was familiar with Context-Driven Testing and when I said I wasn’t they
suggested a book to me, Lessons Learned in Software Testing (Kaner, Bach, Pettichord). I read it
cover to cover, despite the advice not to. What was this magic? How could you not follow a strict
process/procedure while testing? It was my first moment of self-education in software testing.
After that, I read more, started a blog, joined Twitter, engaged with the global testing community,
wrote articles, and then… it happened, a career defining moment - an invite to a peer conference
known as KWST (Kiwi Workshop on Software Testing). The founder and organiser had read one of
my articles and sent an invite to me. This was huge for me because I was going to have to use my
own leave and pay for it all myself. It was a big step for me at the time, but I did it. I had an absolute
blast and met a group of people that I still consider friends today.
I have since continued to write articles and blog posts, organised my own peer conferences (OZWST
– Australian Workshop on Software Testing), jointly organised industry conferences, and even wrote
a book.
All of this investment has not only made me a better tester, but ultimately a better person (if I do
say so myself).
Advice to give: Don’t blindly follow ‘best practice’.
Advice to ignore: So-called ‘best practice’.
More than a touch of ‘truth in jest’ there. For the best part of the first 10 years of my career, I was
fed a lot of best practice and industry standards by various consultancies that were engaged to help
us improve our testing practice and approaches.
While there were parts of these that helped, the overall best practice solution never quite fit our
organisation. Instead of focusing on the parts that worked, we were too focussed on the solution as
a whole, and therefore the parts that didn’t work for us brought the whole improvement process to
an end. Rinse and repeat (too many times).
After so many failed attempts many of us came to the conclusion that it was us, and we were too
broken to fix. I mean, if the best practice couldn’t solve our problems then it had to be us, right?
Wrong.
David Greenlees 56
I’ve since come to learn that there is no such thing as best practice. There is good practice in context,
and even that needs to be constantly reviewed and reflected upon. I prefer to focus on process change
as a series of experiments, which ultimately never end. Keep experimenting and evolving. There is,
however, a common challenge with this approach - the fear of failure, or people’s unwillingness to
fail.
Fail: to fall short of success or achievement in something expected, attempted, desired, or

approved:
The experiment failed because of poor planning.
From my experience, people’s understanding and definition of the word fail is too negative. It can
often prompt quitting, “I failed at that, so I’m going to quit”.
Taking from science, what happens when an experiment fails? Sure, we could simply quit thinking
that our hypothesis is false. However, the science community teaches us to push on, revisit our
variables and control them more tightly if required, take information gathered from the failure and
revise the hypothesis, then experiment again. Rinse and repeat (in a more efficient way this time!).
Remember, a failed experiment can yield just as much valuable information as a successful one, if
not more.
Some cautions that may help with this approach:
• Don’t bite off more than you can chew. The size of the experiment can make a huge difference in
the success of the process change, and people’s willingness to fail. If you develop an experiment
that will take months to run then people’s acceptance and understanding of a failure will be
much harder to come by. Not only that, with a larger process change experiment comes more
variables. You need to limit the variables as much as possible, especially those you cannot
control.
• Use the language of experimentation often. The general understanding of the word experiment
(and the process of experimenting) brings a softer meaning to the words fail and failure. People
understand that experiments fail, and that it doesn’t mean we should immediately give up.
• In line with the first caution above, think about the level of risk associated with your
experiment. If your experiment does fail, what will the impact of that failure be? Can you
recover quickly? If you assess the impact of the failure being too great then it could be a sign you
need to breakdown the experiment into smaller ones, or remove potential high risk variables.
You can’t sell a process of experimenting if your experiments keep killing the business.
The key with all of this is getting people to understand and accept that a certain level of failure is
OK, as long as you’re learning from it.
Extra advice to give: Testing is more that tech!
Don’t forget about, or play down, the human element in testing, and software development in general
for that matter. We’re developing products and/or solutions for humans, and we are a very complex
bunch!
David Greenlees 57
disagree with?
The need for detailed procedural test cases/scripts
Truth be told, I’m seeing this less and less, but it’s likely not for the reason you’re thinking.
Instead of it being because of people seeing less value in it, it’s primarily because my engagements
in recent times have been autonomous and with clients that have little software testing experience.
This has allowed me to take different - and what I consider better - approaches to developing test
artefacts.
I would say that as an industry we have moved passed a critical point with this, though. The
way software is now being developed, generally speaking of course, means that the push for
detailed procedural test cases/scripts has diminished. Despite all the negatives, the time it takes
to produce them simply isn’t available in modern software development. Gone are the days where a
specification is delivered allowing us to spend days/weeks producing step-by-step tests for someone
to follow once we have a build. We’re now faced with an approach where this is all happening
effectively at the same time.
One of the biggest negatives with detailed procedural test cases/scripts is the inattentional blindness
that I’ve seen them create, along with the confirmation bias they produce while testing. If your test
case passes, it works - but does it really? Testing should be more about disproving functionality
rather than confirming it.
Be very cautious of this approach should you be faced with it. Think about the pros and cons very
critically and ensure others are also educated.
The need for significant metrics reporting
Show me numbers or a graph, and I’ll give you a list of variables that could significantly impact the
meaning of them.
Metrics do have their place, and that place is generally at a meta level allowing you to identify
patterns and trends that may lead to the discovery of something important. With that said, be
mindful that metrics without thoughtful commentary or qualitative data are very dangerous as
they can be interpreted in many ways.
The need to automate everything
See my extra piece of advice in my answer to the previous question.
Good testing is a human activity. Yes, you can automate parts of that to assist you and make your
testing efficient, but in the end automated scripts cannot use/interpret human emotions. Until they
do, you cannot - and should not attempt to - “automate everything”.
how?
Being brutally honest!
David Greenlees 58
To clarify, I’ve always been honest, that’s not new, and the term ‘brutally’ is also not entirely accurate,
however there is a point to its use in this context.
Over the years I’ve read various articles linking testing to journalism in that a large part of your job
is the delivery of so-called bad news. I like this analogy as it resonates a lot with me being more on
the management side of testing for the last ten years. Even though the identification and reporting
of important bugs is what we’re paid to do, I still encounter many stakeholders that don’t want to
know or appear to get upset when we do this. To a certain degree I understand, but with a view of
the bigger picture, finding these bugs before users do is an absolute positive!
While in management this further extends to not only questioning the product, but also approach-
es/methodologies, processes, ways of working, etc. With each new engagement as a consultant, I’ve
progressed from someone who ‘played the game’ to someone who now just says it as I see it, in the
most useful way of course. It’s how I now play my game, not the political game of others. Integrity
is black and white, you either have it or you don’t, it’s in the way you display it where all the grey
lies.
In doing this, I’ve noticed that I may be unpopular with certain stakeholders for a short period
of time, but once my questioning leads to improvements it’s soon forgotten - until I do it again.
Personally though, I’d rather be unpopular for a while and have greater success, than the reverse.
Doing this more - and seeing the positive results from it (in the long run) - has also improved my
confidence in raising issues that once I likely would have shied away from. It’s difficult being ‘that
person’ who raises what’s likely on the tip of everyone’s tongue, but the more you do it and learn
from it, the better you get at it.
When I started testing there were small pockets of test automation, but the vast majority was what is
referred to these days as manual testing – I don’t like the term manual so much, but it does provide
a clear differentiation from automation so I’m happy to use it in this context.
Something I wish I had known back then is how big test automation would eventually become. A
couple of reasons for this:
I would have studied it more and likely pushed myself to learn a coding language
Coding for me is like reading, I’ll do it when pushed hard enough but have never really enjoyed it.
I’m not saying that doing it earlier in my career would change that, but I feel that being younger
would have helped. Armed with the knowledge that it would become such a huge part of our industry
would have also given me the extra drive I needed.
I’m not saying that you must know how to code to be a tester, but I am saying that it will open many
more doors for you if you do.
Thinking about a tester starting out these days, I would find it hard to imagine an environment where
you wouldn’t be required to, or at least exposed to test automation and coding to some degree. So, if
you’re reading this in the hope that you’ll get some insight into what will help you in the future, go
study Artificial Intelligence and Machine Learning and how they relate to testing! You’re welcome.
David Greenlees 59
I would have kicked off earlier personal efforts to combat the “automate everything” mentality
There is still a lot of work to be done in this space. We need more voices emphasising the importance
of human interaction in software testing, so perhaps it’s not too late for me. It is, however, something
I wish I had concentrated on much earlier in my career.
One important area of focus is ethics in software development, especially with machines partially
controlling themselves. It’s all well and good to test that the machine functions as designed, but how
can we ensure the decisions they make while functioning are the right ones? You won’t only need
one human for that, you’ll need many with varying degrees of expertise and social awareness.
While these are not necessarily factors by themselves, I’m going to cheat here a bit as the bulk of
my answer will be referring to other’s tools which contain many factors.
Why reinvent the wheel, right?
Heuristic Test Strategy Model (HTSM) – James Bach
Ever since being introduced to it, I have made use of the HTSM on every project I’ve worked on,
no matter what my role. It’s a constant in my toolkit and will remain that way. I’ve found it to be
the ultimate idea generation tool when strategising and testing. Test techniques, project and product
elements, and quality characteristics are included, each with enough guidance to prompt questions
and develop ideas for testing in your given context.
Software Testing Mnemonics – Various
A mnemonic is a tool which aids in memory. Essentially a list of words that are shortened in a
particular way to help us recognise a greater amount of information faster. I’ll use my own ‘CAN I
USE THIS?” mnemonic as an example.
CAN I USE THIS? is a mnemonic I developed to help me remember different elements to consider
when testing the usability of a product:
Comparable Products
Accessibility
Navigation
Intuitive
Users
Standards
Emotional Response
Trunk Test
Heuristic Evaluation
Instructions & Help Text
Satisfaction
? (never forget to ask questions)
David Greenlees 60
There are many examples of other mnemonics which can be found with a little research. Many of
them have added so much to my testing over the years and I’m sure they will continue to do so.
Users
This would be the number one factor that has influenced my testing. In the beginning of my career
I would focus on the product specification as my guiding light which would sometimes prove
successful, but many times not.
With any new product I test now, my first thoughts are with the future users and the problem the
product is trying to solve. Seeking information in these areas can influence the way you test in so
many ways, the majority of which end up being the most valuable.
This was a confronting question for me to answer. I’ve never been a strong reader. I read very
slowly and get bored very quickly while reading, which is not a great combination. The question
has prompted me to revisit my book list and reflect on what I’ve gained from those books I’ve been
able to get through.
I’ve broken them into two lists; Testing and Personal. The bulk reside in Testing as my work in
testing has been the driver for me to read more.
Along with those listed below I still have many books to read. They sit on my dusty bookshelf in
anticipation.
Testing
• Freakonomics¹⁰³ by Steven Levitt & Stephen Dubner

• The Invisible Gorilla¹⁰⁴ by Christopher Chabris & Daniel Simons
• The Phoenix Project¹⁰⁵ by Gene Kim, Kevin Behr & George Spafford
• Perfect Software: And Other Illusions about Testing¹⁰⁶ by Gerald M. Weinberg
• Lessons Learned in Software Testing¹⁰⁷ by Cem Kaner, James Bach & Bret Pettichord
• Tacit and Explicit Knowledge¹⁰⁸ by Harry Collins
• Don’t Make Me Think: A Common Sense Approach to Web Usability¹⁰⁹ by Steve Krug
Personal
• Weinberg On Writing: The Fieldstone Method¹¹⁰ by Gerald M. Weinberg

¹⁰³https://www.amazon.com/Freakonomics-Rev-Ed-Economist-Everything-ebook/dp/B000MAH66Y
¹⁰⁴https://www.amazon.com/Invisible-Gorilla-How-Intuitions-Deceive/dp/0307459667
¹⁰⁵https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/0988262592
¹⁰⁶https://geraldmweinberg.com/Site/Perfect_Software.html
¹⁰⁷https://www.wiley.com/en-gb/Lessons+Learned+in+Software+Testing%3A+A+Context+Driven+Approach-p-9780471081128
¹⁰⁸https://www.amazon.com/Tacit-Explicit-Knowledge-Harry-Collins/dp/022600421X
¹⁰⁹https://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758
¹¹⁰https://geraldmweinberg.com/Site/On_Writing.html
David Greenlees 61
• Secrets of a Buccaneer Scholar¹¹¹ by James Bach
There are some other fiction books that I have really enjoyed, but I dare say the only real impact
they’ve had on me is my utter amazement in actually finishing them!
Along with reading books, I’ve also been on the review team of various industry books along with
a few fiction books:
• Tap Into Mobile Application Testing¹¹² by Jonathan Kohl

• A Practical Guide to Testing in DevOps¹¹³ by Katrina Clokie
• Changing Times: Quality for Humans in a Digital Age¹¹⁴ by Rich Rogers
• Legends of Marithia: War of Prophecies (book 1¹¹⁵ and book 2¹¹⁶) by Peter Koevari
These have always been a great process to be involved in, and I would encourage anyone who may
be interested to give it a go.
important failure?
Reflecting on a 20+ year career and trying to determine the most important failure of many is a very
difficult task. The importance of each is truly subjective, and ultimately dependent on the time they
occurred and what they have influenced in the years to come.
With that in mind, I would be comfortable in stating that one of the more significant failures of mine
would be not dedicating myself to learn a coding language while my brain was more open to it and
I had more patience for it (i.e. when I was younger!).
How could such a failure have set me up for future success is an interesting element to the question.
It’s prompted me to reflect a very positive way.
Being a part of this industry as it predominately moved towards an approach of automation, while
feeling like I was being left behind, has forced to me to think about what other areas I could/should
educate myself in. As with most industries, if you don’t evolve with them, you’ll end up out of them.
While doing this I discovered my passion for all things user experience and usability. This has lead
to years of valuable self-education in the space, multiple well received articles, a conference talk
that took me across the globe, and so on. It’s been a great journey so far, with much more to come.
Failure is hard to deal with, no matter what the scale. At the time you’re filled with mostly negative
thoughts and emotions - and this is the time that everyone tells you to reflect and learn from the
failure. When you’re in that frame of mind, learning is extremely difficult. When possible, I prefer
to acknowledge the failure and move on from it until I feel better. Once I do, that’s the point where
I’ll try to reflect and learn from it.
¹¹¹https://www.amazon.com/Secrets-Buccaneer-Scholar-Self-Education-Pursuit-Passion/dp/1439109095
¹¹²https://leanpub.com/testmobileapps
¹¹³https://leanpub.com/testingindevops
¹¹⁴https://www.amazon.com/Changing-Times-Quality-Humans-Digital/dp/1999702735
¹¹⁵https://www.amazon.com.au/Prophecies-Awakening-Peter-Koevari/dp/1477508724/
¹¹⁶https://www.amazon.com.au/Darkness-Rising-Peter-Koevari/dp/1467948551
David Greenlees 62
Everything.
I’m not joking. Being an enthusiastic late teen when I got my first professional job, I found it difficult
to say no. My main aim was to please as many people as possible and move up the ranks as quickly
as possible. To a certain extent this can work, depending on who you’re constantly saying yes to,
but it’s not something you can maintain long term. The yes’s begin to mount up and the promises of
delivery they imply begin to fail. This can quickly snowball into working on too many things while
successfully delivering none of them.
Ten years later when I first started my engagement with the wider software testing community (blog,
social media, meetups, etc.), my initial enthusiasm produced similar results. I wanted to engage with
everyone and do everything all at once. Again, this worked for a short while, but soon became too
much. I again recognised that I had to limit the yes’s and starting say no more often.
Along with the realisation that I just couldn’t manage the workload, there where are couple of other
things that prompted this at various stages of my career/life.
Family
Getting married and, to a more significant extent, having a daughter changed me a great deal. If
there is one thing that is for certain, having a child will change your perspective on the world, and
the priorities you place on living your life.
Work and the software testing community took a back seat, and I wouldn’t have had it any other
way. Saying no without hesitation became easy. I’m not suggesting I used my family as an excuse
to say no, I’m saying that the no now came naturally.
Turning into a ‘grumpy old man’
This is somewhat of a joke; however, I think there is an element of truth to it. It’s no doubt partially
a result of the above and my perspective on the world changing as I get older, but I really find it
much easier these days to align myself to my priorities and not shy away from letting people know
what they are.
do?
Another interesting question, in that I will often seek to defocus when I’m feeling overwhelmed,
rather than the overwhelming feeling coming from being unfocused.
What do I do? Walk away, just walk away. It may seem trivial, but there were multiple times that I
began to feel overwhelmed when writing my answers to these questions. Instead of sitting staring
at the screen getting frustrated with myself, I just switched it all off and forgot about it for a while.
Lo and behold, when I returned to it later, the words just flowed.
Unfortunately, we can’t just switch off and forget, especially while working. This is where I’ll seek
that opportunity to defocus. I may remain on task but try to look at it from different angles or ask
for different opinions. It’s amazing what a fresh set of eyes and another brain can uncover.
David Greenlees 63
Defocusing is actually a technique I use often while testing. I first learned of its use in this context
from James Bach while taking the Rapid Software Testing course. To quote James from a published
interview:
“Therefore, a big part of teaching testers is to teach them how to defocus. Defocusing
is the solution to the pesticide paradox. Defocusing means to continuously change your
tests, your techniques, and even your test strategy. You can do this with tools as well.”
If all else fails, I will just remove myself from the situation entirely and try to do something I know
will make me feel better. For me this is generally some form of physical exercise, be it martial arts,
gym, golf, etc. If it’s something that I know will clear my mind, I’ll push for that.
I would also add that I’m not afraid to let people know that’s what I’m doing. I think it’s important to
be transparent about your feelings and the reason why you’re removing yourself. In my experience
most people will understand, and actually see the value in you doing it.
David’s bio
David has been testing software or managing it for over 20 years. A community builder Down Under
(Australia), he is passionate about product quality and the craft of software testing, and focuses
heavily on usability and user experience. He has published several articles, and blogs semi-regularly.
You can keep up with his adventures at martialtester.wordpress.com/¹¹⁷. In 2012 David founded the
Australian Workshop on Software Testing¹¹⁸ and in 2014 helped bring Let’s Test to Australia by co-
organising Let’s Test Oz. He’s an author (leanpub.com/u/davidgreenlees¹¹⁹) and a co-organiser of
TestBash Australia. David can be followed on Twitter @DMGreenlees¹²⁰.
¹¹⁷http://martialtester.wordpress.com/
¹¹⁸http://ozwst.wordpress.com/
¹¹⁹https://leanpub.com/u/davidgreenlees
¹²⁰https://twitter.com/DMGreenlees
Scott Miles
“Having a mentor from outside of your organisation can help to diversify your understanding and
widen your experience.”
“Even when not feeling overwhelmed or unfocussed I still often ask for help from a peer or another
member of my team.”
“The emergence of the Quality Coach role in software development teams has had the biggest impact
on my view of the testing industry in recent years.”
It was through co-organizing a testing meetup group in Mel-

bourne a few years ago that I first met Scott. His affable nature and
willingness to share his knowledge were immediately apparent
and he was an obvious choice when I was looking for workshop
presenters for both the CASTx18¹²¹ and TiCCA19¹²² conferences.
He is a natural educator, displaying patience, empathy and a
genuine desire to pass on his knowledge. These attributes were
also evident when Scott helped us out during the EPIC TestAbility
Academy (a software testing training course for young adults with
autism that I ran with Paul Seaman), teaching the fundamentals of
programming in some very well-pitched and useful sessions for our students. I’ve enjoyed working
with Scott in these several different capacities and I hope you now enjoy his responses.
My career path into software quality was completely unplanned and was largely a “learn as you
go” experience. I attended university and completed a Bachelor of Computer Science with the
determination to become a software developer and was unaware of the role of Testers and Quality
Analysts until after I entered the industry. Software quality roles were never taught as possible
career paths at any time during my education and choosing to adopt this career was something of
a pivot after I became aware of how rewarding and complex the field could be.
The most worthwhile investment I have made has been attending local software quality meetups.
I found that I was able to learn much more from these events compared to other conferences,
workshops and certifications that I have completed. The informal format of meetups and the
opportunity for networking have often provided unexpected insights when speaking with other
attendees as well as useful connections.
¹²¹https://therockertester.wordpress.com/2018/03/08/castx18-context-driven-testing-fun-in-melbourne/
¹²²https://therockertester.wordpress.com/2019/03/08/testing-in-context-conference-australia-2019/
Scott Miles 65
I would recommend that new people entering the industry find a mentor to guide them in their
development. There is a broad range of approaches to software testing and having a mentor from
outside of your organisation can help to diversify your understanding and widen your experience.
Attending meetups is also a great place to meet potential mentors.
disagree with?
I still see many Testers and Quality Analysts that work within a team by adding “quality” at the end
of the development process. I believe that most organisations would benefit more by focussing on
quality earlier on with defect prevention strategies. I have observed that the most significant blocker
to companies making this shift is usually the resistance by team members who are hired in quality
capacity.
how?
The emergence of the Quality Coach role in software development teams has had the biggest impact
on my view of the testing industry in recent years. Quality professionals in this role are responsible
for developing the quality skills of all team members and promoting an environment where quality
ownership is shared by the whole team. As these roles gain prominence I have observed a shift in
both the mindset of quality professionals as well as in the expectations of organisations in alignment
with this evolution.
important failure?
Early in my career I was responsible for testing a new release of a system in which my testing
failed to detect a significant issue. This forced me to realise that no matter how much planning and
testing I did there would always be the chance of defects making it into production to impact users.
After coming to this realisation I began to broaden my definition of what a quality professional’s
responsibilities were. I started to understand that building systems that were able to detect and react
quickly to production defects was equally as important as testing.
I have learnt to say no when asked to perform testing on a product for a team and instead ask why.
Was it because the team didn’t have confidence in their testing skills, or because they didn’t have
enough knowledge of the product, or because they don’t have time to do it themselves? This question
often reveals other more significant flaws in the team which should be remedied.
do?
I ask for help. Even when not feeling overwhelmed or unfocussed I still often ask for help from
a peer or another member of my team. Pair programming is very popular in Agile teams because
Scott Miles 66
the diversity of thought and experience that two people bring to the work improves the output
significantly. The same is also true for quality activities, so whenever possible I encourage pairing
within my team.
Scott’s bio
Scott Miles is an international speaker, published writer, workshop instructor and testing enthusiast.
He is a prominent member in the Melbourne testing community where he organises the local meetup
group Test Engineering Alliance of Melbourne¹²³, the collaboration workshop Quality Exchange as
well as the testing conferences Quality Software Australia, Australian Testing Days¹²⁴ and Australian
Test & Tech Automation Conference¹²⁵. Scott is employed as a Principal Quality Analyst at MYOB,
where he promotes the latest technologies and approaches to improve the quality of their products.
Scott enjoys challenging what is accepted as standard practice and is always striving to get more
out of his team and tools. To this end, Scott has published several articles and papers regarding the
limitation of automation techniques and is constantly promoting the use of smarter and better tools.
¹²³https://www.meetup.com/TestEngineeringAlliance/
¹²⁴https://www.australiantestingdays.com/
¹²⁵https://attac.tech/
Brian Osman
“Testing is more about people and less about the product.”
“Find a community that resonates with you and look for people that are further down the pathway
and attempt to learn from them.”
“I realised that being nice and being kind are not the same thing. Being kind means choosing how
and where I can serve effectively.”
It was amongst the throngs of the ISTQB certification mob that

Brian stood out, at the ANZTB’s annual conference back in 2010
in Melbourne. His talk “When is enough, enough? Managing
Exploratory Testing with Session-based Test Management” was
by far the best talk of the two-day event and I made a deliberate
effort to meet Brian for the first time at the drinks reception in the
splendid confines of the Langham hotel. It was immediately clear
that we were on the same wavelength about what good testing
looked like and his advocacy for context-driven testing over the
next few years was great to see. We met again at the Kiwi Workshop on Software Testing in
Wellington in 2013, when we were both in our element sharing our time and context-driven testing
bent with an encouragable group. Brian is a passionate voice in our community, a natural presenter
and educator and, above all, a top bloke. His responses below are, of course, choice - thanks for your
contribution, bro!
The most interesting part of my career is not going down the big corporate route. After spending
time getting my feet wet in testing, I took the contractor path and as you would know it, it meant that
I had to figure this testing thing out myself. After a few years of writing test script after test script,
I thought there must be a better approach to testing. As I brought this up with more experienced
testers and test managers, none could satisfactorily answer my questions. The general response was
“this is how we do it because this is how we’ve always done it”. About 2003, a friend sent me a link to
the Sticky Minds website¹²⁶ and asked me to search for a tester named James Bach - “it will change
the way you will look at testing”. The first article I read was ‘How Do You Spell Testing: A Mnemonic
to Jumpstart Testing’. It literally blew my mind and really resonated with me. This began a more
serious journey into improving my craft and connecting with real leaders in the testing community.
I blame this article for where I am today.
¹²⁶https://www.stickyminds.com/
Brian Osman 68
Spending time with a super group of testers down under to create KWST – Kiwi Workshop on
Software Testing (which also included our cousins from Australia). I recall chatting with James
Bach and asked him ‘How do we build a community?’ We talked about peer conferences and then
he tweeted that I would be starting the first peer conference down under for software testers (I
don’t think I had said yes yet)! From there, KWST was born. It brought together a strong context-
driven community in Wellington, New Zealand, as well as pulling in thinking testers from all over
New Zealand and Australia. It really was at the forefront of building and improving the craft and
challenging the old school, outdated thinking prevalent at that time.
So, the most worthwhile investment? Asking a simple question of a trusted mentor.
Be a sponge, learn things that you need for your job but more importantly learn about what interests
you the most (networking, coding, testing and so on). Find a community that resonates with you
and look for people that are further down the pathway and attempt to learn from them (some people
will give freely, others not so much. It is sometimes a matter of perseverance). From here you will
be able to ascertain which approaches in your discipline connect with you. Test some of these ideas
online to see if you can finetune them (but be aware your post(s) may open you up to scrutiny).
disagree with?
• Automation is testing and will solve our problems No, good automation is important baseline
checking that will give us relatively quick feedback if it is done right, otherwise it is just an
overhead.
• Agile means automation No, you can be agile without automation (but automation could really
help).
• Testing means writing test scripts Testing does not mean that at all and yet testing consultancies
and the like insist on them so that they can demonstrate to audit what they have tested. All
it really shows is intent, the notes that you make show what occurred. Aaron Hodder wrote a
post a while ago on Beyond Scripts - Transcripts¹²⁷ which debunked that myth.
• A test plan needs to follow a format very similar to that laid out in ISO 29119 A test plan
attempts to answer the why, how, where, when and what so why can’t we restructure the test
plan along those questions and avoid the fluff? (Even Google talks about something similar –
read How Google Tests Software¹²⁸ by James Whittaker, Jason Arbon & Jeff Carollo).
how?
‘No, but it could be useful’ is a phrase I quite often use in a work context. What this suggests to
me is to explore the ‘what else is there?’ option. For example, if someone asks me ‘Do you need
¹²⁷https://hellotestworld.com/2011/11/02/beyond-scripts-transcripts/
¹²⁸https://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027
Brian Osman 69
automation to be agile?’ then my response will be ‘No, but it could be useful’. This reminds me to
not to be dogmatic about a solution/response/process/method/technique and hence encourages me
to be a little more open-minded about exploring a solution.
Testing is more about people and less about the product. The product is a vehicle or medium which
is interesting but what is even more interesting is how people interact with that product. Testing is
more a social science and the relationships between the product, customers, users and so forth also
matter more than the requirements. This means I would have explored those relationships more
than just looking at the requirements document for the source of ‘truth’. And that ties in with the
fallacy of making sure the requirements are fully covered and calling that testing. This is extremely
shallow and gives the illusion of good testing.
From a testing perspective, a general iterative process I follow to understand context is Prepare >
Perform > Inform. Prepare is all the relationship building, information gathering and sensemaking
you need to make things a little clearer. Perform is the activity of testing using the appropriate tools,
heuristics, and approaches to gather valuable information about the product and Inform is the art
of communication and collaboration ideally with short, tight feedback loops.
During all of this, I usually look for and apply heuristics to help model the problem space (see James
Bach, Michael Bolton, Darren McMillan and a host of other testers that have written or talked about
different heuristics that they use). All of this helps regardless of the type of project that I might be
on. The project is a change in context and the skill set you have can generally help you test within
and regardless of that context.
For testing
• Lessons Learned in Software Testing¹²⁹ by Cem Kaner, James Bach & Bret Pettichord
• Discussion of the Method¹³⁰ by Billy Vaughn Koen
• How to Solve It: A New Aspect of Mathematical Method¹³¹ by George Polya
• Are Your Lights On?¹³² by Gerald M. Weinberg
• The Book of Five Rings¹³³ by Miyamoto Musashi
• Perfect Software: And Other Illusions about Testing¹³⁴ by Gerald M. Weinberg
¹²⁹https://www.wiley.com/en-gb/Lessons+Learned+in+Software+Testing%3A+A+Context+Driven+Approach-p-9780471081128
¹³⁰https://www.amazon.com/Discussion-Method-Conducting-Engineering-Technology/dp/0195155998
¹³¹https://www.amazon.com.au/How-Solve-Aspect-Mathematical-Method/dp/069116407X
¹³²http://geraldmweinberg.com/Site/AYLO.html
¹³³https://www.amazon.com/Book-Five-Rings-Japanese-Shambhala/dp/1590302486
¹³⁴https://geraldmweinberg.com/Site/Perfect_Software.html
Brian Osman 70
• The “How to Break Software” series: How to Break Software: A Practical Guide to Testing¹³⁵
by James Whittaker, How to Break Web Software: Functional and Security Testing of Web
Applications and Web Services¹³⁶ by Mike Andrews & James Whittaker, and How to Break
Software Security¹³⁷ by James Whittaker & Herbert Thompson.
Personal life
• The Book of Mormon¹³⁸

• Legacy: What The All Blacks Can Teach Us About The Business Of Life¹³⁹ by James Kerr
• Turn the Ship Around¹⁴⁰ by David Marquet
• Counselling with our Councils¹⁴¹ by M. Russell Ballard
• A Soldier’s Way: An Autobiography¹⁴² by Colin Powell
important failure?
My most important failure as a tester is working at a University performing and leading testing in
a supposedly agile context and recognising too late that it was a very political, psychopath-driven,
artifact-heavy, rubber-stamping exercise whereby management had the Dunning-Kruger Effect¹⁴³
on full blast. My failure was realising that they were not going to change and how much of a draining
uphill battle it was to showcase effective activity-based testing as opposed to the mindlessness of
producing artifacts for the sake of the artifacts as espoused by project ‘leadership’ (because they
knew better).
Personally, the failure of not continuing with my blog (The Tao of Software Testing¹⁴⁴ and the
collaboration blog Hello Test World¹⁴⁵) as a way to test ideas and thoughts was something that I
should’ve taken care of and been better at doing.
I guess I have become better at saying no to LinkedIn connection requests or requests for my time
if I am busy (and not feel guilty about it). I realised that being nice and being kind are not the same
thing. Being kind means choosing how and where I can serve effectively.
do?
¹³⁵https://www.amazon.com.au/How-Break-Software-Practical-Testing/dp/0201796198/
¹³⁶https://www.amazon.com.au/How-Break-Web-Software-Applications-ebook/dp/B0028MBKCA/
¹³⁷https://www.amazon.com.au/Break-Software-Security-James-Whittaker/dp/0321194330/
¹³⁸https://www.churchofjesuschrist.org/study/manual/gospel-topics/book-of-mormon?lang=eng
¹³⁹https://www.amazon.com/Legacy-by-Kerr-James-Paperback/dp/B00ZY8YHNE
¹⁴⁰https://www.davidmarquet.com/turn-the-ship-around-a-true-story-of-turning-followers-into-leaders-by-david-marquet/
¹⁴¹https://www.amazon.com/Counseling-Our-Councils-Learning-Minister/dp/1573452092
¹⁴²https://www.amazon.com/Soldiers-Autobiography-Colin-Persico-Powell/dp/009943993X
¹⁴³https://www.psychologytoday.com/au/basics/dunning-kruger-effect
¹⁴⁴https://bjosman.wordpress.com/
¹⁴⁵https://hellotestworld.com
Brian Osman 71
Read an article or a book or play a game or do something physical – enough to change my thought
patterns so as to switch back to the task at hand. Also, if it’s a very overwhelming situation I try
and remind myself to think ‘blue head’ (see the book “Legacy” mentioned in my previous answer)
and ground myself in some way with Papatuanuku¹⁴⁶.
Brian’s bio
Brian is currently a Knowledge Engineer with a company called Software Education¹⁴⁷ and has
worked in industries such as Telecommunications, Finance, Payments, Government and Utilities.
His specialty is software testing having being involved in the craft for over 21 years. He works as
an agile craftsperson consulting, coaching and teaching various disciplines and helps organisations
improve their agility and software testing. He also continues to interact with like-minded, free-
thinking testers and agilista and takes the opportunity to present at conferences and SIGsT groups.
Brian has a presented at conferences such as STARWest, ANZTB Testing conference, STANZ and
Lets Test Oz.
He also founded the Kiwi Workshop on Software Testing (KWST) along with James Bach and has
helped as a course assistant instructor for The Association for Software Testing’s Black Box Software
Testing online series¹⁴⁸.
As a software tester, Brian aligns himself with the Context-Driven School of Testing and is a
proponent of effective, thinking testing. He prefers using lean, low tech, high value approaches
to testing where appropriate.
Brian is also enjoys working in the agile world and is an advocate for quick experiments and looking
for ways in which teams can achieve ‘smoothness’ in their delivery.
Brian is an experienced coach, test manager, tester, consultant, trainer and speaker with over 21
years’ experience in the craft.
Blog: http://bjosman.wordpress.com/¹⁴⁹
Twitter: @bjosman¹⁵⁰
Skype: bjosman23
Email: brian.osman@gmail.com¹⁵¹ or briano@softed.com¹⁵²
¹⁴⁶https://maoridictionary.co.nz/search?idiom=&phrase=&proverb=&loan=&histLoanWords=&keywords=papatuanuku
¹⁴⁷https://www.softed.com
¹⁴⁸https://associationforsoftwaretesting.org/bbst-black-box-software-testing-courses/
¹⁴⁹http://bjosman.wordpress.com/
¹⁵⁰https://twitter.com/bjosman
¹⁵¹mailto:brian.osman@gmail.com
¹⁵²mailto:briano@softed.com
Rob Sabourin
“Learn new technologies without getting attached to any specific technology.”
“Learn story telling.”
“I failed to understand the importance of the role of testing as a service to the team not as a quality
gatekeeper.”
I first met Rob at the OZWST¹⁵³ testing peer conference in Sydney

in 2013 and he acted as the content owner for the conference.
I presented a short experience report on building a context-
driven testing team in China. Rob loved the story and strongly
encouraged me to share it more widely, so I decided to submit a
talk on the same topic to the Let’s Test conference in Sweden. The
talk was accepted and so the next time I saw Rob was in Sweden
in 2014 where I delivered my first ever conference talk on testing.
Rob’s enthusiasm, support and encouragement set me on my
journey of giving conference talks and I’m pleased to say our
friendship and mutual professional respect continues today. I
consider him a mentor, a peer and, most valuably, a friend. I ran
the idea for this book past Rob and his thoughtful comments and suggestions both inspired me to
proceed with the project and also to make some changes that have improved the book you read
today.
Rarely will you come across anyone as passionate and enthusiastic about their craft as Rob Sab and
his answers below hint at that passion, enjoy!
I have a few:
• Building an international peer community using peer conferences as the primary vehicle
• Teaching and learning how to teach
• Mentoring and learning how to mentor
• The diverse people I have built strong relationships with
The discipline of publishing at least one article per year since I graduated from University. I
graduated in 1982 and I am still publishing papers averaging well over one per year.
¹⁵³http://associationforsoftwaretesting.org/2013/09/26/ast-grant-report-ozwst-2013-in-review/
Rob Sabourin 73
I advise delegates to master learning new technologies without getting attached to any specific
technology. I have been at this field since 1979 or so and I have adapted to thousands of different
technologies without losing sight of the fact that they will all change tomorrow. I also advise
delegates to build relationships with people who sell and market technology. Ignore becoming a
guru in the technology of the month. Ignore advice telling you not to learn programming - you
should learn as much as you can about how computers work including hardware and software.
disagree with?
I disagree with the idea of doing work early, I like to suggest you detail testing at the last responsible
moment without necessarily procrastinating. I disagree with outsourcing core business practices.
how?
None that I can think of - but I have not been counting when I introduced practices. A great
habit I have is to hire technology stack gurus to help build examples to help teach test design to
programmers.
My respect for people in sales, marketing and business development. Early in my career, I ignored
or treated these professionals with indifference. I should have built strong relationships with them.
Project: Initial Customer Target Platform (Focus on one instead of many)
I was working with a medical software company implementing point of care diagnostic analysis
software. The product was required to support three database technologies included Microsoft SQL
Server, Interbase and RAIMA, a real time database tool.
The product was experiencing many problems related to technical differences in both the structure
and access mechanisms of the database.
Our sales team closed a deal for a major hospital in Belgium requiring use of Interbase. This would
be the first account for the new product, and it was quite lucrative.
Testing focus was moved away from multiple databases to a fixed database which reduced the
amount of testing effort by over 2 person months.
Project: Graphics Libraries Turbulence (Technical flavor of the month)
The project involved developing an online tool which enabled customers to visualize how clothing
would fit before purchase. The software created visual models of the user and used complex
algorithms to provide a slick visualization with state-of-the-art graphics libraries.
Rob Sabourin 74
Unfortunately, the customer insisted of using the latest and greatest graphics libraries which changed
frequently during the development process.
Each change led to tons of retesting and frequent library specific GUI related bugs. The team was
wasting time and money with all of the rework coupled with being demoralized.
The customer in the internet fashion market was fickle but knew the end user impact of slick graphics
would pay off.
We adopted an ALAP testing strategy and always kept to shippable options available for the
customer. Option 1 was the last best option in terms of functionality. Option 2 was the most recent
build with the latest and greatest technology. Whenever a technology was changed, we looked at
the current Option 2 and reviewed it with product management to see if it was a candidate to replace
Option 1.
We always could fall back to the last best build. We reduced some rework and dramatically increased
the chances of deploying a solid product.
Project: War impact on shipping costs (As if the violence was not enough)
I was involved in developing a character imaging device for the Middle East market but due to the
first gulf war our shipping insurance rates drove product cost to absurd ranges. We refocused and
did an about face to focus on the eastern European market which was opening up at the time due
to perestroika.
Project: Source of investment capital (Show me the money)
On the communique project we had a fixed delivery date. I was given the date as usual from the
product manager in the marketing department. The date was firm, and I expected was tied to sales
campaigns, advertising, and related business obligations.
I discovered that the date was driven by a new shareholder who invested $500,000 with a promise of
an additional $1,500,000 if we could commercialize our technology before the next board meeting.
The investor insisted we have at least one operating commercial valid installation.
We refocused the project on the explicit requirements of one sales lead of significance in our funnel
- this dramatically reduced the scope and focus of testing - in fact we were able to use the real
customer hardware for our testing.
In work, Raving Fans¹⁵⁴ by Ken Blanchard. In life, The 7 Habits of Highly Effective People¹⁵⁵ by
Stephen R. Covey, Choice Theory¹⁵⁶ by Dr William Glasser, and The Bible - New Testament (Letters
of Paul mostly).
important failure?
¹⁵⁴https://www.kenblanchard.com/Store/Raving-Fans
¹⁵⁵https://www.franklincovey.com/the-7-habits.html
¹⁵⁶https://www.amazon.com/Choice-Theory-Psychology-Personal-Freedom/dp/0060191090
Rob Sabourin 75
In early device driver development from 1979-1982, I found some incredible bugs in the hardware
which were never fixed because we could work around them in software. I failed to understand
the importance of the role of testing as a service to the team not as a quality gatekeeper. I was too
proud of my bugs to realize that the cause didn’t matter if a workaround existed. I was humbled
that hardware design with very high capital cost almost always trumped software testing.
I have had many failures. I learn from failures quickly. I learned to fail safely and to guide others to
fail safely too.
My most influential failure as a manager was when I treated relationships with my team members
and subordinates as if they were personal friendships as opposed to professional colleagues. I really
burnt out because of this. I did a lot of stupid things and I learned the very hard way that productive
professional business relationships are not necessarily friendships. Friendships may develop with
time but that is not why you are together. The team lead or manager is not the team’s social
coordinator.
I am not better at saying no - but I am better at spinning requests into fun opportunities. I do not
try to overload myself and I have a rule that I participate in only one major volunteer initiative each
year.
do?
If I have lost focus completing a task:
• I have several tricks - for example, I set a timer to ring every 30 minutes to help me re-focus if
I stray.
• I ask why, I try to learn why before diving deeper
• I ask who - especially who I am doing the work for?
• I ask when - is there a real deadline? Must I do all of the work? Can I do some of the work?
Can I do none of the work?
• I remember Blanchard’s Management of Organizational Behavior¹⁵⁷
• I remember Stephen Covey’s Time Management Matrix¹⁵⁸
• I apply ideas from my own JIT (Just-In-Time) Software Testing¹⁵⁹ approach
• I brainstorm and list the questions I want to answer before starting to write a paper, essay or
report (even a test status report)
There is another way to look at this question, so far I have been thinking of accomplishing a task
but what if the question was more about your chosen profession? Maybe the reader has run into
a brick wall and finds there is no advancement. I often run into testers only to discover that they
¹⁵⁷https://www.amazon.com.au/Management-Organizational-Behavior-Leading-Resources/dp/0132556405
¹⁵⁸https://www.businessinsider.com.au/how-to-use-stephen-coveys-time-management-matrix-2015-12?r=US&IR=T
¹⁵⁹https://www.swissict.ch/event/just-in-time-software-testing-robert-sabourin-english/
Rob Sabourin 76
do not have seventeen years of experience, but rather they have one year of experience repeated
seventeen times. How do you avoid these ruts? I believe in building communities of professionals
who are working on related problems. I believe that this helps to advance the profession and makes
a societal difference. To be sure, most individual contributions on their own may look small and
inconsequential but I feel it is important to recognize that a large community of small contributions
can actually make the world a better place. I feel that finding a venue to share experience with peers
from other companies could be a useful practice. During peer conferences, I have shared experience
reports which led to excellent discussions which help me overcome important obstacles in my work
or professional practice. Some other ideas for regaining career focus:
• Learn story telling.

• Consider participating in organizations such as Toast Masters.
• Participate in local meetups.
Rob’s bio
Robert Sabourin has more than thirty-seven years of management experience, leading teams
of software development professionals. A well-respected member of the software engineering
community, Robert has managed, trained, mentored and coached thousands of top professionals
in the field. He frequently speaks at conferences and writes on software engineering, SQA, testing,
management, and internationalization. The author of I am a Bug!¹⁶⁰, the popular software testing
children’s book, Robert is an adjunct professor of Software Engineering at McGill University. Robert
is the principal consultant (& president/janitor) of AmiBug.Com, Inc.¹⁶¹
¹⁶⁰https://www.amazon.com.au/I-am-Bug-Robert-Sabourin/dp/0968577407
¹⁶¹http://www.amibug.com/
Paul Seaman
“I’m regularly surprised by testers who are not new to the role “discovering” that risk is important
in testing.”
“It was something of a relief to find a whole bunch of people talking about testing in ways that I
understood and in ways that I didn’t understand but would grow to.”
“I found that working in a high stress, toxic environment really is unhealthy. How did I find out?
Three months off work trying to regain my mental health and some sense of “normal”.”
I first met Paul as a result of co-founding and organizing the

TEAM testing meetup group in Melbourne. I worked closely with
him to co-organize the Australian Testing Days¹⁶² conference
and we also enjoyed presenting an exploratory testing workshop
together at the same conference. We continued to form a strong
friendship and have since collaborated on a number of projects.
On the conference front, I invited Paul to assist me with the
responsibilities associated with being the Program Chair for the
AST’s CASTx18 conference¹⁶³ and this led to us being asked to take
organizational responsibility for their next Melbourne conference,
in the shape of Testing in Context Conference Australia¹⁶⁴ in 2019.
We had a lot of fun working together with the AST to plan, organize and run these conferences for
the context-driven testing community.
An important joint effort with Paul was the EPIC TestAbility Academy¹⁶⁵, a software testing training
course for young adults with autism that we put together with EPIC Assist¹⁶⁶. This was a rewarding
experience and Paul’s passion for volunteer efforts like this really drove my interest. We enjoyed
giving this course twice (in 2017 and 2018) and it also led to joint presentation opportunities within
a couple of companies¹⁶⁷, at an ANZTB SIGiST¹⁶⁸, and also two conferences (LAST 2017¹⁶⁹ and
TestBash Australia 2018¹⁷⁰).
More recently, we decided to start a joint blog, Ma Kelly’s Greasy Spoon¹⁷¹, and this has been another
¹⁶²https://therockertester.wordpress.com/2016/05/25/australian-testing-days-2016/
¹⁶³https://therockertester.wordpress.com/2017/05/23/program-chair-for-castx18-in-melbourne/
¹⁶⁴https://therockertester.wordpress.com/2019/03/08/testing-in-context-conference-australia-2019/
¹⁶⁵https://therockertester.wordpress.com/2017/01/08/a-new-year-and-a-new-challenge-the-epic-testability-academy/
¹⁶⁶https://epicassist.org
¹⁶⁷https://therockertester.wordpress.com/2017/07/26/same-story-different-companies/
¹⁶⁸https://therockertester.wordpress.com/2017/08/03/er-of-presenting-at-the-anztb-sigist-melbourne-27th-july-2017/
¹⁶⁹https://therockertester.wordpress.com/2017/07/06/er-of-presenting-at-the-last-conference-and-observations-on-the-rise-of-qa/
¹⁷⁰https://therockertester.wordpress.com/2018/10/25/er-of-attending-and-presenting-at-the-inaugural-testbash-australia-conference-
sydney/
¹⁷¹http://makellysgreasyspoon.wordpress.com/
Paul Seaman 78
different experience for both of us and an avenue for our collective thoughts on various topics to
get an airing.
As I write, we’ve been unable to catch up for our usual coffee chats in the city after work for many
months as we both remain firmly working from home thanks to COVID-19 restrictions. Video calls
keep us in contact, though, so we still take the opportunity to meet and put the testing world to
rights every week! Our mateship is important to me and I hope you will enjoy Paul’s responses.
As a kid, because my dad was a computer engineer, I spent a lot of time around big mainframe
computers that resided in very cold rooms. I was the first kid on the block (by decades) to have a
personal computer. My Dad built it and it ran on a language called mini BASIC. It didn’t inspire me.
To be honest, IT was never on my radar let alone testing. Of course at that time I had no idea how
all-consuming computer power would be in the coming decades.
Like a lot of testers I fell into “testing”. When I finished High School I went to college and completed
a Diploma of Teaching (Primary Education). Several core courses were based in psychology and my
electives were also psychology based. I had no idea how useful that would be at the time. I just knew
that the subject interested me and the lecturers were some of the most interesting people on campus.
Before I found myself in the world of IT, I spent my first six months post-graduation working in a
small fishing tackle store. It was fun for a while as I got to work at a passion, got cheap gear and
spent a lot of time talking to people and learning how to spot what they might really need to buy.
Probably my first lesson in people (especially new fishermen) thinking they want something but
really needing something else. This job also taught me that I don’t handle boredom all that well.
I applied for and was picked to be part of a fast-tracked management program for a major Australian
supermarket chain. This was my first exposure to “command and control” management. I also saw
a lot of managers simply repeating what they had seen or been told and not translating that into
current context. I learned that I didn’t really want to be part of that scene and that supermarket
management was not a career aspiration for me. I did get to learn a bit about routines and processes
having a place (stock ordering, for example - miss your ordering slot and you ran a chance of running
short on stock until your next assigned delivery). The most fun I had during this time was working
with the Fresh Food Manager. He was a bit of a rebel, ordered stock based on his gut feel and
experience and didn’t simply tow the management line. He was honest with a sense of humour.
I spent eight and a half years working for a large Australian bank. I started as an entry level cadet
and was an assistant manager in a business and personal lending group when I left. If you want
to work in a bank, you have to understand the importance of integrity, honesty and accuracy. You
have to be able to deal with people and colleagues. It’s (or was) more challenging than you might
think. There are lots of problems to be solved. My favourite period of my time with the bank was
in lending. I got to solve problems working with people. People would come in with a dream that
required financing for it to happen. Working through financials, getting an understanding of their
plans, researching how other businesses of the type were fairing was challenging and fun. I also had
to learn how to explain to people that sometimes I couldn’t say “Yes”.
Paul Seaman 79
The Bank decided that its focus would move from customer satisfaction to one of hitting product
sales numbers. That killed the fun, I left and took a role with Victoria Legal Aid (VLA). For the first
three months it was great. No pressure, more pay and it was all pretty easy. Then it got boring. I was
walking out of the office one Friday afternoon thinking about job hunting on the weekend when my
Manager asked if I would like to join a project where VLA was introducing a new database system
(and front end) for tracking cases from inception to completion. Suddenly I was both a business
analyst and a tester. Nobody told me this, it just happened and I just worked things out as I went
along. When I had to write up specifications, I spoke to people who would use the system (my
teammates from my former role). I asked them what they would like and why, found out what
bugged them in the current system and how it could be improved. I designed input forms to match
the new workflows and then, when coding was completed, I tested that the system did the things
I knew the users wanted. I logged bugs and tracked them to completion (the vendors actually got
tired of me ringing and asking for confirmation of delivery dates on bug fixes and complained to
my manager. My manager handed on this news followed by “keep pestering, it’s part of your job”).
The team I worked on for this project remains one of the most amazing teams I’ve ever worked on.
Very little software expertise but plenty of domain knowledge and discussion with end users. The
“go live” was almost perfect.
After VLA, I spent almost two decades working for a company that built financial software systems
for investment banks. I started as a business analyst, moved to a support desk lead role and then into
testing. I found testing by accident. Testing was a relatively new team at the time and they were
looking for team members. I had just completed a really tough six-or-so months and needed a change.
That change moved me into testing and a career. I eventually discovered that testing engaged me in
ways no other job had. It appealed to my sense of solving puzzles. It allowed me to collaborate and
help find answers. Testing was my “sweet spot”.
I’m not entirely sure if I can call out “the most interesting aspect” but what I can see in my journey
to testing is that a wide range of jobs and roles has allowed me to meet and learn from a variety of
people and to call on a broad history when thinking about problems and solutions. Writing this has
allowed me to look back over my journey to testing and see just how much of what I do now was
not born of testing but rather brought to testing and then refined by it.
I think some communication techniques from those conversations still stay with me today.
There are a number of things I could write about, but I think the most worthwhile was spending
time exploring why I wasn’t happy with testing and the general industry thoughts on how it should
be conducted. I found the whole notion of waiting for documents and code to arrive annoying. The
idea of being an independent judge, living in a silo, was not fulfilling and it felt like a suboptimal
way to operate. Spending hours writing test cases that, when the code was finally ready, were no
longer relevant in significant ways, felt enormously wasteful.
All the above thoughts and observations started to appear when I was about 18 months into my
testing career and probably 12 months after completing the ISEB Foundation certification. All those
shiny terms, those “best practice” processes and procedures were losing appeal rapidly. It created a
Paul Seaman 80
need to determine if I was a lone crazy dude that really didn’t understand testing or if others were
expressing testing ideas that resonated with my thoughts and feelings. It was something of a relief
to find a whole bunch of people talking about testing in ways that I understood and in ways that I
didn’t understand but would grow to. It gave me confidence that the things that troubled me had
some basis in a broader environment than my own. It gave me ideas to experiment with (sometimes
secretly - “testing in stealth mode”). More importantly it enabled me to develop an approach to
testing that has served me well. It helped me develop critical thinking skills and questioning skills
that have been incredibly useful. Best of all my searching for better showed me that testing could be
performed in ways that are satisfying. That testing could help solve important problems by working
with people and that testing is not defined as writing and executing test cases.
Occasionally, when I’m talking to a new testing acquaintance, I’ll get the observation “you don’t
think like other testers, you’re different”. I take that as a validation of my efforts to become a good
tester.
Probably the first thing I would suggest to them is “don’t ignore any advice”. I think when you are
new to a field, with little experience, you need to take on board a lot of thoughts and ideas. You need
to process them, question them and make decisions about what might work for you. When we reject
an idea or advice, we should be evaluating why we want to reject it. What is it about the advice that
does not fit with our thinking? Does the advice simply not fit with our current context (but it might
be useful later, in another context)? Does it clash with personal beliefs or understandings?
To help with all that processing, find a person, or people, that you can use as a sounding board. People
who can help you sort through ideas but allow you to find what works for you, what resonates as
being reasonable and useful. In my mind, to be good in any field, you need to create a personal
framework of practices that work for you. As you gather more experience and knowledge that
framework will change, your test kitbag will become more robust as you learn across different
contexts.
I’d also recommend to new entrants that they don’t get comfortable, or develop illusions, about
not needing to learn anything new. I’d also suggest tempering this with not attempting to learn
everything. What’s useful, what’s interesting, what’s valuable. Don’t do it for the certificate.
disagree with?
“Automation because… < just insert favourite best practice or misconception >”. There is simply
far too much bad information being circulated around automation and its usefulness. I find it
troubling that many people in testing roles help to amplify the misinformation rather than mounting
counterarguments that are based on both reality and context. Automation is, in some ways, testing’s
version of “agile”. People and companies want the title, they want to be a “cool kid” and talk about
how they are “using all the best practices”, “all the technology”, but spend little time learning about
what adopting either new tools or culture really means for them or what value the change might
Paul Seaman 81
bring. I tend to roll my eyes a little when I see ROI brought into these conversations - yet another
buzzword being abused at scale by testers, toolmakers and consultancies.
I’m tired of seeing testers collecting certificates for tools. I’m tired of hearing testers talk about
how they need to learn the latest three new super tools and not hearing them talk about how they
might spend time broadening their understanding of good testing and how to become a great tester.
I can’t remember the last time I saw a thread in LinkedIn that was focused on improving critical
thinking, understanding human communication, learning a bit of psychology, learning how to test
without a specification document or testing without test cases. It’s rare to see people asking about
or discussing test techniques (and I don’t think this is because of global expertise in the topic). I’m
regularly surprised by testers who are not new to the role “discovering” that risk is important in
testing. The values are misaligned and badly so.
I’d much prefer to see us move to a focus of learning how to test well and understanding that context
is very important to testing missions. Being able to pull requirements from a specification and then
turn them into test cases is not the limit of testing. If anything it sits at the start of the journey of
learning how to test as an explorer and discoverer. Learning how to utilise the right tools in context
needs to become a focus. Personally I don’t care how many tools a tester has certification for if
they can’t use them in ways that help produce valuable information. Demonstrated competence in
context trumps certification every single day of the week.
So how did we get like this? The recruiting sector has a lot to answer for. An approach that
targets filtering on certification provides incentive for testers to chase shallow skills through
certification. Companies recruiting based on what they perceive they want rather than what they
need. Reacting to what they see in other companies’ job advertisements, misguided advice from
recruiting companies but rarely seeking and digesting the advice and feedback of their testers.
It seems it’s far easier to adopt somebody else’s model, to be like the rest, than spend time
understanding what type of person and skills are required to help improve what your company
does.
Testers are also contributing. It’s time for testers to learn how to talk to non-testers about testing in
ways that are not limited to test cases executed, test cases automated and bugs found. While testers
continue to talk in these terms then automation will continue to look like a cure-all to non-testers.
Worse, while you continue to talk about testing in those terms to your Managers it’s pretty simple
for them to join the dots, create an incorrect picture of testing, and remove humans from testing
in favour of computers executing checks. I can already see the same smoke and mirrors being used
to sell AI and ML and the illusion of “codeless automation” that has been driving the “automate
everything” train of thought.
If you’re a tester reading this then your challenge is to tell stories that amplify the value you bring as
a human tester. Talk about how tools in testing help humans but they do not test, they do not discover,
they are the reason testers can be efficient but tools are not testing. When you see outrageous claims
in posts, challenge them with sound reasoning. Contribute to correcting the misinformation that
plagues testing and diminishes the value that good testing and good testers bring.
Paul Seaman 82
how?
I might need to stretch a little past the five year boundary - but not by very much. A little over five
years ago I discovered that caring too much about work and what other people thought was deeply
detrimental. I found that working in a high stress, toxic environment really is unhealthy. How did
I find out? Three months off work trying to regain my mental health and some sense of “normal”.
Not that long after going through the worst of this, I attended a Rapid Software Testing¹⁷² course.
On one of the course days, Michael Bolton mentioned that “… we always have choices. You might
not always like the choices but we always have them”. That was a lightbulb moment for me and
the timing of delivery was exceptional in my context. This has become something of a mantra for
me along with the realisation that making mistakes, getting things wrong, is actually fine. I have
learnt to embrace rather than deny my fallibility. It’s important to clarify here that I don’t dodge
accountability, part of being professional is to accept you have a level of accountability.
It wasn’t all that long after the above that I ended up leaving the company and going to a smaller one
with a much healthier environment and people friendly management. I went there as a Test Coach
but (for several reasons) never spent a lot of time dedicated to that role. About three months into a
role in a Company with an awesome culture, I felt I was struggling. At that time we had an Agile
Coach and she invited me for a chat over coffee. An observation she made “why are you just sitting
around not influencing like I know you can?”. I know I mumbled a few excuses about the other
testers lack of interest in change and a few other things. The response remains clear in my mind
even now. “That’s fine, you can think like that if you want but remember you are choosing to think
like that. You are making a choice to be not at your best”. My reaction was immediate, I immediately
acknowledge that I did indeed have a choice and I’d not been making good ones. My energy levels
lifted almost immediately. I realised when later thinking the conversation through that maybe I
can’t influence a specific group of people but there were others I could, and was, influencing into
better development and testing practices. Those seemingly simple words from Michael have become
a guiding principle in both my professional and personal life.
This is a tricky question for me because every example I can think of has been a learning experience
and shortcutting these would have resulted in a different me as a tester. I like to think that there was
real value in those experiences that made going through them worthwhile.
In many ways I think I was initially far too cautious and far too keen to impress in the wrong ways. I
think back on being sucked into the “ISTQB vortex” and some of the things that it inspired me to try,
such as establishing the ISTQB glossary within the test team I was leading as the communication
standard (pro tip: don’t do this). Spending far too much time on writing test cases, linking them to
requirements and waiting for software to reach me. Part of me would have liked to skip this period
but it was through this that I started to question what I had been taught, how it was working in real
life and ways in which I thought things could be better. Frustration with systems and approaches
can lead you to asking important questions and seeking useful answers. When I finally found
¹⁷²https://www.rapid-software-testing.com/
Paul Seaman 83
Context-Driven Testing it intuitively made sense as I could see how much of it aligned with my
own discoveries.
I’m pretty sure that I really didn’t understand the value of failure when I started my testing career.
In fact I know that I feared failure and possible negative consequences. I’d definitely advise my
younger self to worry less about that and focus more on what is learnt and how that can be used to
be better on the next testing mission.
I’d also suggest to never hold the idea that testers are quality guardians. I went through a phase
where I probably placed more weight on that notion than I should have. I was judgemental with
developers several times and inconsiderate. I gave several people a harder time than I should have
“because quality”. I’d tell myself to skip this nonsense. The best thing you can do is honestly believe
that the people you are working with are doing the best they can. When things don’t work, just
support them. This is part of being a leader and a good team member. Most of all understand that
as a tester you can contribute information that helps improve quality but you don’t own quality.
I think my last piece of advice to myself would be “don’t sweat the small stuff”. Give everything
your best shot and be prepared to succeed and also fail. Don’t stress over either but learn from both.
Work, at its best, is a shared endeavour of chasing common goals to deliver value to our customers.
Enjoy the experience, have fun, offer your opinions and don’t be offended if they are critiqued with
honesty and genuine respect. Give the same to your teammates.
Perhaps the most important concept I grasped as a tester was actively acknowledging context. Up
until that point, it was probably a concept at the back of my thinking, fragmented pieces, not helping
to inform my decision making process. Not surprisingly, talking to people in the context-driven test
community and reading their articles helped me understand not only the importance of context but
strategies in creating models using context. This has been a base on which my testing has grown.
Every time a tester is asked to contribute, there is context around the engagement. That context holds
important information that will help you decide what to test and who to keep informed (amongst
other things). It will also help you understand who to keep in regular touch with if you are working
in an environment where collaboration is not a priority.
Learning to look at testing as a mission has been very useful. It certainly changed the way I look
at testing. I’m fairly sure I picked up this concept from the Rapid Software Testing writings before
I ever attended the classes. I find it useful to have a model that helps me concentrate context into
specific testing focuses. I like that I have an overall mission that I can easily break down into smaller
missions. It allows me to always have a view on what I’m doing and where I need to get to and how
I’m tracking. It also allows me to quickly assess and implement any changes.
I love open and respectful collaboration. When I can test in this type of environment, I can get
“up close and personal” with the changes. I’m not talking about pretend agility, testers sitting and
waiting for the code to drop, but environments where testing is invited in and the contributions
valued. This is my nirvana. Working closely with all stakeholders on a project, influencing how
the design might be built and implemented, taking into consideration who our end users are, their
Paul Seaman 84
needs and capabilities. With this comes a little pressure as you need to be an active contributor to
build trust and also demonstrate that you, as a tester, add value. The rewards of being able to test
small changes often and creating fast feedback loops are worth the effort. This is the environment
in which my creativity peaks and I feel like my testing contributes at its highest level.
The availability of stakeholders is important to parts of my testing. This is part of the context.
Part of my role as a tester is to keep stakeholders informed. When these people are nearby my
communication strategy will differ to when they are more remote. The blend of internal and external
stakeholders, what they need to know and how often will help me form a communication strategy.
I believe that we can under-communicate and also over-communicate, both are problematic. The
bigger the project, the more complex it is, the more effort I need to put into understanding the
information needs of my stakeholders and how I can meet those in a way that is “good enough”. A
policy of “no surprises” is important to me and my communication strategy is a key to minimising
or completely removing “surprises”.
Past mistakes are really important to me. It took me a while to embrace just how important this is.
For part of my career, I worked in a company that thrived on blame. Openly embracing mistakes
in that environment can be unconditionally damaging. Regardless, even in adverse cultures, I spent
time debriefing what went well and what didn’t and trying to understand why. Some time ago, daily
debriefs became a habit. The first twenty to thirty minutes after leaving work, I go through the day
and run a mini review. I’m often distracted enough by traffic and other people while walking to
catch my train home that the debrief is not a direct focus. This works well for me, it helps me think
about things in a different way. I carry a notebook with me to jot down observations I don’t want
to forget. I’ve lost count of the number of times I’ve been able to think of ways of getting around a
problem on these walks and utilising the insights to improve my work.
This is an interesting question as I have a belief that people who are really into testing as a career
are testers twenty four/seven. I’ve spoken to a number of people that I believe are good professional
testers and it is an approach, a belief system, that does not get turned on when entering the office
and turned off upon exit. So anything that impacts my testing at work will impact my life outside
of work. However, in the spirit of the question, here we go.
Lessons Learned in Software Testing: A Context-Driven Approach¹⁷³ (Cem Kaner, James Bach & Bret
Pettichord) has been an important book for me as a tester. It helped me frame some ideas in useful
ways that also shaped how I approached and communicated my testing. I’m a big fan of The Secrets
of a Buccaneer Scholar¹⁷⁴ (James Bach). There was an attitude of achievement around persistence
that I really liked and was something I could identify with (I once had a manager refer to me when I
was testing as a “dog with a rug that won’t give up until satisfied there is nothing left to shake out of
the rug”). I consult with Janet Gregory and Lisa Crispin’s books on Agile Testing¹⁷⁵ pretty regularly.
I like the human focus their approach injects into testing and also their collaboration focus. I could
¹⁷³https://www.wiley.com/en-gb/Lessons+Learned+in+Software+Testing%3A+A+Context+Driven+Approach-p-9780471081128
¹⁷⁴https://www.amazon.com/Secrets-Buccaneer-Scholar-Self-Education-Pursuit-Passion/dp/1439109095
¹⁷⁵https://agiletester.ca/
Paul Seaman 85
name a bunch of books that are written for testers that have been influential but there are a lot of
books not written specifically for testers that I think have played an important role in my testing
and personal life.
Obliquity¹⁷⁶ (John Kay) is possibly one of my favourite books. I can’t remember how I encountered
this book but it has been a game changer for me. The idea that goals are best achieved by an indirect
rather than direct approach. This is why I contend I don’t focus on bugs, instead I focus on putting
together an approach that will put me in the best position to find them while discovering important
information about the system I am testing. I have no doubt this book has strongly influenced my
approach to testing and how I talk about it. I also use the same thinking outside of work. Checking
off on the important little things, getting those “ducks in a row” will make hitting the target fairly
inevitable and more sustainable.
The Checklist Manifesto¹⁷⁷ (Atul Gawande) took my interest in checklists to something approaching
a passion. I doubt there is a day that goes past without me using checklists in some form. Checklists
free up mental capacity and allow me to focus on the really important things both within testing and
my personal life. I experimented with checklists as a team lead some years ago (after reading The
Checklist Manifesto). The team used them to either physically check off an important criteria being
actioned or to remind themselves that it required consideration before moving to the next phase (it
was a waterfall development shop). The result of that experiment was a dramatic drop in skipping
what we considered important steps in our product quality chain and added minimal overhead.
I’m something of an aviation tragic and read a lot of books on aviation. I’m especially interested
in accident investigation and can sit for hours watching my Air Crash Investigation DVDs. The
accident reports produced from aircraft accidents are simply amazing, a great lesson in reporting
what is relevant and how to make an evidence based report that is objective and accurate. Books such
as QF 32¹⁷⁸ written by Richard De Crespigny, the Captain of the Airbus A380 that had an uncontained
engine explosion departing Singapore. This book explores the impact of workplace stress, both short
and long term, which was a theme in my life at the time I was reading the book. It was enormous
help to me personally but the book is also about testing. Testing an aircraft missing many vital
control systems, determining its envelope of safe operation, how to land safely and a story of team
collaboration in pursuit of a shared goal. When I hit hurdles or blockers of some kind in my work,
I often think back to this book and how I might use what I took from the book to continue my test
mission.
important failure?
The most interesting failure I’ve been involved in was a small project with a single business and
functional requirement and the implied tag of “easy project”. I was between major projects so was
asked to test this change. I asked a few questions to establish what was being changed and why. I
had some previous experience with the area so realised that the change itself was not a big deal.
I also remember asking if we were pretty sure we knew what our client actually wanted as some
¹⁷⁶https://www.amazon.com/Obliquity-Goals-Best-Achieved-Indirectly/dp/0143120557
¹⁷⁷http://atulgawande.com/book/the-checklist-manifesto/
¹⁷⁸https://www.panmacmillan.com.au/9781742611174/
Paul Seaman 86
statements were not precise, there was some ambiguity. I was assured that what was being coded
was what the client wanted. To cut a long story short, I ended up testing that project three times.
That simple, one requirement project took three iterations to actually deliver what the client needed
and had requested. Lesson - there is no “simple” and words do matter. Simple is often a dangerous
mindset in software and I now see it as a heuristic that we might be missing important information.
Similarly I’m the person that is most likely to be first to question the use of a word or a term in a
meeting. A common shared, deep understanding is essential to building valuable software.
One of my more important failures wasn’t related to my software testing. I mentioned in an earlier
response that I had tried to embed a common language (the ISTQB glossary) within the testing
team I led and that didn’t work very well. At the same time, with not a lot of experience as a lead
in testing, I got sucked into the “command style” that the company seemed to thrive on. I started
setting behaviour expectations and being a little too zealous in expectations. Not surprisingly, that
didn’t go down very well. It’s interesting though when the feedback from your manager conflicts
with those you are leading. It took a while for me to reconcile what the heck was happening and I
stepped out into another role for a time. In this role, I initially was responsible only for myself and
that gave me time to think about the feedback from the people I had led and some of the ways I had
reacted to situations. It wasn’t a great experience but it taught me to trust my team, to work closely
with them and most importantly that I can’t change people’s behaviour. The best I can do is set an
environment where it encourages people, piques their curiosity about changing a behaviour, trying
something new or being open to a new experience. Creating an environment where openness and
trust are embedded to create a safe place.
Perhaps my most important failure (and I’m not sure that failure is the correct word for this) was
my mental health enforced break from work and the longer recovery period. It taught me valuable
lessons about work and life and people (and a few about me). Work is something I do to enjoy, not
to die of stress. I can make mistakes and not kill people or even injure the company I work for. Most
of all, it is possible to work in good and sustainable, rather than unsustainable, ways. It taught me
to slow down and be deliberate in my actions (the “slow down to speed up” thing is real, at least in
my case). It taught me to make sure I enjoy what I am doing and to never stay with a company that
supports a toxic workplace. I’m pretty sure that the changes brought on by this break resulted in me
becoming a better tester and a better person to work with. Learning to simply “sit back and take a
deep breath” brings balance and a clear headspace faster than anything I know.
I really don’t say “no” very much at all, I tend more to “no, not now” or “can we talk about this at
a later time?” (which could be any agreed time period). I’ve always been somebody that is curious
and loves solving and helping others solve problems so I’m never all that keen to rule out a meeting
of the minds where I will quite likely learn something and hopefully help a colleague.
I’ve even learnt to not say “no” to ideas I don’t like when in a meeting or discussing them with
colleagues. I much prefer to leave that aside and instead seek to discuss an idea (even when I have
a gut feeling that I should say “no”). I’ve learnt a lot by doing this and have seen great solutions
emerge from ideas I would have once simply dismissed.
Paul Seaman 87
I have learnt to say the equivalent to “no” if I’m asked to take on too much work. I’ve learnt to not
take on too much and instead to discuss priorities, what can potentially be put on hold, who else
might be available, etc. In short, explore possibilities. I’m lucky enough to be working in a company
where I can have this conversation without fear of blowback. There is an area however, where to
protect myself and my family, I would say no - if it placed in the “too much on my plate, gotta finish
everything now” scenario I would provide an emphatic no.
Over the years I’ve attended a lot of meetings (far too many) and my tolerance for them has
diminished somewhat so I will say no to meeting invites if the meeting purpose is not clear or
if I cannot see any way in which I can either add value or learn something of value to me and
my role. As a parting tip in this section, if you want to help drive better meeting behaviour, reject
meeting invites that don’t have an agenda and make sure the reason for rejection is clear. I did this
at one company I worked for and a couple of colleagues started doing the same - agendas or meeting
reasons started appearing in all invites very quickly.
do?
I can be very intensely focused when I’m testing, I’ve had instances where I’ve “lost” up to three
hours. While that is the opposite to the question being asked, it is related. While it’s great to get
into the flow, it is mentally draining to be switched on and focussed for such a long stretch. I find
after a period like this my focus can wander for the remainder of the day and I’m easily distracted.
To avoid these long stretches of focus, I’ll sometimes use a timer set for somewhere between forty
five and sixty minutes. When the timer goes off I round off notes so I can pick things back up after
a five minute break. I also take breaks to grab a quick tea, coffee or a camomile tea which gets me
out of my chair, walking and chatting to other people. I also keep juggling balls close by. A couple
of minutes of juggling gets my focus solely on the act of juggling and often clears any distractions
from my mind, allowing me to return to whatever I’m doing with better focus.
Is it controversial to say that sometimes there are days where unfocused is the best you can bring?
We’re human and, for a variety of reasons, we don’t roll up to work every day switched on to
“maximum”. I’ve learnt to accept that I’m not always at my optimum. On these days, I break my
work into the smallest chunks I can and look for things to do that I really like doing. I know that
when I have these days if I don’t try to force concentration or berate myself for not being at my
“tippy top” things will be more or less back to normal the following day if not sometime during the
same day.
If I’m feeling overwhelmed, it is a sign to me that I have lost control in some way. That’s not a
great place to be in as it increases stress. Often people feel overwhelmed without realising what
they need is not that far from them, the answer they seek, the breakthrough is really close by. In
these circumstances I will step back and try to take a look from a distance (at times I physically step
back from my desk as a physical input). What do I think I am missing? Am I being paralysed by too
much information? This is one reason why I like mind maps - using them to create links between
information and ideas allows me to understand that there are trees and a forest. The uncluttered
presentation allows me to process complexity, process where I am and where I want to go.
Paul Seaman 88
I also like to talk to colleagues if I’m feeling overwhelmed. The simple act of sharing the problem and
your feelings helps bring down stress levels rapidly. Stress inhibits both creativity and information
processing so reducing stress levels is an instant win. When we vocalise we also process the
information and often find we can see connections we couldn’t make when the information was
in our head and scribbled in notes. There’s a reason for developers and their rubber ducks. More
than once I’ve had these conversations and experienced the decluttering effect and then found I did
have ways to move forward and remove the sense of being overwhelmed. The other benefit here, of
course, is that our colleagues often have useful ideas, information and tactics that we were unaware
of which may help me feel better equipped to tackle the problem and resume control.
Paul’s bio
I’ve been a professional tester for close to two decades. It is the longest career role I have ever
held and it’s been that way because I get immense satisfaction from testing and the opportunities it
provides.
I am currently working as a Senior Test Analyst at Halaxy¹⁷⁹. I’ve worked in large corporates, large
government businesses, smallish start ups and a few things in-between. I’ve met some amazing
people through testing and travelled interstate and internationally for testing jobs.
I’ve been able to contribute to the testing community through helping establish a meetup group,
co-organising testing conferences, and authoring articles for testing magazines. I’ve provided
review and editing services to several testing magazines (a role I really enjoyed) and blog at
https://beaglesays.blog/about-beaglesays/¹⁸⁰. My favourite community contribution is co-founding
the EPIC TestAbility Academy, an endeavour that taught software testing skills to unemployed,
young adults with autism, with the aim of finding them employment in IT companies.
¹⁷⁹https://www.halaxy.com/
¹⁸⁰https://beaglesays.blog/about-beaglesays/
Amanda Shankle-Knowlton
“I think about risk all the time.”
“Know that a dedicated career in testing isn’t always respected.”
“I’ve become better at saying no to things that neither help me develop a skill I want to develop or
benefit the world or a friend in a sufficiently positive way.”
Amanda came onto my radar when Dell (who had acquired

Quest in 2016) acquired Statistica, where she had worked for
some time as a tester. She showed interest in the more modern
testing approaches I was advocating in the business and it was a
shame I didn’t get the chance to visit the Statistica team to meet
Amanda in person. I’ve enjoyed following her writing around
testing (and life in general) on her blog¹⁸¹ - and I love her LinkedIn
profile tagline, “Minimizer of chaos. Solver of problems. Asker of
questions. In software and beyond”!
Realizing that testing could leverage my anxiety for professional gain. I think “what if X happens
which may lead to Y awful consequence” all day anyway - why not get paid for it
I think about risk all the time. If I’m outside somewhere rustic my mind floods with questions - are
there ticks, are there holes I can twist my ankles in, can we call 911 emergency services from here?
On my path of just getting out of bed every day there has been a lot of professional training -
exploring the space I’m in, the possible threats, and how to quickly figure out what’s most important.
Then reaching a point where I’m comfortable enough to relax and say “from what I can see, this
camping area is free of obvious risks - let’s enjoy!”
When I realized that the first job I took out of college wasn’t what I wanted to do forever, I started
taking classes at my nearby community college. I learned some basics of C#, Java, Unix, and C. These
courses helped me get comfortable at the command line and gave me exposure to a few different
IDEs. I also took a Junior level Computer Science course at a local four-year university. Learning
floating point math has helped me understand a lot of the problems I am exposed to at work - and
plus knowing what happens at the register level is a good ego boost.
Having these courses on my resume got my foot in the door in IT so that I could make a career shift.
¹⁸¹http://amandashankleknowlton.blogspot.com/
Amanda Shankle-Knowlton 90
Know that a dedicated career in testing isn’t always respected. Sometimes it seems like it exists to
have someone to throw under the bus if things go wrong after the release.
You need to be selective about the organization you choose to work in. Is testing infused throughout
the process? Is asking thoughtful questions when a project starts as valued as the last minute heroics
of getting a sloppily planned release out to meet a deadline?
Be technical. Think of efficient ways to do things, whether it’s scripting things that frequently need
to be checked exhaustively or taking a risk-based approach to designing tests that matter most.
Know what the trends are in your job market (location or sector). Is the trend to hire entry level in
lower salary parts of the world? Don’t just learn the mechanics of programming or testing - learn
the problems that are facing industries that are interesting to you and put your technology skills in
service to solving those problems.
how?
Scheduling 10 hours of “Be At Home” time during waking hours each week; it helps me avoid
overscheduling myself in a world where there is so much to go out and do.
Both personally and professionally Mindset: The New Psychology of Success¹⁸² by Carol Dweck
has been a life changer. It inspired me to embrace struggle as a means of growing my skills and
knowledge.
Lessons Learned in Software Testing: A Context-Driven Approach¹⁸³ (Cem Kaner, James Bach & Bret
Pettichord) has the quote “Be a volunteer, not a victim” - I’ve incorporated this into my approach to
working extra hours professionally.
Essentially, I evaluate whether this invitation (or game or social media app) is strengthening a
relationship or skill, acting as an appropriate incentive to a larger goal, or in general something
that I’d like to remember having done when I’m 90.
I’ve become better at saying no to things that neither help me develop a skill I want to develop or
benefit the world or a friend in a sufficiently positive way. Things like organizing fundraisers to pay
for supplementary activities for already-well-off children. Nope, these kids will be fine without my
help here. Activities and meetings that aren’t sufficiently valuable give me less time to do things
that matter.
¹⁸²https://www.amazon.com/Mindset-Psychology-Carol-S-Dweck/dp/0345472322
¹⁸³https://www.wiley.com/en-gb/Lessons+Learned+in+Software+Testing%3A+A+Context+Driven+Approach-p-9780471081128
Amanda Shankle-Knowlton 91
do?
When I’m overwhelmed, I do a “five minute brain dump” where I open up a blank document in
a text editor where I list all of the things on my mind. I typically reflect on my big goals in life -
making sure I have strong connections with family, making sure I am taking care of my physical
health, and using my skills to make the world better in at least a small way.
If that doesn’t do the trick, a ten minute walk is usually a good reset.
Amanda’s bio
I grew up in Moore, Oklahoma, USA and moved to Tulsa, Oklahoma USA in 2002.
I’ve worked in the software industry since 2005, primarily for the Statistica software product (owned
by StatSoft, then Dell, then Quest, then TIBCO). I’ve served in a variety of roles on the team, most
recently as our Quality Assurance Manager since 2017. My goals have been modernizing our testing
process and building skills on the team that both help our business and help the team members grow
in areas they care about.
I live with my husband, daughter, and dogs. I enjoy reading, volunteering for organizations that
strengthen democracy, singing, bowling, and cross-stitch.
Aleksandar Simic
“Sometimes it can be hard to recognize that the way we are doing things is the way somebody else
defined for us.”
“I am learning how to stop monitoring all those channels and focus on things that matter to me.”
“I would be worried to think or start thinking that my biggest failure already happened.”
I was fortunate to attend the Cambridge Exploratory Workshop on

Testing (CEWT)¹⁸⁴ during an extended period in the UK in 2016
and I met Aleksandar at this workshop. His talk at the workshop
revealed an impressive degree of self-inspection and I liked the
way he was deliberate in naming his various testing activities. I
think Aleksandar’s answers again reveal his natural tendency for
self-inspection.
I have only a vague memory of how it happened, but one morning
my boss at that time asked me if I want to be a tester and/or help
to build the test team.
It was a time when our small company was struggling and had to reposition itself in the market
- and the first offer we got was to start with a pilot testing project. That project and the work we
initially did opened the door for other projects and helped the company to survive that period.
I don’t remember if I said “Yes” to my boss right away or I asked for some time to think about it, but
I am still in testing after almost fifteen years.
I am not going to pick one event or course, but I heavily invested my energy, time and money
attending or participating in classes, workshops and conferences onsite and online for about five
years.
If I am not wrong, it all started with Black Box Software Testing (BBST)¹⁸⁵ classes and culminated
with a trip to participate in both the Problem Solving Leadership¹⁸⁶ course and CAST¹⁸⁷ conference,
but it would be unfair not to mention a few others: Skype coaching sessions with James Bach, Anne-
Marie Charrett and Michael Bolton, the various Rapid Software Testing¹⁸⁸ classes and Let’s Test
¹⁸⁴https://therockertester.wordpress.com/2016/11/10/er-attending-the-cambridge-exploratory-workshop-on-testing-cewt/
¹⁸⁵https://associationforsoftwaretesting.org/bbst-black-box-software-testing-courses/
¹⁸⁶https://geraldmweinberg.com/PSL_Site/psl.PSL.logic.html
¹⁸⁷https://associationforsoftwaretesting.org/conference/
¹⁸⁸https://rapid-software-testing.com/
Aleksandar Simic 93
conferences in Sweden. On the other side, I assisted in running BBST classes as an instructor assistant
and these days I help with Rapid Software Testing Applied¹⁸⁹ classes.
If there is an event I would like to see come back, it’s definitely the Let’s Test conference in Sweden,
but I am not going to explain why here.
Well, I am not quite sure how I would answer this question as I’ve never been asked something
similar before. I don’t think I have a list of different advice to ignore.
It would be interesting to find more about someone’s motivation to enter the industry or testing,
and especially to find out why they think someone’s advice could be helpful to them.
I think it is all about different experiences. I haven’t changed companies very often, so my experience
is limited to those environments and cultures.
But, if I could give any advice, it would be something very simple. “Go and give it a try. See how it
works for you. Don’t judge by one place. Let’s talk whenever you have a need to discuss something.”
disagree with?
As I mentioned in my previous answer, I haven’t changed between many different companies, so I
don’t want to pretend I know what is happening in lots of other places.
Sometimes it can be hard to recognize that the way we are doing things is the way somebody else
defined for us, or that we are doing the things in a particular way, because we are constrained by a
specific tool.
I would rather suggest to constantly question the way we work - to step back and think if there is a
better way to achieve our goals.
I remember being in that kind of situation, and I remember it was not easy to introduce a change.
how?
I cannot say I am already there, but I am trying to reduce the set of interesting things that could
finish on my “To Do” list.
There are a lot of places and sources where you can get pointers to interesting reading, ideas, topics,
etc. but I had to realize I do not have time for all of them. These days I am trying to be more selective,
trying to find connecting points with my directions and goals. In general I am learning how to stop
monitoring all those channels and focus on things that matter to me.
Not an easy question, but I think there is one thing that I would consider interesting to try.
¹⁸⁹https://rapid-software-testing.com/rst-applied/
Aleksandar Simic 94
I think I spent a few years trying to figure out what testing is and I was trying to find out where and
from whom to get ideas about testing.
The only thing I would probably change is that early in my career I would look for a good mentor,
a coach, a peer or a colleague that could help me learn and grow as a tester.
I said I haven’t changed between a lot of companies, but I was changing projects, products and teams
very often.
In some way I was trying to understand very early what is there, where do we go and how I can
help. I am trying to learn quickly about the product and project, environment and infrastructure,
people and resources - anything that could help me to do “good enough” testing.
This is not a “one time” effort. You can get some general understanding, but then you have to fine
tune it as you go on different levels of detail.
Reading a book is somehow a personal, sometimes temporary experience. When we read a book, we
might get some ideas right or wrong, because of our attitudes and because of what we know at the
moment of reading. Unless we discuss the book with other people or we come to it later, we might
think we got the things right.
These days, I will visit most of the testing literature periodically when I am interested in specific
content or I find out that I have a problem to talk about or need to explain a specific topic. And I am
trying to read from more than one source. I have ideas or know where to look for a lot of relevant
resources.
If I need to pick a book, then that would be Testing Computer Software¹⁹⁰ (by Cem Kaner, Jack Falk
& Hung Q. Nguyen) because it was one of the first testing books in my library (if not the first) and
its first chapter demonstrated to me that testing even a simple program (like adding two numbers)
can be analyzed over a dozen pages.
important failure?
Hmm, I am not sure I can identify my most important failure right now.
But I would be worried to think or start thinking that my biggest failure already happened. I am
trying to be on guard for the very next mistake that could happen to me.
On the other hand, I am not sure I am able to catch all the mistakes I’m doing every now and then.
So, I am trying to stop myself occasionally to spend some time on closure activities, which includes
looking at recent activities in retrospect, instead of jumping into the next urgent task or activity.
¹⁹⁰https://www.wiley.com/en-au/Testing+Computer+Software%2C+2nd+Edition-p-9780471358466
Aleksandar Simic 95
I touched on the topic of distractions already (having a large “To Do” list), but as I say I know I am
still struggling with that. I am not sure If I can offer a lot, but I think when it come to thinking about
this kind of topic, I must say I am influenced by Johanna Rothman¹⁹¹’s ideas and writing from her
Create An Adaptable Life¹⁹² blog.
do?
My pretty instinctive reactions is to move from the desk (or computer) for a while and go find
someone to talk about anything. But this probably applies only for a temporary loss of focus.
If we are not talking about temporary state then it might be very different, so I will try to list a
couple of examples.
Sometimes you get into something and you cannot stop. You learn something new, which has
nothing with what you do in the office, and you might work kind of double shifts. It could be
that you don’t sleep enough. It might be hard to recognize until is too late that your body cannot
follow that rhythm. Then you need to adjust, get enough sleep and normalize the rhythm.
You could get into some personal issue that might affect the way you work. In those cases, it might
be better to talk with other people and try to find solution that will not put any side in danger.
Aleksandar’s bio
I changed between a few roles in the software industry before I got into software testing - and now
I could say that I am living for testing, and I am testing for a living.
I have about fifteen nice years in testing and, the more I learn about it, I know how much more I
need to learn. I try to find interesting events (mostly online these days) and learn something new,
but I also try to help others learn about software testing (e.g. Black Box Software Testing, Rapid
Software Testing Applied).
Testing brought me to different countries (from Croatia, then Germany, to UK), which adds an extra
flavour on top of the changes we all experience in software development on a regular basis.
When I am not testing, I try to force myself to stay away from a computer, and do some outdoor
activities.
¹⁹¹https://www.jrothman.com/
¹⁹²https://createadaptablelife.com/
Karo Stoltzenburg
“A lot of the key skills that I’ve learned in the humanities are incredibly valuable and transferable
to testing.”
“My number one piece of advice would be to keep an open mind.”
“I think the only failure that would be really hurtful would be to not accept failing as a part of
learning, and trying to hide your failures.”
During an extended visit to the UK in 2016, I was fortunate to

be invited to participate in CEWT¹⁹³, the Cambridge Exploratory
Workshop on Testing. It was a very enjoyable day spent interact-
ing with a group of testers from the Cambridge community, one
of whom was Karo. She gave an excellent talk at the workshop
and we enjoyed talking testing (and other things) over a drink
in a nearby pub after the event. Following Karo since then, it’s
been inspiring to see how much she’s continued to contribute to
the testing community, both locally in Cambridge and also more
generally. Although her Twitter bio reads “German, still baffled about queuing, roundabouts and
non-chilled beer”, Karo’s answers below are not baffling at all, but rather reflect her community-
mindedness and deep insights around our craft.
Most interesting I think is that, despite seeming irrelevant, my background in German Literature
has heaps of overlap with testing. A lot of the key skills that I’ve learned in the humanities are
incredibly valuable and transferable to testing: keeping an open mind and being able to respond to
context, applying and finding tools that fit the current need, being aware of different and diverse
perspectives, biases and backgrounds, diving into the unknown with a curious mind. Non-traditional
career paths into testing can work really well - diversity matters¹⁹⁴!
Hands down: getting involved in the testing community. I’ve been organizing the monthly Ministry
of Testing Meetup in Cambridge¹⁹⁵, which offers events with talks, workshops or activities to
help testers enhance their skills and testing knowledge and to support and connect the local
testing community. I have also been a host of the Software Testing Clinic, a curriculum of Testing
Essentials¹⁹⁶, and have run workshops and been speaking at conferences. It’s invaluable how much
¹⁹³https://therockertester.wordpress.com/2016/11/10/er-attending-the-cambridge-exploratory-workshop-on-testing-cewt/
¹⁹⁴https://putzerfisch.wordpress.com/2018/10/27/diversity-matters/
¹⁹⁵https://www.meetup.com/Ministry-of-Testing-Cambridge/
¹⁹⁶https://www.ministryoftesting.com/essentials
Karo Stoltzenburg 97
I’ve gained through this, personally and professionally - by meeting and engaging with others, by
getting insights into different testing-related topics and by formalizing my own knowledge and
expanding on it continuously. It’s incredibly rewarding and fun - the testing community is fantastic,
with a bunch of awesome people, and I’m really grateful that I have the opportunity to be a part of
it.
My number one piece of advice would be to keep an open mind. Not only are there lots of facets to
testing, every team and every project is different and has its own challenges. It’s worthwhile to stay
flexible, and to learn and respond kindly to whatever context you’ll find yourself in.
And for what to ignore: I’d advise to not let yourself be guided too much by stereotypes - especially
the negative ones about developer and tester relationships, features being thrown over the fence,
bug pingpong and the like. In the end, we’re all humans working with each other, and I cherish the
friends that I made in my career - developers, testers, stakeholders - they’re the best part.
disagree with?
I’m naturally wary of things that are absolute, with a claim to always work or a notion of “you must
do something a certain way, no questions allowed”. Although there are approaches that I’ve seen
work well and methods and ways of working that I’d call good practice, I’m conscious that it all
depends so much on the context you’re in, the people, the project, the structures. Similar to things I
might disagree with, I wonder if an approach I like less couldn’t actually work well in a particular
situation to solve a specific problem. It’s all a bit relative, really.
how?
To be more aware of what kind of activities suit me best when. As an example, I’m really productive
and concentrated in the early mornings. So I try to allocate this time for the most urgent and hairy
things that require my full attention - both for work as well as in my personal life. This way, I not
only get these things done in my best state of mind, but it also frees up my evenings and weekends
for activities that require less concentration and help me to unwind - listening to a podcast while
cooking, doing the dishes, going for a run or just enjoying being outside in nature. Of course that
all worked a lot better before I became a Mom, as now my one year old takes up my early mornings
with his unfailingly happy energy!
I think a good thing to remember is that nobody is perfect, nobody knows everything and everybody
will fail at some point and that that’s not a disaster at all. Thankfully, when I started out as a tester I
was working with some brilliant developers who really lived by that. They were not assuming that
they’d know everything, they treated others with respect, were openly and unashamedly asking
when they didn’t know something and were listening to any questions or suggestions that me or
other juniors voiced. This atmosphere of openness and transparency, the acceptance of failure as
something that will happen to everybody (and is nothing to be ashamed of but something to learn
from) was such a healthy environment to grow as a tester and really shaped my attitude going
forwards, not just as a tester, but for life in general.
I’ll provide just one: context. And that can mean the targeted user base, the space in which the
project operates, my own knowledge about the domain, the tech stack or the product, the skill level
of the people working or contributing, suitable tools and the type of tests that will help answer
the most pressing questions, what these most pressing questions are, the time and place, or even
environmental factors like humidity. All of these might be important… or not. Understanding what
matters, to whom, why and when is essential to plan, target, and conduct testing. Or in the words
of Rikard Edgren: “Testing is simple. You understand what is important and then you test it.”
When I started out as a tester I stumbled upon Lessons Learned in Software Testing¹⁹⁷ by Cem Kaner,
James Marcus Bach and Bret Pettichord. As I was the only tester in the company and didn’t know any
other testers, it was a revelation. So many lessons where I was rigorously nodding my head! I found
kinship in there and felt understood as a tester. It stayed with me throughout my career and every
once in a while I take it down and flick through it, and it’s still resonating and teaching me. It also led
to other great books that have taught me loads - Jerry Weinberg’s books like Perfect Software: And
Other Illusions about Testing¹⁹⁸ and Are your Lights On?¹⁹⁹ and Elisabeth Hendrickson’s Explore
It!²⁰⁰.
It’s more difficult to name specific books that have influenced my personal life - I’m an avid reader,
always have been and even taught Literature at university for a while, so books have paved my way
through life generally. I love the diversity of it and am constantly mixing up genres - from Crime to
Classics, Science Fiction, Poetry or Young Adult, I’m happy to explore and engage.
important failure?
I fail pretty much every day. Some failures hurt a bit more, some I understand better. Some are
easier to take as opportunities to learn from and some occupy my mind for a while before I know
how to properly digest them. I’m trying to take it as a natural and actually healthy part of living
and growing - I think the only failure that would be really hurtful would be to not accept failing as
a part of learning, and trying to hide your failures. And in that sense, every failure is an important
step, a set up to later success and a part of my learning path.
¹⁹⁷https://www.wiley.com/en-au/Lessons+Learned+in+Software+Testing:+A+Context+Driven+Approach-p-9780471081128
¹⁹⁸https://geraldmweinberg.com/Site/Perfect_Software.html
¹⁹⁹https://leanpub.com/areyourlightson
²⁰⁰https://pragprog.com/titles/ehxta/explore-it/
A quote has helped: “Saying Yes to Something Means Saying No to Something Else”. Simple, but true!
And as time and energy are limiting the number of things that are feasible to do, it’s worth focusing
on the ones that I really want to say yes to that I’m convinced are important and worthwhile. And
sometimes other things are no longer as important or urgent as originally thought.
What also helps is to make time for activities that boost energy instead of just dragging me down
in a hamster wheel - exercising, spending time outside in nature, and making sure I have windows
where I can really unwind all give me more energy and motivation and help me in turn to tackle
things more efficiently. Literally a win-win.
do?
Stepping back usually works for me. I even had a Post-it with these words written on it stuck to my
screen for a while. When I get lost, I try to consciously step back from what I’ve been doing. I then
recap where I am and in order to find out what to do next, where to go, I use the rule of three - I
try to find three different ways or approaches. This helps me to take stock, but also sets off a lot
of creative energy and helps to unblock me mentally. And if that doesn’t help either, I literally step
back and take a short break, get a coffee or some fresh air to blow out the cobwebs.
Karo’s bio
Originally from Munich (Germany), Karo now works as a Senior Test Engineer in Cambridge (UK)
for Linguamatics, which provides NLP text mining software in the life science and healthcare
domain. Before joining the test team at Linguamatics, she worked in different industries on E-
commerce platforms, web applications and supply chain management solutions, often as the sole
tester and in both agile and waterfall environments.
She loves that testing is such a diverse, creative, and challenging activity and cherishes the
opportunities for collaboration with other roles in the software development life cycle that come
with it. Karo channels her urge to discuss and share anything testing as organizer of the Ministry
of Testing group in Cambridge, as host of the Software Testing Clinic, a curriculum on Testing
Essentials, and as a regular at the Cambridge Exploratory Workshop on Testing²⁰¹. She blogs at
http://putzerfisch.wordpress.com²⁰². Find and engage with her on Twitter: @karostol²⁰³.
²⁰¹https://cewtblog.blogspot.com/
²⁰²http://putzerfisch.wordpress.com
²⁰³https://twitter.com/karostol
James Thomas
“In hindsight I find it strange now, but there was a period of my career where I didn’t consider that
learning for work was something I could think about doing outside of work.”
“I would say that learning to become comfortable with uncertainty will take you a long way in
testing.”
“I feel incredibly lucky that I happened across context-driven testing when I started.”
I’d been following James for a while on social media (for his
puns as much as his commentary on testing) and through his
blog (for deep thinking on testing) before I finally met him in
2016. He’s a very community-minded tester and an advocate of
context-driven testing, and it’s been great to see the Cambridge
Exploratory Workshop on Testing (CEWT²⁰⁴) develop over the
years under James’s guidance. During a long stint in the UK in
2016, I was fortunate to be invited to participate in CEWT²⁰⁵
and had a great day meeting James and other testers from the
Cambridge community.
Before I started testing I hadn’t knowingly met a software tester but I had done a load of different
roles at my company, including sales, technical writing, software development, customer support,
and director. Becoming the first and only tester was an interesting experience, not least because I
had to find for myself what testing was, or needed to be, in the company at the time.
My view of that context was enhanced by the perspectives on our product and the challenges of the
roles that I’d seen previously. I’m extremely grateful to have experienced them because it helps me
to have empathy for people in other parts of the company when we’re discussing our products, and
to remember that the software isn’t all that the business is.
It’s perhaps meta, but taking the decision to invest in my learning for work was the best investment I
made. In hindsight I find it strange now, but there was a period of my career where I didn’t consider
that learning for work was something I could think about doing outside of work. It’s particularly
intriguing because I was working at a startup and spending an enormous amount of time outside
²⁰⁴https://cewtblog.blogspot.com/p/about-cewt.html
²⁰⁵https://therockertester.wordpress.com/2016/11/10/er-attending-the-cambridge-exploratory-workshop-on-testing-cewt/
James Thomas 101
of the office doing work. Not only that, but I had a background in research from my PhD. I was
perfectly capable of it.
That’s not to say that I didn’t learn, but I was driven to learn the thing I needed to know right then
for the problem in front of me. If I’m honest, “learn” is probably a kind description of what I was
doing, which was looking on Usenet for answers I could copy and hack into something useful. I’d
say it was shallow learning at best.
My perspective was changed at about the point I took on a testing role, when the development
manager that replaced me started referencing things that he’d read. He was more experienced than
me and so had more situations to draw on. But he also had a wide view that came from reading
around. He knew about things that he hadn’t experienced directly, about things in principle, and
about analogous scenarios, all of which proved useful.
I took a leaf from his book, and then took it further by starting to blog and then to get involved in
local, national, and international testing communities. From there, I’ve learned a great deal about
how other people work, and I’ve brought that second-hand experience back to my own team, trying
some things out, leaving others aside.
I would say that learning to become comfortable with uncertainty will take you a long way in testing.
I suffered in my early days as a tester from trying to nail all the details down. I learned that, while
it might be possible, it’s often undesirable to have a rigid view of what we’re attempting because
it can adversely influence what we achieve or the ease with which we’re prepared to pivot when
things aren’t working.
For IT in general, I’d suggest thinking about the human side of work. Being technical is not all about
deterministic things. Software is built and used by humans. Acting with empathy, understanding,
and openness can make relationships with your colleagues so much easier and more collaborative.
disagree with?
It’d be easy to flog some dead horses here: certifications, the false dichotomy of manual vs automated
testing, or a continued perception of testers as being responsible for quality.
I don’t think I have the energy for that kind of thing, so I’ll answer a slightly different question
instead. One of the things that never ceases to dismay me in testers (and software development
teams more generally) is a fixed mindset.
how?
Blogging has made me stop and think about what I do, and provides a way to remember what I
think, or perhaps what I thought previously. Writing helps me to get ideas straight in my head. I
find them easier to challenge when I’ve had to write them down, for two reasons: first, I need to be
clear what I actually do think and, second, I can treat them as external once they are on the page,
and feel freer to find fault with them.
James Thomas 102
I feel incredibly lucky that I happened across context-driven testing when I started. It accorded with
my intuition about how I wanted to test. If I could change one thing it would be to focus less on trying
to squash uncertainty before I started testing. As a tester I can provide value by finding potential
incongruity inside a space of possible implementations, not just by finding that some specific success
criteria hasn’t been met.
Here’s three:
• The expertise of the team in the domain, or in the technology, or in the task. (I include me in
the team.)
• The extent to which there is agreement on the scope of the project.
• The testing that’s already been done.
• Lessons Learned in Software Testing: A Context-Driven Approach²⁰⁶ by Cem Kaner, James

Bach, and Bret Pettichord
• Perfect Software: And Other Illusions About Testing²⁰⁷ by Gerald Weinberg
• Are Your Lights On? How to Figure Out What the Problem Really Is²⁰⁸ by Donald Gause and
Gerald Weinberg
• What Did You Say? The Art of Giving and Receiving Feedback²⁰⁹ by Charles Seashore, Edith
Whitfield Seashore, and Gerald Weinberg
• Extreme Programming Adventures in C#²¹⁰ by Ronald Jeffries
• Managing Humans: Biting and Humorous Tales of a Software Engineering Manager²¹¹ by
Michael Lopp
important failure?
While I was working at a startup I needed to send email to all of our customers. At that stage we
were still focussing on building our product and hadn’t invested in any kind of CRM infrastructure
so customer emails were sent from a regular email client using a list that was copy-pasted from a
shared address book.
²⁰⁶https://www.wiley.com/en-gb/Lessons+Learned+in+Software+Testing%3A+A+Context+Driven+Approach-p-9780471081128
²⁰⁷https://www.amazon.com.au/Perfect-Software-Other-Illusions-Testing/dp/0932633692
²⁰⁸https://www.amazon.com.au/Are-Your-Lights-Figure-Problem/dp/0932633161
²⁰⁹https://www.amazon.com/What-Did-Giving-Receiving-Feedback/dp/0965043002
²¹⁰https://www.amazon.com/Extreme-Programming-Adventures-Developer-Reference/dp/0735619492
²¹¹https://www.amazon.com.au/Managing-Humans-Biting-Humorous-Software/dp/1430243147
James Thomas 103
I was busy, and trying to do two things at once, and didn’t give sufficient attention to the email.
Until it arrived back in my inbox, that is, and I realised that I had cc-ed all of our customers instead
of bcc-ing them. Then it got a lot of my attention.
What did I learn? Don’t try to do two things at once. Instead, decide on the right amount of time to
assign to the tasks and do them one after another.
These days, I am more able to say no to overcommitting myself. I do this by timeboxing and
prioritising. In the past I would often be so keen to “do a good job” that I’d put my own time in
to achieve it. Now I have reframed doing a good job to mean using my skills and experience to get
a good outcome for the stakeholders at a reasonable cost, in the time available.
do?
I write. The act of writing forces me to focus. That’s not to say I can sit down to start writing and
insight just streams out of my head through my fingers. I’ll often create a document and just drop
thoughts into it as I have them. Over time, I can being to organise the thoughts, and the organisation
gives me feedback about what I’m thinking, perhaps clarifies it, or helps me to notice angles that I
haven’t seen before, or just stops the thoughts going round in my mind so much.
James’s bio
James Thomas is one of the founders of Linguamatics²¹², the world leader in innovative natural
language-based text mining. Over the years he’s had many roles in the company, including developer,
technical author, and tech support. He is currently the test manager, a position in which he strives to
provide an environment where his testers have an opportunity to do their best work. He’s on Twitter
as @qahiccupps²¹³ and blogs at Hiccupps²¹⁴.
²¹²https://www.linguamatics.com/
²¹³https://twitter.com/qahiccupps
²¹⁴https://qahiccupps.blogspot.com/
Toby Thompson
“Testers need to be investigators, explorers, questioners and critical thinkers in order to broker strong
relationships between the business and technical sides of an organisation.”
“You need to understand the difference between Value and Quality.”
“I am just like everyone else - vulnerable, smart, stupid, confident.”
I was fortunate to be introduced to Toby many years ago and

remember the first time we caught up for a coffee. It turned out
that we had followed similar paths, both moving to Melbourne
from the UK and both being heavily involved in the testing indus-
try and community. His keen interest in music also immediately
marked him out as a good bloke! We both share a passion for
exploratory testing, especially in improving the awareness and
education around what good exploratory testing looks like and
the great benefits it can bring. Toby’s a gifted and natural teacher
and I see this reflected strongly in his responses to the questions
for this book.
Learning about psychology, design thinking, questioning the words and language we use, question-
ing the assumptions people make, understanding biases and prejudices, using mental models, being
curious. Ultimately it boils down to a never-ending quest for learning and being a critical thinker. I
chose to teach about the testing profession and to be a mentor and coach to newbie testers - many
have gone on to have very successful testing careers. Teaching, Mentoring and Coaching are great
ways to learn and to help others learn. I don’t think you can be a very effective tester without some
critical thinking skills and without empathy for those that use the products you build. Having tunnel-
vision prevents you from making products that are suitable and valuable to those who use them. I
believe that testers shouldn’t pigeon-hole their role - they should be masters of many skills and they
should seek to be as useful to a ‘development’ team as possible.
I like the concept of exploratory testing - essentially you’d expect most testers to explore naturally -
the products we test are not one dimensional, so we should be evaluating the many different ways
that they can be used as well as how they are actually used in the field.
Starting my own company from scratch and building a network of friends and practitioners and
clients over a decade. It was a tough endeavour with its rewards and downsides. The learning was
invaluable - having a small business you learn about sales, marketing, being customer-centric, about
Toby Thompson 105
strategy and focus and about thrift and hard work. If you don’t have a connection with the customer
or the ‘business’ then you’ll have very little idea about how to test effectively.
Testing is everything and should be part of everyone’s role - it is the glue that holds products and
systems together, it is complex and it involves so many different variables and permutations and
characteristics - I think the word ‘testing’ is as broad as the word ‘agile’ - so I would investigate
the type of testing you’d be interested in: be it a form of integration testing, security testing, user
acceptance testing, performance testing, accessibility and usability testing and so on.
Ignore the advice to automate everything!
disagree with?
Anything that suggests that there is one correct way to approach testing - it is all about context.
You need to look outside the box - you need to have empathy with both the delivery team and your
customers and test with them in mind, you need to understand the difference between Value and
Quality. It’s all very well making a product that complies exactly with the proposed requirements
but it’s another thing that users find the product valuable in any way. How does the product solve
problems for the myriads of user types rather than how does this requirement match the test (s) I’ve
written for it. Then as far as quality is concerned - most users expect things to just work exactly
as described on the product’s label - easy to use, fast, secure, reliable, portable, interoperable and
whatever else is expected from a compliance and expectations perspective. Many of these attributes
are often overlooked and deemed out of scope because they aren’t specified explicitly. They are also
often critical to the success of the product.
The job of a tester is to seriously analyse and evaluate the value being provided to users and also
to ascertain whether or not the many dimensions of quality are being considered and to help reveal
the risks and limitations of the product as expediently as possible. This means that testers need to
be investigators, explorers, questioners and critical thinkers, as well as excellent communicators, in
order to broker strong relationships between the business and technical sides of an organisation.
how?
Kata - practice bit by bit over time to engrain new habits and behaviours - most new learning takes
time and practice - I always start small and aim for bigger goals to be achieved over time. BJ Fogg’s
Tiny Habits and Behaviour Model²¹⁵ and Mike Rother’s Toyota Kata²¹⁶ have shown me that we learn
in tiny increments using repeating patterns to gradually change our behaviours by unlearning old
habits and replacing them with new ones. This coupled with my love for learning and applying
critical thinking allows me to view the world with less bias and prejudice and helps me make
informed and educated decisions. I’ve helped people look at the world from multiple perspectives to
²¹⁵https://www.tinyhabits.com/
²¹⁶https://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238
Toby Thompson 106
help them appreciate reality rather than their narrow take on the world and thus guide them out of
groupthink or opinion guided work. Testing is really about truly understanding what the problem is
that you’re solving - generally that’s why we build software - so we need to keep asking questions
and understand what value we as a team are providing our users and customers.
The difference between Quality and Value. The difference between Output and Outcome. The
importance of the end-user and customer. I would have fought harder to get in front of users.
Protocols like “you don’t need to speak to the customer, we have requirements” always irked me.
Gaming - Y2K: Due to a severe lack of up-to-date documentation to inform us of what the various
systems were expected to do, this was a largely ‘sit with the users and use the domain experts’
approach to testing. There was heaps of hardware and software and major and minor systems and
we tested all the systems in descending order of criticality. We used a risk-based approach to which
systems (e.g. lotteries) we would focus on and start with and then a similar risk-based approach to
the features and non-functional characteristics of each of the systems.
We set up a testing structure to support our reporting structure - we engaged stakeholders early
and bought them along the journey. As they were actively engaged at the beginning of the project
and they understood the risks from a product (quality) and project perspective we were able
communicate effectively and build trust around what we were testing and report results in a way
that the various stakeholders involved could understand and act on in a meaningful way.
We were very transparent with everything we did and called out risks as they arose and dealt with
them accordingly. This was a highly structured approach with no expense spared and as a result
the testing was successful with minimal failures once we entered the new millennium. There were
thousands of defects found and resolved of various severities and we were able to produce relevant
and up-to-date documentation of the systems as well as thoroughly test the systems to ensure a
successful outcome. We worked a lot with machines, kiosks, scratchy cards, logistics systems as well
as disaster recovery and end of day and start of day batch procedures. This was a huge undertaking
that started a couple of years prior to the year 2000.
Retail - GST : This was a completely different experience - little time was afforded to this project
- we were given a few months to test the new Goods and Services Tax (GST) and that was for a
national retail chain. The major constraint here was time. There was a lot less focus on building
prescriptive tests that could be run by anyone and more on getting the basics right and then using
knowledgeable users to test the system. Another constraint was the ambiguity of how the new GST
was to be applied - no one could agree on how the legislation affected the systems and therefore
there were delays on testing due to not knowing how to verify and validate compliance. Another
major issue was how things were communicated between the business and various vendors - there
were no requirements per se - rather requests were made of the vendors via email. The emails in
Toby Thompson 107
question were poorly written and resulted in a lot of back and forth misunderstanding between
multiple parties.
With time being a valuable commodity, I urged everyone to start collaborating - there were several
hostile parties, egos, and different agendas involved and a lot of my work was about getting these
parties to communicate regularly so that we could actually get the testing finished on time. I came to
the realisation that without proper validation and without a central point of communication (namely
the testing function), then this would have been a complete disaster. This is why testing is so pivotal
and becomes the glue that helps achieve greater business outcomes if done properly.
Publishing and Advertising - Integration: This was an example of a host of different consultancies
working for a particular company. Everyone had their siloed role and each consultancy was keen
on getting as much business from the company as possible. This is when I realised that I didn’t
want to work for a consultancy ever again. One particular experience had me sitting at my desk for
months on end ‘looking busy’ - I would have been charged out at a premium and achieved nothing
for the company we were contracted to work for - but I was ‘billable’ to the consultancy I worked
for. I experienced the worst kind of ‘do as your told’ management, and this was really a catalyst
for me to go out on my own. Once again where we achieved success was when all the right people
collaborated, and I was often the conduit to get people in a room to make sure we were all on the
same page.
Stockbroking - Green-field product - Agile Team: This started out very shakily indeed - with the
development team having little concept of structured testing approaches and also where the ‘IT
department’ made the decisions and the business were the recipients of such decisions in the form
of the products they built, with very little in the way of interaction between the two groups.
Initially the business were scathing of anything related to IT. This was because IT never really
communicated with the business and never truly understood what the business needed to get their
day to day jobs done.
Enter what we now know as an ‘agile’ way of working. Without all the agile jargon that pervades
the industry we started to work in a different way - we started to collaborate regularly, get stuff in
front of the business and get feedback regularly, we got the business involved and kept them in the
loop and made what we did very transparent, we forged strong relationships and represented the
business through our work. We used technology to support our quest and we had an amazing team.
I suppose the biggest factor and learning from this experience was that I have never been truly
satisfied with the title ‘tester’ and I think it really belittles the extent of what is required to make
sure systems work well (quality) and are fit for purpose (value) - so these were some of the key
aspects of my role other than the day to day testing:
• Marriage broker between IT (the builders) and the business (the users and customers) - for
some reason, initially, these two entities were unable to communicate effectively - I became
the conduit between the two and ensured a healthy and happy dialogue ensued.
• Sales guy - I had to do a lot of sales in terms of why testing was important and how it helped
deliver great business outcomes expediently.
Toby Thompson 108
• Trusted Advisor - the values that I abide by always are integrity, respect and courage.
• Confidante and friend - the favourite part of my role and key to really being successful - you
need to understand what makes all the humans you interact with on a daily basis tick and you
need to be reliable and dependable and working to get the best outcomes for the group as a
whole.
These are a small glimpse into the work I’ve done in the past and how I’ve been influenced by them.
There’s so much more to the activity of ‘testing’ and really it should be just one aspect to your daily
work. Soft skills are as crucial as technical skills.
Thinking Fast and Slow²¹⁷ by Daniel Kahneman - that applies to both tester and personal life - and
Siddhartha²¹⁸ by Hermann Hesse which was an influential and enlightening read during my early
twenties. Also Flow²¹⁹ by Mihaly Csikszentmihalyi.
important failure?
I am constantly failing and constantly learning - I don’t see this as a one off thing - I think that if I
stop learning something new, or adapting the way I might approach things, or being curious about
everything around me, or if I stop asking questions or being interested in other people’s lives and
ideas then that will be the true failure. Failure is not really a word I use; it is too one dimensional
and that’s not what I am.
I am just like everyone else - vulnerable, smart, stupid, confident… if you catch my drift!
Anything that I believe is not valuable and that distracts me from something that is. I often get asked
to do certain things at my work and as painful and difficult as it is, I say No for the above reason.
do?
Go for a walk; play my guitar, look out the window!
Toby’s bio
Toby Thompson has a broad portfolio of skills cultivated from a 25-year career working in both
business and technology. His roles include Business Owner, Managing Director, Practice Lead,
Trainer, Teacher, Facilitator, Mentor, Coach, Test Consultant, Account Manager, Project Manager,
Product Owner and Business Analyst.
²¹⁷https://www.amazon.com/Thinking-Fast-Slow-Daniel-Kahneman/dp/0374533555
²¹⁸https://www.amazon.com/Siddhartha-Novel-Hermann-Hesse/dp/0553208845
²¹⁹https://www.amazon.com/Flow-Psychology-Experience-Perennial-Classics/dp/0061339202
Toby Thompson 109
For more than 15 years he specialised in the Software Testing Domain; working as a consultant and
educator. He has been a principal trainer and consultant across many industry sectors including
finance, banking, stockbroking, telecommunications, retail, publishing and advertising and utilities.
In 2005, he founded a software testing training and consulting business. Whilst growing the business
he adopted lean and design thinking practices to reduce waste, streamline processes, experiment
with products and services in order to satisfy his customers’ ever-changing needs. The company
was acquired by SoftEd²²⁰ in 2014 and he joined as Practice Lead specialising in Software Testing
and has since diversified across multiple domains. His current role is Testing and Agility Senior
Knowledge Engineer.
In the last decade 2010-2020, he has continuously expanded his repertoire - away from domain
specialisation and into a world of continuous learning via the ever-changing landscape of lean, agile,
and design thinking that pervades the modern world of work.
He is not tied to one school of thought when it comes to the buzz around all things agile - he looks at
the ideas and tries to understand the context in which they may derive value. He has worked closely
with tier one organisations assisting them with their transformations and helping their employees
and stakeholders join the dots and understand why the change in their way of work is so critical.
²²⁰https://www.softed.com
About the author
In the IT industry since 1996 in both development and testing
roles, Lee has spent most of his career helping Quest Software²²¹
teams across the world to improve the way they build, test and
deliver software. He currently helps teams and organizations to
improve their testing and quality practices through his software
testing consultancy, Dr Lee Consulting²²².
Lee considers that his testing career really started in 2007 after
attending Rapid Software Testing with Michael Bolton²²³.
Lee was the co-founder of the TEAM meetup group in Melbourne
and co-organized the Australian Testing Days 2016 conference. He was the Program Chair for the
CASTx18 testing conference in Melbourne and also co-organized Testing in Context Conference
Australia 2019.
He is a co-founder of the EPIC TestAbility Academy, a software testing training programme for
young adults on the autism spectrum.
He is a frequent speaker at international testing conferences and blogs on testing at Rockin’ And
Testing All Over The World²²⁴. When not testing, Lee is an avid follower of the UK rock band, Status
Quo; hence his Twitter handle @therockertester²²⁵.
²²¹https://www.quest.com
²²²https://www.drleeconsulting.com.au
²²³https://www.developsense.com
²²⁴https://therockertester.wordpress.com/
²²⁵https://twitter.com/therockertester

An Exploration of Testers

Uploaded by

Document Information

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

An Exploration of Testers

Uploaded by

Copyright:

Available Formats

An Exploration of Testers

This version was published on 2021-09-03

© 2019 - 2021 Lee Hawkins

Preface and acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Ilari Henrik Aegerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

James Thomas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Toby Thompson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

About the author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Tweet this book!

I’ve enjoyed Ilari’s company at many testing conferences over the

• Many of Jerry Weinberg¹⁴’s books for their general wisdom

Influenced in personal life:

Little did I know that an in-house software testing training

Contact Michael at michael@developsense.com²⁵, on Twitter @michaelbolton²⁶, or through his Web

My various travels around the world for work and conferences

I immediately found a welcoming community in Jerry’s SHAPE (Software as a Human Activity

When it comes to respected members of the software testing

• Customer Oriented Software Quality Assurance⁴² by Frank P. Ginac

• On Dialogue⁵² by David Bohm

• Rising Strong⁵³, Daring Greatly⁵⁴ and Dare to Lead⁵⁵ by Brené Brown

I first met James at the EuroSTAR conference in Dublin back in

I used to regularly attend the ANZTB⁶⁷’s “Special Interest Group

• Consider taking one of the training courses mentioned in my previous answer.

It was a lucky break that led to meeting James when he submitted

Experience with this user or set of users

Investing both time and money in self-education.

Fail: to fall short of success or achievement in something expected, attempted, desired, or

• Freakonomics¹⁰³ by Steven Levitt & Stephen Dubner

• Weinberg On Writing: The Fieldstone Method¹¹⁰ by Gerald M. Weinberg

• Secrets of a Buccaneer Scholar¹¹¹ by James Bach

• Tap Into Mobile Application Testing¹¹² by Jonathan Kohl

It was through co-organizing a testing meetup group in Mel-

It was amongst the throngs of the ISTQB certification mob that

• The Book of Mormon¹³⁸

I first met Rob at the OZWST¹⁵³ testing peer conference in Sydney

• Learn story telling.

I first met Paul as a result of co-founding and organizing the

Amanda came onto my radar when Dell (who had acquired

I was fortunate to attend the Cambridge Exploratory Workshop on

During an extended visit to the UK in 2016, I was fortunate to

• Lessons Learned in Software Testing: A Context-Driven Approach²⁰⁶ by Cem Kaner, James

I was fortunate to be introduced to Toby many years ago and

You might also like