You are always running late. By the time you can start your testing the development team is already pushing out builds with tons of functionality, and so there is never time to write all the test cases you want, or to review those you already have in your repository.
With that in mind, should you spend your time writing an in-depth test for the riskier component of your app or a sanity test to go over 80% of the complete system?
In this article, we will cover test case writing best practices. Test cases writing is an art, and it is crucial for the entire process that the tests will be clear to all individuals involved, in order to assure the quality of an application.
The role of Test Cases in testing
A test case specifies the work procedure, expected results and the conditions that a tester needs to verify. It is the basic documentation needed to determine if an application, or one of its features is working as originally planned and desired.
Determining whether a product or it’s features are ready for release will usually require a number of test cases to be written and executed.
The Test Cases, or Test Suites as they are sometimes referred to, derive from the specified or implicit requirements of any application, software or system. This “translation” process of User Stories to actionable test case commands is a core skill to develop as a software tester.
Which brings up an assortment of questions (here are the most common):
- How specific or broad should a test case be?
- What test cases should be written first?
- What aspects of the functionality should I cover?
- How long or short should a test be to remain efficient?
Since time is a limited resource with a price, when it comes to writing test cases in software testing, be smart about it and write down the test cases that will bring you the best Return on Investment (ROI), following our best practices.
Test Case best practices - basic guidelines to follow when writing a good Test Case
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 to 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.
Final thoughts
So, what is a good test case in software testing? As you probably understand by now, there is no straightforward answer to that question. But, as we mentioned in the above points, there are measures you can take to ensure that your tests stay relevant, and that no major risk remains uncovered.
Test management tools, such as PractiTest, can also prove very useful for test case management, and for keeping track of the state of your test cases at all times. Such tools allow you to keep a structured repository of your test cases, organized by different parameters, and thus keep track of the state of your tests at all times to make sure those are up to date.
