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.

how not to write test cases

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.

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 Amazon.com – 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 Amazon.com
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 Amazon.com
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:

tips for test cases

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

testing meme

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:

  • What if one of the conditions fails – we have to mark the entire test case as ‘failed’. If we mark the entire test case ‘failed’, it means all 4 conditions are not working, which isn’t really true.
  • Test cases have to have a flow. From precondition to step 1 and all through the steps. If I follow this test case, in step (a), if it is successful, I will be in the logged on page, where the “login” option is no longer available. So when I get to step (b) – where is the tester going to enter the user name? You see, the flow is broken.

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.

Recommended reading

29 comments ↓

#1 Rahul Suryavanshi

thanks.

#2 Srijeet

I saw many topics on how to write test cases but this one is first on how NOT to write :)

#3 Bilal

Good info… Thanks :)

#4 Priya

First time ever we’ve got an article about things to be avoided in test design, Very useful.

#5 Ramani

Thanks. Very useful information.

#6 Anand Chandran

Really a good topic for tester. Every tester should aware of this.

#7 Parthiban S

#3. Composite steps:

Is wrongly mentioned as #3 actually it is #1 :)

#8 Parthiban S

#3. Composite steps:

Its should be #1

#9 Aga

Thanks. It’s very useful!

#10 Vasanthi

Thanks this is a very informative article.

#11 Swati Seela

@Parthiban S: Its a count down of sorts :) Thank you for your readership!

#12 Swati Seela

@All: Thank you for letting us know this article is useful. Appreciate your readership!

#13 HarishBora

Very Nice article on test cases basics

#14 Chetan Phulwar

Thanks ,nice article it clears basics of test case writing

#15 Darshan

One problem I faced during Mobile application testing is how to write test cases where we follow some set of actions on device 1 and expect some expected result on multiple devices as well as device 1.

e.g. Playing poker game on device 1 and expect output on all connected devices device 2,3,…n

#16 Ameet

Good one. i guess writing composite steps in test cases is ok if you are an experienced guy and the change you are testing is not that basic as tested by freshers, in which case fresher would find difficult to understand test case with composite steps…..i mean only writing composite steps but testing in detail…..

#17 anitha

thanks….it is very useful for freshers and novice.

#18 anitha

thanks a lot

#19 Ragavanka

I agree all the points mentioned. As the situation is hypothetical. We all know that stakeholders need the product on live very soon. So that product compete in the market and get all the analytics in the improvement of the product. So they all cut down each and everything into short. And also we need to be on the same track. Hence what I follow in my company is that going against your points. Follow whatever you have said not to do. :-) There are prons and cons in both the way. I had lot of debate on these points in my company. But one final thing is how the product is sustained in the market is more important. As we all know exhaustive testing is impossible, sameway here it holds good.

#20 Deepak

that’s a nice way to make understood any beginners those are new to software testing.

Thanks !!

#21 Rashid Malik

Dear, this is very interesting and effective article regarding Test Case because you provide easily understandable article and adding some examples to make it practical. Thanks a lot to give your valuable time for us.

Thanks!!

#22 ASHOK KUMAR GUAL

hello,
I found “unreachable browser exception” while doing Automation Testing using Selenium Webdriver.
I want to know the exact reason behind this exception and how to fix it.
please do let me know…

waiting for the your answer.

regards
Ashok Kumar Gual

#23 Prem

@ASHOK KUMAR GUAL
Here is the answer of your question.

https://selenium.googlecode.com/svn/trunk/docs/api/java/org/openqa/selenium/remote/UnreachableBrowserException.html

#24 Shishir

SENT U 20 email to confirm receipt of payment and send me link to videos . Still waiting your response

#25 Istvan

Thank you for your topic. It is helpful for me.

#26 Jens

About #3. Multiple conditions in one test case

In some cases it is useful to Combine more than one condition in a test case for the purpose of saving time or finding bugs that otherwise would not appear. Here is an example:

Imagine the mentioned login dialog.
1. enter the user name
2. leave the password blank (or misspell it)
3. click submit
-> an indicator shows you that you cannot log in
4. correct your Password
5. submit again
-> normally you would log in, however, due to a bug you cannot because the software was implemented poorly and the “wrong Password” flag is still true.

You wouldn’t find that one without combining two conditions.

I agree, though, that you have to be very careful doing that.

#27 Archana pandalaneni

Good one…Now i am very much clear on how not to write test cases.

#28 Romee

Lets say if the AUT have dropbox and in that dropbox there should be correct items like item1, item2, item3 which we have to check. Do we include this in test cases too??

#29 saloni

It was a beautiful explanation on the basics of testing , very clear and simple. Look fwd to read and hear more of your tutorials.

Leave a Comment