Creating a Test Plan6:50 with Ryan Saul
We have written our tests and now we need to start actually running these tests. In this video, we will discuss creating test plans.
Test Plan: RSVP App - Edit Invitee Feature Release
Verify edit invitee feature for RSVP app.
Regression test previous features.
1 hour to execute.
- Test results.
- Bug report.
- 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.
- TEST1: Invite Someone new
- TEST2: Confirm someone
- TEST3: Remove someone
- TEST4: Edit someone
[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 up