- Now we're gonna talk about how to
apply your testing mindset.
We want to avoid the waterfall style of big design up front.
At the same time, we want to know the features
that the business needs and how they should be developed.
We just don't want to go into quite so much detail.
We're going to apply our testing mindset to help create
the shared understanding of features before coding begins.
Small differences and assumptions
can cause big misperceptions.
You've probably seen the pictures of the classic tire swing
metaphor where different members of the team
have a different vision of that swing in the tree.
They might have a rope hanging from branches on either side
of the trunk or three ropes instead of two.
We have to collaborate to build shared understandings
so that we really know that what we wanted was a tire
hanging from a rope in that tree.
We apply our testing mindset in all of the meetings
that we go to, backlog refinement,
story readiness workshops, iteration planning meetings.
A testing superpower that we have is to bring the right
people together for a discussion.
Iteration planning meetings, for example, can be frustrating
if people didn't start out kind of on the same page
with their understanding about the stories
that we're about to discuss.
Try pre-planning meetings with fewer people.
Janet and I have a concept we call the Power of Three
where we get a product owner or other business stakeholder,
a developer, and a tester together to talk about
a story or a feature.
George Dinwiddie calls us the Three Amigos and it's more of
an optimal-sized group for communication.
We might bring in an additional person or two
such as a designer or a database expert,
whoever we need, but not a huge group of people.
We can ask business stakeholders
for business rules and examples.
We definitely want them to give us concrete examples.
And we want to focus on the values of the customer.
What's the goal of each story?
Leave the edge cases.
We can always think of boundary conditions to test,
edge cases to test, but depending on the risks in the domain
where we're working, we can probably leave those for later.
The outcomes of these small meetings can get the larger
team on the same page to do more planning.
If you're a new team, you might try to bring in
a trained facilitator to help you with things like
specification workshops to do these activities
and have these conversations.
Another superpower that testers have
is their questioning ability.
When we start each new feature or new release or project,
by thinking about testing, how we're gonna test it,
that's how we build quality in.
We avoid defects, we avoid unnecessary bling, scope creep.
We can start with a minimal thin slice of functionality
that we can get feedback from our end users
and from our business and improve our product incrementally.
We avoid wasting time delivering software that doesn't
actually solve the business problem.
We're trying to solve problems for the business,
for the customer, and for the end user.
Let's go back to our case study
that we're using for examples here.
We're again going to use the pet salon.
The pet salon's website is pretty basic.
Currently it just describes the services available
and some information about the groomers and times
of opening, things like that.
And so currently, customers have to call to book
their appointments, which interrupts the groomer's work,
and they want to save that time.
So, what the pet salon wants is some basic way for dog
and cat owners to book basic services online
and get an email confirmation about their appointment.
So, as the delivery team, we got together with our customers
at the pet salon and did a story map.
This is something we learned from Jeff Patton,
who has a wonderful book on user story mapping.
It's a great way to think about the capabilities
that you just really wanted.
So we got everyone together and started thinking about
what would our users do when they're thinking about
booking an appointment for their pet.
It allows us to look at how we can give our customers
what they want and still meet our goals,
such as bringing in revenue.
And it helps us decide what we really want
to get done first.
How can we prioritize the features,
how can we divide up our releases?
It also allows us to start testing because we're questioning
early, do we really need this feature,
what problem would this particular thing solve,
who's going to be using this,
what would happen if?
These sort of what-if questions.
It's a powerful framework for a company wide conversation,
getting everybody in the room talking about it.
And when we did our story map, one of the benefits was
we got these personas of types of users for our system,
such as Sally the salon owner, Gigi the groomer,
or Cindy the cat owner.
So there are a lot of different benefits that come out
of this that help us get that shared understanding.
And we can take this and decide what's the initial slice
that we would like to release, what's our minimum viable
or valuable product that we could deliver and get
feedback from our customers?
Again, we're focusing on the value to the customer.
Right now we're not worried about
how we will implement the feature.
We are thinking about who's going to implement it
and who's going to use it.
And it doesn't have to be perfect at this point,
we're just starting to have conversations and thinking about
how we can build incrementally.
For example, the salon has a lot of service options to offer
and we're just gonna start out by having a hard-coded list
on our website.
Later, we want to make that more dynamic so that we pull
those options out from a database.
But, for now, we don't think we need that just to get
feedback on how the website works.
We're focusing on the most valuable capabilities first,
actually booking the appointment.
We encourage you to learn more about story mapping
and give it a try.
Again, great way to get shared understanding.