This is an old joke, but it’s still one of my favorites about testing.
A software tester walks into a bar…
Runs into a bar.
Crawls into a bar.
Dances into a bar.
Flies into a bar.
Jumps into a bar.
And orders…
a beer.
2 beers.
0 beers.
99999999 beers.
a lizard in a beer glass.
-1 beer.
“qwertyuiop” beers.
Testing complete 
A real customer walks into the bar and asks where the bathroom is…
The bar explodes.
One of the topics we cover in our Writing Test Cases for Software Requirements class is the concept of positive versus negative test cases. It sounds like a simple concept, right? Interestingly enough, it’s easy to get turned around and confused.
What’s the difference?
Positive test cases ensure that users can perform appropriate actions when using valid data.
Negative test cases are performed to try to “break” the software by performing invalid (or unacceptable) actions, or by using invalid data.
Let’s take a straightforward example. Here’s a simple user story:
As a Training Admin
I want to add a class to the schedule
So that we can accept student enrollments for the class
The positive test case would ensure that a new class (with all valid data) can be added to the schedule. Negative test cases would try to “break” the software by testing things like:
- Creating a new class when no rooms are available
- Creating a new class on a date in the past
- Creating a new class with an invalid course title
- Etc
The distinction between positive and negative is pretty clear for this requirement.
What’s the problem then?
It gets hard when requirements are written to describe what the software should do when somebody tries to break it. I term these “negative” requirements. Let’s say you have a user story that says:
As an Information Security Specialist
I want to prevent unauthorized users from accessing the system
So that we comply with regulations regarding the use of confidential and sensitive information
This is the point where some people say, “OK, the positive test is trying to have an unauthorized user log in and making sure that the system doesn’t let you do that.”
Actually, no. Trying to log in as an unauthorized user would still be a negative test. Why? Remember our definition of positive and negative test cases:
- Positive Tests: Acceptable actions, valid data
- Negative Tests: Unacceptable actions, invalid data
Regardless of how the requirement is written, attempting to access the system as an unauthorized user is an unacceptable action. Since it’s an unacceptable action, it’s a negative test.
Is your head hurting? What if I re-wrote the user story to say:
As an Information Security Specialist
I want to ensure that only authorized users can access the system
So that we comply with regulations regarding the use of confidential and sensitive information
Now, does it make sense that trying to log in as an unauthorized user is a negative test? It’s sort of like going back to high school English class when your teacher talked to you about double negatives. Or math class where you had to figure out what to do when you multiplied negatives and positives.
Some Ways to Think About It
Since most of us have no desire to go back to high school math or English, let’s look at some other ways to get this straight. Some analysis artifacts can be really helpful. As an example, consider the following user story:
“As an instructor, I want to be able to schedule vacation time so that I don’t get scheduled to teach when I’m not available.”
Acceptance criteria:
- Should only be able to schedule vacation time in the future
- Can only schedule vacation time for myself
- Can’t take more than my annual allotment
- Don’t allow more than two consecutive weeks of vacation to be scheduled
The story is typically written to describe the valid action that the user wants to take, and positive tests can be derived from it. Acceptance criteria often describe invalid actions or data, and negative tests can be derived from them.
Likewise, consider a use case for adding an item to a customer’s shopping cart in a mobile app for a grocery store. The primary (happy) path leads us naturally to a positive test case – successfully adding an item to the cart. The alternate paths often identify negative test cases. This would include things like trying to add an item that’s out of stock or can’t be sold through the app, or exceeding the quantity allowed for a sale item. Also, if you’ve written misuse cases or abuse cases, those also can often be used to identify negative test cases.
Flowcharts can also help. The main flow through a flow chart typically leads us to the positive test case. All the branches from our decision points can be examined to try to identify negative test cases.
Process Flow Chart Symbols Job Aid
A cheat sheet for the most frequently used symbols in various types of common flow charts, including ANSI, BPMN, UML, Value Stream Mapping, and SIPOC.
Who cares?
Good question! It’s essential to remember that the most important objective of testing is to find defects. And the most likely way to find defects is by taking unexpected actions or using invalid data. In other words… the most likely way to find defects is by doing negative tests. This means it’s really important to be able to distinguish between the two so that you use your (typically very limited) testing time wisely.
Think positive!
If you’re stumped, remember to think positive! If it’s a good thing, something you should be able to do, it’s generally a positive test. If it’s a bad thing, something you shouldn’t be able to do, it’s generally a negative test.
Happy testing,
Kathy
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
