Software testing of an application includes validating its functional as well as non-functional requirements. For validating these requirements, software testers are required to create effective test cases using different white box and black box test design techniques.
In this tutorial, we will study test cases, their different attributes, and their types in detail. In our last section, you can also check – test cases in software testing with examples for some of the most frequently asked test cases in software testing interviews. So, let’s begin.
Content
What is a Test Case?
A test case is a set of conditions for evaluating a particular feature of a software product to determine its compliance with the business requirements.
A test case has pre-requisites, input values, and expected results in a documented form that cover the different test scenarios.
Once the test cases are created from the requirements, it is the job of the testers to execute those test cases. The testers read all the details in the test case, perform the test steps, and then based on the expected and actual result, mark the test case as Pass or Fail.
Test Case Attributes
Let’s check the different attributes of a test case that comprise a test case and make them more reliable, clear, and concise avoiding or reducing any sort of redundancy.
- TestCaseId – A unique identifier of the test case.
It is a mandatory field that uniquely identifies a test case e.g. TC_01. - Test Summary – One-liner summary of the test case.
This is an optional field. Normally the test cases either have the ‘Test Summary’ field or the ‘Description’ field. - Description – Detailed description of the test case.
This field defines the purpose of the test case e.g. verify that the user can login with a valid username and valid password. - Prerequisite or pre-condition – A set of prerequisites that must be followed before executing the test steps.
For example – while testing the functionality of the application after login, we can have the pre-requisite field as “User should be logged in to the application”. - Test Steps – Detailed steps for performing the test case.
This is the most important field of a test case. The tester should aim to have clear and unambiguous steps in the test steps field so that some other person can follow the test steps during test execution. - Test Data – The value of the test data used in the test case.
For example – while testing the login functionality, the test data field can have the actual value of the username and password to be used during test execution. - Expected result – The expected result in order to pass the test.
Based on the test steps followed and the test data used, we come up with the expected result e.g. the user should successfully login and navigated to home page. - Actual result – The actual result after executing the test steps.
This field is filled during test execution only. In this field, we write the actual result observed during the test case execution. - Test Result – Pass/Fail status of the test execution.
Based on the expected result and the actual result, the test case is marked as passed or Failed.
Apart from Pass/Fail, we can have other values also like-
Deferred, when the test case is marked to be executed later, for some reason.
Blocked, when the test case execution is blocked due to some other issue in the application). - Automation Status – Identifier of automation – whether the application is automated or not.
This is an optional field used only when we have automation in the project. - Date – The test execution date.
This field helps in keeping track of the different iteration during multiple test execution cycles. - Executed by – Name of the person executing the test case.
This field helps when there are multiple team members working on the test execution activity.
For a detailed Test case template in downloadable Xls format, you can also check our tutorial – Test Case Template (Xls).
How to write good test cases?
- Test design technique
Follow a test design technique best suited for your organization or project-specific needs like – boundary value analysis, equivalence class partitioning, decision table testing, etc. This ensures that well-researched standards and practices are implemented during test case creation. - Clear and concise tests
The test case summary, description, test steps, expected results, etc should be written in a clear and concise way. These should be easily understandable by the different stakeholders in testing. - Uniform nomenclature
In order to maintain consistency across the different test cases, we should follow a uniform nomenclature and set of standards, while writing the test cases. - Fundamental/Atomic Test cases
Create test cases as fundamental as possible. So, a test case should only test a single unit of functionality without merging or overlapping multiple testable parts. - Leave no scope for ambiguity
Write test cases with a clear set of instructions. For example – instead of writing “Open homepage”, write – “Open homepage – http://www.{homepageURL}.com in the browser and press enter”. - No Assumptions
While writing test cases do not assume any functionality, pre-requisite, or state of the application. Instead, map the test cases to the required documents like – SRS, Use-case documents, etc. - Avoid redundancy
Don’t repeat the test cases, this leads to waste of both time and resources. This can be achieved by well-planned and categorized test cases. - Traceable tests
Use a traceability matrix to ensure that 100% of the application’s feature in the scope of testing is covered in the test cases. - Ensure to cover the different aspects of the software
Ensure that apart from the functionality, the different aspects of the software tested like performance, usability, robustness, etc are covered in the test case by creating performance test cases and benchmarks, usability test cases, negative test cases, etc. - Test data
The test data used in testing should be as diverse and as close to real-time usage as possible. Having diverse test data can more reliable test cases.
Time to check some manual test case examples. Here, we have compiled test cases in software testing with examples for some of the most common software applications like Whatsapp, Google, and Youtube along with real-world objects like Pen, Pencils, ATM machines, etc.
These types of questions are frequently asked in software testing interviews to judge the ability of the interviewee to think of test cases covering different types of testing.
Test Case Examples
This completes our tutorial on Test Cases and their different attributes. I hope this tutorial would help you in creating well-documented test cases for your software projects.
Nice explanation.
Actual result is a bug report attribute, but not a test case.
And thank you very much for this site. Very useful!
You are right :-). But sometimes, we do have the ‘actual result’ as a test case attribute. We will keep this field blank initially and at the time of test execution, we will enter the actual result along with the test result for each test cycle.