I wrote a new blog post with some tips on writing better test cases:
I would love to hear your feedback and thoughts on this topic!
7 Likes
Ooh, that looks great! I’m in the middle of an acceptance testing round so I’ve bookmarked that to read calmly with a cup of coffee later.
2 Likes
-
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.
-
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 suits 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, and not only to development tasks.
-
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.
-
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.
-
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.
-
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 release them 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 overhaul and writing a new test from scratch.
2 Likes
This is an excellent post, @mirza. Full of a whole tonne of helpful advice.
Include Execution Evidence
This one stood as a real game-changer when it comes to test cases. I think it’s one of the most useful ways to start good conversations about your discoveries.
And the (Bill &) Ted meme made me 
.
1 Like
Thankyou . You are welcome.
2 Likes