The Fidelity Curve: weigh the costs and benefits of different approaches in test cases design
About 2 years ago Ryan Singer wrote a great article about the costs and benefits of creating UI mockups:
and I was very impressed by his article because the same principles could be applied to explain details in test cases design.
A few months ago I wrote an article:
where I told about my observations on test cases titles design. And this observation is highly bound with test cases design fidelity curve, because “Checklist-style” title for test cases (most optimal title for most test cases) — is a “Complete sentence title without steps” on a fidelity curve below:
“Ideas style” — is an “Epileptic” or “Russian roulette” or “Have no clue” style for test cases titles. Such test cases titles look like:
- Power on
- Power off
- Login
- Logout
etc. — and almost no one but an author of these “test cases” can understand them, their goal, what should be done, what are conditions and what is an expected outcome.
“Complete sentence style” — is a “Checklist” style for test cases titles. Such test cases titles look like this:
- Nginx service does not accept an empty nginx.conf file during reload configuration
- Nginx service accepts regular expressions in “server_name” option in nginx.conf
- PostgreSQL service does not start if there is no free space available for the database
etc. — and almost every IT engineer can understand the idea of the test, conditions for the test and what is expected from such test cases titles. You spend a bit more time to write such “longer” sentences, but the gained benefits are enormous for such amount of time:
- you give much more details for a better search, for better test case understanding, better execution by your teammate without providing any steps;
- you increase test cases coverage because you find more and more test scenarios and test conditions simply looking at your sentences;
- you structure test cases better, putting them into folders — which brings even better coverage;
- everyone in your team can read these test cases and exactly understand 3 things: what is tested, how and what is an expected outcome;
- these test cases could be easily flushed with steps — and this will bring them to an “Orthodox style” test cases — test cases, that could be understood by a newcomer or any other QA engineer in the company:
Lots and lots of benefits for almost the same amount of time, compared to “most used” “Ideas style” test cases and much less time and mental efforts spent compared to “Orthodox style” test cases with steps.
Conclusion
Every QA engineer would like to write test cases fast, simple and clear.
To achieve this I personally found this fidelity curve in test cases design and I recommend you to use it in your daily QA practice.
And note that this “Complete sentence” approach is perfectly tied with an “Ideal Test Case” (which is a one-liner):
Thank you!
