Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll

Introduction to QA Engineering

Well done!

You have completed Introduction to QA Engineering!

Sign up for Treehouse Back to Library
Preview
Video Player
00:00
00:00
00:00
  1. 2x 2x
  2. 1.75x 1.75x
  3. 1.5x 1.5x
  4. 1.25x 1.25x
  5. 1.1x 1.1x
  6. 1x 1x
  7. 0.75x 0.75x
  8. 0.5x 0.5x
Use Up/Down Arrow keys to increase or decrease volume.

The Basic QA Process: Tests and Bugs

6:13 with Ryan Saul

In this video, we'll describe the basic QA process.

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