Introduction

There are lots of different ways to write test cases. This article will give you examples of common structures which you can use and adapt to suit your need.

What is Test Case?

A Test Case is a set of actions executed to verify a particular feature or functionality of your software application. 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.

Writing Effective Test Cases

1. Test Case Naming Conventions It’s always a good practice to name our test cases in such a way that it makes sense to everyone who is going to refer the test cases in future As a best practice, name the Test Cases to represent the module name or functional area we are going to verify in that test case. We should try to make it look relevant to the project/module/functional feature under test. We should make test cases so informative that it could be sensed just by looking at the test case ID or test case name!

2. Test Case Description Description is where we mention all the details about what we are going to test, and the particular behavior being verified by the test. The ‘description’ of a test case should define “What am I going to test?” What needs to be verified, which test environment it needs to be verified in, which test data is to be used – all this information goes into description. Information in a well-written test case description:

• Test to be carried out/behavior being verified
• Preconditions and Assumptions (any dependencies)
• Test Data to be used
• Test Environment Details (if applicable)
• Any Testing tools to be used for the test

3. Assumptions and Preconditions While writing test cases, we should communicate all assumptions that apply to a test, along with any preconditions that must be met before the test can be executed. Below are the kind of details you would like to cover as part of this section:

• Any user data dependency (e.g. the user should be logged in, from which module/page the user should start the journey, etc.)
• Dependencies on test environment
• Any special setup to be done before Test Execution
• Dependencies on any other test cases – does the Test Case need to be run before/after some other Test Case?

We should ensure to add as much information as possible for any conditions to be met before running the test case.

4. Test Data Input Identifying test data can be really a time-consuming activity – many a times test data preparation takes most of the time in a testing cycle. To make our life easy as a tester, wherever applicable, we can give Test Data to be used for the Test Case within the test case description or with the specific Test Case step.This saves a lot of time in the long run as we don’t have to hunt a new test data every time we need to execute the test.

5. Cover all Verification Points in Test Design Steps Another important part of a well-written test case are properly defined test case verification steps covering all the verification points for feature under test. The Test Design Steps should not only cover the functional flow but also each verification point which must be tested! By comparing our Test Case steps with the artifacts (Requirement documents, Use Cases, User Stories) given for the project, we can ensure that the Test Case covers all the verification points.

6. Expected Result A well-written Test Case clearly mentions the expected result of the application or Device Under Test (DUT). Each test design step should clearly mention what is the expected outcome of that verification step. We can also attach screenshots or specification documents to the relevant step mentioning the DUT should work as outlined in the given document to make things simpler.

7. Divide Special Functional Test Cases into Sets For effective test case writing, we should consider breaking down our Test Cases into sets and sub-sets to test some special scenarios. If we strive to write effective test cases, we should write these special functional test cases separately. For instance, test cases to verify error conditions should be written separately from functional test cases and should have steps to verify the error messages. If while writing the scenarios into sets, a particular feature has a lot of input combinations, we can separate the test into sub-tests.

8. Easily Understandable While designing test cases, we should always consider that the Test Cases will not always be executed by the one who designs them. So, the tests should be easily understandable and to-the-point. Test Case suites that are only understandable by the ones who designed them are not considered as a mature Testing Professional. There may be scenario where the person who wrote all those Test Cases leaves for some reason and a completely new team has to work on the Test Case execution, the entire effort spent during the design phase could go down the drain.We should focus on writing Test Cases that:

• are Simple and easily understandable by everyone
• are to-the-point! We don’t have to be writing essays! (wherever we feel that any Test Case is going beyond a certain amount of steps, We should break it into a new Test Case)
• still have enough coverage.

9. Review With Test Cases playing an important role in Software Testing Life-cycle, making sure they are correct and confirm to standards becomes even more necessary – that is where the Test Case review process comes into picture.Test Case Review can be done by Peer Testers (termed ‘Peer Review’), Developers, Product Owners or any Relevant Stakeholders.

10. Reusable We should write test cases keeping in mind that they could be re-used in the future for some other projects.On that note, before writing a new Test Case for our project/module, we should always try and find out if there are test cases written already for the same area? That really saves a lot of time!This might not apply if we are landed in a new NPI.

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

1. For documenting Test Cases: With tools you can expedite Test Case creation with use of templates
2. Execute the Test Case and Record the results: Test Case can be executed through the tools and results obtained can be easily recorded.
3. 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.
4. 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.
5. 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
• Versioning
• Read only storage
• Controlled access
• Off-site backup

Popular Test Management tools are : Quality Center and JIRA.

Conclusion:

It’s a huge task to write effective test cases with all the required details in it. We should think from the end user’s perspective, know the application end-to-end, and follow the best practices to make our test cases more effective and efficient.