When should a company use user-acceptance testing? When should they not?

[Ronan Healy]

After all, it is the customers that will be using the final product so when you introduce the product to them?

I know creating exclusive beta programmes are one way of asking the customers to find the bugs but is this a good idea?

The approach to release stable software rather than bug-free software is one that seems to be growing. I wonder though do customers want the software quicker or want it better?

[Melvin]

This is a very interesting topic. I think the use of user acceptance test and Beta testing by clients depends of the target audience, for instance for highly scientific domain software sometimes the target are big companies (e.g. reservoir simulation software for Oil companies), and they have their own big complex models in which is good to test it before the full commercial release. About the preference of customers if they want the software quicker or better, I would say both! I think this is the main challenge that software development is currently facing.
Regards.

[Archana]

In the service based companies that I have worked for, most of the times UAT was a mandatory thing — as the development and testing team was part of the same organization. So, the User acceptance testing was done by a separate team of testers hired by the client.

[Jesper]

Value of “user acceptance testing” depends heavily on how custom the solution is.

I rarely see that you would do a UAT on a new COTS (commercial of the shelf) application like an Office Suite or similar. .. but then again I could see this happening in large organisations. There more customized and configured the application is (Like in SAP and MS Dynamics) business applications, the configuration may need testing. Either by the person configuring the things or someone else.

I know contexts where UAT by business experts is all the testing there is, and other contexts where UAT is executed by software testing professionals.

To many the term “user acceptance test” is a dated construct, where the pains it addresses are mitigated in other ways. Frequent touch points of agile, business subject matter expert testing etc.

[Marco Foley]

In my experience UAT really depends on the company. I have seen one company with one business person signing off as UAT, another there was 2-5 people depending on the requirements and another where the test team just presented their results to the business.

I think there is value in having the business users testing the near/final product due to the fact requirements can lose meaning as they are communicated and BA/Developers interpret requirements differently which can end up in incorrect requirements. As a skilled tester, you also have the responsibility of understanding the business domain and being able to reduced the gap between the described, the imagined and actual. This can reduce the time users spend on UAT.

 

[Author]

Posts