As we all know, a Test Case is an important instrument in Software Quality Assurance (SQA). For the benefit of those aspiring for a career in SQA, I’d like to explain why writing good test cases is imperative, and go on to describe the key elements in a good test case template. But before I go into details, let me firstly define a test case.
Test case is a document that describes an action or an event in a software app, and the expected response for that action based on the given input. It determines whether the features of the application are working to the expectations of the end users. A collection of test cases is called as a Test Case Document. A test case consists principally of many specifications such as the Test Case ID, Description, Steps, Inputs, Expected Results and Pass/Fail criteria.
So why do we need a Test Case Document?
1. To identify gaps in business requirements at an early stage of development
In SQA Practice, it is recommended to start writing test cases in the early stages of the development lifecycle, as it can help you identify problems in the requirements or design of an application. For example, if we are unable to figure out a test case (or test cases) for a given requirement, the requirement is probably too broad to be coded. It would force the product owner to go back to the drawing board and refine his or her statement of requirements.
2. To optimize testing effort
Writing test cases requires us to “think through” the entire app upfront from a functional perspective and ensure we don’t miss out on test scenarios during actual testing. Whilst ad hoc testing is a critical component of any testing exercise, deadlines and ill-thought functional boundaries by newcomers to the team at the last minute may cause us to skip checking vital functional pathways in an app. This problem is avoided when the test cases are documented. On the other hand, having test cases also helps us from repeatedly covering the same ground and wasting time; for example stepping through the login functionality many times in an app that doesn’t have CAPTCHA secured login. By spelling out exactly the necessary maximum scenarios to ensure 100% functional coverage (I use the word functional here in a broad sense, inclusive of performance, usability and other relevant testing scopes), one can save time.
3. Instill confidence in a release
When a release is tested and a set of test cases are marked as “passed”, “failed” or “not run”, everyone in the team has a clear idea of where the release stands in terms of quality. Stakeholders can make an easy judgment call about whether to push a release to Live, or to hold off for bug fixes, when under pressure due to the business urgency of the release. If one relied on ad hoc testing, one has to depend on the gut feeling of the testers, and there is no formal accountability for the quality of a given release.
4. Easy to scope-down one’s testing effort
Having test cases will help you to identify the most critical functional pathways of an app. So it offers us the advantage when under a time constraint, to intelligently scope-down the testing effort, to cover the most relevant testing areas for the release.
Types of Test Cases
We can categorize test cases based on their purpose within the SQA lifecycle. Three of the most frequently used test case types are:
1. Functional Test Case – a test case which steps through new functionality in the app
2. Regression Test Case – test case that is executed to identify the impact from changes to existing functionalities
3. Smoke Test Case – a summarized test case or a check list item which is executed to identify whether the build is stable and can be accepted for further testing
How to improve Test Case Management
Due to simplicity and cost, most small software companies write test cases in Word or Excel document formats. However, there are many Test Management Software tools available in the market such as Mercury Quality Centre, QA Complete, or even open source tools like TestLink.
What is the Calcey Test Case Template?
Calcey Technologies follows industry standards for testing, and shown below are the essential elements in our Test Case Document template, that any newbie to SQA can study and master.
| Field Name | Guideline | Example |
|---|---|---|
| Test Case ID | To uniquely identify a test case, when referring to it in project communication.Give the prefix/section# given in the Functional Spec document. This will facilitate mapping the traceability and identifying any missing test cases.
Note: The test case IDs need not be just sequential numbers like 1,2,3,4 etc. |
Functional Spec document:5.1 Login In Test Case document: 5.1.0.1 for the first test case 5.1.0.2 for the second test case |
| Category | Two categories, UI and FUN.UI: UI test cases check the screen layout and all page elements presence.
FUN: Functionality test cases cover all the user actions belonging to a particular function. This ensures that the System works as intended or accepts all the valid inputs, which is supposed to be accepted. |
|
| Feature Description | This is the Test Case name. Write the Test Case Name in simple present tense.1. UI category:
Feature/Functionality name. 2.1: Feature/Functionality name-Valid-<User actions if any> 2.2: For invalid test case combinations: Feature/Functionality name-Invalid- <User actions if any> 2.3: For any Cancel/Abort action: Feature/Functionality name- Cancel Try to cover each user action in a separate test case. |
1. Scenario: Verify labels in the Login screenUI: Login Screen-Labels 2. Scenario: Verify Valid User Login to the System FUN: User Login-Valid 3. Scenario: Verify Invalid User Login to the System FUN: User Login-Invalid 4. Scenario: Verify Cancel button in Login screen FUN: User Login-Invalid-Cancel |
| Negative/ Positive Scenario | This is a mandatory field, which has to be filled at the time of writing the test cases.This is to differentiate happy scenarios and negative scenarios. | |
| Prerequisite | Any activity that must take place prior to executing the test cases.If we are using previously executed Test
Cases as pre-conditions, always use the cell reference of the corresponding test case. When writing pre-conditions, if a user is involved in the action, state the actor(s) name mentioned in the UC. (E.g. System Admin, Us Write the pre-requisite in past tense. |
1. Adobe Reader 8 must be installed.2. User is logged in to the system. |
| Test Steps | This is a mandatory item in test cases.These are the steps used to execute the test case. Each step in the “Test Procedure” has to be numbered and placed in a new row.
The numbering format should be as follows: |
1. Click on the Next button2.Enter a valid security question 3. Enter the address 4. Click on the OK button |
| Input Data | List data to be entered into these fields in order to execute the test case.Alternately, you may point to a separate excel spreadsheet that contains the input data values used for testing.
If you do not know the input data, keep it as “<TBD>”. Do not leave this column blank. |
Admin User Login = testuser@calcey.comAsset Name = <TBD> N/A |
| Expected Results | This is a mandatory item in test cases.For each test step the predicted outcome should be documented under expected results. Without this step, the tester may not know whether the test case is a pass or fail. It’s better to use the word ‘should’ when writing the expected results, since ‘should’ is used to indicate that something is expected. |
1. Segments should be displayed when the user clicks on Organize tab.2. System should display the error “User Name cannot be left blank” |
| Multiple Target Apps | Today we often have mobile and web apps that are complementary and represent the same system under testing. In such cases, one must clearly mark whether the test case must be repeated for several user interfaces or devices prior to passing or failing. | App1, App3 |
| Automated | Indicates whether the test has been automated or is performed manually.You can also give the name of the script for easy traceability. | |
| Status (Passed / Failed) | Initially left blank. This is a mandatory field that has to be filled at the time of execution of the test case.All tests executed should be marked as either passed or failed.
If a test case cannot be executed due to any reason, then it should be marked as “Not executable” or “Differed”, with a Comment. |
|
| Defect ID | This is a mandatory field that has to be filled at the time of execution of the test case.For each test step if there is any deviation from predicted outcome then that should be documented in the defect-tracking tool (such as JIRA). Then the Defect ID generated for the defect by the tool has to be documented here. | |
| Build Number | This is a mandatory field that has to be filled at the time of execution of the test case.This is to differentiate the test cases for different builds. | |
| Use Case Spec Reference | This is not a mandatory field.Document any other Functional Spec document or Use Case references here. | |
| Comments | Any comments to elaborate a situation that cannot be represented via standard fields. |