OK, but first things first.
Test case is a document. It is one of the import documents created by Testers.
But what exactly is a test case?
Well, a test case is basically a set of instructions that outlines the steps to be taken to verify that a particular software feature or function works as expected.
It serves as a roadmap for the tester to follow while testing.
And is detailed enough to ensure that all possible scenarios are covered.
I use a particular template for test cases. This make sure that, I am not missing any data.
My Test case template contains following sections:
- Header section
- Test case name
- Test scenario
- Requirement/Story
- Developed by
- Test case priority
- Test case status
- Reviewed by
- Review date
- Review status
- Details section
- Steps
- Action
- Test data
- Expected result
- Actual result
- Pass/Fail
- Defect number
- Remarks
- Executed by
- Execution date
Above details same for all test cases.
Here is the screenshot of a typical test case.
Now, let us deep-dive and see what these sections are:
- Test case name
- It is the unique name of the test case. It can be Test case ID also. I use to have some naming convention. Like <functionality><X001>
- Where X=1 or 2
- 1 represents Positive scenarios
- 2 represents Negative scenarios
- Test scenario
- In this section, I write the test scenario, to which this test case belongs to.
- As you know, a scenario can have multiple test cases.
- This helps in traceability of test cases.
- Requirement/Story
- This field contains the client requirement or Story, for which I am writing test case.
- This is one level higher mapping for the requirement-test case traceability.
- If there are any doubts, I can go to Requirement/Story and expand or delete the test cases, as per the need.
- Developed by
- Developed by informs that who developed the test case? Basically it is the name of the person who has written the test case.
- Test case priority
- Test case priority indicates the priority on which, this test case needs to be executed.
- Priority is indicated by 1 , 2 or 3. I follow this.
- But some projects use ‘Critical’, ‘High’, ‘Medium’ etc.
- Ideally, all test cases should be executed for Full Regression testing. But usually, what I have experienced in various testing cycles is, lac of time for full regression. So, in these kind of smaller cycles, I suggest to execute Priority 1 test cases first. If time permits, Priority 2 test cases will be executed.
- Test case status
- This field show status of the test case- Active or Inactive.
- Some times, a particular functionality changes. Or user flow changes. Or even a feature in the application will be removed. In these scenarios, the developed test case will no longer be valid.
- So, it is good practice to keep re-visiting this status.
- Reviewed by
- This field indicates you, who reviewed the test cases.
- I prefer to have a peer-review of test cases.
- This helps in maintaining quality of test cases. So, in the review process a person will review test cases and provide feedback. If there are any editions done, again review will be made. Finally it will be set to review status.
- Review date
- Gives you the date on which final review is done
- Review status
- This field show the current status of the test case review.
- I keep 3 statuses - ‘In Progress’, ‘Reviewed’, ‘Returned’.
Now, let us see details section:
- Steps
- The serial number of steps.
- Action
- Action to be performed on the application under test. This is the heart of test cases.
- Examples are : Enter the text in username field, Click on ‘OK’ button etc.
- Test data
- Data we are using in that step.
- Some people us test data in the ‘Action’ itself. But, I prefer to separate it.
- Basically it is the input data for the application.
- Examples are : ‘Test name’, 123456 etc
- Expected result
- If we perform some action, what is the expected behavior ?
- This is given is Expected result. This is with reference to story/requirements.
- Example is : User is logged in.
- Note : Up to this step, all details are available before execution. Next column onwards I fill them during execution of test case.
- Actual result
- In this section, I enter what is current behavior of application in response to the action I am doing on it.
- Example is : Same as expected. or Invalid login error is displayed
- Pass/Fail
- If Actual result is same as expected result, I mark it as Pass. Else, Fail.
- Note : If some action is not performed due to blocker in the previous steps, I make it as ‘NA’.
- Defect number
- If the step fails, I report a new bug in bug tracking tool. And enter that bug number here.
- If bug is already existing, I write that number.
- Remarks
- If there is something specific to highlight or make note of, I use this column.
- Executed by
- I enter my name here, if I am executing test case.
- Basically, who is executing, they will enter their name here.
- Execution date
- The date on which test case is executed.
- This is how I am developing and executing the test cases.
- I have made the template in MS excel. If I use any Test management tool, most of them have similar fields of data.
- So, use my Test case template and become pro tester !