How NOT to Write Test Cases (Tips for New and Experienced Testers)

Test case writing is one of the primary activities of the QA team. We spend most of our time writing, reviewing, executing or maintaining these. It is quite unfortunate that test cases are also the most error prone.

The differences in understanding, organization testing practices, lack of time etc. are some of the reasons why we often see test cases that leave a lot to be desired.

There are lot of articles on our site on this very topic, but today’s post will be about How NOT to write test cases – a few tips that will be instrumental in creating distinctive, quality and effective test cases.

Let’s read on and please note that these tips are for both new and experienced testers.

First things first- what are test cases and how do we write them?

Test case is a set instructions of “HOW” to validate a particular test objective/target, which when followed will tell us if the expected behavior of the system is satisfied or not.

For basic instructions on how to write test cases, please check the following article and the video:

Writing Test Cases from SRS Document

and watch this nice video with tips and tricks on HOW TO write good test cases:

The above resources should give us the basics of the test case writing process.

What You Will Learn:

3 Most common Problems in Test Cases:

Now, the most common problems I see in the test cases these days, both from my students and colleagues at work are:

  1. Composite steps
  2. Application behavior taken as expected behavior
  3. Multiple conditions in one test case

These three have to be on my top 3 list of common problems in the test case writing process.

What’s interesting is that these happen with both new and experienced testers and we just keep following the same flawed processes never realizing that a few simple measures can fix things easily.

Let’s get to it and discuss each one in detail:

#3. Composite steps:

First off, what is a composite step?

For instance, you are giving directions from Point A to point B: if you say that “Go to XYZ place and then to ABC” this is not going to make a lot of sense, because here we find ourselves thinking – “How do I get to XYZ in the first place”- instead starting with “Turn left from here and go 1 mile, then turn right on Rd. no 11 to arrive at XYZ” might achieve better results.

The exact same rules apply to test cases and its steps as well.

For example: I am writing a test case for – place an order for any product

The following are my test case steps (note: I am only writing the steps and not all the other parts of the test case like the expected result etc.)

a. Launch

b. Search for a product by entering the product keyword/name into the “Search” field on the top of the screen

c. From the search results displayed, choose the first one

d. Click on Add to Cart in the product details page

e. Checkout and pay

f. Check the order confirmation page

Now, can you identify which of these is a composite step? Right- Step (e)

Remember, test cases are always about “How” to test so it is important to write the exact steps of “How to check out and pay” in your test case.

Therefore, the above test case is more effective when written as below:

a. Launch

b. Search for a product by entering the product keyword/name into the “Search” field on the top of the screen

c. From the search results displayed, choose the first one

d. Click on Add to Cart in the product details page

e. Click on Checkout in the shopping cart page

f. Enter the CC information, shipping and billing information

g. Click Checkout

h. Check the order confirmation page

Therefore, a composite step is the one that can be broken down into several individual steps. Next time we write test cases, let’s all pay attention to this part and I am sure you will agree with me that we do this more often than we realize.

#2. Application behavior taken as expected behavior

More and more projects have to deal with this situation these days.

Lack of documentation, Extreme programming, rapid development cycles are few reasons that force us into relying on the application (an older version or so) to either write the test cases or to base the testing itself on. As always, this is a proven bad practice- not always really. It is harmless as long as you keep an open mind and keep the expectation that the –“AUT could be flawed”. It is only when you do not think that it is, things work badly.

As always, we will let the examples do the talking. If the following is the page you are writing/designing the test steps for:

Case 1:

If my test case steps are as below:

  1. Launch the shopping site
  2. Click on Shipping and return- Expected result: The shipping and returns page is displayed with “Put your info here” and a “Continue” button

Then, this is incorrect.

Case 2:

  1. Launch the shopping site
  2. Click on Shipping and return
  3. In the ‘Enter the order no’ text box present in this screen, enter the order no.
  4. Click Continue- Expected result: The details of the order related to shipping and returns are displayed

Case 2 is a better test case because even though the reference application behaves incorrectly, we only take it as a guideline, do further research and write the expected behavior as per the anticipated correct functionality.

Bottom line: Application as a reference is a quick short cut but it comes with its own perils. As long as we are careful and critical it produces amazing results.

#3. Multiple conditions in one test case

Once again, let’s learn from example – Take a look at the below test case steps: The following are the test steps within one test case for a login function.

a. Enter valid details and click Submit

b. Leave User name field empty. Click Submit

c. Leave the password field empty and click Submit

d. Choose an already logged in username/password and click Submit

What had to be 4 different test cases is combined into one. You might be thinking- What’s wrong with that? It is saving a lot of documentation and what I can do in 4, I am doing it in 1- isn’t that great? Well, not quite. Reasons? Read on:

Hence, write modular test cases. It sounds like a lot of work but all it takes for you is to separate things and use our best friends Ctrl+C and Ctrl+V to work for us. :)

In conclusion:

That was a quick round up on a few commonly happening test case documentation problems. Please do let me know if you have faced any of your own that you would like for us to talk about in the coming articles.

Your feedback, comments, questions, readership and participation is highly appreciated.