Preparing Test Materials
I usually enjoy creating materials for UAT. As long as I know who the testers will be, and I understand their expectations with regard to the test materials, it can be interesting to think of the product from the user's point of view. The challenge in building materials is developing a balance between providing detailed steps versus writing in a way that might be deemed patronizing or excessive.
In most cases, the users know the application pretty well. In my experience, the primary reason that UAT testers need test materials is that they're likely to "freeze up" under the spotlight of UAT, wondering exactly what they should test. The test materials can provide the UAT testers with a little guidance, some suggestions about what they might want to test, and perhaps some detailed steps if any of the functionality is new.
UAT testers often need to understand the "happy path" and what it means to test outside of the "happy path." I'm often dismayed to find that the expression "happy path"so well understood by developers and testersis unfamiliar to UAT testers. The "happy path" follows the standard or expected process in an application, without using complex or boundary-provoking data or challenging the process. This kind of testing confirms functionality but doesn't challenge the application. Once I explain to the UAT testers that they should step through the basics but then also consider trying the application with more complex data, their eyes often light up with that "Aha!" look, indicating that they understand. For example, at a recent UAT session for accounting software, I asked the users, "Do you have a favorite month you would like to review?" Every user in the group smiled without hesitation.
The materials created for UAT vary as much as the users vary. Sometimes, the materials consist of a checklist of features to review. Sometimes the materials include specific test cases in which the steps to test are outlined. Most often, the materials include either access to the defect-tracking system or a list of existing defects for the new features, so that we can avoid duplicate defect reporting.