Write better test case steps
Avoid steps
As much as possible avoid writing test cases that require steps.
I know this is a bold statement. Especially for an article that aims to show you how to write better test case steps! But this is because test case steps consume a huge part of your time and energy and they still often leave much to be designed: written incomplete, too vague, often unclear, etc., etc. And they start require test cases management around them!
Instead of writing test cases with steps, I encourage you to write test cases with great titles as much as possible! Take a look how:
But if you can’t avoid steps, then write them right
We can’t write all test cases without steps. That’s impossible! Because test cases — are a Knowledge Base for our product or service. They keep valuable info about the product and instructions on how to model situations of real life, that the product or service can face.
That’s why I want to emphasize this again: as much as possible avoid writing test cases with steps. But if you need to write test case with steps — that’s fine, too! But write them right!
Test case steps done right
Test case steps done right do not leave you with questions! They answer your questions!
What questions do you have when you pass test case step by step?
They are 3 and only 3 simple questions: What? Why? and How? If you answer them in each of your test case steps, your steps become very simple and clear. More than that: Why? question is very often not required — so you answer only 2 questions for most of your steps: What? and How? And this is easy!
Example:
Title:
Nginx service on web server is automatically restarted on crashSteps:
1. Login to web server with ssh
2. Crash nginx service
3. Make sure nginx service was restarted and is running again
Why these steps are bad? Because they ask you for questions!
“Crash nginx service” Ya know how?? Do I need to go Stackoverflow to find out this? Then: “Make sure nginx service is running” — again to Stackoverflow? Or to internal wiki? Or to my memory? Why?
But what do you think about this:
Title:
Nginx service on web server is automatically restarted on crashSteps:
1. Login to web server with ssh
2. Find out nginx service process ID. Execute: pidof nginx
3. Crash nginx service. Execute: kill -9 nginx
4. Make sure nginx service was restarted. Execute: pidof nginx
Much better, right? Why these steps better? Because they answer 2 questions: What? and How?
We can even omit “Execute” word:
Title:
Nginx service on web server is automatically restarted on crashSteps:
1. Login to web server with ssh
2. Find out nginx service process ID: pidof nginx
3. Crash nginx service: kill -9 nginx
4. Make sure nginx service was restarted: pidof nginx
Looking good? Clear? Simple? Precise? Yeah!
And everything thanks to good steps, that answer 2 simple questions:
Title:
Something successfully/unsuccessfully happens at some conditionSteps:
1. What to do? (no need to explain how because a very common step)
2. What to do? How exactly?
3. What to do? How exactly?
4. What to do? How exactly?
We even didn’t use Why? here! And that’s fine!
But let’s use it?! Let’s introduce Why?
Take a look:
Title:
Nginx service on web server is automatically restarted on crashSteps:
1. Login to web server with ssh
2. Find out nginx service process ID: pidof nginx
3. Emulate crash of nginx service: kill -9 nginx
4. Make sure nginx service was restarted: pidof nginx
and we’ve got our Why? Easy!
Title:
Something successfully/unsuccessfully happens at some conditionSteps:
1. What to do? (no need to explain how because a very common step)
2. What to do? How exactly?
3. Why this command, why this step? What to do? How exactly?
4. What to do? How exactly?
Conclusion
Each great test case step answer 2 simple questions: What? and How?
Only What? or only How? — is not enough. Use both! And sometimes, for even more clarity, add Why? And you will be amazed how simple, clear and precise your test cases become!
But don’t stop here! Use better test case titles — and your test cases base will become much more agile and easier to work with!
Bonus for SQA Mate users
SQA Mate users have a special support for working with test cases without steps. Take a look:
This simple feature allows you to write steps only for some of your tests — just to provide instructions for the commands, pages, objects being used in tests in test suite. All other test cases titles are written with complete sentences — which makes test design more complete and test cases design much easier!
P.S.: if you liked this 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!
