The Best Test Case
This article aims to share with you some principal understanding about the what an ideal test case is, what’s a real-life one, what’s the difference between them and how to live with it.
An Ideal
The best test case is written with a one simple and clear sentence.
The Best Test Case — Is A One-Liner
The best test case — is a final idea, a concentrate. And it’s all about “what to check” and “what is expected” — told with a single line. For example:
- Monitor service is automatically restarted on crash
- MRB service does not start with invalid Backup locations configuration
- HMP service clears its cache during prompts deployment
Such test cases suppose, that you are in a context, in a ready-to-go environment, that you know a lot of “what”, “why” and “how”.
Ideal test cases build ideal checklists.
Reality
In real life things tend to get a little bit more complicated. Test cases almost always need to answer contextual questions as well. This is because test cases in their essence — are instructions about modelling of real life situations.
And that’s why, during test cases design we need to always think about the “what”, the “why” and the “how” — and answer on them.
Below is an example of a real-life manual test case on High-Availability, written with these 3 simple questions in mind:
You can easily find there all the answers on these 3 questions:
- What (is checked)? — Some service must be restarted when another service crash.
- Why (does this check exist at all)? — Because there are some limitations in failover procedure for some service — and a QA engineer explained this in “Idea” section, bringing more context for the test.
- How (to check)? — Steps with Expected results do the stuff.
More than that: each step of the test is written as a small test itself!
Each step is written with the same 3 simple questions in mind — to bring more context for executor:
- What (do we do in this step)? — Bring meaning to the action which is going to be executed: “Emulate hmpd service crash with sigkill”;
- Why (does this step exist)? — Often omitted because its obvious from a “global” test case’s “why?”;
- How (to do it)? — Exact, ready-to-copy-paste-and-execute command: “Execute command: kill -9 <PID of process>”.
Such simple and clear test cases really fit on their purpose: they help to qualify the product as fast and as cheap as possible — because executor doesn’t need to think and ask anyone (person or google) questions during this test case execution.
Simple and clear, right?
A word about Simplicity and Clarity
There are a lot of brilliant articles and books on this topic. And my personal favorite article is this one:
Software engineers should write because it promotes many of the same skills required in programming. A core skill in both disciplines is an ability to think clearly. The best software engineers are great writers because their prose is as logical and elegant as their code.
…
Bad code wastes CPU cycles; bad essays waste brain cycles.
As to me, this is valid not only for programmers, but for all software engineers. And I strongly recommend to every software engineer to have read at least one of these great books on copywriting:
- This book will teach you how to write better — by Neville Medhora
- Everybody Writes: Your Go-To Guide to Creating Ridiculously Good Content — by Ann Handley
- Write. Publish. Repeat. — by Sean Platt
- Don’t make me think — by Steve Krug
— they will teach you how to write and think better!
If you have anything to comment, add or share regarding the topic, please, do it! It’s our pleasure to build useful, helpful and interesting content for you!
