Ask Questions and Observe Language to Find State Transitions
Stumped by an intermittent, ephemeral bug? You know it’s there. You’ve seen it yourself or heard rumor of it, but reproducing it on purpose seems to be impossible.
Defects like that are sometimes triggered during what Elisabeth Hendrickson in her book Explore It! calls a “window of vulnerability: a moment in time when all the conditions line up just right so something can go very wrong.” Bugs that peek out during a window of vulnerability can make us think we’ve been outsmarted, but in their sleuthing bag testers have a powerful tool—state modeling—that can surface such issues.
State diagrams describe the various states an object can have, the events that change an object’s state (transitions), the conditions that must be fulfilled for the transition to occur (guards), and the activities that occur during an object’s life (actions). By asking certain questions to help detect states, testers can systematically identify windows of vulnerability where bugs may hide.
Courtesy of Alan A. Jorgensen, Elisabeth lists three questions that indicate change in the software:
- Are there things I could do now that I could not do before?
- Are there things I cannot do now that I could do before?
- Do my actions have different results now than before?
Similarly, Elisabeth says to watch for certain words used in describing the behavior of the software. Using the word while, as in “while the file is uploading” or “while the system is processing the order,” typically indicates a unique state for the system, perhaps a transitional one that will result in another state when complete.
Also watch for use of the word if, which can indicate events that may take place. For instance, “if the user enters an invalid password three times” or “if the system fails to connect to a remove server” are statements about events that trigger certain states.
Not all events are triggered by the user or the system completing a background activity. Consider a statement like “if the user is idle for ten minutes,” which speaks to events that change the software’s state after the passage of time or at a certain time.
To keep from being overwhelmed by the massive number of states and events that may be uncovered by asking these questions and paying attention to the language, focus on a single feature, workflow, or entity that has different states. Focusing on a single area will reduce the guesswork and the trial and error involved in teasing out those elusive bugs related to short-lived windows of vulnerability.
