PDF eBook Automation Awesomeness

AUTOMATION
AWESOMENESS
260 actionable affirmations
to improve your QA and
automation testing skills
joe
co
io
l
n
anto
Automation Awesomeness
Copyright © 2023 by Joe Colantonio.
All rights reserved.
No part of this publication, Automation Awesomeness: 260

Actionable Affirmations to Improve Your Testing and Automation
Skills, may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without
the prior written permission of the author, Joe Colantonio,
and the publisher, TestGuild Press.
The author and publisher have made every effort to ensure the
accuracy of the information contained within this book. However,
they assume no responsibility for errors, inaccuracies, or omissions.
If advice concerning legal or related matters is needed, the
services of a fully qualified professional should be sought.
For more information visit www.testguild.com
TestGuild Press
Book cover design by Joe Colantonio
Book design, formatting and interior illustrations by

Gareth Southwell (art.garethsouthwell.com)
First Edition
ISBN (paperback): 979-8-9883354-0-5

ISBN (ebook): 979-8-9883354-1-2
Printed in the United States

To Emma
My mom once told me, “You don’t say much, but when you do,
you really stick your foot in your mouth.” (LOL!) So, following
my mom’s advice, in this book I only highlight actionable
automation advice from other experts I’ve interviewed over
the years, as opposed to my own. :)
The style of this book was inspired by For Today, published by

Overeaters Anonymous. In the early 1990s, I would read it to
my mother each day in my best Stuart Smalley voice. (Check
out SNL if you don’t know who I’m talking about.)
Acknowledgments
I want to give a big shout-out to Sauce Labs for being a sponsor of the Test-
Guild Automation podcast since 2014, and to SmartBear for sponsoring the
TestGuild Performance and SRE podcast since 2019. Y’all have been instru-
mental in helping us bring valuable insights and information to our listeners.
We couldn’t have done it without you!
A huge thank-you also to all the amazing guests we’ve had on our shows
over the years—at more than 500, there are just too many to name! We
appreciate every one of you for taking the time to share your knowledge and
expertise with us. Your contributions have made our podcasts a valuable
resource for the testing and automation community.
Foreword
Angie Jones, Automation Architect
As I sat down to read Automation Awesomeness, I couldn’t help but be

reminded of my own journey into the world of test automation.
My first job out of college was as an Automation Engineer. But there was
one big problem: I knew nothing about building quality software. I remember
the first time I saw a script execute a test case on its own. A lightbulb went off,
and I immediately recognized how much of a force multiplier test automation
could be for the software development industry.
But as much as I was excited about the possibilities, I was also intimidated
by the sheer amount of knowledge I needed to acquire to become a profi-
cient automation engineer. I didn’t just want to be good. I wanted to be one of
the best.
And that’s where Automation Awesomeness comes in. The TestGuild
Automation Testing Podcast has been such an integral part of my career
development. It’s the place where I tune in to keep up to date with the latest
industry news. It’s the show that afforded me my first podcast interview. It’s
my weekly dose of actionable advice to better my craft.
What a treat to have a compilation of 260 affirmations right at your finger-
tips. Little nuggets of wisdom from some of the most experienced automators
in the world! It’s like having them all as personal mentors by your side, guiding
you through the complexities of automated testing.
These bite-size affirmations are accessible, and easy to understand and
apply. Focusing on just one affirmation a week gives you five years of action-
able advice that you can incorporate into your daily work to improve your skills
and mindset.
I highly recommend Automation Awesomeness to anyone looking to up their
test automation game. Whether you’re a seasoned pro or just starting out,
there’s something in this book for everyone. Dive in and get ready to take your
automation skills to the next level. You won’t be disappointed!
A Note to the reader
With this book, my hope is to inspire you through the insights of some of
the smartest testers I’ve had the privilege to interview on my TestGuild
Automation and TestGuild Performance podcasts. At the end of each pod-
cast episode, I always ask my guest for one piece of actionable advice that
someone listening can put into place to help them with their software testing
or automation efforts. I’ve taken some of the best responses and shared
them here.
The book is a unique blend of motivational affirmations and practical advice
for professionals and enthusiasts looking to strengthen their automation and
testing skills. By combining the power of positive thinking with actionable
steps, I aim to inspire readers to excel in their careers and personal projects.
If you're seeking a book with extensive technical content and code sam-
ples, this may not be the right book for you. While the principles discussed in
this book are applicable to both the technical and non-technical aspects of
software testing processes and automation, the emphasis is placed primarily
on the development of soft skills.
My goal is for you to glean an actionable tip, tool, best practice, or mindset
each workday, which you can apply to your daily software testing and, in some
cases, to your life in general.
Why 260 Quotes?
I wanted to create a resource that you could use every workday – hence 260
quotes.
The average number of workdays in a year can vary depending on factors
such as weekends, public holidays, and the number of work hours per week.
There are 52 weeks in a year, and if we assume that people work five days a
week (Monday to Friday), then there are 260 workdays in a year. However, this
doesn't factor in public holidays, which can vary by country, state, or region.
How to Use This Book
I recommend that you start your workday with some mindfulness practices to
set your intentions for the day. I encourage you to jot down any thoughts that
come to mind during this time in the “Thoughts” section for each quote. It’s a
great way to kick-start your day and ensure that you’re focused and motivated
to tackle your software testing challenges.
Naturally, not all the advice in this book will resonate with you. That’s okay.
Take what works and ignore the rest.
As I always say, test everything and keep the good.
Read This First
I want to offer you some free bonus materials** that will help enhance your
experience of reading this book.
Bonus #1
E2E Tests: How To Raise Your Demanding Toddler
In this training session, Girish Rathod (Principal Software Engr.) will walk you
through his team’s 18-month journey to build a robust & scalable E2E test
system.
Bonus #2
Unlock the Power of Testing: The Ultimate C-Suite Checklist!
Discover how to engage executives, optimize testing strategies, select the

best automation solutions, and more. Learn how to make your quality efforts
business-relevant and get your entire team on board.
If you have claimed your bonuses once, you get auto-access to any new
resources, I might add.
Claim your free bonuses at the link below:
https://testguild.com/bookbonus
Bonus #3
Exclusive discount code for my next Automation Guild event
Every year, I organize and host an industry-standard online event – Automation

Guild – where I bring together top E2E testing experts to share actionable tips,
tools, techniques, strategies, etc. on the latest & most relevant topics.
As a special gift for owning this book, you can register for my next LIVE virtual
event at a massive 33% off the regular investment for the ticket.
Your code (to be used at checkout when registration opens):
BookGuild33
** Note: I intend to include more actionable resources in this collection.

Tap into the Power of TestGuild
Connect with Your Ideal Audience, Boost Brand

Awareness, and Generate Quality Leads
Do you have a product or service aimed that will benefit developers and
testers with test automation and DevOps?
We are the curators of the world’s best tools, software, knowledge, services,
and all things test automation related. And love to help our community find
and learn about the right software tools for their needs.
If you want to achieve your brand awareness, lead generation and thought
leadership goals by promoting your products/services to your ideal target
audience – let’s talk.
Book a strategy call, and together, we can create a plan to help:
TestGuild.com/Apply
What others have said about

working with the TestGuild
“Joe’s service is outstanding. He set up a virtual event with over 1,000

attendees in a matter of days and built an amazing online experience
for the event attendees.”
Moshe Milman Co-Founder and COO @Applitools
“The webinar the TestGuild organized for us garnered a fantastic turnout

that surpassed our expectations, outshining other events we’ve partici-
pated in. We highly recommend working with them.”
Cristina Suchland, Integrated Marketing Manager, HCL Software
“We’re still seeing dividends from our sponsorship of the Automation

Guild months after the event. Supporting this conference was a great
ROI for us.“
Francis Adanza Testim.io
o n ab
ti
le
ac DAY
1
ss
aw
e
s
e
omen
The best piece of advice I can give about automation efforts is to
remember the test pyramid. If you have a lot of small tests and a few
integration tests, and maybe one or two Selenium tests for end-to-end
testing, you’re doing it right. If you have thousands of end-to-end tests,
possibly using Selenium, and only five unit tests, then you’re in a whole
world of pain. It’s been true since before I started Selenium, and it’s still
true to this day.
O
SIM N
Creator of
EPISODE 327: testguild.com/a327 WebDriver
T
TE
S
R
WA
Daily Actionable Awesomeness
Think about the automation tests in your current project. Do they follow the
test pyramid principle? If not, what are some steps you can take to improve the
testing strategy and align it with the pyramid principle?
Reflect on the advantages of having a well-structured test suite that
follows the pyramid principle. How can you communicate the importance
of this concept to your team and ensure that everyone is on board with the
strategy?
1
o n ab
ti
le
ac
DAY
2
ss
aw
e
s
e
omen Focus on learning about testing and gain a deep understanding of

the environment you work in and what’s important in that space. This,
for me, meant delving into startups, businesses, and web design,
which interest me within my industry. Ideally, you should be passion-
ate about your industry and aim to improve it, not just focus on testing
methodologies.
How can you improve the industry and the product you’re working
on? This is only sometimes related to testing. Sometimes the testing
world becomes so preoccupied with finding bugs that we lose sight of
the bigger picture, such as business goals or user needs. You need to
see the whole picture, not just the individual pieces, to succeed.
Rosie
EPISODE 20: testguild.com/20 Founder

of Ministry S
of Testing h e r ry
Do you have product knowledge? What can you do today to learn more
about the product you’re testing? Think about the industry or product you’re
currently testing or working on. Ask yourself: what can I do to improve this
industry or product?
Consider how you can contribute to the bigger picture beyond just testing.
Take time to learn about the business side of things, the user needs, and the
overall goals of the project. Focus on adding value and making a positive
impact on the industry or product you’re working on.
Remember that testing is just one aspect of the bigger picture, and your
contribution can go beyond that to help shape the industry or product for the
better.
2
o n ab
ti
le
ac DAY
3
ss
aw
e
s
e
omen So I’m going to advocate for multiple overlapping abstraction layers

where you model the physical world and your logical concepts and
focus on synchronization. And if you were to do anything tomorrow,
let’s look through your abstraction layers to ensure that you’ve got the
right level of synchronization, and ramp down any implicit wait times
that you’ve got until you’re relying entirely on explicit waits.
A L AN
Principal
EPISODE 4: testguild.com/04
N
Consultant at
RI
O
H
C
Compendium ARDS
Developments
What strategies do you have in place to ensure the right level of synchroniza-
tion? Can you identify any implicit wait times that you can ramp down and rely
more on explicit waits?
Review your current approach and identify areas for improvement to
enhance your synchronization and abstraction layer modeling skills. Then
share your findings with your team and discuss potential solutions for any
issues you identified.
3
o n ab
ti
le
ac
DAY
4
ss
aw
e
s
e
omen Don’t allow others to make you believe that AI or machine learning
is this all-knowing black box. As testers, we know better. We under-
stand that this is not the case.
So get involved, read up more [on] what machine learning actually
is, look at different applications that are using machine learning, and
start thinking about how you would test it. A key question that I often
ask is how would you test this? What would your test strategy be for
something like a Netflix recommendations page or Twitter’s timeline
of tweets, for example? Start thinking about that.
G
AN IE
EPISODE 194: testguild.com/194 VP, Developer

Relations
j
ones
Don’t believe the hype. Take some time to research the topics of AI and
machine learning. Also, check out some tools that claim to have AI capability
to see what they can actually do and, more importantly, what they can’t do.
Think of an application or system that uses machine learning, such as a rec-
ommendation engine, speech recognition software, or autonomous vehicles.
Then take some time to learn more about its underlying principles, how it
works, and the types of data it requires. Next, consider the specific challenges
that arise when testing these kinds of systems, and try to come up with a test
strategy that would cover all the relevant scenarios. What are the unique risks
and potential failure modes associated with machine learning systems, and
how can you design your tests to detect them?
Share your insights with your colleagues or fellow testers, and encourage
them to do the same. Remember, as a tester, you have a crucial role to play
in ensuring the quality and reliability of these cutting-edge technologies, so
it’s important to stay informed and up to date on the latest developments in
the field.
4
o n ab
ti
le
ac DAY
5
ss
aw
e
s
e
omen The best advice I can give is to slow down and continue learning
about good development practices. Treating tests as code rather
than just a set of hastily slapped-together instructions is the best way
to improve your testability and overall test suite health. As you
improve your development skills, you’ll also strengthen your test
writing skills because these two are related.
There are several good design pattern books out there, and
although it may seem like a waste of time to learn about design
patterns and problem-solving approaches, it’s crucial to improve
ourselves as software testers. We tend to sell ourselves short by
thinking that we’re just quality assurance people and not developers,
but there’s no reason why we can’t be as good at writing code as
developers are.
We should always try to improve ourselves. [We should] never settl[e]
for poorly written code that tests the website and leads to confusion
and frustration. Instead, we should strive for perfection, building a
logical and well-written test suite that impresses any developer who
looks at it. Nothing is more soul-crushing than a test suite that fails
randomly. But a well-written test suite that reflects our dedication
and skills can make us feel good about ourselves and our job.
My best advice is to keep learning, keep improving, and strive for
perfection. When you do, your tests will [be] better, your program-
ming skills will improve, and you’ll enjoy writing tests a lot more.
dima
Author of
EPISODE 30: testguild.com/30 Selenium
o
k
o
Design Patterns
k
va
len
& Best Practices
Reflect on your approach to testing and consider whether you’ve been selling
yourself short as a software tester. Are you approaching your tests as a set of
hastily slapped-together instructions or are you treating them as code?
Take the time to learn about good development practices and design pat-
terns to strengthen your test writing skills. Don’t settle for poorly written code
that tests the website and leads to frustration. Instead, strive for perfection by
building a logical and well-written test suite that reflects your dedication and
skills.
Remember, improving your programming skills will ultimately improve your
test writing skills, and that will lead to a happier and more satisfying job as a
software tester. So make it a priority to keep learning, improving, and striving
for excellence in your testing practices.
5
o n ab
ti
le
ac
DAY
6
ss
aw
e
s
e
omen The best advice that I can give to our users [is to] use all the
resources that are available to you. Read about Selenium to under-
stand why it is so important, why it’s becoming a standard in web test
automation. Use a tool that allows you to become more efficient within
the organization to bring all the parties that do the testing together
with a tool that allows you to do all of that in one place.
a sh a
M
EPISODE 32: testguild.com/32 Product

Leader K
s
o
zin et
Are you reading the documentation of the tool you’re having issues with
before you assume there is an issue or that it doesn’t provide the functionality
you need? If not, you should be. You might uncover something you didn’t
known about. Take it one step further you could design and implement a col-
laborative learning project within your organization, focused on mastering
Selenium for web test automation. Bring together a diverse group of team
members, utilize various resources to deepen your understanding, and create
a centralized platform for sharing knowledge and insights with one another.
6
o n ab
ti
le
ac DAY
7
ss
aw
e
s
e
omen Make sure you get the training you need to use the tool as it was
designed to be used. Go back to your management, even if you find a
webinar or something online that you can take that’s going to help
[start] you off in the right direction. Ensure that you can tie that training
back to the vendor or some trusted source. . . . That’s an excellent
place to start and something I would highly recommend to folks.
e
Gr g
EPISODE 8: testguild.com/08 Author of Test

Automation in P
as l
the Real World ka
Think about a tool or technology you recently started using or plan to use
soon. Have you received proper training on how to use it? If not, what steps
can you take to ensure that you receive the training you need in order to use
the tool effectively and as it was designed to be used?
Research available training resources, such as webinars, online courses,
and vendor-provided training, and discuss with your manager or team the
importance of receiving proper training. By taking the time to get trained, you
can avoid bad information and ensure that you’re using the tool to its full
potential, ultimately increasing your productivity and improving the quality of
your work.
7
o n ab
ti
le
ac
DAY
8
ss
aw
e
s
e
omen When implementing automation, break down big tasks into smaller
ones and automate those tasks one at a time. This approach will allow
for the implementation of best practices, such as writing small shell
scripts and analyzing log files, which will lead to quality delivery of the
project.
Additionally, it is essential to continue learning and exploring new
tools, such as Weka, a machine learning library developed at the
University of Chicago. Weka is an excellent tool for those who are not
experienced programmers, and it is easier to start with than other
machine learning libraries such as TensorFlow or Python program-
ming. When using Weka, [train] with multiple data sets to increase
accuracy and use the knowledge flow to perform in-depth analysis
is essential.
Finally, it is essential to remember that while AI and automation will
change the role of testers, they will not replace them entirely, as
humans will still need to do intelligent work.
havan
B
i
EPISODE 225: testguild.com/225 Certified
Software Test
Manager R
Reflect on how automation and AI are changing the role of testers in your
industry, and identify one big task that could be broken down into smaller
ones and automated. Research new tools, like Weka, to help you achieve your
goals more efficiently. Then create a plan to implement automation for that
specific task, including training with multiple data sets and using knowledge
flow for in-depth analysis.
Finally, consider how the implementation of automation will impact the
role of testers in your organization and how you can prepare for the changing
landscape.
8
o n ab
ti
le
ac DAY
9
ss
aw
e
s
e
omen The best thing you [can] do tactically is, if you’re not using page
objects, [to] figure out what those are and start using them. That’ll
make your tests immensely better, more readable, and much more
maintainable.
In terms of something that’s a little bit softer, that’s actionable, I
would say try to understand how your business makes money or gen-
erates value, and identify critical things that users use in the system.
Then match this business value and see if you have automated tests
to cover it. If you don’t, add them. You’ll be thanking yourself later after
you’ve avoided some catastrophic emergency release.
Dave
EPISODE 2: testguild.com/02 Writer of

Elemental
r
H
a
Selenium effne
Think about your current testing practices. Are you using page objects in your
automated tests? If not, consider using them, as they can improve the quality,
readability, and maintainability of your tests.
Next, consider the business value your system provides and identify critical
user actions that support that value. Do your automated tests cover these
critical user actions? If not, make it a priority to add them to your test suite.
This can help prevent emergency releases and ensure that your system is
delivering the value your business relies on.
9
o n ab
ti
le
ac
DAY
10
ss
aw
e
s
e
omen Start to get the whole team to solve testing problems. So, instead
of saying this is a testing problem and this is my problem, use those
retrospectives to say, hey, we have this testing problem, how are we
going to solve it. Then learn to use the 5 Whys . . . to get to the real
problem, to solve it.
Jane
EPISODE 34: testguild.com/34 Co-founder of

Agile Testing
y
r
Fellowship egor
Think of a recent testing problem you faced, and instead of trying to solve
it alone, bring it to your team in the next retrospective. Use the 5 Whys
technique to get to the root cause of the problem and brainstorm solutions
as a group. Challenge yourselves to think outside the box and come up with
creative solutions that involve everyone, not just the testers. How can devel-
opers, business analysts, and other team members contribute to solving the
problem?
Don’t be afraid to ask why again and again until you reach the true cause of
the issue. By working together as a team, you can come up with more effective
solutions and improve your testing processes in the long run.
10
o n ab
ti
le
ac DAY
11
ss
aw
e
s
e
omen If you’re a business analyst, find a QA and a developer. If you’re a

QA, find a developer and a business analyst. If you’re a developer, find
a QA and a business analyst. Then take one of the stories for your next
sprint, and sit down and spend 20 minutes, just 20 minutes, before
anybody writes any code, just discussing that story. Try to make a list
of the business rules that you understand for that story, try to make a
list of examples that illustrate those business rules, and try to get
some agreement about what those examples would be.
Just spend 20 minutes on one story for your next sprint and, mark
my words, you’ll find that story is more straightforward to develop than
any of the other ones.
Mat t
EPISODE 35: testguild.com/35 Author of The

Cucumber W
Book ynne
Take the opportunity to connect and collaborate with other roles in your soft-
ware development team. Choose a story for your next sprint and schedule a
20-minute meeting with a QA, a developer, and a business analyst.
Use this time to discuss the story, identify the business rules, and make a
list of examples to illustrate those rules. Then reflect on the experience and
see if it made the development process for that story easier. Consider incor-
porating this collaboration and discussion process into your development
workflow for future sprints.
11
o n ab
ti
le
ac DAY
12
ss
aw
e
s
e
omen
Performance testing is an integral part of the DevOps approach to
software development and production. The key component of this
approach is the ability to automate and make the whole process fast
and agile. It is important to test performance at different stages, from
the development of the pipeline to the pre-production environment,
and even in the production environment.
Performance testing should not be isolated. [It] should be part of a
synergy that covers every step of the software lifecycle. Synthetic
monitoring, which is a more complex way of pinging resources and
providing a full set of key performance indicators, is also a useful tool
for real-time monitoring.
Therefore, the actionable advice is that organizations should incor-
porate performance testing as a regular part of their DevOps activities
to ensure their software development and production process is fast,
agile, and effective.
ol a
Pa
EPISODE 192: testguild.com/192 Technical

Program
o
R
o
Management ssar
How can you make performance testing a regular part of your software devel-
opment process, and what tools can you use to monitor the performance of
your applications in real time?
Take a step back and assess your current approach to performance testing.
Are there any areas that can be improved? What steps can you take to make
the process more efficient and effective?
Consider how synthetic monitoring can provide a more comprehensive
view of your application’s performance, and how you can use this information
to optimize your software development pipeline.
Remember, by making performance testing a regular part of your DevOps
activities, you can ensure that your applications are fast, agile, and effective,
and that they meet the needs of your users in real time.
12
o n ab
ti
le
ac DAY
13
ss
aw
e
s
e
omen If you’re getting some problem or something’s going wrong, there

always ends up being a reason. It could be this really obscure reason,
like your code was doing something you didn’t intend or something
you didn’t think of before. But at the core of it, there is always going to
be some reason there. . . . It’ll probably be something ridiculously
simple that you’ve just forgotten. But . . . there will be some logical
reason.
Al
Author of
EPISODE 54: testguild.com/54 Automate the
t
Boring Stuff w
eig a r
with Python
Challenge yourself to adopt a curious mindset and actively search for the
underlying reason behind any issues you encounter during testing. Instead
of becoming frustrated or assuming a problem is unexplainable or magical,
approach the issue with the assumption that there is always a logical expla-
nation.
Take the time to carefully analyze the problem and consider all possible
factors that could be contributing to it, no matter how obscure or unexpected
they may be. By cultivating a deep understanding of the underlying mechan-
ics of the software you’re testing, you’ll be better equipped to identify and
solve problems quickly and effectively.
Additionally, try to create a culture of curiosity and inquiry within your team,
where everyone is encouraged to investigate issues with a critical eye and a
willingness to learn.
13
o n ab
ti
le
ac
DAY
14
ss
aw
e
s
e
omen I’d love to see more fresh ideas! Let’s explore new ways of doing
things. It’s funny how we still think of agile as something new, even
though it’s been around for over 15 years. And some organizations still
find exploratory testing to be a strange concept, even though it’s been
around for 30 years.
There are plenty of great ideas out there that we haven’t fully
embraced yet, and some of the old ones are starting to become out-
dated. So, what’s the next big thing?
isti
hr n
C
EPISODE 84: testguild.com/84 Ph.D., Sr.
n
Director
W
e
n
i
dema
Think about the latest technology trends and their impact on software devel-
opment and testing. Consider exploring emerging technologies such as
artificial intelligence, machine learning, and blockchain.
Based on your research, identify potential testing challenges that these
technologies might introduce and propose innovative solutions. Then share
your insights and ideas with your team or community to spark a conversation
on the next big thing in testing.
Remember, it’s important to keep an open mind and be willing to explore
and adopt new ideas to stay ahead of the curve.
14
o n ab
ti
le
ac DAY
15
ss
aw
e
s
e
omen My one big piece of advice is to educate [y]our colleagues and co-
workers about testing. It’s important to let them know how effective
automation can be used. If we keep our views about testing to our-
selves, people will keep asking us for things we’re uncomfortable with.
This is because they don’t know any better. Therefore, we should start
sharing our ideas about testing and educating the rest of the business
on the value we can add.
Testing is often treated as an afterthought and only considered
when the product is nearly complete. There are better approaches
than this. We need to start educating people about the importance of
testing, and we should do this as early as possible in the development
process. This is not an easy task, but we need to do it. We should
constantly push the value of testing to the business and to our team
members.
ichard
R
EPISODE 47: testguild.com/47 CEO at

Ministry of
w
r
a a
Testing dsh
Think about a recent project or task in which you encountered challenges with
testing or test automation. Did you communicate effectively with your team
and stakeholders about your views on testing? Did you make the value of
testing and usable automation clear to them? Take some time to reflect on
what you could have done differently to better educate your team about the
importance of testing and how it should be done.
Consider reaching out to your team or stakeholders to have a conversation
about testing and how it can add value to your projects. Think about how
you can better collaborate and educate others on the testing process moving
forward.
Sharing your views on testing and educating others can help everyone on
the team better understand the importance of testing, and ultimately can lead
to better-quality software.
15
o n ab
ti
le
ac
DAY
16
ss
aw
e
s
e
omen Imagine you’re facing a huge testing challenge that’s been bugging
you for a while. Now picture this: you take this challenge to your entire
delivery team and say, hey, we’re in this together, let’s put our minds
together and find some innovative ways to solve this problem.
By collaborating with your team and thinking out of the box, you can
come up with some powerful experiments that can help make your
testing problems smaller. So don’t hesitate to reach out to your team
and seek their help in tackling your biggest testing hurdles.
Lisa

Agile Testing C
Fellowship ris pin
Think about a testing problem you are facing or have faced in the past. It could
be related to test automation, exploratory testing, regression testing, or any
other area of testing. Consider the impact this problem is having on the quality
of the product and the team’s ability to deliver value.
Next, bring the problem to your entire delivery team, including developers,
testers, designers, product owners, and anyone else involved in the product
development process. Explain the problem and ask for their input and ideas
on how to solve it. Encourage them to think creatively and come up with
experiments to try to make the problem smaller or even solve it entirely.
The key is to work together as a team to address the issue. By involving
everyone in the problem-solving process, you’ll not only come up with more
ideas but also foster a sense of ownership and shared responsibility for the
quality of the product. So act now and bring your team together to tackle that
big testing problem!
16
o n ab
ti
le
ac DAY
17
ss
aw
e
s
e
omen I think that the most important thing in most software products is
that you decompose your system into smaller parts and test them
individually. Once you start to split up your big system into smaller
parts, many things will become easier. They will become easier to test.
It will be faster to run your automated tests as well, because you don’t
have to run your entire suite for all your subsystems. You can just run
the tests for the subsystem that changed.
[Also] everyone should read Eric Evans’ book Domain-Driven Design.
I think that’s one of the best books out there.
h an
Jo
EPISODE 45: testguild.com/45 Creator of

REST Assured H
a l e by
Think about the software project you’re currently working on and try to iden-
tify how you can decompose it into smaller subsystems. Consider how this
could make it easier to test and run your automated tests more quickly.
Eric Evans’ book Domain-Driven Design is a must-read because is it pro-
vides a comprehensive understanding of the strategic design patterns and
practices involved in creating complex software systems. By learning these
concepts, test engineers can effectively communicate with developers and
business stakeholders, better understand the underlying domain, and design
more meaningful and targeted test scenarios that align with the application's
core business logic. This, in turn, helps to create more reliable, maintainable,
and valuable software systems.
After reading consider how the ideas in the book could be applied to your
project and discuss this with your team to see if they see potential benefits to
implementing this approach.
17
o n ab
ti
le
ac
DAY
18
ss
aw
e
s
e
omen The number-one starting point should be the test plan, that auto-
mation plan. . . . Identifying where you are and where you want to be.
And as you start writing down numbers one, two, and three, those
pieces will start to come together. So, what are the things you need
to consider concerning the people? What are the things you need to
consider regarding your current process? And then pick the right
technology. That would probably be the simplest structure for starting
your test strategy, your test automation strategy.
alis
nn
a
EPISODE 393: testguild.com/a393 Executive VP
o
C
a
l
m
a ril
Create a test automation plan for a project you’re working on or one you
worked on in the past. Consider where you are with your current test automa-
tion efforts and where you want to be in the future. Identify the people
involved in the testing process and what roles they’ll play. Evaluate your
current testing process and determine how it can be improved.
Finally, pick the right technology for your project based on your evaluation.
Once you’ve completed this exercise, reflect on what you’ve learned and
share your insights with your team.
18
o n ab
ti
le
ac DAY
19
ss
aw
e
s
e
omen Automation is often thought of as a purely technical issue, but I

believe we’re missing the bigger picture. To truly leverage the power
of automation, we need to approach it as a marriage of business and
technology. By doing so, we can build stronger, more meaningful part-
nerships within our organizations.
Gone are the days when automation was just a matter of program-
ming a few lines of code. Today it’s about understanding the business
processes that underpin our work and finding ways to automate them
intelligently. When we view automation through this lens, we can see
the possibilities and opportunities that lie ahead.
By working together with our business partners, we can identify
areas where automation can make the most impact, streamline our
workflows, and achieve greater efficiencies. With a shared vision and a
collaborative mindset, we can drive real change and create a brighter
future for our organizations.
So let’s shift our perspective and start thinking about automation
as a strategic tool that brings together the best of both worlds. When
we do that, we’ll be well on our way to building stronger, more
resilient businesses that can thrive in today’s fast-paced, technology-
driven world.
yan
al a
K
EPISODE 60: testguild.com/60 President

of Cigniti
a
R
a
d
o
Technologies Ko n
Imagine you’re a software engineer tasked with automating a critical business

process. How would you ensure that your automation efforts align with the
company’s overall business strategy? How would you collaborate with busi-
ness stakeholders to ensure that the automation solution not only meets
technical requirements but also drives real business value? In what ways can
you bridge the gap between technical and business teams to create a larger
business partnership within the company?
Consider the benefits of a more holistic approach to automation, and how it
can lead to better outcomes for both the company and its customers.
19
o n ab
ti
le
ac
DAY
20
ss
aw
e
s
e
omen When it comes to behavior-driven development (BDD), collabora-

tion is key. If you’re unable to work closely with your colleagues on the
business or customer side of things, then using Cucumber as a test
automation tool might not be the best fit for you. Instead, consider
using a dedicated test automation tool.
At its core, BDD is all about fostering collaboration and communica-
tion. Cucumber was designed with this in mind: to help teams work
together to build better software. If you’re just looking to automate
your testing without a strong emphasis on collaboration, then Cucum-
ber might not be the best choice for you.
However, if you’re committed to working closely with your col-
leagues to deliver high-quality software, then Cucumber can be a
powerful tool in your arsenal. With its user-friendly syntax and ability
to bridge the gap between technical and nontechnical stakeholders,
Cucumber can help you build stronger, more collaborative teams.
So, if you’re looking to use Cucumber for test automation, remember
that it’s not just a technical tool, it’s a collaboration tool. By working
together with your colleagues and leveraging the power of BDD, you
can create software that truly meets the needs of your customers and
business partners.
seb
EPISODE 53: testguild.com/53 Co-author of

The BDD Books
ro
se
Reflect on your team’s approach to collaboration in software development.

Are you actively involving stakeholders from the business or customer side in
your development process? If not, consider the benefits of doing so, such as
gaining a better understanding of their needs and requirements, improving
the quality of your software, and fostering a more collaborative and support-
ive work environment.
Explore tools and techniques that can help facilitate collaboration, such as
BDD and its associated frameworks, like Cucumber, and consider whether
they may be appropriate for your team’s needs.
Remember that collaboration is not just a technical matter, but a business
one as well, and that by working together with stakeholders, you can create
more effective and valuable software products.
20
o n ab
ti
le
ac DAY
21
ss
aw
e
s
e
omen One of the most valuable pieces of advice I’ve come across is to re-
run tests on failure to differentiate between flaky tests and legitimate
test failures. This simple technique can save you hours of debugging
time and help you pinpoint the real issues with your code.
Another tip that can help you supercharge your testing efforts is
parallelization. If you’re using a tool like Sauce Labs, you have the
power to run multiple tests at the same time, which can significantly
speed up your build times. And we all know that faster builds mean
more efficient teams and better results in the long run.
So, if you’re looking to optimize your testing processes and get the
most out of your tools, keep these tips in mind. By using smart tech-
niques like rerunning tests and parallelization, you can streamline
your workflow, reduce errors, and deliver high-quality software more
quickly and efficiently than ever before.
eve
St

Sauce Labs
Ha l
ze
Think about your current test automation process and identify areas where
you could improve efficiency. Consider implementing the advice of rerunning
tests on failure to identify flaky tests and using parallelization, especially if
you’re using a service like Sauce Labs.
How could implementing these strategies improve your team’s productivity
and make your test automation process more efficient? What tools and
resources could you use to help implement these strategies effectively? Take
action to experiment with these strategies and track the results to see the
impact they have on your team’s productivity and efficiency.
21
o n ab
ti
le
ac
DAY
22
ss
aw
e
s
e
omen Prioritize the mean time to diagnosis as a key metric for your testing
process. This means ensuring that when a test fails, you can quickly
identify why it failed, preferably within a minute or two, without having
to rerun the test or go through lengthy debugging processes. To
achieve this, you should intentionally try to make your tests fail during
development by manipulating the operating system or changing
comparisons to ensure that you understand what a failure looks like
and how to diagnose it.
This practice will not only help you write more effective tests but
also save time and increase efficiency in the testing process. Finally, it
is important to note that while full TDD may not be necessary, testing
practices should always include the intentional creation of failing tests
and quick diagnostic procedures to ensure the highest quality of code.
A lan
EPISODE 44: testguild.com/44 Author,

Podcaster,
VP Pag e
What are some specific steps you can take to prioritize mean time to diag-
nosis in your testing process? How can you intentionally create failing tests
and develop quick diagnostic procedures to streamline the testing process
and improve code quality?
Consider implementing these practices in your own testing process and
measuring the impact they have on efficiency and overall code quality.
How can you encourage your team or organization to prioritize this metric
and make it a key part of your testing process?
22
o n ab
ti
le
ac DAY
23
ss
aw
e
s
e
omen Run your tests early and run them often. Don’t wait until the last
minute to check if everything works. By incorporating testing into your
CI/CD pipeline, you’ll receive crucial feedback quickly and be able to
catch issues before they escalate. After all, you’ve invested a lot of
time writing tests, so don’t let that effort go to waste by not running
them frequently.
Keep your tests updated and schedule regular runs so you can
catch any issues and have that safety net to rely on.
gh a
ea
n
EPISODE 126: testguild.com/126 Senior
Content
Le
Developer wis
Think about the last time you wrote automated tests for a project. Did you
consider how to run them effectively in a continuous integration (CI) pipeline?
If not, take some time to research how to integrate your tests into a CI pipeline
and configure them to run on a schedule.
Also, consider the benefits of running tests often and how this can provide
valuable feedback on the health of your project. Then make a plan to imple-
ment this in your current or next project to ensure that your tests are run
regularly and effectively to catch issues early on.
23
o n ab
ti
le
ac
DAY
24
ss
aw
e
s
e
omen To improve your testing efforts, it’s essential to be mindful of why

you’re performing each activity. Don’t just blindly follow best practices
without considering whether they actually provide value to your team.
Even if a particular activity is helpful, ask yourself if it’s the most effi-
cient use of your time and resources. Take the time to periodically
reassess what you’re doing and why. Why are you invested in this
process? Are there better options available? By doing so, you can
ensure that you’re optimizing your testing efforts and achieving the
best possible outcomes for your team.
Andy
EPISODE 78: testguild.com/78 Security

Architect T
in
m
kha
Think about a testing activity that you and your team are currently doing, and
ask yourself why you’re doing it.
Is it providing value to the team and the business, or is it just a best practice
that you’re blindly following? Are there other things you could be doing
instead that would provide more value in the same amount of time?
Take the time to periodically evaluate your testing efforts and make sure
you’re using your time and resources effectively.
24
o n ab
ti
le
ac DAY
25
ss
aw
e
s
e
omen Testers should use their analytical skills to ask the right questions at
the right time to see the big picture. Testers should focus on two main
questions: are we building the right product and are we building the
product right. They should also aim to build relationships with different
stakeholders by understanding their needs and coming across as
subject matter experts.
Testers can add value by being knowledgeable about the whole
system and helping different teams with their needs, such as the sales
team, operations team, and infosec team. When moving into a lead-
ership role, testers should focus on building trust, communicating
effectively, and prioritizing work based on the big picture.
A nn a
EPISODE 207: testguild.com/207 Founder of

Test Masters
n
R
o
Academy yzma
Think about when you were part of a project team in which testing was an
afterthought and errors were discovered late in the project, leading to signifi-
cant delays and cost overruns.
Now imagine yourself as a tester on a similar project. How would you use
your analytical skills to ask the right questions at the right time to ensure
that the product is built correctly? How would you build relationships with
different stakeholders to understand their needs and be seen as a subject
matter expert? And if you were to move into a leadership role, how would
you prioritize work based on the big picture, build trust, and communicate
effectively with your team and stakeholders?
Reflect on these questions and consider how you can apply them in your
current or future role as a tester.
25
o n ab
ti
le
ac
DAY
26
ss
aw
e
s
e
omen Automation is not a silver bullet.

A lot of teams, when they start doing automation, they get dragged
away and they get too much into the frameworks and . . . their automa-
tion does super-duper things, but they lose the focus or the intention
of the automation, which is actually to help in testing.
[Automation] should supplement your testing efforts, not replace it.
nmesh
U
Author of
Selenium
a
G
u
Testing Tools ndech
Cookbook
Think about how you can strike a balance between manual testing and auto-
mation in your team. Ask yourself what can be automated to save time and
improve efficiency, and what tasks require human intelligence and intuition.
Take a step back and assess your current automation practices. Are they
helping to supplement your testing efforts, or have they become a distraction
from the real goal of improving the quality of your product?
Remember, automation should never replace manual testing entirely. So
how can you strike a balance that works for your team and ensures that both
manual and automated testing efforts are focused on the right things?
26
o n ab
ti
le
ac DAY
27
ss
aw
e
s
e
omen Have you ever felt overwhelmed by the complexity of your enter-
prise environment and wondered how to approach things in a more
organized manner?
Recently, I stumbled upon a book called Toyota Kata by Mike
Rother, and it provided me with valuable insights. Rother spent over 20
years studying Toyota and developed a framework that can be applied
in any enterprise environment. The key takeaway is to identify your
current situation and compare it to your target situation. By doing so,
you can identify the gap and create an iterative plan to close it. This
framework can significantly improve your testing efforts.
Additionally, it is essential to assess the risks associated with your
software, company, and team to prioritize your tasks accordingly. By
following these principles, you can effectively manage complexity and
achieve your goals.
M ark
Author of The
EPISODE 98: testguild.com/98 Hitchhiker’s
Guide to Test Fin k
Automation
Reflect on your testing practices and consider how often you take a step back
to evaluate your current situation and identify your target situation.
How might applying the iterative planning framework discussed in Toyota
Kata help you achieve your testing goals more effectively? Additionally,
consider the risks associated with your software, company, and team, and
reflect on how you can prioritize your testing efforts to address the most
pressing risks.
Finally, consider how you can build a culture of continuous improvement
within your team by encouraging the use of the Toyota Kata concepts as a
problem-solving framework.
27
o n ab
ti
le
ac
DAY
28
ss
aw
e
s
e
omen I’ve authored several books aimed at helping people improve their
testing skills, covering a range of different subjects. Testing . . . encom-
passes many different aspects, and finding your own area of focus is
crucial to becoming a better tester. At a metalevel, the key to becom-
ing a better tester is to discover that one thing that you need to work
on. It may sound silly, but it’s true. This is your first task. Unfortunately,
many people tend to do the opposite.
For instance, take bodybuilders. They may have great biceps, but
they neglect other areas of their physique and don’t end up winning
competitions. Similarly, in testing, I’ve met many testers who excel
at detecting and isolating errors in code but are unable to effec-
tively communicate with developers and managers. Others may be
good communicators but struggle to write clear error reports. Still
others may not be good problem solvers and tend to overlook
important details.
My advice is this: when you find yourself saying “that’s one thing I
don’t need to know about,” catch yourself and learn about it, because
that’s exactly the area you should be focusing on. Don’t neglect any
aspect of testing, even if you think it doesn’t apply to you. Whether
it’s communication skills, writing skills, problem-solving skills, or
something else entirely, focus on improving in that area. That’s the
path to becoming a better tester.
erald
G
EPISODE 100: testguild.com/100 Author of

over 40
g
W
ei
books nber
Take a moment to reflect on your testing skills and consider which areas you
may need to improve to become a better tester. Ask yourself what skills or
knowledge gaps you have that may be holding you back.
Once you’ve identified these areas, challenge yourself to improve in at least
one of them over the next week or month. For example, if you struggle with
communicating your findings to your team, take a course on effective commu-
nication or practice writing clear and concise error reports. Or if you struggle
with problem-solving, look for opportunities to practice your problem-solving
skills, such as by taking on more challenging testing assignments.
Remember to be open to learning new things and to always strive for
continuous improvement in your testing practice.
28
o n ab
ti
le
ac DAY
29
ss
aw
e
s
e
omen I would recommend every tester, whether they do automation or

manual testing, to do exploratory work. Start an exploratory session
and try to think out of the box. I find my exploratory sessions refresh-
ing, and each of them can be completely different.
It’s easy. Just choose an area of your application that you don’t know
but where you would like to obtain more info. Explore and see what
happens. I think this is a great exercise to do from time to time. Maybe
not daily, but it helps improve product quality and [can be] a healthy
improvement in old projects.
Kinga
Head of
Software Watch
Community Wi
t ko
Automation testing is just a small part of a team’s quality effort. Take some
time to have some exploratory sessions with your team to uncover issues your
automated tests might be missing. By thinking out of the box and embracing
curiosity, I think you’ll be surprised by how many participants will uncover
potential issues and areas of improvement that might have gone unnoticed
during routine testing processes. For a step-by-step approach to conducting
an effective exploratory session download the bonus material for this book at:
testguild.com/automationbook-bonuses
29
o n ab
ti
le
ac
DAY
30
ss
aw
e
s
e
omen Before you get started on creating your API, I’ve got some advice for
you that goes beyond just testing. Have you considered involving as
many stakeholders as possible from the very beginning? It’s not just
a technical interface, but a crucial tool for your sales, business devel-
opment, and marketing teams. It’s the backbone of your business,
delivering services to your partners and customers. So why not keep
them in the loop from the start?
By involving them every step of the way, from design to testing, you
can ensure that your API works flawlessly, delivering the intended data
without any surprises. Trust me, it may take some extra effort, but
involving your stakeholders will pay off in the long run.
N ei l
EPISODE 72: testguild.com/72 Developer

Experience at
a
M
Atlassian a
n sill
Consider a recent or upcoming API project you’re working on or plan to work

on. Reflect on the stakeholders who will be impacted by the API, such as the
sales team, business development team, and marketing team.
If you didn’t involve these stakeholders from the beginning of the project,
ask yourself what steps you can take to involve them more closely. Think
about the information they need in order to make informed decisions and how
you can ensure that they have access to that information throughout the
project’s lifecycle.
Next, consider the testing phase of the project. How can you involve stake-
holders in the testing process to ensure that the API meets their needs and
expectations?
Finally, remind yourself that the API is more than just a technical interface.
It’s a critical part of how your business conducts business. By involving stake-
holders early and often, you can ensure that the API meets the needs of
your customers and partners and ultimately contributes to the success of your
business.
30
o n ab
ti
le
ac DAY
31
ss
aw
e
s
e
omen If I were to give you one piece of advice, it would be to take advan-
tage of the debugging features in programming languages like Java
and .NET. You can use breakpoints in your IDE, such as Visual Studio,
to step through the execution of your tests and stop them at the exact
point where you anticipate they will fail. This way, you can check to see
if the application under test is in the state you expect it to be in. This
practice can help you identify and fix issues more efficiently, saving
time and resources.
J im
Core
EPISODE 28: testguild.com/28 Contributor
Selenium E
va n s
Project
Are you familiar with the IDE you use to create automation tests? Have you
explored all the shortcuts and features that can make your work more
efficient? Discovering the hidden gems of your IDE can greatly enhance your
testing efforts.
Take advantage of keyboard shortcuts to navigate and streamline your
workflow. It’s amazing how much time you can save by mastering these tools.
Trust me, it’s made a world of difference for me!
31
o n ab
ti
le
ac
DAY
32
ss
aw
e
s
e
omen When it comes to testing . . . strive to be the person who’s constantly

improving their craft. Sure, you go to work and do your job, but when
you’re not on the clock, keep learning. Read blogs, follow experts on
Twitter, participate in weekend testing events, learn new tools—
there’s so much material out there. You can even have your own
in-home education in testing and become really good at it.
And if you need advice, don’t hesitate to reach out. I’m more than
happy to share the things I’ve learned, the paths I’ve taken, and the
conferences and people who have been helpful to me. Constant
education in testing is key to becoming great at what we do, and the
resources are out there for us to take advantage of.
M ik e

Drive-Thru is Not
Always Faster Ly
les
Reflect on your current approach to your job. Are you simply doing the work
and punching the clock, or are you taking an active role in your own education
and growth? What steps can you take to increase your knowledge and skills
in your field, and how can you integrate these into your daily work?
Consider reaching out to colleagues, attending conferences or training
events, following experts on social media, or even doing personal research on
your own time. Challenge yourself to be the best at what you do, and commit
to ongoing learning and development in your field. Keep learning something
work-related during your free time.
32
o n ab
ti
le
ac DAY
33
ss
aw
e
s
e
omen I guess if you want to get really good at any automation, the best
thing to do is learn how to program. I had a lot of people asking me
how to get into Selenium or how to start automation testing. And really,
you’ve got to understand how the program side of it works. You can’t
hope to write good scripts if you don’t understand the basics of pro-
gramming.
M ark
Author of
EPISODE 81: testguild.com/81 Mastering
Selenium C
o l li n
WebDriver
Reflect on your current level of programming skills and consider how they
may be holding you back in automation testing. If you have limited or no
programming experience, explore online resources for beginner program-
mers or enroll in a programming course. If you’re already proficient in one
language, consider branching out to learn new programming languages,
frameworks, or tools.
Look for opportunities to apply your programming skills to automation test-
ing, such as building your own automation scripts or contributing to open
source testing projects. Remember that investing in your programming skills
can improve the quality and efficiency of your automation testing and open
new career opportunities in the field.
33
o n ab
ti
le
ac
DAY
34
ss
aw
e
s
e
omen My general advice when creating automated tests—and this doesn’t

only apply to a robot framework, but to any other automation tool—
is to try to make your test cases as easy to understand as possible. Of
course, this . . . depends [on whether] you are using a programming
language like Java to create Selenium tests. Then it’s not going to be
as easy to read for businesspeople as a test case created using a robot
framework or Cucumber. But still, try to make it . . . easy to read and
understand for people reading it.
kk a
Pe

RobotFramework K
lä rck
Think about the last automated test case you created or worked on, and
review it from the perspective of someone who isn’t as familiar with the
technical details of your automation tool or programming language. Consider
how clear and understandable the test case would or wouldn’t be to someone
who has a nontechnical background, such as a business stakeholder or a
product owner.
Based on your evaluation, identify specific ways that you could improve the
readability and understandability of your test cases. For example, you could
add more descriptive comments, use more natural language, or break down
complex test steps into smaller, more manageable ones. Plan to implement at
least one of these improvements in your next automated test case.
34
o n ab
ti
le
ac DAY
35
ss
aw
e
s
e
omen Don’t say no to automation. It’s a lot of fun, and you can get many
benefits from it.
To learn, you can find an automation mentor who will show you what
they’re doing. Take a look at their tests and see what their process is,
or maybe just look at some tools that you might find interesting. There
are so many tools out there, so choose one, read the documentation,
and see if it’s easy to write tests with. Do some research on the world
of automation, and you will definitely find something that is helpful. I
don’t know anyone who has gone into automation and never gone
back. Trust me, if you get into it, it’s going to be a lot of fun.
There are so many interesting topics related to automation, like the
biggest thing that I’ve seen lately, which is artificial intelligence testing.
Take a look at it yourself, and surely you will find something that
suits your qualities as a tester and helps you in your day-to-day work.
ri n a
Co
EPISODE 183: testguild.com/a183 QA Lead
Pip
Reflect on your current approach to testing and consider the benefits of

incorporating automation into your process. Take some time to research
different automation tools and read up on current automation trends, such as
artificial intelligence testing. Seek out an automation mentor or colleague
who can show you how they’re implementing automation in their work. Try out
a new tool or approach and see how it can help you be more efficient and
effective in your testing.
Don’t be afraid to embrace automation and see how it can add value to
your work.
35
o n ab
ti
le
ac
DAY
36
ss
aw
e
s
e
omen Don’t review large chunks of code. Don’t try to tackle two thousand
lines of code. Don’t try to sit down and hammer out four hours’ worth
of code review. All of the studies show you need to be doing smaller
chunks of time, no more than 60 to 90 minutes. And you should be
doing, you know, 400 lines or less.
So I would say that that’s a big and important kind of actionable
item: don’t try to do too much all in one sitting.
stin
Ju

Leader at C
SmartBear ol
lie
r
Think about your code review process and how you approach it. Are you guilty
of trying to review large chunks of code in one sitting? How effective has this
been for you and your team?
Consider implementing a new approach where you break up the code
review process into smaller, more manageable chunks of time, focusing on
400 lines of code or less in each session. How could you implement this in
your team’s workflow? How could you ensure that everyone is aware of this
new approach and understands its benefits?
Reflect on the impact of this change on the quality of your code and the
productivity of your team. Keep track of your progress and reassess your
approach regularly to continue improving.
36
o n ab
ti
le
ac DAY
37
ss
aw
e
s
e
omen To succeed in test automation, it’s critical to approach it as a soft-

ware development initiative. This means that if you’re building a
framework and you lack programming experience, it’s important to
practice programming and gain basic program design skills. This
doesn’t necessarily require obtaining a computer science degree,
but rather learning from your mistakes and constantly pushing the
envelope.
Don’t be afraid to fail, as mistakes and failures are essential for
learning and improving. With this in mind, it’s crucial to have a strong
foundation and understanding of how software and programs are put
together. This knowledge will help you create sustainable, maintain-
able, and supportable software that can withstand the test of time.
So start by embracing test automation as a software development
initiative, learn to program, practice, and keep pushing the boundaries
to make your efforts a success.
Paul
EPISODE 90: testguild.com/90 Automation

Initiative Creator
i
r
f
and Architect iz z a f
First, in honor of Paul, fin some classic heavy metal to listen to on Spotify, and
then think about a new skill you want to develop or an initiative you want to
undertake.
Instead of focusing on perfection or fear of failure, approach it like a soft-
ware development initiative. Practice, experiment, and make mistakes as
you go along. Learn from your mistakes and keep improving. Recognize that
failure is a necessary part of the learning process, and view each setback as
an opportunity to grow and innovate.
By approaching new challenges with a software development mindset, you
can build a solid foundation for sustainable, supportable, and maintainable
success.
37
o n ab
ti
le
ac
DAY
38
ss
aw
e
s
e
omen Ensure that you have real-world conditions when testing your
system. This means setting up an isolated system. In my case, it was
having a warehouse that looks like a real warehouse, and filling it up
with actual inventory levels. Also, ensure that the system you are test-
ing is not interfered with, and that you capture every function call and
all the data sent to different components to debug the system. This
will help you get the right response time and make sure you are doing
something realistic.
Additionally, when dealing with complex deliveries, find smart ways
to hook into the program and reproduce the function call over to the
system. By following these steps, you can ensure that your testing is
accurate and reliable, which will help you improve the performance of
your system.
H ele n
EPISODE 37: testguild.com/p37 Managing

Director
B
a l ly
Think about a recent project or system that you tested. Did you have real-
world conditions set up for testing? Did you simulate real-life scenarios to
ensure that the system performs optimally?
If not, brainstorm ideas on how you can create real-world conditions for
your next project. Think about how you can set up an isolated system that
closely resembles the environment where the system will be deployed. What
data can you use to fill the system and ensure it is realistic?
Also, consider how you can capture all function calls and data sent to
different components during testing. How can you ensure that the system is
not interfered with during testing? Finally, explore ways to reproduce function
calls for complex deliveries and hook them into the program to ensure accu-
rate and reliable testing.
By focusing on real-world conditions, you can help improve the perfor-
mance and reliability of the system, leading to a better user experience and
fewer issues in production.
38
o n ab
ti
le
ac DAY
39
ss
aw
e
s
e
omen As far as test management efforts, I think the critical thing is that
teams, as they take a look at their current process around testing and
test management, look at it from the perspective of how tightly does
this process work with the overall needs of the software delivery
requirements that the business has. Is it meeting those needs?
And come out of the box from how they thought of test management
in the past and go to it from the perspective of, well, what does business
require in terms of visibility? What would make development’s defect,
resolution, et cetera, much more simplified[?] . . . Come to it from that
angle and identify what gaps they see. And then . . . figure out how to
drive or address those particular gaps.
njay
Sa
EPISODE 58: testguild.com/58 Technology

Executive
ia
Z
a
la ad
v
Take some time to reflect on your team’s current process around testing and
test management. How tightly does your process work with the business’s
overall software delivery requirements? Is it meeting those needs?
Challenge yourself to think outside the box and approach test manage-
ment from a fresh perspective. What does the business truly require in terms
of visibility? How can you simplify defect resolution for development?
Identify any gaps you see, and think critically about how to address them.
As the quotation emphasizes, collaboration is key. Consider how you can foster
more collaboration between team members and stakeholders to improve your
test management process. Keep in mind that your goal is to deliver high-
quality software that meets the needs of the business.
39
o n ab
ti
le
ac
DAY
40
ss
aw
e
s
e
omen To take your team’s test automation efforts to the next level, it’s
crucial to start with a holistic approach. Before diving into tools and
technologies, take the time to assess your team’s goals and the
unique factors influencing your environment.
Consider the people around you, policies, and other forces that may
be impacting your testing efforts. By understanding the bigger picture,
you can make informed decisions that are more likely to succeed.
Don’t rush into implementing tools without first understanding the
full scope of the situation. Only then can you accurately determine the
best path forward.
Paul
EPISODE 105: testguild.com/105 Principal at

Beaufort
M
l
Fairmont e r ril
Think about a recent decision your team made regarding test automation.
Take some time to step back and look at the bigger picture. What are your
team’s goals when it comes to test automation? What specific challenges are
you facing in your environment? Who are the stakeholders involved in this
decision? What policies and regulations are in place that may impact your
approach? Analyze these factors and understand the bigger picture. Are you
making any assumptions that may be inaccurate?
What steps can you take to gather more information and make a more
informed decision that takes all of these factors into account?
By taking a more holistic approach, you may be able to make a more effec-
tive decision that considers all the nuances and complexities of your specific
situation.
40
o n ab
ti
le
ac DAY
41
ss
aw
e
s
e
omen As developers, it’s easy to fall into the trap of testing everything
from a technical standpoint, trying to cover all the nitty-gritty details
under the hood. However, this approach often leads to frustration and
confusion, as the complexity of the system can become overwhelm-
ing. Instead, we should focus on testing things from the perspective of
a user of the website. By doing so, we can ensure that our tests cover
the most critical features of the application while also being more
manageable and efficient.
The key is to strike a balance between different types of testing.
Functional tests are essential for covering the bulk of the critical fea-
tures, but they can’t do everything. We need to be strategic in our
approach and use other types of testing, such as unit testing and API
testing, when appropriate. By being fluent in all of these types of testing
and knowing which tool is best for the job, we can be more productive
and successful as developers. So let’s keep the user in mind and focus
on testing what matters most to them.
David
er
Senior Architect
Ca
d
w
d
alla
Think about the last time you wrote a test as a developer. Did you approach it
from a user’s perspective or did you focus solely on the technical details?
Reflect on how this may have impacted the effectiveness of your test. Then
take a critical look at your testing strategy and assess how much time and
effort you’re spending on functional testing, unit testing, and API testing. Are
you allocating your time and resources effectively?
Consider experimenting with different testing approaches and tools to find
the best solution for your team and your users.
Remember, the goal is to ensure that critical features of your application are
covered through testing and that you’re using your time efficiently.
41
o n ab
ti
le
ac
DAY
42
ss
aw
e
s
e
omen What I would suggest, and something that I think has helped me
a lot in my software testing career, is perhaps don’t focus just on
software testing. . . . Psychology and human behavior, particularly
emotional intelligence software testing, is a human activity. As testers,
we’re the messengers, where we’re gathering the information; we’re
helping light the way of the project. And so to do that, we need to
deliver a lot of unfortunate, lousy information to stakeholders that
sometimes think their products are brilliant. But perhaps they aren’t so
excellent, and the way that we deliver that information is so critical. We
can’t just hand over the bad news and say, here you go, your product
sucks. We need to be a little bit more intelligent than that.
I think emotional intelligence and aspects of that help a great deal.
Suppose we can pick up on what is the best way to deliver that infor-
mation, not to offend anybody, and to hopefully help us sell that
information and get the changes in the product that we think should
be in there to make the product better, to help the company make
more money and whatever it is that you’re trying to achieve personally
and for your organization.
So think outside software testing. Don’t just focus purely on software
testing. There’s a lot of other industries and sciences and so on out
there that we can study that will help us with our software testing.
David
EPISODE 96: testguild.com/96 Senior Architect

G
s
r
ee
e
nle
Think about a challenge you had when delivering bad news about a product
or project to stakeholders. Reflect on how you approached delivering the
news and on the stakeholders’ reactions. Consider the principles of emotional
intelligence and human behavior that the quotation highlights, and think
about how you could have approached the situation differently to better
handle the delivery of bad news.
Research the concepts of emotional intelligence, psychology, and commu-
nication and see how they can be applied to improve your software testing
approach.
Finally, share your insights with your team and encourage a discussion on
how to incorporate these principles into your testing process.
42
o n ab
ti
le
ac DAY
43
ss
aw
e
s
e
omen The number-one piece of advice to becoming a better communica-

tor is to ask [questions]. It’s the simplest way. But it’s often the most
challenging way for people to get clarity on an idea. There are all kinds
of social norms and cultural reasons [why] people may be afraid of or
less apt to ask questions. But it is often the most effective way, of
simply saying “I need to get more information about this idea so that
we’re on the same page.”
We need to make sure that we’re doing in-depth, deep communica-
tion rather than having a shallow agreement.
mian
Da

Ineffable
s
S
o
y
n
Solutions a din
Think about a recent communication you had with a colleague or team mem-
ber. Were any of the points unclear? Did you leave the conversation feeling
unsure about something? If so, reach out to that person and ask for clarifica-
tion or more information.
Practice active listening and ask open-ended questions to ensure that you
fully understand their perspective and ideas. By doing so, you can improve
your communication skills and develop a deeper understanding of the topics
discussed, leading to more productive and meaningful conversations in the
future.
43
o n ab
ti
le
ac
DAY
44
ss
aw
e
s
e
omen Don’t give up. You know how frustrating it could be. I’ve been there.
But . . . just keep at it and you can end up getting it to do what you need
[it] to do by working through it.
stin
Ju

Engineer at
Applitools Is o n
Think of a task or project related to automation that you’ve been struggling

with or have given up on in the past. What main challenges or roadblocks did
you encounter? Now take a moment to reflect on why you started that task or
project in the first place. What goal or desired outcome were you trying to
achieve?
Next, recommit to that goal or outcome and make a plan to approach the
task or project again. Automation can be a challenging and frustrating
process, but it’s important not to give up. Break the task down into smaller,
more manageable pieces, and approach each one systematically. Don’t be
afraid to try new approaches or seek help from others if needed. With per-
sistence and determination, you can get your automation to do what you need
it to do.
44
o n ab
ti
le
ac DAY
45
ss
aw
e
s
e
omen Asking yourself why every time you do something is crucial. Why?
Well, it helps you understand why you chose that particular path in
the first place. As passionate humans, it can be hard to hear criticism
of our work, especially when it comes to our favorite frameworks.
That’s why finding mentors who can provide constructive feedback is
so important.
To evaluate the quality of test automation scripts, I use a scorecard
with six key areas. First, is it maintainable? Second, is it relevant to the
business? Third, does it have clear traceability? Fourth, is it reusable?
Fifth, is it manageable and scalable? And sixth, is it accessible across
the company?
But that’s not all. The script should also be robust, portable, and
provide actionable insights with dynamic data adapters. Can you use
it to diagnose issues and provide real information to developers?
Overall, it’s important to consider factors such as platform tech-
nology, data source, test type, test approach, element ID technology,
continuous build integration, and maintenance. By using a scorecard
approach, you can ensure your scripts meet all of these criteria and
provide the most value to your team.
natho
o
n
EPISODE 38: testguild.com/38 CTO (Keysight
Eggplant) /
W
Automation Cyborg rig h
t
Think about the last time you wrote a test automation script or executed a test.
Did you ask yourself why you did everything you did? Consider the six different
areas of what makes the perfect test automation script: maintainability, rele-
vance, traceability, reusability, scalability, and accessibility. Using these areas
as a scorecard, evaluate the test automation script or test that you last worked
on. Did it meet all the criteria? If not, what areas could be improved?
Think about how you can incorporate actionable insights and dynamic data
adapters to make your test automation more robust and portable. Reflect on
the benefits of asking why every step of the way and finding mentors who can
provide support and offer a different perspective. How can you apply these
principles to your future testing work?
45
o n ab
ti
le
ac
DAY
46
ss
aw
e
s
e
omen When you’re choosing tools or when you’re trying to automate,

think about what is important for the business and not what is impor-
tant for your résumé. This is something I see happening often in our
industry. Remember that whatever adds the most business value is
what is going to take you higher in your organization. And also, it’s
going to help the business that you’re actually employed with.
aya
ar
n
EPISODE 135: testguild.com/135 Creator
of Sahi
R
a m an
Think about the tools and automation you’re using in your work. Are they
aligned with your organization’s goals and priorities or are they primarily
focused on adding new skills to your résumé?
Reflect on the impact these tools have on the business and how you can
better align your choices with the organization’s needs. Identify areas where
you can make changes to focus more on adding business value and work
toward implementing those changes.
Remember that prioritizing the business’s needs can help you grow within
your organization and contribute to its success.
46
o n ab
ti
le
ac DAY
47
ss
aw
e
s
e
omen Set and meet skills growth targets every quarter, I would say, would
be my piece of advice. Learn something new that’s important to your
career. So, for example, if you’re a black box tester and you don’t know
how to program, learn in the next three months how to write scripts.
And then three months after that, learn how to program. . . . As things
continue to evolve, it’s going to be important to keep up.
Rex
EPISODE 148: testguild.com/148 President at

RBCS, Inc. B
l ac k
Think about your current career goals and what skills you need to develop to
achieve them. Set specific skills growth targets for the next quarter that will
help you move toward those goals. Write down actionable steps you can take
to learn and practice these skills, and make a plan to dedicate time to work on
them regularly.
Remember to track your progress and celebrate your accomplishments
along the way.
By consistently setting and meeting skills growth targets, you’ll not only
stay up to date with industry changes, but also become a more valuable asset
to your team and organization.
47
o n ab
ti
le
ac
DAY
48
ss
aw
e
s
e
omen To improve your API test automation effort is a more general tip. Just
start exploring your applications and see whether there is anything
that you’re currently testing at the user interface level that you can
also check sufficiently (and just as effectively) on the API level. Or
maybe even on the unit test level. Don’t think that you have to do
everything through the user interface.
Try to explore. Ask around or use a tool like Fiddler to examine your
application to see what APIs are available, what business logic they
expose, and how you can leverage those for more efficient automation
in general.
Bas

OnTestAutomation
a
D
ĳ
kstr
Take some time to assess your current testing efforts and identify areas
where you could potentially improve your API test automation. Make a list of
tasks or tests you’re currently doing at the user interface level that could be
automated more efficiently by shifting to the API or unit test level. Then start
exploring your application to identify the APIs that are available and the
business logic they expose.
Look for opportunities to leverage those APIs to create more efficient and
effective automated tests. Finally, set a goal to implement at least one new
API test automation effort in the next quarter and measure the impact of this
shift on your testing process and results.
48
o n ab
ti
le
ac DAY
49
ss
aw
e
s
e
omen I think if there is one piece of advice, it is to have a quality dash-

board. Everything today is within your CI/CD. It’s actually running
behind the scenes. You need this visibility. Start with measuring the
important quality metrics . . . [on] a quality dashboard that everyone
will see. For every build, you need to understand what was tested.
What’s the status? What’s the coverage? Is it improving? Is it decreas-
ing? Do you have quality goals or not? Make sure you have a quality
dashboard for every build, and [make sure] it’s a centralized one so
everyone can share it: developers, QA, DevOps, and management.
Er a n
EPISODE 147: testguild.com/147 Co-founder at

SeaLights
Sher
Think about the quality metrics that are important to your organization and
what you want to communicate to different stakeholders with a quality
dashboard. Consider the challenges in creating such a dashboard that is
informative, easy to understand, and actionable. Brainstorm ways to collect
the data you need and visualize it in a way that will be impactful for your
team. Finally, discuss with your team how the quality dashboard can be used
to drive continuous improvement, and ensure that everyone is aligned on the
importance of quality for your product.
49
o n ab
ti
le
ac
DAY
50
ss
aw
e
s
e
omen I think the most significant difference I see between testers and the
results they achieve is based on how many conversations they have
with the people around them. Even if you’re the most awesome tester
ever, if you’re not talking to your developers, product owners, and
business analysts about what they’re doing and why, your testing will
be less effective. You haven’t taken input about what other people
have already tested, why this thing was designed the way it was, how
customers expect this thing to behave, and what information from
testing will be valuable. Without those conversations, you increase the
risk of delivering stuff from testing that people find irrelevant.
So the biggest piece of real advice that I would give to a tester is to
go talk to people, and do it more than you think you should have to.
Actively seek out what other people are doing and why.
atrina
K
CTO / Author
of A Practical
Guide to Testing C
l o kie
in DevOps
Think about the last project you worked on. How many conversations did you
have with the people involved in the project? Did you talk to the developers,
product owners, business analysts, and customers? Did you ask them what
they’ve already tested, why the system was designed a certain way, and what
information would be valuable to them from your testing?
If you didn’t have these conversations, think about how you can start having
them. Who can you talk to and what questions can you ask to get a better
understanding of the project and how you can contribute to it? How can you
build relationships and foster communication within your team?
If you did have these conversations, think about how you can improve their
quality and frequency. Can you reach out to more people or have deeper con-
versations with the people you already talked to? Can you proactively seek
feedback and incorporate it into your testing process? Remember, effective
testing is not just about finding bugs; it’s also about providing valuable insights
and feedback to your team and stakeholders.
50
o n ab
ti
le
ac DAY
51
ss
aw
e
s
e
omen Even if you are not interested in committing to the Selenium project,
there is still so much value in getting familiar with the underlying
codebase. There are a lot of patterns and understanding that you can
gain by looking at the source code in GitHub.
If you are trying to build some functionality on top of Selenium, it’s
important to maintain those patterns for consistency. But even if you’re
not, you can still benefit from the good information about how some of
the functionality works behind the scenes, which is contained right in
the source code.
This advice applies to any other open source project you might be
working on.
Hu gh
EPISODE 139: testguild.com/139 SDET
l
M
il
c
C
a m ph
Explore an open source project that you’re interested in, even if you don’t plan
to contribute to it directly. Get familiar with the underlying codebase and the
patterns that are used, and consider how you might be able to apply some of
these patterns to your own projects for consistency and efficiency.
Reflect on what you can learn from the source code and how it can help
you gain a deeper understanding of how the functionality works behind the
scenes. Then think about how this experience can help you become a better
developer and can benefit your future work.
51
o n ab
ti
le
ac
DAY
52
ss
aw
e
s
e
omen As a quality analyst, it is important to pay attention to accessibility

testing as it is crucial for the user experience and abiding by the laws
of the respective countries. To make accessibility testing easier, con-
sider using a web automation framework like Cypress, which offers
advantages like running in the same loop as the application, providing
native access to DOM elements, and showing hidden shadow elements
of shadow DOM elements. Additionally, use an accessibility engine like
AXE to automate the accessibility testing process and give timely
feedback to the development team about any violations. Overall,
making accessibility testing a part of the quality assurance process
will ensure that the products are accessible by everyone and enhance
the user experience.
g
ra ati
P
EPISODE 376: testguild.com/a376 Senior Product

Manager at S
ThoughtWorks
a
ha
rm
How can we ensure that technology is inclusive and accessible to everyone?

Is it enough for companies to simply follow laws and regulations related to
accessibility, or should they strive for more? In what ways can automated test-
ing tools like Cypress and AXE help make accessibility testing more efficient
and effective? And what are the ethical considerations involved in prioritizing
accessibility in software development and testing?
52
o n ab
ti
le
ac DAY
53
ss
aw
e
s
e
omen My best advice is to start finding new ways to gather metrics on your
automated test runs. This includes things like pass/fail rates, execu-
tion times, and if possible, processor and memory usage. By capturing
this data, you can begin to analyze it in creative ways to gain deeper
insights into your testing process.
G re g

Craft of Testing P
l
aska
Reflect on how you currently gather and analyze metrics for your automated
test runs. Consider what information you’re currently tracking and how you’re
using it to improve the quality and efficiency of your tests. Spend some time
learning about new and creative ways to gather and analyze data related to
your test runs.
Consider metrics such as processor usage and memory usage, and think
about how they could be used to identify potential performance issues and
optimize your tests. Experiment with new tools and techniques for gathering
and analyzing this data, and think about how you can use it to improve your
test automation process.
Finally, reflect on how these efforts can help you become a more effective
and valuable automation engineer, and how you can use the insights you’ve
gained to make a positive impact on the quality and efficiency of your organi-
zation’s testing efforts.
53
o n ab
ti
le
ac
DAY
54
ss
aw
e
s
e
omen The best advice I can give to anyone who is struggling with auto-
mation is that you’re dealing with the real world. Chaos is part of the
real world. There is no way to escape it completely. The best way to
deal with this kind of stuff is to remember a saying from Bruce Lee:
“Be like water.” You’re not going to stop a river, but you can divert it.
If you take that and apply it to your tests, it’s a great way to think
about it.
Mat t
EPISODE 108: testguild.com/108 Executive

Director
r
B
a
rbou
Reflect on the challenges you’ve faced with test automation and how you’ve
dealt with them. Consider how you’ve approached difficult situations and
how you can improve your response to chaos and unexpected events in your
automation process. Spend some time learning about the concept of being
flexible and adaptable, like water, in the face of uncertainty and change.
Consider how this mindset can help you respond to unexpected events in
your test automation process. Think about how you can identify the “river”
in your test automation process and find ways to divert it in a more positive
direction.
54
o n ab
ti
le
ac DAY
55
ss
aw
e
s
e
omen The bottom line is to take automation seriously, and that will take
you very far. I see this with test design a lot. And then I talk about it and
people say, yeah, that’s a good idea. But then they go into the project
and they start mindlessly clicking buttons again. They forget about the
business level and focusing on risk areas. At some point, if you don’t
take it seriously, you’ll pay the price.
Ha n s
EPISODE 130: testguild.com/130 CTO at

LogiGear
a
B
u
wa l d
Reflect on how seriously you take automation in your testing efforts. Consider
how much thought and effort you put into your automation design and how
much you prioritize automation in your overall testing process.
Spend some time learning about best practices in automation design and
how to create a solid structure that aligns with the business level. Challenge
yourself to incorporate these best practices into your automation design and
testing process, and think about how you can take automation more seriously
in your approach.
55
o n ab
ti
le
ac
DAY
56
ss
aw
e
s
e
omen Please think about maintainability when you write any test. That’s
the number-one thing. A lot of people write tests that only they will
understand, or they don’t think of anyone else. If you’re giving the test
to somebody else, will they understand it? People forget about that.
So think about how other people are going to use it before you write
anything.
Anil
EPISODE 132: testguild.com/132 Head Of
Ka
y
Engineering
t
d
imis et
Reflect on how you approach test design in terms of maintainability. Consider

how much thought you put into making your tests understandable and acces-
sible to other members of your team.
Spend some time learning about best practices in test design for main-
tainability and how to create tests that are easy for others to understand and
use. Challenge yourself to incorporate these best practices into your test
design and think about how you can make your tests more maintainable for
the benefit of the entire team.
56
o n ab
ti
le
ac DAY
57
ss
aw
e
s
e
omen I think everyone should be early adopters of tools and technology.

We should always be looking for continuous improvement. If we im-
prove ourselves personally, that will naturally allow us to be a model
for others and hopefully improve our overall software development
lifecycle. Always look for ways to improve. So, if you find yourself
repeating a task, whether it’s adding data manually or testing the
same type of scenario over and over again, take a few seconds and ask
yourself: is this something that can be automated?
And don’t let that be the end-all: if it can be automated, where will
I spend my time (assuming that it will save me time in the long run)?
Maybe that means you have more exploratory testing sessions, or you
can focus on a particular area that you have not been able to focus on
that you really want to. So it’s not just about [asking] “can it be auto-
mated?” but taking it to the next step and asking “once it is automated,
what will I do with that newfound time?”
elissa
M
EPISODE 123: testguild.com/123 Director,

Quality
Engineering To
nd
i
Think about areas of your work where you may be able to automate repetitive
tasks to save time and improve efficiency. Reflect on how automation can help
you focus on higher-level testing and exploratory work that can add more
value to your organization’s testing efforts. Identify a task or scenario that
you find yourself repeating often, and brainstorm ways in which it could be
automated. Consider the potential benefits and drawbacks of automating this
task and think about how it fits into the larger context of your organization’s
testing strategy.
Finally, challenge yourself to act and implement an automation solution for
the identified task or scenario, and track the results in terms of time saved and
increased productivity. Use this newfound time to engage in exploratory test-
ing or other high-value activities that will help improve the overall quality of
your organization’s software development lifecycle. By continuously seeking
ways to improve and optimize your testing process, you can become a model
for others and make a significant impact on your organization’s overall testing
strategy.
57
o n ab
ti
le
ac
DAY
58
ss
aw
e
s
e
omen The thing that has helped me the most in my career and given me
the most bang for my buck is to never stop learning. Regardless of
your field, it’s important to take some time out of your day to learn
something new. Don’t just rely on your 9-to-5 job. Maybe take half an
hour or an hour to improve your skills even further.
There are so many benefits to this approach. For example, con-
stantly improving your skills means you’ll always have job options
since you’ll stay up to date with the latest technologies. When it’s time
for you to reenter the field, the market will welcome you because you’ll
have the skills they’re looking for.
I’ve seen individuals using outdated technologies and skills for test-
ing applications, and it’s not a good situation. One guy was working for
a year testing an application, and he couldn’t get a single test going
because he was trying to use QTP on a tablet, which was nearly impos-
sible. I had to teach him Selenium, WebDriver, and some program-
ming, and finally he was able to get up to speed. Imagine if his boss
wasn’t understanding and decided to lay him off. He would have reen-
tered the job market with outdated skills and uncertain job prospects.
To avoid this scenario, keep learning and growing. This way, you’ll
always have job options, and you’ll be really good at your job. Plus,
learning is enjoyable and can help you enjoy your work more.
kolay
Ni
EPISODE 143: testguild.com/143 Dev Advocate

Ad
in
at Sauce Labs v
k
olod
Think about a skill you’ve been meaning to improve or learn but haven’t due
to lack of time. Consider setting aside a small amount of time each day, even
just half an hour, to focus on learning and practicing that skill. This could be
through online tutorials, in-person courses, or even practicing on your own.
Challenge yourself to learn something new each day, and don’t forget to
keep track of your progress along the way. By making a commitment to con-
tinuous learning and growth, you’ll not only improve your skills and job
prospects, but you’ll also feel more confident and fulfilled in your work.
Remember, the most successful people are those who never stop learning.
58
o n ab
ti
le
ac DAY
59
ss
aw
e
s
e
omen Everyone should preserve their right to indignation. Please think

about that. When you maintain your right to anger, you are unassail-
able. If you take the time and energy to work on your craft, view it as a
job between medical school or until you develop the next app that
orders pizzas. When your brain gets hungry, that’s fine.
However, if you accept quality engineering, quality analysis, and
quality services as a craft that evolves, you want to make sure that
you are educated and that you preserve your right to indignation. You
never want someone to say, I feel like you could have done this better;
you could have done this differently; you could have followed better
practices. So educate yourself, find out what’s right, and attend local
meetups.
If there isn’t a local testing meetup in your area, I encourage you to
start one. Do yourself a favor and find other people like you to discuss
what works and what doesn’t.
gor
re
G
y
EPISODE 118: testguild.com/118 Scrum Master
S
t
ch
mid
What does it mean to preserve your right to indignation? How can you use
your indignation to fuel your passion for your craft and drive you toward
excellence?
Consider taking some time to reflect on your work as a quality engineer or
analyst. Are you satisfied with the quality of your work or do you feel you could
be doing better? Are you up to date with the latest practices and technologies
in your field or are you falling behind?
If you feel there is room for improvement, think about how you can learn
more about your craft. Look for local meetups or other opportunities to
connect with like-minded individuals and discuss best practices. Don’t be
afraid to express your indignation when you see something that could
be done better. Channel that energy into a positive force that drives you to be
the best quality engineer or analyst you can be.
59
o n ab
ti
le
ac
DAY
60
ss
aw
e
s
e
omen Make sure your tests are atomic, meaning they are independent
and don’t have any dependencies on other tests. Many times, I have
seen people use dependency injections for each test, and if test A
completes, then run test B, which can create cyclic dependency
issues. To avoid this, write tests that are atomic, simple, and fast. Break
your tests into smaller units and run them in parallel. This will save you
a lot of time and provide quicker results.
nshul
A
EPISODE 149: testguild.com/149 Engineering

Lead Quality S
a
ha
rm
Think about the tests you’ve written so far. Are they atomic, independent, and
fast? If not, refactor them. Break them down into smaller, more manageable
units and run them in parallel. This will help you save time and give you
quicker results. Consider the dependencies your tests might have and try to
eliminate them.
Now take this a step further. Think about how you can apply the concept of
atomicity beyond just testing. Can you break down your tasks or projects into
smaller, more atomic units? How can you ensure that these units are indepen-
dent and don’t have dependencies on other tests?
Finally, consider the benefits of atomicity, independence, and speed
beyond just saving time. How can these concepts help you and your team be
more efficient and effective in your work? What other areas of your work could
benefit from atomicity and independence?
60
o n ab
ti
le
ac DAY
61
ss
aw
e
s
e
omen One piece of advice to any developer is to constantly be on the

lookout for good new testing and development tools, and to continu-
ally evaluate new technologies. There may be a tool that can really
make your life easier. It might not be Cypress, but maybe some other
tool. If you don’t try it, you’ll never find out.
G le b
DR PH.D. /
Senior Director
v
B
a
Of Engineering hm
ut
o
Think about a project or task you’ve been working on for a while. Are there any
repetitive or time-consuming tasks that you can automate or optimize with
new tools or technologies? Take some time to research and evaluate some
new tools that may help you improve your workflow or make your job easier.
Don’t be afraid to try new things and experiment with different tools. You
might be surprised at how much time and effort you can save by adopting new
technologies.
Remember, staying up to date with the latest tools and technologies is a
key factor in being a successful and efficient developer.
61
o n ab
ti
le
ac
DAY
62
ss
aw
e
s
e
omen If you’re interested in performance engineering, the first thing you

need to do is get curious about the transactions happening behind
the scenes. To do this, hook up a sniffer, like a network sniffer such as
Fiddler, Firefox Firebug, or Chrome Network Inspector. You should
look at the posts, the gets, the API calls, and the traffic.
Once you have the transactions, the next step is to make the sce-
nario realistic by adding think times to get the scripts to act like real
human beings. To create a realistic throughput, you can use weblogs to
understand the scalability and reproduce the transaction flow in your
load test, which leads to accurate results. It is essential to test in an
environment that closely mimics production in both configuration
and hardware, where you will get scalability numbers and accurate
results.
Finally, try to integrate hybrid tests, where 90% of the load is driven
via the network and the rest can be a user load that can be done in a
number of ways. You can use a real user load or a browser user load,
and you can capture response times using tools such as Fiddler running
on their machine.
e cc
eb
R
a
Solutions C
d
Engineer li
nar
How can performance engineering techniques and tools be adapted to

improve an application’s user experience? Consider a scenario in which a
popular ecommerce website is experiencing slow page load times, resulting
in a decrease in sales. How can you use performance engineering tech-
niques to diagnose and resolve the issue, while also ensuring a positive user
experience?
Discuss the importance of realistic scenarios, accurate throughput, and inte-
gration of hybrid tests, and explain how using tools such as network sniffers
and weblogs can help in identifying and fixing performance bottlenecks.
Finally, discuss the trade-offs between performance and other factors,
such as usability and security, and how to strike a balance between these
competing priorities when designing and testing an application.
62
o n ab
ti
le
ac DAY
63
ss
aw
e
s
e
omen If you want to excel in software development, make a habit of read-

ing about best practices and incorporating them into your work as
much as possible. This investment in yourself will pay off handsomely
over time.
While technology is constantly evolving and becoming outdated,
the fundamental principles of software development have a much
longer lifespan. By honing your skills and expertise in this area, you’ll
be well-equipped to adapt to new technologies and stay ahead of
the curve.
So keep up with the latest best practices and make them a regular
part of your development routine. Your future self will thank you for it!
dim
la i
r
EPISODE 77: testguild.com/77 Pluralsight
Author
v
K
h
o r i ko
Think about the software development best practices you use and consider
how they have benefited your work. Reflect on any practices that have
become outdated or are no longer effective in your current environment. Next,
challenge yourself to identify at least one new software development best
practice that you can learn and practice over the next month. This could
involve learning about agile development, test-driven development, or other
modern development practices.
Consider how this new practice might improve the quality of your work or
the efficiency of your team. Finally, remind yourself that while technology
evolves rapidly, the fundamental principles of software development endure
over time. By continuing to learn and practice best practices, you can build a
strong foundation for your career in software development.
63
o n ab
ti
le
ac
DAY
64
ss
aw
e
s
e
omen Don’t look at your tests as just a checkbox, but take a step back and
ask, what am I trying to test? Ask yourself if there is actual business
value in those tests. And ask what the business value of those tests is
and what it is about the feature that you’re trying to put under the
microscope.
Rob
EPISODE 24: testguild.com/24 Lead

Software
F
Engineer
l
rie s e
Analyze a test you wrote or are currently working on. What is the business
value of this test? Why is it important for the application or feature it is testing?
Consider whether there are any additional tests you could write to increase
the business value of your test suite. Reflect on how understanding the
business value of your tests can help you prioritize testing efforts and better
communicate the value of testing to stakeholders.
If a test isn’t adding business value and/or isn’t worth keeping, delete it.
Share your insights with your team and see if they have any additional per-
spectives to add.
64
o n ab
ti
le
ac DAY
65
ss
aw
e
s
e
omen I generally think that because we get so excited about writing our
test scripts and discovering new things, we don’t think about execut-
ing them right away in an independent environment. So the one piece
of actionable advice is to avoid wasting your time and turning your
machine into a test executor. Instead, start building your delivery
channel as early as you can to run your tests against an independent
environment.
aciek
M
SRE Tech Lead
z
Ko
ic
n
ko w
lo
Think about how you currently execute your tests. If you’re running them on
your local machine, consider the benefits of running them in an indepen-
dent environment, such as being able to detect issues that may not arise on
your local machine. Challenge yourself to start building your CI/CD early so
that you can run your tests against an independent environment as soon as
possible.
Things to consider include what tools and resources you need to make this
happen and how you can optimize your testing process to ensure that you’re
not wasting time and resources. Act today and start building your delivery
channel to run your tests in an independent environment.
65
o n ab
ti
le
ac
DAY
66
ss
aw
e
s
e
omen What I would suggest is that when you look at anything . . . come up
with different ways of looking at that object, item, or . . . scenario. Come
up with a different way to look at it and to think about it, and then ask
yourself questions: the hows, the wheres, the whens, the whys, and the
whos. Who would benefit from it? Who would not benefit from it?
Those kinds of things are what inspire me. And I really do focus on
my questions. When I do that, that’s when ideas start coming really
strong. So really focus, I think, on the why, where, and when. I think
those are the really important questions, especially when it comes to
mobile testing.
n An
ea
n
EPISODE 169: testguild.com/169 Principal Test
Engineer
n
H
a
r ris o
Choose an object, item, situation, or scenario that interests you and try to think
about it from different perspectives. Ask yourself questions. Why is it like that?
Where did it come from? How does it work? When was it created? Who uses
it and who doesn’t? What are its potential benefits and drawbacks?
Try to think of as many different angles as possible and explore the topic
deeply. This exercise can help you develop your critical thinking skills and
inspire you to come up with new ideas and perspectives, which can be valu-
able in mobile testing and any other field.
66
o n ab
ti
le
ac DAY
67
ss
aw
e
s
e
omen So the one piece of advice that I always give is to go for value. If
it’s not going to provide value now, later, or at some point, if it’s not
going to bring value, if it’s not worth your time, don’t do it. Do some-
thing else. That is the one piece of advice I can really give, and it
applies to everything.
But obviously, I’m focused on automation. Think about value as
opposed to anything else first, and then a lot of the other decisions will
just fall out from there. I think you’ll make more responsible decisions
that way.
Paul

Architect
i
G
r
f
iz z a f
Think about a task or project you’ve been working on. What value does it pro-
vide? Does it align with your goals and the goals of your team or organization?
Will it ultimately benefit the end user or customer?
If you find that the task or project doesn’t provide much value, consider
discussing it with your team or manager to determine if it’s worth continuing
or if it’s better to shift your focus to something more meaningful. By focusing
on value, you can ensure that you’re making the most of your time and
resources and contributing to meaningful outcomes.
67
o n ab
ti
le
ac
DAY
68
ss
aw
e
s
e
omen I think people need to keep their ears to the ground in terms of new
technologies, especially ways to automate test cases, because, to me,
that’s really the key to increasing coverage and reducing risk. And
then, as they create more test cases, they have to find ways to set up
a framework so that they can prioritize, scale, and parallelize their
executions. Then they have big data-like reporting because the more
test cases you have, the more data you need to plow through. And you
need to know how to group and identify trends in your test cases.
Amir
EPISODE 164: testguild.com/164 Sr. Director,

Product
g
R
r
o
ze
Management nbe
Think about the last time you learned about a new testing technology or
approach. Did you dive in and try to understand it, or did you dismiss it as
something you didn’t need at that time?
Challenge yourself to be more proactive in keeping up with new develop-
ments in the testing industry. Make it a habit to read about new technologies,
attend webinars or conferences, and network with other professionals. Then
think about how you can apply these new ideas to your own testing strategy.
How can you use automation and big data to increase coverage and reduce
risk in your organization’s testing? What frameworks or tools can help you
prioritize, scale, and parallelize your test executions?
By keeping up with new technologies and being open to new ideas, you can
improve your testing process and drive better results.
68
o n ab
ti
le
ac DAY
69
ss
aw
e
s
e
omen Actually use the product that you’re developing and make sure your
test cases reflect how somebody is going to use it. Also, make sure
your unit tests reflect that use case and that you’re actually using the
feature in the product. I know it sounds basic, but I think it’s very impor-
tant. If you just focus on that aspect, on the use aspect, on how it’s
going to be used, then the testing and implementation all sort of fall
in line behind that use case.
aqa
Ed
EPISODE 153: testguild.com/153 Writer,
y
Programmer o
rto ra
When you developed or tested your last product, did you really use it like an
end user would? Did you explore all the features and use cases?
Put yourself in the shoes of your target audience and use the product
extensively. Then revisit your test cases and unit tests to ensure that they
reflect real-world usage scenarios. Ask yourself whether the tests capture the
potential issues a user might encounter. By doing this, you’ll be able to
improve the quality of your tests and ensure that the product meets the user’s
expectations.
69
o n ab
ti
le
ac
DAY
70
ss
aw
e
s
e
omen I think one thing every tester, especially those testing iOS apps,
should do is avoid keeping the integration cycle too long. If you have
long-running scenarios that take weeks or months to complete,
adopting better advanced testing strategies can help reduce app
shipping time.
Speed is key going forward, and techniques like DevOps, CI, and CD
allow you to ship builds faster. So try to avoid long regression cycles.
Continuously learning new technologies, such as what’s happening in
AI/ML, is crucial.
Self-education will help you make smart tool selections, so attend
conferences, learn something new every day, and try new things.
Exploration is key.
hika
as
h
n
S
t
EPISODE 199: testguild.com/199 Xcode
Engineer J
ag p
ta
Think about the last time you tested an app and reflect on the time it took to
complete the testing cycle. Did it take longer than you expected? If so, what
were the reasons for the delay? Were there any long-running scenarios that
could have been optimized?
Make a list of possible strategies you could adopt to reduce app shipping
time, such as using DevOps, CI, CD, and advanced testing techniques. Also,
think about the last time you learned something new in the field of mobile
testing.
How often do you engage in self-education and exploration?
Make a commitment to attend a conference (like automationguild.com),
learn new things every day, and try new things to continuously improve your
skills and stay up to date with the latest technologies.
70
o n ab
ti
le
ac DAY
71
ss
aw
e
s
e
omen My approach to better understanding or solidifying my knowledge

of anything is a process of consuming information, building with it or
working with it, and then teaching about it.
So my piece of advice to you to solidify your testing capabilities is
to consume information about it. But don’t stop there. You should start
implementing what you learn, whether that’s in projects at work or
personal projects for practice. In that process of practice, you will learn
a lot. I recommend that you share the things you learn with other
people. And if you feel uncomfortable sharing it, you should at least
write a blog post and keep it to yourself.
But do something to try and teach it, because that is where you will
solidify your understanding of it and realize whether or not you actu-
ally understand it when you start to try and teach it.
nt C
Ke .
EPISODE 195: testguild.com/195 Software

Engineer and
Educator D
odds
Think of a testing topic or technique that you want to understand thoroughly.

Spend time consuming information about it, whether through reading articles,
watching videos, or taking online courses.
Then create a personal project to implement the technique or use the
knowledge you gained. As you work on the project, take notes on what you
learn and the challenges you face.
Finally, try to teach what you learned to someone else, whether through a
blog post, a presentation, or a conversation. Use the teaching experience to
reinforce your understanding of the topic and identify any gaps in your knowl-
edge that need further exploration.
71
o n ab
ti
le
ac
DAY
72
ss
aw
e
s
e
omen First of all, you need to write your integration tests in such a way
that they can be automated. Many people write integration tests that
involve some manual interactions or require manual preparation of the
testing environment before they can be run. To make your integration
tests reliable and able to be run frequently, you must eliminate any
manual steps. Therefore, you should write your integration tests in a
way that they can be automated and easily integrated into your contin-
uous delivery process without manual intervention. Only then can you
execute your tests reliably and frequently. When creating integration
tests, make sure to automate them completely, end to end.
ristop
h
h
Creator of the
Citrus Integration
h
Testing Framework
D
e
p pis c
How can you create more automated end-to-end integration tests in your
current project? Look at your current integration tests and assess which ones
have manual interactions or require manual setup steps. Then brainstorm
ways to automate those steps and refactor your tests accordingly.
Consider using testing frameworks, tools, or even custom scripts to auto-
mate the manual parts of your tests. Additionally, you can investigate incor-
porating continuous delivery practices into your workflow to ensure that your
tests can be executed reliably and frequently.
By making these changes, you can increase your confidence in your testing
and reduce the risk of errors caused by manual intervention.
72
o n ab
ti
le
ac DAY
73
ss
aw
e
s
e
omen For mobile testing, make sure to utilize each layer of the mobile test-
ing pyramid. Use desktop browsers with mobile simulation for exten-
sive functional testing and responsive design. Test mobile simulators
and emulators for functional testing, user flows, and visuals. Focus on
usability testing and real-life conditions for real devices. For instance,
perform testing with different network conditions and integrate with
GPS and background apps. It’s important to test under various scenarios
to ensure the app works well in different environments.
Kwo
EPISODE 172: testguild.com/172 Test

Automation
Consultant Din g
How might you improve your mobile testing strategy by incorporating differ-
ent layers of the mobile testing pyramid, and what are the potential benefits
of doing so? Think about the types of tests you are currently performing, and
consider how you might utilize functional, usability, and real-world testing to
improve the quality of your mobile app. What challenges might you face in
implementing this approach, and how can you overcome them?
Take some time to research the different tools and techniques available for
each layer of the pyramid and start incorporating them into your testing
process.
73
o n ab
ti
le
ac
DAY
74
ss
aw
e
s
e
omen Two things that I think automation engineers should always consider
are, first, having a great synchronization strategy. There are four syn-
chronization methods that every tester should have in their toolbox:
checking if something exists, [checking] if something does not exist,
waiting for something to exist, and waiting for something to not exist.
The second one is related to object identification. When it comes to
locators, I tend to standardize on two to three properties at most. I can
usually come up with a great locator with just two properties. I recom-
mend avoiding anything that has to do with the look and feel of the
application, such as a class name. Although it’s popular to use CSS
class names in locators, I think that it’s the last thing you should try to
use. Try to find an ID or something else that’s more reliable.
G re g
EPISODE 158: testguild.com/158 Author of Test

Automation in
P
the Real World
l
as
ka
Reflect on your synchronization strategy and object identification methods in

your automation testing. Do you have the four synchronization methods down
pat? Can you standardize your object identification to two to three properties?
Evaluate your current methods and consider implementing changes to
improve the reliability and efficiency of your automation testing. Additionally,
explore alternative synchronization and object identification strategies to
expand your toolbox and increase your proficiency in automation testing.
74
o n ab
ti
le
ac DAY
75
ss
aw
e
s
e
omen There’s a little game I like to play called “Why are we testing?” Over
my 20-plus years in the industry, I’ve answered this question differ-
ently many times. The answer changes as I think more deeply about
what I’m trying to achieve with my testing, what process I’m doing,
and as I’ve repeatedly asked and thought more profoundly about that.
I’ve thought more about the philosophy of what we’re actually doing,
particularly in the intermediate type of tester. They tend to be very
focused on “I am doing this testing because somebody else is asking
me to do this testing”; “the customer wants me to do it this way”; “my
manager wants me to do it this way.” And it often means when you
move from one project to the next, you tend to copy and paste what
you’re doing: on my last project, we did this; why don’t we do this?
I think the way to become a great tester is to think more about why
you’re doing things. What’s the benefit? . . . Is it a waste of time because
you can do this more efficiently? Those are the key questions to ask
yourself for every process that you follow, every activity that you do.
That kind of challenge makes you think much deeper about what
you’re trying to do with testing.
M i ke
EPISODE 193: testguild.com/193 Technical

Product Owner
Ta
lks
Think about your current testing process. Are you simply following instruc-
tions or copying what you did on a previous project without considering the
unique needs of your current project?
Challenge yourself to think deeper about the philosophy of what you’re
doing and the benefits of each activity in your testing process. Are there more
efficient or effective ways to achieve your goals?
Make a list of the key questions to ask yourself for each process and activ-
ity, and commit to incorporating this deeper level of thinking into your testing
approach going forward.
75
o n ab
ti
le
ac
DAY
76
ss
aw
e
s
e
omen If you’re looking to bring quality into your team, it’s crucial to involve
everyone and not make the mistake of thinking that agile means elim-
inating quality experts or QAs. There’s still plenty of room for quality
evangelists who can provide a unique perspective and ensure that
quality is prioritized in the development process. The challenge is
finding ways to make quality more appealing and engaging to the rest
of the team, as well as implementing automation and tools like Sonar
to enforce quality standards.
This requires elevating awareness and visibility through techniques
like dashboarding and actively engaging with developers to ensure
that quality is not left behind in the race to deliver features quickly. So
hop on the train of development and stay engaged with your team,
keeping your ears open to their perspectives while making sure they
hear yours.
Quality is a team effort, and by working together, you can create
better software that meets the highest standards of excellence.
s war
ha a
Sa
n
am
am
Su
b
r n
a
m a nia
What techniques can you use to make quality more appealing and engaging
to your team? How can you bridge the gap between quality engineers and
developers so that they work together in a more integrated way?
Think about ways to increase awareness and visibility of quality issues, and
how automation tools like Sonar can be leveraged to enforce quality standards
in a collaborative and inclusive way. Consider how you can create a culture
of continuous improvement where everyone on the team is committed to
delivering high-quality software, and how you can effectively communicate
the value of quality to the broader organization.
76
o n ab
ti
le
ac DAY
77
ss
aw
e
s
e
omen The most practical and easily doable piece of advice I have for
people who want to improve their testing is to get involved in the
community. It’s important because you’ll gain access to many different
perspectives and sources of information. All of a sudden, you’ll have a
support group of hundreds or thousands of people with various expe-
riences and perspectives that you can learn from.
You should also share your knowledge and experience. Giving
back is crucial, and I believe everyone has something to contribute.
By getting involved in the community, you’ll have access to all this
knowledge and support, making it easier to realize that you too have
something to contribute. It’s a great way to stay on top of new devel-
opments in technology, which are always changing. Being connected
to people and the community is an excellent way to stay informed.
ssand
a
r
a
EPISODE 167: testguild.com/167 Quality Coach,
Software Tester H
. L g
eun
How connected are you to the testing community? Whether it’s through online
forums, social media groups, conferences, or meetups, getting involved in the
testing community can have a significant impact on your growth as a tester.
Take a moment to assess your level of involvement and consider how you
can increase your engagement. Can you find a local testing meetup to attend
or join an online forum? Can you start sharing your knowledge and experi-
ences with others?
By building relationships and exchanging knowledge with others in the
community, you can enhance your learning and career opportunities, and stay
up to date with the latest trends and technologies in the field.
77
o n ab
ti
le
ac
DAY
78
ss
aw
e
s
e
omen The best thing you can do for your automation is to put your test
automation into the dev code. This will help you in so many ways. The
first one is accountability. Automation code is development, so devel-
opers should be looking at it, commenting on your code, and helping
you with better ways of doing things. At the same time, you should
develop your automation test code according to their standards. The
automation code is essential, so put it in the dev code.
Another thing that many automation people miss is that writing the
automation part is easy. Keeping them running and having them give
useful feedback is the hard part. Anyone can pick up a test automation
tool, write a few cases, and think their job is done. But a good engineer
follows through. Even years down the line, their automation code
should still run reliably and provide useful feedback.
yaj
at it
S

M
u
alug
Think about the current state of your test automation efforts. Have you been
keeping your automation code up to the standards of the development
code? Have you been collaborating with developers to ensure that your auto-
mation is running smoothly and providing valuable feedback? If not, consider
putting your test automation into the development code. This will give you
accountability, help you maintain standards, and encourage collaboration
with developers.
Review your automation code, involve your colleagues, and make sure
your automation is providing value to your team for years to come. Take the
necessary steps to make this happen and see how it improves your automa-
tion efforts.
78
o n ab
ti
le
ac DAY
79
ss
aw
e
s
e
omen To improve your testing skills, definitely follow the DRY pattern,
which is Don’t Repeat Yourself. So look through your code. You proba-
bly have some steps that you do a lot of times. Go ahead, pull it out,
refactor it, make it cleaner, and make it easier to maintain. By doing so,
you can avoid redundancy and make your code more efficient.
n d re w
A

Kr
ug
Think about your testing process and identify any repetitive steps that you do
frequently. Analyze your code and try to find any redundancies or duplications
of code that you can refactor to follow the DRY pattern.
Consider ways to streamline your testing process and make it more effi-
cient, such as creating reusable functions or scripts. Reflect on the benefits of
reducing redundancy in your testing and the impact it could have on your
productivity and the quality of your work.
Take action to implement these changes and observe how they affect your
testing process over time.
79
o n ab
ti
le
ac
DAY
80
ss
aw
e
s
e
omen Something actionable about improving the Cucumber tests is

making sure that you make really fast Cucumber scenarios. Check out
the GitHub application todo-subsecond. It’s a small web app I cre-
ated to demonstrate subsecond full-stack acceptance tests using
Cucumber. It will teach you design patterns you can use for devel-
oping end-to-end test runs in milliseconds. That’s a great way to learn
about how to do this.
l ak
As

Cucumber
y
H
e
llesø
Think about the time it takes to run your current Cucumber scenarios. Are
they taking too long? Could they be faster? Look at the todo-subsecond appli-
cation on GitHub and see how it’s designed to run subsecond full-stack
acceptance tests using Cucumber. Try to apply the same design patterns to
your own tests and see if you can reduce their runtime.
Not only will this make your testing more efficient, but it will also give you
more time to focus on other areas of testing or development. And who knows,
you might even discover some new techniques that will improve your testing
skills and make you a better tester!
80
o n ab
ti
le
ac DAY
81
ss
aw
e
s
e
omen I think that if I have one piece of advice for anyone about automa-
tion, it would be around transferability. Test automation today, regardless
of what tool you use, whether it’s Selenium, UFT, Test Architect, et
cetera, should be designed with the idea that someone else other
than you will execute and maintain it. That person should be able to
analyze your tests, explain your results, and maintain both the test and
its results. I think transferability requires transparency in the way that
you design tests.
You should also consider the business perspective. At the end of
the day, automation is being pushed to the forefront because people
see it as a business benefit and solution to compete. Therefore, think
of building your test asset as part of the business. It’s not about writing
the code or anything else; it’s about being a big part of the business
solution.
ng Q
Hu .

LogiGear N
g u yen
Think about how transferable your test automation is. Review your existing
automation tests: could someone else easily understand and maintain them?
Consider how you can make your test cases more transparent and easier to
analyze so that anyone in your team can get insights from them.
Also, think about the bigger picture and how your test automation fits into
your company’s business solution. How can you align your automation tests to
better serve the overall business objectives?
Take the time to reflect on these questions and make any necessary adjust-
ments to your test automation approach to ensure transferability and alignment
with the business.
81
o n ab
ti
le
ac
DAY
82
ss
aw
e
s
e
omen My company spends time with hundreds of teams building cutting-

edge products. What I see is that the teams that are really at a high
level of performance are adopting a more product- and user-focused
approach to their work.
So they’re thinking about the user journey and how to ensure that
they have the right amount of testing coverage. They identify the user
journeys that our users are actually exercising and find the correct
data from tools like Google Analytics, Mix Panel, et cetera, to prioritize
them. They make sure that there is robust coverage for those user
journeys, regardless of how quickly our product is changing. This may
mean that small changes don’t get the right coverage because the QA
team is more focused on testing the product as it’s used by their users
rather than trying to cover every line of code that developers check in.
Dan
EPISODE 182: testguild.com/182 Co-founder

of mabl B
r
el
che
Think about the user journeys of your product or service. Look at the data in
tools like Google Analytics and Mixpanel to identify the most important jour-
neys to your users. Then assess your testing strategy and ensure that you have
robust coverage across those journeys, even if it means deprioritizing certain
code changes or updates.
Consider adopting a more product- and user-focused approach to testing,
and work with your team to shift the testing mindset toward user satisfaction
and coverage of the most critical user journeys.
82
o n ab
ti
le
ac DAY
83
ss
aw
e
s
e
omen When it comes to accessibility testing, establish an organizational

level of commitment. Perhaps find a key stakeholder within your com-
pany and make them responsible for accessibility. Give them some time
to learn about accessibility, as that’s something essential. Ensure the
UX architects, who design the UX, use the global experience language
(GEL) to create wireframes in a more accessible way.
And most importantly, have the developers use these tools as they
develop the UI components to check for accessibility defects right as
they develop. Let’s not push it off to later testing or even to the actual
people with impairments.
anoj
M

Relations
K
umar
Think about your organization’s level of commitment toward accessibility

testing. Is there someone in your organization who can be a champion for
accessibility? Are your UX architects designing wireframes with accessibility
in mind? Do your developers have tools to check for accessibility defects as
they develop? Take the time to assess your current approach to accessibility
testing and consider ways to improve it. Can you establish a clear organiza-
tional commitment to accessibility?
Can you encourage your team to prioritize accessibility at every stage of the
development process? What steps can you take to make your products more
accessible to people with disabilities?
83
o n ab
ti
le
ac
DAY
84
ss
aw
e
s
e
omen The best advice I can give is to have fun with your testing adventure,
whether it involves a single test case or a million test cases running
together. If you’re not enjoying it, then your career choice or pathway
can become very mundane. Remember that everyone experiences
highs and lows, so you need to work through them. Know your limits,
understand them, work past them, and have fun. For automation test-
ing and concurrency, focus on making things small and fast, and
tweak as necessary. Review, review, and review again, and be okay
with the possibility of failure.
M ik e
EPISODE 168: testguild.com/168 Director

of Quality M
Engineering i l g at e
Think about the last time you worked on a testing project. Did you enjoy the
experience? If not, why not? And if you did, what made it fun? Reflect on your
answer and make a list of ways to inject more fun into your testing work. Per-
haps it’s as simple as setting aside time to learn a new testing tool, or maybe
it’s joining a testing community or group. Whatever it is, make sure to incorpo-
rate it into your testing practice.
Also, try breaking down your testing tasks into small, manageable chunks
so that you can focus on making them fast and efficient. Lastly, don’t be afraid
to ask for feedback and learn from your mistakes. Remember, having fun and
enjoying your work is key to a fulfilling and successful testing career.
84
o n ab
ti
le
ac DAY
85
ss
aw
e
s
e
omen Never stop reflecting back at what you do and improving by way of
thinking out of the box, because you’re only as good as your last hour.
rushy
u
a
G
m
Sr. Director,
Platform
Engineering M
ony
Reflection and continuous improvement are essential to personal and pro-

fessional growth. Take some time to reflect on a recent project or task you
completed. What successes and challenges did you encounter, and what did
you learn from them?
Now think about how you can apply these insights to your future work, and
how you can incorporate new ideas or approaches to help you continuously
improve. Challenge yourself to think outside the box and experiment with new
strategies or techniques. Remember, you’re only as good as your last hour, so
make every hour count toward your growth and development.
85
o n ab
ti
le
ac
DAY
86
ss
aw
e
s
e
omen If you’re considering using blockchain technology, thoroughly test

any applications you develop on top of it. Because the technology is
nascent, there have already been instances where people have lost
millions of dollars due to faulty applications.
While some good tools and frameworks are being developed to aid
development and testing, it’s essential to understand that intersection
with machine learning is also necessary for effective testing. There-
fore, when developing applications on top of blockchain technology,
it’s essential to focus on testing to ensure the technology is reliable
and secure.
i an
Rh
Developer,
Cryptocurrency Le
Revolution wis
The emergence of blockchain technology has revolutionized various indus-

tries, and its adoption is increasing at an unprecedented pace. However, with
great potential comes great responsibility. Today’s quotation emphasizes the
importance of thoroughly testing blockchain applications to ensure their
reliability and security.
Considering this, ponder the following questions:
• What are the potential risks of faulty blockchain applications and

how can they be prevented?
• How can machine learning be effectively integrated into
blockchain testing to enhance reliability and security?
• What are the ethical implications of developing blockchain
applications without rigorous testing, given the potential for
financial loss and other negative consequences?
• In what ways can society balance the need for innovation with
the responsibility to ensure that new technologies are safe
and trustworthy?
Reflect on these questions and consider how you can develop and imple-
ment blockchain technology in a way that maximizes its potential while
minimizing risks and negative consequences.
86
o n ab
ti
le
ac DAY
87
ss
aw
e
s
e
omen I would encourage testers to focus on the fundamentals of testing.

My advice is to not forget the essence of the software testing game.
The goal is to gather information, not to automate everything. Testing
and automation are two separate entities.
Testing can’t always be reduced to discrete procedural units called
test cases.
Michael Bolton once stated that a recipe is not cooking, a . . . Power-
Point [file] is not a conference talk, and a sheet of music is not a musical
performance.
Similarly, a test case is not the same as testing. You can conduct
testing without test cases, and you don’t necessarily need tools or
automation to do so.
Ingo

Strategist P
hili p p
Reflect on the role of automation in your testing process. Are you relying too
heavily on automation, or do you find that you’re using it as a tool to sup-
plement and enhance your testing efforts? Go back to the fundamentals of
testing and think about what you’re trying to achieve.
Consider how you can use data to inform your decisions, and explore alter-
native methods of testing beyond just test cases and automation.
Embrace a holistic approach to testing that goes beyond tools and frame-
works and prioritizes the goal of gathering information about the software
you’re testing.
87
o n ab
ti
le
ac
DAY
88
ss
aw
e
s
e
omen Automation should only be used to enhance testing, not replace

it. Many people mistakenly believe that new automation means
manual testing goes out the window, but that’s not true. It’s a big mis-
conception to think that automation will take over the field of testing
completely.
r
La ry

klassi-js
d
G
o
d da r
Today’s quotation highlights the importance of using automation to enhance

testing, not replace it. This means manual testing and other forms of testing
should still be used in conjunction with automation. To reflect on this idea,
think about how automation is used in your testing process. Do you rely solely
on automation to test your software, or do you use it to enhance your testing
efforts?
What are the pros and cons of using automation in your current testing
approach? Are there any areas where manual testing may still be necessary or
more effective?
Consider these questions, and use your reflections to make any necessary
adjustments to your testing process.
88
o n ab
ti
le
ac DAY
89
ss
aw
e
s
e
omen Regardless of the tool or framework you use, it’s crucial to have a
structured approach to creating your framework and to design your
test cases to be both modular and atomic. By atomic, I mean that each
test case should be an individual entity and not heavily dependent on
other components.
When test cases and frameworks are not structured properly,
parallel testing can be challenging. However, if you design them in a
clean, modular manner, it will be much easier to conduct parallel
testing successfully.
aghav
R
Founder of
Automation
Step-by-Step Pa l
Think about the current state of your test framework and test cases. Do you
have a structured approach in place, and are your test cases modular and
atomic? Take some time to review your current test cases and framework to
ensure that they’re structured in a way that allows for easy parallel testing. If
you find that your test cases depend on multiple components or that your
framework isn’t modular in nature, consider refactoring your code to create
cleaner and more structured test cases.
Remember that well-structured frameworks and test cases will not only
help you with parallel testing, they’ll also make it easier for you to maintain and
update your tests in the long run.
89
o n ab
ti
le
ac
DAY
90
ss
aw
e
s
e
omen Rather than simply trying to solve the current issue you’re facing,
take some time to reflect on where you see your API testing needs
going in the future. Adding API testing as part of your CI/CD pipeline
may not allow for proper functional uptime monitoring or provide
much value to your development team, who are continuously looking
to improve the platform. Therefore, consider all these aspects before
making a decision, especially since many customers reach a wall after
months of work, which may require them to re-platform and redo
everything.
So, before diving into using a downloadable application or building
a platform from scratch, a build versus buy discussion should be taken
seriously due to unforeseen constraints that may arise.
trick
Pa
EPISODE 214: testguild.com/214 VP of Product

P
o u li n
Think about the future of your API testing needs beyond just solving the issue
at hand. Consider the different aspects of your development and the potential
constraints you may face. Then evaluate whether it’s more beneficial to build
your platform from scratch or to use a downloadable application. Have an
honest and open-minded build versus buy discussion with your team and
stakeholders to ensure that you’re making the most strategic and informed
decision for your organization.
Remember, by taking the time to consider all the potential constraints, you
can avoid reaching a wall and having to redo everything down the line.
90
o n ab
ti
le
ac DAY
91
ss
aw
e
s
e
omen Recognize that digital transformation is difficult for everyone involved,

and discipline is key. It’s essential to ensure that you understand, learn,
and apply the necessary discipline. Finally, don’t give up, as achieving
high quality is a worthy goal. If you stick with it, the results will pay off
in spades.
il e s
ha
h
R ao
Think about a time when you or your team underwent a significant change or
digital transformation. What were some of the challenges you faced? Did you
have the discipline and resilience to stick with it, or did you give up?
Reflect on what did and didn’t work during that process, and identify what
you could have done differently to achieve better results. Consider what you
could do to cultivate discipline and resilience in yourself and your team, and
how you can apply these qualities to your current or future projects to achieve
high-quality results.
91
o n ab
ti
le
ac
DAY
92
ss
aw
e
s
e
omen When it comes to writing tests, it’s essential to think about future-
proofing. You don’t want to spend hours creating tests that become
obsolete as soon as the application changes. Instead, consider adding
layers of abstraction to your tests to make them more flexible and
reusable.
So, what exactly does adding a level of abstraction mean? Let’s say
you need to click a button or fill out a form in your test. Rather than
doing it directly in the test, take a step back and think about what
you’re trying to accomplish. Are you adding a product to a shopping
cart or filling out a registration form? Once you understand the higher-
level goal, you can create a utility method that handles all the logic for
that action. For example, you could create a method called “submit
registration form” that fills out all the fields and clicks the submit button.
By abstracting the implementation details into a utility method, you
can reuse it in multiple tests, and if the application changes, you only
need to update the utility method, not every test that uses it.
Don’t make the mistake of thinking it’s easier to skip the abstraction
layer or that you’ll be long gone from the company by the time the app
changes. Trust me, it’s a slippery slope that will come back to haunt
you. Even if you’re not around when the change happens, it’s not great
for your karma points. So take the time to future-proof your tests and
create a solid foundation for your testing framework.
drian
A
Senior
cu
Th
Software
o
e
Development
s
do re
Manager
Think about your current approach to writing tests and consider whether
you’re adding levels of abstraction to your tests to future-proof them. If you
aren’t, try taking a step back and identify what your tests are really trying to
achieve. From there, create separate utility methods that handle those actions
and interactions and encapsulate them with a name that’s easy to understand.
Doing this will make it easier for you to write tests, future-proof them, and
update them when the application changes.
Taking the extra time now to add this abstraction layer will save you time
and headaches in the long run.
92
o n ab
ti
le
ac DAY
93
ss
aw
e
s
e
omen My view of being agile or moving to faster releases does not mean
you can compromise on your users’ quality or user experience. If going
more agile or adopting a DevOps style means that you run fewer tests
or invest less in quality just to release faster or smaller versions in a
short amount of time, then don’t do that. Don’t compromise on your
quality, because fixing a defect in development time costs much less
than fixing it in production time. Do not sacrifice quality for quantity.
isha
Av i
EPISODE 244: testguild.com/244 Senior Product

Manager M
a
oshk
Think about how you can strike the right balance between speed and quality
when it comes to software development. Evaluate your current development
processes and ask yourself if you are compromising on quality to deliver faster
or smaller versions of your product. Are you running fewer tests or investing
less in quality to meet release deadlines? Take a step back and consider the
long-term consequences of such compromises. Are you potentially setting
yourself up for bigger problems in the future that could cost you more time
and money? If so, brainstorm ways to optimize your development process
without sacrificing quality.
How can you improve your testing and quality assurance practices to
ensure that your product meets high standards of quality, while still releasing
updates in a timely and efficient manner?
93
o n ab
ti
le
ac
DAY
94
ss
aw
e
s
e
omen I’ve been talking to people about this recently, and one of the
things that people have said that I think is really interesting is to build
relationships. A lot of the time as a tester, I can go to somebody else
on the team who’s not a tester and say: “How can I help you? What
could we do together to solve a problem?” And it could just start with
something personal: “Hey, how’s your day going? Nice weather we’re
having today.” Just build on those personal relationships and start
collaborating together.
Because I really do believe we need the whole team. We need
diverse skill sets. We need diverse perspectives. We need to work
together. And we need to connect as humans first to be able to do that.
So I would say, go out and forge some new relationships.
Lisa
Co-founder of
EPISODE 218: testguild.com/218 Agile Testing
Fellowship C
ris pin
Think about the relationships you have with your colleagues and team mem-
bers. Are there opportunities to build stronger connections and collaborate
more effectively? Consider reaching out to someone you haven’t worked
closely with or who has a different role or perspective. Start by finding
common ground and building rapport, and then explore how you can work
together to solve problems or improve processes.
Strong relationships are built on mutual respect, trust, and communication,
so be open and honest in your interactions and be willing to listen and learn
from others.
94
o n ab
ti
le
ac DAY
95
ss
aw
e
s
e
omen With all the new tools and technologies popping up every day,
like AI and machine learning, I like to consider how I can incorporate
these new tools into my current processes. However, if the effort
required to integrate the new tool outweighs the benefit it provides,
then I need to reconsider whether it’s worth pursuing.
Before starting with new tools, it’s important to carefully consider
all the necessary steps to ensure that they will be effective in the
long run.
Diego
Contributor and
EPISODE 208: testguild.com/208 Maintainer of
the Selenium M
o lin a
Project
Think about a new tool or technology you’re considering implementing in your

current process. Ask yourself: What specific benefits does this tool offer that
are worth the effort and resources required to integrate it? Are there any
potential downsides or risks associated with using this tool that you need to
be aware of? Are there any other steps you need to take before integrating the
tool, such as training or reorganizing your workflow?
Finally, consider whether the cost–benefit ratio is favorable to your team
and organization, and whether the potential improvements outweigh the risks
or costs. Reflect on your answers and make an informed decision based on
your analysis.
95
o n ab
ti
le
ac
DAY
96
ss
aw
e
s
e
omen For me, asking questions has always been the way forward. I love
learning, so I’m not afraid to not know something, and I enjoy finding
out about it; joining in the next conversation, realizing that I don’t know
something and then asking again.
I do like the people who say that QA means question asker, and I
think that is one of the biggest skills that we have. Because tools
change, processes change, projects change, and people change in
the projects, we have to be able to adapt to lots of new situations, and
asking questions is one of the best ways to do that.
A le x
CEO &
ck
Sc
Head of
e
la
h
Quality deb
Think about the last time you encountered something you didn’t understand
or were unsure about at work. Did you feel comfortable asking questions
about it? If not, what held you back? What could you do to overcome those
barriers and become more comfortable with asking questions? And if you did
ask questions, how did that help you learn and adapt to the new situation?
Consider how you can incorporate this skill of asking questions more delib-
erately into your work, and how it can help you navigate the constantly changing
landscape of tools, processes, and people in your job.
96
o n ab
ti
le
ac DAY
97
ss
aw
e
s
e
omen Don’t jump into selecting an automation tool or technology right

away. Whether you’re evaluating new options, or entering automation
as a new profession, or looking to adopt more automation for your
organization, consider which solution can bring the most robustness
and automation, which can give you the speed to align with your con-
tinuous delivery.
And lastly, most importantly, don’t just look at automation in silos,
but have a [simple] solution that can handle your web, file interactions,
APIs, and databases . . . without having to hire an army of developers
to accomplish it. Look at these core aspects before you select a solu-
tion, framework, or tool.
jee
ul t
G
Chief of
EPISODE 315: testguild.com/a315 Products &
N
Strategy at
l
ag u
pa
ACCELQ
The last time you or your team evaluated an automation tool or technology,
what approach did you take? Did you jump straight into selecting a tool with-
out considering the bigger picture?
Take some time to reflect and assess whether the tool you chose was the
best fit for your needs. If you’re currently considering implementing auto-
mation, use this quotation as a guide and think about what aspects are most
important for your organization’s automation needs. Remember to look
beyond just one aspect, such as speed or robustness, and consider how the
tool can handle different aspects of your application architecture.
97
o n ab
ti
le
ac
DAY
98
ss
aw
e
s
e
omen The number-one thing is to not be intimidated by artificial intelli-

gence (AI). Build your own from scratch, use a vendor, do whatever you
can, just don’t be intimidated by it. People who were threatened by AI
were the same people who were intimidated by mobile or by the web.
Unfortunately, many of those people now don’t have jobs or are one of
the 30 COBOL testers on the planet.
Change is coming, so don’t be shy about it. Be aware of it, read
about it, play with it. You don’t have to be an expert AI person; nobody
really is these days. It’s all still pretty new, so don’t be afraid of it.
s on
Ja
Founder of
Test.AI, Author
A
of How Google rbon
Tests Software
What’s one thing related to AI that you’re curious about but have been too
intimidated to explore? Research it, read articles or watch videos, and then
experiment with it yourself. Start small, and don’t worry about being an expert.
Use your curiosity as a driving force to learn more about AI and its potential
applications.
With any new technology, it’s okay to make mistakes and to learn as you go.
So don’t be afraid of AI. Embrace the opportunities it offers, and stay curious.
98
o n ab
ti
le
ac DAY
99
ss
aw
e
s
e
omen If you don’t already know what’s happening in your production envi-
ronment, my first actionable advice would be to talk to someone who
supports your software in production day to day or try to get access to
the monitoring tools they use to figure out what’s happening. That’s an
excellent first step towards building your awareness of what happens
after you’re finished with your software development.
It’s important to understand what your users are actually doing and
how the people who support your software determine whether it’s
behaving correctly or not. Developing this understanding is an excel-
lent first actionable step.
atrina
K
CTO / Author
EPISODE 233: testguild.com/233 of A Practical
Guide to Testing C
l o kie
in DevOps
In your development process, are you fully aware of what happens to your
software after you’re done with development? If not, take the first actionable
step and talk to someone who supports your software in production day to
day. Find out what monitoring tools they use to figure out what’s happening in
the production environment.
Try to develop a deeper understanding of what your users are doing and
how your software is behaving. This can help you improve your development
process and deliver better-quality software to your users. Remember, building
this awareness is an ongoing process, so keep learning and improving.
99
o n ab
ti
le
ac
DAY
100
ss
aw
e
s
e
omen The main starting point if you want to try to adopt BDD is to have the
conversation up front. Before starting to invest in development, meet
with all the stakeholders: a product owner, tester, and developer. This
is where we create most of the value. You can use Post-its for this or
tools like Hiptest, but the tool is not the most important thing. Having
the conversation and creating a shared understanding is definitely the
biggest outcome of BDD.
u re n
La
t
Entrepreneur
and Product
Leader Py
Think of a project or feature you’re working on or will be working on soon.

Identify all stakeholders involved in the project, including the product owner,
tester, developer, and any other relevant parties.
Once you have a clear understanding of who is involved, schedule a meet-
ing with them to have a conversation about the project. During this meeting,
use tools such as Post-it Notes or Hiptest to help facilitate the conversation,
but remember that the tool is not the most important thing. The goal of the
conversation is to create a shared understanding among all stakeholders
about the project’s requirements, goals, and expectations.
By taking this approach, you can create more value for the project and
improve collaboration and communication among all parties involved.
100
o n ab
ti
le
ac DAY
101
ss
aw
e
s
e
omen For me, even though we use Selenium and have our own frame-
work, which works well, I still continue, as an automation engineer, [to]
explore other products. For example, I’ve been playing with Katalon,
which is a nice-looking product that I find quite easy to use. I have also
been experimenting with the new Selenium IDE. Currently, I’m looking
at implementing Docker.
As a tester, I believe we should never stop learning. There are so
many products out there, and we should give each one a chance to
prove itself. We should always look for the best solution that fits our
company’s needs. So my advice is to never be content with what we
have, but to keep exploring and find out what else is out there.
e
ich ll
M
e
EPISODE 236: testguild.com/236 Senior Test
Automation
d
l
a
Engineer c
Dona
Think about the automation tools and technologies you use in your job. Are
there any new tools or products you’ve heard of but haven’t had a chance to
explore yet?
Take some time to research and experiment with a new tool or technology.
Consider how this new tool could be integrated into your current processes
and whether it would bring added value to your work. Remember, as the
speaker suggests, it’s important to never stop learning and exploring new
products.
101
o n ab
ti
le
ac
DAY
102
ss
aw
e
s
e
omen I’ve found the best way to make time to learn something new, like
automation, is to schedule it, whether it’s after work or during work. In
my experience, my managers and colleagues are supportive of engi-
neers who want to learn new things. If you express your desire to learn,
they will often help you and allow you to do it on work time.
So my advice is to bring it up and figure out a way to make time for
yourself at work if you want to learn something new. Overcoming the
fear of expressing your desire to learn is the key.
r
Ch i s
EPISODE 253: testguild.com/253 Tester &

Engineer K
enst
Think about a new skill or technology you’ve been wanting to learn. Schedule
some time during your workday to focus on learning that skill. Approach your
manager or supervisor and let them know about your desire to learn, and ask
if you can allocate time during your workday to do so.
Take the first step toward improving your skills and creating a culture of
learning at your workplace. By taking the initiative to schedule time for learn-
ing and expressing your interest to your colleagues, you might be surprised
at how supportive and encouraging they can be in helping you achieve your
learning goals.
102
o n ab
ti
le
ac DAY
103
ss
aw
e
s
e
omen When you’re starting out trying to become a better tester, keep your
base really wide. Look into being an engineer for a little bit; under-
stand how product management works and how they bring accep-
tance criteria to the teams.
Become a jack of all trades and get a wide breadth of roles and
responsibilities before you start to home in on what you want to do.
That’s what I did for the first few years. I found that I’m really good at
finding the root cause of defects, fixing defects, and pinning regression
tests around that. So I ended up on a production support team, and
that’s one of the best things that has happened to me in my career.
I would say, keep your mind open and don’t limit yourself by saying
that if your first job was as a software engineer, you’re going to be a
software engineer for the rest of your life, or if you’re a manual tester,
you’ll be a manual tester forever. Explore the different roles and respon-
sibilities that are available to you before you home in on something.
me s
Ja
Pe
n
Architect n
o
nin gt
Think about your current role and the different roles and responsibilities in
your organization. Are there any areas that interest you or that you would like
to learn more about? Make a list of the different roles you would like to explore
and research them further. Try to speak to people who work in those roles and
understand what their day-to-day looks like. Keeping your mind open and
exploring different roles and responsibilities can help you identify what you
enjoy doing and where your strengths lie.
Don’t limit yourself to your current role. Be willing to take on new chal-
lenges and responsibilities to grow your skills and knowledge.
103
o n ab
ti
le
ac
DAY
104
ss
aw
e
s
e
omen The best advice I can offer to help people improve the quality of test-
ing at their company is to get their bosses to buy into the idea of having
an architect. An architect can pave the way and make the software
process run more smoothly. With an architect in place, you’ll have more
work capacity to focus on testing and creating better-quality testing
suites.
Fabio
Director of
Frontend
N
Development ol
sc
o
Think about the current testing process in your company. Are there any road-
blocks or bottlenecks that are hindering your ability to produce high-quality
testing suites? If so, consider having a conversation with your boss about
the idea of hiring an architect to help pave the way for smoother software
processes. What benefits could an architect bring to the table? How could it
help you and your team focus more on testing and improving the quality of
your work?
Brainstorm some potential arguments you could make to convince your
boss to invest in an architect and put together a plan to present your case. The
goal is to improve the quality of testing in your company, so be creative and
think outside the box when it comes to finding solutions.
104
o n ab
ti
le
ac DAY
105
ss
aw
e
s
e
omen If you’re just starting with chaos engineering, here’s a scary-sounding

but essential piece of advice: focus on critical systems, not the easy
targets. Why? Because when you intentionally introduce failure into a
vital operation of a critical system, you can demonstrate to others the
importance of what you’re doing and the positive impact it can have.
By prioritizing critical systems, you’re more likely to uncover sig-
nificant issues that need fixing, like bugs, infrastructure problems,
configuration errors, paging, and monitoring issues. Some examples
of critical services include your database storage layer, traffic layer
(for example, engine X or Apache), proxy, or caching layer (such as
mem cache). Starting with running MySQL locally on your desktop
and injecting failure is a great way to ease into it before moving on
to production.
So go ahead, dive in, and focus on the critical systems!
mmy
Ta
EPISODE 246: testguild.com/246 VP Product

B
utow
Think about a critical system in your organization or project that you’re respon-
sible for testing. Reflect on the possible negative impact of a failure in the
system and identify some of the underlying causes of failures. Then consider
how you could use chaos engineering techniques to test the system and
uncover potential failure points.
What specific failure scenarios could you simulate, and how could you
measure the impact of those failures on the system? Finally, plan to run a
chaos engineering experiment on the critical system, focusing on one or two
key failure scenarios, and share the results with your team and stakeholders.
Remember, start small and focus on critical systems, not low-hanging fruit,
to maximize the impact of your chaos engineering efforts.
105
o n ab
ti
le
ac
DAY
106
ss
aw
e
s
e
omen The emphasis for me is always on pushing. I know we need to get

the wording right, but making people appreciate that automation is
about more than just checking and testing, and it’s more than just
coding. The skills needed to succeed go beyond coding. The idea
behind the theory is that if you understand the method and can do
all the work before writing the code, there’s always someone better
than the automation engineers and the SDETs in a company to write
the code, and they’re called developers. So, if you can do all that work
up front, you can just hand it to someone else to actually implement.
a
ich rd
R

Ministry of
w
r
a a
Testing dsh
Think about a project or task you’re working on that involves automation or

coding. Consider the time and effort you’ve put into it so far, and ask yourself
whether you’ve focused enough on the method and work that go into it before
writing the code.
Reflect on the quotation and consider the idea that the skills needed to
succeed in automation involve far more than coding. How can you approach
the work differently to ensure that you’re doing all the necessary work up front
and not just coding? How can you better appreciate the value of automation
beyond checking and testing?
Think about how you can communicate this to your team or manager to
help them understand the importance of this approach.
106
o n ab
ti
le
ac DAY
107
ss
aw
e
s
e
omen When it comes to writing test scripts, one of the biggest challenges
is avoiding duplicated code. You don’t want to end up with multiple
copies of the same code scattered throughout your test suite. The
solution is to abstract your tests in a way that makes it easy to reuse
code and eliminate redundancy.
One effective way to achieve this is by using simple keywords to
abstract your code. For example, in our automation framework, we use
keywords like page, form, view, dialog, and overlay to abstract our
code. So, instead of copying and pasting the same code over and over,
we can simply call a keyword like app.autologin or nav.scheduling. The
actual code to execute that specific action is abstracted and lives
somewhere else in our framework.
The beauty of this approach is that it makes our test scripts read like
plain English, without all the technical jargon. And if something
changes in a form or navigation, we only have to update the code in
one place, and it automatically gets reflected in all our test scripts.
So take a close look at your test scripts and see where you can
abstract your code. By moving duplicated code to an abstraction layer,
you can keep your test scripts clean, readable, and easy to maintain.
And that, my friends, is the key to a successful testing framework.
se y
Ca
EPISODE 231: testguild.com/231 Director of QA

& Automation
l
C
a
Architect
l
ntwe
In the test scripts you’ve written for your automation framework, do you notice
any duplicated or copied code? Reflect on the impact this could have on your
scripts, such as making them difficult to maintain and update. Consider ways
to abstract your code to remove duplicated code and make your tests more
readable. Think about what keywords you could use to make your test scripts
more readable and easier to update.
Challenge yourself to implement these changes in your framework and
observe the benefits of having more maintainable and efficient tests.
107
o n ab
ti
le
ac
DAY
108
ss
aw
e
s
e
omen When it comes to creating a test suite, don’t get caught up in trying
to do too much. Instead, focus on the basics. Every API endpoint
should have a smoke test that’s complete enough to ensure a well-
formed response and an acceptable response time.
The goal is to never have a testing backlog. This means that when
someone touches an endpoint, they also update the corresponding
test. So always make sure there’s at least a basic test for every end-
point, and avoid letting a backlog build up. Remember, it’s not accept-
able to have a backlog, so stay on top of your testing!
aus
Kl
EPISODE 209: testguild.com/209 Head Of Product

Management at
d
eu
N
BlazeMeter hol
Think about your current testing process and assess whether you have a test-
ing backlog. If you do, come up with a plan to eliminate it.
Start by identifying your critical API endpoints and creating a basic smoke
test for each of them. Make sure the test is complete and clearly defines what
a well-formed response looks like and how quickly you want it to come back.
Ensure that every time someone touches an endpoint, they also touch the test
and update it if necessary.
By eliminating your testing backlog, you can ensure that every piece of
code you build is thoroughly tested, and you can catch potential issues before
they become significant problems.
108
o n ab
ti
le
ac DAY
109
ss
aw
e
s
e
omen As testers, we have a fantastic opportunity to collaborate with the

development team, especially when working with new technologies
like augmented and virtual reality. Sometimes the developers working
on these projects might be experiencing these APIs for the first time,
which provides us with an ideal chance to educate ourselves.
My advice is to spend a few hours creating a straightforward AR or
VR experience on Unreal or Unity. Doing this will give you context and
a deeper understanding of how these apps are created. You’ll learn
about marker databases and where they can reside, which opens up
possibilities to mock data, set up devices for testing more efficiently,
and ask fewer questions.
Another great tip is to be more integrated with developers. At the
beginning of the year, I moved my desk into the development cube,
which has made a massive difference in my work. Now when I’m work-
ing on something and [I’m] unsure of what’s going on, I can turn around
and ask the developers. They can come over, and within minutes, we
can discuss any problems or surface issues and work on resolving
them quickly.
BJ
EPISODE 220: testguild.com/220 QA Lead
e
b
erle
Augmented reality (AR) and virtual reality (VR) are still new technologies, and
it’s an excellent opportunity for testers to align themselves with the develop-
ment team by educating themselves on these technologies.
Take the initiative to learn more about AR and VR by going to Unreal or Unity
and creating a simple AR or VR experience. Spend a few hours creating a
simple project, and you’ll get perspective and context as to how these apps
are created.
Also, consider sitting with the development team. Move your desk to their
cube and make a concerted effort to be more integrated with them. Being in
close proximity to the developers allows you to get quick answers to ques-
tions and to surface issues promptly, which is essential when working on new
and emerging technologies.
109
o n ab
ti
le
ac
DAY
110
ss
aw
e
s
e
omen In today’s fast-paced business world, time is not just a precious

commodity, it’s the key to growth. Everyone is in a never-ending race
to release to the market faster. However, rushing and releasing half-
baked products can have severe financial implications.
Don’t compromise on quality just because the board, the CTO, and
the CEO are pushing for a quicker release. Instead, find ways to make
your development process more efficient. If that means using new
tools, adapting to new methodologies, or moving to a different tech-
nology, don’t hesitate. You have to make your own advantage in a
market full of easily replaceable applications, software, and SaaS
solutions. And the number-one advantage you can have is quality.
Customers are willing to compromise on features and be patient if
their product’s quality is high.
Personally, I always prioritize quality in my applications. I’ve seen
software with fantastic UIs and numerous features but with poor
quality, crashing, and buttons that don’t work. Whenever I encounter
such issues, the first thing I do is to seek a refund.
r a el
Is
EPISODE 244: testguild.com/244 Director of

Cloud Product R
a
at IncrediBuild ogoz
Think about a product or project you’re working on. Are you compromising on
quality to meet tight deadlines or to please stakeholders? Take some time to
reflect on ways you can make your process more efficient without sacrificing
quality. This could involve learning new tools, adopting new methodologies,
or making changes to the technology you’re using.
Also consider the long-term benefits of prioritizing quality, such as building
trust with customers and maintaining a competitive advantage in the market.
Take action to make quality a top priority in your work and see how it positively
impacts your project or product.
110
o n ab
ti
le
ac DAY
111
ss
aw
e
s
e
omen First things first: if you find yourself using an XPath that is just a
literal path through your document (/html/body), you’re not doing it
right. Take a step back and see if there’s a better way to go about it.
Secondly, when you call WebDriver.findElement(), you’re returned
an element that you can keep a reference to. I often see people using
driver.findElement().clear(), driver.findElement() for the same element,
[and] sendKeys, driver.findElement() for the same element submit-
ted, which is a lot of extra work. Remember that each WebDriver call
is essentially a remote procedure call (RPC), so if you’re using a system
like Sauce Labs, you’re making multiple calls over the internet. To
streamline this, just hold on to the element reference and use
element.sendKeys(), element.clear(), element.submit(). This reduces
the work you’re doing and speeds up your tests.
If you encounter a stale element exception, don’t panic! This simply
means that the application has changed in a way you weren’t expect-
ing. As a tester or developer, this should raise some alarm bells. Why
don’t you know the current state of the application? Use this as an
opportunity to investigate and learn more about what’s going on
under the hood.
mon
Si

WebDriver
t
te
S
r
wa
Think about the automation scripts you’ve written for your projects. Are you
following the best practices for WebDriver? Are you keeping hold of the ele-
ment reference? Are you locating the elements in the most efficient way?
Review your existing scripts and see if you can optimize them to reduce the
number of remote procedure calls and improve the speed of the tests.
Additionally, if you come across a stale element exception, don’t just treat
it as an error to be fixed. Instead, use it as an opportunity to investigate the
state of the application and learn more about its behavior. Use these insights
to improve your automation testing process and enhance the quality of your
software.
111
o n ab
ti
le
ac
DAY
112
ss
aw
e
s
e
omen To really succeed in any role, you need to go beyond your specific
area of expertise and reach out to people across different depart-
ments. As a QA person, you should be having meaningful conversations
with the design team, the OPS folks, and the infosec team. But don’t
just talk at them—have conversations with them. Listening is key,
especially in today’s world, where businesses need to be more empa-
thetic and attentive to their employees’ needs. By expanding your
scope and listening to others, you can gain a better understanding of
the organization as a whole.
So my advice would be to seek out opportunities to listen to people
in different areas of the company. You never know what insights or per-
spectives they might offer.
J ef f
Author of
Designing
S
Delivery
a
ussn
Think about the different departments and teams in your organization. Which
ones do you interact with regularly, and which ones do you rarely or never
talk to? Make a list of those you don’t really interact with, and then challenge
yourself to have at least one conversation with someone from each of those
teams in the next week. During those conversations, listen to their perspec-
tive and understand their role and their challenges within the organization.
Ask questions to learn more about their work, and look for ways that you can
collaborate or support each other’s efforts.
Take note of any insights or ideas that come up during these conversations,
and consider how you might use that information to improve communication,
teamwork, and outcomes within your organization.
Remember that effective communication is a two-way street, so be sure to
listen as much as you speak, and approach these conversations with an open
mind and a willingness to learn.
112
o n ab
ti
le
ac DAY
113
ss
aw
e
s
e
omen Now is the time to dive into the exciting world of AI-driven testing
solutions, where software testers can harness the power of artificial
intelligence to supercharge their test coverage, efficiency, and speed.
AI is transforming the testing landscape from visual AI testing that
enhances existing scripts to self-healing automation scripts that adapt
to application changes. Explore the world of autonomous test bots,
designed to quickly run random tests across various devices and
browsers, streamlining sanity and regression testing.
Stay ahead of the curve by keeping up to date with industry trends
and use cases through reports, webinars, and conferences, ensuring
your organization remains competitive. Now is the perfect time to
experiment with AI-driven testing solutions, so don't hesitate to sign
up for free trials and evaluate their impact on your testing processes.
Embrace the future of testing and discover the remarkable benefits of
AI-driven solutions today.
a
vin sh
A
EPISODE 440: testguild.com/a440 Co-founder

at pCloudy Ti i
wa r
Inspired by the transformative power of AI-driven testing solutions, take a

moment to research, and identify three AI-driven testing tools that could
benefit your organization. Sign up for their free trials and create a detailed plan
to evaluate their effectiveness over the next month.
Share your findings and experiences in a blog post and consider presenting
your insights at an upcoming industry webinar or conference to contribute to
the ongoing conversation around the future of software testing.
113
o n ab
ti
le
ac
DAY
114
ss
aw
e
s
e
omen Take automation to the next level because, unlike the world of
development, we get new technological advancements all the time.
In the world of QA, we don’t have that same energy. We’re still look-
ing at page objects. Page objects are old. I’m not saying that we don’t
need them, but the whole design of page objects is outdated. We can
extend page objects to be better. However, project after project, com-
pany after company, when you talk to the core QA team and ask them
what are the guts of your framework and how do we make it scale, it’s
the same thing: we have to go in there, manually update or create
page objects, and write support functions in those page objects man-
ually, and then you realize, oh my goodness, it’s the same thing.
It’s not the year 2007! Yet, they’re still using the same approach for
a problem that’s quickly becoming more complex to solve.
t
Pe e r
EPISODE 66: testguild.com/66 Director of

Quality
Engineering Kim
Think about the automation approach in your organization or team. Are you
using outdated methodologies or tools that are no longer effective? How can
you take automation to the next level and make it more efficient and effective?
Explore new technologies, methodologies, and frameworks that can help
you improve your automation process. Engage with your team members and
stakeholders to understand their pain points and find ways to solve them
using innovative approaches. Don’t settle for the status quo. Strive for contin-
uous improvement and keep up with the latest technological advancements
to stay ahead of the game.
114
o n ab
ti
le
ac DAY
115
ss
aw
e
s
e
omen The last piece of advice I will give to everyone regarding automa-
tion is this: no one automation tool is perfect for every solution, and no
one tool is inherently slow or fast, or inherently good or bad at any one
thing. It’s always a matter of how you utilize that tool, and how you
tailor its use to your specific product. So you must understand the
product you are testing, the goal of that product, what the business
wants, and where they want the quality. Based on that, choose your
tooling to fit your team’s unique needs. Focus on making your automa-
tion super solid.
yank
ri
a
The Lean Stater H
alder
Think about the automation tools your team is using. Are they meeting your
team’s unique needs and the products you’re testing? Take the time to assess
whether they’re the right fit, and if not, consider exploring alternative tools that
may better align with your team’s goals and objectives.
Additionally, focus on making your automation solid by conducting thor-
ough testing and incorporating continuous improvements to your automation
processes. The success of your automation ultimately depends on how well
you understand your product and business goals, and how effectively you
utilize your automation tools to achieve them.
115
o n ab
ti
le
ac
DAY
116
ss
aw
e
s
e
omen The best way to prove your skills in browser automation is to start
contributing and being involved with an open source project like Web-
driverIO. It not only teaches you how the framework works, but also
how test automation works in general. That is something I always
advocate for and is really important if you want to find hidden errors,
support the project, and quickly fix issues.
So understand how the product you are testing works and its goals,
choose your tooling based on your team’s unique needs, and focus on
making your automation super solid. Contribute to open source
projects like WebdriverIO to improve your skills and learn more about
test automation.
istia
hr
n
WebDriverIO B
n
ro
ma
Think of an open source project that aligns with your interests and career
goals, particularly in the field of test automation. Take the time to learn about
the project, understand how it works, and identify opportunities for contribu-
tion. Start small, maybe by reporting a bug or submitting a documentation fix.
As you gain more experience and confidence, challenge yourself to take on
more complex tasks, such as adding a new feature or fixing a critical issue.
By actively contributing to an open source project, not only will you
enhance your skills in browser automation, but you’ll also learn from others,
collaborate with a community, and make a meaningful impact.
116
o n ab
ti
le
ac DAY
117
ss
aw
e
s
e
omen The best thing to do is probably to do a value stream assessment

and understand where your biggest waste is. I can guess that your big-
gest waste is not having automated tests, so just get started. Take a
look at the unit testing first, because unit testing is something that
you’re going to have to do. You really need to invest in it and start look-
ing at it. You need to understand that capability and start looking at the
individual programs as you’re changing them. Start testing them.
alin
os
d
IBM Fellow,
CIO DevSecOps
e
R
a
CTO d c lif f
Think about the software development process in your organization. Can you
identify where the biggest waste is? Are you investing in automated testing? If
not, consider starting with unit testing and understanding its capabilities. Look
at the individual programs as you make changes and start testing them.
Remember, the best thing to do is to get started with automated testing, so
don’t wait any longer!
117
o n ab
ti
le
ac
DAY
118
ss
aw
e
s
e
omen I love testing new technology. I love following what’s happening on

product lines and with new tools. So I would say keep listening to pod-
casts like this one and stay current with what’s going on in the industry.
There’s a lot of opportunity with these big changes, and if you stay
hungry and stay current, you can identify trends early. Do things that
not a lot of people are doing, and a lot of interesting opportunities can
come your way.
Mats
Lj
of Boozang
n
u
e
nggr
Take a moment to reflect on your approach to learning about new tech-

nologies and industry trends. Do you regularly seek out new information and
resources to stay current in your field? If not, consider making a commitment
to listen to podcasts or read articles that cover emerging technologies or
industry developments.
Additionally, challenge yourself to try new things that not many people are
doing in your area of expertise. This could be testing out a new tool or frame-
work, exploring a new area of interest, or taking on a new project that pushes
you out of your comfort zone. By staying hungry and current, you can position
yourself to identify trends early and pursue new opportunities in your field.
118
o n ab
ti
le
ac DAY
119
ss
aw
e
s
e
omen
arcus
M
EPISODE 263: testguild.com/263 Vice President

at Sauce Labs M
l
er l
re
Think about the UI tests your team runs. Are they atomic and autonomous? If
not, consider breaking them down into smaller, independent tests. This will
make it easier to identify issues when they arise and to avoid false positives.
Additionally, make sure each test has a clear and distinct purpose. This will
help keep your tests organized and focused on specific functionality, and it
will reduce the risk of interference between tests.
Start by reviewing your existing test suite and identifying opportunities to
improve the atomicity and autonomy of each test. From there, work with your
team to develop a plan for implementing these changes, including training
and documentation, and set goals for gradually improving the quality and
coverage of your tests over time.
119
o n ab
ti
le
ac
DAY
120
ss
aw
e
s
e
omen Your automation should focus on the goals of the business. Test
automation goals should be in line with what the business is looking
for at the end of the day. It’s the business value of a test that makes a
project successful. And if your automated test is always failing and no
one is paying attention to removing it, it’s not a test anymore; it’s just
noise, and it’s not adding any value to the business at that point.
a Bind
m
i
H
u
Software
P
Engineer e t e ti
Think about your company’s goals and the business value your automated
tests provide. Do they align with each other? Are you spending too much time
on tests that aren’t adding any value to the business?
Identify the tests that aren’t adding value and discuss with your team
whether those tests should be removed or improved. Brainstorm ways to
make your automation tests more focused on the goals of the business. The
value of a test isn’t just in finding defects, but also in providing insights into the
quality of the product, helping to make better decisions, and reducing the risk
of failure.
120
o n ab
ti
le
ac DAY
121
ss
aw
e
s
e
omen I think the single biggest piece of advice is not to dive in with both
feet. Don’t just download the latest framework or tool you’ve read
about on LinkedIn. Step back and think about the requirements for
your organization.
Testing and test automation is not just about tools, it’s about
automating processes. If those processes aren’t right in the first place,
throwing the latest and greatest tool at them won’t help. So take a step
back, read a book, do some research, and look for things that will help
make automation successful before diving into an idea and starting to
write JavaScript or Java code.
u n c an
D
Br
w
of Odin
a
g
Technology gin s h
i
Take a moment to reflect on your approach to test automation. Are you

caught up in the latest buzzwords and rushing to implement tools without
considering your organization’s specific needs? How much time do you spend
developing the right processes before diving into the code?
Consider taking a step back to evaluate your current processes, identify
any gaps, and determine what you need to automate to achieve your goals.
Invest time in researching and learning about the right tools and frameworks
that will help you achieve success, rather than jumping on the latest trend.
Test automation is about automating processes, so make sure your processes
are sound before investing in automation.
121
o n ab
ti
le
ac
DAY
122
ss
aw
e
s
e
omen I think the best advice I would give people is to try to be a tester and
not try to be an automator, and not to be too technical. Because from
all the people I’ve seen, those who started as a QA engineer, a manual
QA engineer, and started their career in that way, have an advantage
over people who directly start with automation. What I’ve seen is that
people who are too focused on getting things done, instead of looking
at what the business value of automating this is, are not as successful.
If you have 100 test cases automated, but only 10 of them provide real
value, then you are waiting a long time for your build to succeed. As a
manual tester, you would only focus on those 10 or 20 test cases that
give you the most value and have a fast build. So my advice is to first
learn how to do proper manual testing before diving into automation
W im
EPISODE 271: testguild.com/271 Staff Product

Manager Mobile S
@SauceLabs elles
Think about your approach to testing and automation. Are you focused on
getting things done quickly, or are you taking the time to contemplate the
business value of what you’re automating?
Consider taking a step back and looking at your process from a different
perspective. Try to approach automation like a tester, not an automator, and
take the time to understand the value that automated tests can provide to
your organization. Also, consider doing some manual testing first, and then
using that experience to help guide your automation efforts. Finally, take the
time to evaluate your automated tests to ensure that they’re providing real
value, and be willing to adjust your approach as needed.
122
o n ab
ti
le
ac DAY
123
ss
aw
e
s
e
omen I would say that test automation is a tool. It’s a tool to help you
with testing. Testing is all about trying to figure out the requirements
and user expectations and making sure that a system follows and
conforms to those expectations. So part of what makes testing an art
is that you sit there and try to figure out all the different permutations
and how you can hack into this particular system. If you’re going into
test automation, don’t forget the art of testing. Concentrate your
efforts on understanding how the system works on the inside, figuring
out the risk points, and identifying where components are held
together with gum and sticky tape.
t
Pe e r

Smashtest T
esler
Think about a testing scenario you’ve encountered or are currently working

on, and analyze its requirements and user expectations. Identify the different
permutations and risk points in the system and how you can approach testing
those components. Use this analysis to inform your approach to test automa-
tion—keeping in mind that automation is a tool to help you test, but that the
art of testing involves deeper understanding and analysis of the system.
123
o n ab
ti
le
ac
DAY
124
ss
aw
e
s
e
omen For any test automation, you should have an assertion in place. I
have seen people doing automation without validating what they
expected to see. So assertions are essential, and everyone needs to
understand them. And that has to be part of your test automation
script. Accessibility is a very important topic in today’s world, and we
have to take it as a personal responsibility to test and ensure that what
we are building is for everyone. So it’s not just about following any law;
. . . it’s a social responsibility that we need to build something that
everyone can use.
rna
pa
hnan
A
Go
EPISODE 274: testguild.com/a274 QE Consultant
s
a i
p
lakr
Think about the last test automation script you wrote or worked on. Did it have
assertions in place? Were you testing for accessibility? If not, take a step back
and think about how you can add assertions to your tests and start testing for
accessibility. Consider what social responsibility means to you and how you
can make sure the software you’re building or testing is inclusive and accessi-
ble to everyone. Take some time to research best practices for accessibility
testing and start incorporating them into your work.
Remember, small actions can lead to big changes, and as the speaker says,
it’s our responsibility to build software that is accessible to all.
124
o n ab
ti
le
ac DAY
125
ss
aw
e
s
e
omen If you’re going to develop your own automation infrastructure, you

should always think about the maintenance and flexibility of your
infrastructure. Because there are many automation solutions, and I’ve
seen it many times, especially in-house solutions, where some com-
panies decide not to use any external tools and just go ahead and
develop something of their own. It eventually fails in most cases
because it becomes harder and harder to maintain. And it’s like you
have new demands, but you are not flexible enough with your infra-
structure. Eventually, it becomes the elephant in the room, and no one
uses it or talks about it.
So, if you do decide to go with your own solution, always think
ahead about how easy it will be to maintain this infrastructure and the
tests that we will build on top of it. Also, consider how flexible it will be
for changes and to handle any new technologies.
dar
El
EPISODE 322: testguild.com/a322 Senior Director
y
at Tricentis
k
av
ets
Think about the automation infrastructure in place in your organization and

whether it’s flexible and easy to maintain in the long run. Evaluate the tools
and technologies used and analyze whether they’ll be able to keep up with
changes in the industry. Identify the potential problems that may arise due to
lack of flexibility and maintenance, and brainstorm solutions and strategies to
improve the infrastructure and make it more sustainable for future growth and
change. Finally, don’t be afraid to reach out to experts and to invest in external
tools if necessary.
Remember, the key to success in automation is to develop the right tests
and to maintain a flexible and sustainable infrastructure.
125
o n ab
ti
le
ac
DAY
126
ss
aw
e
s
e
omen Be a hero. You will need bravery. You will be scared. But step past
that fear. You will fail, but it’s okay; that’s how you learn the most. So
take that step. DevSecOps absolutely needs more heroes. They need
people to be brave enough to really push the envelope.
acy
St
EPISODE 280: testguild.com/a280 Founder of

QualityWorks
Kir k
Think about a time when you were scared to take a step forward, but you did
it anyway. What did you learn from that experience?
Now imagine being a hero in the field of DevSecOps. How can you push the
envelope and embrace failure as a learning opportunity? What kind of impact
could you make by being brave enough to take that step?
126
o n ab
ti
le
ac DAY
127
ss
aw
e
s
e
omen I believe that test automation should involve everyone on the team,
not just testers. If testing is solely the responsibility of testers, it will
always be a step behind the developers. However, when developers
are involved in test automation, you gain the rigor of code reviews and
the ability to version tests alongside the code. Therefore, I think it’s
essential that tests aren’t owned solely by testers but by the entire
team, and that they’re visible and subject to developer rigor.
me s
Ja

Appsurify F
r
a
r rie
Think about your team’s approach to test automation. Are your testers the only
ones responsible for creating and maintaining tests, or are your developers
also involved?
If your team isn’t already taking a collaborative approach to test automa-
tion, consider taking action to change that. Schedule a meeting with your
team to discuss the benefits of involving developers in the test automation
process, such as increased code review and versioning of tests. Encourage
everyone to take ownership of the tests and make them visible to the entire
team. By taking this step, you can help ensure that your team has a rigorous
approach to testing and is able to catch bugs and issues before they impact
your users.
127
o n ab
ti
le
ac
DAY
128
ss
aw
e
s
e
omen It’s a straightforward piece of advice. If you look at a requirement,

just read it, and you will see that people mix up data terminology
inside a business description. If you go through and change your
requirement document to have just a section on data, that could be
the data required to run this requirement. For example, it may rely on
my employee table or my employee rules table. Great. When you refer
to something in the linked requirements documents, the data makes
life so much easier for your tester or automation engineer because
they then have, in effect, a blueprint on how to create the test data for
the people that are gonna develop the system.
And you should think about test data as something that happens
before you even begin development. . . . For instance, if you look at our
most successful customers, their teams start from the project’s incep-
tion, drawing out from their users what they need from a test data
point of view. Then they will beaver away and create a vibrant test and
development data set. And that is probably the best thing you can do.
You can do that with your technology, and you don’t need anything
new. It’s just a bit of a mindset change in how you do that.
Hu w
Managing
EPISODE 282: testguild.com/a282
Director at
Curiosity Pr
ic e
Software
Think about the last time you worked on a project where test data was a
bottleneck for testing or automation. Did your team have a clear understanding
of what data was needed to run each requirement?
If not, schedule a meeting with your team to discuss the benefits of creating
a blueprint for test data. Encourage everyone to think about test data as
something that happens before development, and involve users in the
process of drawing out their test data requirements.
By creating a vibrant test and development data set from the project’s
inception, you can help ensure that your team has the necessary test data to
create effective tests and automation. Remember that this shift in mindset
doesn’t require new technology, but rather a change in approach that can
ultimately save time and increase the quality of your project’s outcomes.
128
o n ab
ti
le
ac DAY
129
ss
aw
e
s
e
omen I think the best advice I could give to someone to improve their
automated testing and overall testing is to focus on the product, the
business, know the product and what to expect, then put themselves
in the end user’s shoes. Because that’s where you tend to find the
things that are not so logical or the things that might annoy you as an
end user.
Because most of the time when you’re a tester, you start working
with the alpha version of an app and then the beta version. And if it’s
. . . badly designed from the start, you just get used to it, and then you
can no longer see that it’s . . . not intuitive, or it’s a terrible experience.
Liviu
EPISODE 284: testguild.com/a284 Solutions

Architect at
Lu
Endtest p ei
The last time you conducted automated testing for a product, did you focus
on the product, understand the business, and put yourself in the end user’s
shoes? If not, set aside some time to dive deep into the product and under-
stand what the end user experience is like. Take notes on areas that seem
illogical or frustrating, and think about how you can address those issues in
your testing.
Remember that your goal is not only to find bugs, but also to help ensure
that the end user has a positive experience with the product. By taking this
approach, you can improve the overall quality of your testing and ultimately
make a more meaningful impact on the success of the product.
129
o n ab
ti
le
ac
DAY
130
ss
aw
e
s
e
omen My piece of advice is to care about your infrastructure. Automation

is more than just writing scripts and executing them. It’s everything
about it, including where it runs. So go to a whiteboard and draw out
all the little boxes—this is the machine that our scripts execute on, this
is where the scripts execute against, this is the machine that controls
that execution, and these are the people that have the keys to these
various machines. How are they configured? Once you have that map
or illustration drawn out, you’ll be amazed at how complicated your
actual infrastructure is. And that should be enough to scare you into
looking at how to manage it better.
am
Ad
EPISODE 288: testguild.com/a288 Director of

Software
r
G
o
uche
Think about the last time you conducted automated testing. If you didn’t
take the time to consider the infrastructure supporting your testing, consider
taking action to change that. Schedule a meeting with your team to draw
out your current infrastructure on a whiteboard. Look at that map of your
infrastructure—the machine that executes the scripts, where the scripts
execute against, and the machine that controls that execution. Consider the
people who have keys to the various machines and how they’re configured.
Once you have a clear picture of your infrastructure, you may be amazed
at how complex it is. Use this illustration to help identify areas where your
infrastructure can be improved. Also, consider implementing new tools or
processes to help manage your infrastructure more effectively.
Remember that automation is more than just writing scripts and executing
them. It’s also about where the scripts are being run. By caring about your
infrastructure, you can help ensure the success of your automated testing
efforts and ultimately the success of your project.
130
o n ab
ti
le
ac DAY
131
ss
aw
e
s
e
omen Focus on identifying the factors that affect the performance of mobile
native apps. It is important to understand that testing the performance
of native apps is different from load testing, which is more applicable
for web apps. Therefore, testers should consider the infrastructure and
system of the client side, including the mobile device and network, to
ensure a good user experience.
They should also use tools that are specific to mobile app perfor-
mance testing, rather than load testing tools, to identify the factors
that cause delays in the app’s performance. Additionally, testers
should understand that there are three main factors that affect the
user experience, which are the response time of the server, the network
speed, and the mobile device used. By identifying and optimizing
these factors, testers can improve the performance of mobile native
apps, leading to [a] better user experience.
f
So í a
Co-founder or
uk
Pa
EPISODE 52: testguild.com/p52
Apptim a
h
l
m a rc
Think about a mobile app that you frequently use, and evaluate its perfor-
mance. Consider the factors that may affect its performance, such as server
response time, network speed, and mobile device used. Reflect on how these
factors impact your user experience and whether there are any delays or
issues that could be improved.
Based on your observations, brainstorm some ways that the app’s perfor-
mance could be optimized. Consider what tools could be used to identify
performance issues and how they could be addressed. Finally, reach out to
the app’s development team or leave feedback on the app store to help
improve the app’s performance and enhance the user experience for yourself
and others.
131
o n ab
ti
le
ac
DAY
132
ss
aw
e
s
e
omen The only scaling benefit you get when testing microservices is if you
can force-release the independence of your service from everything
else in the organization.
Testing is a critical component of that. You need to be able to test
your service independently of anything else so that you can release it.
Service virtualization is a great way of doing that, and the open source
tool Mountebank is a great option for service virtualization. I highly
recommend testing it out.
d
a n on
B
Thoughtworks
Head of
Technology B
ya r s
Reflect on the importance of service virtualization in testing microservices and

develop a plan to implement it in your organization. Consider the current state
of testing in your organization, particularly with regard to microservices. Do
you have a strategy in place for testing these services independently, without
relying on other system components? If not, begin exploring service virtualiza-
tion as a solution.
Research tools like Mountebank and assess their feasibility for your organi-
zation. Start experimenting with service virtualization in a test environment
and see how it impacts the testing process. Finally, evaluate the results and
consider implementing service virtualization on a larger scale if it proves to be
effective.
Being able to test microservices independently is critical to achieving the
benefits of microservices architecture. Service virtualization can be a valuable
tool in enabling this independence.
132
o n ab
ti
le
ac DAY
133
ss
aw
e
s
e
omen I always suggest to everyone to keep sharing your knowledge and

. . . whatever framework you have done or anything good you have in
your day-to-day work. Just share with everyone. . . . This is what I did
with SelectorsHub. I shared it with everyone, and now we have a large
user base saving a lot of effort. And we are growing, and everybody’s
getting help.
So, if you have done something amazing in your day-to-day work
which is saving you time, help others with that and let others also save
time.
anjay
S

SelectorsHub
K
umar
Think about something you’ve developed or a process you’ve streamlined in

your work that has saved you a lot of time and effort. Now document it and
share it with your colleagues or with the broader community through a blog
post, presentation, workshop, or other relevant channels. Encourage others to
try it out and to provide feedback. Not only will this help others save time, but
it will also help you improve your work and learn from others’ experiences.
Remember, sharing knowledge and helping others is a win-win situation!
133
o n ab
ti
le
ac
DAY
134
ss
aw
e
s
e
omen If I were to give specific advice for anyone considering beginning

automation, do not start with a tool. The point here is to say if you have
a process that’s not running very well, it’s not gonna be running any
better when you automate it. So spend some time analyzing to
determine what works and [what] doesn’t. How can you optimize this
particular process in the way that it has to accommodate my business
needs within my organization? Only when you have that well in control
[should you] start looking at automating it. If you automate stuff that’s
not working very well, it’s gonna keep on working not very well,
it’s just gonna do it faster. It will cause more pain than when you
did it manually.
S u ne
EPISODE 301: testguild.com/a301 Senior Product

Evangelist E
n g sig
Think about a process in your work or personal life that you feel could benefit
from automation. Before jumping into automating it, take a step back and
evaluate the process, identifying the pain points and areas that could be opti-
mized. Then brainstorm ways to improve the process to better meet your
needs and those of your organization. Once you have a solid understanding
of the process and have identified ways to optimize it, then start exploring
automation tools to help you achieve your goals.
Automation is not a silver bullet, and if you automate a flawed process,
you’ll only end up with a flawed process that runs more quickly.
134
o n ab
ti
le
ac DAY
135
ss
aw
e
s
e
omen I recommend getting the Security+ certification if you want to get a

security testing position. It’s a must for any entry-level position in the
security field. This certification provides a broad overview of security
concepts and practices. For those studying for the Security+ certification,
flipping to the back of the book and memorizing the glossary first is
recommended. Additionally, getting context for terms and concepts,
such as understanding security programs in general and their various
components, is essential for success.
Soft skills such as attention to detail, documentation, policy making,
and public speaking are also valuable in security. Those with skills in
these areas should emphasize them during the hiring process.
r
Ma il
EPISODE 41: testguild.com/s41 Purple Team

Program V
Manager ernon
Think about a work-related skill or certification that you’ve wanted to obtain

but have been putting off. Consider the benefits of having that skill or certifi-
cation and how it could potentially enhance your career. Then research the
requirements and resources needed to obtain the skill or certification, and
create a plan of action. While you’re at it, don’t forget to focus on developing
soft skills such as attention to detail, documentation, policy making, and
public speaking, as they can be just as valuable in your field.
Remember, investing in yourself and your skills can lead to great opportu-
nities and growth in your career.
135
o n ab
ti
le
ac
DAY
136
ss
aw
e
s
e
omen My advice is to explore all of the new things coming out. And if you
can’t do it directly, look at YouTube. Tons of people have videos of
these things in action. There’s so much going on. The catchphrase—
I think it’s become my catchphrase now—is that we’re in a golden age
of testing.
I really believe it. I think there are so many interesting things hap-
pening. If you’re not involved in the testing community, like the social
media level, seek that out because I learn so much on a daily basis
just from reading what other testers are doing. And it’s such a lovely
community.
. . . I learned about mabl from [the] TestGuild automation podcasts. . . .
I think there’s so much happening out there, it’s always hard to know
really what’s going on. So I say my best advice is, amp up your curiosity
right now because there’s so much out there to find.
r re
Da l
Solutions
EPISODE 306: testguild.com/a306 Engineering
Manager Fa s
r ri
at mabl
Explore the latest testing technologies and trends by following thought lead-
ers and influencers on social media and watching relevant videos on YouTube.
Expand your knowledge by seeking out different perspectives and experi-
menting with new tools and techniques. Join online communities and engage
with other testers to stay up to date on the latest developments in the industry.
Curiosity and a willingness to learn can be powerful tools for professional
growth, and can help you stay ahead of the curve in today’s constantly evolv-
ing world of software testing.
136
o n ab
ti
le
ac DAY
137
ss
aw
e
s
e
omen I think my advice would be to keep it simple and narrow your

constraints. A lot of the difficulty with testing comes from too much
complication or complexity in what you’re trying to test. So see how
you can narrow the scope of what you’re trying to test and divide
things up as much as you can. That will allow you to have more main-
tainable tests and tests that are less flaky. It will also help you get
more value out of your tests.
v
Ke i n
EPISODE 307: testguild.com/a307 Front-end

Engineer
g
a
L
& Tester m pin
Think about the last time you were testing something and found it difficult to
write or maintain a test. Reflect on the complexity of what you were testing
and consider how you could have narrowed the scope to simplify the test.
Then identify ways in which you can start narrowing the scope of what you test
in the future. Ask yourself: What is the smallest set of functionality I can test
that still provides value? Can I divide this test into smaller, more focused tests?
By implementing these strategies, you can simplify your tests and make
them more maintainable, leading to more valuable testing.
137
o n ab
ti
le
ac
DAY
138
ss
aw
e
s
e
omen My advice is to just jump in and learn. Find a business problem—

something that can identify a quick return on investment. Do a little bit
of side learning and then jump in and show some ROI. Automate some
process that is painful and put on a little sales pitch to your boss and
say, hey, this took so long to do, I’ve now automated it, and boom—
show it off.
. . . There’s an answer out there, [so] leverage the community. You’ve
got to be proactive, and I think QA does involve a little bit of salesman-
ship as well sometimes.
Dave
EPISODE 320: testguild.com/a320 Principal QA

Engineer M
a r tin
Think of a business process in your organization that can benefit from automa-
tion. It could be a tedious task that takes up a lot of time, a process that is
prone to errors, or something that can be optimized for better efficiency. Start
learning about the different tools and techniques that can be used for auto-
mation, and explore the various resources available online such as blogs,
tutorials, and videos. Identify the ROI of automating the process and present
your findings to your boss. Practice your communication and persuasion skills
by preparing a sales pitch that highlights the benefits of automation.
Remember to seek help from the testing community whenever you en-
counter challenges, and stay proactive in your learning and implementation.
Take the first step toward automation today and see how it can revolutionize
the way you work.
138
o n ab
ti
le
ac DAY
139
ss
aw
e
s
e
omen One piece of advice that I would give is, if you’re just doing functional
testing, try to think outside of UI testing. UI testing is not the only type
of testing that you can do. There are tons more. I’m not only talking
about API testing, but also performance testing, load testing, mobile
testing, and many other types of testing.
[Also] don’t get close to a single tool that you have at your company.
There are also many free noncommercial tools that you can use, which
can be used in enterprise projects. So don’t limit yourself to the tools
that your company has bought. Use everything that is possible.
ichal
M

at Int4
k
K
r
aw y
cz
Think about the tests you conduct in your role. Are you relying heavily on UI
testing, or do you explore other types of testing as well? If you’re only doing
functional/UI testing, challenge yourself to learn more about other types,
such as performance testing, load testing, and mobile testing. Look for
resources online, such as YouTube videos, online courses, and webinars, to
learn more about these types of testing. Don’t limit yourself to the tools your
company has bought; explore free and noncommercial tools that can help you
perform different types of testing.
Finally, share what you’ve learned with your team, and encourage them to
explore different types of testing as well.
139
o n ab
ti
le
ac
DAY
140
ss
aw
e
s
e
omen In today’s reality, especially in the digital landscape, automation is

becoming very complex, and you need to be smart about it. The old
rules of executing all your automated testing every day, for each code
change, [don’t] really work anymore. You really need to have a good
decision-making solution that allows you to slice and dice your test
data and make better decisions, so you are really focusing on the code
that was impacted. Make sure that you are running the right test, the
one that is giving you value, so you really get the most out of your test
automation. . . . Try being smarter about decision-making in tests and
scoping test coverage as an ongoing practice.
Er a n
EPISODE 313: testguild.com/a313 Global Head

of Product
r
Ki
e
Marketing s
n
brun
Challenge yourself to rethink your current approach to automated testing.

Take a closer look at your testing data and identify areas where you can opti-
mize your testing strategy. How can you make your decision-making process
smarter and more efficient? Are you running the right tests and getting the
most value out of your automation?
Set aside time to analyze your test data, and come up with a plan to scope
your test coverage more effectively on an ongoing basis. In doing so, you can
improve the quality of your automated testing and ensure that you’re focusing
on the code that truly matters.
140
o n ab
ti
le
ac DAY
141
ss
aw
e
s
e
omen Incorporate component testing into your testing strategy, espe-

cially if you are working with complex components or systems. This
type of testing can help catch issues in isolation and make debugging
faster, which can ultimately improve the quality of your code.
Additionally, consider adding accessibility and visual testing to your
testing plan, as these are important aspects of [the] user experience
and can help catch issues that might otherwise be missed. Finally,
consider implementing a checklist or guideline to ensure that all
necessary tests are being performed and that testing is integrated into
the code review process.
r
Ma ie
EPISODE 316: testguild.com/a316 Developer

Advocate at k6
Cr
uz
Think about your testing strategy for software development. Are you incorpo-
rating component testing to catch issues in isolation and improve debugging
speed? Are you performing accessibility and visual testing to ensure a positive
user experience? Have you implemented a checklist or guideline to ensure
that all necessary tests are being performed and integrated into the code
review process?
Consider these factors and explore how incorporating these practices into
your testing strategy could ultimately improve the quality of your code and
the overall user experience of your product.
141
o n ab
ti
le
ac
DAY
142
ss
aw
e
s
e
omen My one piece of advice is to write your code with the reader in
mind. Don’t write your code for a computer. Write your code for your
coworkers.
Cory
EPISODE 13: testguild.com/13 Founder at

Reactjsconsulting
H
ouse
Take a moment to reflect on your coding practices and consider whether

you’re writing your code with your coworkers in mind. Are you considering
their perspective and making it easy for them to understand and work with
your code? Take a step back and try to put yourself in their shoes. How would
they approach your code, and what could you do to make it more accessible
and intuitive for them?
Challenge yourself to write code that is clear, concise, and easy to follow,
and consider seeking feedback from your colleagues to improve your coding
practices. By prioritizing the needs of your coworkers, you can create a more
collaborative and effective coding environment and produce higher-quality
code that is easier to maintain and work with over time.
142
o n ab
ti
le
ac DAY
143
ss
aw
e
s
e
omen Automation code is not production code.

Of course, you should treat testing like production code with the
same value, and not say, oh, it’s just testing code, we don’t need to
have a look at it. So don’t get me wrong on this point, it’s equally
important at least. But there are some patterns, some conventions,
which are important for production code but not that suitable for
test code.
My favorite example is the Don’t Repeat Yourself (DRY) principle,
which basically says that you should avoid duplication at all costs.
However, if you follow this principle in tests and use a lot of abstrac-
tions, or less documentation or comments, you make it more difficult
to understand the test in the future or to maintain it.
So this pattern might conflict with the golden rule, and you should
choose readability instead of trying to overengineer your automated
test.
o
am n a
R
Software
Engineer
g
h
n
w e ri
How can you strike a balance between the DRY principle and the readability
of your automated tests? Can you think of any examples where prioritizing the
DRY principle may have led to tests that were difficult to understand? How can
you ensure that your automated testing code is treated with the same level of
care and attention as production code, while still allowing for readability and
maintainability?
143
o n ab
ti
le
ac
DAY
144
ss
aw
e
s
e
omen If you want to make sure that your hard work is recognized and
appreciated, you need to make it visible to others. The key to doing
that is documentation. If it’s not documented, it’s like it never hap-
pened. Let me give you an example. Let’s say your manager gives you
a complex task to write an automation script that involves dynamic
elements and validation. You work extra hours to complete it, and then
let your manager know it’s done. But when it comes time for your
annual performance review, your manager may not remember all the
hard work you put in. That’s where documentation comes in. You should
send an email documenting everything you’ve accomplished, including
the specific expectations and elements you worked on.
To make sure you’re not just making things up, maintain a “success
folder” where you store all your documentation and screenshots of acco-
lades and accomplishments. During your performance review meetings,
you can pull from this folder to showcase all the great work you’ve done.
But it’s not enough to just document your accomplishments. You also
need to talk about them. Bring them up during your daily stand-up meet-
ings, sprint planning meetings, and any other opportunity you get. By
consistently sharing your accomplishments, your team will start to see
the value you bring. And don’t be afraid to use numbers to quantify your
impact. For example, you can say, “Yesterday I finished the automation
script that reduced our testing time from five hours to just 30 minutes.”
By following these simple steps, you can make sure that your hard
work doesn’t go unnoticed. And who knows, you may even become a
star performer like me, rated highly by six out of the seven companies
I’ve worked for. Remember, it’s the little things like documentation and
talking about your accomplishments that can make a big difference in
how others perceive your value to the team.
Raj
EPISODE 357: testguild.com/a357 Author of

er
Su
Skyrocket b
y
ra
Your Career me
Think about a project or task you completed recently and are proud of. How
did you document your work and communicate your accomplishments to your
team and superiors? Did you follow the three steps mentioned in the quota-
tion: documenting everything in emails, maintaining a success folder, and
regularly talking about your accomplishments in team meetings? If not, how
could you improve your process to make your work more visible and increase
your value to the team? What benefits do you think following these steps
could bring to your career advancement and recognition within the company?
Reflect on the importance of effectively communicating your work and
accomplishments, and consider how you can use these strategies to enhance
your professional reputation and achieve your goals.
144
o n ab
ti
le
ac DAY
145
ss
aw
e
s
e
omen Start small. If you’re having flaky tests right now, start with 10 tests
that are running in the CI that you trust, and then start adding more
tests one at a time. Trust is the most important thing. Always keep the
CI super clean, so everyone in the organization [will] trust your tests. So
that’s my advice: make sure everyone trusts your tests, so that when
they do fail in CI, it is most likely due to a real issue.
O re n
EPISODE 353: testguild.com/a353 Founder

of Testim
R
u bin
How can you implement the advice of starting with 10 trusted tests and build-
ing up from there? What specific tests do you need to prioritize to gain the
trust of your team and stakeholders? How will you ensure that the CI remains
clean and everyone trusts the tests? What strategies can you use to commu-
nicate the importance of trust in the testing process and create a culture of
trust within your organization?
Think about these questions and develop a plan to increase the trustwor-
thiness of your tests to make them more valuable and effective for your team.
145
o n ab
ti
le
ac
DAY
146
ss
aw
e
s
e
omen Test results are usually for humans to consume, and if we want to
save human time in dealing with a large automated test suite, then I don’t
want to be reading through garbage and spending my time looking at
stuff that’s kind of accidental complexity. That’s not really helping me
make any decisions I need to make.
What I want to see from a test result is something that quickly helps
me make an important decision. The decision I need to make is, should
I deploy this or should I not deploy this? Are there problems here that
prevent me from proceeding? Should I roll back and go back and fix
this stuff?
Lots of testing frameworks just bombard people with data in the
results because they want to show how grand and how useful they are,
spitting out numbers and percentages all the time. If I’m not making
a concrete decision based on something, I don’t want to see the data
at all.
Douglas Hubbard covered in his wonderful book How to Measure
Anything . . . how the value of a piece of information is proportional to
the decision it helps you make. Every time I see these code coverage
reports where they’re all, you know, 76%, 55%, 98%, and then people
have this massive table that’s green and orange and red and they
never make any decisions based on that, it’s kind of just a total waste.
If you’re making an important decision based on it, brilliant. If you’re
not making a decision, why are you showing it?
jko
Go
EPISODE 351: testguild.com/a351 Partner at Neuri

Consulting LLP
tA c
d zi
Reflect on how you present test results in your organization. Do you feel like
you’re bombarding people with data that isn’t helpful or meaningful? If so,
what steps can you take to streamline your reporting and provide decision
makers with the information they need to make informed decisions about
deployments and rollbacks?
Consider the value of the information you’re providing and whether it’s
proportional to the decisions that need to be made. Challenge yourself to
present test results in a way that is clear, concise, and meaningful to stake-
holders, while also avoiding accidental complexity that can waste everyone’s
time. Remember, the goal is to provide the right information at the right time
to facilitate effective decision-making.
146
o n ab
ti
le
ac DAY
147
ss
aw
e
s
e
omen One of the most important things to do in test automation is get

your developers involved. Try not to live in a vacuum. Tell them what
you’re doing, ask for their advice, ask for their suggestions, [and] teach
them how to do what you do.
I think a lot of testers are worried about that because they’re afraid
they’re going to work themselves out of a job, but they’re not. Because
developers are never going to be as passionate about testing as you
are. So get them involved. They will have all kinds of great ideas, like,
Oh, you know what, I can make a little test harness for this that will
make it easier for you to do your automation, or You know what, I think
we should organize our variables this way instead; it’ll be easier for
everybody. And that just makes the team gel and work so much faster.
ristin
K
EPISODE 354: testguild.com/a354 Principal

Engineer III- a
y
Software Testing c
k vo n
How can you involve your developers in test automation to improve collabora-
tion and the overall quality of your team’s work? Think about specific actions
you can take to encourage your developers to contribute to your testing efforts,
such as regularly sharing progress updates, soliciting feedback, providing
training opportunities, and creating a culture of open communication and
collaboration.
Consider how these actions can improve the quality of your team’s test
automation as well as foster a more productive and supportive work environ-
ment for everyone involved.
147
o n ab
ti
le
ac
DAY
148
ss
aw
e
s
e
omen You don’t want quality engineers to be the people who just find
defects. To really get into it, [you] want QE to be wearing multiple hats
and become full-stack tester[s]. So you should work in collaboration
with [y]our DevOps partners and developers. The goal should be to
push for CI/CD pipelines where deployments are simple enough for
everyone to do. We made it mandatory for everyone to deploy, and we
literally got everybody on the squad to deploy, including the product
owners and delivery managers. For this to work, it has to be simple
enough: a one-click release to production, and everyone has to be
involved in the releases. We want quality engineering to be involved in
the releases.
g an
La
Manager
Quality
Engineering K
ha re
Think about your development and testing process. Are you working in a silo?
Or are you actively collaborating with other teams to ensure that everyone is
on the same page? If you’re not already working in a cross-functional team,
what steps can you take to encourage collaboration and integration?
Consider implementing a CI/CD pipeline to help simplify the deployment
process and make it more accessible for all team members. Identify ways to
involve everyone in the testing and release process, including product
owners, delivery managers, and other stakeholders. How can you ensure that
everyone is involved in the releases, even those who don’t typically work
directly on development or testing?
Think creatively about ways to get everyone involved in the process, and
encourage a culture of collaboration and ownership when it comes to quality
engineering.
148
o n ab
ti
le
ac DAY
149
ss
aw
e
s
e
omen The most actionable item to help with your AI testing is a mental
connection. You have to understand that it doesn’t matter whether it’s
a self-driving car and the AI is learning actions driving in different
directions. It doesn’t matter if it’s the frozen lake and our actions are
moving around it. It’s no different than the web application that you’re
testing.
Your application under test is an environment, and the things you
do in your app are your actions. Once you realize this, you can go to
any tutorial on the internet that has to do with reinforcement learning
or other types of machine learning. And if you have that mindset in
your mind, you can use just about any AI out there, or you can quickly
determine if it’s valid or not for you by making that comparison
between environments and actions.
From a practical perspective, I [also] encourage you to do a basic
Python tutorial.
evor
Tr
Artificially
EPISODE 344: testguild.com/a344 Intelligent
r
C
Expert h
a n dle
Imagine you’re a software tester who has never worked with AI testing before.
You’ve been tasked with testing a new AI-powered feature in your application,
but you don’t know where to start. After doing some research, you come
across today’s quotation.
How can you apply this concept of mental connection to your testing
process? What specific steps can you take to better understand the relation-
ship between environments and actions in your application? How can you use
this knowledge to effectively test the AI-powered feature?
Reflect on your current testing practices and how they might need to
change to accommodate the unique challenges of testing AI. Also, consider
exploring a basic Python tutorial to help you get started with AI testing.
149
o n ab
ti
le
ac
DAY
150
ss
aw
e
s
e
omen One thing that would be helpful and applicable to any test suite is
finding a way to introduce convergence if you have to wait for some-
thing, like an explicit wait.
So [say] I have some code that says I’m going to check every 10
milliseconds to see if that thing showed up. . . . That fixed wait period is
a fixed cost. It’s like paying for parking where you only need five minutes,
but you have to pay for an hour. That’s how that fixed wait works.
Suppose you introduce convergence to replace that wait-for with a
convergent behavior. Some libraries [like the Testing React Library]
offer this where you can wait for this element to become visible. In
that case, that is way better than waiting for 300 or 500 milliseconds.
If you can do that, that will bring value to your test suite, which is just
adjusting that one thing.
r as
Ta

Frontside
i
a
k
Software nk
ov
s
Consider a test suite you’re working on: how can you introduce convergence
to replace fixed wait times in your tests? Take a moment to identify any areas
where you’re using a fixed wait period and consider how you might replace
it with a convergent behavior. What benefits would this bring to your test suite?
How might this impact the reliability and speed of your tests? Experiment
with ways to introduce convergence to your tests and see how this affects
your results.
Share your experience and insights with your team to help improve the over-
all quality of your test suite. Remember, small changes can often have a big
impact, so don’t be afraid to experiment and iterate until you find the optimal
approach for your needs.
150
o n ab
ti
le
ac DAY
151
ss
aw
e
s
e
omen If you’re using maturity tools like this, you shouldn’t only have mea-
surability and figures and management and all this stuff in mind. Yes,
especially in big companies, it’s necessary, you need to track progress.
But this is only one side.
. . . The other side is this contact with the team, this communication,
this continuous communication. And you must earn the trust of the
teams. You must have role models to foster exchange. And this is
really the hard part: that the mindset changes. And the cultural
change. But without it, you will not be successful. You will get fake
engineering and fake numbers, and you’ll think that you are doing
something. But in the end, you do the same thing that you did the last
10, 20 years.
David
EPISODE 339: testguild.com/a339 Head of Agile

Engineering
r
H
e e
it
zin g
How do you measure the success of your projects? Are you only focused on
the metrics and figures, or do you also value the communication and collabo-
ration with your team?
Reflect on how you can foster better communication and trust with your
team, and how you can balance the importance of measuring progress with
the importance of a strong team dynamic. Identify one action you can take to
shift your mindset toward valuing both measurability and communication in
your work.
151
o n ab
ti
le
ac
DAY
152
ss
aw
e
s
e
omen One thing I would say is this: if you want to be a leading organization
in quality engineering, and if you want to be a leader in quality engi-
neering, always follow the industry, the larger industry. What is IT
doing now that is going to be coming in the testing scope tomorrow?
And if you follow that trend, you will always be ahead of the curve, and
you will not end up having technical debt. If you understand what is
going on in the industry in terms of data infrastructure, I think that’s
exactly going to come into the testing scope for tomorrow.
And if you build coverage for that for tomorrow, if you have already
thought about it, you are always going to be ahead of the game.
rasa
a
r
of Digy4
Sa
ha
Think about the current trends and innovations in the larger tech industry: how
might they impact the field of quality engineering in the future? Consider
attending industry conferences (like automationguild.com), reading industry
publications, or joining online communities to stay up to date on the latest
developments.
Once you have an idea of what’s coming, brainstorm ways to incorporate
these trends into your organization’s quality engineering practices. By being
proactive and forward-thinking, you can ensure that your organization is pre-
pared for what’s to come and avoid falling behind with technical debt.
152
o n ab
ti
le
ac DAY
153
ss
aw
e
s
e
omen The best advice I can give is to dive deep into JavaScript. Feel free
to take some Udemy or Coursera courses—there are some great ones.
You can also use Mozilla MDN documentation, which is neat for
JavaScript. Don’t be afraid to experiment. Break things; that’s how you
learn. Write as many tests as you can; test different scenarios; dive into
different sides of interacting with elements. Feel free to test new
strategies; do as much proof of concept as you need. The more expe-
rience you get, the smoother it will go anyway.
So my suggestion would be to take your time and go . . . steadily into
the things you’ve decided to go with in terms of automation testing
and a set of technologies. Feel free to ask for help. Don’t be afraid
to create bugs or issues in GitHub and Stack Overflow, because if a
community is strong, many people are willing to help you, and they do
it fast.
mytro
D
EPISODE 335: testguild.com/a335 Senior Software
yi
Sh
Engineer in Test p
k
a
ko v s
Think of a scenario in your current or desired role where you can benefit from
improving your JavaScript skills for automation testing. Identify some Udemy
or Coursera courses that align with your goals and take the time to explore
them.
Additionally, experiment with writing different types of tests, trying new
strategies, and exploring various ways of interacting with elements. As you
experiment, take notes and document your process.
Consider sharing your experiences and seeking help from the community
on platforms such as GitHub and Stack Overflow. Over time, you’ll develop
valuable skills, knowledge, and experience, which will benefit you and your
team in the long run.
153
o n ab
ti
le
ac
DAY
154
ss
aw
e
s
e
omen When it comes to the automation engineer, look at the work that
you do as a partnership with your test engineer. Even try to separate
that idea of manual versus automated test engineers.
At the end of the day, a good automation engineer really needs to
be a great test engineer because you need to understand the craft
of testing, and you need to understand when an automation fire drill
comes up and someone says, “This awful thing happened; automate
this.” And you can go through the reasoning of a test engineer and
say, “You know, while we could do that, at the end of the day we might
miss one of the highest risks I see here,” or “This is a better task to be
done visually by a test engineer and we can build automation to come
alongside and help that test engineer, but to solely automate it, it
sometimes actually blinds you from seeing it again.”
So try to get into that place. A lot of test engineers aspire to go into
automation, and that’s a worthy place to move. But . . . automation is
hard. The easiest thing we do in automated testing is writ[e] automated
tests. There is a lot of hard work that it takes to do that consistently and
reliably and give you exceptional results . . . .
Gre g
Author of Test
Automation in
P
the Real World
l
as
ka
Have you been treating automation testing as a task that is separate from
manual testing, or have you been looking at it as a partnership with your test
engineers? Take some time to learn about the craft of testing and the reason-
ing behind the decisions your test engineers have made. Understand the
strengths and limitations of automation testing and where it fits into the
overall testing strategy. Work on building a better partnership with your test
engineers, and strive to integrate automation testing in a way that comple-
ments and supports their work, rather than replacing it.
Finally, remember that automation testing is not easy. It requires a lot of
hard work and attention to detail.
154
o n ab
ti
le
ac DAY
155
ss
aw
e
s
e
omen For application performance testing, one thing you can do is to test
it at every phase, every release test. Get those metrics, get those num-
bers, and you’ll have comparables. And then you can see if things are
getting slower over time.
I mean, I’m sure we’ve all seen the slow degradation that has hap-
pened to some of our favorite applications. I remember back in the
Winamp days—Winamp 3 was so good; 3.1 was amazing. Then AOL
bought it, it became version 4, and suddenly it was a heavy beast.
People stopped wanting to use it because the performance wasn’t
there anymore. It wasn’t the lightweight, great MP3 player that it once
was. And then [for] version 5, they rolled back to version 3 basically.
There’s something to be said for performance. And if you don’t have
those metrics, you won’t realize that it’s getting slower over time. You
need to find a way to measure it and keep a history of it and make sure
everyone is aware of it.
trick
Pa
EPISODE 332: testguild.com/a332 Co-Founder

of ApiFortress
P
o u lin
Think of an application that you use regularly and that you suspect might be
getting slower over time. It could be a mobile app, a desktop program, or even
a web-based service. Start testing the performance of the application at each
phase, release, or update. Record the metrics and numbers of each test and
compare them to the previous ones. Analyze the trends over time and see if
there’s a degradation in performance.
If you notice any performance issues, document them, and report them to
the development team or the product owner. Try to work with them to come
up with solutions to address the issues and improve the overall performance
of the application. Remember, keeping track of performance metrics and
communicating the results to the team is essential to ensure the success of
an application in the long run.
155
o n ab
ti
le
ac
DAY
156
ss
aw
e
s
e
omen Design your code with testability in mind right from the beginning.
This means keeping your logic separate, having small, modular com-
ponents, and building in test hooks. By doing this, you can write your
tests right from the beginning, even for small components, and know
that you have successful code written when your unit tests pass.
It’s essential to get everyone on the team to participate and collab-
orate in this process, but if there’s someone who doesn’t want to par-
ticipate, it’s challenging to move them. Hence, it’s important to create
a culture where everyone sees the benefit of writing tests and the pos-
itive outcomes that result from it.
anine
Je
EPISODE 144: testguild.com/144 Software Test

Professional
Ru
st
On the last project you worked on, did you design your code with testability
in mind? Did you have small, modular components with built-in test hooks?
If not, what could you have done differently?
Consider ways to create a culture where everyone on the team sees the
benefits of writing tests and collaborating in the process. What steps can
you take to encourage participation and ensure successful code from the
beginning?
156
o n ab
ti
le
ac DAY
157
ss
aw
e
s
e
omen Focus on how you can become a better influencer, whether that
means finding people inside your company who are good at it and
learning from them, reading books on influence, or any other way.
This is important not just for your job but for your life. If you can
improve your skills in this area, many new possibilities will open up.
a
on l d
R
n
Co-founder of
oh
Cu
Global App
Testing -
J
m
mi
ngs
As a software tester, your job isn’t just to find bugs. It’s also to influence people
to take action based on your findings. Your ability to influence others is critical
to your success as a software tester.
Think about a recent testing project you worked on. Who did you need to
influence to get things done? Was it a developer, a project manager, a busi-
ness stakeholder, or someone else? Reflect on the strategies you used to
influence them. Were they effective? What could you have done differently
to get better results?
After this reflection, take some time to research and learn more about how
to become a better influencer. Check out books, podcasts, and online courses
that can help you develop your skills. Find a mentor or colleague who excels
in this area and learn from them. Focus on how you can improve your ability
to influence others, not just in your testing role but in your personal life as
well. The better you become at influencing people, the more opportunities
will open up for you in your career and in your personal life.
157
o n ab
ti
le
ac
DAY
158
ss
aw
e
s
e
omen If you’re writing automated tests and you’re still triggering them
manually, you’re not getting the full value. . . .You have to connect it to
some CI platform. You have to run it, and trigger it for every code
change. Otherwise, you’re not getting the real value of having this fast
feedback loop.
Because the way I see it, we know that tests are about quality, but
for me it’s also about agility and the ability to move fast. I mean, we
obviously won’t compromise [on] quality; we want the best quality for
our product. But for me, automated tests are like this fixed fast feed-
back loop where you change something and you immediately know
that you didn’t break anything, and you can move forward.
Ido

of Loadmill
C
ohen
Have you integrated the automated tests you’ve run in the past with a CI/CD
pipeline to ensure that they run automatically with every code change? If not,
what steps can you take to connect them to your pipeline?
Consider the benefits that come with having a fast feedback loop, including
agility and the ability to move quickly while maintaining quality. Reflect on how
you can improve your automated testing processes to maximize the value of
your tests, and the impact it can have on the product’s quality, delivery, and
overall success.
158
o n ab
ti
le
ac DAY
159
ss
aw
e
s
e
omen . . . For anyone who wants to start [in AI], I think the barrier to entry in
the last couple of years has just been dropped so low that anyone can
start to play with these things. I think there’s something made by
Google (ai.google), but you can basically just build AI-based models
without any sort of expertise or training. You can say, “Here are three
pictures of dogs, here are three pictures of cats,” and it can build an ML
model for you that can look at it and determine if it’s a cat or dog. If you
want to play with it, you can start today. There are a lot of open source
and free tools out there as well that you can check out. And there’s
also the AI for Software Testing community that is focused exclusively
on this and sends out emails, so that’s a good resource as well. Just be
open-minded and try things out.
Some AI may not apply to your particular need or might not work for
your particular use case, but some of it might work really well. It’s worth
honing your craft and trying things out. Continued self-development is
always useful, so try to find some time to play with all of these tools.
r
Ch i s
EPISODE 410: testguild.com/a410 CEO of

Dev Tools
s
N
a
v ride
Think of an aspect of your work that could benefit from the use of AI, whether
it’s related to software testing or any other area of your job. Spend some time
researching the open source and free AI tools that are available and see if you
can find one that could help with your particular use case.
Once you’ve found a tool that looks promising, take some time to experi-
ment with it and see if it can improve the efficiency or accuracy of your work.
Don’t be afraid to try out different tools or techniques, even if they don’t work
perfectly at first.
Remember that AI is a rapidly evolving field, and continued self-develop-
ment and experimentation can lead to new possibilities and innovations.
Share your learnings and progress with others in your team or community to
help spread awareness and encourage others to explore the potential of AI in
their work as well.
159
o n ab
ti
le
ac
DAY
160
ss
aw
e
s
e
omen Do some research on data generation tools. Check out what’s out
there. You know, you’re not alone in having to create quality test data.
It’s a problem all teams are facing right now, and there are a lot of
new tools out there on the market. Check them out because they will,
in the long term, even in the short term, save you a lot of headaches,
a lot of time.
It really shouldn’t be that the burden is on developers or testers to
create data, to de-identify the data in-house. It’s just too much. The
data is too big, it’s too complex, and it shouldn’t be your responsibility
to ensure data privacy and security within your testing environments.
Seek out a tool, because they’re worth your time.
iara
Ch
EPISODE 405: testguild.com/a405 Product

Marketing
i
o
C
Manager lomb
Think about the data generation process in your testing workflow. Are you cre-
ating test data manually, or are you relying on developers to create it for you?
Research and explore the data generation tools that are available in the
market and consider how they can benefit your testing process. What are
the pros and cons of implementing such tools? How much time and effort
could be saved by using automated tools for data generation? Are there any
potential risks associated with using these tools, such as data privacy or secu-
rity concerns?
Once you’ve done your research, meet with your team and determine
whether using a data generation tool could benefit your testing process and
ultimately improve the quality of your product.
160
o n ab
ti
le
ac DAY
161
ss
aw
e
s
e
omen If you write tests, run them as frequently as you can. The more fre-
quently you run your tests, the more details you get. Automated tests
can be dumb and sometimes fail for weird reasons, like time zone,
nightly builds, weird infrastructure, timeouts, and hardware problems.
To eliminate all of these issues, your tests should run all the time. You
can create a separate machine to run the tests nonstop.
u s l an
R
DevRel
Ak
ov
Lead at
n
m
Qameta e t zia
Are your automated tests running frequently enough to give you the most
detail? If not, what’s stopping you from running them more frequently? Is it a
technical limitation or a process limitation?
Consider ways to overcome these limitations and explore the benefits of
running your tests all the time on a separate machine. What impact could this
have on the reliability and stability of your automated tests? How could it help
you catch bugs and issues earlier in the development cycle? Take action to
increase the frequency of your automated tests and evaluate the results.
161
o n ab
ti
le
ac
DAY
162
ss
aw
e
s
e
omen With software being very, very complex, with multiple moving parts
like cloud native services, gateways, endpoints, databases, and multi-
ple repos, you really need to think about your environment as more than
just microservices. And you really need to think about local develop-
ment. The IDE is always going to be local, but with the evolution of
[the] cloud, I think it’s about time we moved part of the development
process to the cloud.
So, yeah, I just urge engineering leaders to measure what the team
is doing, how productive they are, and then think about the environ-
ments more realistically.
a
Sh ni

of 21 labs S
m
ho
ha
Are there any pain points in your development process and development
environment that slow you down and hinder productivity? Consider how
moving part of your development process to the cloud could help alleviate
some of these issues. Research the available cloud-based development tools
and environments, and evaluate their benefits and drawbacks. Analyze how a
cloud-based development environment would impact your team’s productiv-
ity and decide whether to transition some parts of your development process
to the cloud.
Finally, communicate the benefits of moving to the cloud, and implement
the necessary changes to improve the overall efficiency and productivity of
your team’s development process.
162
o n ab
ti
le
ac DAY
163
ss
aw
e
s
e
omen It's important to remember that when managing test operations,

recognize that there is no perfect solution.
The key is to strike a balance between control and speed, accepting
that some trade-offs are necessary. Embrace adaptability to address
issues and continuously improve your testing process quickly.
To achieve this balance, consider these steps:
• Shift left: Aim to catch bugs early in the development

process by integrating testing into earlier software
lifecycle stages.
• Federate and fragment: Delegate responsibilities to
individual teams and developers, allowing them to manage
their tests and take ownership of any issues that arise.
• Be selective: Focus on running specific tests for the
changes made to minimize flakiness and ensure more
accurate results.
• Use available tools: Don't hesitate to use third-party tools
like Testim to help manage and scale your test operations.
They can save time and resources while still providing
necessary functionality.
• Accept imperfection: Understand that no solution will be
perfect and that trade-offs are inevitable. Find a balance
between control and speed that works best for your team
and project.
Finally, remain open to learning, adjusting, and evolving your

approach to test operations as new challenges and opportunities
arise. By embracing balance and adaptability, you can create a more
efficient and effective testing process that meets your organization's
needs.
Maor
Principal
EPISODE 353: testguild.com/a353 Software
Engineer at F
l
r e
ank
Microsoft
Reflect on your current testing process and identify areas where you can strike
a balance between control and speed while embracing adaptability. Consider
the steps outlined in the quote and take action to improve your testing
process. Discuss your findings and possible improvements with your team and
create a plan to continuously evolve and adjust your test operations as new
challenges arise.
163
o n ab
ti
le
ac
DAY
164
ss
aw
e
s
e
omen I think it’s really important, whether you’re starting a new QE initia-
tive or looking to up-level your existing efforts, to develop a vision—to
start with, where do we want to go as a team and to make sure that’s a
long-term view, that you get buy-in from all the stakeholders in your
team. . . . You really want leadership and executive-level support in that
vision, because one thing I’ve seen is these initiatives, they sound
great at the start—you have one good champion and, you know, she’s
driving things to get going—and then maybe she leaves or maybe the
winds change direction internally and things get blown off-course.
And so I think you need to get that sort of alignment up and down the
organization to say, “We’re going to go do this together.”
Dan

of mabl B
r
el
che
Take some time to reflect on your current QE initiatives, or if you’re starting a

new one, think deep about your vision for the team. What do you want to
achieve in the long term?
Once you have a clear vision, share it with all stakeholders and get buy-in
from everyone, including leadership and executives. This will help ensure that
your initiatives are sustainable and that you can weather any changes that
may come along.
Remember, having a strong vision that is supported by everyone in the
organization can be a powerful force in driving success.
164
o n ab
ti
le
ac DAY
165
ss
aw
e
s
e
omen My top tip is to live in the codebase and write tests as closely as you
can to it. Whether that’s pairing with the developer to get started with
API or contract testing, you often need a developer to get you started.
That’s my top tip: pair as much as you can.
wis
Le
EPISODE 399: testguild.com/a399 QA Lead
t
P
r
e s c ot
Think about a recent project or codebase you worked on as a tester. How

closely were you able to work with the developers? Were you able to pair with
them to write tests, or did you work in silos? Consider how this impacted the
quality of the tests and the overall product.
Next, identify a project or codebase you’ll be working on soon. Consider
how you can build stronger partnerships with the development team to
ensure that you’re writing tests that are as close as possible to the codebase.
Can you arrange for regular pairing sessions to write tests together? Are there
other opportunities for collaboration that you could explore? Plan how you’ll
work closely with the development team on this project, and follow through
on that plan.
Remember, the closer you can work with the development team, the more
effective your tests will be, and the higher quality the final product will be.
165
o n ab
ti
le
ac
DAY
166
ss
aw
e
s
e
omen I think the biggest thing, especially as our industry and technology
evolves, is that there’s not going to be a one-size-fits-all solution. . . . I
meet a lot of engineers and QA professionals who are like, “I’m looking
for something that can test web and mobile and physical,” and I’m like,
“I don’t think I know any solution on the market that’s going to do all
three or [meet] all of your needs.”
I think a good palette, a good portfolio of QA tools, is going to
involve a web-first tool. There are a lot of excellent ones out there.
And there is a time and place for running automated UI tests,
whether it’s [with] XCUI, Espresso, Appium, or whatever it is. And then
I do think there’s a final place for physical testing, for UI testing. And
so I think the one thing that I would want to share with everyone is [to
be] open-minded.
Yes, there’s this convenience of, yeah, I could just pick one tool and
it’ll solve all my problems for me magically. But if anyone’s run a QA
process for a few years, [they’ll] know that it’s a combination of tools
that will solve [their problem, including] welcoming human interven-
tion and feedback into that process. I think CI/CD is something that’s
great to aspire to, but I also think about being reasonable with what’s
actually happening in reality, rather than just falling back on ideologi-
cal DevOps best practices. And so I think it’s good to think about
having a portfolio of tools rather than one size fits all.
Ed e n

of Mobot
h
u
F
ll Go
Reflect on your QA testing approach and consider whether you’re relying too
heavily on a one-size-fits-all solution. Are you falling back on idealistic
DevOps best practices, or are you open to trying out a variety of tools and
being reasonable with what’s happening in the industry?
If the latter, think about building a portfolio of tools that can solve your
unique challenges, and consider welcoming human intervention and feed-
back into your process.
166
o n ab
ti
le
ac DAY
167
ss
aw
e
s
e
omen To ensure that your app or software is robust and not frustrating to
users, it is important to focus on delivering value consistently and
avoiding disappointment. To achieve this, you can start by defining
what robustness means for your application and create robustness
requirements, similar to usability and performance requirements.
One technique to test for robustness is through random strikes,
where you do things that may be stressful to the application, both
expected and unexpected. To make this testing more effective and with
a larger sample set, you can consider using a tool that can perform
these strikes.
Another technique is to create an exploratory testing charter
focused on robustness, where you target a feature or a transaction or
a scenario and investigate and assess the robustness of the soft-
ware. This can be challenging, but it is necessary to ensure that the
software is robust and not frustrating to users.
To get everyone on board and committed to robustness testing, it
is important to have conversations about what it means, the barriers
to achieving it, and how to overcome those barriers. By doing this,
you can ensure that robustness is not just paid lip service but is an
essential part of the conversation, and everyone has a level of commit-
ment to it.
w
Da n
EPISODE 10: testguild.com/p10 Testing

Yogini &
H
Coach ay n e s
What steps can you take to ensure that your app or software is truly robust as
opposed to just functional? Consider the importance of defining robustness
requirements and implementing techniques such as random strikes and ex-
ploratory testing charters. How can you involve everyone on your team in the
conversation about robustness and overcome any barriers to achieving it?
Reflect on these questions and take action to prioritize robustness testing
in your development process. Remember, creating a robust software appli-
cation isn’t just about delivering value, but also ensuring that users aren’t
frustrated by bugs and errors.
167
o n ab
ti
le
ac
DAY
168
ss
aw
e
s
e
omen If you’re curious about testing and wondering where to start, let me
share with you my top piece of advice: start today. It’s all too easy to
get caught up in the complexities of legacy code or feel overwhelmed
by the thought of adding tests to an existing project. However, if we
take a step back and look at the bigger picture, we can see that testing
is an investment in the future of our codebase.
Imagine we’re two years into a project and we haven’t written a
single test. That means our entire codebase is currently 100%
untested. But if we start writing tests today and keep at it consistently,
we’ll eventually reach a point where the majority of our code is cov-
ered by tests.
Don’t worry if you’re new to testing or if your first few attempts at
writing tests aren’t perfect. Starting small is key, and as you continue
to learn and improve, you’ll start to see the benefits of testing first-
hand. In fact, I’ve found that writing tests can be so satisfying that I
sometimes lose track of time and end up staying late just to write a
few more!
So my advice to you is this: don’t let fear or uncertainty hold you
back. Take the plunge and start writing tests today. Even if it’s just one
test at a time, you’ll be amazed at how much your codebase can trans-
form over time. Sure, it may be challenging at first, but remember that
every mistake is an opportunity to learn and grow.
Nate
Director of
Engineering at Ta
ylor
Pluralsight
Take a moment to decompose your system into smaller parts and identify one
small part of the system that you could start testing today. It could be a single
function or a single module. Write a test for that small part of the system and
see it pass.
Take note of how you feel and the benefits you see. Do you feel more con-
fident about the code? Can you catch bugs more quickly? Are you able to work
more quickly and with fewer manual tests? Use this small win as motivation to
keep writing tests for other parts of the system. Remember, it’s never too late
to start writing tests!
168
o n ab
ti
le
ac DAY
169
ss
aw
e
s
e
omen To effectively address performance issues in your application, it’s

important to first understand your problem and what you need to
solve. Ask yourself why you want a more performant application and
focus on what you really need to solve. Performance and security
should be built into the DNA of your team, and everyone in the team
should be concerned about how their code will affect the overall per-
formance of the application.
This should be considered before defining performance tests or
load performance tests. Take a collaborative approach by talking to
your developers and the rest of the team, and use tools like k6 or
Gatling to experiment and see how easy it is to test performance. It’s
important to have everyone on board for real change to happen.
s ti a n
ri
o
EPISODE 87: testguild.com/p87 Solution
Architect &
C
Test Advocate unha
How can you collaborate with your team to build a culture of performance and
security in your application? Start by asking yourself why you want a more per-
formant application and what problems you need to solve. Build performance
and security into the DNA of your team, and have everyone concerned about
how their code will affect the overall performance of the application.
Before defining performance tests or load performance tests, take the time
to understand your problem and what you need to solve. Experiment with
tools like k6 or Gatling to test performance, and talk to your developers and
the rest of your team about your findings. Real change can happen when
everyone is on board, so collaborate to create a culture of performance and
security in your application.
169
o n ab
ti
le
ac
DAY
170
ss
aw
e
s
e
omen The best thing I can say is to look at where your pain points are.
Every software system has its own set of annoyances, so when you’re
examining the systems you work with, ask yourself: where do I feel like
I’m having to work against the system? These are the best places to
focus on to make improvements. This is true whether you’re a software
engineer, SRE, DevOps tech, QA, or engineering manager. Everyone
can benefit from identifying and addressing pain points.
m
Ja ie
EPISODE 86: testguild.com/p86 Author of

Software R
l
ie e
Telemetry des
Identify where you feel like you’re having to work against the system. Once
you’ve pinpointed these areas, take action to address them. You could start by
discussing these pain points with your team or manager and brainstorming
potential solutions. Consider how you might leverage your skills and expertise
as a software engineer, SRE, DevOps tech, QA, or engineering manager to
make meaningful improvements.
Remember that everyone can benefit from taking a proactive approach to
identifying and addressing pain points in software systems, so take action and
start making positive changes today.
170
o n ab
ti
le
ac DAY
171
ss
aw
e
s
e
omen The biggest piece of advice is to not panic, and not be intimidated
by it at all. I think, again, there’s really no ideal to get to. Any change
you make in the way you’re doing things is likely to be positive. I would
just view it as something where you can go and pick and choose, and
figure out what’s best for your project, and what changes you could
make tomorrow that might make everything better. It might be that
that’s all that you need. You don’t have to look at the end goal and then
kind of get intimidated and think I’ll never get there; I’m not even going
to start.
I really like the idea in the book by Jez Humble and David Farley,
Continuous Delivery. It says something about if something hurts, bring
it forward, or something to that extent. I would just go and look at your
processes and figure out what is the most painful thing, which is
almost definitely going to be something that people are avoiding. Like,
what is the thing that everyone avoids doing, or that we only do once
a year because it’s so awful to do? And I think that, inside of that,
there’s probably something that you could tackle incrementally. You
don’t have to solve the whole thing, but that’s where I think there’s the
most potential to really not only make your processes better, but also
to make everyone’s lives easier and reduce the stress level overall,
which is important.
isti
hr e
C
Author of
EPISODE 387: testguild.com/a387 Grokking
Continuous W
il s o n
Delivery
How can you identify the most painful and avoided aspects of your processes
in order to make meaningful improvements? Take some time to reflect on
what aspects of your work cause you the most stress or anxiety. What tasks do
you find yourself putting off or avoiding altogether?
These pain points may not be immediately obvious, but by identifying them
and working to improve them incrementally, you can not only improve your
processes, but also reduce stress levels and make everyone’s lives easier.
Remember that any change, no matter how small, can make a positive
difference. So don’t be intimidated by the big picture. Just focus on what you
can do tomorrow to make things better.
171
o n ab
ti
le
ac
DAY
172
ss
aw
e
s
e
omen I’m a fan of learning programming. It’s important to learn program-

ming concepts, not just specific languages like Java or JavaScript. You
need to learn how to program, and then apply it to different languages
to get a sense of how to solve problems. Once you have a good grasp
of programming, the next step is to go to Test Automation University.
They have great content and teachers, and it’s a lot of fun to learn
there. You should take advantage of the wealth of information avail-
able there to improve your testing and test automation skills.
The last thing I would like to say is that it’s important to keep moving
forward and not stand still. Always think about what the next interest-
ing step could be, like learning about AWS Lambda or AI. Don’t be
afraid to explore new topics and technologies to keep growing and
improving your skills.
trick
Pa
EPISODE 375: testguild.com/a375 Lead Software

Quality Engineer
D
ö rin g
Reflect on your journey with programming and test automation. Have you
only focused on one language or technology? Challenge yourself to learn
programming concepts beyond what you’re comfortable with, and apply
those concepts to different languages and tools. Consider enrolling in Test
Automation University or take TestGuild courses to deepen your knowledge
and gain new insights.
Lastly, embrace a growth mindset and constantly seek out new areas of
learning and exploration. What are some emerging technologies or trends
that interest you? How can you incorporate them into your work or personal
projects? Act today to expand your skills and push yourself to the next level.
172
o n ab
ti
le
ac DAY
173
ss
aw
e
s
e
omen I think the most actionable thing to do is to contemplate whether

your software development lifecycle is efficient, because a lot of times
people sit on their laurels and say it’s good enough because it’s hard.
Trying to fix it yourself is a difficult problem. We tend to find that many
companies haven’t really thought deeply about what their process
would look like if it was more efficient. What if environments were
ubiquitous? How would that change our ability to get products to our
customers faster and ultimately grow faster? People just live with these
noneffective ecosystems because getting out of it is really hard.
It took me a good two years to solve this problem at my prior com-
pany, and it took a lot of fortitude to go after it. If a product had existed
in the market, it could have shrunk that two-year time span to a month
or six weeks. Engineering leaders need to envision a better state and
not just sit there and say it’s good enough because it is the way that it
is. Once you’ve envisioned that better state, you’ve got two choices:
build or buy. It’s a waste of money to build it in-house.
mmy
To

of Release
g
M
cC
lun
Take a step back and evaluate your software development lifecycle. Are there
any areas where the process could be made more efficient? Are there any
tools or technologies that could be implemented to speed up the process?
Consider the possibility that your current system might not be good enough,
and envision a better state for your software development ecosystem.
Once you’ve identified areas for improvement, decide whether to build or
buy the solutions. What are the costs and benefits of each option? How much
time and resources will it take to implement the changes? What will be the
impact on your team and your customers?
Take action to make the changes necessary to create a more efficient soft-
ware development lifecycle. And remember, it’s not enough to sit on your
laurels and accept the status quo. Don’t be afraid to take on the difficult
problem of improving your software development process.
173
o n ab
ti
le
ac
DAY
174
ss
aw
e
s
e
omen One overlooked area in testing is data validation. When dealing with
data from multiple sources that you want to bring into a centralized
database, many things can go wrong. Typically, a development team
owns these data feeds and has custom ETL code that transforms the
data to fit into your application’s database. The problem with this
approach is that developers usually don’t test these transformations
performed by their code thoroughly. They might do some sampling,
but when dealing with large data sizes, this approach is more of a hope
and prayer that they will catch any issues.
The team will be thrilled if you can provide an ETL testing frame-
work that can find all kinds of edge cases. Plus, clean data is vital for your
application. I advise shifting left as far as possible to validate data.
B il l

of RTTS H
ay d u k
How is data validation being handled on your applications or projects? Are

there any potential risks or issues that could arise from not thoroughly testing
data transformations?
Brainstorm ways to implement ETL testing and data validation earlier in the
development process, and consider how this could improve the overall quality
and reliability of your application or project. Additionally, think about how
clean and reliable data could benefit your users and stakeholders, and how it
could positively impact the success of your project.
174
o n ab
ti
le
ac DAY
175
ss
aw
e
s
e
omen In the past couple of years, with all that’s happening in the world,
companies have realized that they need to be more nimble and agile
in their business processes, in the way they respond to changes. This
has led them to think about transforming their ERPs—the backend
ERP, their financial systems, their supply chain systems, [and] their
human experience management system. So those migrations are
underway.
A simple example is migration to the cloud. At this point in time, only
9% of enterprises have moved their ERP to the cloud, which means
that there are still 91% out there which are going to make this transition
over the next seven to eight years. It’s a big pain area in the market.
Companies are not ready for that.
So, if you are undergoing an ERP migration in the next couple of
years or as we speak, or [undergoing] an ERP transformation program,
think about test automation not just as a time or money-saving measure,
but also as something that can really help you transform your ERP
experience for your users.
nka
Pa j
EPISODE 395: testguild.com/a395 CEO at

Opkey
G oel
How can test automation play a critical role in the transformation of ERP
systems? Consider the challenges and opportunities presented by the migra-
tion to the cloud and the need for companies to be more agile and responsive
to changes. What are the potential benefits of incorporating test automation
into your ERP migration or transformation program? What are the risks of
neglecting this aspect of your project?
Think about how you can leverage test automation to not only save time
and money, but also enhance the user experience and overall success of your
ERP project.
175
o n ab
ti
le
ac
DAY
176
ss
aw
e
s
e
omen You don’t necessarily have to select Java as your programming lan-
guage, and sometimes it’s selected for the wrong . . . reason: . . . the
idea of “if you only have a hammer, everything looks like a nail.” If
you only have Java developers and you ask them what language
should we use for our automation and they say, oh, I’ll do it in Java,
because once it falls to us, we’ll be able to handle it, that’s really kind
of a fallacy.
. . . The idea is that it really doesn’t matter what language you program
in; but consider using the languages that you know . . . that don’t have
such a large footprint as Java.
As SDETs, every day we are either going to be spending time writing
test cases or debugging and extending our framework. Why use the
language that has so many more characters and intricacies to build,
and spend your time doing that, rather than building more test cases?
I don’t see the advantage of that, so I do recommend looking at differ-
ent languages that are available out there. Java just isn’t the only thing
that’s out there. Selenium supports at least six different languages out
there, so do consider that.
Paul
EPISODE 371: testguild.com/a371 SDET
n
r
o a
ssm
It’s important to select the right programming language for test automation.
Are you defaulting to a language simply because it’s what your developers
know, or have you considered alternative languages that might be easier or
more efficient to work with? Take a step back and evaluate your approach to
test automation language selection. Are you making the most of your time and
resources, or are you stuck using a hammer when a different tool might be
more effective?
Think about exploring other programming languages supported by auto-
mation tools, and see if they might offer you benefits you hadn’t previously
considered.
176
o n ab
ti
le
ac DAY
177
ss
aw
e
s
e
omen When deciding on a framework for mobile application testing, it’s

important to understand your needs and the critical components of
your application, such as how it works on iOS and Android devices.
Native application frameworks, like XCUI Test for iOS and Espresso or
UI Automator for Android, can be fast and reliable but may still be flaky
and hard to maintain.
If you want your application to run on both iOS and Android, Appium
is a great option for cross-platform testing. Appium is a hybrid frame-
work that encompasses native frameworks like XCUI Test and UI
Automator to create one script that can run on both platforms. How-
ever, Appium, which also encompasses these native frameworks, is
slower than the native frameworks and can be a deterrent for some
customers who prioritize speed.
Ultimately, choosing a framework depends on what works best for
your individual needs, with both native and cross-platform frame-
works having their own pros and cons.
nn o
ha
n
EPISODE 385: testguild.com/a385 Dev Evangelist
at Kobiton
Lee
Reflect on your experience with choosing technology or tools for a project.

Did you consider your needs and critical components of the project before
deciding on the technology? Have you ever experienced issues with frame-
works that were flaky or hard to maintain?
Think about how cross-platform frameworks like Appium can provide a
solution to device fragmentation, but at the cost of speed. What do you priori-
tize in your testing framework? Is it reliability or speed? Consider the trade-offs
and make an action plan to evaluate and choose the best testing framework
for your next project based on your specific needs.
177
o n ab
ti
le
ac
DAY
178
ss
aw
e
s
e
omen When deciding if you need service virtualization when testing, use
the ABCD of service virtualization checklist. There are four primary
obstacles that service virtualization needs to resolve.
A is for availability. In your enterprise, you may have teams that work
on different schedules that are developing services. Services just may
not be available, they just might be brittle, and [just] in that particular
environment, due to whatever deployment constraints.
B is for behavioral constraints. That’s when you’re looking for a spe-
cific behavior from a particular service—could be a third-party service,
could be again an internal service—but in a context of a test environ-
ment, you just can’t get it in the right state. And so service virtualization
can aid with that.
C, for Cost, is a big one with third-party components because let’s
say you’re integrating with some third-party component; they charge
you 2 cents a hit or less than 0.2 cents a hit or something like that.
But then all of a sudden you have to do performance testing in that
environment. That cost is going to scale exponentially, right? So that’s
prohibitive; it’s prohibitive in the context of performance testing or any
kind of testing if you’re being charged per hit like that.
And then finally there’s D: data. So just having access to nonpro-
duction data, having access to test data that is reusable, that you can
redeploy on demand, is another constraint for test automation.
So service virtualization can address all four of those, whether
you’re standing up at any point just because you don’t have one or
because you need a certain state or you need data, or you just want
to reduce costs due to integrations with third-party systems or third-
party applications.
rigori
G
EPISODE 394: testguild.com/a394 Senior Solution

Architect at
r
T
Parasoft o fi m o
What are some ways you can identify and prioritize the obstacles that service
virtualization can resolve in your testing environment? How can you use the
ABCD of service virtualization checklist to assess the availability, behavioral
constraints, cost, and data challenges your team is facing? In what ways can
service virtualization help your team overcome these obstacles and achieve
more efficient and effective testing?
Consider evaluating your current testing process and identifying areas
where service virtualization can make a positive impact.
178
o n ab
ti
le
ac DAY
179
ss
aw
e
s
e
omen The best advice I can give is to always pair up. Collaborate with your
team members, ensure everyone is on the same page, learn from your
peers, and learn about the product and its benefits. Don’t just test and
learn everything around it, but learn the story behind the data you’re
using. Why is it helpful? How are you helping test this product?
Boost your testing, and if there’s another type of testing you can
bring in, whether functional or nonfunctional within the data science,
don’t hesitate to bring it. For instance, if you’re testing on the front end,
ensure accessibility is part of it. This is important because if your future
customer has a permanent or temporary disability, we cannot leave
them out. So focus on these things as well.
v ee n a
La
Test Manager
ni
Ra
a
m
ch d
an
Think about a recent project you worked on and reflect on how you
approached testing. Did you collaborate with your team members? Did you
learn about the story behind the data you were using? Did you consider non-
functional testing aspects, like accessibility?
If the answer to any of these questions is no, consider how you can improve
your testing process by pairing with your team members, learning about the
product and its benefits, and considering both functional and nonfunctional
aspects of the product. Brainstorm ways that you can incorporate these
strategies into your future testing efforts, and discuss them with your team to
ensure that everyone is on the same page.
Remember, effective testing requires collaboration, learning, and a focus
on the customer, so don’t hesitate to bring in new ideas and approaches that
can help improve the quality of your product.
179
o n ab
ti
le
ac
DAY
180
ss
aw
e
s
e
omen There is a concept called the Tyranny of Or. Let’s not get caught up
in the Tyranny of Or. For us, this is the end. We incorporated Cypress
testing into our platform because there’s a legitimate need for a tool
like that: developer-friendly, and a little bit lighter weight than Sele-
nium, without the full black box testing that Selenium does. Each has
its place. That’s why we also support Puppeteer, Playwright, and Test-
Cafe on our platform. We should have had the separate API testing
feature years ago.
. . . For many years, Sauce Labs was purely Selenium-focused.
People who generally use Selenium are very familiar with this, and it’s
a Selenium-like board member telling you this: people have overused
Selenium for years, and as much as I believe it absolutely has its place,
at Sauce, what we’re doing is pulling the camera lens back and saying
Selenium occupies exactly this much space in the process. We just
believe that it all ought to be under the same roof. And there’s not just
one size that fits all.
arcus
M
VP of
EPISODE 396: testguild.com/a396 Technology
Strategy at M
l
e r ril
Sauce Labs
What are the different types of testing frameworks that you use in your orga-
nization, and how do you determine which one to use for a particular project?
Are you falling into the Tyranny of Or trap by thinking that one framework is
better than all others? How can you ensure that you’re selecting the best
testing framework for each project, and that you’re not limiting your options
by focusing on just one?
Consider taking a step back: evaluate all the testing options available to
you, and think critically about the strengths and weaknesses of each.
180
o n ab
ti
le
ac DAY
181
ss
aw
e
s
e
omen How do we define unit tests . . . [and] why do we often call them inte-
gration tests? . . . Especially in the developer community, it’s completely
fuzzy about the definitions of those different layers.
I recently read an article from Kent Beck and Erich Gamma. They
wrote it in the ‘90s after they created the JUnit framework, which
allowed developers to write tests as part of the Java code, making
test-driven development more accessible in general. In my opinion,
with test containers, a way to very easily spin up integration testing
dependencies like your database, it suddenly becomes much easier
for you as a developer to write an integration test. This can change the
way you think about composing your test suite.
Before, you might have done a lot of mocking and not wanted to do
an integration test against a database because it was messy to set up,
or it was flaky because you were sharing the database with someone.
However, now you can just instantiate a Java object that is your
abstraction. This will then spin up the container with the database, and
then you can run an integration test against the test SQL. This just
changes the way you test and develop, and it’s not a lot of work. Well,
sometimes it takes a little bit more time to spin up stuff, like in the area
of seconds, so you have to be mindful of this when you want to do it
and/or not.
It’s still beneficial to decompose your test, so if you have pure
functions, it’s okay to test them as pure functions and not do a big
integration test. But if you are testing your integration with another
technology, like with the database or with Kafka, and you want to use
the full power of this other technology, my advice is to embrace
integration testing instead of building additional abstractions that then
do not allow you to use the full power of the service in your application
anymore.
Kevin

Engineer
W
it t e k
How do you approach unit testing and integration testing in your development
process? Do you believe there is a clear distinction between the two, or do you
think the lines are often blurred? What benefits do you see in embracing
integration testing, and how can tools like test containers help make it more
accessible?
Think about your testing strategies and consider how you might adjust
them to take advantage of the benefits of integration testing.
181
o n ab
ti
le
ac
DAY
182
ss
aw
e
s
e
omen I think the main challenge that I have personally seen over the years
is that there is sort of a challenge that projects have in terms of bal-
ancing the speed of delivery and the quality of software. So obviously,
with the rise of CI/CD tools, development cycles have tremendously
shrunk to a few hours and people are essentially delivering software
on a weekly basis, sometimes even shorter cycles. But what has been
lagging is mainly automated testing, and historically, projects have
tried to scale up their testing through manual efforts and by providing
more and more resources to be able to do that. But obviously, that
becomes a cost barrier to the project. Then obviously there is a limit as
to how much you can scale with manual testing. So I think testing, and
in general, automated testing, has been a main contributor to the
failures of digital projects.
One case for a no-code testing solution is the problem [that] is there
are just not enough automated testers in the market. What I have seen
is that to be able to compensate for that lack of resources in the
market, projects will try to provide eight to 12 weeks, 16 weeks, of
programming training to testers that they have internally tried to
convert them to automated testers. But it adds complexity because
it’s yet another codebase to maintain. And it’s not a project that you will
ever be done with. You must maintain it throughout the lifecycle of
your project. But more importantly, when you have resource attrition
and people leave, finding other resources whom you can train in time
to be able to pick up where the previous people left it off will be its
own challenge as well.
ya
Pa m

Subject7
Ford
Reflect on the balance between speed of delivery and quality of software in

your projects. Consider whether your automated testing is keeping up with the
pace of development and whether there are any barriers to scaling up testing
efforts. Think about the resources that are currently dedicated to automated
testing and whether there are any opportunities to improve efficiency or
reduce costs.
Finally, consider whether a no-code testing solution could be a viable
option for your team, especially if you have limited resources for training and
maintaining a separate codebase for automated testing.
182
o n ab
ti
le
ac DAY
183
ss
aw
e
s
e
omen Nothing beats a good process. So I’ve been speaking to quite a lot
of peers in the industry about the different kinds of software testing,
and they talk about lots of new tools coming up. Ultimately, I think that
when you want to implement automation, you have to go through the
due process of figuring out why you need it and what the actual
benefits are. This is what I call discovery, which involves looking at the
technology, understanding your requirements, choosing the technol-
ogy that best fits those requirements, running a proof of concept, and
making a benefits case.
Nalin

of Infuse P
u
ar
bh
In your projects, are you taking the time to understand why you’re automating
and what benefits it will bring? Do you perform a discovery phase to under-
stand your technology and requirements, and do you choose your automation
tools based on those factors?
Take some time to reflect on how you can improve your process and ensure
that you’re making informed decisions when it comes to automation. Select
a tool or process and run a proof of concept through your SDLC. Consider
discussing the results of the POC with your team or colleagues to get their
input and ideas.
183
o n ab
ti
le
ac
DAY
184
ss
aw
e
s
e
omen If you’re developing for VR, it’s important to take safety into account.
Consider implementing safety tests to ensure that users are aware of
their surroundings and that they can hear important alarms. Addition-
ally, consider the potential discomfort that may arise when multiple
users are in the same virtual space, and take steps to establish secu-
rity and prevent abuse.
To automate some of these safety tests, look into tools that can
simulate test input, such as the ones available in Unity. When testing
VR applications, keep in mind that objects may be located behind the
user, so it may be necessary to rotate the camera and simulate user
actions to properly test functionality. By taking these considerations
into account and using appropriate testing tools, you can ensure that
your VR application is safe and functional for users.
e
No mi

Software
a
Engineer in Test e
F
rrer
Are you developing for VR? If so, act now to ensure the safety and security of
your users. Consider implementing safety tests to ensure that users are aware
of their surroundings and that important alarms can be heard. Additionally,
take steps to prevent abuse and discomfort that may arise when multiple
users are in the same virtual space.
To automate some of these safety tests, investigate tools like the ones
available in Unity that can simulate test input. When testing VR applications,
remember that objects may be located behind the user, so it may be necessary
to rotate the camera and simulate user actions to properly test functionality.
Don’t wait until it’s too late. Prioritize safety and security in your VR devel-
opment by taking these considerations into account and using appropriate
testing tools. Your users will thank you for it.
184
o n ab
ti
le
ac DAY
185
ss
aw
e
s
e
omen When looking at the performance of a mobile app, you need to

observe how the app behaves on a device. We have a lot of devices
that communicate with backend cloud services, and as a result, we
can auto-scale our devices. Therefore, the traditional performance
metrics that we used to consider in the past are not as crucial as they
used to be. However, it is still not an easy task, and we need to make it
efficient. The actual performance bottlenecks now happen on the
device. So, how fast does the UI render, and how long does it take to
start rendering the UI?
Sometimes we might have to wait for some data to come from the
backend data sources, but we don’t want the user to wait for that to
happen before the UI shows up. They want to see the UI start to appear
while the app pulls the data in the background. Therefore, we need to
measure the time it takes for the page to load, CPU cycles, memory,
and other performance metrics associated with the UI. We need to
keep track of how the performance of the device affects the app’s
performance, and we need to treat both of these issues separately.
R ic k
EPISODE 380: testguild.com/a380 Solutions

Architect B
r
roke
Think about the last time you used a mobile app that was slow or unrespon-
sive. What was your experience like? Did you keep using the app or did you
give up and find another one?
Now imagine you’re the developer responsible for the app’s performance.
What steps would you take to optimize the app’s rendering speed and ensure
a smooth user experience? How would you measure and monitor the app’s
performance on the device? Consider researching different tools and tech-
niques for measuring mobile app performance and try implementing them on
a small project to gain hands-on experience.
Remember, in today’s world, users expect apps to be fast and responsive,
so ensuring good performance is crucial for the success of your app.
185
o n ab
ti
le
ac
DAY
186
ss
aw
e
s
e
omen My actionable approach is to not think of testing as piecemeal items.

We often have tests that focus only on units, only on functionality, or
only on regression. Ultimately, these are all steps in the journey
towards achieving full automation.
You can’t have a model-based approach without building upon
unit-based testing, functional testing, and regression testing. The
journey is not just about getting to X and Y in the future, but about
establishing a solid foundation first. This is usually the first thing that
most of our clients ask us: how do we get the end result? But you need
to know what you need to know first so that you can build towards it.
h an
Et
Manager,
Solution
Architect at C
hung
Keysight
Think about a project you’re working on or a skill you’re trying to develop.

Consider the different components or stages that go into that project or skill,
and the tests or checkpoints you’ve put in place to ensure quality and
progress. Are these tests and checkpoints isolated and disconnected from
one another, or are they part of a larger cohesive strategy? How might you
build a stronger foundation for your project or skill by creating a more holistic
testing approach that recognizes the interconnectedness of different stages
or components?
Take some time to reflect on how you can build a more comprehensive
testing approach to ensure the success and longevity of your project or skill.
186
o n ab
ti
le
ac DAY
187
ss
aw
e
s
e
omen One piece of advice is don’t worry, and don’t be scared about your
role, whether it’s as a manual tester, automation tester, or AI specialist.
Nothing will stop us, and we must always be there. You don’t have to
learn every tool out there to advance in your career; you can always
be a quality influencer. You don’t have to do everything, but you can
always influence quality. So don’t be afraid that the tester’s job will
disappear or anything like that.
ve e
ar
P
n
EPISODE 379: testguild.com/a379 Senior QA
Consultant
Kh
an
Are you worried about the future of your role? Do you feel like you need to
learn every tool out there to stay relevant?
Take a step back and ask yourself what you can do to be a quality influencer,
and what you can do to improve the quality of the products or services that
you’re involved in. Reflect on how you can adapt and evolve in your role, rather
than being afraid of change. Take the time to explore your options and find
ways to grow and thrive in the industry.
187
o n ab
ti
le
ac
DAY
188
ss
aw
e
s
e
omen Mobile user expense performance is more significant than on the

web. . . . Companies like Google, Apple, and Facebook—those com-
panies are excelling in providing excellent user experience. Most
companies are trying to replicate the same user experience found at
the top companies. People are used to this level of user experience,
and this is becoming a de facto standard.
People’s expectations have changed. For instance, say, five years
ago, a 5-second response time for a page was decent. Today the
expectation is the page should be available in [a] 2-second response
[time]. So I think that I really encourage any functional engineer, a
functional automation engineer, to learn more about the performance.
I think that this is a highly needed requirement for a functional engi-
neer, and this is going to grow over time.
Guy
CTO of
Continuous
Testing at A
r i e li
digital.ai
How can you improve the mobile user experience of your company’s app?
Research and study current user behavior and expectations, and learn about
mobile app performance optimization techniques. Identify areas where you can
make improvements in terms of app speed, responsiveness, and reliability.
Consider working with a performance testing expert or consultant to help you
develop a comprehensive mobile app performance strategy.
By taking action to improve the performance of your app, you can help your
company meet and exceed the rising expectations of mobile users and stay
competitive in today’s rapidly evolving digital landscape.
188
o n ab
ti
le
ac DAY
189
ss
aw
e
s
e
omen The worst thing about chaos engineering is the word chaos in it,
because it gives people so many ideas and makes it a harder sell. At
its core, chaos engineering is the practice of experimenting on a piece
of software or a system to verify what you think is going to happen
during turbulent conditions. There are a bunch of good reasons to do
this, especially with the cloud and more complicated architectures
like microservices. Emergent properties can arise, where subcompo-
nents may work well in isolation but, when combined, have unexpected
properties that were not accounted for. However, chaos engineering
can also be much more rudimentary than this.
Many people still focus on achieving 100% unit-test coverage,
which sounds great but, in practice, only covers the most basic stuff. In
a distributed context, problems often occur at the border between
different components. There are many things that can go wrong, such
as slowness, which can be difficult to diagnose. Folks should focus on
making their applications as resilient as possible, and using chaos
engineering can help.
ikolaj
M
Author
ki
Pa
of Chaos w
s
Engineering li ko w
Think about a complex system you’re involved with or rely on regularly, such
as a transportation network or financial system. What are some potential
“emergent properties” that could arise if one part of the system fails or expe-
riences turbulence? Consider the different components and the borders
between them, and how they interact under normal and stressful conditions.
Now imagine applying chaos engineering to this system to test its
resiliency and discover potential failure points. How might this help improve
the system and ensure better performance and reliability?
189
o n ab
ti
le
ac
DAY
190
ss
aw
e
s
e
omen If I was to start my automation over again, there are three main
things I would change. One of the biggest things I would do differently
[is] not to just limit ourselves in just the quality team kind of owning this
thing. I would open everything up to all engineering and really get their
full buy-in on it, and just get them involved with the entire process as
well. Because it was a bit of a bottleneck in the sense that there’s a lot
that we wanted to do, and there was still a lot that I was thinking about,
like adding OWASP, static analysis, performance, and all these kinds of
things to our test suites. I think getting the whole team approach
allows you to get different opinions on things. I think that’s the biggest
benefit. . . . I think it’s an amazing thing because you don’t think of
everything, so having a team of folks can bring up options you would
never have thought of.
Nowadays, what I would do is look at AI solutions like mabl. AIOps
is a big thing now and you shouldn’t ignore it. I would try to get that
buy-in for these tools, because it would have saved my team a lot of
time. Leverag[ing] these solutions would have allowed [us] to be able
to scale more quickly, whereas with our own solution a lot of our time
was spent on refactoring tests. I wouldn’t go all in on it, but I think [it’s]
worth some time to evaluate some of the AIOps tools to see if they can
help your team.
And finally, I think getting more comfortable with deleting tests that
repeatedly fail is a big thing. So invest in a whole team approach,
better metrics, and pruning your test suite.
Evan
EPISODE 374: testguild.com/a374 Site Reliability

Engineer o
Ni
l
d
e
o ja d
Think about the automation process in your organization or team. Are there
any bottlenecks or limitations that are preventing you from achieving your
goals? Are you involving the entire engineering team in the automation
process or is it just limited to the quality team? Consider opening the automa-
tion process to all team members and getting their buy-in.
Additionally, consider exploring AI solutions like mabl or other AIOps tools
to see if they can help your team scale more quickly and save time. Evaluate
the benefits and drawbacks of these solutions and determine if they can help
you achieve your automation goals more efficiently.
Finally, are you comfortable with deleting tests that repeatedly fail? Con-
sider the benefits of pruning your test suite and removing unnecessary tests
that may be slowing down your automation process.
190
o n ab
ti
le
ac DAY
191
ss
aw
e
s
e
omen Don’t worry about testing everything. Get some tests done. That
means create some tests and ensure that you have some level of
quality, at least to get started, and learn any new tool or API. Like any
creative endeavor, you must build a number of these browser tests to
really feel confident and comfortable with it.
So write a few tests, see where it starts to work for you, and then go
back and flesh out those areas as you learn the APIs of a test library
more.
nja
So
EPISODE 372: testguild.com/a372 Director of
Qu
f
Engineering
a
a
rtz Le
The next time you need to learn a new tool or API, instead of trying to test
everything at once, create a few basic tests to get started and ensure some
level of quality. As you become more comfortable with the tool or API, go back
and flesh out those areas with additional tests.
Just like any creative endeavor, building several tests will help you feel
more confident and comfortable with the tool or API. Start small and build
from there. How can you apply this approach to improve your testing process
and become more proficient in the tools and APIs you use?
191
o n ab
ti
le
ac
DAY
192
ss
aw
e
s
e
omen Let me tell you about my previous company, which was an AI

machine learning company. Before I started working on day one, I had
zero experience testing machine learning algorithms. Ripple, my
current company, is a crypto blockchain company, and on the first day
of my job, I started learning about what crypto blockchain is. It’s not
necessary to know everything when you have a specific role; the
things you need to know, you can learn on the job. The most important
thing for me is to connect with the hiring team and the recruiter to
ensure that I know what is expected. If I’m hiring for a certain role, I can
teach you the rest, but it’s probably not in the job description.
So, if you’re moving to a new domain or new technology, don’t be
afraid. That’s the first thing. And if there’s nothing else, look for
YouTube tutorials. They’re usually good people explaining big ideas in
30 minutes. That usually helps. Then you can have the theory and start
talking to people to understand what the role actually is.
hya
us n
t
Senior
Manager,
Software
a
A
c
h a ry
Engineering
Do you want to learn something new but you feel intimidated or unsure about
where to start? Think about how you can connect with people in that industry,
and ask for advice and insights about what the role entails.
Don’t let the fear of the unknown hold you back from pursuing your curios-
ity and passions. Consider seeking out online resources like YouTube tutorials
to gain a foundational understanding of the concepts and jargon related to
your chosen topic. Remember, it’s okay not to know everything before starting
a new role or pursuing a new interest. Focus on learning as much as you can
on the job and seek help and guidance from those around you.
192
o n ab
ti
le
ac DAY
193
ss
aw
e
s
e
omen As a software tester, it’s important to be open and willing to learn

new programming languages. While different languages may have
different syntaxes, they are all similar in their logic. Therefore, if you
understand the logical flow of programming languages, you can get
familiar with any language. Additionally, a liberal use of Stack Overflow
can be helpful for any coding exercise.
In terms of testing games, it can be challenging to automate game-
play as it is difficult for a computer to judge the quality of gameplay. It
is also important to remember that gameplay development can be
independent of server-side development, so testing must be done
accordingly.
When testing backend services, Postman can be a useful tool for
both manual and automated testing. It allows you to explore APIs,
send post requests to your web server, set up headers and cookies,
and check the response. It is also helpful for learning what an API does,
which can be useful when load-testing a web server. So, as a software
tester, keep an open mind, be willing to learn new languages, and use
tools like Postman to your advantage.
m be r
A
EPISODE 121: testguild.com/121 Sr SDET

Ra
ce
Think about a time when you were hesitant to learn a new programming
language or tool. What were your reasons for avoiding it? How did it impact
your work as a software tester? Consider the quotation: “. . . If you understand
the logical flow of programming languages, you can get familiar with any
language.” How can this mindset benefit you in your career as a software
tester?
Take some time to reflect on your approach to learning new skills and tools
in your profession. Challenge yourself to be more open and willing to learn,
and consider how it could enhance your work and skill set.
193
o n ab
ti
le
ac
DAY
194
ss
aw
e
s
e
omen It’s a difficult thing to say, but find the confidence in yourself to push
improvements forward because it’s so challenging when you’re work-
ing on so many different things. But it’s really just a matter of finding
that confidence and highlighting what is lacking in the organization. I
think it’s potentially easier to do at startups or small to medium test
organizations, but it’s helped me a lot. It’s helped me build out a test
process and an SRE process so far.
You can utilize that confidence to build the process itself, and if you
can speak the business language, you can take it further. That’s my
advice, and from there, learn to love yourself. When you’re putting in
a lot of time, find the time for yourself, because you can’t do stuff all
the time.
Evan
EPISODE 78: testguild.com/p78 Site

Reliability
o
Ni
l
d
e
Engineer o ja d
Reflect on how confident you feel about pushing for improvements in your
organization. What areas do you see that could be improved? Take some time
to identify these areas and brainstorm some ideas on how to improve them.
Once you have some ideas, take the first step toward implementing them.
Remember to speak the language of your business and focus on how your
improvements can provide value to the organization. Additionally, take some
time to learn to love yourself and find a healthy balance between work and
your personal life.
194
o n ab
ti
le
ac DAY
195
ss
aw
e
s
e
omen In my career, I have found that it is very important to make your

automation visible. Your work should be transparent to the entire
organization in your company, not just the QA department. This way,
people should think, oh, QA has built some kind of automation. By
being transparent and finding more customers in your company for
your solution, you can find more people who can use automation. At
Visa, I even trained my business owners to run the automation to do
the unity so that they can be more exposed to our tool and appreciate
what we are building. They can also give us feedback.
M al a
Director,
EPISODE 366: testguild.com/a366 Salesforce
Devops and P
i
un n
ya
Engineering
Think about how you can make your automation work more visible and
accessible to others in your organization. How can you communicate the
value of your work and ensure that it’s not just seen as the responsibility of
the QA team?
Consider ways to train and empower others to use automation tools, even
if they’re not part of the QA team. Think about how you can foster a culture of
collaboration and communication around automation so that it’s seen as a
shared responsibility and so that everyone can contribute to improving the
quality and efficiency of your organization’s work.
195
o n ab
ti
le
ac
DAY
196
ss
aw
e
s
e
omen Start with something very simple and grow from there. Once you
know that the simple thing is working reliably for you, slowly focus on
improving the reliability and work from there. I think it can be over-
whelming, especially in games, with so much to test. But if you start
small and build on top of that, that would be my advice.
Ru
EPISODE 365: testguild.com/a365 Senior Tester /

Managing C
in a
Partner dre
Think about a project or task you’ve been putting off because it seems over-
whelming. Instead of trying to tackle everything at once, start with a simple,
manageable component and focus on making that reliable. Once you’ve
established a foundation of reliability, gradually build upon it, expanding the
scope of what you’re testing or improving.
By starting small and building up, you can gain momentum and confidence
while ensuring that the core aspects of your project or task are functioning as
intended. What is one simple thing you can start with today to make progress
toward your larger goal?
196
o n ab
ti
le
ac DAY
197
ss
aw
e
s
e
omen The most critical metrics are the ones that consume 80% of your
load. It’s usually very easy to identify the ones that have the most hits,
the ones that occur most often. These are the metrics that you should
give special attention to.
There are others that are good to have, to know how your system is
doing, but they are not as critical. I don’t like to say this, but you could
skip some of those. . . . My personal preference is to have at least a
baseline for everything that your application can do. I would like to
have as many metrics as possible.
I understand that there are environments where the load is so big
that metric gathering and logging can become a bottleneck. But I
like to give the example of the instrumentation that an airplane has,
such as altitude, latitude, speed, and fuel. There must be thousands of
metrics that an airplane gathers. If you try to put more people in your
airplane—let’s say users in your system—and for the sake of pushing
more people, you start to take out these metrics—these instruments
in your airplane: personally, I would not like to be on that airplane.
And something similar should be applied to your applications. It’s
crucial . . . to know how your applications are doing, even in production,
even if you have a very basic production. You should consider expand-
ing it rather than saving resources on something that might be a little
biased as a performance engineer.
nd r
ea
o
L
EPISODE 1: testguild.com/p01 DevRel at k6
z
M
e
lende
For today, consider the most critical metrics that impact the performance of the
system under test. Identify the ones that consume the most load and happen the
most often. These metrics should receive special attention during testing. While
other metrics may be good to have, neglecting critical metrics can have severe con-
sequences. Therefore, it’s important to establish a baseline for all metrics and gather
as many as possible to gain a deeper understanding of the system’s behavior.
Consider the analogy of an airplane’s instrumentation, which has thousands
of metrics. If you were to remove any of these metrics for the sake of pushing
more passengers onto the plane, it could compromise the safety of the flight.
Similarly, by neglecting critical metrics in your application, you could be
putting your users at risk. It’s crucial to know how your application is perform-
ing, even in production, and to consider expanding your metrics-gathering
process rather than saving resources.
As a software tester, ask yourself: Are we gathering enough metrics to get a
clear understanding of the system’s behavior? Are we neglecting critical metrics
to save resources? What are the consequences of not gathering all critical met-
rics? By reflecting on these questions, you can take action to ensure that your
testing process is thorough and that your application is performing at its best. 197
o n ab
ti
le
ac
DAY
198
ss
aw
e
s
e
omen When it comes to getting started with application performance

monitoring (APM), I would recommend looking into something that is
easy to install and implement without requiring a lot of money, espe-
cially if you’re just exploring the topic.
One option that I’m currently investigating is the Elastic Stack. You
might have heard of the ELK stack (Elasticsearch, Logstash, and Kibana),
which is an open source solution that includes an APM component
and a real user monitor. There are different licensing levels for support,
but you can quickly set it up even if you have Docker. Just download
three or four containers and do the wiring in about 15 minutes, and
you’ll have a working APM solution with visualization. This is probably
the easiest way to get started. You can start by exploring how to turn
data from your systems into a graph that you can examine and say,
wow, I didn’t know it was doing that! If you become more serious about
APM, you can then explore some of the other commercial products
available.
ot t
Sc
EPISODE 5: testguild.com/p05 Founder of

Scott Moore
M
o o re
Think about how you could improve your application’s performance moni-
toring with limited resources. Consider the benefits of open source solutions
like the Elastic Stack and how it can help you quickly and easily implement
an APM solution. What data can you extract from your systems to better
understand your application’s performance? How can you turn this data into
actionable insights that will help you identify potential issues and improve
overall performance?
Challenge yourself to explore new tools and techniques for APM, and take
the time to assess their effectiveness in enhancing your testing process.
Remember, investing in performance monitoring is an essential step toward
ensuring the reliability and scalability of your application.
198
o n ab
ti
le
ac DAY
199
ss
aw
e
s
e
omen I don’t think there’s such a thing as hacking. It’s just creative IT
administration. . . .You can’t attack something if you don’t understand
it, so you really have to understand things from the fundamental level
of what that technology does before you can attack it.
Some of the best and most creative methods I used to move
through a network, attack, and generate things were by recruiting
the help of experts on various pieces of technology. They were not
necessarily hackers, but I could work with them, ask how they would
do certain things, and then start to apply threat techniques to it. We
could work together. So the big piece of advice is to make sure you
understand the technology you’re working on.
Joe
EPISODE 16: testguild.com/s16 Principal

Security
Engineer AWS Vest
Consider this quotation and think about how you approach testing from a
hacker’s perspective. What can you learn about a system by understanding it
at a fundamental level? How can you work collaboratively with experts in
different areas of technology to improve your testing skills and develop more
creative and effective testing methods?
Challenge yourself to go beyond the typical boundaries of software testing
and explore new ways to uncover vulnerabilities and improve the security and
reliability of the systems you test. Remember, hacking isn’t about attacking
systems; rather, it’s about understanding them at a deep level to better pro-
tect them.
199
o n ab
ti
le
ac
DAY
200
ss
aw
e
s
e
omen I think the best thing I would tell someone to do is to stay curious.
So, if you encounter a problem, instead of saying, “Oh well, this is
something that’s outside of my current domain, I don’t really know that
much about Linux and I’m going to let someone else solve this prob-
lem,” really dig into the problem and go all the way to the root cause.
Dig really, really deeply until you know exactly what’s happening on
your computer.
That is the piece of advice that I would give to folks: stay curious
and be patient with consistent effort. You will get it done and you will
learn what you need to learn.
ura
La
Senior Site
Reliability
Engineer S
tone
The next time you encounter a problem in your work as a software tester,
instead of just fixing the surface-level issue, take some time to dig deeper and
understand the root cause. Ask questions, do research, and stay curious until
you fully comprehend the problem and its underlying causes. Then document
your findings and share them with your team to help prevent similar issues in
the future.
Remember, patience and consistent effort will lead to better understanding
and improved problem-solving skills.
200
o n ab
ti
le
ac DAY
201
ss
aw
e
s
e
omen Are you a beginner in performance testing? Don’t worry; just grab a
performance tool and start learning. But don’t forget to seek guidance
from someone [who is] experienced, to ensure that you’re building
performance tests in a way that will benefit you in the long run.
Once you’ve mastered a tool, it’s time to shift your focus to perfor-
mance as a risk. Identify where performance issues might occur and
take proactive steps to mitigate them. And don’t limit yourself to
testing alone. Sometimes there are simple solutions that can mas-
sively reduce performance risk without any testing at all. Take, for
example, a system I once tested, where we found bottlenecks in
report generation. By simply training the users to generate reports
on the client side, we eliminated the performance issue immediately.
So think broadly, be proactive, and never stop learning!
p he
te n
S
EPISODE 12: testguild.com/p12 Observability

and SRE
d
To
n
w
Advocate nshe
When it comes to performance testing and risk management, don’t just focus
on the tools and techniques; think creatively and proactively about ways to
mitigate performance issues. Look beyond testing and explore other possibil-
ities, such as training users or making small adjustments to the system, that
can help eliminate or reduce performance risks.
By taking a holistic approach to performance, you can identify issues as
well as take action to prevent them before they occur.
201
o n ab
ti
le
ac
DAY
202
ss
aw
e
s
e
omen The big piece of advice I have for you is to focus on self-service,
especially in performance engineering. If you’re providing feedback
to engineers about performance, try to make it as automated and
self-service as possible. For example, at Citrix, a team has developed
chatbots that allow engineers to ask about their build’s performance
and key indicators. All of this can be done from within Slack. It’s that
simple!
Automation and self-service are crucial in providing performance
feedback. Even if you’re not in performance engineering, you can still
ask your colleagues to provide performance feedback in a fully auto-
mated way. This approach gives you more autonomy, reduces your
dependency on others, and makes you more self-sufficient. And who
doesn’t want to be more self-sufficient?
So I urge you to ask your colleagues the same question: how can I
get performance feedback in a fully automated way? Trust me, it’s
worth it. It’s time to take control of your work and make yourself more
autonomous. Are you ready for it?
Andy
DevOps
Activist at
r
G
Dynatrace r
a bne
Think about a process or task in your organization that involves receiving feed-
back or information from others. Can you identify ways to make this process
more self-service and automated? Consider exploring tools or technologies
that could streamline this process and reduce the need for manual interven-
tion. Discuss your ideas with your team and colleagues to see if they have any
suggestions or feedback.
By finding ways to increase autonomy and reduce dependency on others,
you can help improve efficiency and productivity in your organization.
202
o n ab
ti
le
ac DAY
203
ss
aw
e
s
e
omen I’m not a big fan of the page object approach. Personally, I think it’s
an overengineered solution that often leads to unnecessary code
duplication. Many homegrown automation frameworks are guilty of
this. People get so obsessed with reuse that they start splitting func-
tionality into reusable files.
But here’s the thing: we’re talking about automation, not production
code that users interact with. While reuse can be beneficial, it also has
a downside. Suddenly, you have an extra file to navigate and switch
between, which can be cumbersome. I’ve seen this happen a lot with
the page object model pattern.
So, can you avoid it? I would strongly advise folks to do so if possible.
I understand that my stance on reuse may be controversial, but as
someone who comes from the world of programming, I believe that
sometimes less is more. In this case, keeping things simple and avoid-
ing unnecessary abstractions can make your automation code more
efficient and easier to maintain. Don’t let yourself get bogged down in
overengineering. Keep it simple and practical.
te r
Pe
EPISODE 273: testguild.com/a273 Co-founder of

Karate Labs T
h s
oma
Consider the effectiveness of your automation frameworks and the use of the
page object model pattern. Take a step back and analyze whether it’s
overengineered and causing code duplication. Think about the potential
downsides of reuse and how it could impact the efficiency and productivity of
your team.
Finally, experiment with other approaches and techniques to find what
works best for your situation, and be willing to challenge conventional wisdom
to optimize your automation processes.
203
o n ab
ti
le
ac
DAY
204
ss
aw
e
s
e
omen Focus on critical bugs and opportunities to learn in the security

field. As there are costs associated with certifications, one should con-
sider the financial costs, length of time, and one’s starting point before
pursuing a certification. It is advisable to not list certificates as in
progress, but to acquire them if they are mandatory, especially for
government organizations.
In addition to technical skills, soft skills are important in security,
including being able to communicate vulnerabilities and solutions
quickly and effectively to customers.
Small wins early on are valuable and can help create momentum.
Lastly, when considering bug bounty programs or other large
projects, it is best to not rush into them too quickly.
y
wa ne
D
EPISODE 22: testguild.com/s22 QE to

Product T
Security
s
ho
ma
Think about your current position as a software tester and identify one critical
security bug or opportunity to learn that you can focus on. Reflect on the
financial costs, length of time, and your starting point before pursuing any
certifications. Consider the importance of both technical and soft skills, and
practice communicating vulnerabilities and solutions effectively to customers.
Also, start with small wins to create momentum, and avoid rushing into bug
bounty programs or other large projects too quickly. Importantly, challenge
yourself to balance your desire for growth with practicality and patience.
204
o n ab
ti
le
ac DAY
205
ss
aw
e
s
e
omen Create a framework with a set of requirements to evaluate load

testing tools. As load testers, we should have our own requirements
and assess the tools based on those. We should not rely on the tools
that we have always used or are comfortable with, but rather, test the
tools themselves, including things like CPU and memory utilization,
ease of use, and user experience.
It is also recommended to have a direct comparison of scripts with
different tools and approach it as a toolbox where we can have differ-
ent tools for different situations. Lastly, it is important to consider open
source tools, as they tend to develop faster due to technical reasons
and community contributions.
o le va
ic
n
Developer
Advocate at k6
de
n
r
e
Hoev
Reflect on your approach to load testing tools: are you relying on the same
tools you’ve always used, or are you open to trying out new options? Chal-
lenge yourself to create a framework with a set of requirements for evaluating
load testing tools, including CPU and memory utilization, ease of use, and user
experience. Consider comparing scripts with different tools and thinking of
them as a toolbox for different situations.
And don’t forget to explore open source tools, which can offer faster devel-
opment and community contributions. By broadening your approach to load
testing tools, you may discover new solutions that can improve the quality and
reliability of your software testing.
205
o n ab
ti
le
ac
DAY
206
ss
aw
e
s
e
omen Realiz[e] that creating quality software involves change, and

change is hard. It’s very convenient to get distracted by all the fads and
obvious things you need to do to be successful. But you’ve got to
understand that change requires discipline. Just as you don’t want
stress in your personal life, the same applies to creating bug-free
software. This is even more important for large companies with legacy
systems and inherent complexities due to their size. You’ve got to
manage that change with discipline, and if bug-free software is a
worthy goal (which I think it is), you’ve got to stick with it.
There will be ups and downs, you may slip and fall, and there will be
failures as well as victories, but you must create and make a habit of it.
For some people, the pill of choice is yoga or meditation, but for those
of us in the testing world, it might be Selenium, Appium, Jenkins, or
whatever works for us. We must figure out how to make it work, and it’s
definitely a worthy goal. It’s a harder bottom line, but it’s worth doing.
il e s
ha
h
R ao
Create a habit of daily practice to help you stay focused on your goal of creat-
ing bug-free software. Set aside a few minutes each day to review the tools
you’re using for testing, and develop a plan for how to make them work
for you. Monitor your progress, celebrate your successes, and keep pushing
forward.
206
o n ab
ti
le
ac DAY
207
ss
aw
e
s
e
omen I encourage you to become more technical and to look beyond the
scope of testing. From my perspective, if you look 10 years ahead, you
will need to understand the technical background of your testing
application for every test.
My most significant recommendation is that many testers are afraid
to be technical. I suggest exploring different types of testing, and if you
want to start, begin small. Take a tool like Oxygen, Postman, or
Cypress, or anything that you know is easy to start with, and then
expand your knowledge. By becoming more technical, you can help
organizations test the most challenging aspects of their software,
which are usually hidden behind the scenes in integration testing.
achum
N

of CloudBeat
Di
mer
Imagine yourself as a software tester 10 years from now. What kind of techni-
cal knowledge and skills do you think will be necessary for you to excel in your
profession? Consider taking small steps to improve your technical acumen,
such as learning to use testing tools like Oxygen, Postman, or Cypress. How
can you use this knowledge to improve the quality of the software you test,
especially when it comes to integration testing?
Reflect on the potential impact of your technical expertise on your orga-
nization's success and your own career growth.
Based on this Create a plan to become more technical in your approach to
testing.
207
o n ab
ti
le
ac
DAY
208
ss
aw
e
s
e
omen My one piece of actionable advice would be to try and shift your
testing to the left by learning some of the skills that developers use
daily, such as building and deploying an application. This will not only
help you become a better tester, but also equip you with important
skills that can enhance your testing.
kolay
Ni
EPISODE 417: testguild.com/a417 Dev Advocate
Ad
in
at Sauce Labs v
k
olod
Create a testing plan that incorporates a developer’s skill set. Identify the
tasks that developers would normally do and how you can use those same
skills in your testing efforts. Then discuss your plan with developers to ensure
that your understanding of their skills is accurate. Finally, put your plan into
action and use the acquired skills to improve your testing capabilities.
208
o n ab
ti
le
ac DAY
209
ss
aw
e
s
e
omen My recommendation in terms of looking at large enterprises and

digital transformation is that, as leaders, directors, and managers, it’s
important to emphasize the value of this to your business, your leader-
ship, your CIO, and even your CEO. Because at the end of the day,
digital transformation without quality or business assurance is not a
true transformation. Customer experience is the ultimate goal, and
leaking things into production can negatively impact stability and
performance, so it’s crucial to prioritize quality.
Based on lessons learned, my advice is to encourage your leader-
ship to invest in it, put together a business case, and show ROI and
the value that you can get out of it. Working towards a plan to invest
in quality is vital for large organizations to fully benefit from digital
transformation.
Secondly, it’s essential to build a solid team focused on different
aspects, such as strategy, test automation, performance, AI/ML, et
cetera. To do this, you need to have a strategy team that is separate
from the delivery team. Cross-functional teams, QA engineers, and
end-to-end teams should work together, but it’s important to keep the
strategy team and the digital team separate and encourage them to
talk to each other to promote healthy competition. By doing this, you
can avoid challenges with delivery, prevent production outages, and
promote innovation and productivity.
lh an
Di
Director of
M
u
a
Quality
d
na
wa
Engineering
Create a business case and ROI plan to demonstrate the value of digital trans-
formation to your organization’s leadership. Break the digital transformation
team into focused subteams, such as strategy, test automation, performance,
and AI/ML, and ensure that there is a clear separation between the strategy
team and the delivery team. Foster communication between the two teams
and encourage a competitive environment to ensure successful delivery and
innovative outcomes.
209
o n ab
ti
le
ac
DAY
210
ss
aw
e
s
e
omen Keep your tester’s mindset when you’re building out your auto-
mated test cases. Ultimately, what you’re trying to do is not to automate
the application, but to automate the testing of the application and to
find bugs. So always keep a tester’s perspective when building out
your automated tests and automation framework. Doing so will give
the testers and the team the most flexibility in covering whatever
scenarios and conditions they need to test.
arcu
M
s
QUART Consulting T
s
Services ho
ma
Take a few minutes to brainstorm how you can incorporate a tester’s mindset
into your current automated test cases to ensure that all potential bugs are
identified. Write down at least three ways that you can adapt your test cases
to be more effective in finding bugs. Implement what you wrote down, track
the results and share with your team.
210
o n ab
ti
le
ac DAY
211
ss
aw
e
s
e
omen I would like to leave with a small piece of advice for everyone
embarking on the automation journey. It’s a journey you can’t reach the
end [of] or the ideal state [of] just by jumping into it. Sometimes it’s a
journey you need to go through. In my journey, I went through Appium,
learned its pros and cons, and found out that native testing was actu-
ally working better for me. At one point, you may pass UI testing and
start digging deeper into component-level or controller-level testing,
and you’ll be comfortable without having to worry about UI testing.
Everyone has their own journey, and I recommend going through it
to find the right balance that works for your team, whether it’s fully UI
testing or skipping UI testing and doing more controller-level testing.
It’s the journey that you and your team need to go through to arrive at
that point. So I recommend people do research and arrive at that point
more quickly. That’s the last piece of advice I would like to give to
everyone listening.
swant
a
h
EPISODE 411: testguild.com/a411 Staff
n
Quality
a
a
n
Coach ig u n d
Spend time researching and exploring the different approaches to automation

testing that are available to you and your team. Identify the best balance of
approaches that is most suitable for your team and goals, and then design a
plan to move forward with testing in a way that will bring you to the desired
end state.
211
o n ab
ti
le
ac
DAY
212
ss
aw
e
s
e
omen Be okay with small steps . . . [with] understanding that this isn’t a
flip-the-switch kind of journey, this is something that you will be
working on forevermore. As depressing as that sounds, that should
also be liberating because it means you don’t have to succeed in it on
day one. Start by giving yourself the groundwork to be successful. If
you don’t already have structured logs, get structured logs. If you
have structured logs, but you don’t have timing data or tracing data
associated with your logs, associate that data with your logs. If you
don’t already have a user interface that allows you to query that in
unique ways, you need to think about what tool you need for that. Build
from wherever you are because it is just going to be a journey and
there are a lot of actions that you can take.
I think your point about building observability was just so key that I
might reiterate it. Often, testers feel like this is very out of their realm
and it’s something they can’t really get involved with. But I think it’s
actually the opposite. As someone who’s not writing the code, you are
asking questions about it. And if you can’t ask them for yourself, that’s
a really good indicator of an opportunity to add more visibility into your
systems. As software engineers, we need to welcome questions from
people who are not software engineers: testers, product owners, and
all sorts of roles. We want to encourage those questions and be able
to answer them from our data and the other roles’ perspective. Keep
asking those questions and don’t settle for “probably”—look for ways
to actually find the data for it.
I think this is a team effort across all roles, and it's really important.
Abby
EPISODE 364: testguild.com/a364 Site

Reliability
r
B
Engineer a
ngse
Create a plan for how you can use structured logs, timing data, and tracing
data to build more observability into your system. Make sure to include how
you will involve other team members in the effort and how you will answer any
questions they may have.
212
o n ab
ti
le
ac DAY
213
ss
aw
e
s
e
omen The best advice I can give to people in the automation space is to
prioritize problems over tools. Spend time understanding your context
and try to identify the problem space and what you’re trying to solve.
Then think about the tool that’s right for you. The most successful
automation practitioners are not the ones who know all the tools, but
the ones who can define the problem and then select the right tool to
solve it.
Choosing the wrong tool doesn’t necessarily mean that things will
go wrong, but it will take a lot longer to achieve results. When we’re
expected to deliver quickly, we can’t afford to waste time.
M ark
Author of
Win
m
Testing
a
t h
Web APIs er
in g
Create a list of potential problems you need to solve, and brainstorm tools and
techniques that could help you solve them. Evaluate the pros and cons of
each tool and technique to determine the best option for your situation.
Finally, develop a plan to implement the chosen tool or technique and
measure its effectiveness.
213
o n ab
ti
le
ac
DAY
214
ss
aw
e
s
e
omen I prefer to talk about integration testing more in terms of testing

individual system components. I think you should narrow down
integration testing where you only test a single service, and you only
start infrastructures that are required for the single service to test it.
So, if unit testing tests your code and pieces of your code, such as
functions, then integration testing takes it to the next step, where you
test individual deliverables such as services.
Imagine you need to test Netflix and need to test your movie cata-
log service. To test your movie catalog, you don’t need to start the
notification service, billing service, and many other services. You don’t
need to deploy the whole infrastructure to test a single one. You only
need to start your movie catalog service, maybe some network stub
for authentication, so that you can just verify if the authentication
service is according to this contract: returns, the correct token is given
the request, and the movie catalog service precedes correctly. That’s
only one.
You only need to verify that your movie service talks accurately to
the authentication service, but you don’t need to test it. And then
you start databases acquired for this particular service, [this] movies
service. So let’s imagine they’re using Elasticsearch for the movie
catalog. Then you only need to begin Elasticsearch and some network
stubs for [the] authentication service, and you’re good to go. You don’t
need the whole infrastructure to test it, making it much easier to run
and test this functionality in development locally.
That’s why I recommend that everyone look into something like
Test Containers to make testing quicker and more efficient.
rge
Se i

of AtomicJar E
go v
ro
Look at your application and test suite. Identify gaps that would be good
candidates for single-service testing. Create an automated integration test
suite that uses Test Containers to verify the functionality of an individual
service in your application, without having to deploy the entire infrastructure.
214
o n ab
ti
le
ac DAY
215
ss
aw
e
s
e
omen So your tests are suitable for functional testing, but what do you do
if you also have to do visual testing to ensure that the alignment is
correct? Like verifying the font, color, and everything is correct on the
web page or a mobile app? To do that, there are many commercial
solutions. But what about an open source option? I recommend folks
to check out the Visual Regression Tracker (VTR) project on GitHub.
My team is using VTR to meet our visual regression goals. It is easy
to use; you only need a simple docker-compose file, which you can
download and run as a Docker container. In the container, you will have
a UI dashboard, services layer, and Postgres databases.
Once it’s set up with your API key, you can do all kinds of things, like
writing the code needed to send the images to VTR. Once the images
are in VTR, you can approve or reject the changes. It will take those
images as the baseline if it’s the first time, and then you have to
approve or reject it from the next run onwards. It’ll show you the
changes that have happened since the last baseline. You can also
apply the ignore areas if there are any dynamic parts. You can ignore
regions or specify just this area you want to compare. You can also
use VTR to compare branch-wise if your project has multiple
branches. If you’re happy with one branch, you can merge the
baselines onto another.
rat
Su
EPISODE 373: testguild.com/a373 Automation

Architect
Da s
Consider how you approach testing and quality assurance in your work or
personal projects. Are you solely relying on functional testing, or do you also
consider visual testing to ensure that alignment, font, color, and other aspects
are correct? If you haven’t been incorporating visual testing, take some time to
experiment with tools like the Visual Regression Tracker project on GitHub.
This open source solution can help you meet your visual regression goals by
providing an easy-to-use dashboard, services layer, and Postgres database
that you can run as a Docker container.
Try using VTR to send images and approve or reject changes, and see how
it can help you improve your testing and quality assurance processes. By
incorporating visual testing, you can ensure that your project is not only
functional, but also visually appealing and aligned with your brand standards.
215
o n ab
ti
le
ac
DAY
216
ss
aw
e
s
e
omen White box and black box are both testing methodologies. They
differ in the information that is shared or not shared. In a black box
approach, an organization may hire an outside firm to conduct security
testing without sharing any information. This is done to emulate an
attacker and see if the system can be breached. On the other hand, in
a white box methodology, the organization collaborates closely with
the testers, sharing information such as design documents, access to
engineers, and access to source code.
People often think that black box testing is necessary because the
attacker does not have information about how the system works, but
this reasoning is flawed. In a black box model, the security tester is
actually being tested more than the system, making it less effective.
A castle metaphor can be used to explain these concepts. For
example, imagine a medieval king who wants to understand if he can
be assassinated. In a black box model, the king would send knights to
test the castle’s defenses without sharing any information about them.
This would be like the knights trying to count the alligators in the moat.
The king already knows how many alligators are there, so the test
would be a waste of time and money.
In contrast, in a white box model, the king would share information
about the castle’s defenses, such as the number of alligators in the
moat, how the drawbridge works, and the interior compartments. This
would allow the knights to identify weaknesses in the castle’s
defenses and test them.
Therefore, white box testing is more effective in identifying and
improving the security of the system.
Te d
EPISODE 370: testguild.com/a370 Author of

Ha
Hackable
o
r
rin gt
For security testing in your work or personal projects, do you use a black box
or a white box testing methodology, or a combination of both? Take some time
to research the differences between the two approaches and understand the
benefits and limitations of each.
Consider the importance of collaboration and information sharing when it
comes to identifying security issues and improving the security of your
system. Reflect on the castle metaphor used to explain these concepts and
think about how it applies to your work. How can you improve your security
testing practices by incorporating more collaboration and information sharing
with your security partner? Are there any security vulnerabilities that you may
have missed by relying solely on a black box approach? By incorporating a
white box approach and sharing more information, you may be able to identify
and address these vulnerabilities more effectively.
216
o n ab
ti
le
ac DAY
217
ss
aw
e
s
e
omen The first thing is that if you want to build security into your SDLC or
your organization, you must have top management support. It is hard
to achieve it from the bottom up. It has to be an organizational change.
If you want to build secure applications, you have to make security part
of your core values. Without that, you will fail. And of course, security
is a process.
You cannot achieve 100% security by only using some automated
tools in your CI/CD pipeline. You can use code scanners, third-party
scans of libraries, dynamic scans, [and] penetration testing done by an
external company, and still make mistakes. You have to engage in
several different activities. I believe the most crucial part is to think
about security when you’re trying to implement something, whether
you’re drawing diagrams on the whiteboard or working on a specific
feature. Such activities as threat modeling are essential to start with.
You can do small threat models and complex ones, but you can start
thinking about what can go wrong in the application in the future of
your planning . . . because you can quickly add tools and code scanners.
But still, you need someone who will take the output from those
scans and those tools to try to analyze it. Does it make sense what I
have to change? Is it a false positive, for example, or is it really an
issue? I believe the first step to making the application or the organi-
zation secure is to make it your top priority.
ateus
M
z
EPISODE 362: testguild.com/a362 Senior IT
Security
a
O
l
Specialist ej
ar
k
What steps can you take to promote a culture of security within your organiza-
tion? How can you work with top management to integrate security into the
core values of the organization?
Consider implementing threat modeling to identify potential security risks
during the planning stage of development. How can you ensure that the
outcomes from automated security tools are analyzed and acted upon
effectively? How can you build a process for ongoing security review and
improvement, and ensure that security is always a top priority?
Reflect on your organization’s current approach to security and consider
how you can work to make it more robust and comprehensive.
217
o n ab
ti
le
ac
DAY
218
ss
aw
e
s
e
omen From my experience, smaller businesses, organizations—and startups

especially—don’t pay much attention to the analysis process. I believe
one of the reasons behind that is that as small organizations or startups,
they don’t really do much automation. They’re more focused on deliv-
ery, forgetting about automation and quality, which is unfortunate. But
once you have a running business, a complex software solution
making you money, you become more concerned about automation.
You definitely want to have more transparency and visibility of what’s
going on.
In our experience, we believe that it is imperative for organizations
to focus on automation, especially when they reach a particular scale.
This is particularly relevant to enterprise-scale organizations with
thousands of tests running. Even if you don’t have a considerable
percentage of failures—say, 5% of the tests failing every day—it can
be terrible to review. If you think about that 5% out of, say, 10,000 tests,
the reviewing part can be a nightmare. Not only is the reviewing part
problematic, but you also want to understand what is happening. You
want to know which tests are unstable and which tests are flaky.
Basically, you need to identify issues and address them. Maybe you
should even refactor some of your tests.
So ideally, you want your regression reports to always be green.
Yes, in our experience, that mostly comes at a certain level of organi-
zational maturity.
it
Nik a

of Zebrunner
Si
h
d
c
or i
ev
How can your organization prioritize automation and quality, even if you’re a
small business or startup? What steps can you take to ensure that as your
business grows and becomes more complex, you have the transparency and
visibility needed to identify issues quickly and efficiently? And how can you
ensure that your regression reports are always green, even as your organiza-
tion scales?
Consider the trade-offs between short-term delivery and long-term sus-
tainability, and reflect on how you can strike the right balance to ensure the
success and longevity of your organization.
218
o n ab
ti
le
ac DAY
219
ss
aw
e
s
e
omen I cannot tell you whether to use this tool or other tools, but I believe
that if you have the opportunity to use AI tools or tools that incorporate
AI and make our lives easier, you should consider using them. I’m all
for making our lives easier, and I think the main goal should not be to
create more code but to make tests more reliable and approachable.
Therefore, you should definitely use tools that will help you achieve
that. So never reject using tools unless you have a valid reason not to
[use them].
n
Dia a
EPISODE 350: testguild.com/a350 Research

Assistant
Oks
Think about the tools and technologies you use in your work. Are there any
AI-powered tools that can help you automate or improve your testing
process? Do some research and explore what options are available. Consider
the benefits and drawbacks of using these tools and how they can impact the
quality and reliability of your tests. Challenge yourself to be open to new
technologies and tools that can improve your work, and be willing to adapt
and learn how to use them effectively.
Remember, the goal is not to create more code but to make testing more
reliable and approachable, so always prioritize tools that can help you achieve
that goal.
219
o n ab
ti
le
ac
DAY
220
ss
aw
e
s
e
omen Eighty percent of companies still prefer to use custom solutions to

update their stack from scratch. So, if you see that test automation is
still an isolated solution, it’s broken and isolated from the mainstream
developer ecosystem. It takes a lot of time and effort to put all these
things together.
For example, every company in a heterogeneous environment like
web, mobile, API, and database, et cetera—if you have to build a
framework for all these tools and you like to bring in about a hundred
different tools and libraries together, you have to stitch everything
together and use a test solution architect. It takes a lot of time and
effort. And eventually it becomes a development project or a parallel
development project where they have a dedicated team just for their
framework. After all that, many still do not see any ROI on their efforts.
Creating your homegrown solution is a considerable effort. Accord-
ing to [a] recent World Quality Report, 63% of companies say they
don’t see the ROI and don’t know how to measure the ROI from their
custom-built frameworks. That’s why I call it a broken test stack.
So you have a choice to seek out existing tools or frameworks or
be ready to invest a significant amount of time and effort in creating
your own.
k m an
u
g
R
ad
Founder of
a
Ka
Testsigma
n
d ya l a
Are you building your test automation framework from scratch or using exist-
ing tools and frameworks? Consider the pros and cons of both approaches,
and ask yourself the following questions:
• How much time and effort does it take to build and maintain
your homegrown solution?
• Have you seen a significant return on investment from your
custom-built framework?
• What are the potential risks and drawbacks of using existing
tools and frameworks?
• How well integrated is your test automation stack with your
mainstream development ecosystem?
Reflect on your answers and see if there are areas where you can improve
your approach to test automation. Consider exploring existing tools and
frameworks to save time and effort, while also evaluating how well these
tools integrate with your current development ecosystem. Remember that
the goal of test automation is not to create more code, but to make tests
more reliable and approachable.
220
o n ab
ti
le
ac DAY
221
ss
aw
e
s
e
omen This is more of a mindset change: that, in the end, we have to think
about simulation. There are so many devices, browsers, and other
technologies emerging. Ideally, can you run every test on different
types of browsers and devices? That’s the real challenge. It’s not
possible to do that.
And first, we must ask the question: is it needed? If you look at other
industries, like automotive, mobile, and semiconductors, they have
adopted simulation to a very mature level. In the electronics industry,
Fablabs are very expensive. You don’t take a design and test it from
the beginning at a Fablab. You go through simulation to a certain
extent and make sure it’s working, and then go to the Fablab for the
final pieces.
Similarly, we can test a significant amount of our device testing in
simulation, and then certain things which cannot be [tested there] can
be tested on a real device. We have an opportunity to create a cost
pyramid that shows which things should be tested where, and then we
can optimize the testing process.
I also think there is a need to give people access to certain things
like admin access, and level of access should be available on demand,
which will help them. Sometimes, because of access levels, you can-
not do certain things and you are stuck. By adopting these solutions,
we can make testing more efficient and effective.
rasa
a
r
of Digy4
Sa
ha
In what ways can your industry or organization adopt simulation to optimize

your testing efforts? Take some time to consider which types of tests can
be run in simulation and which should be run on real devices. Additionally,
consider what types of access levels are necessary for your team to efficiently
adopt these solutions. Can you provide on-demand access to certain tools or
environments to streamline your testing process?
Challenge yourself to think outside the box and consider new ways to
optimize your testing efforts through simulation and improved access levels.
221
o n ab
ti
le
ac
DAY
222
ss
aw
e
s
e
omen As a test automation engineer on my previous projects, I used to

write Selenium tests and had to figure out issues when tests failed.
The problem very often turned out to be that developers made
updates and didn’t notify the QA team. So, many of the test failures
were not real issues but simply because some UI elements were
changed, such as changing their ID. To fix this, I helped create the
Healenium project to help fix tests in real time.
Healenium works [by] using an algorithm from dynamic program-
ming, which is a method of optimization often used in AI. From the first
test run, it takes the DOM object of a page and saves it for every loca-
tor to the element used in the test; . . . not just the XPath or CSS locator,
but in a better sequence of parent-child nodes and their relationship
with these attributes. So, for example, if you are trying to interact with
a red button, and in the next test run the ID of this button changes,
Healenium will see that it received a “no such element” exception,
indicating that this element is not present. It will then look at the
previous state and the current state of this element, compare them,
and propose a new locator to execute a search with this new locator at
runtime. If the search is successful, it will mark the test and step as
green and proceed with other test steps. By using the open source
library Healenium, you can avoid test failures due to UI changes.
A nn a
Customer
va
Success Ch
Engineer r
e
e
n ysh
How can you ensure that your test automation is robust and reliable in the face
of UI changes and updates?
Consider the impact of developers making updates without notifying the
QA team, leading to failed tests that aren’t actually issues. Explore the benefits
of using dynamic programming and AI techniques, such as the open source
library Healenium, to optimize test automation and ensure that tests continue
to pass even when UI elements change. Think about how you can implement
such solutions in your own test automation projects, and collaborate with
developers to improve communication and reduce the risk of UI changes
causing test failures.
222
o n ab
ti
le
ac DAY
223
ss
aw
e
s
e
omen To make sure your code is ready for release, you need to focus on
collecting better data. Digital transformation DevOps processes can
help, but what you really need is quality intelligence. You must gather
metrics at every stage of the process, from unit testing to functional
testing, to make intelligent decisions about your code’s readiness.
It’s simple: you can’t afford production incidents. To improve, you need
the right data to empower your decisions at quality gates. You need to
be smart about making release decisions based on data, not a gut
feeling. That means adding the right tools to your pipelines to surface
insights at every stage of the process, making data-driven, fact-based
decisions.
It’s not just about automation either. CI/CD and automated testing
are great for speed, but they don’t necessarily make a difference in
quality. You need to augment automation with accurate data to make
the best decisions. By doing so, you can improve the quality bar and
prevent untested code from entering your codebase in the first place.
In short, quality intelligence is mission-critical to achieving quality
and speed. Collect the right data, use it to make informed decisions,
and feed those decisions into your pipelines. That way, you can release
code with confidence, knowing that you’ve made the best decisions
based on data, not guesswork.
r
Ch i s
EPISODE 309: testguild.com/a309 Vice President

at SeaLights R
ow ett
How can you improve the quality of your software development process?
Consider the role of data collection and analysis in making informed decisions
about when code is ready for release. Reflect on your current development
pipeline and identify areas where you can add automated testing and quality
intelligence tools to prevent production incidents and improve code quality.
To ensure that your automation efforts are focused on speed as well as
on driving quality improvement, think about the right metrics to gather and
the right places in the pipeline to surface insights so that you can make
data-driven decisions at every step of the development process.
223
o n ab
ti
le
ac
DAY
224
ss
aw
e
s
e
omen If you’re a tester, it’s important to stay current and up to date on your
skills. Make an effort to try out different tools and techniques to keep
your knowledge current. You can do this by experimenting with new
tools and techniques during your 9-to-5 job or by creating personal
projects in your free time.
Additionally, if you’re interested in learning about new test auto-
mation techniques or tools, check out Test Automation University, an
online website that offers free courses on UI, mobile, API, and holistic
automation. These courses are taught by brilliant minds in the indus-
try and are accessible to anyone, regardless of location or financial
constraints.
Angie

Relations
J
ones
When was the last time you tried something new in your profession? Have
you been actively seeking out ways to improve your skills as a tester? If not,
make a commitment to yourself to dedicate time to learning and experi-
menting with new tools and techniques. Whether it’s during your workday or
in your free time, challenge yourself to step out of your comfort zone and try
something different. And if you’re interested in expanding your knowledge of
test automation, consider checking out Test Automation University and
enrolling in one of their free courses.
Remember, staying current and up to date is essential to not only improving
as a tester but also advancing in your career.
224
o n ab
ti
le
ac DAY
225
ss
aw
e
s
e
omen If you’re trying to learn something new, the best advice I can give
you is to get your hands dirty and dive right in. Sure, you can check out
courses and read books online, but unless you actually try it out your-
self, you won’t fully understand it. So find a test app or pull up a tool
and start experimenting. You’ll quickly realize what you don’t know,
and then you can circle back to the resources with fresh eyes.
It’s all about creating a learning loop of reading, studying, listening
to podcasts, taking courses, and then practically applying what you’ve
learned. Don’t be afraid to make mistakes and learn from them. The
more you practice, the more you’ll understand, and the better you’ll
become. So roll up your sleeves and get to work!
Dave
EPISODE 356: testguild.com/a356 Senior Test
ld
W
Developer
s
e
t e rv
What is something you’ve been wanting to learn or improve upon? It could be

a new skill, a hobby, or a professional skill. Take a moment to reflect on why
you want to learn it and how it will benefit you. Then make a plan to practice
and apply what you’ve learned. This could be finding an app or tool to test, or
creating a project to work on.
Don’t be afraid to make mistakes and learn from them. Remember that the
learning process is a loop of reading, studying, and practicing, so make sure
to revisit your resources and continue to apply what you’ve learned. Embrace
the challenge and enjoy the journey of learning something new.
225
o n ab
ti
le
ac
DAY
226
ss
aw
e
s
e
omen If you’re starting fresh with JMeter or any other tool, my advice is to
take it easy. There are a lot of resources out there, so don’t worry; it’s
only a matter of time before you find the right resources and use what
you learn to put together your own solution. You can start with suitable
courses, and there are many good ones available, like Pluralsight or
LinkedIn Learning. If you’re willing to invest in yourself, I highly recom-
mend doing so.
Remember, the learning process can be slow and gradual. The
more important thing is that if you’re starting a brand-new project,
you’re going to piece things together slowly and gradually. Start by
learning from an online course, and then consult the documentation
provided by the tool vendor. Go step by step and build your testing
scripts slowly and gradually. Once you have something useful, you can
refine it further.
So take your time, stay patient, and build it piece by piece. Ultimately,
you’ll get there.
ee m
Na
EPISODE 97: testguild.com/p97 Udemy
Ak
k
Instructor
li
r
a a
m M
What steps are you taking to invest in yourself and your career development?
Consider exploring new tools and resources, like JMeter, to expand your skill
set and enhance your testing capabilities.
Remember, progress is a gradual process, so take your time and focus on
building your knowledge piece by piece. What new project can you start
today, and how can you use available resources and documentation to bring
it to life?
Challenge yourself to act and make progress toward your professional
goals.
226
o n ab
ti
le
ac DAY
227
ss
aw
e
s
e
omen When it comes to testing, especially with security testing, having a

methodology in place is crucial for many reasons. It’s important to
remember that context doesn’t transfer, which means that without
environmental context or full threat details, questions are introduced
that could lead to doubt and subject the entire test results to intense
scrutiny, potentially rendering them useless.
That’s why we need to ensure that our data set is resilient and
robust enough to withstand attacks and be judged solely on merit and
the discipline executed through the test series. A methodology, even
a lightweight one-page or two-page document, can help ensure that
our data set is above judgment and that we are conducting effective
and valuable tests.
M ik e
Security
Evangelist
r
S
a
e
p
n bau
Think about a situation where you must make an important decision, but you
don’t have all the information you need. Now imagine that you have the same
problem in your testing process. Without a proper testing methodology in
place, you may miss critical details and not have enough context to make
informed decisions.
Your action prompt is to create a testing methodology for a project that
you’re currently working on. Start by identifying the key aspects that you need
to test for, including security, functionality, and user experience. Then develop
a methodology that outlines the testing procedures and tools to be used, and
the expected outcomes.
Make sure the methodology includes the necessary environmental context,
threat details, and toolset information to ensure that the test results are
resilient and robust enough to stand against potential attackers. Remember
that a lightweight methodology is better than no methodology, but aim to
create a methodology that is comprehensive enough to ensure that the data
set is above judgment. Finally, make sure the methodology is followed consis-
tently, and review and update it as needed to ensure that it remains effective.
227
o n ab
ti
le
ac
DAY
228
ss
aw
e
s
e
omen As a quality engineer, it’s crucial to prioritize customer value,

technical risk, task complexity, and identifying your customer. While
it’s common to debate the optimal percentage of UI-automated
tests, there’s no universal answer. It depends on your specific cir-
cumstances.
For instance, a company may not require any UI-automated tests,
while another could potentially lose millions of dollars due to a
single spelling mistake on their homepage. Therefore, rather than
focusing solely on tool selection, it’s essential to identify your testing
requirements first and then find the most suitable tools to fulfill those
requirements.
h on
nt
A
y
EPISODE 419: testguild.com/a419 Principal
Software S
r
Engineer ta
f fie
Think about your current testing strategy or the strategy you plan to imple-
ment for your product or project. Ask yourself the following questions:
• What is the customer value of my product or project?

• What are the technical risks associated with it?
• How complex are the tasks involved in testing it?
• Who is my target customer, and what are their expectations?
Once you have a clear understanding of these factors, evaluate the avail-
able testing tools and select the ones that align with your needs. Remember,
selecting the right tools is important, but it’s not the only factor that deter-
mines the success of your testing strategy. You should also consider other
factors, like team collaboration, documentation, and reporting. Keep customer
value, technical risk, task complexity, and customer expectations at the
forefront of your testing strategy, and you’ll be on the right path to success.
228
o n ab
ti
le
ac DAY
229
ss
aw
e
s
e
omen
ashan
r
t
EPISODE 419: testguild.com/a419 Senior Principal
Software Engineer
P at i l
Consider the testing strategy for your current project or application. Are you
relying too much on UI testing, or are you leveraging API testing as much as
possible?
Take some time to evaluate the areas where UI testing is essential and
where API testing can be used effectively to reduce test runtime and improve
confidence in your test results. Look for opportunities to do more targeted
testing to make your test runs more efficient and effective. Finally, try to strike
a balance between UI testing and API testing that works for your project, and
make sure you have the right tools and frameworks in place to support your
testing strategy.
229
o n ab
ti
le
ac
DAY
230
ss
aw
e
s
e
omen Having a strategy for your automation is crucial. People often make
the mistake of thinking they must automate everything, without a clear
plan for what actually needs to be automated. The truth is, not every-
thing requires automation. So it’s important to take the time to develop
a well-thought-out strategy that outlines the objectives, priorities, and
criteria for automation. This will help you avoid the trap of automating
everything and ensure that your automation efforts are targeted and
effective.
eh a
Sn
Director
Vi
m
of Quality
a
s
w
Engineering a lin g
Have you or your team ever fallen into the trap of trying to automate every-
thing without a clear plan? If so, think about what could have been done
differently and identify the areas that could have been approached more
strategically. What are the core objectives of your automation efforts? Are they
focused on maximizing efficiency, reducing costs, or ensuring quality? By
taking a more thoughtful and strategic approach to automation, you can
ensure that you’re using your time and resources effectively and achieving the
desired outcomes for your project.
230
o n ab
ti
le
ac DAY
231
ss
aw
e
s
e
omen Team members should give more consideration to application

performance management (APM) tools. If you use an APM tool like
Datadog or New Relic to examine production traffic, you may discover
that many of your endpoints aren’t being accessed. Furthermore, 80%
of your traffic may be going to just two to five endpoints.
By analyzing your production traffic and tapping into the knowledge
of your developers, you can identify what to test and how to prioritize
it. Since time is limited, it’s critical to focus on tests that provide value.
Eric
Director
of Quality
Engineering D
rig g s
Take a closer look at your team’s application performance management tools

and start analyzing the data they provide. Identify which endpoints are getting
the most traffic and which aren’t being used at all. Work with your develop-
ment team to understand which endpoints are critical for your application.
Use this information to prioritize your testing efforts and make sure you’re
testing the endpoints that matter most. Also, make sure you have a strategy
in place for testing, based on what’s important for your application and your
customers.
Remember, your time is limited, and you need to make the most of it by
focusing on the tests that add the most value.
231
o n ab
ti
le
ac
DAY
232
ss
aw
e
s
e
omen In today’s world, the use of artificial intelligence (AI) in various tools
is becoming increasingly popular. But . . . you should be asking: is AI a
good fit for my organization and projects? It’s important to understand
that there’s a big difference between organizations that operate on a
project basis and those that do everything in-house.
Let’s consider the scenario of a consultancy that only works on
short-term projects for others. In this case, AI might not be the best
option as it requires continuous learning, which may not align with
their work model. However, for a large enterprise like Barclays, which
generates a massive amount of data over time, AI-assisted technology
is likely to be a good fit. The advantages of AI make sense in such a
case, where there is an extensive data set to work with.
However, many people tend to lose focus on the fact that technolo-
gies such as low-code, no-code, AI, and machine learning (ML) require
a complete learning process within the environment before they can
add any value to the project.
Therefore, it’s crucial to ensure that AI is a suitable option for your
testing efforts based on your specific needs. Before jumping on the
AI bandwagon, ask yourself: does AI align with my organization’s
objectives and project requirements? Don’t just follow the latest
trends blindly. Instead, make an informed decision that aligns with
your organization’s unique needs.
rry
La
EPISODE 421: testguild.com/a421 Creator of

klassi-js
d
G
o
d da r
Think about your organization’s testing needs and determine whether AI and
machine learning are a good fit. Ask yourself what kind of data your organiza-
tion produces and if it’s sufficient to support an AI/ML system.
Does your organization operate on a project-by-project basis or does it foster
a continuous learning environment? Look beyond the hype and think critically
about the advantages and disadvantages of AI for your specific situation.
Only adopt AI if it’s a good fit and will add value to testing efforts.
232
o n ab
ti
le
ac DAY
233
ss
aw
e
s
e
omen Don’t be an AI skeptic. When you think about what test automation
does, it provides efficiency. In test automation, you should create
abstractions to have more centralized code. This provides an easier
way to use a function and all the different things abstraction does.
AI is a form of abstraction. Are you writing all the AI? No, but you’re
allowing more intelligent and appropriate individuals who understand
the meat and potatoes, the guts of AI, to do that authoring and to pre-
pare it for you. This allows you to leverage it and extend it to do some
training to the AI or to provide details to the AI engine to help it work
better for [you]. So we’re getting an immense amount of benefit there.
r
Ch i s
Enterprise QA
Automation
T
Architect
r
ri
m pe
Reflect on your perspective on AI in testing. Are you open to the idea of using
AI in test automation, or are you skeptical? Consider the benefits and limita-
tions of AI in testing and how it aligns with your testing goals and needs.
Research different AI tools and frameworks that could potentially be inte-
grated into your testing process, and evaluate their effectiveness in meeting
your requirements. Finally, consider the potential impact of AI in testing on
your organization and how it may affect your team’s workflow, roles, and
responsibilities.
233
o n ab
ti
le
ac
DAY
234
ss
aw
e
s
e
omen When it comes to automation dashboards, most of them are mean-

ingless. It’s not helpful to have a green dashboard, because to most
management, that just means everything is okay. And a red dashboard
simply means that something is wrong. I recently worked with a customer
who had 120 test cases, and 21 of them failed. The dashboard showed
a little red pie in the top-right corner, which made them nervous and
gave testing some attention. But nobody really investigated the
details to understand the root cause of the issue.
That’s why I think that more than just a dashboard is needed.
Whether the dashboard is green or red, it doesn’t provide meaningful
insights because it just shows whether the test cases passed or failed.
The moment the dashboard turns red, people start to panic and get
interested in testing. But often, the issue is minor and just needs some
fixing. That’s why we don’t get a lot of insights from a dashboard alone.
bias
To
Managing
Director of
M
TestResults.io üller
Reflect on the quality metrics and dashboards used in your organization’s

testing process. Do they provide meaningful insights into the quality of the
product? How often are they reviewed and acted upon? Are they aligned with
the goals and priorities of the business?
Consider the limitations of relying solely on pass/fail metrics and how to
supplement them with more nuanced data that can provide better insights
into the state of the product. Think about ways to communicate testing results
more effectively to stakeholders so that they have a better understanding of
the value that testing provides to the project.
234
o n ab
ti
le
ac DAY
235
ss
aw
e
s
e
omen My advice is to always measure early and measure often. Only the
real world knows what really works!
David
EPISODE 68: testguild.com/p68 Author of

Experimentation
S
for Engineers w eet
Look at your current project or task and identify some key metrics that you
think are important for measuring its success. These could be things like user
engagement, conversion rates, or performance metrics. Then start measuring
these metrics as early as possible in the development process, even if the
project is still in the planning phase. Continuously monitor and track these
metrics throughout the development cycle, adjusting and optimizing as
needed. Finally, compare the results with the initial metrics to see if the
project met its goals and if the metrics were accurate predictors of success.
Use these insights to improve future projects and refine your understanding of
which metrics are most useful for measuring success in your field.
235
o n ab
ti
le
ac
DAY
236
ss
aw
e
s
e
omen Resilience testing is more important than chaos testing, in my opin-

ion as a tester and performance tester. Chaos testing can imply a
reckless approach of breaking things with a sledgehammer, while
resilience testing is a more practical way of testing. Traditionally,
performance testers exercised applications by sending traffic to see
how they respond to specific load profiles, such as stress tests and
soak tests.
With resilience testing, you can intentionally introduce faults or
failure modes to see how the application responds to stress. It’s
not just about requests and response times or the metrics you col-
lect from 100 concurrent users. It’s about understanding how the
application responds to intentional changes in its conditions. For
example, you may have a test where a thousand concurrent users
are running smoothly in your staging environment, but when you inject
500 milliseconds of latency, how does the application respond? Do
errors occur, or do things start queuing up in the database?
By creating such conditions, we can better understand how stress
and load affect our application[s].
ichael
M
EPISODE 75: testguild.com/p75 Solution

Architect
Sa
ge
Think about a recent testing experience you had where you primarily focused
on measuring requests and response timings. How would your approach
change if you instead focused on testing resilience?
Consider the kinds of faults or failure modes you would introduce and how
they could help you better understand your application’s ability to handle
stress and load. How would the data you collect differ from traditional perfor-
mance testing metrics, and how could this new approach benefit your team
and organization?
Take some time to plan and implement a test that focuses on resilience,
and evaluate the insights gained from this new approach.
236
o n ab
ti
le
ac DAY
237
ss
aw
e
s
e
omen When it comes to testing, one crucial aspect that often gets over-
looked is the importance of a solid data strategy. In my experience,
many customers encounter problems when it comes to managing
their data, and this issue is only becoming more prevalent.
However, instead of getting bogged down in the details, what’s need-
ed is a clear and effective test data strategy. It’s an area that I believe
every tester should invest time and thought into, as doing so can yield
significant benefits in terms of ensuring efficient and accurate testing.
r
Ch i s
Head of
Product – H
DevOps at HCL ag
ga
n
Take some time to reflect on your data strategy, and ask yourself the following
questions:
• What data do you use for testing? Is it realistic and representative

of real-world scenarios?
• How do you obtain and manage your test data?
• Are there any compliance or regulatory requirements you need
to consider when handling data?
• What tools or processes do you have in place to ensure data
quality and privacy?
• How do you test the data itself, such as data completeness,
accuracy, and consistency?
After reflecting on these questions, identify areas of improvement in

your data strategy and come up with actionable steps to address them.
Remember, having a solid data strategy can help you identify issues early on,
reduce testing time, and ultimately improve the quality of your software.
237
o n ab
ti
le
ac
DAY
238
ss
aw
e
s
e
omen We’re going into what everyone perceives as an economic down-

turn, right? And that’s got a lot of people stressed out. But don’t give
up on your career, your dreams, or the hope of your team. If you get hit
hard by the downturn in your company, it’s okay. Don’t cash in your
chips. You can rebuild. Rebuilding is just a part of life, but you can do it
right. Never give up. You will face some of the hardest things in your
life. As a manager, I have actually gone home and shed more tears
than in any other role that I have ever done in my life.
There will be times when you want to avoid going to work or when
you don’t want to tell someone they’re doing a lousy job because
they’re a great person, but you don’t want to provide corrective action.
However, don’t give up. Please give them the necessary feedback
because they can only grow if you do. So never give up. Never, ever
give up.
illip
Ph
EPISODE 434: testguild.com/a434 Sr. Software

Quality
Ta t
Manager lbo
Reflect on a time when you faced a difficult challenge in your career or

personal life, and you felt like giving up. What did you do to overcome the
challenge, and how did you bounce back? What lessons did you learn from
that experience that can help you navigate future challenges?
Take some time to write down your thoughts and reflect on how you can
apply those lessons to stay resilient in the face of adversity. Share your re-
flections with a trusted friend, mentor, or colleague, and see if they have any
additional insights or suggestions to offer.
Remember, challenges and setbacks are a natural part of life, but with the
right mindset and support, you can overcome them and come out stronger on
the other side.
238
o n ab
ti
le
ac DAY
239
ss
aw
e
s
e
omen The most important advice is to ensure that you incorporate test
automation in the early stages of testing. So, as we discussed earlier,
adopting a shift-left mentality and bringing in automation as early as
possible can significantly help many teams and prevent them from
making the same mistakes through manual testing.
Lastly, I would say to any C-level executives or key stakeholders
reading this: ensure that you are supporting these key teams and
developers, so you can make the necessary advancements in testing
and alleviate these challenges for their team.
utumn
A
Enterprise
EPISODE a433: testguild.com/a433 Account
il
o
Director at
C
ib e rt
Keysight
Think about your organization’s testing process. Are you incorporating test
automation at the early stages of testing, or is it only being considered toward
the end of the development cycle? Reflect on the benefits of shifting left and
how it can help your team save time and avoid making the same mistakes.
If you’re a C-level executive or key stakeholder, how are you supporting
your team’s testing efforts? Are you providing them with the necessary
resources and tools to implement proper advancements in testing? If not,
consider how you can better support your team and help them overcome the
challenges they face in their testing process.
239
o n ab
ti
le
ac
DAY
240
ss
aw
e
s
e
omen Service virtualization is a tool that can be used when access to

dependencies and real systems is not available. It has become
increasingly important in recent years as organizations rapidly deploy
new software products to meet the demands of the modern world.
Code development is shifting towards cloud environments, and ser-
vice virtualization has evolved from being solely a developer activity
to a testability tool. The creation and deployment of simulations
should be separated, with the design done by developers who have a
pulse on what’s going on, and the deployment done by nontechnical
testers. The term API simulation may be better as it reflects the split
desire for early-stage feature testing and failover. By separating these
activities, service virtualization can be used as a lightweight, punchy
solution to get out of trouble at the moment and then be integrated
into a larger DevOps regression cycle.
Take a look at any number of the free simulation tools that are avail-
able. Simulation has many uses, and I would like to see more people
pick up one of these free tools and try it in some of their development
and testing activities. Just see if it fits and if it feels good. You will be
pleasantly surprised.
Chris
EPISODE 428: testguild.com/a428 Product

Manager at
o
C
o
Tricentis l o si m
Think about a recent project you worked on and identify any dependencies or
real systems that weren’t available for testing. How did this impact the quality
and reliability of your testing efforts?
Now consider implementing service virtualization as a tool to overcome
this challenge. Explore the free simulation tools available and see if they can
help you create and deploy simulations that accurately reflect the dependen-
cies and systems you need to test against. Reflect on the benefits of service
virtualization and how it can help you develop and test software products
more efficiently and effectively.
Finally, share your experience and findings with your team to promote the
use of service virtualization in your organization.
240
o n ab
ti
le
ac DAY
241
ss
aw
e
s
e
omen Every solution in test automation is tailored to fit the specific needs
of the organization. There is no one-size-fits-all solution. In our case,
which I believe is representative of many enterprise contexts, we
found this solution. Even without adopting Boozang, the approach
mentioned in this book could be interesting with other web automa-
tion tools.
In terms of test automation, the modularity of the automation code
is the key to success. If it is built with modularity in mind, it will be
easier to maintain, and that is where you can determine whether an
automation initiative is a success or failure.
anni
Gi
Author of
Boozang from
i
the Trenches u n
P
c cia
Take a step back and evaluate your organization’s current approach to test
automation. Is it tailored to your specific needs, or are you using a one-size-
fits-all solution? Consider implementing a modular approach to your automa-
tion strategy to increase maintainability and success. Reflect on what factors
have contributed to the success or failure of past automation initiatives and
apply those lessons to future efforts. Challenge yourself and your team to
continuously improve and optimize your automation strategy to fit the unique
needs of your organization.
241
o n ab
ti
le
ac
DAY
242
ss
aw
e
s
e
omen Try out different tools and see which one works best for your needs.
WebdriverIO is a web automation tool that differs from Selenium
WebDriver. It is based on web standards and supports cross-browser
automation, among other features. When choosing a tool, there are
many factors to consider, including whether mobile support is essential,
the speed of testing cycles, and the required level of cross-browser
compatibility. I always recommend trying the tool out for yourself and
making a decision based on your experience. Don’t just believe the
hype; test it for yourself and see if it meets your needs.
istia
hr
n
C
WebDriverIO
n
r
oman
Think about your current web automation tool or the tool you’re planning to
use. Are you fully satisfied with its performance and capabilities? Is it meeting
all your requirements? If not, take the time to research and try out different
tools, including WebdriverIO, to see which one works best for your needs.
Don’t be swayed by marketing hype or what others say is the “best” tool.
Take the time to test different options for yourself and make an informed
decision based on your experience. By doing so, you may discover a tool
that can significantly improve your testing process and help you achieve
better results.
242
o n ab
ti
le
ac DAY
243
ss
aw
e
s
e
omen To avoid wasting money on fixing performance issues, shift your

performance engineering efforts left and provide continuous feedback
to your development teams. This will help them improve and avoid
technical debt buildup.
Avoid a siloed mindset in your operations and DevOps efforts to
effectively implement this process.
sef
Jo

Performetriks
r
e
y
a
rhof
The quotation emphasizes the importance of shifting left and of continuous

feedback in performance engineering. To apply this in your organization, take
a critical look at your current performance engineering efforts and evaluate
whether you’re detecting performance issues too late in the development
cycle. Identify opportunities to incorporate performance testing earlier in the
development process to catch issues before they become deeply ingrained in
the code.
Consider establishing a process for providing continuous feedback to
development teams regarding performance, focusing on the areas that
require improvement. Create a culture of collaboration and communication
between operations and development teams to avoid silos and ensure that
performance engineering is integrated into the overall DevOps process.
As an action prompt, consider holding a meeting with your operations and
development teams to discuss the benefits of shifting left in performance
engineering and how you can incorporate this mindset into your current pro-
cesses. Brainstorm ways to create a more collaborative environment between
the two teams and establish specific actions to implement these ideas.
243
o n ab
ti
le
ac
DAY
244
ss
aw
e
s
e
omen Low-code and no-code platforms can be valuable tools for

automating business processes and streamlining workflows, but it’s
important to consider their limitations and understand their place in
the larger toolbox. While they can be productive for those with limited
coding knowledge, they can also cause difficulties when issues arise,
and troubleshooting might take longer than if you were coding
directly.
It's recommended to keep low-code and no-code platforms as one
of the tools in your toolbox, and to seek out affordable open source
options for small organizations.
rry
La

klassi-js
d
G
o
d da r
What role do low-code and no-code platforms play in your toolbox for
streamlining business processes and automating workflows? How do you
balance the productivity benefits with the limitations and potential difficulties
that may arise?
Are you fully utilizing the potential of low-code and no-code platforms, or
have you overlooked their value?
Take some time to reflect on these questions and consider the role these
platforms may play in your organization’s future success.
244
o n ab
ti
le
ac DAY
245
ss
aw
e
s
e
omen The first thing I would do if I were starting to do BDD is, after I write
my Given-When-Then, [I’d] ask myself, can I implement this behavior
using steam?
So, what I mean is that if I have a Given-When-Then that has button
clicks and mouse clicks, obviously I need a mouse, so I can’t use steam
technology. But if the behavior you’re describing is implementation
detail–free, you could make it work using steam. You can say magic
too, if you’re into Harry Potter; you could say, well, can I make this using
magic?
So, if you’re talking about things like button clicks and hovers, you’re
not going to be able to implement this feature using steam or magic.
But if you’re talking about behaviors and keep[ing] your BDD imple-
mentation-free, you create a nice little steampunk engine for that.
n ce
La

Consultant
Kin d
Imagine you’re starting a new project using behavior-driven development

(BDD) methodology. How would you approach the Given-When-Then state-
ments to ensure they’re free of implementation details and can be tested
using steam technology or even magic? What are some examples of behav-
iors that can be described without implementation details, and how would
you create a steampunk engine to test them?
Discuss the benefits and challenges of using steam technology and keep-
ing the implementation details separate from the behavior descriptions
in BDD.
245
o n ab
ti
le
ac
DAY
246
ss
aw
e
s
e
omen Prioritize and invest in application security. Companies must ensure

that their software is secure, as poorly written software is the number-
one cause of data breaches. Security teams should not just focus
on perimeter and network security, but also have someone who spe-
cializes in software. It is crucial to run vulnerability assessment scans
and actual vulnerability assessments, and to develop secure coding
guidelines and standards to ensure that the software is secure from
the beginning.
Additionally, companies must involve the security team earlier in
the development process to avoid any last-minute panic and sub-
optimal fixes. Companies should also encourage testers to participate
in threat modeling to ensure a comprehensive and thorough approach
to application security. Finally, companies must ensure that they have
the necessary resources and personnel to address any vulnerabilities
identified in the software.
nya
Ta
EPISODE 17: testguild.com/s17 Founder of

We Hack
Ja
Purple nca
Reflect on how you approach security in your work, whether you’re a devel-
oper, a tester, a manager, or in any other role related to software development.
Consider how you can prioritize and invest in application security, beyond just
perimeter and network security. Think about how you can involve the security
team earlier in the development process and encourage threat modeling to
ensure a comprehensive approach to application security. Identify any gaps in
your current approach and come up with a plan to address them.
Remember that poorly written software is the number-one cause of data
breaches, so taking action to improve application security is crucial for
protecting sensitive information and maintaining the trust of users and
customers.
246
o n ab
ti
le
ac DAY
247
ss
aw
e
s
e
omen Start where you are; write your own scripts on your own, practice, and
gain experience. If you are looking to get into automation and worried
about how to get a job without experience, start practicing automation
in your spare time. Keep practicing and get that experience.
Once you are good enough or better, start searching for jobs in
automation within your company. If there are no job opportunities
within your company, try to go for a salary increase or a promotion to
a relevant position at another company. Don’t be afraid to learn new
tools and expand your skill set. Fear of not being able to get hired or
not having experience should not hold you back. Keep practicing and
using your skills to avoid losing them.
Re x

Trainer, Author,
J
& Consultant ones
Think about a skill or profession you’ve been interested in learning or pursuing

but have been held back by the fear of not having enough experience or not
being able to find job opportunities. Consider taking action today to start
learning and practicing that skill in your spare time.
Write out a plan for how you can gain experience and improve your skills,
and commit to taking regular steps toward your goal. Don’t let fear hold you
back from pursuing your passions and developing your talents.
Remember, the best way to gain experience is to start where you are, write
your own scripts, practice, and keep learning.
247
o n ab
ti
le
ac
DAY
248
ss
aw
e
s
e
omen Load testing is a subset of performance testing and it’s crucial for
companies to understand how their systems perform under various
conditions, including response time, uptime, and reliability. The prac-
tice of performance testing has evolved over time, and the focus has
shifted from just testing the backend to testing the whole system,
including the frontend, to understand how it behaves under different
network conditions.
The performance of an application can have a direct impact on
revenue and user experience, so it’s important to test it to ensure it
meets requirements. The skills required for load testing vary depend-
ing on the architecture of the system, and it’s crucial to have a clear
understanding of what’s being measured.
The people working on performance testing today are more likely
to be frontend engineers, whereas service engineers may not have all
the necessary skills.
E ri c
EPISODE 101: testguild.com/p101 DevOps

Engineer
r
P
r
o e gle
Take a moment to reflect on how you approach performance testing in your

work. Are you aware of the importance of load testing and its role in ensuring
a system’s reliability and response time? Do you have a clear understanding
of the skill set required for load testing, and do you possess these skills? If
not, what steps can you take to acquire these skills and gain a better under-
standing of performance testing as a whole? How can you ensure that your
company’s systems are tested thoroughly to meet requirements and provide
a positive user experience?
Consider the impact that performance testing can have on revenue and
user experience, and think about how you can contribute to the evolution of
the practice to ensure the best outcomes for your company and its customers.
248
o n ab
ti
le
ac DAY
249
ss
aw
e
s
e
omen To effectively debug your infrastructure and improve observability

in a fast-paced CI/CD environment, consider adopting a more explo-
rative form factor like Jupyter Notebooks. Utilize notebooks to gather
and analyze different types of data, including logs, traces, deploys,
and builds, to reason about your infrastructure and services.
Additionally, consider how DevOps tools can benefit from the move
towards collaborative software, just as productivity, design, and web-
site building tools have.
h a He r
ic
n
M
an
de z
Va
Fiberplane
n
Le n
uffe
Consider implementing Jupyter Notebooks in your infrastructure and Dev-

Ops workflow to enhance observability and streamline debugging. Begin by
evaluating your current data sources and identifying areas where Jupyter
Notebooks could help you better understand and reason about your infra-
structure and services.
Experiment with the explorative and collaborative capabilities of Jupyter
Notebooks to facilitate more effective and efficient debugging in a fast-paced
CI/CD environment. Consider how this approach can be extended to other
DevOps tools and processes to further improve collaboration and productivity
across your teams.
249
o n ab
ti
le
ac
DAY
250
ss
aw
e
s
e
omen Stay curious. That’s what I always say. . . . When you go to the
requirement meeting and you listen, don’t just think, oh, I’m just a QA
person, so I don’t care about the requirement. Yes, you do. Be curious
and ask all the right questions because the best QA folks are the
product’s subject matter experts. And I’ve been one in the past. You
are like the go-to person. I’ve been in a team where the new person
joins in . . . and then I train the person based on my test cases because
I’m close to everything. Back to that cross-pollination: I’m talking to
everybody in the organization, all the different components.
So it’s the curiosity that drives you to get that level of detail on all
this. . . . And so stay curious. When you’re talking to the developer, stay
curious as well. Ask them about the code and why they’re making this
decision. Because when you’re testing, you need to understand why
those decisions will be made in the algorithm or how they imple-
mented it. Staying curious, for me, is like the golden rule. And that’s
why I love my job. Your curiosity makes you want to continue learning.
s et t e
Li
Director
of Quality Z
Engineering o
uno
n
Think about a recent project you worked on or a task you completed at work.
Did you ask all the right questions during the requirement meetings? Were you
curious enough to understand the product and the technology behind it?
Reflect on how you can apply the principle of curiosity to your work to
become more of a subject matter expert and to produce high-quality work. The
next time you’re in a meeting or talking to a developer, ask more questions
and try to understand the why behind their decisions. Make a commitment to
stay curious and continuously learn in your job.
250
o n ab
ti
le
ac DAY
251
ss
aw
e
s
e
omen Avoid overusing XPath locators in Appium. Although XPath is a

powerful way to find elements, it comes with a significant performance
cost, and there is usually a better way to locate elements. It may
involve having a conversation with your development team to ensure
the right accessibility ideas or other labels are in place.
By making your app testable, you can avoid making common mis-
takes and optimize your test code. It is also recommended to set up
your application in a way that you can quickly get to specific views
and specific user states. For instance, if you have 10 different tests
for the shopping cart functionality, eight or nine of them may go through
the same steps of logging in, finding an item to add to the cart, et cetera.
So you can set up a way to set up that state and immediately start a
test in that appropriate state.
natha
o
n
J
EPISODE 187: testguild.com/187 Project Lead
for Appium
Li
pps
Think about the last time you wrote automated tests for your mobile app. Take
a moment to reflect on the locators you used to locate elements in your app.
Did you rely heavily on XPath? If so, consider having a conversation with your
development team to ensure the right accessibility ideas or other labels are in
place. Additionally, take a step back and think about how you can make your
app more testable. Can you set up your application in a way that allows you to
quickly get to specific views and user states?
By optimizing your test code, you can avoid making common mistakes and
improve the overall performance of your automated tests. Remember, the
goal of automated testing is to save time and improve the quality of your
app, so take the time to invest in making your tests as efficient and effective
as possible.
251
o n ab
ti
le
ac
DAY
252
ss
aw
e
s
e
omen Use the right tool for the right job. Be open to learning new tools
and techniques, even if they seem intimidating. Automating tasks with
the right tools can save time and help solve challenges, like creating
loan data, validating data, or finding bugs.
Paul
EPISODE 420: testguild.com/a420 SDET
n
a
r
o
ssm
Sometimes it can be easy to stick with what we know and to use the tools and
techniques that we’re comfortable with. However, this can limit our ability to
solve challenges effectively and efficiently. To be a successful problem solver,
it’s important to be open to learning and using new tools and techniques.
Think about a challenge you’re facing in your work or personal life. Take
some time to research and explore different tools and techniques that could
help you overcome this challenge. Don’t limit yourself to what you already
know. Instead, be open to learning and experimenting with new solutions.
Consider the benefits and drawbacks of each option and try a few different
tools to see what works best for your specific challenge. Remember, the right
tool for the right job can save you time and help you find better solutions.
252
o n ab
ti
le
ac DAY
253
ss
aw
e
s
e
omen My advice would be to check out Python for creating automation

scripts. Try using Pytest as a core framework for test automation in
Python. Pytest is concise, focused on tests, and allows for scalable and
reusable setup and cleanup through the use of fixtures. Additionally,
when testing web UI, Selenium WebDriver is recommended, and for
REST API testing, the Requests library is a popular and indispensable
choice.
Furthermore, the Python community is highly supportive, making it
an excellent choice for beginners and experienced programmers alike.
I think that using Python for test automation, leveraging Pytest, and
selecting the appropriate packages for the specific testing needs is an
effective approach to successful software testing.
Andy
Principal
Advocate at K
nig ht
Applitools
Still not using Python?

Now that you know how effective Python and Pytest can be for test auto-
mation, it’s time to take action! Start by exploring the Pytest framework and its
features, and then consider how you can apply it to your own testing needs.
Don’t forget to check out the Selenium WebDriver for web UI testing and the
Requests Library for REST API testing.
And remember, with the supportive Python community behind you, you have
everything you need to succeed in software testing.
So why wait? Take the first step today!
253
o n ab
ti
le
ac
DAY
254
ss
aw
e
s
e
omen My actionable piece of advice is to align your automation tech stack

with your application tech stack to get buy-in from developers. By
using the same language, developers are more willing to help with
testing efforts, and this collaboration can change how you approach
the project.
You can also embed your team members into the development
team and involve them in the planning process, where the entire team
reviews user stories and acceptance criteria. This process can improve
the acceptance tests and help you allocate resources more effectively.
Finally, it is crucial to create interactive workshops or labs to onboard
new team members and show them how to write automated tests.
By doing so, you can help your team members feel like they own
the quality piece, which can help move the team forward.
Gre g
EPISODE 171: testguild.com/171 Vice

President, S
Quality Engineering y p o lt
Think about a current or future project and ask yourself how you can align your
automation tech stack with your application tech stack to get buy-in from your
developers.
Consider embedding team members into the development team and
involving them in the planning process to improve acceptance tests and allo-
cate resources more effectively. How can you create interactive workshops or
labs to onboard new team members and show them how to write automated
tests?
Reflect on how implementing these actions can help your team members
feel like they own the quality piece, which can move the team forward. What
steps can you take to ensure that your team is aligned and working collabora-
tively to achieve the project’s goals? Challenge yourself to act, and see the
positive impact it can have on your project and team.
254
o n ab
ti
le
ac DAY
255
ss
aw
e
s
e
omen My advice to take your test automation game to the next level is to
look no further than utilizing patterns. The key is to learn from existing
solutions and apply them in new and exciting scenarios. Don’t get
bogged down with specific tools. Focus on general problems and
create solutions that are adaptable to any situation.
But how do you find the perfect automation pattern for your unique
problem? Think like a doctor! Use diagnostics (to learn more, check
out testautomationpatterns.org) to ask general questions and use the an-
swers to guide more specific ones. This approach will help you identify
the most suitable automation pattern for your particular challenge.
And don’t forget to stay up to date with the latest patterns and auto-
mation tools. Automation is constantly evolving, so make sure you’re
always in the know.
et ta
er
t
Author of A
EPISODE 229: testguild.com/229 Journey through
Test Automation G
a m ba
Patterns
What automation challenges have you faced in the past, and how have you
overcome them? Take a moment to reflect on your experiences and think
about how utilizing patterns in test automation could have helped you over-
come those challenges more efficiently.
Challenge yourself to apply this advice to your next automation project and
see how far it can take your test automation game. Remember, the key is to
focus on general problems and adapt existing solutions to new and exciting
scenarios. So, what’s stopping you from taking your test automation to the
next level?
255
o n ab
ti
le
ac
DAY
256
ss
aw
e
s
e
omen API security is essential due to the vulnerabilities in mobile apps,

the poor implementations of security protocols, and the rush to
release products in the Internet of Things world, making it a perfect
storm for API vulnerabilities.
Test engineers should understand that all communication with
HTTP-based APIs can be observed, intercepted, and manipulated.
Additionally, they should be aware of common risk patterns and
poor implementations. Man-in-the-middle attacks are one of the most
common security attacks, and with the rise of internet-connected
devices, all HTTP/HTTPS communications are susceptible to being
intercepted.
Troy
EPISODE 21: testguild.com/21 Founder

of Have
Hunt
Take the time to review the security protocols and measures in place for
the API you’re testing. Consider performing a thorough risk assessment and
vulnerability scan, as well as implementing various security testing methods
to ensure that the API is protected from common attack patterns. Be vigilant
about checking for weak points in the system, and be willing to speak up
about potential security risks to the development team. Remember that a
secure API can be the difference between a successful and safe product, and
a product that is vulnerable to attack.
256
o n ab
ti
le
ac DAY
257
ss
aw
e
s
e
omen If you want to ensure that your UI appears correctly to users, use a
visual validation testing tool like Applitools to automatically detect all
the visual bugs and validate the visual correctness of your application.
Applitools is a quality assurance tool designed for visual testing,
which is different from functional testing tools like Selenium that help
validate application functionality in the UI. Applitools helps ensure
that each UI element appears in the right color, shape, position, and
size, and that it doesn’t hide or overlap any other element. With Appli-
tools, you can run thousands of visual tests every day, making it ideal
for large-scale testing.
Additionally, Applitools has a collaboration tool that allows stake-
holders like project managers and product managers to view the
application’s UI changes and provide immediate feedback to develop-
ers. Unlike traditional visual testing tools that use general-purpose
algorithms, Applitools uses innovative image processing technology
specifically designed to solve the problem of visual validation.
a
Ad m

of Applitools
C
a r mi
Think about a user interface that you frequently use and rely on, such as a
mobile app or a website. Consider the visual elements of this interface and
how they contribute to your overall user experience. Now imagine if those
elements were slightly off, with buttons that aren’t aligned, text that is hard
to read, or images that are cut off. How would this impact your experience
and perception of the interface?
Your action prompt is to take some time to visually inspect and test the UI
of an application that you use regularly, paying close attention to the details.
Use a visual validation testing tool like Applitools to identify any visual bugs
that may be impacting your experience. Consider how such tools can
improve the quality and reliability of user interfaces and ultimately improve
the user experience. Share your insights and findings with others in the soft-
ware development or user experience community to raise awareness of the
importance of visual validation testing in software development.
257
o n ab
ti
le
ac
DAY
258
ss
aw
e
s
e
omen It is essential to test the email workflow that flows into or out of
your product or platform. Email workflow testing should not be done
by sending messages to customers, as this can be detrimental to
customer service. Instead, email should be tested somewhere else
before live customer interactions. The same applies to SMS-based
interactions with your clients. You can use email testing tools like
Mailinator to test your workflows without the need to create new
inboxes. Always ensure you have a good email testing strategy in
place before turning on your live customer interaction systems to
avoid customer service issues.
Jack

of Mailinator
e
L
a
w c
ren
Ask yourself: how can I create a comprehensive and efficient email testing
strategy that ensures the quality and functionality of email workflows without
negatively impacting customer service?
To act on this thought, you could consider the following steps:
1. Research and identify the best email testing tools available

for your product or platform.
2. Create a testing plan that outlines the various scenarios and
use cases that should be tested in the email workflow.
3. Determine a schedule and frequency for testing to ensure that
your email workflows are continuously evaluated and optimized.
4. Develop a process for reporting and resolving any issues
that arise during testing.
5. Collaborate with other teams involved in the email workflow,
such as developers and customer support, to ensure that
everyone is aligned on the testing process and goals.
By taking these steps, you can help ensure that your email workflows
are functioning correctly and efficiently, which can ultimately improve the
customer experience and prevent any negative impacts on customer service.
258
o n ab
ti
le
ac DAY
259
ss
aw
e
s
e
omen I can’t overemphasize the importance of faster feedback, teamwork,

and collaboration in the software development process. To achieve
this, it is essential to address the least addressed area of iteration,
making it faster by building an on-demand ephemeral environment
solution. This solution should enable the parallelization of feature
development, with every developer having an isolated environment
for each branch, and integrate testers and stakeholders to provide
feedback earlier in the process.
The higher-level construct of an environment should be elevated
to provide an endpoint where developers can reach their applications
and test everything else below it that should be automated. Building
a culture of ownership, collaboration, and teamwork in software devel-
opment can enhance performance and create a sense of belonging.
Therefore, it is crucial to invest in solutions that help improve the
iteration process, enable faster feedback, and enhance teamwork and
collaboration in the software development process.
Jo s h

of Uffizzi
n
h
T
urma
Start a discussion with your development team about implementing an on-

demand ephemeral environment solution. This could include gathering more
information about the technical requirements and benefits of such a solution,
and working with the development team to evaluate different options for
implementing it.
Additionally, advocate for more collaboration and communication between
testers, developers, and stakeholders to provide feedback earlier in the
development process, and work toward building a culture of ownership and
teamwork within your organization.
259
o n ab
ti
le
ac
DAY
260
ss
aw
e
s
e
omen To get started with automation testing, firstly one should have a
strong understanding of the system and be knowledgeable about
every aspect of it. Then they should identify feasible and infeasible
scenarios for automation based on the technology stack of the appli-
cation and devise their framework accordingly.
Additionally, API testing can help reduce the load of UI testing,
but it cannot completely replace it. It is important to create your own
narrative and ensure that you can explain the technology to someone
new to it before feeling confident in your testing skills.
il
ric la
P
EPISODE 402: testguild.com/a402 Test Engineer /
n
Bil
Team Lead
a
a
ve r
nd
Think about a system you interact with regularly, whether it’s a website, appli-
cation, or device. Consider the different scenarios you encounter while using
it, and imagine how you could automate those scenarios using testing tools.
What knowledge and skills would you need to develop in order to effec-
tively design and execute automated tests for this system? How would you
approach identifying feasible and infeasible scenarios for automation based
on the tech stack of the application?
Reflect on the benefits and limitations of using API testing versus UI test-
ing and how you could use both approaches to create a comprehensive
testing strategy. Finally, challenge yourself to explain the technology behind
the system to someone who is unfamiliar with it in order to solidify your
understanding and improve your communication skills as a tester.
260
o n ab
ti
le
ac DAY
ss
aw
bonus
e
s
e
omen As each episode of my podcast comes to a close, I always remind

my listeners of a simple, yet powerful motto: “Test everything and keep
the good.”
This is inspired by 1 Thessalonians 5:21-22: “But test everything.
Keep what is good, 22 and stay away from everything that is evil.”
But this concept is not unique to the Christian Tradition.
In Hinduism, the scripture Bhagavad Gita (Chapter 2, Verse 49) says,
"Perform your duty equipoised, O Arjuna, abandoning all attachment
to success or failure. Such evenness of mind is called yoga." This
encourages the practitioner to focus on the present moment and per-
form their duties without getting attached to the outcome.
In Buddhism, the Kalama Sutta teaches that one should not believe
in something simply because it is traditional or has been passed down
through generations, but should instead test everything for them-
selves to see if it is true.
In Taoism, the philosopher Lao Tzu wrote in the Tao Te Ching (Chapter
63), "Practice non-action. Work without doing. Taste the tasteless.
Magnify the small, increase the few. Reward bitterness with care. See
simplicity in the complicated. Achieve greatness in little things." This
emphasizes the importance of simplicity and the power of small
actions.
JO e
co
io
Daily Actionable Awesomeness l
n
anto
As a software tester, you have a responsibility to thoroughly test everything

related to the software you are testing. This includes all functionality, user
interfaces, error handling, performance, and security aspects. Just like the
quote suggests, it is important to test everything and keep what is good while
avoiding everything that is evil.
In this context, "evil" could be anything that causes harm to the software or
its users, such as security vulnerabilities, poor performance, or usability issues.
Consider how you approach testing and how you can apply a critical and
discerning mindset to your work. How can you ensure that you are testing
everything thoroughly and only keeping what is good for the software?
Finally, the advice given in this book may not align with your personal
beliefs or experiences. However, instead of immediately dismissing it, it's
worth putting the advice to the test. By doing so, you may find that it works
well for your situation. Conversely, if it does not work for you, you can have
confidence that you tried and learned that it does not apply to your particular
context.
This approach ensures that you are giving the advice a fair chance and
gaining knowledge about what does and does not work for you.
261
About Joe Colantonio
Joe Colantonio has over 25 years of experience in software automation test-

ing and is the founder of Test Guild, a dedicated independent resource for
actionable and real-world technical advice from industry experts (blog, video
tutorials, podcasts, and online conferences) to help improve your DevOps
automation, performance, and security testing efforts.
As the host of the TestGuild Automation Podcast (Formally TestTalks) the
longest-running podcast on automation testing, Joe has interviewed over 400
industry leaders. He is also the creator of Automation Guild, the premium
annual online event for test automation engineers. Joe has also hosted over 600
hours of live online events for some of the biggest companies in the software
testing space, including Tricentis and Micro Focus.
Test Guild also provides services to software companies to help them
reach a community of more than 33,000 highly engaged, growth-oriented, and
ambitious software testing professionals.
Boost Your Awesomeness Karma!
YOUR INPUT MATTERS!
Thanks for embarking on this incredible journey with me by reading my book!

Your support means the world to me, and I genuinely value your feedback.
I am committed to continuous improvement, and your input is essential in
shaping the next version of this book and enhancing my future works. Please
take a moment and share your thoughts by leaving a helpful review on
Amazon. Your review will guide me in delivering even better content and assist
other readers in making informed decisions.
testguild.com/reviewbookpb
INDEX of speakers
All numbers refer to ‘days’ and pages
Aberle, BJ - 109 Colombi, Chiara - 160

Acharya, Dushyant - 192 Colosimo, Chris - 240
Advolodkin, Nikolay - 58, 208 Crispin, Lisa - 16, 94
Adzic, Gojko - 146 Cruz, Marie - 141
Akhmetzianov, Ruslan - 161 Cummings-John, Ronald - 157
Akram Malik, Naeem - 226 Cunha, Cristiano - 169
Arbon, Jason - 98 Das, Surat - 215
Arieli, Guy - 188 Deppisch, Christoph - 72
Bahmutov, Gleb - 61 Dijkstra, Bas - 48
Bally, Helen - 38 Dimer, Nachum - 207
Bangser, Abby - 212 Ding, Kwo - 73
Barbour, Matt - 54 Dodds, Kent C. - 71
Belcher, Dan - 82, 164 Döring, Patrick - 172
Bilavendran, Pricilla - 260 Driggs, Eric - 231
Black, Rex - 47 Egorov, Sergei - 214
Bradshaw, Richard - 15, 106 Engsig, Sune - 134
Brigginshaw, Duncan - 121 Evans, Jim - 31
Broker, Rick - 185 Fard, Payam - 182
Bromann, Christian - 116, 242 Farrier, James - 127
Bütow Bryant, Tammy - 105 Ferrera, Noemi - 184
Buwalda, Hans - 55 Ferris, Darrel - 136
Byars, Brandon - 132 Fink, Mark - 27
Cadwallade, David - 41 Frankel, Moar - 163
Camarillo, Annalisa - 18 Friesel, Rob - 64
Cantwell, Casey - 107 Full Goh, Eden - 166
Carmi, Adam - 257 Gamba, Seretta - 255
Chandler, Trevor - 149 Goddard, Larry - 88, 232, 244
Chernysheva, Anna - 222 Goel, Pankaj - 175
Chung, Ethan - 186 Gopalakrishnan, Aparna - 124
Ciliberto, Autumn - 239 Goucher, Adam - 130
Cindrea, Ru - 196 Grabner, Andreas - 202
Clinard, Rebecca - 62 Greenless, David - 42
Clokie, Katrina - 50 Gregory, Janet - 10
Clokie, Katrina - 99 Grizzaffi, Paul - 37, 67
Cohn, Ido - 158 Grossman, Paul - 176, 252
Collier, Justin - 36 Gundecha, Unmesh - 26
Collin, Mark - 33 Haeffner, Dave - 09
Haggan, Christopher - 237 Lewis, Rhian - 86
Halder, Priyanka - 115 Lipps, Jonathan - 251
Haleby, Johan - 17 Ljunggren, Mats - 118
Harrington, Ted - 216 Lupei, Liviu - 129
Harrison, JeanAnn - 66 Lyles, Mike - 32
Hayduk, Bill - 174 Macdonald, Michelle - 101
Haynes, Dawn - 167 Malugu, Satyajit - 78
Hazel, Jim - 21 Manawadu, Dilhan - 209
Heitzinger, David - 151 Manigundan, Jaswanth - 211
Hellesøy, Aslak - 80 Mankovski, Taras - 150
Hernandez van Leuffen, Micha - 249 Mansilla, Neil - 30
House, Cory - 142 Martin, David - 138
Hunt, Troy - 256 Mayrhofer, Josef - 243
Ison, Justin - 44 McCamphill, Hugh - 51
Jackvony, Kristin - 147 McClung, Tommy - 173
Jagtap, Shashikant - 70 Melendez, Leandro - 197
Janca, Tanya - 246 Merrell, Marcus - 119, 180
Jones II, Rex - 247 Merrill, Paul - 40
Jones, Angie - 04, 224 Millgate, Mike - 84
Kadimisetty, Anil - 56 Molina, Diego - 95
Kandyala, Rukmangada - 220 Mony, Gurushyam - 85
Kenst, Chris - 102 Moore, Scott - 198
Khan, Parveen - 187 Mortoray, Edaqa - 69
Khare, Lagan - 148 Moshka, Avishai - 93
Khorikov, Vladimir - 63 Müller, Tobias - 234
Kim, Peter - 114 Nagpaul, Guljeet - 97
Kind, Lance - 245 Navrides, Chris - 159
Kinsbruner, Eran - 140 Neuhold, Klaus - 108
Kirk, Stacy - 126 Nguyen, Hung - 81
Klärck, Pekka - 34 Niedojadlo, Evan - 190, 194
Knight, Andrew - 253 Nolasco, Fabio - 104
Konda, Kalyanarao - 19 Oks, Diana - 219
Konkolowicz, Maciek - 65 Olejarka, Mateusz - 217
Kovalenko, Dima - 05 Page, Alan - 22
Kozinets, Masha - 06 Pal, Raghav - 89
Kravetsky, Eldar - 125 Palamarchuk, Sofía - 131
Krawczyk, Michal - 139 Parbu, Nalin - 183
Krug, Andrew - 79 Paskal, Greg - 07, 53, 74, 154
Kumar, Manoj - 83 Patil, Prashant - 229
Kumar, Sanjay - 133 Pawlikowski, Mikolaj - 189
Lamping, Kevin - 137 Penning, James - 103
Lawrence, Jack - 258 Peteti, Hima Bindu - 120
Lee, Shannon - 177 Philipp, Ingo - 87
Leung, Cassandra - 77 Pip, Corina - 35
Lewis, Meaghan - 23 Poulin, Patrick - 90, 155
Prescott, Lewis - 165 Synadinos, Damien - 43
Price, Huw - 128 Sypolt, Greg - 254
Proegler, Eric - 248 Talbot, Phillip - 238
Pucciani, Gianni - 241 Talks, Mike - 75
Punyani, Mala - 195 Taylor, Nate - 168
Py, Laurent - 100 Tesler, Peter - 123
Quartz Leaf, Sonja - 191 Theodorescu, Adrian - 92
R, Bhavani - 08 Thomas, Dwayne - 204
Race, Amber - 193 Thomas, Marcus - 210
Raman, Narayan - 46 Thomas, Peter - 203
Ramchandani, Laveena - 179 Thurman, Josh - 259
Rao, Shailesh - 91, 206 Tinkham, Andy - 24
Richardson, Alan - 03 Tiwari, Avinash - 113
Riedesel, Jamie - 170 Tondi, Melissa - 57
Rogoza, Israel - 110 Townshend, Stephen - 201
Rosalind Radcliffe, Rosalind - 117 Trimper, Chris - 233
Rose, Seb - 20 Trofimov, Grigori - 178
Rossaro, Paola - 12 van der Hoeven, Nicole - 205
Rowett, Chris - 223 Vernon, Maril - 135
Royzman, Anna - 25 Vest, Joe - 199
Rozenberg, Amir - 68 Viswalingam, Sneha - 230
Rubin, Oren - 145 Weinberg, Gerald - 28
Rust, Jeanine - 156 Westerveld, Dave - 225
Sage, Michael - 236 Wiedemann, Christin - 14
Saha, Parasar - 152, 221 Wilson, Christie - 171
Schladebeck, Alex - 96 Winteringham, Mark - 213
Schmidt, Gregory - 59 Witko, Kinga - 29
Schwering, Ramona - 143 Wittek, Kevin - 181
Selles, Wim - 122 Wright, Jonathon - 45
Sharma, Anshul - 60 Wynne, Matt - 11
Sharma, Pragati - 52 Zalavadia, Sanjay - 39
Sher, Eran - 49 Zounon, Lisette - 250
Sherry, Rosie - 02
Shoham, Shani - 162
Shpakovskyi, Dmytro - 153
Sidorevich, Nikita - 218
Spanbauer, Mike - 227
Staffier, Anthony - 228
Stewart, Simon - 01, 111
Stone, Laura - 200
Subramanian, Sahaswaranamam - 76
Subrameyer, Raj - 144
Sussna, Jeff - 112
Sweet, David - 235
Sweigart, Al - 13

PDF eBook Automation Awesomeness

Uploaded by

Copyright:

Available Formats

You might also like

PDF eBook Automation Awesomeness

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

PDF eBook Automation Awesomeness

Uploaded by

Copyright:

Available Formats

AUTOMATION

No part of this publication, Automation Awesomeness: 260

For more information visit www.testguild.com

Book cover design by Joe Colantonio

Book design, formatting and interior illustrations by

ISBN (paperback): 979-8-9883354-0-5

Printed in the United States

The style of this book was inspired by For Today, published by

As I sat down to read Automation Awesomeness, I couldn’t help but be

Why 260 Quotes?

How to Use This Book

Discover how to engage executives, optimize testing strategies, select the

Claim your free bonuses at the link below:

Every year, I organize and host an industry-standard online event – Automation

Your code (to be used at checkout when registration opens):

** Note: I intend to include more actionable resources in this collection.

Connect with Your Ideal Audience, Boost Brand

What others have said about

“Joe’s service is outstanding. He set up a virtual event with over 1,000

“The webinar the TestGuild organized for us garnered a fantastic turnout

“We’re still seeing dividends from our sponsorship of the Automation

Daily Actionable Awesomeness

omen Focus on learning about testing and gain a deep understanding of

EPISODE 20: testguild.com/20 Founder

Daily Actionable Awesomeness

omen So I’m going to advocate for multiple overlapping abstraction layers

Daily Actionable Awesomeness

EPISODE 194: testguild.com/194 VP, Developer

Daily Actionable Awesomeness

Daily Actionable Awesomeness

EPISODE 32: testguild.com/32 Product

Daily Actionable Awesomeness

EPISODE 8: testguild.com/08 Author of Test

Daily Actionable Awesomeness

Daily Actionable Awesomeness

EPISODE 2: testguild.com/02 Writer of

Daily Actionable Awesomeness

EPISODE 34: testguild.com/34 Co-founder of

Daily Actionable Awesomeness

omen If you’re a business analyst, find a QA and a developer. If you’re a

EPISODE 35: testguild.com/35 Author of The

Daily Actionable Awesomeness

EPISODE 192: testguild.com/192 Technical

Daily Actionable Awesomeness

omen If you’re getting some problem or something’s going wrong, there

Daily Actionable Awesomeness

EPISODE 84: testguild.com/84 Ph.D., Sr.

Daily Actionable Awesomeness

EPISODE 47: testguild.com/47 CEO at

Daily Actionable Awesomeness

EPISODE 101: testguild.com/101 Co-founder of

Daily Actionable Awesomeness

EPISODE 45: testguild.com/45 Creator of

Daily Actionable Awesomeness

Daily Actionable Awesomeness

omen Automation is often thought of as a purely technical issue, but I

EPISODE 60: testguild.com/60 President

Daily Actionable Awesomeness

Imagine you’re a software engineer tasked with automating a critical business