Modeling application state transitions

Question

I am a little bit confused with the "state transition modeling" technique used for testing.

On a high-level, we have 3 major states when a user logs into the application under test:

1. logged out
2. logging in
3. logged in / dashboard

But, during logging in, our application under test makes multiple asynchronous requests to different API endpoints. I'd like to explore if there are any potential problems related to order of the received responses, or if some of the responses were never sent, network timeouts etc.

Should I break the "logging in" state into multiple smaller states? How deep and inter-connected, in general, should the state transition tables/diagrams be? Are there any best-practices?

Answer 1

It depends.

You actually have more states implied by your example than you indicated:

• Not logged in - can be reached by entering the system, logging out, having your session timed out. "logged out" is a subset of the not logged in state from this point of view.
• Logging in - reached by submitting credentials. Depending on how granular the API calls are, this could split into substates or be represented by multiple states such as "username verified", "username and password verified", "permissions retrieved" etc.
• Login completed and failed - Again, this state could be split into multiple possible states such as "account locked", "invalid credentials", or even "site not accepting logins at this time".
• Login completed successfully - This state could be a precursor to the state of "dashboard displayed" or you could separate it out, again, depending on precisely how your application processes the data. I've also seen state models distinguish by permission levels, so the outcome of a successful login could be one of "Logged in as administrator", "Logged in as power user", "Logged in as general user".

The important thing with state transition modeling is that the modeling captures your application transitions in a way that is useful to your testing.

Answer 2

Treat the API calls individually. Each API is an interface connection which can stand independent.

Then after you have them all separate reference the diagrams for each in a sequence for the page load. Any API modifications then are fully encapsulated in their own place while your login remains a single place too and just references them.