Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Well done!
You have completed Introduction to QA Engineering!
You have completed Introduction to QA Engineering!
Preview
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