About PM4Web

The PM4Web blog was born as an outlet to return knowledge back to the web development community. My goal is to share my experiences as a project manager from over the years in a manner which helps you succeed with your own projects.

01 August, 2008

User Acceptance Testing

A formal process for demonstrating project completeness

Ever had a project where you thought you were done, but the client had other ideas? The project schedule may say all tasks are done, the QA tester may have successfully run through the System Test Plan, and the programmers may have cleared all known bugs. So why wont the client settle their account and let you get on with your next project? Easy, they don't know the project's finished, and why should they unless you can demonstrate without a doubt that you have delivered on everything you promised.

This is where User Acceptance Testing, or UAT comes to the rescue (also known as System Acceptance). It's not quite the finale of a project, but its getting close. You could say the Sign-off Agreement or Project Post-mortem is the real project end point. In essence, System Acceptance helps give closure to a project, without it, you may have a tough time convincing a client to sign the Sign-off Agreement (where the client formally indicates they are happy with the work you have done).

The actual structure of the document I use for System Acceptance is quite simple, filling it in is the tricky part.

The idea behind the System Acceptance process is to first make a list of every screen contained in the system, then you arrange a time to go sit with the client and systematically go through all the screens with them. For each screen, you ask the client two questions; 1) does the page appear error free?, and 2) does it perform all functions according to the spec? If the screen passes these criteria, its initialled by both you and the client. If you're thinking "oh god, doesn't that get really tedious after about twenty screens?", you are absolutely right. But as painful as it is, it will produce the desired effect; a tangible sense of closure within the client's mind. I recommend you forewarn the client of the less joyful aspects of the process, explaining that there will likely be multiple sessions lasting a few hours each, and that the process may seem inane at times, but you ask that they bare with you.

Now for some inconvenient truths. Will you complete the acceptance process in the first session you book with your client? probably not. As a rough guide, allow ten minutes per screen, a twenty page web application could take over three and a half hours. However, what tends to happen is the client really starts thinking about their software once they realize its almost over, its their last chance to make changes before they become indisputable feature additions. The result is that you may get side-tracked. The other issue is that a UAT session isn't meant to be a critique of interface cosmetics or functionality, but it can easily turn into such a discussion.

Mobile Device Issue Cartoon

If the time consuming and tedious nature of UAT weren't daunting enough, there is another looming danger; bugs. Chances are good the client will discover bugs during the acceptance session. If you've been wondering what the 'Comments/Notes' column was for, now you know; to write down bug details. What will probably happen is a good portion of the screens will pass, and some wont. You will have to make arrangements for another session with the client after you've had time to get the bugs fixed. Eventually you'll have all screens signed off, then you are ready to present the client with the Sign-off Agreement.

1 comment:

  1. Interesting approach. Very pragmatic, thank you for sharing it.