State machine testing

Hi there!
Quite often, I need to test a state machine of some software products. Given my experience and expertise in such tasks, I’ve written an article on this topic, which will be posted on (I’ll share it with you later if you’re interested in this kind of stuff). While I’m waiting for the editors’ review of my article, I would like to discuss this topic with the community of QA professionals to hear your opinions, knowledge, and experiences.

So, my general approach is the following, which I always keep in mind:

  1. Isolate code that generates output from state transition logic.
  2. Focus on one state and transition at a time.
  3. Cover every potential state transition, including unexpected state-to-state pathways.
  4. Assess the state machine’s handling of different values.
  5. Ensure the state machine can handle incorrect inputs or scenarios without compromising features/app.
  6. Verify that the state machine works well with other system parts, maintaining accurate integration.

Pretty simple and straightforward, huh?

But what I’m really interested in, and often practice, is fuzzing testing (automated) of a state machine, including handling external disruptions, network issues, and heavy load/performance testing of a state machine. And, of course, my favorite: race conditions :smiley:

So, what is your take on these points and their applications? Have you had experience using any of these in state machine testing, or do you have other experiences and details to share? If you haven’t had such an experience, that’s fine, but let me know if you want to know more about this :thinking:

I’ve tried, but never actually do much of this kind of thing to be fair. I’m system level tester, and as such the state machine is never the actual product, and thats what many folk spend most time on. Which generally means the thing is to break it down to the point that the integrations make sense are grouped and can be mocked very well. I know that’s your 6th point there, and probably the biggie.


I’m not sure what you mean by “isolating code”. Mocking of parts of the system?

I use state-transition table once in while, but on system level.
I want to see the whole application to switch from one state to the other while I look for potential problems.

Maybe I just rephrased just what Conrad already had written. :thinking:

Probably, it wasn’t clear what I meant by isolating code :sweat_smile: my bad.
Ensure that the code responsible for generating output is separate from the logic responsible for state transitions. This separation enhances the testability of the state machine - define interfaces for actions triggered by state changes, then check these these actions are implemented separately. Check state transitions with inputs or conditions, and separately test output generation logic using mocks for states or transitions. This kinda general approach is not always achievable in reality of course.
For example, if a state machine controls a login process, the state transition logic would determine when to move from entering pass to logged-in. The output generation logic, separately implemented, might display a welcome message upon entering the logged-in state. Tests would separately verify the transition from entering pass to logged-in state with a correct password, and that the welcome message is correctly generated when entering the logged-in state