User Acceptance Testing – a business analyst’s perspective

uat_testingUser acceptance testing is one of the many flavours of testing that has emerged over the last twenty years or so. As the software development life cycle has become more sophisticated and rigorous (or, in the case of agile, more lightweight), the testing phase has been broken down into many different aspects and styles of testing.

This article explains user acceptance testing from the business analyst’s perspective. It will describe the history, how it fits into the project life cycle, the objectives of UAT and how the business analyst can be involved.



User acceptance testing has emerged as more user involvement is both expected and required. User means the business or subject matter experts (SME’s) or, usually, the actual end user of the product rather than the manager who may have been more involved in the project.

The business expects to accept the product rather than simply assuming the final product will be fit for purpose. This additional involvement is reflected in the software life cycle in all stages prior to user acceptance testing with a particular focus during the analysis phase when the requirements are agreed.

The benefit is that there are no surprises when the product is released and any surprises can be addressed before the product is released to the wider user community. The downside is greater involvement of user time but this can be managed and the benefits offset the disadvantages.


Project Context

V modelThe V model is a common representation of the project life cycle. It should be read at the start of the V (top left) with user requirements, follow the V down to code and back up to Acceptance testing (top right).  Acceptance testing can be seen to have a direct correspondence with the user requirements which should inform the structure and content of the user acceptance tests.




UAT’s prime purpose is to demonstrate that the system is fit for use in the business. It is not the same as system testing which should prove (within time and resource constraints) that the system behaves in the way that was described in the requirements specification.

UAT is, to some degree, a public relations exercise as end users tend to be involved as well as stakeholders and they will (hopefully) gain some confidence in the quality of the system, understand how to use it and, very importantly, start to see its benefits.

There are many other forms of testing which, for example, prove the code works as designed at a fine grained level (unit testing) or prove the various systems interact as expected (integration testing).


Business analyst’s role

The business analyst will be involved in UAT to a degree, depending on the project.

At a minimum, he/she will provide guidance to system behaviour and identify scenarios which would be suitable to test. They may be requested to review the test scripts and objectives and, in some cases, may actually coordinate and manage the execution of the user acceptance testing.

The business analyst should do no more than co-ordination as it is critical that the business has ownership of the tests and, hence, believe that passing business acceptance testing genuinely means the product is fit for purpose.

This will depend on the company culture, the specific project and whether there are any resourcing issues.



Some time should be invested in selecting appropriate scenarios for inclusion as it will not be possible nor appropriate to test all scenarios. The following should be considered when deciding these scenarios:

  • existing requirement documentation
  • critical success factors
    CSF’s will not all be provable in UAT as some may only be proven over a period of time
  • business benefits
    Most business benefits will also not be provable as they are likely to involve a cost saving or revenue generation which can only be measured over a period of time
  • typical scenarios
    Normal or happy path scenarios should be a central part of UAT
  • high risk scenarios 
    Scenarios that are recognised to drive profit, can trigger cost savings or have regulatory impact should be candidates for UAT.



Although it is not as exhaustive as system testing, it is equally rigorous in what is tested and documented and formal acceptance criteria and process.

Project objectives, business benefits and critical success factors should all be used to help define acceptance criteria

Users and business stakeholders should be involved in decision making and planning throughout UAT. They will become natural ‘champions’ for the new system if they are fully involved and consulted.

It is critical that the business are fully engaged in the planning and design of the user acceptance test and the production of acceptance criteria. This is one of the last hurdles before the product is released into the world and the understanding of the product and problems uncovered at this stage are vital in making the decision to ‘go live’ with the product.

Poor user acceptance testing can cause significant problems for the business.


Related Links

Wikipedia – Acceptance Testing

Short paper on UAT


This article discussed the history of use cases and it’s context in the project. It also explained how the business analyst can be involved and both the planning for user acceptance testing and the principles that should be followed.


User acceptance testing is not my area of expertise so this article reflects my understanding. I would welcome any feedback or debate.

About Alex Papworth

32 Responses to “User Acceptance Testing – a business analyst’s perspective”

Read below or add a comment...

  1. Rozella says:

    you are in reality a good webmaster. The website loading speed is incredible.
    It kind of feels that you are doing any unique trick.
    Moreover, The contents are masterwork. you have done a magnificent
    activity in this topic!

  2. Arthur says:

    Remarkable issues here. I am very glad to look your article.
    Thanks so much and I’m taking a look forward to
    contact you. Will you please drop me a e-mail?

  3. daniel udeh says:

    i wanted to start this from scratch how will it help?

  4. news says:

    Can you tell us more about this? I’d care to find out more

  5. Pulu Okram says:

    Hi Alex,

    Pulu here, I am the lone tester of a company.I have done all testing activities like drafting test plan, test case preparation and execution, bug report generation.

    My doubth is
    1.For UAT who will prepared test cases.
    2.What is the duration time/day/week/month for a project.
    3.We have a project for Thrift & Credit and consists of 8 modules.. my question here is how long we will be given fro UAT.

    Please give me suggstion and it is very urgent


  6. binayak says:

    i am currenlty taking a BA training the trainer is quite fast and i sometime forgets to ask key questions? do you think BA is agood career to chose if i have a degree in business administration? if i chose to BA and down the road if i do get placesd in a company what are the main things you would recommend me to understand? please give me a list so i can do some homework of my own and avoid being embarrassed in the company?

  7. Lpx says:

    Great article, Alex. Thank you.
    As a BA, do I need to know SQL Server? What would be my role with a database as a BA? Some examples, please.

  8. Ram says:


    Can Explain the difference between

    1. QA & UAT
    2. UAT & BA
    3. QA & BA

    • Alex P says:

      My opinion is that QA and UAT are related. These both relate to proving the solution delivers what is required. BA is quite different as it helps discover and define the requirements. Often, a business analyst takes on the testing role.

  9. Arun says:

    Hi alex,Now i am a SIT Tester,Is it possible to become a business analyst,then what should I do?
    Please give your suggestion.

  10. edwin says:

    Hi , I just joined organisation……i am as Ba. they gave me UAT acceptance criteria………..wht shld my next step ………..create use case or test case……………….

  11. Ebbing says:


    I don’t think you’ve quite got the V-model right:

    The point of the V-model is that you define the project outputs at different levels of granularity and from different perspectives.
    -User requirements = "I want this"
    -Functional spec = “this is what the solution has to *do*”
    -Tech spec = “this is how the solution will work”

    Testing reflects this, and verifies the outputs against what has been defined in those docs.
    -Tech spec: Link test = “does the solution work how we agreed it would?”
    -Functional spec: System test = “does the solution do what we agreed it had to?”
    -User requirements: UAT = "does the solution deliver what we agreed you want"

    Note: one of they key messages of the V-model is that it is vital always to test against what was agreed. So in UAT, you are not testing against what they user wants – you are testing against what they asked for. If they have new ideas, these will be treated as changes.

    So for each round of testing, the delivered system must be proven to meet the related document. If it matches, it's a pass; if they don't match, it's a fail.

    "system testing which should prove (within time and resource constraints) that the system behaves in the way that was described in the requirements specification."
    No. UAT proves the system against the requirements spec.

    “Project objectives, business benefits and critical success factors should all be used to help define acceptance criteria.”
    No. UAT specifically tests whether the documented requirements have been met – anything else is out of scope. The requirements spec *is* the acceptance criteria.

    “Although it is not as exhaustive as system testing…”
    No no no no no. It has a different focus from system testing, but UAT absolutely *must* be as rigorous and thorough as other rounds of testing.

    "UAT is, to some degree, a public relations exercise…"
    Only if defining requirements is a PR exercise. If requirements are an important part of a project, then UAT is an equally vital part.

    Or to look at it another way, all user engagement is a PR exercise. Requirements workshops, project reports, steering group meetings – all part of the PR. But they are also fundamental, vital parts of a project.

    • Darbelo says:

      I completely agree with your response. As I was reading the sections that you pointed out, I was thinking the same thing about some of the errors in the article. But, overall it was a well written article.

    • SamaraBru says:

      I disagree and offer another perspective… UAT tests the end-to-end process against the business requirements, not the detailed functional requirements. "Does it do what I stated needs to be done in my general user requirements?" They should all be aligned, yes, and proven through testing. But but there's a distinct difference between UAT and validation that is not mentioned. I would also offer that UAT in an agile process should be the last testing step, and conducted only after the software is stable, the end-to-end testing is complete, and integration testing is near complete…. otherwise it becomes unit testing, compounds regression testing, and erodes confidence in the application.

  12. Amy says:

    Nice article Alex. I will look forward to more info.

  13. jhane says:

    im amaze of your job thanks for the info. i learn more on your site

  14. K. Banjo says:

    Fantastic article, Precise and Str8 to the point. Thank you!

  15. Athira says:

    Who creates test cases QA or BA?

    • alexpapworth says:

      Hi Athira

      that's an easy one and it all relates to roles. The QA (who has many other names) will create test cases.
      Who will be wearing the QA hat? Even if you are the BA, you may well be expected to wear that hat.

      There are arguments for and against the BA undertaking this role which I will not go into here.

      This is one of those areas where we can have an argument about the correct way of doing things but it is largely irrelevant if your employer has fixed ideas on how to do things.

      I, for example, have never undertaken the QA role (except in the distant past) and have only reviewed their work.
      In other organisations, I believe the opposite is true. I suspect that as the organisation gets smaller, you wll be expected to 'wear more hats' as they can't justify employing too many people. In larger organisations, they tend to specialise to a much greater degree…


    • GAZ says:

      UNless you expect that QA does only software testing, QA by itself is the natural way to define, create and implement Test Scenarios, Test Cases and Test Scripts.
      The BA function would be to coordinate with the business side the implementation and execution based on his/her understanding of the business expectations.
      Do not get confused.

      • alexpapworth says:

        That is my experience and expectation Gaz. However, as a freelancer, the customer is king and it always pays to be flexible.

        However, if the client asks me to start doing coding, I would need to have a frank and open debate about risk 🙂

  16. Athira says:

    It was a good paper.I have a doubt with class diagrams who does it BA or architects?We have a big confusion in our project with this class diagrsm.I know both work together to get it done but who is the placeholder for a class diagram

    • alexpapworth says:

      Hi Athira

      it's a good question and one that doescause confusion, not least beecause it is perceived as 'technical'.
      Your first question should be what is the purpose of the class diagram?

      Is it to describe and understand the business in business terms?

      Or, is it to describe the solution or is a step in solving technical problems that should be of no interest to the business?

      If it is the former, the business analyst could produce the class diagram.

      If it is the latter, it would be a designer, developer or database designer who should produce it and the business should not have any sght of it.

      Even if it is the former, you need to tread carefully because you need two more things.
      Firstly, many BA's are inexperienced in producing these so some skills or support is required. Secondly, you need to be careful how you use it.
      It can be something that you create and use to trigger questions and test assumptions with the business. You could also whow it directly and walk it through with the business. Again you need to be very cautious as many business stakeholders will be uncomfortable with such a 'technical' diagram.

      I have written more in this article –

  17. IanMcI says:

    Alex, good easy to understand presentation with reference to V-model. I am currently on a site where the vendor/developer is trying to base all their test scripts (system) and the business/UAT scripts – bizarre to my way of thinking.

    I am interested in your take on the middle line down in this diagram and what you believe this is referring to. Happy to discuss off-line if you give me a contact email.
    Regards Ian


  1. business analyst Responsibilities…

    User Acceptance Testing – a business analyst’s perspective |…

  2. […] User Acceptance Testing – a business analyst’s perspective // […]

  3. […] User Acceptance Testing – a business analyst’s perspective Another great knowledge source especially for business analysts and this article describes that kind of view. From objectives, role to planning with principles. Very interesting including lots of comments. […]

Leave A Comment...