Taking a Time Out

When you’re testing an application with any sort of security, you test the following as a matter of course:

  • User with correct username/password can log in.
  • User with incorrect username/correct password cannot log in.
  • User with correct username/incorrect password cannot log in.
  • User can log out.
  • User who is not logged in cannot access protected functions.

However, in the case of some applications and most Web applications, the server has a time limit on user inactivity; that is, after a certain amount of time, the server assumes that the user is done and shuts off the connection. You better make sure that works.

I’m going to speak about Web applications mostly here, but the following might apply to other sorts of client/server applications in your stable.

That being said, you need to make sure that when your session times out, the application recognizes the condition and handles it gracefully. Typically, the application redirects the user to the login screen to re-establish his or her credentials. And by “typically,” I mean, “the application should typically.” However, in many cases, the application will proceed with an operation even though the session has timed out or it will dump a stack trace.

To check on the time outs, it would be good to set the timeout value to something like two minutes instead of 20 or 30 or whatever the application normally uses. Otherwise, you’ll need a couple of extra machines/browsers to create sessions on so that you can run the timeout tests on them and continue with other test cases on your primary machine.

That said, you want to check what happens on the following after your session has timed out:

  • You use application navigation to try to reach another page.
  • You try to save the value in a form. That is, you open the form and enter data, but wait until after the timeout to save the data or abort the operation. This mimics the use case of a user going to lunch or getting called into a quick meeting.
  • Got AJAX? Sweet! Then you have to try every single asynchronous operation within a page. Your form populates from the database based on a JavaScript selection without a page reload? You have to check every single operation within the page that makes a call to the server.

A lot of times, you build your test cases to account for the use cases of an active application user. However, a lot of actual users will act much like we do in the course of normal daily computer use, so they will have timeouts. You better know what happens when they do.

Comments are closed.

wordpress visitors