Like this article? We recommend
Vision Tests
Vision Tests
The structure of a test shouldn't change much from context to context. This structure always includes the following:
- A set of assumptions, which you guarantee with some kind of setup phase
- A way to invoke the software under test (the trigger)
- Some kind of verifications performed on the result of triggering the software under test (the assertions)
What varies from context to context is the scope of what is being tested and what is being validated. For instance, an acceptance test specifies and ensures that a unit of value is delivered by a system; a unit test specifies and ensures the presence of a single behavior within a system of classes.
We'd like to introduce the vision test, which specifies and verifies delivery of an entire value stream. A vision test is much broader in scope than a typical acceptance test, which verifies only a single piece of value, as opposed to testing the entire stream.
The most important aspect of a vision test is that it specifies all the steps needed to support delivering value to the actual customer(s). Whereas an acceptance test probably only specifies how a user interacts with a system to get a single nugget of value out of it, a vision test would include the steps that are entirely manual (as when a customer service representative apologizes for inconvenience) or even delegated to another organization (as when an item is shipped to an customer).
The best place to start developing a vision test is with the envisioned value stream. Imagine a fictional company, Petrieval.com, that helps pet owners recover lost pets. Figure 3 shows an example value stream for that company from which a vision test might be built.
There's a lot to build, some of which must be physical infrastructure. Nevertheless, the story in Figure 3 represents a complete set of steps that might conceivably result in value for an owner who has lost her pet.
When practicing value-stream–oriented architecture, an architecture diagram that looks like Figure 4 might result from that value stream.
A diagram is a suggestion, but a test is a specification. You shouldn't couple a vision test to implementation decisions; instead, couple the test directly to the value stream you intend to enable. Your vision test might be as simple as Example 1 (defined in the FIT convention), with driver code calling out that first layer of architecture.
That test tells the same story as described by the previous value-stream diagram: A pet goes missing, the owner tells Petrieval.com, hardware and software are used to narrow the search field, hardware and human effort are used to find the animal, the animal receives medical care (if such care is required), and finally the animal is reunited with the owner. The difference between the previous sentence versus a value-stream diagram and corresponding vision test is that the test tells the story in verifiable detail.
Such an artifact will help to keep everyone focused on the same ultimate goal. As parts of the process begin to pass/fail, having the diagram will ensure clarity about which parts of the process have been built at any given point in time.
)
)