You know, I once came in partway through a project with test cases that were a little light on the details, like:
It was a little perplexing to say the least. How do I move a team and what’s meant to happen once I do it? The other testers were just as confused as I was by this cryptic instruction. I ended up mandating that test cases have steps and verification points, believing that more information was better. I stood by that belief for quite some time, until I came in partway through a different project with test cases which were VERY thorough, a bit like this:
Is the username text field there?
Is the password text field there?
Is the Login button there?
Type your username into the username text field.
Type your password into the password text field.
Click the Login button.
Did the welcome pageload?
Did the picture of Snarfy the Cow appear at the top of the page?
Does the text at the top of the page say “Welcome to Snarfy’s barnhouse of fun!”?
and I don’t mean that was one test. I mean that was part of every single test case that was written. Some of these test cases had more than 150 verification points. Can you imagine how long that would take to test?
Honestly I believe if you want to try either of these options, there’s a much easier test case to write:
Point at foot
because either way, you’re going to end up with frustrated crazy testers and who knows what that will lead to? A desolate wasteland of despair where untamed bugs feast on the grisly remains of your software, that’s what. What a terrible thought.
So just try to aim somewhere in the middle, yeah? No need to list out every little step along the way, that’s what user guides are for after all. No need to be too general in order to increase test coverage, that’s why you have more than one test case after all. Just make sure the test cases have a purpose and an expected result defined, that’s all I ask. And maybe make them a pretty colour, just for the heck of it. Just because test cases are bland and dull, doesn’t mean they can’t look attractive!