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 and negative test scenarios

Positive or negative classification of test scenarios/cases

Test design process is 3 fold:

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

Test scenario IDTest scenario descriptionPositive/Negative
TS_login_01Validate if the user logs in successfully if the credentials entered are correctPositive
TS_login_02Validate if the user is not allowed access when the credentials entered are incorrectNegative
TS_ViewProduct_01Validate if all the items are listed when View products link is clickedPositive
TS_logout_01Validate if the already logged in user is signed out of the system when logout is clickedPositive

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

Table B: Entries marked Red are invalid test scenarios.

Test scenario IDTest scenario descriptionPositive/Negative
TS_login_01Validate if the user logs in successfully if the credentials entered are correctPositive
TS_login_02Validate if the user is not allowed access when the credentials entered are incorrectNegative
TS_ViewProduct_01Validate if all the items are listed when View products link is clickedPositive
TS_ViewProduct_02Validate if the all the items are not listed when view products link is clickedNegative
TS_logout_01Validate if the already logged in user is signed out of the system when logout is clickedPositive
TS_logout_02Validate if the user does not log out when logout link is clickedNegative

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:

InputOutputPositive/Negative
Correct (correct login info)Correct (User logged in)Positive
Incorrect (incorrect login info)Correct (An error message)Negative
Correct (correct login info)Incorrect - Login failsBug/Defect
Incorrect (incorrect login info)Incorrect (system logs them in) – “Oh, the horror!” :)Bug/defect

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.

InputOutputPositive/Negative
Logout (click)Correct - Logs outPositive
Logout (click)Incorrect - Stays signed inBug/defect
View products (click)Correct - Displays productsPositive
View products (click)Incorrect (not list or incorrect list display)Bug/defect

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!

Recommended reading

13 comments ↓

#1 Ahmed Fathi Elgaly

As am always expect from Softwaretestinghelp.com, it is very useful article, and I hope more and more.

#2 Kiran

Cant believe anybody writes the test scenarios like the invalid test scenarios you showed as example. Its overcomplicating simple things. But yes, anything is possible:)

#3 Swati Seela

@kiran: the point isn’t about which way we are writing. It is about being able to figure out what alternate behavior exists for a certain functionality. Whether you write it this way, another way or not at all if really an individual choice. Thanks for stopping by :)

#4 James Kamara

I have found the info very helpful and well structured and easy to follow, which is great when you are new to subject like this. Please keep it coming

#5 kumar

Saying about new things always interesting, but saying interestingly about known things always challenging. Job well done Swati.

#6 md rahman

Awesome STH !!

#7 Testlakkie

I think it’s as easy as:
Positive testing is following the flow and prove the product is functioning as expected.
Negative testing is putting in incorrect or unexpected data, formats etc. Try out the unexpected to prove the robustness of the product. Act as a user!

#8 Gaurav Khurana

“Validate if the user is not allowed access when the credentials entered are incorrect”

I don’t think this is a true negative case. As here we are testing a requirement which says – “User should not be allowed to login with incorrect credentials”.
Negative cases would be the things which a user in generic case may not do.

example:- “Clicking on logout button 3-4 times continuously”
“Copy paste a username/password”
“Clicking on back button and then forward to check if the account is still logged in”

So these are some negative things we are trying which is not the requirement but some users may do it by chance or intentionally

#9 Prisha

Wonderful article!! Great help thanks

#10 wills

test

#11 Mike

good

#12 Mohammed

Positive = happy scenario
Negative = unhappy scenario

Am I right ?

#13 Nagasiva

I think it is good artical and helpfull for freshers….

Leave a Comment