Hello and welcome to Module Two. And this module I will discuss test cases and test scenarios and how to create them both. So, what is a test case? Well, a test case is a set of test inputs, execution conditions, unexpected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. The language a test case should be very simple and easy to understand someone with little or no knowledge of that system or the functionality should be able to understand the test case. So, what are the characteristics of a good test case?

It should be very simple as I mentioned, it should be treated traceable to a particular requirement. A test case should be repeatable and reusable. It should also have a unique name assigned to it. There are different types of test cases. Here I've listed just a couple. You have a functionality test case and functionality test cases use to discover if an application and interface work with the rest of the system in its users.

Generally, the author of the functionality test case is the is a software tester. Then you have the user interface test case. And these test cases are used to verify the Pacific piece of the graphical user interface. That is the GUI and how it looks and how it should perform. So take forever Example, you have a textbox on an application. And that text box the requirement states that it's it should accept only fo characters, while tester would test that form out of that field out to make sure that that field except on the efa characters.

And here's just some more information on a GUI test case. They can be used to identify cosmetics and consistency, grammar and spelling errors, links in other elements that the user interacts with or sees. And they're also generally written by the software testing team. However, sometimes there might be a design team that will create a user interface or GUI test case. Here's just an example of a test case. Let's review just some of the fields.

The system that will be tested here in this test case, they're testing the ATM system. They also have the subsystem that they're testing. They're testing the pin functionality. We have a short description here. They're testing the ATM change pin service. We have some preconditions.

So before this test case is executed, there are some things that must take place prior to executing this test case. So here's just three of them that are listed. The user has a valid ATM card. The user has access to ATM by placing his ATM card in the machine. The current pin, it's 123 form. And this system displays the main menu.

So again, these are some preconditions. Here are the steps, as well as that what as well as the actions that should be performed what the expected results are. So after a user or a tester enters the excuse me, clicks that change pin button. The system should display a message asking the user to enter the PIN. If anything else outside of this happens, this test case will fail. There's also a pass and fail column as well as a comment column.

So let's discuss test scenario. test scenarios and what they are. test scenarios is a functionality That can be tested. It is also called a test condition or test idea. As a tester, you may put yourself into the in users shoes and figure out the rear row scenario and use case of the application that's under test. So say for example, you're testing the the ATM pin functionality, and the system requirements states that the ATM pin accepts.

For numeric characters. As a tester, you want to come up with several ideas on how to test it ATM pin functionality. The requirements stated that it accepts only four numeric characters. So one of the test you could conduct is testing the system to ensure that accepts only four numeric characters. You can also come up with another test. Another test would be to try the test ATM pin with more than four numeric characters.

And another scenario. Another test idea would be is to try to test this system to see if it would accept three numeric characters. And again, these are just some examples of test scenarios and test ideas to test out the ATM functionality. Here as you can see on your screen here is a copy of a system requirements specification. For an application that is called cyclos. This demonstration, you will see exactly what a software tester does.

Software tester read and analyze requirements. They then generate test scenarios and test cases. On the right hand side of the screen is actually a an example of some scenario test scenarios that I will review later on. So let's move forward reviewing the cyclo system specifications. So what I'm doing right now I'm going to just scroll down to the functionality that we will be testing. And that is the login functionality requirement.

That is requirement number one. So let's grow down to that requirement. And here's just some information about the cyclos website. And I'm just moving forward to access the website. Here is the URL and I'll just make a copy. Have it because we will log on to it later on.

And let me scroll down. So here requirement number one is the login functionality requirement. Here's a screenshot of the landing page, the homepage or the cyclos. application. And for this exercise, we will write test scenarios and test cases for these requirements below. Requirements one dot one dot one, dot two, and dot three.

So let's review and requirement one dot one dot one for this system login page. When a user logs in, successfully, they should receive a message stating Welcome to cyclos version. That other that And then requirement number two. When a user enters in invalid error message excuse me, when a user enters the wrong login name, or password, they will receive a message stating the given login name or password is incorrect, please try again. And dot three, the user will receive another message. When the login name or the password fields are left blank.

The message that they will receive is the action couldn't be could be processed, as there was a validation error. login name is required or the password is required. here's just some more additional information about just some of the fields the mandatory fields for that log in those login fields. So you have the login name In the password here, these both have mandatory fields, the minimum data field value that's required for the login name field is for the maximum amount is 16. And that fields should only accept alpha and numeric characters. The password field, the minimum value, except it is for the maximum is 25.

And this is also a mandatory field. So I'm gonna move the screen over here just a little bit more. And as you can see the requirements. There's some more information about this new user registration functionality. The name, the login name, the email address, these are all mandatory fields. These These are some additional fields that are on that new user for the minute user by stration it is mandatory that this checkbox I will agree with the above registration agreement, that box must be checked.

Along with this visual validation information that information must be entered in this new code field before clicking Submit. And here's some additional information about the new user registration functionality. The tester would read this information as well to assist them or running their tests in areas such as gonna scroll down here a little more. In here some more information about the of the fields associated with the new user registration. The mobile phone field, no information is required. This is not a mandatory field as you can see in a submission Some additional information about the new user registration.

So let's move over to this decision table. And the decision table is a technique that a tester can use to aid them in creating test scenarios and coming up with test ideas. And as you learned earlier in the system requirements, the the name, the login name and email address, as well as the password Confirm Password. I agree with above registration checkbox, and the new code, text box these are all mandatory fields. So in the decision table, what a tester will do is create this table lists all of these field names and in this scenario one here. Why means yes, yes.

The value valid value is entered into that field and the login, the same thing, as well as the email address. So, and once the user clicks the Submit Submit button, they should receive two things, they should receive the message stating that thank you for registering, we're gonna put yes right here. And then they should also receive a validation message in their email, informing them for some additional steps or additional things that they should do before they log in. Next, we are going to test the second scenario. And if I can go back over here to the system requirements, and, and our requirements one that one that too. We're going to create a scenario for this one and that one, when they wrong name or password is provided, they should receive an error message.

So we're going to test that feature out as well. And so here we put in a valid name. And in the login name, we're going to put in the wrong name and the login name field. The email address is correct. Now what should happen here, the user should not receive thank you for registering because they put in invalid information into that login name field as the system requirements stated. And then here in the email address feel they're not going to receive an email address email, I'm sorry, because they put in incorrect information.

However, they will receive a message informing, informing them that that login name and their password is incorrect. Please try. So here, the answer should be yes or yes should appear in this box. Next, we're going to test the three functionality in this one, it states that when those fields are left blank, another message should appear. So here in test scenario three, this time, we're going to leave that field blank, the login name field. And instead of receiving this error message that the information is incorrect, the user should receive or the tester should receive another message and then messages state, the action could not be proceeded as there was the validation error, the login name and or the password is required.

And here we're going to answer yes. So After the tester has created all of their scenarios, they're going to convert those scenarios into test cases. Now, as you can see here, there are some additional scenarios that a tester could create. To test this functionality out. They could come up with some other scenarios where the email address is left blank. But for time, we're just going to test these three requirements here.

So let's move on to the test case. And the test case, the test case name is new user registration. The subsystem, the system is by close and the subsystem is the new user registration. So the name of the test case is News, New User Registration and the system we're testing Is the site close New User Registration? So what is the purpose of this test, but the purpose of this test is to test the login functionality to ensure that it's functioning as designed. You could put something similar to this or you can put that you're testing to make sure that the new user functionality function is designed.

You also want to put the author's name and in this example, I put my name, the date that test case was created, and any preconditions anything that the tester should do before they can execute these steps. That information should go on the test case. And in this case, we have just one. And basically, the user must be the tester should be on the cyclos homepage or the landing page before they can execute step one. Now let's go to the actual test case. This test case right here, this is the first test.

And if you recall, we created three scenarios. So this test ID, and this one represents the first test. Then we have a step step one. And if you recall, in the definition of test cases, we stated that a test case that language should be very simple. So which means anyone with a little of no knowledge of the cyclos application, this person should be able to pick this test case up and execute the steps. And so let's review the action the first step, click on the register link, located in the upper right hand corner of the cycles homepage.

This is just a step. They expect the results so after that user clicks that link The expected results the states that the new user registration page should appear. appears not should appears. The second step that you should enter some information and in this case, we're entering tests green into the name textbox. What should happen after you enter that test green appears in the name textbox. So basically, you have an action and then in this specter results, you're then listing what should happen after that action.

And I'll just scroll on down a little bit further here. And in the final step, after they've entered all the mandatory information, and click the submit button, let's go to step number nine they click the submit button. That Thank you message should appear. Then next, the tester will log in to the email account. They've logged in successfully, and they should have the email address an email from cyclos. they log in and take steps from there.

He here is the second test case that we created a test scenario and in this test, if you recall, we're going to put some invalid data into their login name field. Now, the login based upon the system requirement, it states that the login name, the minimum value is four, but as you can see here we have three and what should happen when they click submit that error message should appear At final test case, we did the same thing. But in Step three, instead of putting invalid test data, we left those that field blank and then message. The message that appeared stated that the action couldn't proceed, because there was validation error login name error and our password is required.