Redefining User Acceptance Testing

User Acceptance Testing or “UAT” is a critical part of any project. It’s where the customer takes your software into their environment, tests it and reports any issues which must be resolved before they take it into live. Development teams then resolve these issues, send the application for retest and (hopefully) get a signed off version.

I have a deep seated dislike of this concept.

I should clarify that I have no problem with customers doing their own testing – in fact I encourage it, we’re software professionals and don’t work in our application’s domain. High quality customer collaboration is essential if we are to produce a good product. No, what I have an issue with is the concept of a development, testing, and bug fix phase.

If Agile and Scrum techniques have taught us one thing it’s that we need to move away from “development phases” and towards continuous delivery with ever increasing value.

Leaving bug detection and resolution until the end of project is bad!

What then is the role of UAT in modern development methodologies? How do we achieve a signed off version without digging ourselves into these waterfall defined project stages we were supposed to have abandoned years ago?

By making UAT a continuous process alongside the development.

In my view as soon as a project begins, while the stories are still being written and the mock ups created the latest and greatest version of your application should be installed into the customer’s UAT environment. Then, while you’re working away creating the new features the stakeholders in your client’s business are testing the suitably of what you’ve already developed against their needs.

As you continue, Sprint on Sprint, Story on Story you can incorporate your client’s feedback (both bugs and suggestions) to deliver the best possible product at the end of the project. It’s only by presenting your build to the customer early that you can get this feedback. Forcing your clients to wait until your project is feature complete and signed off internally will create these heavy bug fixing phases we’re all working so hard to avoid.

1 thought on “Redefining User Acceptance Testing”

  1. Nice idea about having customer test early however you need to also cover those customers who work within a waterfall framework and will not have testers available till the software completes primary development of user stories. My company (a software vendor) constantly struggles with projects where we are delivering our product at end of each sprint to the customer’s uat environment but they are no in position to test until all development is complete. We then go into a dreadful bug fix cycle that often carries well beyond the time where we had planned to move into production. This is not something we can typically change as we are generally the mouse servicing the elephant.

    Like

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