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
We have written our tests and now we need to start actually running these tests. In this video, we will discuss creating test plans.
RSVP App link: https://treehouse-projects.github.io/selenium-webdriver-intermediate/waits/app/index.html
Test Plan: RSVP App - Edit Invitee Feature Release
Scope:
Verify edit invitee feature for RSVP app.
Regression test previous features.
Schedule:
1 hour to execute.
Deliverables:
- Test results.
- Bug report.
Release Criteria:
- Release must contain edit feature.
- All critical defects must be fixed.
- 100% of regression tests pass.
Risks and Contingencies:
- Previous client data may not load.
- Rollback to previous version.
Test Cases:
- TEST1: Invite Someone new
- TEST2: Confirm someone
- TEST3: Remove someone
- TEST4: Edit someone
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
Hey there, so
we have our tests written up, and
0:04
now we need to start getting down
into actually running those tests.
0:07
This stage will focus on how to go
about planning and executing tests, so
0:12
that your company will be confident
delivering this software.
0:17
In this video, we're going to be
talking about creating test plans.
0:21
Now, test plans are definitely
one of the most stringent parts
0:26
of the software testing world.
0:30
You probably remember TPS reports
in the movie Office Space,
0:32
which stands for
Testing Procedure Specification.
0:37
And that is actually what we're
gonna be talking about today, but
0:41
maybe not TPS reports specifically.
0:44
Our newest feature for
0:47
the RSVP app is editing someone's
name after we've saved it.
0:48
We wanna release this soon, but also make
sure that everyone in the company is
0:52
confident about our testing efforts, so
we'll create a test plan to cover this.
0:56
We wanna create a plan that
covers the following tests.
1:02
And let's assume we've written up all
these tests as different test cases at
1:06
this point.
1:10
So invite someone new,
confirm someone, remove someone, and
1:11
edit someone, which is actually
the feature we tested in the last section.
1:16
We'll create a plan that
covers all these tests,
1:21
as well as a little bit of information
around our strategy for testing.
1:24
Our test plan document would be a formal
write up of the following topics.
1:28
Scope of testing, schedule,
1:33
test deliverables, release criteria,
and risks and contingencies.
1:36
Okay, so
first topic is scope of the testing.
1:42
This is like telling the reader what
our objective is for the test plan.
1:45
It should list some objectives like
verify edit invitee feature for
1:49
the RSVP app, and
regression test previous features.
1:53
And it should also list what work may
be out of scope for the test plan.
1:57
In this case we are not gonna be
testing browser compatibility,
2:01
only that the features
work with Google Chrome.
2:05
Because it is the most popular web
browser and covers most of our users.
2:07
For schedule, we'll wanna figure out
approximately how long this set of tests
2:12
will take to execute, and
give a rough time estimate.
2:16
Each time we execute tests,
2:19
we should get a better idea of how
long it will take to execute them.
2:21
This is important to keep in mind if
some of the testers are brand new.
2:26
Each of these tests only takes about
15 minutes to execute, and we only have
2:30
four tests total, so this test plan
should take about 1 hour to execute.
2:35
Longer test plans might require some
more planning around when certain tests
2:41
should be done.
2:46
It might be good to set goals like 50% of
test cases are finished after one week.
2:47
You may also need to share
resources with other teams, though.
2:53
Like if you only have access
to a few Apple devices and
2:57
another team needs to use them later.
3:00
So it might be good to say, all Apple
products are tested within the first week.
3:02
Test deliverables are the reports and data
generated from the test plan that must be
3:07
collected, and
possibly given to the client.
3:12
These are usually
included in test reports,
3:15
which test pass versus which failed.
3:18
Bug reports, which we'll get to later,
and logs from the application, and
3:20
anything else that a client might be
interested in seeing from the tests.
3:25
In the past, for
3:29
me, this has been a complete list
of every test and every step.
3:29
What passed or what failed, and
what caused those failures.
3:34
Release criteria is an important part
of test planning because it gives you,
3:39
the tester, a way to be objective in
the face of pressure to release something.
3:43
Not everything in your test plan is
going to pass the first time around.
3:47
It may not even have all the features that
your product manager originally wanted.
3:51
It's important to write down
which conditions are needed
3:55
to release this product.
3:58
Some good examples of release criteria
would be percentage of tests passing.
4:00
As in, we're only gonna release
once 95% of our tests have passed.
4:06
Another pretty common requirement is
that all critical defects must be fixed
4:12
before release.
4:16
Lastly, and
I've seen this happen in many cases,
4:19
agreement about the minimum
features needed before releasing.
4:22
Often a very specific feature
needs to be in the release.
4:27
So the requirement might be that this
one feature must be complete, but
4:32
others can be left out if
they're not completely finished.
4:37
These criteria will help when determining
4:41
if it is all right to
release a product yet or not.
4:43
People at a business almost always
wanna release quickly and often.
4:47
But as good quality assurance engineers,
4:52
we need to be able to tell them whether
it's ready or not with confidence.
4:55
We also need a good reference when the
business needs a quicker path to release.
5:00
Release criteria should help determine
if some components of the test plan
5:05
are really necessary or not.
5:10
Lastly, risks and
5:13
contingencies are a sort of measurement
of the uncertainties with testing.
5:14
We may not be certain
if a client's complete
5:20
dataset will work with the new software,
for instance.
5:22
In these scenarios,
we want to know how to mitigate the risks.
5:26
So being able to revert safely
back to a previous version easily
5:30
would be a good way to mitigate that risk.
5:34
Honestly, though, risk analysis and
managements tends to be a pretty broad
5:37
topic and we wont cover much
about it in this course.
5:41
So, in my experience, the amount of
detail that needs to go into a test plan
5:45
has a lot to with what customer needs.
5:49
Some customers need to know exactly
what your company has tested.
5:53
How long it took, how they did it, who did
it, and with what hardware and software?
5:57
This is pretty extreme, though, and
6:03
in other cases the company does
not need that level of detail.
6:05
Ultimately, the business needs to decide
how much detail a test plan needs.
6:09
Just a simple list of what
test cases have been executed,
6:15
and what needs to pass before
something could be released is fine.
6:18
You all need to work with your company
to decide what you'll need to create for
6:23
a useful test plan.
6:27
In our next video, we'll be going over
regression and configuration testing.
6:30
These are similar topics to
creating a formatted test plan, and
6:35
that's why I wanted to introduce this
broader idea of a test plan first.
6:39
The next video should give you a better
sense of what exactly should go into one.
6:45
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