How Not to Write Test Cases? (Most Common Problems in Test Cases)

This is the third article in the series of our articles about test cases. In this article, we are discussing How Not to Write Test Cases? (Most Common Problems in Test Cases).

Software testers devote most of their time writing, reviewing, executing, or maintaining test cases. Let’s see How NOT to write test cases, a few suggestions that will help to create unique, quality, and effective tests.

1. Combined/Composite Test Steps

First of all, what is a composite step?

For Example, I am writing a test for Amazon.com to place an order for any product.

The following are my test steps (Note: We are only writing the steps and not all the other parts of the test like the expected result etc.)

i. Launch Amazon.com

ii. Search for a product by entering the product name or code into the “Search” field on the top of the screen.

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

iv. Click on Add to Cart on the product details page.

v. Checkout and pay.

vi. Check the order confirmation page.

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

Remember, tests 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.

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

i. Launch Amazon.com

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

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

iv. Click on Add to Cart on the product details page.

v. Click on Checkout on the shopping cart page.

vi. Enter the CC information, shipping, and billing information.

vii. Click Checkout.

viii. Check the order confirmation page.

Hence, a composite step can be broken down into several individual steps.

2. Application behavior is taken as expected behavior

Many projects have to deal with this situation these days. Lack of documentation and Rapid development cycles are a few reasons that force us into trusting the application (an older version) to either write the tests or to base the testing itself on. As always, this is a proven bad practice- not always.

It is harmless as long as you keep an open mind and keep the expectation that the “application under test could be flawed”. It is only when you do not think that it is, things work badly.

Suppose you are writing the test steps for the shopping site. Consider the following cases:

Case 1:

If your 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 information 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 on 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 expected correct functionality.

3. Multiple Conditions in one case

Once again, let’s learn from an Example.

Look at the underneath test steps: The following are the test steps within one test for login functionality.

a) Enter valid details and click Submit.

b) Leave the Username field empty. Click Submit.

c) Leave the password field empty and click Submit.

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

We have combined four different cases. You might think, what’s wrong with that? What if one condition fails then we have to mark the entire test as ‘failed’. If you mark the entire case ‘failed’, it means all four conditions are not working, which is not true.

Tests need to have a flow. From pre-condition to step a) and throughout the steps. If you follow this case, then in step a), if it is successful, you will be logged on the page, where the “login” option is no longer available. So, when you reach step b) where is the tester going to enter the username? The flow is broken.

We’ve written this article to give you the insight to avoid mistakes in writing test cases. Stay connected with us and check out our series of articles to know more about test cases and share your thoughts in the comments!