Middle ground

By Trish KhooTest cases

You know, I once came in partway through a project with test cases that were a little light on the details, like:

Move team.

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:

Start application
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:

Load gun
Point at foot
Pull trigger

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!

3 thoughts on “Middle ground”

  1. One of the positive things of the example above (which obviously still needs to be cut back) is the injection of verification points into the steps. My head explodes when I have a test case that has a long series of steps and all the verification points at the bottom. I find myself constantly moving my eyes and trying to focus on what I’m doing than actually doing it. Then there’s the constant scrolling thanks to TFS’s insane panoramic content view.

    Anyway, you could use different colours to differentiate verification from steps. I would personally give more visual weight (not bold, just a colour with more contrast) towards the verification points and the steps can be used as guidance when it isn’t self-evident.

  2. I currently use Rational Manual Test, which differentiates verification points from steps by having either a tick icon (VP) or a footprint (step). It makes it pretty clear as to what is going on.

    I agree that it is nicer to have the verification points along the way if necessary, but I also believe in making short test cases that are as focused as possible, so that you can tell at a glance what the problem is when the test case fails. Obviously the first example is *too* short, but I usually go for something more along the lines of:

    1. Login as administrator.
    2. Go to team management page.
    3. Create a team.
    4. Move the team to location A.
    VP1: Verify location A contains the team.
    5. Move the team back to location B.
    VP2: Verify location A does not contain the team, and location B does contain the team.

Comments are closed.