- Now let's learn what tests critique the product
for fast feedback and realistic use.
Guiding coding with testing is great,
but we can't think of everything.
Some testing requires the code to actually be there
to be complete.
So let's look at the right side of the quadrants.
This side is about finding defects.
Quadrant three, that's kind of one of the places
where testers have spent their entire lives in
traditional projects.
But in Agile as usable chunks are delivered,
you can evaluate it.
Does it meet the needs of the business, the customer,
the end users?
Are we testing for the right value?
For example, if we look at the pet salon owner,
are we helping them save time on scheduling?
When we look at the tests in quadrant three we wanna
think about what activities build confidence.
Exploratory testing is one of the things that we
usually think about.
They provide feedback into other stories, and we'll talk
much more of them on lesson five in exploring.
But maybe we have iteration reviews, the demos.
Perhaps we pair with our customers or our product owners.
There's lots of different ways that we can do testing.
Usability testing, user acceptance testing.
Can the user do their work?
We wanna do it as early as possible.
Can we bring our users in?
We really wanna focus on the value to the business.
Think back to our pet salon.
As a busy client, you're scheduling your pet's grooming.
As an employee, you're organizing your schedule and
accommodating clients.
How do people in different roles, in different jobs
use their product?
Quadrant three is a little interesting because we really
wanna think about feedback into quadrants one and two.
What are we learning because quadrant three is about
learning, it's about evaluating our product.
When we think as real users we tend to start
testing differently.
We wanna look for missing functionality.
We might even find a defect or two along the way.
We wanna make it fun as well.
For example, our pet salon.
What if one groomer is so popular?
Can we help her manage her schedule?
Can we help her best clients get access to
their favorite groomer?
What is the value to the customer?
What information might be useful?
We are learning about the product, so what we do,
how we conduct the tests will depend on your own context.
Let's talk about quadrant four now.
This is about critiquing a product still,
but from a technology perspective.
This is often the most forgotten quadrant.
Business stakeholders often assume the team
knows what we want, performance, security,
other quality attributes.
However, the tests in this quadrant might be more
important than the actual functionality,
and is easily overlooked.
The early Agile books and articles focused on customer
and programmer tests.
And I had testers constantly ask me, and I'm sure
Lisa has too, well what about all those other kinds
of testing?
This model has given us a way to talk about them.
Here's a sample of the tests that we categorize
in quadrant four.
You can see there's a lot of different kinds of tests.
We often talk about ility tests, things like reliability,
interoperability, browser compatibility,
but there's also tests like the data migration or
infrastructure testing that team don't think about.
These can be addressed as quality constraints,
and we'll talk about those in the next section.
Why do we have to do it?
Well, a lot of times the non-functional, and we prefer
the term quality attributes, have a higher priority
than functionality.
Example, an airline website.
It goes down when it's having a huge seat sale.
The functionality really doesn't make any difference
if I can't get on and buy that seat when I want to.
If we look at our pet salon, it has a light load,
so load testing is probably not important,
but maybe the privacy of the customer data is.
Does you team have all of the skills that it needs?
It sometimes takes specialized skills for performance,
security, maybe data warehousing or accessibility.
You wanna make sure that you have the skills on your team,
so if you bring in a specialist, collaborate to transfer
those skills.
The fit and finish of your product is what makes the
difference often from yours and the competitor's.
You will need test environments, infrastructure tools,
maybe a production-like environment for load testing.
Really look at that whole product.
When you're planning with the quadrants,
use them to have visual clues.
It helps you to plan for the right infrastructure,
for the right people, maybe the right skills
when you need them.
Use the quadrants to guide planning for conversation,
for priorities, right?
If you understand and you see what testing you need to do,
you learn how to make them part of what you're planning.
We encourage you to make your own quadrants.
Take it, put a poster up, talk about what testing you have
and make it visual.
Remember, it's a thinking tool.
There are other models that might work better for you.
If the quadrants don't work, experiment with alternatives.
On our website, agiletesting.ca, we have download of
chapter eight from our second book, and it talks a lot
about lots of different variations.
One of those might work for you.