Hello there. It’s time for testing training and this is Inder P Singh on today’s class, which is How to write effective test cases quickly? If you have been assigned the task of writing test cases, then you may have certain worries that it may take you a long time and effort to write those test cases. Then you may be worried about… Whether when the test cases you write are read by others, they will be able to understand your test cases or not? And if they’re going to have problems in running your test cases and also, you would like your test cases to be easily updated whenever there are certain changes that you need to implement in them. Well, we can do all that. So, the question we are asking today is how to write test cases quickly so that they are easy to write, easy to understand by you when you read your own test cases after a duration of time or by others (other than the author of the test case), easy to execute, also have the minimum number of steps and also fast to execute, easy to maintain (easy to change whenever there are some desired changes you want to make in your test cases) and have less number of mistakes. So with this introduction, let us look at an ordinary test case how it is written. So, here is an example of a test case that has been written to test the login functionality of a system. Now in the first column, we have the Step numbers 1), 2) and 3) and 1 is the Test Case ID. Then in the Steps column (the second column), we have all the steps. And then the third column is the Expected Results column, where we have the expected result for every step. So, let us go to step number 1) so in order to check whether the login functionality of the application is working correctly or not, what the tester has done is they have written a step – Enter a valid username and valid password and Click on the login button. So, this is an example of a positive test. By positive I mean, that the correct inputs are given to the system and the system has to give the correct output, which is the expectation and exactly that we can see in the Expected Results against this particular step. It says the application should display the home page. Now after the first step is executed, what the tester now wants is to give negative inputs. That means it is a negative test. Some or all of the inputs are going to be incorrect and basically, the application should error out or provide some kind of feedback to the user, saying that the inputs are incorrect and they need to re-do their operation. So, the step here is log out of the application, enter a valid username, but an invalid password. So here, the inputs are partially Incorrect, so this is a negative test. So, if the valid username but an invalid password is given and the login button is clicked, then the application will not work. It will not give the correct result of showing the home page. Instead, the expected result here is the application should display an error message and re-open the login page. Basically, the application should say that you have provided incorrect inputs and asked the user to perform the login operation once again. Then in step 3)… This is another example of a negative test, but here all the inputs are incorrect. So, it says log out. Then enter an invalid username and an invalid password. So, make sure the user is logged out of the application. Then enter a username which is invalid and a password which is invalid, meaning that a username that does not exist in the application data store and a password that does not exist in the application data store and click on the login button. Here since it is a negative test, the application will not proceed as expected, but the expected result says the application should display an error message and re-open the login page. Basically, the same expected result that is there in Step 2). Now, there are some problems with this ordinary test case. Well, what are the problems? Well, the first problem is that there is a lot of text over here. So, first it’s a positive test and that is fine and then a lot of typing has been used to describe what kind of negative input is to be given and there is a duplicity also. The same Expected Result is copied from Step 2) to Step 3). And also, if you notice carefully, this does not test all the negative combinations. For example, it DOES test for valid username and valid password. How about not giving a username and not giving a password and just clicking on the login button? Well, that is not covered here. Then an invalid username and a valid password. That means a username that does not exist in the application data store but a password that does. That combination is not there. So, this is an example where the tester has compromised. Well, they have covered some testing, in the sense that they have both positive tests and negative tests. But all the possible combinations which the real users of the application may give, those are NOT tested over here and also, it takes a lot of time to write because there is a lot of text over here. So, what is the solution??? Well, in order to tell you the solution, I need to re-write this test case and this is what I have written. So, the Test Case ID 2 is the same test case as Test Case ID 1. But it has been written differently. Now how I mean it is written differently? Well, it has the different steps over here and you can see that the very first step says, Verify the following username and password combinations. And there is a legend, which says V means valid and I means invalid. And in the Expected Results, it says E means an error message and H means the home page. Now, since there is just one step and it asks to verify all the combinations, now very little typing is involved. So if you write your test cases like this, you will end up spending much less effort in typing out the text of the test case. So here there are multiple combinations. So as we can see, first the username is blank and the password is blank. And the expected result is E which means that the application should display an error message. Then it is blank and, I which means user name is blank but and the password is invalid (some invalid password), which does not exist in the application data store. Again, there is an error message. Then it is a blank username and a valid password (one of the existing passwords in the application). But again, the expected result is an error message and so on and so forth. It tests all the combinations and also in the end, it does a positive test. It gives a valid username and valid password and here the application displays the home page. Now, if you notice the differences between Test Case 1 and 2, Test Case 1 is the ordinary test case which took longer time to write and also, the coverage of the test case was not as good as the Test Case 2. Test Case 2 is faster to write (it required less effort in typing out the Steps and the Expected Results. It is very easy to understand because here instead of text, we are mentioning 1.1) blank, blank, 1.2) blank, invalid, 1.3) blank, valid. Then, 1.5) invalid, invalid, 1.6) invalid, valid. It is very easy to understand. It is also fast to execute because when at the time of execution or at the time of running the test case, the tester need not read long sentences and try to understand their meaning and then to do those steps in the application. It is also very easy to update. So, let us say that it is not possible to give a blank username and blank password. It will not allow the user to click on the login button because the login button is disabled in case the username and password fields both are blank. Then you can just delete this particular step. So, it is easy to update also. And because it has been written in a systematic fashion, chances of mistakes are less. Unlike the ordinary Test Case 1, where there is a lot of text and chances of mistakes are very high, unless someone spends a lot of effort in going through the entire Steps and the Expected Results and make sure everything is correct. S,o this is how you write test cases quickly and you get the additional benefit that your test cases are more effective. They are easier to write. They are easier to understand. They are faster to execute, easier to update. So, not only you can write test cases in less effort, but you get the other advantages also. Now just one explanation about the combinations over here… Now as you can see, there are in the test design there are 3 possible values for the username and again 3 possible values for the password. By 3 possible values of the username, I mean it can either be blank (which means no user name is specified) or it can be an invalid username (which does not exist in the application) or it can be a valid user name. So, there are three possible values for username and there are three possible values for the password. So, 3 * 3 is 9. And 9 is the number of combinations. So if you look closely, here it is blank and blank. Then, the value of blank username continues over here for 3 times and the password iterates it’s values (blank, invalid, valid). Then again, the value of invalid username continues for 3 times and again we iterate or means we run the values of password which are blank, invalid and valid. And again, we have the value V for the username (which means it is a valid value) and again we put the same 3 different values in the same order. So this way, you can have 3 * 3=9 combinations. So all possibilities of blank, invalid and valid username and blank, invalid and valid password are given over here. So, this is how you can write more effective test cases much more quickly and also get very good side effects. That your test cases are easy to understand. They are easy to execute, easy to update and also have much less mistakes then if you write the test cases in the normal fashion. So, I recommend that you use this particular approach to cut down on your effort (your time) of writing the test cases because test cases are written before testing is executed in many cases because they serve as a guide. They serve as a record of what actually was tested. And also, they help to aid the memory later on. If you just want to refer what you tested a couple of months ago, then you can just refer to those executed test cases at that time and then you can remember what exactly was tested. So in many cases, test cases are written. It is not always exploratory testing. So, whenever you are writing test cases, follow these approaches and you will be able to write your test cases faster and much more effectively. Now, let us take a moment to recap what we have learned. So, how to write test cases effective test cases quickly so that they are easy to write, easy to understand, easy to run easy to change, and have less mistakes? The solution lies in using tables in the test case, so that you spend your effort and your intelligence in designing the different tests, not in the actual typing of the text. Typing of the text is not very beneficial activity you’d better are spent the same time and your intellectual capabilities in designing the different interesting tests that are likely to throw up bugs in the application. Another thing you can do is instead of copying text from other requirements (such as requirements documentation), you can simply refer to those IDs in the other documents, so that is going to save you time because instead of copying the text, then copying and pasting text in your test case takes some time. So instead of doing that operation, simply refer the other ID and the document name and it also serves you another indirect purpose. Whenever the source document changes, so let us say something changes in the source document, you need not update the text within your test case. Because you are simply referring to the source document. So even if the source document something changes, because you are referring to it, you need not do any updates in your already written test cases. Always keep in mind that you need to declutter your test cases. If you try to declutter your test cases by using all these recommendations (by using tables, by writing very little text and referring other documents etc.), you will find that you are able to write effective test cases which have better coverage, interesting test design, and you will be able to write your test cases quickly. Well, that is all for this video. If you liked this video, make sure that you give a Like or Share it using social media. And also subscribe to the channel, Software and Testing Training. So, that is all for today and see you next time. Thank you.