How To Write A Test Case? | Test Case In Software Testing | Software Testing Tutorial | Edureka

[Music] hey guys Amer China from Ed Eureka and a welcome you all to this session on test cases in software testing so without any delay let's go ahead and take a look at the topics which we will be talking about in this session so we will begin by discussing why documentation is really important in software testing then we will start with our today's topic which is test cases we will take a look at what test cases are why do we need their format of it as case and how to write a good test case in software testing and finally we will end this session by writing a simple test case on a bank website so I hope agenda was clear to you guys let's get started this the primary objective of any software project is to get a high quality product while reducing the cost and the time required for completing the project and to do that companies most of the time need to test their software before it actually goes out the door software testing over time has evolved as an important domain and computer science software testing basically is the process of executing the software or in any kind of application to find out if there are any bugs or errors in it before software actually goes public programmers spend hovers trying to iron out every little bug there is in an application or software they check for any mistakes or problem in the design and the functionality of the software until then the product won't be available for commercial use in the market finding out bugs can be lot of fun and it's not only for testers but it's also for everyone who wants their application to be bug free today's tester has a very high demand in IT market while according to recent reports companies contribute about 25% budget to software testing and by 2025 it might be around 33% so you get the point right the demand for testers is really high well that's out of way now let me ask you guys a question is documentation really necessary in software testing what do you think yes it is documentation plays a very important role in software testing either it can be manual testing or automation testing here's an example to convince you people well a company let's call it ABC had delivered a project and the project had unknown issue that delivered this project to one of its client let's say a very angry client and they found out the issue at slide site which became a very bad situation for the company and as usual all the blame was put on on quality analyst of the company the issue was something regarding the compatibility of one website well when this issue was taken to higher authorities they showed the client a written proof of not receiving any requirement asking to check the compatibility of the website so the issue was resolved very peacefully in a way documented requirements save the company from getting sued and that's our documentation comes handy now if you are asked to write the test case would you know what to do or what that is what Odetta script or a test scenario be the first step is learning what these terms are each of this dawn implies a different level of detail and documentation and is used for a different purpose once a tester knows what each of this terms mean they can figure out how to use them to describe the testing that they're doing on a daily basis so let's get started then the story actually begins with most detailed way to document testing which is the test script it is a line-by-line description of all the actions and the data needed to perform a test a script typically has steps that try to fully describe how to use the program like which button to press or in which order to carry out a particular action in the program as such sometimes they also include specific results that are expected for each step for example an example step might be click the X button and for that step example result would be the window closes so that's what test script is it's detailed way of documenting what you're actually doing during or after off before the testing the second most detailed way of documenting testing work is to use test cases test cases describe a specific idea that is to be tested without the detailed steps which are actually specified in test clips for example a test case might say test that discount codes can be applied on top of a sale price this doesn't mention how to apply the code or whether there are multiple ways to apply the code will the tester use a link to apply a discount or enter a code or have a customer service app that apply the discount it doesn't matter test cases give flexibility to the tester to decide exactly how they want to complete the test in a bar from test script and test cases we have least detailed type of documentation which is test scenario a test scenario is a description of a knob active a user might face when using the program an example might be test that user can successfully log out by closing the program just based on that light description tester might choose to close the program through the menu option kill it through the task manager turn the computer off or see what happens when the program runs out of memory and crashes since test scenarios of a little information on how to complete the testing they offer the maximum amount of flexibility to the tester who is responsible for testing so guys well these are three ways of documenting what you're actually doing before or after testing apart from these there are other types of documentation but as for today's session we are going to concentrate on test cases the primary goal of a test case is to ensure where the different features within an application are working as expected under the given conditions or not it helps validate a software is free of defects and if it is working as per the expectations of end-users the activity of writing test cases help you to think through the details and ensures you're approaching the test from as many angles as you possibly can so basically test cases ensure good test coverage which is really a key functionality when it comes to testing it improves the quality of the software and decreases the maintenance and software support costs it allows the testers to think through different ways of validating features as in as a tester you will have the option to think from different angles and in test cases you can light test cases for negative test data as well which is often overlooked most of the time and these test cases are reusable for future and even can reference them and execute the test and they also help you to verify that the software meets then use acquirements and the end user or a customer is really happy about your product or an application so guys these are few reasons why test cases are extremely visible in software testing test cases are powerful artifacts that are beneficial to future teammates as well as a good source of truth for how a system and particular feature should work however before we dive into the lessons for writing top-notch test cases let us have a basic idea on the terminologies associated with them so the primary ingredients of a test case are an ID description bunch of inputs few actionable steps as well as expected and actual results let's learn what each of these terms mean first you have test case name the first step for writing an effective test case is giving it a name or a title that is self-explanatory as a best practice it's good to name the test case along the same lines as the models that you're actually testing for example suppose you are testing a login page title can be something like login page if the tool you're using doesn't already do this it might make sense to include a unique identifier instead of a long title so what I'm saying is that instead of using the test case name you can actually use an ID for the test case as well and make sure the ID is unique for each test case but if you are using a title or a name it should be self-explanatory so one look at the title name any person who is looking at it should get to know what you're actually testing on so moving on to next parameter it is test case description the description should tell the tester what they are going to test sometimes this session might also include other information such as test environment test data preconditions assumptions and all that a description should be easy to read and immediately communicate the high level goal of the test it should not be lengthy right so if it's actually very lengthy nobody is gonna look at it it should be in such a way that it should be very small and one look at it the reader will know what it is actually about so crisp that's the word I'm looking for so the next parameter is preconditions you should include any assumptions that apply to the test or any kind of preconditions that must make bet prior to the test being executed dwell this information can include which page the user should start the test on dependencies on the test environment and any special set of requirements that must be done before you actually start the test this information also helps test keep the test tips short and concise for instance in our agon example the assumptions and prerequisite can be the user is logged in and already has a valid yahoo.com email address along with the password and as for the Assumption it could be the user is trying to access yahoo.com on a supported web browser so anything that you want to actually mention before you actually start testing you can do it in this preconditions the next one is actually the test case steps the test steps should include the necessary data and information on how to execute the test this is perhaps the most important part of a test case it is important to keep the steps clear and brief without leaving any essential details in case the step is difficult to navigate having relevant artifacts like screenshots or some sort of comments can be very helpful and next comes test data testing for every data permutation and combination is really challenging and literally impossible hence it becomes important to select a dataset that gives you a sufficient coverage so select a data set that's specified not just the positive scenarios but negative as well so this way you cover all Ron possibilities then you have expected result the expected result tells the desktop what they should experience as a result of test steps it helps the tester determine if the test case passed or failed then comes the actual result actual result column in the test case specifies how the application actually behaved while test cases were being executed if the actual and expected results are the same it means that your test case was successful and be sure if your test case for successful or not you can actually add one more parameter like status of the test case well I haven't shown it your but you can go ahead and add it and finally you have something called comments any useful information such as screenshots the tester can provide to developers or some sort of instructions can be included in this comment part so guys this is the typical format the testers follow in the write a test case along with these elements testers can include additional parameters like test case priority type of test case like is it a positive test case or a negative test case or if you have lot of bugs you naturally design NID separate for each puck so we have another parameter like bug idea not so this is not a fixed format it depends on the tester but basically every test case usually includes these parameters plus additional sum so now that you know about the basic format or how to represent a test case let's go ahead and look at different techniques that you can use to write the test cases a good test case design technique is really crucial to improving the quality of the software testing process it helps to improve the overall quality and effectiveness of the release software or an application the test case design techniques are broadly classified into three major categories which are specification based or blackbox test then you have structure based and finally you have something called experience based so let's look at each of them in more detail specification based or blackbox test case design techniques are usually used to design test cases in a systematic manner they use external description of the software such as technical specifications design details clients requirement and more to derive the test cases with the assistance of these test case design techniques testers are able to develop test cases that save time and allow full test coverage and under specification based or blackbox techniques you have five more types let's look at them later moving on to our next major category its structure based or white box techniques the structure based designs test cases based on internal structure of the software program and code here developers go into my new details of the develop code and test them one by one it's further divided into five categories again and finally the last major category is experienced based techniques these techniques are highly dependent on testers experience to understand the most important areas of software they are usually based on the skills knowledge and expertise of people involved in the testing phase so these are the three major categories moving further let's look at different techniques which come under the categories that we just discussed first under specification based or blackbox test we have five types like I said earlier the first one is something called boundary value analysis or aggravation is BVA this techniques catches any input errors that might interrupt with the proper functionality of the program then you have equivalence partitioning or eep-eep in this technique the test input data is partitioned into number of classes having an equivalent number of data so the data is distributed equally the test cases are then designed for each class or partition that are made this hack Chile helps you to reduce the number of test cases and then you have decision table testing here test cases are designed on the basis of decision tables that are formulated during different combination of inputs and then you have state transition diagram as the name actually indicates testers use state transition diagram to write and filter out the test cases finally you have something called use case testing in this technique the test cases are designed to execute different business scenarios and end-user functionalities moving on to a next major type of white box or specification based here again we have five types the first one is statement coverage this technique involves execution of all the executable statements in the source code at least once then there is decision coverage well this is also known as branch coverage it is a testing method in which each one of the possible branches from each decision point is executed at least once to ensure all reachable code is executed then you have condition coverage condition testing is also known as predictive coverage testing each boolean expression is predicted as true or false here all the testing outcomes are at least tested once this type of testing involves hundred percent coverage of the code and then you have multiple condition testing the purpose of multiple condition testing is basically to test the different combination of conditions to get hundred percent coverage which I mentioned in the previous step which is condition coverage and finally we have something called path coverage in this technique the source code of a program is used to find every executable path this helps to find out all the faults within a particular code moving on to your next major type its experience-based we have something called arrow guessing in this technique the testers and is paid their O's based on their experience availability of data and their skill and knowledge of product failure so that's why it's called error guessing and then we have something called exploratory testing this technique is used to test the application without any formal documentation in this the test design and the test execution are performed concurrently so guys these are some major popular techniques that you can use to write a test case so the successful application of any of these test case design techniques will render test cases that ensure the success of software tester so guys test cases are very important for any project because they are the first step in any testing cycle and if anything actually goes wrong at this step it might impact as you move forward in your software testing lifecycle knowing how to write good test cases is extremely important it doesn't take too much of your effort and time to write effective test scripts as long as you follow certain guidelines let's take a look at few guidelines or best practices that you need to follow while writing test cases first of all you need to consider test cases based on risk and priority prioritize which test cases to write based on the project timeline and the risk factors of your application for example a high risk feature that is scheduled for delivery in six week might be a higher priority than a feature or a low risk feature which is due to be released the next week well there's no given formula on how to decide on the priority here you will get to know with experience moving on make sure you don't forget about the 80/20 rule the 20% of your test should cover 80% of your application even writing a short scenario can uncover a significant part of your box so this is basically the principle which is used behind sanity and smoke test actually then start with a good enough test cases what I mean by that is writing test is never done in one swoop many times it's better to write test cases that are good enough at the present but be sure to revise them in future if needed and the most important thing is your test cases should be crisp this suit should be defined so that the teeth between 45 and 90 minutes to run while still covering a significant area of system in one swoop so when choosing what does to write focus on how they can be outsourced make sure your test cases can be completed by others if necessary next classify test cases based on business scenario and functionality this will allow you to look at the system from different angles the logic here is that you need to know what tests you write and when to actually write it differentiating will also help organize your tests in the test library so you and your team can actually choose what does cases need to be run based on the need of your testing another important thing put yourself in the shoes of customer it is often a common scenario like we discussed one in the beginning of the session that an angry customer would knock up at customer support explaining that software is not delivering an intended feature up according to use expectation so while writing test scenarios keep end-users requirement in the back of your mind because ultimately the product or the software design is actually for the customer right so that's important put yourself in the shoes of customer think like a customer and actively use a test case management tool this case management tools are deemed necessary for managing a stable release cycle they help to develop a level of transparency where everyone knows about who is walking on board they can also be used for tracking deadlines related to a bug fix and a lot more in order to write effective test cases it is important that you learn the practical use of your respective test case management suit two guys are a lot of test case management tools in the market you can choose the one according to your requirements and actually be sure of what you're actually using the tool for and finally monitor all the test cases so when working as a remote software tester or if there are too many software testers working on a similar project and it's common for two software testers to bump on to similar test case therefore monitor all the test cases which are written by you and make sure to note them if they are unique or if they're common also remember to remove the irrelevant and the duplicate test cases well I can keep going on but there are way too many guidelines Donna can actually cover in this session the ones that we learned just now should be good enough for you guys to actually get started in writing test cases so do check out for more as you progress now let's see if your common problems that you come across in test case writing process the first thing is composite step so what is a composite step here's an example let's say you are giving directions from point A to point P when you say something like go to XYZ place and then to ABC it doesn't make much sense right that's a composite step instead of that you can say down left from here and go one mile and then turned right on the road number 11 to arrive at place XYZ that makes more sense here's an actual testing example so as you can see that's the wrong way of writing your test case I have five steps you're the first step is to log into website then actually to go to real-time test session select the configurations and the step four is hit start button to run the test and perform testing of your website on respective configuration and step five is to terminate the test session now what do you think of these steps is a composite step if your answer is four you're absolutely light you will get to know why let me show you the right way of writing it instead of just saying hit start button to run the test and perform testing of your website based on the respective configuration you can just elaborate it for example let's say let's start from the step four hit start button to run the test scroll from the top to bottom of the web page check all the icons and padding's are supported or not check resolution display and then terminate the session well in the wrong way of writing we've actually skipped all this important steps so what I'm trying to say here is that this cases should always be self it is important to write the test cases as granular as possible so guys big granular were writing down the steps for execution so break them down instead of making it complex and representing them in the single sentence another frequent mistake that you might make is including multiple conditions in one test case once again let's learn from example on the screen you can actually see set of steps which are included in a single test for a login function let's check them out so the first step is to enter a valid details and click Submit leave user name field empty and click Submit leave password field empty and click Submit choose an already logged in user name or password and click Submit so basically I have included all the for step in 1 step now you might be thinking what's wrong with that it's saving a lot of documentation and what I can do in 4 step is actually I'm doing in 1 step isn't that great well not quite here are the reasons as to why so what if one of the condition fails we have to mark the entire test is failed right if we mock the entire case fail it means all the 4 conditions are not working which really is in the case it's because just the first case is not working but you're marking failed for all the four conditions that doesn't make sense tests need to have a flow here which you cannot actually seen so the solution is to write modular tests so guys these are the common mistake that you might make when you're actually started writing test cases so please do keep this in mind when writing test cases so that you can avoid them so guys that's all with the theory part let's go ahead and write the test case now but before that here are the simple steps to get you started with first thing is to prepare to write a test case first of all consider if your test key is already exists before writing a new test case for your module find out if there are any already existing test cases that test the same component if you do find anything as such consider updating the test case rather than writing a new one next know the characteristics of a good test case being aware of what constitutes a good test case will help you write a better and a strong test case while you might ask what can dr. Styx here are few first of all you have something call accuracy the test clearly articulates the purpose then you have something called tracing the test is capable of being traced to requirements then you have repetition this can be used to test as many times as necessary reusability the test can be used if necessary and then you have independence every test case your right should be able to be performed in any order without depending on any other test case these are a few characteristics that a good test case should have so make sure your test case Falls somewhat under these categories in the next step is to consider the different scenarios before we actually start writing concentrate and what would happen with the product when being used by customer think from the shoes of customer think about this carefully and design your tests accordingly and finally give yourself sufficient writing time because scenarios and cases form the base for your future test cases and testing you need to give yourself enough time to write a quality test as well as time to have procedure to Rollie reviewed so don't write the test cases in hurry like I said the best guideline when you're actually writing a test case is to write a good enough test case start with small and make it perfect as you progress so these are just prep before you actually start writing a test and now that you have started writing a test what you actually need to do is selected tools for the writing a test case there are a lot of tools out there Excel spreadsheets are highly recommended for writing basic test cases and for manual testing as well apart from that you have other tools such as test link web tests tests ophea and many others so according to your requirements choose the tool whichever you feel comfortable with and make sure you know the functionality of the tube and next step is to write a test case with the chosen two well we did this cuz the template of the test case all you're right so include all those parameters and write our well defined test case so once you've a written a test case the next step is to write a basic test case statement for example you have few parameters like verify what is being actually tested using what tool are using the tag name dialog then you have width what are the conditions under which you are actually testing for and then to what is being actually fed as an input to the test what is being written and what is the expected result and all that so once you're finished testing it's like a final note on what you actually have written your test case or a basic test statement for your test case and finally review the written test case your job isn't quite over once you've actually written the test case you still need to review everything that has been written and evaluate that all steps are clear and comprehensible and that the expected results match with those steps so I hope the steps were clear enough right and I guess now you're good to go you can actually start along with me or you can actually see what I'm doing right now and after that you can go ahead and write a test case of your own so let's go ahead and write a test case for a banking website so guys asked for this session in this demo I will be using excel sheets to write my test case you can actually go ahead and use any other kind of test case management tool for your purpose so before you actually get started with the test case there are some basic details that you should mention it's not a compulsory thing but it's good to have a basic description about what you're actually going to do so let's say the project name project name then module name as in the model which I'm going to test the test case is written by written date executed or reviewed by and similarly executed it did and so the project name would be Bank web site testing then you have module name which can be login because we're tracking the login functionality first it's written by let's queue my name date some dates are month and some year it's you did buy some XYZ person and then again some dates a month and some year we're good to go now let's just mention the parameters which should be test case title or it can be ID if you want next should be dust case description then their steps pre-conditions if I have any test data expected result so I'm just gonna add these for now if according to your requirement you can go ahead and add all things as well actual result and let's add something called status to see if the test case were successful not and finally comments here we go we are checking on login functionality so I'm giving the name as login functionality just verify functionality with valid username and password let me line it okay and as for the test steps which should be navigate to login page enter username enter password click login' preconditions nothing for navigation here I'm saying it should be valid username similarly valid passport now the test data let's give username as some random data and as for the password again so what should be the expected result for navigator login page you should be able to see the login dialog box credentials can be entered or you can say same thing credentials can be entered before not actually you're trying to enter when you're trying to enter if the data is actually getting inserted or not then here for the click login you can say user logged logged in since we are using valid username and password let's just write the actual result for each of these steps let's say we have successfully navigated a login page so let's just write as expected it means we're able to navigate to the login page then credentials can be entered again as expected Borden trying to represent here by writing as expected as that it's as expected to my expected results and user logged in since you are entering valet details at successful login ah let's say user sexually now the status is Pass which is from all my four steps so I'm gonna do this us I do not have any comments that's it guys we've successfully written a test case let's write another one for the invalid details so again the name is same let me just copy this and paste it that's better with invalid username and password the rest of the steps are same invalid username I've removed the you if you can see her then the password is going to be ballots so I'm gonna put that your same as for this you should be able to see the login page that should be successful credentials can be entered as in you're able to enter the details and use a logged in this three should be same as expected because you're able to navigate you're able to enter in the details but as for her user login unsuccessful so that will be pass which is gonna be same forest of three steps but this dead is a faith so guys as for loggin these are two cases that I've written here we can go ahead and write for multiple possibilities like invalid username invalid password valid username invalid password or if your navigation to the login page is not happening like that for different combination you can actually write test cases suppose let's say you have logged in successfully let's write a test case to upload photo in your profile so the name should be upload for the functionality here we go what should be the description upload a photo as logged in usual sounds good when I say logged in user I meant valid user now I want to add another extra figlio let's say preconditions or pre steps actually I need to insert a column yup here we go and I'm gonna make it us free step what is a pre step the pre step here is login with correct data login with valid data that's the action I actually want to perform that's why I've written in the step as with the preconditions I can say login details should be valid now the test steps I have three first one is click the upload let's say click the upload photo link or photo button link is more better then upload a photo as an add the photo and then you have click on upload button so precondition have already added that's login details it should be valid I do not have any test data or anything let's go for the expected result what I'm expecting to happen youris app load of photo should open that's what I'm expecting to happen and as for here when I upload a photo image should be selected image to add to the selected image to be uploaded should be selected now the next thing is click on upload button photo should be successfully uploaded so photo uploaded correctly properly or correctly anything now what are the actual results I'm expecting it's the test case here is upload photo as a logged in user as and successful user so as expected if the navigation works proper if I click on that photo upload link if it goes proper then as expected similarly and here's the same as well so this will be passed pic is my testers pass successfully then pass and pass well this was for a logged in user if you do the same for the logged for the invalid user credentials you wouldn't have anything in the pre step pure so upload photo as a invalid user for all these actions upload a photo page if it navigates properly that should be a pass upload a photo if you actually have any photo that you're uploading that would be a pass but when you click on the float button it does work properly but before actually this happens you are logging in or you're using this as a invalid user so here your test tape actually fails here itself before itself because your not a valid user so this way you can actually write the test cases according to your requirements so guys based on the things that we have learnt today go ahead and write a sample test case according to your requirement there are a lot of sample templates on Google that you can search for and verify to actually master writing test cases so guys so guys we've reached the end of the session I hope you have understood what we have learned today and I hope you've liked the session if you did like it please do click on the like button and if you have any doubts or any kind of comments please include them in the comment section below thank you and meet you in the next session I hope you have enjoyed listening to this video please be kind enough to like it and you can comment any of your doubts and queries and we will reply them at the earliest do look out for more videos in our playlist and subscribe to any rekha channel to learn more happy learning

Channel: edureka!

Views: 80,384

Keywords: yt:cc=on, test case, test case in software testing, test case template, test case with example, test case sample, test case writing, what is test case in software testing, test case in software testing with example, unit test case, test case scenario, test cases in manual testing, test cases examples, writing test cases tutorial, test case format in software testing, sample test case document, how to write a test case, test cases manually, software testing training, edureka

Id: KxelISpFqOY

Length: 38min 6sec (2286 seconds)

Published: Mon Apr 01 2019