Description

As soon as a status is more than binary, there is room for more error.

Explore the factors leading to and from “yellow” (or the middle status).

This is a specific example of the ifs are iffy heuristic.

The story

This microheuristic comes into play when we encounter any kind of status. It is closely related to “ifs are iffy”, but it is more specific in that it refers to a particular result of the “ifs”, and it’s also easier to recognise without knowing much about how the internal code might be designed.

Status is important

Much of the software that we write involves statuses of some kind. Go or no go, passed or failed, save or cancel, published or draft mode.

These kinds of status are interesting enough in themselves, but it gets really interesting for me as a tester when we move from binary status to anything that can be somewhere in the middle. If we’re thinking of traffic lights – as soon as we move from only red and green to red, yellow and green, then we’re in interesting territory.

This is where the relation to “ifs are iffy” comes in. To me, moving to a non-binary status is where if statements may be more complex. Additonally, if we have statuses viewable by users of the software, they are particularly easy to recognise as calculated decisions. There are questions we can ask about order (what happens if I confirm this before I say it’s pending…?), and about transitions between statuses (can I mark something as rejected but later another person confirms it?). Statuses are fun to explore.

Example

The example where I noticed myself using this microheuristic was in a piece of software that approves vehicles for sale. There were multiple roles (sales / development) and each role was allowed to provide input on sales requests (desirable/undesirable) and technical implications (possible/impossible). Depending on these decisions and on inherited attributes from the basic construction of the vehicle, a status could be red (impossible and undesired), green (possible and desirable) or yellow (any other mix of possible but not desired / desired but impossible / desired and possible but violates another constraint/ …).

That’s all very well and good, but I didn’t entirely understand the domain logic. (I still don’t). All I saw was a yellow dot for the status and said “yellow is interesting, let’s explore that”.

It turned out that yellow was interesting enough that we found an error in the software. Changing one of the contributing statuses after the initial calculation had been created led to the cumulative status being “green” instead of “red”. And not just in terms of the wrong colour being shown in the UI.

“Yellow is interesting”. Anything that has more than two statuses has a good potential to be explored. The workings of it are likely to be similar to “ifs are iffy”, but I feel like it was worth presenting separately.

Summary

Back to overview