- Janet just explained some key success factors
to succeed with testing in Agile projects,
but there's even more we can do to build confidence
in the features that we release.
Let's talk about some core testing practices
that let us deploy frequently without worrying.
We wrapped up our second book More Agile Testing
with a list of confidence-building practices.
These practices support the key success factors
that you just learned about.
Again, these aren't best practices
because they don't all apply to everybody,
but we do feel they're leading practices.
It always depends on your situation.
Confidence builds our courage to innovate,
to experiment, to improve.
Let's look at each one of these practices
that can help us do that.
Have you ever been in one of those endless meetings
where a discussion seem to just go around and around
in a circle but achieve no clarity?
If that ever happens to you,
our advice is to grab a marker
and start drawing examples on a whiteboard
to get the conversation back on track.
It's the best way to illustrate business rules.
Examples take many forms.
We've talked about some of these,
things like mockups, spreadsheets.
Talk through them with your business stakeholders,
with your delivery team.
Use those acceptance test-driven,
behavior-driven specification by example tests
to guide development with examples.
They may be executable automated tests or not.
We've talked a lot about exploratory testing
because we think it's so key to building confidence
in our software product.
Testers can help other team members
learn exploratory testing skills.
This is something that my team has been doing
quite successfully, having developers pair with a tester
to do exploratory testing before finishing a story,
or as they gain their exploratory testing skills,
developers can pair with each other to do this.
That lets us catch problems sooner
and they record what they learned
about that particularly story
so that anyone doing additional testing
such as a product owner doing acceptance testing
knows what's already been tested in that story.
It can save some time.
And it also allows programmers and product owners
to know to go beyond the happy path of the story level,
to try some misbehaviors,
to maybe even channel some personas
and see how different users would use the system.
This all allows testers to have more time
for exploratory testing at a feature level,
thinking about that big picture,
thinking about impacts on other parts of the system.
So, pairing with other team members
do things that might be missed
like checking for backwards compatibility
when you build new features or change old features.
Transferring these professional testing skills
benefits everyone in building confidence.
When we talked about the big picture, as Janet mentioned,
we are always working in these small chunks
and small increments and that's good.
It helps us finish things as we go.
It helps us focus.
But, we don't wanna forget impacts on other areas.
We don't wanna forget about the value
that we're trying to deliver.
And Janet compares this to putting together a jigsaw puzzle.
You don't necessarily have to complete the entire puzzle
to get value out of it.
Maybe you're most interested in seeing
the faces of the people in the puzzle
or maybe there are some nice flowers
and you just wanna do that part of the puzzle.
What's the most value to you?
We can do that with our software as well.
We can't necessarily test everything,
but we can test the most important things
and remembering those additional quality attributes
like performance, usability, and security.
Learning continually, we've talked a lot about learning.
You can't fix every problem at once,
so use your retrospectives.
Identify what's holding you back,
what's the one thing that you would like to get better at,
what's the one goal that your team wants to achieve?
And think of some small experiments
to get closer to that goal or to solve that problem.
When we have self-organizing teams
that feel safe to experiment,
that's when we get the innovation
that gives our company the competitive advantage
and makes us more successful.
Cross-functional teams with diverse skillsets,
remember those t-shaped skills
and those square-shaped teams,
help make sure all the testing gets done
at the appropriate time.
Remember your context.
We talked a lot about that.
Apply the Agile values, principles, and practices.
That's what's important.
Just learn those and apply them in your own context.
We've talked about how your team might be subject to audits
and regulatory agencies that perhaps have requirements
for things that you don't have like extra documentation,
so be sure to plan for discussing those things with auditors
and discussing those things with your business
to decide what can you do that works for you
and meets these requirements.
If you're working in a global enterprise company
with distributed teams, maybe in different timezones,
you have a lot of extra challenges
to ensure good communication and to manage dependencies.
If you're working on something like mobile application
or embedded software,
you have to be creative to find ways
to test multiple devices,
different operating system versions.
You have a lot more complicated problems to solve
than someone who's working on a web application
that only needs to run on one browser.
You may need to bring in people with specialized skillsets
or you may need to devote time
to learning those specialized skills.
Be sure to plan for that.
You may need to invest in new infrastructure,
for example to make your continuous integration builds
run faster and get that fast feedback that we need so badly.
Whatever gets in the way of the quality
that you want to give your customers,
look for creative ways to solve the problem.
Testers are good information providers
and testing helps us inform the business about risks
and we can also make suggestions
about how to mitigate those risks
with testing or other activities.
If we can't get the necessary testing done
before a particular business deadline,
ask the business stakeholders whether scope can be reduced
so that we can achieve the level of doneness that we want.
We found that new Agile teams,
because they're very eager to succeed,
often take on too much work at once and they find that,
"Oh, we don't have time to automate the test," or,
"We don't have time for exploratory testing
"because we have to deliver all of these stories."
Manage your workload so that you build in time
for all those necessary activities.
And if they're new skills for you,
build in time to learn them.
You can limit your work in progress.
For example, your teammate decide to only work at
up to three stories at one time.
If all the development activities are done for those stories
then the whole team can help finish the testing activities.
We're always faced with pressure from the business to say,
"Can't you do a little more work?
"Can't you get it done a little sooner?
"Can't you meet this business deadline?"
As Bob Martin points out in his book The Clean Coder,
saying will try when we're asked to do something
that we know is impossible doesn't help the company succeed,
so it may be tempting to tell your manager,
"Oh, yes you want that by next week?
"We'll try," and you know good and well
it's not gonna happen.
You sometimes have to give a reality check and say,
"We can't get that done,
"but how about if we reduce the scope?
"What do you really have to have by next week?"
It's never fun to deliver any kind of bad news,
but it's better than letting problems get out to production
and affecting your customers in a negative way.
When the whole team owns quality,
look for ways to learn quickly about any issues
with the new features that you want to deliver.
And again, educate managers, others in the company,
about the value of testing.
Why does this investment and quality pay off?
It forms a good basis so that we can deliver
that business value frequently.
We're not afraid to change our code.
We're not afraid to add new features
because we have all these supporting safety nets
and regression testing
and the knowledge to do exploratory testing
and other forms of testing.
So, for the company, that's gonna pay off in the long run.
Collaborate across the delivery team
and with the business stakeholders
to find better ways to build quality in.
If there's a testing bottleneck,
again, engage the whole team in finding ways to remove it.