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 addition to simply testing what the developer has done, manual test cases can also provide useful documentation for people learning how to code for the software.
RSVP App link: https://treehouse-projects.github.io/selenium-webdriver-intermediate/waits/app/index.html
Definitions
- Test Step: An individual thing to do in the test.
- Expected Results: What the expected result of the software is after performing a step.
- Setup: Steps to take to get the test prepared and ready to execute.
- Tear Down: Cleanup steps after a test is completed. Important for leaving a clean slate for later tests.
Blank Test Case:
Name:
Setup:
Steps:
| # | Step | Expected Result |
| 1 |
Teardown:
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
[MUSIC]
0:00
Welcome to stage two of
intro to QA Engineering.
0:04
We're now going to be getting into the
real work of testing by writing out manual
0:08
test cases.
0:13
These test cases can serve
a lot of useful purposes.
0:15
In addition to simply testing what the
developer has done, they can also provide
0:19
useful documentation for people
learning how to code for the software.
0:23
They can also serve as a proof
of work later down the road for
0:29
things like certification.
0:32
So it's important to write our
test clearly and not just to
0:34
fill it with too much jargon that only
our testers and coders would understand.
0:37
The very first thing we'll do
is choose a name for our test.
0:42
We're gonna be testing a very simple
part of the RSVP application,
0:47
the edit button for an invitee.
0:51
So when I click edit,
a person's name can be edited.
0:54
And when I change the name,
let's just put a 2 here,
0:59
I can click the save button and
the name has been updated.
1:02
Pretty straightforward.
1:07
So I'm going to go over to our Test Case,
and for the purposes of these videos we're
1:08
going to be using simple Word processors
with just tables and spreadsheets.
1:12
So I'm going to be writing
this just in Google Docs.
1:17
First let's name this test based
on our feature, the Edit button.
1:20
I'll start by simply naming it Edit.
1:24
Now, Edit is probably one of the most
commonly used terms in software,
1:27
up there with save and new,
so I'd also like to indicate
1:31
where in the software I'm editing this,
which is the invitee.
1:35
Eventually, I'd like to have a lot of
tests that are fairly easy to find, so
1:38
I wanna put the major part
of the feature first.
1:42
So now when I edit it,
1:46
I'm gonna actually going to add in
Invitee to the beginning of that name.
1:46
And it will look like Invitee- Edit.
1:52
We'll probably create some other
test cases, like Invitee- New and
1:55
Invitee- Delete later.
1:59
Okay, now let's add some steps.
2:01
Test step should be very atomic, or in
another words you should do one thing and
2:03
then you expect something
else to happen from that.
2:08
You also want to be very descriptive
about what exactly should happen.
2:11
So I'm going to go back
to the RSVP app page.
2:16
And I just wanna click the edit button,
and
2:20
I expect the person's name to
now be in an editable text box.
2:23
I'm going to go back to the test case,
and then add this step as,
2:27
Click Edit under the first person.
2:31
Our expected results should be,
Person's name is in a text box, done.
2:38
That's just one step.
2:47
But we need a few others to
actually test out this feature.
2:48
The next step will be to test whether
the text box is actually editable.
2:52
All we need to do here is change
the name of the user to test that.
2:57
Our next step is then going to be,
3:00
Delete the person's name and
type 'Test Person'.
3:03
Our expected result,
3:11
'Test Person' is now in the text box.
3:14
Great, so I wanna take an aside
here because we're actually testing
3:20
out a lot of functionality
with just that one step.
3:25
We're testing things like, can you delete
the person's name or just add on to it?
3:29
How fast is the act of deleting and
typing in a new name?
3:35
Does your cursor show up
when you click the text box?
3:39
All these things could be called out
in our expected results section or
3:42
even be just their own individual steps.
3:46
But we're not gonna do all
that here because, one,
3:49
it would balloon the size of our tests.
3:52
And two, there's just some things
that we assume the user knows,
3:55
even in the meticulous world of QA.
3:59
We like to call these assumptions, and
if those assumptions are not obvious,
4:02
like our textbox example, they should
get called out in the test case itself.
4:07
Let's add something simple, though,
4:14
just to make sure that there's
no ambiguity in the test step.
4:15
Just to make sure we're not leaving
too many assumptions up to the tester,
4:19
let's add click text box to
the beginning of this step.
4:24
It's okay to have multiple things for the
user to do in the test step as long as you
4:32
don't expect a lot of changes to
validate between those things.
4:36
This also eliminates
a potential assumption
4:40
should the text box be focused
right after you click Edit.
4:42
If that was the case, we could probably
add that to the expected result of step 1,
4:46
but that's actually not the expected
behavior here, so we'll just move on.
4:51
So I'm gonna go back over the RSVP app and
4:54
then actually perform that step
by entering in Test Person.
4:57
And I wanna save the name
that I just entered.
5:02
When I click the save button,
the name is saved, and
5:05
the edit box is no longer there.
5:08
So let's go back over to our test case and
add that as our last step.
5:10
So for step 3, let's add,
Click Save button.
5:14
And our expected result is that 'Test
Person', Is now the invitee's name.
5:20
So this is an extremely simple test case,
but it should give us some confidence
5:29
about testing whether the edit
functionality is doing its job or not.
5:33
I mentioned earlier that test cases can
make good documentation and proof of work.
5:39
And a good example of that is when you
explicitly call out things in the test.
5:44
Like when I click edit, I don't expect
the app to focus on the name, so
5:48
I could add that as one of
the expected results for step one.
5:53
Instead I expect the user
to click the name.
5:57
Someone asking later down the road about
why this doesn't work the way they assumed
6:02
can be pointed to the test case.
6:07
If we wanna change that functionality,
we will also need to edit the test case.
6:10
There's one more thing we're going
to need to add to this test,
6:16
though, before it's complete.
6:19
We're making a pretty big assumption
that when we load the application,
6:21
there's already a person there to edit.
6:27
But we don't really know
if that's the case or not.
6:29
So let's say another test had me
delete every invitee on the page.
6:32
Now when we get to the edit test,
we don't have any data to work with.
6:37
That's not really a big deal
on this particular case, but
6:41
I think any reasonable tester would assume
they need to add a person to edit them.
6:44
But for more complicated
applications where the data can be
6:48
much harder to set up, it may not be
very obvious what steps need to be
6:51
taken to get the test ready to execute.
6:55
We're gonna go back over
to the test case and
6:57
fix this by simply creating a setup step.
7:00
And all it's going to say is,
7:03
Delete all existing people.
7:08
Add invitee Jay McGavern.
7:13
This is a nice setup step because it works
in any scenario the app is already in.
7:19
These are important things to remember,
7:24
especially if you're
automating your tests.
7:26
Test data from previous tests can pretty
easily muck up your application and
7:28
make it difficult to test.
7:32
As a final note,
we should also probably tell our testers
7:34
to clean up their data before
they move onto their next test.
7:37
This is called a teardown step.
7:41
So let's write our
teardown step simply as,
7:43
Delete user 'Test Person,' which is
the person we created during the test.
7:47
Remember that we renamed
the user in the test.
7:55
In other applications it's probably
better to use a unique ID of some kind.
7:58
And that's it for our test.
8:03
This is a very simple test case, but
as you can see, a lot of care and
8:05
thought went into each step and
what we were verifying specifically.
8:09
So as a recap, it's good to remember to
name your tests both appropriately and
8:16
in a way that makes it easy to find them.
8:21
Your test steps should be atomic
with one input and one output, and
8:24
always with clear things for the user to
do, and clearly defined expected results.
8:29
Anything that can't clearly be assumed
should be written down somewhere,
8:34
either as a note in the test itself,
or as a clear step or expected result.
8:39
Also don't forget to list any Setup or
Teardown steps
8:44
that help testers get the application in
the right state before performing tests.
8:48
Thanks, and join me in the next
video as we expand this test
8:54
to include some edge cases that
we don't normally think of.
8:58
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