Identifying what states exist in functionality and how changes in state take place enables testers to identify tests that should be executed. State transition diagrams provide simple notation for summarising states and how changes in states take place. I recently used a state transition diagram on a project and it helped me identify the tests to execute.
To create a state transition diagram you need to first identify objects that may be in one of several states depending on what events have occurred. An event causes an action which may change the state of the object.
The above state transition diagram shows the states of sports matches and the transitions between them. The notation used in the diagram above is:
- Circles represent to the states that the system may be in
- Labelled arrowed lines from states show events that cause actions
- Text on a line represents actions that are taken when events occur
- Arrowed lines from actions show a change to another state
The state transition diagram identifies for us the states of matches and the changes that cause matches to change state. We can then test all of the states and test all the actions that cause the matches to change state. This gives us a level of test coverage and so gives us confidence in our testing.
Many charting tools that support the creation of state transition diagrams have free plans.I used Lucidchart for the diagram in this post.
I find that creating a state transition diagram is an iterative process from which I learn about the functionality I am to test. Whenever I come back to the diagram I review how the diagram represents the functionality and this helps me get a better understanding of the functionality that is to be tested. As I get a deeper understanding of the functionality I update the diagram and in this way creating a state transition diagram helps me gain a fuller appreciation of the functionality my team is developing.
The diagram can also be shared and reviewed. Sharing the diagram helps collaboration within your team. Something I learned from using a state transition diagram on a recent project was that the diagram is easier for the rest of the team to use if, instead of having one crowded diagram, you break the functionality down into several clear diagrams.
Further reading: Computer Science 4th Edition by C. S. French
[[..PingBack..]]
This article is curated as a part of #61st Issue of Software Testing Notes Newsletter.
https://softwaretestingnotes.substack.com/p/issue-61-software-testing-notes
LikeLike