I’ve seen some pretty bad test cases in my day.

Just to be fare I’m sure I’ve had a bunch of letdowns myself.

Alright maybe it was just once… yea one horrible test case. That sounds about right.

But seriously, if you work at a software company you’ve probably seen at least one poorly written test case.

If not well todays you’re lucky day.

Warning Poorly Written Manual Test Case Below Do Not Try This At Home!!

Steps: Enter invalide credentials.

Expected Results: Error message is shown.

If someone said this test passed you would have no idea what really happened.

Did they enter in an invalid user name? Was there an invalid password? Was the error message even about invalid credentials?

The most common reason for bad test cases is a poor description of the steps

Maybe at the time of writing this example was crystal clear. Things that are obvious now might not be in a few months.

So How Do You Avoid This Issue?

Like most things in life, it’s about the details.

Tip #1: Stop the bleeding.

Every time your creating a new test case do your future self a favor and write it like your working with the system under test for the very first time.

Tip #2: Work On The Backlog.

Go through your old test cases and clean up anything that can’t be ran by anyone on the team. Even someone that started this week.

But even with all of this, try to remember that excessive details are bad for maintainability. So shoot for a happy medium.

Remember you’re writing test cases for the company and not for yourself. You want the team to understand and benefit from the work that you’ve done.