Write better test cases titles

December’2020 update

I’ve made a workshop for this practice. If you interested in writing test cases and bugs titles better, take a look:

Workshop: “Write better titles for your bugs and test cases”

Prephase

I am for more than 10 years in Software Testing already and during last several years I’ve become very interested in what QA Engineers write in their test cases.

I participated in a lot number of projects during last years, I looked at another projects test cases, I reviewed our test cases base (which is more than 100.000 test cases for today), I participated in a number of QA conferences where test cases design has been debated…

Test cases titles — are the most powerful part of test cases. And this part is too often misused.

And what I found is that test cases titles — are the most powerful part of test cases. And this part is very often misused even by very experienced QA Engineers. And I’d wanted to help to fix this with this article.

During my investigations I found that QA Engineers usually write 4 types of titles. And this naturally demonstrates how our brains work: from an idea of test case that “strikes” our mind “out of Space” (“epileptic style” of test cases titles) to a complete thoughtful sentence (“checklist style” of test cases) of a conscious mind.

And the gap between them, between such test cases and their author’s experience is huge. And what is that experience? What is that understanding? Let me explain that.

What Test Cases are at their core?

Test Cases — are instructions for modeling of some situation of real life.

Test Cases — are simply instructions for modeling of some situation of real life. The more clear, the more simple these instructions — the better. And very often you don’t need complete instructions for modeling of test situation. Instead, often you just need a reminder of “what should be tested”. And clear, simple, yet complete test case title can be such a reminder.

If you are interested in this topic, take a look at this article:

Test Cases — what are they?

Test Cases are for humans

Well-written test case is much easier to be read and much faster to be understood.

Test Cases are much more often being read than being written. That’s why well-written test case is much easier to be read and most importantly to be much faster to be understood.

Well-written test case does not waste “brain cycles” of a reader (same as good code does not waste CPU cycles). And this does not happen automatically! This happens when test cases author put this “don’t make me think” thought into test cases. I.e. clarity and simplicity are built into test cases by their authors. And they did that intentionally, because test cases — are for humans.

Code and Test Cases — are for humans

Test Cases form a Knowledge Base

Test Cases — are not scenarios that try to break the system. They are scenarios that aim to get knowledge about the tested system, to get a sure, to get assurance, a quality assurance about the tested system. That’s why test cases tend to form a Knowledge Base about your system. And if this crafted fine, then test cases base becomes a very powerful tool for different purposes: from regression testing to newcomers education.

Test Cases — are Knowledge Base for your system

Test Cases — are Knowledge Base for your product or service

So, why better Test Cases titles?

This understanding of test cases nature that comes with years of QA experience pushes us to investigations in test cases design (writing test cases) and in test design (forming test coverage). And these investigations demonstrate, that great test cases titles perform very well on purpose and help us to improve both test cases design and test design, saving us a lot of time and energy.

The Fidelity Curve: How to weigh the costs and benefits of test cases design

What is the best test case title?

The best test case title — is a short yet complete sentence that answers 3 simple questions:

• what’s an object?
• what’s it’s behavior?
• at what condition?

For example, test case titles like:

• Login
• Logout
• Forgot password

do not answer these questions. Actually, they ask for more questions! What Login? What Logout? Successful/unsuccessful? Who? When?

That’s why test cases with titles:

• Login with valid credentials
• Login with invalid credentials
• Login with empty credentials

also do not answer all these questions and that’s why they force us to ask more questions or (worse) to make assumptions. Login with invalid credentials — and what is expected? Go to read test case body to understand that? Why? Why to do this, if we could just a bit extend test case title to answer these questions already!

Take a look:

• System successfully authorizes user who logged in with valid credentials
• System does not allow to login to user who tried to log in with invalid credentials
• System does not allow to login to user who tried to log in with empty credentials

Clear? Simple? Yes. And you can detail that “does not allow” if you want. For example:

• System does not authorize and shows a warning message to user who tried to log in with invalid credentials

Right? Yes.

The only complain to this — is that sentences may become too long to read. That’s why don’t make a composition, don’t write long sentences. Write simple and clear sentences that answer just 3 questions. That’s enough for most use cases!

And it actually looks good in test cases management system and helps you to improve your coverage, because you start to see missed verification scenarios when you look at these sentences, standing right to each other:

Screenshot from SQA Mate test cases management system

P.S.: If you liked an article and found it useful, please, don’t hesitate to give it some claps — just to let more people to know about it!

Thank you!