Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
In software we use the terms Happy Path and Edge Cases as ways to describe what the feature was intended to do, versus what our users might actually do.
Definitions:
- Happy Path: Testing with only the acceptance criteria of the feature.
- Edge Cases: Testing outside of the base assumptions, finding different ways to use a feature that were not intended.
- Inputs: Where a user can create their own data or interact with the application
- State management: features that may work in different ways depending on actions taken by the user
Common things to look for with user behavior:
- Inputs - anything where the user can type something in, add a photo or file, or click/drag/move things in the application.
- State management - Doing an action in one part of the app that affects what can happen in another part of the app. Think workflows or how the user navigates through the application.
Common edge case questions to ask:
-
Can the user enter anything in this text field?
- How much can they enter?
- Can they enter special characters?
- Is it numbers only, alphanumeric characters only, date only?
-
Is this icon always draggable?
- Where can I drag it?
-
Can I upload a file?
- What kind of files are supported?
- How large can the file be?
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
Now that we've gotten a fairly
basic test case created,
0:01
it's time that we start to test
more of the less obvious pathways.
0:04
In software, we often like to
use the terms happy path and
0:09
edge cases as ways to describe what
the feature was intended to do,
0:13
versus what are users might actually do.
0:19
Let's picture that we're at
a really nice grassy park,
0:23
a path cuts down the middle of it and
it's the only way to get through.
0:27
This is our happy path where nothing wrong
can happen as long as we stay on it.
0:32
We might become bored though,
and venture off that path.
0:38
Some of the ground here is
muddier than we thought.
0:41
There's bramble and bushes to get through.
0:44
And it's pretty obvious that
the park creators never intended for
0:46
us to walk off of the path.
0:50
In a lot of ways, code ends up being
like this when it's first written,
0:52
where designers and developers only really
think about the clear cut happy path for
0:56
users to take.
1:01
It's our job as QA engineers to think
about what the common scenarios are,
1:03
where people will wander off of that path.
1:07
That seems pretty difficult to do,
though, doesn't it?
1:10
How can we possibly know everything
that our users will want to do
1:14
that we didn't think of?
1:18
Maybe instead of typing in their name,
1:20
the user will type in
their user ID by mistake.
1:22
Maybe a user has a particularly long
name that a text box can't handle.
1:26
Or maybe, a user is having a slow
internet connection and decides
1:32
to click the save button very rapidly over
and over again, and it causes a big error.
1:36
The answer is that we can't possibly
think of everything users will do.
1:42
Experience will teach us
a lot about what to look for.
1:46
There is a lot of fairly common
things that users will do however,
1:50
that we can look for.
1:54
The most common places where users
can stray heavily off the happy path
1:56
are inputs.
2:00
So anything where the user can
type something in, add a photo or
2:02
a file, or quick and drag, or
move things in the application.
2:06
So think web forms,
add a file button, drag and
2:11
drop images, or even games that involve
where the mouse pointer is on the screen.
2:15
Our other most common
area is state management.
2:20
This can get complicated though.
2:23
Basically, it is doing an action
in one part of the app
2:26
that affects what can happen
in another part of the app.
2:29
Think workflows or how the user
navigates through the application.
2:32
If a user goes to one area before they've
done an important action in another part
2:37
of the app, then it's probably
outside the normal happy path.
2:41
And we need to test what
happens in that case.
2:45
These two things will make up
the majority of testing user edge cases.
2:48
For inputs you can ask questions like,
2:53
can the user enter anything
in this text field?
2:55
And if so, how much can they enter?
2:58
One very common issue is when
a user tries to enter in
3:01
way more text than what
the developers intended.
3:04
Is this icon always draggable and
if so, where can I drag it?
3:08
Sometimes, users will move an icon to
a weird part of the screen that we didn't
3:13
think of, and
make the icon disappear entirely.
3:18
For state management,
we can ask questions like,
3:21
can I click this icon if this
other icon is highlighted?
3:24
If the developers were trying to lock
out the screen to your other actions,
3:29
then they probably didn't want
users clicking anything else.
3:33
But, it's best to assume that users
will still try to do that though.
3:37
Our RSVP app has a few places where
we can look for these edge cases.
3:42
In the next video, we'll be writing a test
for some of these common edge cases.
3:46
Our added name feature
from the first video
3:51
involves a text field which allows
the user to re-enter whatever they want.
3:54
Some things to consider here are,
3:59
how many characters should
the user be allowed to enter?
4:01
What if the user has a very
long name with no spaces?
4:04
What if the user has some special
characters in the name that
4:07
aren't supported by the website?
4:11
A few state management
things here happen too.
4:13
For instance, it's possible to hide
users who haven't responded yet.
4:16
What happens when we hide
users while editing a user?
4:22
On the whole,
edge cases are going to make up
4:26
a lot more of your test cases
than just the happy path.
4:29
So it's good to understand them.
4:33
But also understand that you
simply can't think of everything.
4:35
Users will find other ways
to break the application.
4:39
Our job is to simply try to stay as far
ahead of them as we can within reason.
4:42
In our next video, we'll be putting
some of those edge cases into our
4:48
edit button test from the last video.
4:52
I'll see you then.
4:55
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up