[MUSIC]

Welcome to stage two of intro to QA Engineering.

We're now going to be getting into the real work of testing by writing out manual

test cases.

These test cases can serve a lot of useful purposes.

In addition to simply testing what the developer has done, they can also provide

useful documentation for people learning how to code for the software.

They can also serve as a proof of work later down the road for

things like certification.

So it's important to write our test clearly and not just to

fill it with too much jargon that only our testers and coders would understand.

The very first thing we'll do is choose a name for our test.

We're gonna be testing a very simple part of the RSVP application,

the edit button for an invitee.

So when I click edit, a person's name can be edited.

And when I change the name, let's just put a 2 here,

I can click the save button and the name has been updated.

Pretty straightforward.

So I'm going to go over to our Test Case, and for the purposes of these videos we're

going to be using simple Word processors with just tables and spreadsheets.

So I'm going to be writing this just in Google Docs.

First let's name this test based on our feature, the Edit button.

I'll start by simply naming it Edit.

Now, Edit is probably one of the most commonly used terms in software,

up there with save and new, so I'd also like to indicate

where in the software I'm editing this, which is the invitee.

Eventually, I'd like to have a lot of tests that are fairly easy to find, so

I wanna put the major part of the feature first.

So now when I edit it,

I'm gonna actually going to add in Invitee to the beginning of that name.

And it will look like Invitee- Edit.

We'll probably create some other test cases, like Invitee- New and

Invitee- Delete later.

Okay, now let's add some steps.

Test step should be very atomic, or in another words you should do one thing and

then you expect something else to happen from that.

You also want to be very descriptive about what exactly should happen.

So I'm going to go back to the RSVP app page.

And I just wanna click the edit button, and

I expect the person's name to now be in an editable text box.

I'm going to go back to the test case, and then add this step as,

Click Edit under the first person.

Our expected results should be, Person's name is in a text box, done.

That's just one step.

But we need a few others to actually test out this feature.

The next step will be to test whether the text box is actually editable.

All we need to do here is change the name of the user to test that.

Our next step is then going to be,

Delete the person's name and type 'Test Person'.

Our expected result,

'Test Person' is now in the text box.

Great, so I wanna take an aside here because we're actually testing

out a lot of functionality with just that one step.

We're testing things like, can you delete the person's name or just add on to it?

How fast is the act of deleting and typing in a new name?

Does your cursor show up when you click the text box?

All these things could be called out in our expected results section or

even be just their own individual steps.

But we're not gonna do all that here because, one,

it would balloon the size of our tests.

And two, there's just some things that we assume the user knows,

even in the meticulous world of QA.

We like to call these assumptions, and if those assumptions are not obvious,

like our textbox example, they should get called out in the test case itself.

Let's add something simple, though,

just to make sure that there's no ambiguity in the test step.

Just to make sure we're not leaving too many assumptions up to the tester,

let's add click text box to the beginning of this step.

It's okay to have multiple things for the user to do in the test step as long as you

don't expect a lot of changes to validate between those things.

This also eliminates a potential assumption

should the text box be focused right after you click Edit.

If that was the case, we could probably add that to the expected result of step 1,

but that's actually not the expected behavior here, so we'll just move on.

So I'm gonna go back over the RSVP app and

then actually perform that step by entering in Test Person.

And I wanna save the name that I just entered.

When I click the save button, the name is saved, and

the edit box is no longer there.

So let's go back over to our test case and add that as our last step.

So for step 3, let's add, Click Save button.

And our expected result is that 'Test Person', Is now the invitee's name.

So this is an extremely simple test case, but it should give us some confidence

about testing whether the edit functionality is doing its job or not.

I mentioned earlier that test cases can make good documentation and proof of work.

And a good example of that is when you explicitly call out things in the test.

Like when I click edit, I don't expect the app to focus on the name, so

I could add that as one of the expected results for step one.

Instead I expect the user to click the name.

Someone asking later down the road about why this doesn't work the way they assumed

can be pointed to the test case.

If we wanna change that functionality, we will also need to edit the test case.

There's one more thing we're going to need to add to this test,

though, before it's complete.

We're making a pretty big assumption that when we load the application,

there's already a person there to edit.

But we don't really know if that's the case or not.

So let's say another test had me delete every invitee on the page.

Now when we get to the edit test, we don't have any data to work with.

That's not really a big deal on this particular case, but

I think any reasonable tester would assume they need to add a person to edit them.

But for more complicated applications where the data can be

much harder to set up, it may not be very obvious what steps need to be

taken to get the test ready to execute.

We're gonna go back over to the test case and

fix this by simply creating a setup step.

And all it's going to say is,

Delete all existing people.

Add invitee Jay McGavern.

This is a nice setup step because it works in any scenario the app is already in.

These are important things to remember,

especially if you're automating your tests.

Test data from previous tests can pretty easily muck up your application and

make it difficult to test.

As a final note, we should also probably tell our testers

to clean up their data before they move onto their next test.

This is called a teardown step.

So let's write our teardown step simply as,

Delete user 'Test Person,' which is the person we created during the test.

Remember that we renamed the user in the test.

In other applications it's probably better to use a unique ID of some kind.

And that's it for our test.

This is a very simple test case, but as you can see, a lot of care and

thought went into each step and what we were verifying specifically.

So as a recap, it's good to remember to name your tests both appropriately and

in a way that makes it easy to find them.

Your test steps should be atomic with one input and one output, and

always with clear things for the user to do, and clearly defined expected results.

Anything that can't clearly be assumed should be written down somewhere,

either as a note in the test itself, or as a clear step or expected result.

Also don't forget to list any Setup or Teardown steps

that help testers get the application in the right state before performing tests.

Thanks, and join me in the next video as we expand this test

to include some edge cases that we don't normally think of.