TL;DR

Every software tester has its own model of application under test. This post explains how to create effective oracle models. The post is aligned with the Black Box Software Testing Foundations course (BBST) designed by Rebecca Fiedler, Cem Kaner, and James Bach.

Definition

It is essential to state that every model is SIMPLIFIED, formal (having a conventionally recognized form, structure, or set of rules) representation of relationship, process, or system. The above picture shows a sailing boat model because its scale is smaller than a real sailing boat. We must do simplification because doing that we make some aspects of application clearer, more visible, and easier to work with.

For example, when we use Google search, we simplify that feature by just observing the search input box and page result. We are not interested that input actually goes to a vast Google search network that consists of thousands of servers.

We base our test on such simplified models and doing that, we could miss essential bugs. Many models are implicit, which means that those are not directly expressed. You probably tested some program and thought:

This behavior feels wrong.

That feels wrong was a clash with your internal model of application under test. For example, if you put in Google search:

Famous software testers

and the first result is your name, you would say that this feels wrong.

Here are examples what tester could model in oracle:

• Business process emulated by software under test; an example is buying the cheapest airline ticket.
• the software emulated by software under test, this could be a C64 computer emulator in Linux.
• the transactions that this product participates, the example is blockchain node
• the physical process emulated by software under test, the example is x-ray controller
• the device this program interacts with, the example is printer
• the reactions or expectations of the stakeholder community, the example is the stock market day trading system
• the usage patterns of the product, the example is how we use Facebook
• the user interface of the product, the example is the user interface of text editor
• the objects created by this product, the example is a multi-language code editor.

But what guides our creation of a model? Following aspects of the thing that we model could help us:

• capabilities
• preferences
• focused chronology, here we analyze life history of action or object
• the sequence of actions, we usually use sequence and state diagrams
• the flow of information, we use data flow diagram, protocol diagram, and maps
• interactions/dependencies, we use decision trees, data dependencies charts, connection charts of system parts
• collections
• motives

Now that we know what could be used to guide our model creation, we can understand why every model is a simplification.

We never use all aspects of model creation!

We use some of them and hide the rest of the aspects. There is one crucial reason why we use simplified models of the real thing:

Using the model is easier or more convenient to work with, or more likely to lead to new insights than working with the original.

For example, using the boat model from the picture above, we could get insight into where and how fast it would go depending on wind direction and strength.