- It's easy to be overwhelmed.
We've been talking about planning and executing all
of the necessary testing activities
but all during a short delivery cycle.
Let's talk about seven success factors.
In our first book, Agile Testing, Lisa
and I ended the book with seven success factors.
When we thought about our final chapter to be
the success factors, we sent our
top 20 factors to our reviewers.
We had about 20 people that had been reviewing
the book all along, we asked them
to return their top 10 in priority order.
The top 10 were pretty consistent, maybe
a little bit different priority except for the number
one success factor, that was the whole team approach.
It was consistent, every single person said if you
do not practice whole team, you don't stand a very
good chance of being successful.
Number two was mindset for your agile testing.
Number three was automating.
Number four, feedback, both giving and receiving.
Number five was really understanding your core agile
practices and number six was collaborating with customers,
not to say collaborating with programmers isn't important.
But you need you customers so you understand what to build.
And the last one was remembering the big picture.
We're gonna review each of these individually.
The whole team approach, remember
testing is an activity, not a phase.
Everyone on the team can help.
Testers can teach testing skills.
We can elicit concrete examples of desired
and undesired behavior from the business experts.
We have exploratory testing, we evaluate different
attribute, programmers can help testers understand the
system's architecture, we had coding skills we can share.
We can all learn from each other about design, data,
infrastructure, the business domain, everything that
goes into delivering a software product.
As a team, when we want to solve a problem,
we want to do at as a team.
We want to use our diverse skills and our wide experience.
To be able to do that, we need to have an atmosphere of
trust and safety which also means a learning culture
where we can experiment, continually improve, how we
do testing, how we code, not being scared to fail.
That safety, we cannot overemphasize that.
Number two is that mindset.
If you're a tester and watching this, ask how can you help,
not how can you control, testers are not the quality police.
It's not up to a tester to say go, no go, it's not ready.
But be able to explain the risks, articulate the impact
of those risks so the business
can make an informed decision.
Be proactive, be willing to learn new things.
Take responsibility for your learning, be curious.
I actually start every morning by looking at what's
new on Twitter, I look for new blog posts.
I review some of the things.
You want to be looking and seeing what's out there
constantly asking, constantly being curious.
If you wanna learn about unit tests, read.
Or maybe buy a developer lunch and ask her.
If you're a developer and you want to gain testing skills,
ask a tester to pair with you.
Apply your agile principles and values, work closely
with a technical business teams to keep the big picture
in mind as you put small feature increments together.
We spent a long time on automation in lesson four.
But there's a few things we'd like you to remember.
Start small and simple, keep your
automated tests to a minimum if you can.
When you're starting, you may even want to start
with your biggest pain points to get a quick win.
Strive for a goal but remember small steps.
Don't try to do everything as once.
Use your executable specifications to guide development
so that the automation happens almost as a side effect.
Keep enough regression tests to give you confidence
about releasing, run those regression tests often.
You want that fast feedback.
At a very minimum, you wanna run 'em daily.
And you can even keep in different scripts so you
can run 'em at different times.
For example, unit tests with every single build.
Put your automation to the lowest level that will
work for your situation, remember automation is not
about finding bugs, it is a change detector.
The whole team approach makes you wanna think about
holistic testing even in your automation.
A good automation strategy allows you to have time
to find the real issues and explore.
Remember the quadrants to help think about the different
types of testing and think about what you wanna automate,
which ones you wanna leave for manual exploratory testing.
Some of the quadrant two tests might be manual, like
paper mark ups, quadrant three tests are primarily manual
because they have tests like user
acceptance testing and exploratory testing.
Quadrant one pretty much all automated because it's
those unit tests and the programmer kinds of tests.
Giving and receiving feedback, that's an art.
It's hard to give good feedback.
It's hard to receive feedback and know what to do with that.
Testers are really good at providing feedback, use it.
Use the feedback form automation regression tests
or exploratory testing or any other kinds of testing
to learn and to improve your whole team experience.
Whole team retrospectives at least weekly
or at the end of every iteration to identify
your biggest testing related problems and then
design experiments to help chip away at those.
Any time you have a testing problem, make it a team issue.
Let the whole team address it.
Communication skills are key, practice active listening
and find good ways to give feedback.
I took Toast Masters for years.
It's a public speaking forum to learn to speak in
out in public, what I took away from that, one of the
most important things I took away from that was not
learning how to public speak, which was good.
But learning how to give feedback to other people.
It's not as easy as we would think.
People have different communication styles
so be aware of that and try to accommodate different needs.
Find ways to visualize quality and testing outcomes.
Can you display the build results and statistics
on a wall monitor or on a light display?
Find light weight methods to share exploratory testing
outcomes, the transparency that comes
with visibility is very, very powerful.
Number five, following best practices doesn't
guarantee success, in fact, Lisa and I don't think
there is such a think as best practices.
There's some very good practices and we wanna keep
doing those but to say a best practice, that kind of
thinks that maybe we're as good as we can get.
And that's really not what we're trying to do.
That agile testing mindset says
we continue to improve all the time.
Core development practices that help us deliver reliable
and valuable software both frequently
and sustainably are important.
Working in small increments, thin slices.
Integrate testing and coding activities.
Collaborate for quality, get people with the right
skill set to work together.
Remember no story is done until it is tested.
All types of testing has to be considered.
Continuous integration is not new but it is important.
Lisa worked on a waterfall team in the early '90's
to practice continuous integration.
It kept the teams on track with fast feedback.
And when you use it in that way, it avoids
that pre-release integration hell.
And we don't want that, we want it to be smooth.
Remember that big check mark.
Have appropriate and controllable test environments
for different types of testing.
Know what you're testing in each of them.
Developers need their own local sandboxes, for example.
You need production like environments for exploratory
testing and performance testing.
Lisa's team has made an investment in having their
continuous integration automatically deployed artifacts
from successful builds to the appropriate test environment.
For example, into the development environment so
they can run a smoke test.
You may want it to deploy to your test environment.
But be careful because sometimes you may want to
have a test environment that's stable if you're running
a long, a test that takes more than a few hours.
You don't want automatic deployment at that time.
So really understand your test environments.
We are constantly making trade offs to help
the business targets but when we make shortcuts
and we get resulting technical debt, we have to pay it back.
For example, if we skimp on test automation to meet
a business deadline, we should immediately automate
sufficient tests to allow for later changes or refactoring.
Respect the automated regression tests and keep them green.
Number six, collaborating with your customers.
It's not just a saying, it's critical.
If we don't understand what problem they're trying
to solve, we may solve the wrong one.
Teams need to work with their customer to understand
their needs, testing allows teams to identify risks
so customers can make their best
decisions which in turn builds trust.
By delivering working software and getting input from
our customers, they also gain confidence in the team.
Learning their domain by working closely with the end
users or asking for examples or drawing pictures
on white boards will help understand the difference
in clarifying meetings, for example,
we use the examples of Lisa's donkey.
She tried to explain to me and I didn't understand
what she was talking about till she drew the picture
and really started labeling them.
Visual clues are so important.
Ask for those concrete examples, scenarios.
How will you use this, what's the worst that can happen?
Testers can facilitate developer customer communication
but it is really important not to get in the way.
You're not in the middle, the power of three
is a critical practice to make sure
everyone is on the same page.
Priorities need to be negotiated by the team
and the customer has to take into consideration
the trade off on the business risk and the development risk.
And number seven, we have mentioned this so many times,
thinking about the different
levels, looking at the big picture.
As programmers work on a story, they often focus on
that small part, the narrow part of the application.
We also need to look at how that story fits into
the larger system, guiding development with business
facing tests helps us keep an eye on that larger system
and how it meets customer and user's needs.
We can use mind maps, flow diagrams, context diagrams,
state change diagrams or any other tool to look
at dependencies and the ripple effects of each new feature.
If our features aren't easily understood
and used by everyone, they won't provide the intended value.
So keeping an eye on that big picture is a strength
that testers bring to the agile teams.