What is Test Case?
A Test Case is a set of actions executed to verify a particular feature or functionality of your software application.
This tutorial describes test case designing and the importance of its various components.
Now, consider the Test Scenario Check Login Functionality there many possible cases like
Test Case 1: Check results on entering valid User Id & Password
Test Case 2: Check results on entering Invalid User ID & Password
Test Case 3: Check response when User ID is Empty & Login Button is pressed, and many more
This is nothing but Test Case. Test scenarios are rather vague and cover a wide range of possibilities. Testing is all about being very specific.Hence, we need Test Cases
Please be patient. The Video will load in some time. If you still face issue viewing video click here
- Now just Consider the test case, Check the response on entering valid Agent Name and password. It's obvious that this test case needs input values viz.Agent Name & Password
- This is nothing but Test Data. Identifying test data can be time-consuming and may sometimes require creating test data afresh. The reason it needs to be documented
- Before we proceed ahead consider a quote from a witty man who said "To ensure perfect aim, shoot first and call whatever you hit the target" But if you do not live by this philosophy, which I am sure most of you do not then your Test case must have an expected result.
- For our test case, expected result would be, Login should be successful
- If expected results are not documented, we may miss out on small differences in calculations in results that otherwise look OK.
- Consider this example, where you are calculating monthly pay for an employee which involves lots of calculations. The need for documenting expected results becomes obvious.
- Suppose the author of the test case has left the organization or is on a vacation or is sick and off duty or is very busy with other critical tasks and you are recently hired and have been asked to execute the test case.Since you are new, it would certainly help to have test steps documented which, in this case, would be Launch application, Enter Agent Name, Enter Password, Click OK
- You may wonder that for this simple test steps, documentation is not required
- But what is your test steps looked something like this? (pic in video) I think the need will become instantaneously obvious.
- That apart your test case -may have field like, Pre - Condition which specifies things that must in place before the test can run
- For our test case, a pre-condition would be Flight Reservation Application should be installed, which I am sure 50% of the people watching this tutorial do not have
- Also, your test case may also include Post - Conditions which specifies anything that applies after the test case completes.
- For our test case, a post - condition would be time & date of login is stored in the database
- During test case execution, you will document the results observed in the Actual Results column and may even attach some screen shots and based on the results give PASS & FAIL status.
- This entire table may be created in Word, Excel or any other Test management tool.That's all to Test Case Design
Format of Standard Test Cases
Below is format of a standard login Test case
|Test Case ID||Test Scenario||Test Steps||Test Data||Expected Results||Actual Results||Pass/Fail|
|TU01||Check Customer Login with valid Data||Userid = guru99 Password = pass99||User should Login into application||As Expected||Pass|
|TU02||Check Customer Login with invalid Data||Userid = guru99 Password = glass99||User should not Login into application||As Expected||Pass|
While drafting a test case do include the following information
- The description of what requirement is being tested
- The explanation of how the system will be tested
- The test setup like: version of application under test, software, data files, operating system, hardware, security access, physical or logical date, time of day, prerequisites such as other tests and any other setup information pertinent to the requirements being tested
- Inputs and outputs or actions and expected results
- Any proofs or attachments
- Use active case language
- Test Case should not be more than 15 steps
- Automated test script is commented with inputs, purpose and expected results
- Setup offers alternative to pre-requisite tests
- With other tests, it should be incorrect business scenario order
Best Practice for writing good Test Case Example.
1. Test Cases need to be simple and transparent:
Create test cases that are as simple as possible. They must be clear and concise as the author of test case may not execute them.
Use assertive language like go to home page, enter data, click on this and so on. This makes the understanding the test steps easy and test execution faster.
2. Create Test Case with End User in Mind
Ultimate goal of any software project is to create test cases that meets customer requirements and is easy to use and operate. A tester must create test cases keeping in mind the end user perspective
3. Avoid test case repetition.
Do not repeat test cases. If a test case is needed for executing some other test case, call the test case by its test case id in the pre-condition column
4. Do not Assume
Do not assume functionality and features of your software application while preparing test case. Stick to the Specification Documents.
5. Ensure 100% Coverage
Make sure you write test cases to check all software requirements mentioned in the specification document. Use Traceability Matrix to ensure no functions/conditions is left untested.
6. Test Cases must be identifiable.
Name the test case id such that they are identified easily while tracking defects or identifying a software requirement at a later stage.
7. Implement Testing Techniques
It's not possible to check every possible condition in your software application. Testing techniques help you select a few test cases with the maximum possibility of finding a defect.
Boundary Value Analysis (BVA): As the name suggests it's the technique that defines the testing of boundaries for specified range of values.
Equivalence Partition (EP): This technique partitions the range into equal parts/groups that tend to have the same behavior.
State Transition Technique: This method is used when software behavior changes from one state to another following particular action.
Error Guessing Technique: This is guessing/anticipating the error that may arise while testing.This is not a formal method and takes advantages of a tester's experience with the application
8. Self cleaning
The test case you create must return the Test Environment to the pre-test state and should not render the test environment unusable. This is especially true for configuration testing.
9. Repeatableand self-standing
The test case should generate the same results every time no matter who tests it
10. Peer Review.
After creating test cases, get them reviewed by your colleagues. Your peers can uncover defects in your test case design, which you may easily miss.
Test Case Management Tools
Test management tools are the automation tools that help to manage and maintain the Test Cases. Main Features of a test case management tool are
- For documenting Test Cases: With tools you can expedite Test Case creation with use of templates
- Execute the Test Case and Record the results: Test Case can be executed through the tools and results obtained can be easily recorded.
- Automate the Defect Tracking: Failed tests are automatically linked to the bug tracker , which in turn can be assigned to the developers and can be tracked by email notifications.
- Traceability: Requirements, Test cases, Execution of Test cases are all interlinked through the tools, and each case can be traced to each other to check test coverage.
- Protecting Test Cases: Test cases should be reusable and should be protected from being lost or corrupted due to poor version control. Test Case Management Tools offer features like
- Naming and numbering conventions
- Read only storage
- Controlled access
- Off-site backup
Popular Test Management tools are : Quality Center and JIRA
- Please note that the template used will vary from project to project. Read this Article to Learn Test Case Template with Explanation of Important Fields
Download the above Test Case Template Excel (.xls)
I keep getting several requests to share a good Test Case Template. And I’m surprised that many testers are still documenting test cases with Word docs or Excel files. Most of them prefer excel spreadsheets because they can easily group test cases by test types and most importantly they can easily get test metrics with the Excel formulas. But I’m sure that as the volume of your tests goes on increasing, you will find it extremely difficult to manage.
If you are not using any test case management tool, then I would strongly recommend using an open source tool to manage and execute your test cases.
Test case formats vary from one organization to another. But using a standard test case format for writing test cases is one step closer to setting up testing process on your project. It also minimizes ad-hoc testing done without proper test case documentation. But even if you use standard templates you need to set up test cases writing, review and approval, test execution and most importantly test report preparation process, all by using manual methods.
Also if you have a process to review test cases by the business team, then you must format these test cases in a template agreed by both the parties.
Here is how to make this manual test case management process a bit easier with the help of simple testing templates.
Note: I’ve listed maximum fields related to a test case. But it is advised to use only those fields which are used by your team. Also if you think any field used by your team is missing from this list, then feel free to add it to your customized template.
Below are the Standard Fields of a Sample Test Case Template
There are certain standard fields to be considered while preparing a Test case template.
Several standard fields of a sample Test Case template are listed below.
Test case ID: Unique ID is required for each test case. Follow some convention to indicate types of the test. E.g. ‘TC_UI_1’ indicating ‘user interface test case #1’.
Test priority (Low/Medium/High): This is very useful while test execution. Test priority for business rules and functional test cases can be medium or higher whereas minor user interface cases can be of low priority. Test priority should always be set by the reviewer.
Module Name: Mention the name of the main module or the sub-module.
Test Designed By Name of the Tester
Test Designed Date: Date when it was written
Test Executed By Name of the Tester who executed this test. To be filled only after test execution.
Test Execution Date: Date when the test was executed.
Test Title/Name: Test case title. E.g. verify login page with a valid username and password.
Test Summary/Description: Describe test objective in brief.
Pre-condition: Any prerequisite that must be fulfilled before execution of this test case. List all the pre-conditions in order to execute this test case successfully.
Dependencies: Mention any dependencies on other test cases or test requirement.
Test Steps: List all the test execution steps in detail. Write test steps in the order in which they should be executed. Make sure to provide as many details as you can. Tip – In order to manage a test case efficiently with a lesser number of fields use this field to describe test conditions, test data and user roles for running the test.
Test Data: Use of test data as an input for this test case. You can provide different data sets with exact values to be used as an input.
Expected Result: What should be the system output after test execution? Describe the expected result in detail including message/error that should be displayed on the screen.
Post-condition: What should be the state of the system after executing this test case?
Actual result: Actual test result should be filled after test execution. Describe system behaviour after test execution.
Status (Pass/Fail): If actual result is not as per the expected result mark this test as failed. Otherwise, update it as passed.
Notes/Comments/Questions: If there are some special conditions to support the above fields, which can’t be described above or if there are any questions related to expected or actual results then mention them here.
Add following fields if necessary:
Defect ID/Link: If the test status is failed, then include the link to the defect log or mention the defect number.
Test Type/Keywords: This field can be used to classify tests based on test types. E.g. functional, usability, business rules etc.
Requirements: Requirements for which this test case is being written for. Preferably the exact section number of the requirement doc.
Attachments/References: This field is useful for complex test scenarios. To explain test steps or expected result using a Visio diagram as a reference. Provide the link or location to the actual path of the diagram or document.
Automation? (Yes/No): Whether this test case is automated or not. Useful to track automation status when test cases are automated.
With the help of above fields I’ve prepared a test case example template for your reference:
Download Test Case Template with Example
– DOC file and
– XLS file
Also, refer few more articles on writing effective test cases here and here. Use these test writing guidelines and the above template to write and manage test cases effectively on your project.
Personally, I prefer to use a test case management tool. You can start with any open source tool. It will be a good addition to your efforts to set up testing process and meanwhile, it will also save a lot of time instead of manually maintaining these documents.
Are you an expert in preparing Test cases? Then kindly share few valuable tips with us.
Let us know if you have any queries, comments/suggestion about this post.
← PREV POST | NEXT POST →