Last weekend while I was working with James Bach, James had me test some small applications. When I would find a problem, James would ask me to explain why I thought what I found was a problem. I quickly discovered that I had no vocabulary for why I thought 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 kinda looked at him and said, "Well, it seems like it should work like this, not like that."
Needless to say, that was not good enough...
James then gave me the following handy mnemonic for oracles: HICCUPP
History
Image
Comparable Product
Claims
User Expectation
Product
Purpose
Inconsistent with History
If a product is inconsistent with its history then you might have found a problem. A product's history can include previous versions, patches, claims, etc. If something has changed (and no one told you it was suppose to change) then you might have found a problem.
Inconsistent with Image
Most companies want to have a good image in the marketplace. That means their software needs to look professional and consistent with accepted standards. If a product is inconsistent with image, then what you are saying is "we will look silly if we release this software to the market."
Inconsistent with Comparable Product
If something is inconsistent with a comparable product, you are letting another product serve as your oracle for that test. As long as the comparable product really is comparable, and you want your product to be an alternative to that product, or you desire the same users that product has, then this oracle can be very compelling.
Inconsistent with Claims
If something is inconsistent with claims, then it is inconsistent with requirements, help, marketing material, or something a project stakeholder said in the hallway. A claim can be anything that someone in your company says about the product.
Inconsistent with User Expectation
Inconsistent with user expectation says that this product does not do something that a reasonable user of this product would expect it to do or does not perform a task in a way that they would expect. Using this oracle means you have some idea of who the user is and you have some indication of what they expect.
Inconsistent within the Product
Inconsistent within the product means that something behaves one way in one part of the product, but behaves a different way in another part of the product. This could be terminology, look and feel, functionality, or feature set. All you are doing is pointing out where the product is inconsistent with itself. These are often compelling bugs.
Inconsistent with Purpose
In my mind the most compelling, the inconsistent with purpose oracle says that the behavior you found is contradictory to what a user would want to do with this software. This is often used in conjunction with inconsistent with claims or inconsistent with user expectations since those tend to indicate the purpose of the software, but it does not have to be. You might be talking about the purpose of a feature. "Look, I can make the value for headings for a page in MS Word negative." That wouldn't really be consistent with the purpose of headings and footers.
Needless to say, that was not good enough...
James then gave me the following handy mnemonic for oracles: HICCUPP
History
Image
Comparable Product
Claims
User Expectation
Product
Purpose
Inconsistent with History
If a product is inconsistent with its history then you might have found a problem. A product's history can include previous versions, patches, claims, etc. If something has changed (and no one told you it was suppose to change) then you might have found a problem.
Inconsistent with Image
Most companies want to have a good image in the marketplace. That means their software needs to look professional and consistent with accepted standards. If a product is inconsistent with image, then what you are saying is "we will look silly if we release this software to the market."
Inconsistent with Comparable Product
If something is inconsistent with a comparable product, you are letting another product serve as your oracle for that test. As long as the comparable product really is comparable, and you want your product to be an alternative to that product, or you desire the same users that product has, then this oracle can be very compelling.
Inconsistent with Claims
If something is inconsistent with claims, then it is inconsistent with requirements, help, marketing material, or something a project stakeholder said in the hallway. A claim can be anything that someone in your company says about the product.
Inconsistent with User Expectation
Inconsistent with user expectation says that this product does not do something that a reasonable user of this product would expect it to do or does not perform a task in a way that they would expect. Using this oracle means you have some idea of who the user is and you have some indication of what they expect.
Inconsistent within the Product
Inconsistent within the product means that something behaves one way in one part of the product, but behaves a different way in another part of the product. This could be terminology, look and feel, functionality, or feature set. All you are doing is pointing out where the product is inconsistent with itself. These are often compelling bugs.
Inconsistent with Purpose
In my mind the most compelling, the inconsistent with purpose oracle says that the behavior you found is contradictory to what a user would want to do with this software. This is often used in conjunction with inconsistent with claims or inconsistent with user expectations since those tend to indicate the purpose of the software, but it does not have to be. You might be talking about the purpose of a feature. "Look, I can make the value for headings for a page in MS Word negative." That wouldn't really be consistent with the purpose of headings and footers.