Creating the Test Case

[MUSIC] 0:00 Welcome to stage two of intro to QA Engineering. 0:04 We're now going to be getting into the real work of testing by writing out manual 0:08 test cases. 0:13 These test cases can serve a lot of useful purposes. 0:15 In addition to simply testing what the developer has done, they can also provide 0:19 useful documentation for people learning how to code for the software. 0:23 They can also serve as a proof of work later down the road for 0:29 things like certification. 0:32 So it's important to write our test clearly and not just to 0:34 fill it with too much jargon that only our testers and coders would understand. 0:37 The very first thing we'll do is choose a name for our test. 0:42 We're gonna be testing a very simple part of the RSVP application, 0:47 the edit button for an invitee. 0:51 So when I click edit, a person's name can be edited. 0:54 And when I change the name, let's just put a 2 here, 0:59 I can click the save button and the name has been updated. 1:02 Pretty straightforward. 1:07 So I'm going to go over to our Test Case, and for the purposes of these videos we're 1:08 going to be using simple Word processors with just tables and spreadsheets. 1:12 So I'm going to be writing this just in Google Docs. 1:17 First let's name this test based on our feature, the Edit button. 1:20 I'll start by simply naming it Edit. 1:24 Now, Edit is probably one of the most commonly used terms in software, 1:27 up there with save and new, so I'd also like to indicate 1:31 where in the software I'm editing this, which is the invitee. 1:35 Eventually, I'd like to have a lot of tests that are fairly easy to find, so 1:38 I wanna put the major part of the feature first. 1:42 So now when I edit it, 1:46 I'm gonna actually going to add in Invitee to the beginning of that name. 1:46 And it will look like Invitee- Edit. 1:52 We'll probably create some other test cases, like Invitee- New and 1:55 Invitee- Delete later. 1:59 Okay, now let's add some steps. 2:01 Test step should be very atomic, or in another words you should do one thing and 2:03 then you expect something else to happen from that. 2:08 You also want to be very descriptive about what exactly should happen. 2:11 So I'm going to go back to the RSVP app page. 2:16 And I just wanna click the edit button, and 2:20 I expect the person's name to now be in an editable text box. 2:23 I'm going to go back to the test case, and then add this step as, 2:27 Click Edit under the first person. 2:31 Our expected results should be, Person's name is in a text box, done. 2:38 That's just one step. 2:47 But we need a few others to actually test out this feature. 2:48 The next step will be to test whether the text box is actually editable. 2:52 All we need to do here is change the name of the user to test that. 2:57 Our next step is then going to be, 3:00 Delete the person's name and type 'Test Person'. 3:03 Our expected result, 3:11 'Test Person' is now in the text box. 3:14 Great, so I wanna take an aside here because we're actually testing 3:20 out a lot of functionality with just that one step. 3:25 We're testing things like, can you delete the person's name or just add on to it? 3:29 How fast is the act of deleting and typing in a new name? 3:35 Does your cursor show up when you click the text box? 3:39 All these things could be called out in our expected results section or 3:42 even be just their own individual steps. 3:46 But we're not gonna do all that here because, one, 3:49 it would balloon the size of our tests. 3:52 And two, there's just some things that we assume the user knows, 3:55 even in the meticulous world of QA. 3:59 We like to call these assumptions, and if those assumptions are not obvious, 4:02 like our textbox example, they should get called out in the test case itself. 4:07 Let's add something simple, though, 4:14 just to make sure that there's no ambiguity in the test step. 4:15 Just to make sure we're not leaving too many assumptions up to the tester, 4:19 let's add click text box to the beginning of this step. 4:24 It's okay to have multiple things for the user to do in the test step as long as you 4:32 don't expect a lot of changes to validate between those things. 4:36 This also eliminates a potential assumption 4:40 should the text box be focused right after you click Edit. 4:42 If that was the case, we could probably add that to the expected result of step 1, 4:46 but that's actually not the expected behavior here, so we'll just move on. 4:51 So I'm gonna go back over the RSVP app and 4:54 then actually perform that step by entering in Test Person. 4:57 And I wanna save the name that I just entered. 5:02 When I click the save button, the name is saved, and 5:05 the edit box is no longer there. 5:08 So let's go back over to our test case and add that as our last step. 5:10 So for step 3, let's add, Click Save button. 5:14 And our expected result is that 'Test Person', Is now the invitee's name. 5:20 So this is an extremely simple test case, but it should give us some confidence 5:29 about testing whether the edit functionality is doing its job or not. 5:33 I mentioned earlier that test cases can make good documentation and proof of work. 5:39 And a good example of that is when you explicitly call out things in the test. 5:44 Like when I click edit, I don't expect the app to focus on the name, so 5:48 I could add that as one of the expected results for step one. 5:53 Instead I expect the user to click the name. 5:57 Someone asking later down the road about why this doesn't work the way they assumed 6:02 can be pointed to the test case. 6:07 If we wanna change that functionality, we will also need to edit the test case. 6:10 There's one more thing we're going to need to add to this test, 6:16 though, before it's complete. 6:19 We're making a pretty big assumption that when we load the application, 6:21 there's already a person there to edit. 6:27 But we don't really know if that's the case or not. 6:29 So let's say another test had me delete every invitee on the page. 6:32 Now when we get to the edit test, we don't have any data to work with. 6:37 That's not really a big deal on this particular case, but 6:41 I think any reasonable tester would assume they need to add a person to edit them. 6:44 But for more complicated applications where the data can be 6:48 much harder to set up, it may not be very obvious what steps need to be 6:51 taken to get the test ready to execute. 6:55 We're gonna go back over to the test case and 6:57 fix this by simply creating a setup step. 7:00 And all it's going to say is, 7:03 Delete all existing people. 7:08 Add invitee Jay McGavern. 7:13 This is a nice setup step because it works in any scenario the app is already in. 7:19 These are important things to remember, 7:24 especially if you're automating your tests. 7:26 Test data from previous tests can pretty easily muck up your application and 7:28 make it difficult to test. 7:32 As a final note, we should also probably tell our testers 7:34 to clean up their data before they move onto their next test. 7:37 This is called a teardown step. 7:41 So let's write our teardown step simply as, 7:43 Delete user 'Test Person,' which is the person we created during the test. 7:47 Remember that we renamed the user in the test. 7:55 In other applications it's probably better to use a unique ID of some kind. 7:58 And that's it for our test. 8:03 This is a very simple test case, but as you can see, a lot of care and 8:05 thought went into each step and what we were verifying specifically. 8:09 So as a recap, it's good to remember to name your tests both appropriately and 8:16 in a way that makes it easy to find them. 8:21 Your test steps should be atomic with one input and one output, and 8:24 always with clear things for the user to do, and clearly defined expected results. 8:29 Anything that can't clearly be assumed should be written down somewhere, 8:34 either as a note in the test itself, or as a clear step or expected result. 8:39 Also don't forget to list any Setup or Teardown steps 8:44 that help testers get the application in the right state before performing tests. 8:48 Thanks, and join me in the next video as we expand this test 8:54 to include some edge cases that we don't normally think of. 8:58