“Have you been finding your sessions timing out as expected?” the boss asked. After the initial release of the financial services product, the team added functionality to end a user’s session after sixty minutes of inactivity.

“I tried it once, and it timed out as expected,” I said. Which was true: I’d logged in and walked away for an hour, and when I returned, I had to log in again. However, if I’d left it at that, I would have done a great disservice to the company and to its users. Although the feature was simply to end the user session, to say that it worked if the session ended after an hour overlooked the all-important “And then what?” part of testing. The most important thing to look for in testing a timeout is what happens when a user tries to do something but the session is timed out.

Some situations and applications display a timeout message to the user to indicate the session has timed out. In other cases, the timeout takes place behind the scenes with no notification to the user. These situations will require an extra level of testing and thought to predict potentially troublesome user workflows. This article looks at both situations and how to test them.

The Automatic Timeout Message

Many financial service applications display a message that indicates a logged-in user (which I’ll henceforth call an LI user) will time out, and that prompts the user to reset the timer with a click. If the user doesn’t, the application replaces the current page with a message that says the user session timed out. This solution gives the user who has timed out (henceforth, the TO user) immediate feedback as to what occurred.

If you get involved in the design phase of the project, suggest this practice and perhaps some functionality so the user can resume whatever he or she was doing when the session timed out. At the very least, this will allow the user to log back in on the same page, and it might include retaining data the user entered so the user doesn’t have to retype it.

If your application behaves this way during a timeout, you’ll need to test the timeout prompt and timeout message on different types of pages. For example, on a banking website, you might have a page that shows all accounts, a page type that displays an individual account, an individual transaction, basic informational pages, and perhaps a contact page. You’ll want to ensure the timeout prompt and message display on each page where it is appropriate. In some cases you might not want to replace an informational or Contact Us page with an alternate message when the user session times out.

Navigation and Pages

Many applications have two sets of pages available to the user: a set of external, informational pages available to any user who is not logged in (henceforth, an NLI user), and a set of internal pages that contain the important user-specific data and data entry forms that only LI users can access. As part of basic testing, I ensure the NLI user could see the appropriate pages and login prompts or buttons on the pages that only LI users can access. Once the user has logged in, I review the same pages to ensure the user can view (and use) all the pages.

I also check pages to ensure that, when a user manually logs out, the newly NLI user cannot see the same things as when he or she was logged in. The addition of a session timeout makes me run through the pages again with a user that has timed out. Conceptually, the TO user can differ slightly from the NLI user, so I like to ensure that the TO user cannot access things a LI user can. In a variety of timeout paths and on different pages, I click the browser’s Back button to see if a TO user can see internal previous pages and forms inappropriately (and, heaven forfend, submit them when NLI).

Two forms merit special consideration: the login form and the register form. If the application displays a message or redirects when the LI user goes directly to the form, I need to make sure the redirection or message does not occur after the session has timed out and the LI user becomes a TO user. Sometimes these forms do not reside on pages of their own, but display at the top of the page when a user clicks a button while NLI, and the user name or alternate controls display when the user is LI. When the LI user times out, the forms and controls must revert to reflect the NLI state.

Incomplete Forms

If your site or application does not provide a prompt and redirection when the user session times out, your users can begin a form, go to lunch, and then complete the form after the session has timed out. At the very least, this can frustrate a TO user when the submission fails. At worst, the application can crash spectacularly.

To test how an application handles this situation, I open individual forms pages, let the user session time out, and then submit the form. If the form has multiple steps, I let the user sessions time out on each step of the form to uncover any hidden interaction with the server. If I only test on step 4 of the form, where the user completes final submission of the form, I might miss that step 2 performs server-side address validation that could fail badly for a TO user.

Ideally, your application would provide some mechanism that would allow the user to continue without entering all the information that the user typed in, such as a modal login prompt that will return the user to the current page.

However, the application should not return an unhandled error message, nor should it “hang” with no response to the user.

In-Page Updates and Refreshes

Many modern website architectures feature automatic data updates to currently loaded webpages without the user having to click anything. On a financial website, this might include automatically updating stock prices. On other websites, this might include an activity feed or ticker in the banner or rotating callouts in the sidebar. Whenever a site includes these automatic updates, I let a user time out on the affected pages to see what happens. Does only the current content display? Does a login prompt display? Or does an error display on screen or in the JavaScript console?

Anything and Everything Else

This article addresses the behavior of websites when user sessions time out. However, if the mobile application you’re using has some sort of session time out, you also can apply some of these ideas to mobile testing, as the communications between the client and the server will be similar. To test a mobile ecommerce app, log into and go to an individual item page and leave it in the background until the timeout period passes. What happens when you add the item to the cart? Does the application prompt for login before allowing the user to check out?

The key to testing timeouts lies in familiarity with how your application communicates with the server, how your users interact with the application and establish their logged-in state, and what they might try to do when that session times out.

These basics can give you a head start to testing timeouts, but your knowledge and experience with your application will identify other places to look. You might already have a sense for the loading order and location of JavaScript files. Might some of them be affected when the user session times out and the user navigates elsewhere? I’m eager to hear your ideas and experiences with testing timeouts in the comments below.