How to Classify Positive and Negative Test Scenarios – A Tester’s Cheat Sheet

You can do something the easy way or the hard way – the important thing is that you do it. There are few simple everyday things, but without confidence, something about them does not quite fit in our minds and the extent of success is a hit or miss.

Let’s take one simple example today and find shortcuts that will not only clarify the concepts but also make sure that you will always get it right. 

Positive or negative classification of test scenarios/cases

Test design process is 3 fold:

• Identify requirements
• Write test scenarios (one line pointers of what to test)
• Design detailed instructions on how to test (test cases)

When writing test scenarios, we classify them into positive and negative conditions. (When you think about it, is it really important to make this classification? If yes, what purpose does it serve? We have to test them all anyways, isn’t it?) It beats me too, for the most part. But I think it is an attempt to establish adequate coverage and helps to establish that we are testing both the happy and alternate paths the system is supposed to handle. Please comment below, if you know of any other reasons why this is done.

Now, let’s look at a few requirements, write test scenarios and perform the classification.

#1) Login: A user who enters correct credentials gets into the system. If the credentials are incorrect, access is denied and an error message is displayed.

#2) View products: Let’s assume there is an online catalog of all the products available in the system and it displays them all in a list when “View products” link is clicked.

#3) Logout: When clicked on this link, the user is logged out.

I am going to write few Test scenarios for these requirements.

Table A: The right way

However, sometimes I see the Test scenario written like this.

Table B: Entries marked Red are invalid test scenarios.

For login’s successful case, there is an equal and opposite case when it won’t be successful. Not all requirements are supposed to be that way and for them, there is really no compulsion to write a negative scenario.

Bottom line: Not every requirement should have negative cases.

At this point, if you are thinking “How will I know” or “I’m still not sure”, here is a simple cheat sheet that will help.

If there is one generalization we can make about applications is that they are dynamic. The input (data, clicks, etc.) that we provide will cause the application to be a certain way and generate a certain output.

A simple correlation between the input and output variables will make this easy to comprehend.

Let us try the following for login:

So, you see from the above table, we can say that we categorize the primary flow as positive and the alternate flow (also the correct behavior of the application) is marked as negative.

The last two cases in red are in fact, bugs. Testing is about validation of requirements and when they don’t work as intended, we find bugs. Since we don’t go validating for defects, the last two cases are invalid.

Following the same line of thought and applying it to logout and view products, here is what you will get.

As you can see, for these requirements, there isn’t a possibility to supply an incorrect input. Therefore, there need not be negative test scenarios/cases written.

Concluding thoughts:

The system could be subjected to positive or negative input. Either way, the system should generate correct output. The cases that tend to deal with correct input are positive. The ones that are about correct but negative input are negative.

A few pointers:

#1) When an end to end test cases are written for UAT or even system testing, it is always the positive test cases that make it into the flow.

#2) Sometimes, the classification is subjective. For example, if I am deleting something on a site and I receive a confirmation message that asks me “Are you sure you want to delete this entry?” with OK and Cancel options – according to me clicking on cancel is a positive case. But some think, it’s negative as the primary intent of “Delete” option is to delete and not cancel the operation. So, a tester’s judgment also plays a part in the classification.

#3) For every positive case, there isn’t always an equal and opposite negative case.

The above method always guarantees correct classification. Try it yourself and tell me, if it does not. 🙂 “A shortcut is often a wrong cut.”- But then, it may not be in this case!

For a more formal explanation of Negative testing, please check => What is Negative Testing and How to Write Negative Test Cases?

About the author: This article is written by STH team member Swati S. Join her live QA training course here: “The best software testing training you will ever get!“

Please let us know if you have liked this article and want to see any such basic concepts explained easily in the coming articles.

Your comments, questions, feedback and readership is highly appreciated and valued here at STH. Happy testing!