How to write a Test Case
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.write an in depth test for the riskier component of your app or a sanity test to go over 80% of the complete system?
The role of Test Cases in testing
A test case specifies the work procedure, expected results and the conditions 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 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 testing commands is a core skill to develop as a software tester.
Which brings up an assortment of question (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, be smart about it and write down the test cases that will bring you the best Return on Investment (ROI). Here’s how!
Basic guidelines to follow when writing a good Test Case
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 formula, you will need to solve this equation repeatedly.
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.
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 suites all audiences and you may consider writing 2 separate versions of a single test.
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 not only to development tasks.
Create test cases like you are running a marathon not a sprint.
Create test 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.
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 if it’s not the final list, you can later break tests down or merge them.
Classify Test Cases based on Business Scenarios and Functionality.
This will allow you to look at the system from different angles. The logic here, is to know what test to write and when to write it. Differentiating will also help organize your tests in the Test Library, so you and your team can choose what tests can be run based on the needs of your test plan in the future.
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”.
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.
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 overhauls and writing a new one test from scratch.
This article is based on a blog post that was published on our QAblog