[Music] hello everyone and Greece for the day welcome back to another tutorial on ist qb8 once test analyst we are in Chapter three and really still looking at the point two specification based techniques we'll be following with the new technique here called as use case testing we know that it is already being covered in the foundation we and lot a lot about this in the foundation levels labels so you can look up the card and click on that if you would like to know the basics quickly to revise about use case testing so let me just quickly recall the basic and fundamentals of use case testing which we have covered in the foundation useless testing generally provides a transactional scenario based test that would emulate intended use of the component or system specified by the use case so it generally represents interaction between the actor and the system which is being created or which the user is trying to use or actor here generally represents the human users or any kind of external hardware or the component of the system which would be emulating the activities on the product or the application use cases generally describe the interaction and are helpful to identify the defects related to interaction interfaces between the system and the different modules so that's where we are generally is helpful to derive the test cases for integration system and acceptance testing it's just not applicable for camp and in testing so let's quickly move into the advanced level that what kind of questions you can expect and how the typical way of asking the question will be prom the board so let's look at one of the sample question here right now on the screen we have got a scenario here with us which is all about easy travel card reloading or loading certain amount on the easy travel card and quickly let me tell you what is easy travel it is just like a metro card or maybe a bus transit or bus transfer cards so generally making many you make use of smart cards and you try to load certain money to use at further for your travel so the scenarios will be always user friendly so that you would have work done at one another way or probably you would be knowing about it which will be us in the examination so here if you look at the cushion first of all it says easy travel is a card which is used to paying journeys on the buses and underground which means metros the user can store credit to the card at the easy travel loading machines and system automatically deduct the fee of the journey while the user shows the card to the card reader on a bus or at underground stations you are working on the easy travel system maintenance project and the following use case has been given to you for reviewing use case add to easy travel balance from credit card ID a use case ID as you see 2-0 want to return something and prefers is user is increasing the balance on their easy travel card and the actors or users and system now look at your right we have got the main scenario being elaborated to you so if you can quickly recall the point from the foundation we always have one successful path which will be the main part about the particular scenario so whatever our steps is involved between the user and the system to finally load the amount to the screen so I'll quickly read this for you here so first of all the user tries to place the card on the reading plate system responds with few options like a query card balance or add to balance or the card so whenever you see use cases generally one use case will always have one main thought if there are several other options for any of the parameter then it will be covered in the different use case so it will be mark that this part of it will be covered in a different use case so query card balance is not a part of the scenario so we have specified a separate use case then what if the user selects add to balanced and we continue further like user chooses add balance system ask the amount you mentioned around system asks what kind of payment method are you using so again there are two or for that like cash cash or credit card so cash is a separate use-case credit card is what we are looking into the scenario user selects the credit card goes into the credit card slot and inserts the credit card enters the amount to be charged user confirms and then so on and finally removes the card and then the system returns to the main menu also to notice that it will be in a sequential activity like 1 2 3 4 that means it's a sequential operation which happens between user in the system another thing which is being marked here is e1 and e2 so e are basically to represent the exceptions where maybe a system can reject your operation or maybe the activity which you're performing so when you say e1 you can read at the bottom what are the exceptions all about so user can stop the process by review removing the eztravel card from the reading plate till step 8 so till 8 step number 8 E 1 is possible that you can remove the card and you don't want to continue with the process but once you have inserted the credit card there's another exception called as II do which means if the user does not accept the amount to be charged that means it maybe you do not probably enter your PIN or you do not want to be charged for that you can also terminate the process that's e 2 because this is a different case so you already been into the transaction now your credit card has to be valid or any other thing so all these information will be provided to you in the cushion now let's come back to the scenario precondition user must have easy travel card and a credit card end-user is your true card must be added with the balance now what they want to know is how many test cases are required to achieve the minimum coverage for this use case now it's very simple and easy to understand now one of the thing will be the main part successful positive test case so right from one to step 15 you will be operating one successful transaction and you call it as one case one test case other five will be here with the e ones which are marked like II 1 e 1 ID step for a one at step six and E one at eight and then e 2 at so if you see we have got five exceptions here so that has to be tested in terms of negative that if the person removes the card does the transaction terminate or not so we will have altogether six test cases as the right answer so one for the successful part and one for the exceptions one and another for exception two so we have four exception one so for test cases and plus one for eg so total six test cases now if you are wondering about what about the separate use case of course those will be the different use cases and you would have different set of test cases for that so each use case is identified with a unique ID and we probably always look for precisely testing each one of them separately so that's all from this particular tutorial team I think that was quite clear and easy to understand about use cases testing here and how to derive the test cases for used cases should you have any further queries feel free to comment below I'll be there to address your queries and we'll be able to elaborate further if you need any help till then keep learning keep exploring keep understanding the context about this topic thanks for watching the video team and happy learning