One of the things that can make user acceptance testing go horribly wrong is that the users have no idea what they are supposed to be doing. They do not know how to use the system. They do not know what works and what doesn’t. They have no idea what the expectations are.
Last year, I worked on a project that was almost destroyed because the user testing was not effectively managed. Six months were spent recovering from a testing event disaster.
The following is a redacted document that I created for a very informal testing event. A few senior managers are going to play with the system that we built for them for a few days. This document helps to manage their expectations and describe what they are trying to accomplish.
Testing Environment
The application is ready for testing.
Goals
1) Validate and approve the user experience with the application.
We want you to sign-off on the facts that this application is what you want, that the user experience is acceptable, and that this is the “right” application. There may still be issues in individual areas of the application, but we want to know if you think this is a “good” application. This includes our decisions about colors, fonts, navigation, and how things work.
2) Help us to identify any specific issues about usability, specific functionality, etc.
We have done a lot of testing but, in an application of this size, there are always little issues that are missed. If you find anything wrong, please keep in mind that an error that cannot be replicated can’t be fixed. Therefore, if you encounter any error that causes the application to crash or you receive a data-specific error message, STOP! Log everything that you did and any messages on the screen. Call us and stop working on that user account. If you fix the data in the application so that the error goes away, we may have trouble replicating the error.
What you can test and what you can’t
The entire application is complete and all parts have been internally tested.
You can test the following:
1) Logging in for the first time, changing your password and answering security questions.
2) Forgetting your password and having to answer a security question prior to receiving a new password (since these are not yet real emails, it will not actually send you an email or reset your password, but you can test the user interface).
3) Filling in the entire application, including all forms and data fields.
4) The help screens accessed from the left hand side of the dashboard.
5) All section, form, and question-level text and tool tips.
6) Checking for errors and correcting those errors.
7) Submitting part(s) of or the entire application.
8) How the applicant can ask questions.
9) Re-logging in using your new password.
You will not be able to test functionality that involves interaction with external systems or the help desk at this point so you will NOT be able to test:
1) What happens when the external system accepts or rejects submitted data.
2) What happens when answers to questions come in from an external system.
3) On-line chat capability.
User Accounts
We are providing a set of user accounts that you can use for testing. Each of these accounts is newly created so you will be asked to set a password and answer security questions for each account that you use.
<list of accounts>
The initial password for each account is <Insert email here>.
Important Information
- This internet connection and this facility are not secure. Do not enter real data into the system.
- Once you submit a form, the data on that form will be locked and you will not be able to edit it.
Testing Environment
The URL to access the testing environment is: <Insert URL here>
The system has been certified for the <Insert browser names here> browsers. For testing you MUST use only these browsers and versions.
Logging Errors
For all errors, email them to: <insert email here>.
For cosmetic errors (misspellings, poor wording, etc.) bundle the issues and email them to us.
For functional errors, make sure you provide screenshots, the user name/password you used, what you did to make the error occur, and expected versus actual behavior. As soon as you find a functional error, email us the issue and we will respond within an hour to tell you if we were able replicate the issue or not.
Leave a Reply