The importance of user state management

The importance of fresh user state in testing.

A user represents a unique account within your system that is tied to a unique data set. User attributes determine the type of experience they have when interacting with your application.

📘

User state determines user behavior

If you have an app where Premium Users have the ability to book hotel and flight packages, and Free Users only have the ability to book hotels, you need the app to perform differently when it recognizes a Premium vs Free User upon login.

In other words: tests are reliant on the state of the user.

So, when a test results in a user ending in an altered state, you need to ensure that the user is returned to a fresh state prior to the test running again.

📘

Resetting the user state

That means that the same starting point in the same starting state of an app need to be restored before the next test is run. For more information, check out our Waldo Academy entry on User State Management.

Continuing our example from above: if you want to test the Free User’s ability to upgrade to a Premium User within the app, you have to login as a Free User and end as a Premium User.

• That means when the test goes to run again on that same account, it would fail, because the account is already a Premium user and cannot upgrade.

How to achieve fresh state

If you are doing something like a Sign Up, this naturally generates a new user in a fresh state each time.

If you are doing something like a Log In: you need to ensure that the same fresh state is achieved within the account by managing the end state of the user.

• This can be done programmatically, where you ensure that fresh state is achieved early in the test (duplicate new users every time upon login, or you can deeplink, etc.)
• If you app is not able to be programmatically managed, you can use test teardown to achieve your fresh user state.

📘

A note on test teardown

Test teardown allows you to quickly setup a test that ensures end users are in fresh state every time. However: it is not necessarily long term solution as you can’t be sure that the steps will be deleted at the right time, and tests reliant on teardown cannot be run concurrently.

User Example of a Read/Write Test + User State Management

An application called TravelSpot allows users to crowdsource recommendations for tourists in any given location. The user can do this by creating a “Spot” and logging notes about the location for perspective visitors.

When testing the application…

You would want to test that a user is able to repeatable add a “Spot”. However, if the user account attempts to add the same spot over and over, this test will fail after the first run because the “Spot” will already exist as shown below.

The solution…

Steps need to be added to the test that ensure that the correct starting point is regenerated. In our example: this means deleting the spot after it is generated. That way the spot can be reliably and repeatably “added”.

📘

Want to learn more?

For more examples of User State Management and guidance on test teardown practices, please visit our Waldo Academy Site. You will find use cases, live product examples, and best practice guidance that will help you sustainable manage your user state across your test suite.