Visual test models and state transition diagrams are two means of visualising information. Though they may appear similar at a glance, the structure and purpose of each is unique. When used in software testing, they act as tools to guide entirely different test techniques.
This article compares these two types of visualisation in the context of a real-world example based on purchasing a book from e-commerce retailer Amazon.
Visual Test ModelsTesting often begins by focusing on function first. Sometimes this is because testing is being driven by a requirements document or the acceptance criteria of a user story. Sometimes it’s because not all of the functionality is present in an iterative delivery model, so the testers have to concentrate on one piece at a time. Sometimes it is just due to personal preference.
When focusing on function, we are testing to see what the software can do. James Bach lists four key points of function testing in the Heuristic Test Strategy Model:
- Identify things that the product can do (functions and sub-functions).
- Determine how you’d know if a function was capable of working.
- Test each function, one at a time.
- See that each function does what it’s supposed to do and not what it isn’t supposed to do.
A visual test model begins as a useful way to quickly capture the things that a product can do, acting as a note taking tool during investigation of a function.
Imagine that we have received the Amazon Shopping Cart function to test. A screenshot of a cart with one item awaiting purchase is shown below:
A visual test model that identifies things that the product can do might look like this:
Once the visual test model shows what the product can do, it can then be used to capture how the tester could know whether each function was capable of working. Test ideas are added to each branch and might include negative tests – those ideas that determine that the function doesn’t do things that it shouldn’t.
When switching between documenting function and capturing test ideas it may be useful to switch colour, to clearly delineate between different types of information. A continued example for the Amazon Shopping Cart is shown below:
From this point the continued use of the model will vary dependent on the test approach. It may be extended to show exploratory test sessions and progress of testing. It may drive discussion around which ideas are suited to automated checking. It may be used as a reference to create pre-scripted test cases in a test case management tool.
A visual test model is a good way to capture quick thinking about what a product can do. It is a simple mechanism to capture test ideas that drive function testing.
State Transition DiagramsOnce the pieces of the product have been functionally verified, the tester will want to examine how they interact together. The shopping cart, the checkout and the order review page may all work in isolation, but unless they also integrate correctly with each other a customer will not be able to purchase a book.
Flow testing is where a tester does one thing after another. The Heuristic Test Strategy Model lists three key points about the flow testing technique:
- Perform multiple activities connected end-to-end; for instance, conduct tours through a state model.
- Don’t reset the system between actions.
- Vary timing and sequencing, and try parallel threads.
State transition diagrams offer a way to visualise paths through a product. Determining how activities are connected end-to-end will help the tester to identify varied flow through the application that may otherwise have been missed.
To create a state transition diagram start by identifiying the scenario for a successful interaction. When purchasing a book using Amazon, the simplest flow through the product may look like this:
Then investigate the other scenarios that a user could encounter at each point in this simple flow. An expanded diagram may look like this:
Because the state transition diagram is focused on interaction, it is a good visualisation for flow testing. Traversing the diagram through varied paths, while adopting different timing and number of users, is a good way to explore a piece of software through a different lens.