Using Heuristic Test Oracles
- Enter the HICCUPP Heuristic
- Crossover Among Oracles
- HICCUPP Applied
- You Take It from Here
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Quick! Test the application in Figure 1! No really, test it. It’s Google Earth (Beta version 3.0.0762). It’s okay, I’ll wait for you. Just don’t take more than an hour. I’ve got other people to share this example with.
)
Figure 1 Very cool Google software.
How did you do? Did you find any bugs? I found the little beauty in Figure 2just a couple of minutes into my testing. It seems that if you search with large strings, Google Earth thinks it has a network error. What’s even more interesting is that it actually changes your search criteria. I found that if I searched with a 5,000-character counterstring followed by a 1,000-character counterstring, Google Earth changed my search criteria back to the 5,000-character counterstring. It continued to do this for several different values.
)
Figure 2 Searching with large strings led to this error message.
Is this a good bug? Probably not—there’s a low likelihood that someone will actually have a valid reason to search with 5,000 characters. Is this a bug that should be fixed? Eventually—most likely there are more important bugs to fix (like the funny white lines when rendering). However, bugs like this are like blood in the water. They tell me that the developer may not have the control over the application that he thinks he has.
What does all this have to do with heuristic test oracles? Suppose you ask me, "How do you know the behavior you found above is a bug? You don’t have any requirements telling you what the software should do." To that, I might answer, "Uh, well...it just didn’t seem right to me." But that response wouldn’t win many supporters, would it?
Instead, I need to say something like, "I believe it’s a bug because the message states that there’s a network problem, and yet searches with smaller values still work. The search feature behaves inconsistently given the same network conditions. In addition, the search field changes my search text after I get the error message, but it doesn’t do that before I get the error message. That’s also inconsistent behavior. Finally, I truly don’t believe that there’s a network error, which means that Google Earth is reporting an inaccurate error message. I don’t believe Google really wants to report inaccurate error messages. That makes them look bad. That’s not good for their company image."
The rest of this article is intended to help you develop a vocabulary for explaining why you feel that something you find that looks wrong is in fact a bug. Rather than being forced to rely solely on incomplete requirements ("Where’s the requirement that says we should spell everything correctly?") or having to put your reputation on the line ("I think it’s a bug, and you should fix it because I’m a good tester"), this article offers some simple heuristic test oracles you can use to explain why you think something is a problem.
Enter the HICCUPP Heuristic
Last year, while I was working with James Bach, he had me test some small applications. When I would find a problem, James would ask me to explain why I thought that what I found was a problem. I quickly discovered that I had no vocabulary for why I thought that something was a problem. There were no requirements documents around, so I couldn’t point to something and say, "Look there. It’s a problem because that says so!" Instead, I just looked at him and said, "Well, it seems like it should work like this, not like that."
Obviously, that wasn’t good enough. James is fairly good at role playing, and I quickly got everything from a defensive developer ("Well, I don’t care if you’re a good tester—I’m a good developer, so it’s not a bug!") to a dismissive project manager ("Well, that’s just your opinion"). It seems that most people don’t react well when they suspect you’re being subjective.
James gave me the following handy mnemonic for test oracles (the principle or mechanism by which we recognize a problem): HICCUPP. Here’s what the letters stand for:
- History
- Image
- Comparable Product
- Claims
- User Expectation
- Product
- Purpose
Let’s consider how you address these oracles:
- Inconsistent with History. A product should be consistent with past versions (or history). History can include previous versions, patches, claims, etc. If something has changed, and no one told you it was supposed to change, then you might have found a problem.
- Inconsistent with Image. Most companies want to have a good image in the marketplace. Therefore, their software needs to look professional and be consistent with accepted standards. If a product is inconsistent with the desired image, what you’re saying is this: "We’ll look silly (or unprofessional) if we release this software to market."
- Inconsistent with Comparable Product. You’re letting another product serve as your oracle for this test. As long as the comparable product really is comparable, and you want your product to be an alternative to that product, or you want to get the users that that product has, then this oracle can be very compelling.
- Inconsistent with Claims. A "claim" can be anything that someone in your company says about the product. If something is inconsistent with claims, it’s inconsistent with the product’s stated requirements, help, marketing material, or just something that a project stakeholder said in the hallway.
- Inconsistent with User Expectations. This product doesn’t do something that a reasonable user of this product would expect it to do, or doesn’t perform a task in a way that the user would expect. Using this oracle means that you have some idea of who the user is and some indication of what he or she expects.
- Inconsistent Within the Product. Something behaves in one way in one part of the product, but in a different way in another part of the product. The change could be related to terminology, look and feel, functionality, or feature set. All you’re doing is pointing out where the product is inconsistent with itself. These are often compelling bugs.
- Inconsistent with Purpose. In my mind, this is the most compelling of the oracles. It states that the behavior you found is contradictory to what a user would want to do with this software. You might be talking about the purpose of a feature, for example: "Look, I can enter a negative value for headers in this Microsoft Word dialog box." That wouldn’t really be consistent with the purpose of headers and footers, would it? This oracle is often used in conjunction with Inconsistent with Claims or Inconsistent with User Expectations because those oracles also tend to address the purpose of the software.