- When we talk about user scenarios
you want to start with a happy path.
You have to have at least one.
You might have several misbehaviors.
When we're thinking about those scenarios again,
we want to be thinking about the business rules as well
because we really want to get that understanding
of that feature and without the business rules
mapping to the examples and the scenarios,
you get lost.
- Thinking about more business rule might make us realize,
we actually need an additional story here
or we need to make sure we do extra exploratory
testing around these rules because they're pretty tricky
and we want to make sure we get them right.
We'll be talking about exploratory testing
more in lesson five.
Use examples that pertain to the business value.
Again this isn't the time to think
of every possible edge case and as testers
we can usually think of lots of those.
Again depending on risks and the domain you're working in
and the context and the level of detail that you need.
In general we want to be focusing on
what are we giving the user with this feature.
We want just enough examples to clarify the desired
and undesired behaviors,
so that the developers know where to start.
- You mentioned a really good point there
that don't get carried away on all the edge conditions.
A lot of times I've heard teams say,
"We don't want the testers in these meetings
"because they ask too many questions."
(laughs)
I find that it's not too many questions.
The level of detail is too low.
Instead of realizing they're at the feature level,
they're asking questions down at the task level
and so understanding that level is quite important as well.
Some of the scenarios that we're thinking of,
user enters a valid option for the information
and receives a confirmation appointment.
- That's the happy path.
That's the expected behavior.
What about if the user selects a time slot,
enters all the information and then moves away from the page
without the confirmation because the phone rang.
- We really don't want that user to lose their data.
People would really hate that.
- What would you do if you come up
with that kind of question?
Would you say, make it so
or would you come up with some concrete examples?
- We might just make them know that we need
to think of a way to mitigate that
or we might even discuss some options like
where we can cash that information in the browsers
so that they an come back and they haven't lost it.
- But you wouldn't solve all of them at this point in time.
- Right, right.
- What about say, sequel injection exploits?
Somebody wants to get out of a pet salon
and book up all our appointments
because maybe they just are mad at the dog groomer?
- Exactly.
All kinds of evil hacks could happen
and we talked about things like
the importance of privacy of data, things like that.
These are questions that are good to bring up
and the answer might be,
"Our architecture already takes care of that
"or we take care of that at the database level,
whatever it is."
But asking that question because of the highrisk
is appropriate.
- Alright, next let's look at how we can actually
use tests to guide your development.