The Basic QA Process: Tests and Bugs6:13 with Ryan Saul
In this video, we'll describe the basic QA process.
- 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.
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 up