What is a Test Case in Software Testing?
A test case measuring functionality across a set of actions or conditions to verify the expected result. They apply to any software application, can use manual testing or an automated test and can make use of test case management tools.
A key thing to remember when it comes to writing test cases is that they are intended to test a basic variable or task such as whether a discount code applies to the right product on an e-commerce web page. This allows a software tester more flexibility in how to test code and features.
Test Script vs. Test Case
The difference between test cases vs. test scripts should also be clarified. A test script is a short program meant to test certain functionality. A test case is a document with steps to be completed as planned out ahead of time.
Consider test cases as a meticulously planned trip and test scripts to be more like a quick trip to the grocery store.
What Are the Best Practices for Writing Quality Test Cases?
1. Consider Test Cases based on Risks and Priorities
Prioritize which test cases to write based on the project timelines and the risk factors of your application. A high-risk feature that is scheduled for delivery in 6 weeks, might be of higher priority than a test for a low risk feature due to be released next week. Mostly, because later in the project, you might not have the time to write the test for the high-risk feature. There is no given test case formula, you will need to solve this equation repeatedly.
2. Remember the 80/20 rule
20% of your tests will cover 80% of your application, this is the principle behind sanity and smoke tests. Even writing a short scenario can uncover a significant part of your bugs.
That’s why it’s best to start from an end-to-end sanity suite and only then begin covering specific features more in depth. Furthermore, when covering a specific feature it is better to work on the short tests that cover it end-to-end before moving deeper.
3. Make sure your test cases can be completed by others when necessary
When choosing what test to write, focus on how they can be “outsourced”. For instance, write tests you can give to developers to run while you are busy testing those high-risk tasks you cannot give to anyone else. In some occasions it will be impossible to write a single test that suits all audiences and you may consider writing 2 separate versions of a single test.
4. The Good enough test case
Writing tests is never done in one swoop, many times it is better to write test cases that are “good enough” at present. Be sure to revise them in the future when possible. This Agile/Iterative approach of refactoring applies to test case writing, and not only to development tasks.
5. Create test cases like you are running a marathon not a sprint
Create tests that will be relevant in future sprints/builds/releases; if you make them too specific, their relevance will only last for this stage of your project.
6. List your tests before you write them
Create a list of topics and their priority based on risk. This will help keep focus on what you need or want to test. Even when the list is not final, you can later break tests down or merge them.
7. Classify Test Cases based on Business Scenarios and Functionality
This will allow you to look at the system from different angles. The logic behind this process is to know what test to write and when to write it. Differentiating will also help organize your tests in a Test Repository, so you and your team can choose what tests can be run based on the needs of your test plan in the future.
8. Not too long or too short
Test suits should be defined so they take between 45 and 90 minutes to run, while still covering a significant area of the system in” one swoop”.
9. Test-drive your tests
The tests you write at first will probably be run once or twice while you perfect them. So before you send them out the door to others or released to customers make sure you take your test for a test-drive.
10. Run your tests regularly to keep them relevant
You will need to continuously make small changes to your test cases based on constraints, such as application changes, environment modification and many other reasons. Making small changes is quick and easy, and better than making a full overhaul and writing a new one test from scratch.
How to Write Software Test Cases
Writing test cases varies depending on what the test case is measuring or testing. This is also a situation where sharing test assets across dev and test teams can accelerate software testing. But it all starts with knowing how to write a test case effectively and efficiently
Test cases have a few integral parts that should always be present in fields. However, every test case can be broken down into 8 basic steps.
Step 1: Test Case ID
Test cases should all bear unique IDs to represent them. In most cases, following a convention for this naming ID helps with organization, clarity, and understanding.
Step 2: Test Description
This description should detail what unit, feature, or function is being tested or what is being verified.
Step 3: Assumptions and Pre-Conditions
This entails any conditions to be met before test case execution. One example would be requiring a valid Outlook account for a login.
Step 4: Test Data
This relates to the variables and their values in the test case. In the example of an email login, it would be the username and password for the account.
Step 5: Steps to be Executed
These should be easily repeatable steps as executed from the end user’s perspective. For instance, a test case for logging into an email server might include these steps:
- Open email server web page.
- Enter username.
- Enter password.
- Click “Enter” or “Login” button.
Step 6: Expected Result
This indicates the result expected after the test case step execution. Upon entering the right login information, the expected result would be a successful login.
Step 7: Actual Result and Post-Conditions
As compared to the expected result, we can determine the status of the test case. In the case of the email login, the user would either be successfully logged in or not. The post-condition is what happens because of the step execution such as being redirected to the email inbox.
Step 8: Pass/Fail
Determining the pass/fail status depends on how the expected result and the actual result compare to each other.
