4 types of Test Cases titles that QA Engineers write
Prephase
I develop SQA Mate — test cases management system that aims to help QA Engineers to evaluate software quality as fast as possible.
This aim is closely tied with test cases design: the better and simpler design and process of design — the better software we have as a result. That’s why I always interested in what QA Engineers write in their test cases and how do they write them and when and why and so on…
After a few years of analysis I found that Manual QA Engineers write 4 types of titles in their test cases. I even gave them such names:
- Epileptic style
- Russian-roulette style
- Have-no-clue style
- Checklist style
My personal favorite is “Checklist style”: if it’s used properly, then it helps QA a lot now and in the future!
But, let’s see everything in order! Let’s get started!
Epileptic style
I hate this style! Usually, it is one-word title.
I call them “epileptic style” because when I see them (usually, a bunch of them in a test suite), I imagine QA Engineer in “epileptic attack” who is hitted by “test cases ideas” and just “write them down as they appear”: Login! Logout! A! O! U! And then, suddenly, had no time to make that title more verbose.
Example of such test cases “titles”:
- Login
- Logout
- Start
- Stop
- Input
- Cross-Platform
- Performance
- UI
- Total
These are real examples from real test cases!
I guess, no one understands: neither what’s happening, what is exactly verified, and how and what’s the system reaction expected — nothing!
Guys, please, don’t do it! Even if you are the only 1 QA on the project!
Why not? Because test cases — are knowledge base for your product. Because test cases are written for humans (and other QA that can join your team later or DEV, OPS, PM, etc. want to read them). More than that, coverage is not visible with such “titles”.
Russian-roulette style
A gun. Sometimes, a machine gun (with tens of such test cases in test suite). Bang! Bang!! Baang!!! Test cases look like this:
- Corrupted field: “to”
- Corrupted field: “from”
- Corrupted field: “type”
And overall pattern is:
- Bla-bla: X
- Bla-bla: Y
- Bla-bla: Z
Sometimes they get super-charged guns:
- Bla-bla: Bla-bla-bla: Bla-bla: X
- Bla-bla: Bla-bla-bla: Bla-bla: Y
- Bla-bla: Bla-bla-bla: Bla-bla: Z
Not smart at all! But QA write them! A lot!
Why don’t you put them in a folder (suite) “Corrupted field” and then write test cases titles with more comprehensive, more human description, than just “to”, “from”, “type”…?
Please, avoid such “revolvers”!
Why not? Because they don’t tell anything about system expected behavior. They just set conditions: X, Y, Z,… But what happens to the system? Also, they are usually copy-pasted, i.e. your passion and carefulness shines through them.
Have-no-clue style
“Have-no-clue style” test cases have much more information compared to a single-word titles of “epileptic style”, but still… have no clue!
Look at them:
- Get participant status
- Drop participant
- Button ‘Add Email’
- One Time Zone
- Connection (next day)
- Login several users
- Login several accounts
Have no clue what the exact system behavior is verified!
Checklist style
This is my favorite. I recommend this style for most use-cases! The thing is to tell a simple, yet complete sentence about the system behavior at some conditions:
- Automatic Deployment System successfully deploys “ABC” service via “Full-Deployment” procedure
- FAX server finishes call session correctly on SIP BYE received after SIP re-INVITE
- Load Balancer Server responds with SIP 200 OK on SIP OPTION if there is at least 1 available downstream server
Even if you don’t know mentioned protocols or systems, you easily understand: what’s happening, with what objects, at what conditions.
The pattern for such titles is:
- “Something successfully/unsuccessfully does something when something happens”
or
- “On some event something successfully/unsuccessfully does something”
Easy. Clear. Simple. And in a lot of test cases (especially for small agile-teams), you even don’t need to describe the steps — because everything is already clear.
Why do? Because they are simple and fast to create. They a human. Coverage is also obvious — because they look good. They ask you to structurize them in folders — which brings a structure to you “knowledge base” called “test cases base”. And more: they are easily extended with test cases steps if required, evaluating to “orthodox” test cases — so you can provide all the details of the way to execute the test.
Conclusion and Recommendations
Write test cases titles with complete sentences with pattern:
- “Something successfully/unsuccessfully does something when something happens”
or
- “On some event something successfully/unsuccessfully does something”
because test cases — are knowledge base for your product or service made by QA Engineers — people, who touched the app last before it went to PRO. They explain what happens to software under different situations and do it in a human way. Because test cases are made for humans. Even auto-tests and even program code — everything is created simple and clear not for machines, not for computers, but for us, for humans!
P.S.: If you liked an article and found it useful, please, don’t hesitate to give it some claps — to let more people to know about it!
Thank you!
