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 this video, we'll describe the basic QA process.
Definitions:
- Test Case: The set of steps to perform that will attempt to prove if the software is running to our specification.
- Defect/Bug: A flaw in the software that must be fixed.
- Feature Request: Additional feature that someone wants included in the software.
When to run tests:
A test must be run at least once before the release of a feature, and may be run multiple times as defects are fixed and other features are introduced.
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
Okay, so after the acceptance criteria for
0:00
a feature has been defined,
a developer will take that and
0:03
begin working on the code for it,
and then check it into the project.
0:06
At this point, the team will want
someone to test that the feature works
0:11
as it is being developed,
and before it gets released.
0:15
That's where you come in.
0:19
We talked a lot about acceptance criteria,
because it's very important for this step.
0:21
We're gonna create a test case,
which is a series of steps to perform,
0:26
that will attempt to prove that the
software is running to our specification.
0:31
Mostly, the test case is there to see
if the new feature does what we said it
0:36
was going to do.
0:40
So our test case steps are mostly
evaluating the acceptance criteria
0:42
that was defined early on.
0:47
That's why it's so
important to be very specific and
0:49
ask lots of clarifying questions.
0:53
We can't test what we don't know.
0:56
Now, after we've written a test case,
we need to execute it.
0:59
This is basically running through each
step that we've written down as a test.
1:03
Test cases should really
be written in a way that's
1:07
not specific to whoever wrote it.
1:10
In other words,
1:12
I should be able to give this test
case to any other tester on my team.
1:13
And they should be able to execute it
without a lot of help from whoever
1:17
wrote it.
1:20
This will come in handy later when we
start running past tests on new releases.
1:21
But it's also important so people can
check your work, or verify what you did,
1:26
as well as being very clear
about what you're doing.
1:30
The test case is almost like
a journal of what was done
1:33
to make sure the software works.
1:36
Because we want to prove that
we didn't find any defects.
1:38
Defects are flaws in
the software that must be fixed.
1:41
If some of the steps in the test case
fail, or if the product does not act in
1:45
a way that we've defined somewhere,
then that defect needs to be fixed.
1:50
Defects are essentially what we're always
on the lookout for as QA engineers and
1:54
testers.
1:59
Defects are also called bugs.
2:00
Bugs are named after the days
when mainframe computers,
2:02
computers that would fill up literal
rooms, would generate lots of heat.
2:06
This heat would attract lots of moths and
flies to the room.
2:11
The little creatures would
get into the circuitry and
2:15
sometimes short circuit the hardware.
2:17
Causing huge problems that the computer
engineers would have to go inside and fix.
2:20
Obviously, the software wouldn't
work very well when this happened.
2:25
These problems were then deemed as bugs.
2:29
We want to spot these bugs
before our customers do.
2:32
Bugs that are in the release
product don't look very good.
2:36
And will probably lead to some unhappy
customers and angry support tickets.
2:39
We really don't want that, in fact,
2:44
it's the main reason we're
here as QA engineers.
2:47
Defects can often be a little tricky for
people to define.
2:51
It's really common to see
someone say that a bad font or
2:55
a bad color choice is a bug, but is it?
2:59
The answer is, maybe, but
use your best judgment here.
3:03
If the acceptance criteria left a lot up
to interpretation, then it's often kinda
3:07
hard to say that a developer's
choice was quote-unquote a defect.
3:12
In our RSVP app,
spacing a box 10 pixels further than
3:17
what the product designer
expected isn't really a defect.
3:22
It's just an oversight that
can be addressed later.
3:25
As long as it's not impacting
the user too negatively.
3:28
We usually call these feature requests,
because it's a new feature that others
3:31
are asking to put on top
of the current features.
3:36
But on the other hand,
defects could be from other areas.
3:39
If a developer leaves a color red on a
text box just to easily see where the box
3:42
showed up, but forgot to remove it later,
3:47
then you can probably
consider that a defect.
3:49
If the font chosen is completely
different from the single font
3:53
that we've chosen to use in
the rest of the RSVP app, and
3:56
nobody said we need to use this new font,
then that's also probably a defect.
4:00
Bugs will typically be reported
back to the development team and
4:05
get fixed before these new features
make it out in the release.
4:08
The software gets re-tested, and
the process continues until all or
4:12
at least most of these
defects have been fixed.
4:17
It's really important to make this
distinction between defect and
4:21
feature request.
4:25
Because we want the development process
to be fairly predictable and testable.
4:26
Adding requirements to the design late
in the development process creates
4:32
a lot of unneeded stress
on the development team.
4:37
Who are now probably scrambling to add
all these last-minute additions to
4:40
the product.
4:43
And we also wanna limit the amount
of testing that must be performed.
4:46
Testing takes a while to do properly, and
4:50
every time a defect is discovered,
these tests need to be re-run.
4:53
Generally, tests must be performed
at least once before the release of
4:58
a product.
5:02
But it's pretty common to
run them multiple times,
5:03
especially as other features, defects, and
fixes to those defects get introduced.
5:06
Once our tests have been run and bugs
have been fixed, we're ready to release.
5:12
At this point,
5:17
QA must be interested in customer
feedback to see what didn't get spotted.
5:18
Or maybe where customers might be looking
for when we're designing another feature.
5:23
This feedback loop is important to
assuring that the product is meeting
5:28
the needs and desires of our customers.
5:32
And that's it for the basic QA and
software development process.
5:35
We mostly touched on some
high-level notes here.
5:39
But we'll be getting into the details of
many of these things in the next stages.
5:42
In stage two, we'll be talking about
how to write manual test cases.
5:47
In stage three,
we'll cover executing those test cases.
5:52
In stage four, we'll be looking at how
to spot and report bugs or defects.
5:56
And finally, in stage five,
6:03
we'll be looking at how to improve quality
assurance practices in more detail.
6:05
Thanks for watching,
I'll see you in stage two.
6:10
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