So let's go into more details on the duties of a software tester. So that's what we will cover here in module four, analyze and re requirements or user stories. So, system requirements is a description of a software system to be developed. It lays out functional and non functional requirements. And it may be may include a set of use cases that describes the user's interaction that the software must provide. So if I could go back to exercise one, exercise one for example, you're required to write requirements for their product or service.

What well in the role of software testing as I mentioned earlier, business analysts will meet with the end users meet with the business owners, and they will document those requirements. A tester would read those requirements in generate test ideas and test cases, as I mentioned mentioned earlier, and system requirements. Sometimes they could be somewhat technical, because they're describing how the system should perform. However, user stories, user stories is a tool used in Agile software development to capture description of a software feature from an end users perspective. Again, these are similar to requirements, however, is describing how the system should perform from a user's point of view. They're less technical, so they're explaining exactly what the system should do when a cut Customer interacts with it.

And again, a software tester reads these documents to help them to help them develop. Test deliverables like test cases to test ideas in an eight them when it's time for them to test the system out. Here is an example. Here's a picture of requirement. So this is a login functionality requirement. So Let's read it together.

Text fields are used to gather short text response from a user. text fields can also be used to gather numerical data. So here we have the login name textbox, as well as the password so let's see More about each field and how they should perform. So the login name and password are the two text fields that should be available on the login page. So this is the login page. Users should be able to log in as a member by providing members registered user ID and password requirements one dot one dot one states on successful member login member members homepage should be available with a welcome message Welcome to cyclos version enhance the version number.

The next will cry mistakes that when wrong user ID or password is provided. An error message should calm stating invalid login please try again. And then the Final requirements states that when empty user ID and passwords are provided in error message tocom login name is required and password is required. So here are some characteristics or some attributes for each field that's provided the login name that feel should accept a minimum of four characters in no more than 16 it is a mandatory field. So that means that something should be put in that field data is why and it except efa. In numerical characters only.

The password field the password field, the minimum field value is four and the maximum is 25. It is also 25 and athletes numerical in accepts ephah numerical characters only. So, based upon these requirements, that's come up with some test scenarios, or some test ideas on how we are going to test these two new fields, the login name field in the password field. Okay, so here's one test scenario on successful member login, this will be available when so when the user successfully log in the welcome page should appear. Welcome to cycles. So this is one test itself.

We would test the system out, put it in the correct username, login name, I'm sorry, in the correct password. And then we'll test the system and see when we put in the correct information and click submit that welcome welcome. psychos mess disappears. Okay, that's one test. Here's the second test. When the wrong username, user ID or password is provided, error message should calm and it should say invalid login.

Please try again. This is another test. So what you would do is put in incorrect username or password and test to make sure that that invalid login name message appears. And then finally, another test could be when either field is left blank, login name is required and password is required. So here in this system requirement, you've already the testers already been provided with at least three test scenarios. So Or call positive tests.

You're testing the system out based upon what the requirements states it should do. Now let's think of some things that we could do to break the system. Okay. Now for example here on successful member login, when a page should be excuse me, when the member name should be members homepage shut up should be available. The welcome page should appear on successful login. Now what we could do here in this case, we could put a, the correct username here and the login name and then we could put an invalid logging in, excuse me, we could put it in Allah pass for in this password field and see what happens.

We could also another thing that you could do, it states that each field should accept alpha numeric characters only. You could test the system out and put something else in there like special characters, and see how the system performs. So those are just some examples of test scenarios or in this to see a login functionality requirement. A tester would read these requirements and generate test ideas and test ideas or test data on how they could test the system out. These requirements would also help the tester come up with negative test scenarios and negative test scenarios are basically how something outside of the requirements, something that a tester would do to try to break the system. And test scenarios.

Here's just a formal definition of test scenarios. test scenario is the functionality that can be tested. It is also called test condition or test ideas. As a tester, you may be put into the users shoes and figure out the real world scenario and use cases of application under test. And this is really a great definition. At eight software tester takes on the role of the end user.

And so you come up with ideas in thinking like a user would. You're thinking of ideas in ways on how to test the system out based upon how eight in user test the system test cases, test cases to say a structured test script that describes how a functional feature should be tested. It includes test steps, expected results, precondition and post conditions. So let's take a look here. Here's an example of a test case. Now test cases samples may vary depending on the corporation that you work for.

However, all test cases must have these three components. There must be an Action column. There must be unexpected results. And in this example, right here is expected system response that is quite similar to expected results. It should also have an hour We'll call up. Or in this case, we have a pass fail, or comment column.

But the main components again, it should be at an action step, an Action column, expected results, or expected system response, followed by actual result column or pass fail comments. Here, let's review some other areas as some other parts of the test case. So you have the test case number. The system that you're testing, you're testing an ATM system designed by this would be the testers name, the person that wrote it the tests that created this test case. Also the test case, name itself, change pin, a subsystem, so the testing the ATM an ATM system that says system is the pin functionality, the date the test case was created. And you should also include a short description.

This lets one knows exactly what true testing. So in this case, they're testing the ATM change pin service of the change pan functionality. Here are some other components in this test case example. The preconditions. These are the things that must be done before you can execute this test case. So let's read.

The user has a valid ATM card and the user has access the ATM placing this ATM card into the machine. The current pin is 1234. And the system displays the main thing you all of these things must be in place before you can start with step one, so let's read step one. Click the change pin button. And what are the expected results of the expected system response? The system displays a message asking the user to enter the PIN.

Now if this occurs, what a tester would do is put pass in the column. If anything else outside of this occurs, say if another message appears, or a message doesn't appear at all. The tester would write fail. And then they would also write a comment explaining exactly what happened. Here's an example of test data. Enter 5555 this is test data that the tester would use in order to test the pin.

So again, let's cover the test case. recap. The test case, test case should always have an Action column, followed by expected system response or specfic system results, followed by the pass fail and comment column. Or you can have an actual column. You should also include the system that you're testing a subsystem, the testers name, the date the test case was created, and a short description of of the actual tests that will be performed, any preconditions should be also be listed. And now the key information that you should know test cases should be read very elementary.

And what I mean by that is anyone with little or no knowledge of that system that person should be able to execute this test case without any problems or with no questions it should be very simple to read and understand. And let me just briefly explain test execution. Once this test case is complete, it is generally is on like a document, or they are testing tools that one can create test cases in. But basically what a tester would do is take this test case and actually sit in front of a system in front of a computer, on this case the ATM machine, and they would follow these steps. Looking at each step, follow these steps and checking to make sure The system does exactly what it's supposed to do. And if anything else happens outside of that, they're gonna document and say that it failed.

And they're gonna write an actual comment explaining exactly what happened. And as I mentioned earlier, test data. In order to test some functionality out data test data is needed. So that's read here exactly what the stadium test data. test data is the data that is used in tests of a software system. In order to test the software application needs enter some data for testing, most of the features, any such specific pacifically identified data, which is used in test is known as test data.

Test data. Here the example is 5555. So when testing out that at The user or the tester is required to enter, enter these four numbers right here. And again, this is called test data.