This week i read the blog few hiccups by Michael Bolton which can be found here. This article is about better describing the expectations you have for your code before testing which makes it easier to find problems in the code. Also in the article is identifying and applying oracles. I could not figure out what that meant at first but in an older Michael Bolton article i found the definition to be as follows.An oracle is a principle or mechanism by which we can tell if the software is working according to someone’s criteria; an oracle provides a right answer—according to somebody. That article which is called Testing without a map can be found here.
The article is actually a mnemonic in which the blog is based around. The mnemonic is split into two parts, FEW and HICCUPS. The HICCUPS part of the mnemonic refers to a list of the authors oracle principles. HICCUPS is designed as follows:
- History. We expect the present version of the system to be consistent with past versions of it.
- Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
- Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
- Claims. We expect the system to be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals, whiteboard sketches…) or in conversation (meetings, public announcements, lunchroom conversations…).
- Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
- Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
- Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
- Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.
Each one of these is a criteria that can be used to identify a problem in your code. We have a problem once we realize that the product or system is inconsistent with one or more of these principles. The FEW part of the mnemonic is defined as follows:
Explainability. We expect a system to be understandable to the degree that we can articulately explain its behaviour to ourselves and others.
World. We expect the product to be consistent with things that we know about or can observe in the world.
Familiarity. We expect the system to be inconsistent with patterns of familiar problems.
These last 3 oracle specifications were added later on updating the mnemonic from HICCUPS to FEW HICCUPS. The way to remember this given in the article is: When we’re testing, actively seeking problems in a product, it’s because we desire… FEW HICCUPPS.
I stumbled on to this blog by accident while looking at other blogs about testing consistency but i am glad that i did. This was a very interesting read and was not like other blogs that i have read. All the different specification oracles in the article were interesting and each seems to have it’s place. These specifications i think would make you a much more consistent tester by giving you a consistent guideline for finding problems in your code. The mnemonic was my favorite part of the article and not something that i have seen to many times in software testing. This seems like it would be very helpful in memorizing these oracle principles well into the future.This is something i am going to try and remember and use in my testing. Often times it is hard to pick were to start looking for problems in your code , or how to identify those problems. This mnemonic seems like a good way to fix that.
Dhimitris CS Blog 