How to write Test Cases and Documents Test Case design is the most important task in the Testing cycle since this document will decide what would be the quality level of the Application that will be released.
Test Scenario: A scenario is nothing but a real time event which can occur with respect to the functional aspects of the application. Ex: Lets assume that we need to test login functionality of a web application. Here Before testing anything we first imagine the scenarios what could happen with the Login page. Let’s list them out.
Scenario 1: User will enter user id and password will click the submit button.
Scenario 2: User will enter only user id textbox and will click submit button.
Scenario 3: User will enter only password field and click on submit button.
Scenario 4: user will not enter any data and will click submit button.
These are the four scenarios which could happen in the login page. Hence Scenarios are nothing but possible events which could happen related to the functionality of the application. The quality of the product will be directly dependent on the number of Scenarios a Software tester can imagine. That is why Software Testers should have a very good Vision of the real time scenarios.
Test Cases: Test cases are nothing but properly documented Test scenarios in a well-defined manner. Test cases are used to track the progress of testing, act as proof of test execution and official documentations which would imply test completion. Hence a test case document is nothing
but a set of Scenarios, conditions, validations against which the tester will validate the functionality of the application and record the results. The image given below would demonstrate the fields present in a Typical test case document and how the test case should be designed for a login page.
Test Case Design: The Image would open in a new window. Please keep this image open as we will discuss each field in the test case document one by one. Below given Columns are present in the attached screenshot.
1. Automation: This column will have values Yes or No. This will indicate if we have Automation Script prepared for this test case or not. 2. Test Case Number: This is nothing but the unique number given for each test case. 3. Requirement number: Requirement number is nothing but the Requirement ID in the requirements document for which the present test case has been written. 4. Module: Module or part of the Software for which the present test case written. Example: Inbox, Sent, Draft etc. are the different modules in a mail server. 5. Pre – Requisites: Before executing any test case we may have any pre- requisites for the test case.
Ex: Before trying the login we should have a valid login id and password. 6. Steps to follow: This is a detailed step by step instruction on how to execute the test case. Please refer the image for an example 7. Expected Result: This column will have the expected result according to the requirement after test steps are executed. 8. Actual result: This column will have report of actual result what we see once we execute the test steps. 9. Status: This column will have any one of the below given value status based on the actual result. a. Pass – If the Actual Result is same as Expected result. b. Fail – If the actual result is not same as the expected result. c. Pending – The test case is still not executed. d. Post Launch – This test case will be executed in the next release. There can be many other status values what we can put in based on project requirements. 10. Open Defects: This column will have the open or Defects which still exist for the current test case. 11. Close defects: This column will have the defects which are fixed and working fine but were raised earlier for the same test case. These defects will be retested in the regression testing. 12. Remarks: If we want to put any remarks about the result of the test case. ex: Test case is pass but the application is a bit slow when executing current test case.
Types of Scenarios:
Positive scenario:
Positive scenario is the one which are straight forward and normal scenarios which happen with respect to the application in accordance functional aspects of the system. Ex: Let’s assume the login functionality of a webpage. Positive scenario would be something like: User will enter a valid user id and password and clicks on submit. Now we know this is a straight forward test case written from the requirement.
Negative Scenario test cases :
In this type of scenarios tester will try to write down the scenarios which are not straight forward and which are not written in the requirement document. Tester will visualize the possible events where the system can break, Tester will try the scenarios which are opposite to the regular approach. Ex: We will again take the login functionality: Negative scenarios for the login page can be listed as given below: 1. Tester will enter wrong user name and password and click submit 2. Tester will enter valid user name but wrong password and click submit 3. Tester will enter valid user name but expired password and click submit 4. Tester will enter valid user name and password of the other account in the same email server and click submit.
Also Check:
List of Test Design Techniques
Fundamentals of Test Process