We have 3704 guests and 24 members online

Video Spotlight

Home > Blogs > Featured Blogs > Plan and Deliver > More Adventures in UAT: The User Decides When it’s Done

More Adventures in UAT: The User Decides When it’s Done

Written by Peter Schuh   
Thursday, 16 April 2009 12:08

The two-headed, three-armed beast is slain. (See my previous post if you don’t get this reference.)

An interesting question arose the week before we began UAT. How do we decide when UAT is done?

There were several proposed answers to this.

  • When all the test cases pass.
  • When there are no open issues remaining.
  • When there are no critical open issues remaining.

Or, my personal favorite:

  • Starting Friday afternoon, put all the VPs in a room and let them decide. Repeat on a daily basis until the VPs all decide we’re done.

Isn’t that a lot like how they select the pope?

I pulled a page from agile (at least, from my book on agile) for the answer to this:

UAT is done when the users say they can and will begin using the delivered product in their daily work.

Sometimes I earn my pay. And sometimes people even listen to me.

UAT lumbered along for four weeks as the PM reported daily progress against existing issues and the new issues that had been uncovered. The users regularly said “it’s getting closer but we can’t trust the data yet.”

Sometimes things work out just about right - and this was one of those times. When it was clear things weren’t going according to plan, everyone ignored the arbitrary deadline. No one pushed the users to accept a deliverable that made them uncomfortable. The users and the team, meanwhile, communicated meaningful status on a daily basis. Everyone agreed on the goal, and could sense whether we were moving toward or away from that goal.

Finally, earlier this week, we got the word: “We’re ready to use it. UAT is over. And here’s the three things that still need to be resolved in a follow-up release.”

Again, the way it should be. I know there are sound reasons why you cannot always let users decide when they are ready to accept the delivered product and end UAT, but everything goes so much smoother when you can.

More Adventures in UAT: The User Decides When it’s Done

Read Full Article
Author:Peter Schuh

Comments (0)Add Comment


Write comment

You must be logged in to post a comment. Please register if you do not have an account yet.

busy
 

Agile Marketplace - Announcements and Special Offers

Webcast:  Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!

Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial

Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper

PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now