I recently completed running my first UAT. Oh my word… I had no idea! Maybe my UAT was the exception to the rule and these things normally execute flawlessly… I mean, we wrote the business requirements, based on the business team’s needs, we wrote the functional requirements based on the business requirements, we reviewed all of these things with business and IT, the IT team did QA/SIT testing, we wrote the test cases based on the business requirements and the IT team provided the scripts for the cases, which should have all been tested in SIT… So UAT should be quick and easy, the last glance over of the final product before we apply the stamp of approval, right? Hmm… there must have been a disconnect somewhere on my project that isn’t supposed to happen… Assuming someone else may have a similar glitch, here are some things I have found to be useful…

1. Document assumptions. Really. Document them. All of them. Even the silly ones. Especially the silly ones. If they are indeed silly, AWESOME! However, there are some silly assumptions that no one documents because they think they are silly or obvious, but those are the silly assumptions that turn out NOT to be valid. Finding out halfway into UAT that an assumption you made and didn’t realize was an assumption, so it was never verified to be true and valid, is actually NOT true is NOT FUN. This mistake can lead to a heap of trouble. I had to explain to a PM that the business wouldn’t be getting several features they thought they were getting because someone made an assumption in the beginning, but never documented it as an assumption and no one else realized the error needed to be corrected. Sit down and think hard about anything you may be assuming. Write them down. Review them with all the stakeholders. If they turn out to be silly, move on. But if you manage to catch even one thing that isn’t valid, you can save yourself a lot of time and money.
2. Don’t skimp on the test data. My test team was awesome. They were all over the test data creation… then an application crashed and we had to start over. So we had a rolling start into UAT, using the data we had initially and then adding scripts into the schedule as the data became available. This wasn’t our fault necessarily, but it definitely had a negative impact. Of course this wasn’t the only issue we encountered during testing; so as the issues compounded, it became harder and harder to catch up. You never want to have to backload your schedule!
3. Train your testers. Just because the testers are supposed to be the business users who will be using the system does not mean they know how to execute the test cases. The system may be all new – of course they don’t know how it will work! Even if it is not new, the new updates or new functionality may not be intuitive. Time is wasted when testers do not properly execute a test case, log a defect because they didn’t get the desired results, the IT team has to investigate the defect, the testers have to be retrained, and then a second set of test data has to be used on the same test case. Hold training sessions. Create training documentation that the testers can refer to if they have questions. Review the test scripts to make sure they’re correct and the testers understand what they are supposed to do. This may mean that you need to make your testers walk through the scripts in a dry run or test in training. Ensure your testers are trained on the procedures for logging defects and updating whatever test tool that you’re using so that you can accurately track testing progress.
4. Create a detailed schedule. This doesn’t mean saying July 1-14 is the UAT window. Create the schedule day-by-day. Sometimes you have to specify that certain test cases must be executed before others.  Even if you do not have to do this, provide a schedule of cases that should be executed each day. Plan this schedule with your testers. The testers should be able to provide estimates of how long each case will take. Do not plan 6 or 8 hours’ worth of testing for each day. The testers likely have normal daily responsibilities they still need to fulfill. Testing will also inevitably take longer than anticipated. If you get lucky and the testers can get ahead of schedule, great! Don’t set yourself up for failure by over-booking your team though.
5. Map test data to test cases. Do not simply provide a list of test data and a list of test cases. Even if the scripts will all be using sales order, assign a specific sales order to a specific test case. If a defect is encountered, the defect could be caused by the data rather than the system. If you have multiple testers and your test cases will modify the data in some way that it cannot be re-used, you don’t want multiple testers selecting the same piece of data to test with. Testers may inadvertently select a piece of test data that doesn’t satisfy the prerequisites for a test case if they are left to pick and choose.

I could list lessons learned all day for UAT, but I will leave you with 5 today. Feel free to add your favorite tips and lessons learned!