Test Cases — what are they?
There is a formal definition of test case in Wikipedia or in ISTQB, but this definition would not help you to understand test cases nature good enough to write them right way.
The following article aims to help you to dig deeper into the world of test cases and look at them from an extremely practical perspective.
Let’s get started!
Definition of Test Case
Test cases are not (and should not be) something complex or extraordinary!
They are no less no more than instructions, simply notes, about modelling of special situations (test scenarios) made in order to verify that product fits its purpose:
Test Case — is an instruction about test situation modelling
Instruction — is a set of steps with clear results. And test situation modelling aims to verify product’s quality — i.e. product-requirements fitness. That’s what makes a test case!
The reason why test cases are written — is to help you to qualify products as fast and as cheap as possible, to share and generate test ideas, to document product’s functionality.
Good Test Case Criteria
To fit their purpose test cases must be simple, clear and easy to work with. And that’s why:
Each good Test Case — is a clear answer on 3 simple questions: “What?”, “Why?” and “How?”
Let me explain this a little bit more:
- What (to check)? The best place for an answer on this question is in Summary of test case. Ask yourself: what’s the Case? — and you’ve got a Summary for your test!
- Why (does this check exist)? Often the Reason for test case existence is clear and obvious from test case’s Summary. But also very often it’s better to give more Context for the test. Especially if this test is based on some bug, or it is not intuitive, or it will be delivered to another person or team who is not familiar with functionality (which also often happens).
The best place for an answer on this question — is right after test case’s Summary. Because, if test idea is not clear from test case’s Summary, then clarification is just waiting for you at the next line! - How (to check)? The best place for an answer on this question is in Steps and Expected results section of test case. This is the Way. The answer on smaller questions: where to go, what to do and what to expect.
Test cases, designed with these 3 questions in mind execute really well.
And everything, that executes well — is a quality thing!
That’s how we get quality products: with quality tests!
Example of a Good Manual Test Case
Below is an example of a real-life manual test case on High-Availability, written with these 3 simple questions in mind:
Indeed, take a look:
- What (is checked)? — Some service must be restarted when another service crashed
- Why (does this check exist)? — 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.
By the way, have you noticed, that each step of the test is written as a small test itself!? I mean each step is written with the same 3 simple questions in mind:
- What (do we do in this step)? —Bring meaning to the action before an action: “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 you don’t need to think and ask questions during this test case execution.
Conclusion
With this 3 simple questions technique you will be able to write quality tests like a beast! And that is good — because everyone wins in this case: you, your company, your product, and at last, but not least, — your customers.
If you have anything to comment, add or share regarding the topic of an article, please, do it! We are really interested in building useful, helpful and interesting content for you!
Thank you!
