We get a lot of references to doing "user testing", and there seems to be a vague notion of what that means. At a basic level, there are two types, and they are very different. Here's how I explained it in a recent correspondence with a project sponsor:
...there are two types of testing that should be required of our customers: usability testing and user acceptance testing. They have different purposes, and different processes.
Usability testing is a one-on-one test with a facilitator and a participant....The goal is to identify barriers to users completing what they need to do in the system. This testing usually happens before the design is finalized....It is scripted and structured to quantify specific usability issues that will negatively impact implementation success and user adoption.
User Acceptance Testing is a test phase, usually after QA testing by the internal test team, where project sponsors and users are given access to the test system ,and are asked to do their normal tasks using the system and report back any functional problems. The goal is to identify what would prevent us from launching. Usually this happens well after the system is built, just before "go-live". It is usually not moderated but may be scripted.
So, if you do usability testing, it should identify major issues up front, which is much less costly to mitigate. Then UAT will likely only identify minor issues that would prevent launch. If you don't do usability testing, UAT will uncover more severe issues requiring more expensive mitigation, such as code refactoring.
Certainly usability issues may be uncovered--and should be addressed!--during UAT. But UAT is not a replacement for usability testing early in the process. Early, you are focused almost exclusively on the usability and accessibility of the system BEFORE the code is carved in stone.
Different and equally valid goals, and neither should be short-changed.
