jump to navigation

The Trouble With UAT – Part 1 September 28, 2009

Posted by yvettefrancino in QA.

On Friday, I joined a free teleclassHelping Users Find Time for User Acceptance Testing,  presented by Robin F. Goldsmith, JD.  Mr. Goldsmith, author of Discovering REAL Business Requirements for Software Project Success, maintains that traditional UAT does not work well because typically we translate Business Requirements (the WHAT) into Functional Requirements (the HOW), rather than drilling down to get more detailed Business Requirements.

According to Goldsmith, conventional teaching is that UAT is a confirmation of product system requirements (rather than the business requirements) and simply a rubber stamp. “We’ve already tested it.  Just go give it your blessing, Mr. User.”  Users only are asked to do the positive proof of concept. It’s very common that UAT is a subset of System Test, and users are unlikely to find new problems providing little test value.   All that’s needed is one test per use case.  It’s a lot of effort without much payback.

In the model that Goldsmith presents, there is a phase of proactive drilldown into the Business Requirements, with requirements-based test cases identified early, prior to development, by the business. Goldsmith’s model, which he calls the Proactive Testing Life Cycle,  identifies more than 21 techniques for evaluating business requirements and then over 15 techniques for evaluating designs.

Goldsmith’s presentation was informative and he made some very valid points. However, Devil’s Advocate that I am, I would argue that the presentation was mis-titled. I think it is absolutely essential to have business folks involved up-front and ensure that business requirements are solid, but that takes time up front!  I guess the idea here is to convince the business that in the long run, this time will be worth the investment. While I think we’d all agree that being proactive is beneficial, how do we really help users find time for UAT? I’ll give my viewpoints on this in tomorrow’s post.



1. Robin Goldsmith - September 30, 2009

In my experience, when users say they don’t have time to participate in UAT, it often actually indicates that they don’t see the value in participating. Some of the main reasons they don’t see value are because: (1) they’re being asked to confirm that the product works as designed (i.e., meets functional requirements) rather than providing value by doing what the business needs (i.e., meeting REAL business requirements); (2) they’re asked to repeat tests that already have been done and consequently don’t find much; (3) they’re blamed for not having found the problems that subsequently show up in production; (4) they’re told to do the testing without having much idea what to do or how to do it; (5) they’re not coming from a development mindset and don’t think that defects are what they should be experiencing, which make them think they broke it and makes them reluctant to touch it again.

Proactive User Acceptance Testing focuses the user’s time on appropriate things, both tests confirming that REAL business requirements have been met by the product/system and Proactive User Acceptance Criteria that are what the user needs to see demonstrated before they are willing to bet their jobs on the system working.

I have a full-day course presented through IIST both online and in-house in-person which teaches how do Proactive User Acceptance Testing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: