Skip to content

User acceptance testing (UAT)

Jump to bottom
Embrik Einang edited this page Feb 9, 2018 · 4 revisions

Definition

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system” Source: www.istqb.org

What is it?

  • User acceptance testing is a process that obtains confirmation that a system meets mutually agreed-upon requirements. The UAT acts as a verification of the required business function and proper functioning of the system, emulating real-world usage conditions on behalf of customers.

General guidelines:

Test early. Make a paper prototype and test it with the customer ASAP. Always test on real users and never on yourself. That includes people working on the project, people paying for the project or otherwise involved. Give the user relevant tasks.

Example of a UAT user story:

  • As a product owner or a SME, I want to ensure that the code developed for this release performs the required business function defined by the user stories and acceptance criteria, so that I can ensure that the released software meets user requirements.

Acceptance criteria:

  • UAT tests perform the final verification of the required business function and validate proper functioning of the software, emulating real-world usage conditions.
  • UAT tests also ensure that business function for the user stories are validated not only from the component level but also from the system integration perspective.

When is UAT testing done?

UAT stories/tasks should be started during regular sprints. UAT testing tasks should be completed and marked done during the sprint.

FAQ:

  1. Should any testing happen before sprint Review?

Meeting a true Definition of Done means that the item is production-ready. Only items that are complete (meet DoD) should be presented in the Sprint Review.

  1. What if during Review stakeholders point out a defect, do we still close the story or leave it open till it's fixed & accepted?

Is the item that the stakeholders identify a true defect (something not meeting the acceptance criteria of the story), or does it reflect missing acceptance criteria? In my opinion, a story should not be rejected if it meets acceptance criteria. Considering the Product Owner should be the only one to close/accept items, does s/he still want to accept the story if a stakeholder identifies an error or something missing?

  1. What if stakeholders invited by PO could not attend the Review & now asking for more time to check out the product during next sprint - is it common to close the story or leave it open till it's formally accepted? I know it's about DoD, so shall it be included there or not?

Stakeholders may be invited to the Sprint Review by the Product Owner, but their non-attendance should have no affect on whether a PO accepts or rejects an item. It is not a part of Scrum to hold up acceptance of sprint items because of stakeholder review. The PO must be capable of accepting or rejecting team deliverables in a sprint, regardless of stakeholder involvement.

If post-sprint stakeholder review uncovers issues, they should coordinate such findings with the PO, to potentially identify additional stories related to missing requirements or defects.

  1. What if the story has been accepted during Review, but a defect arrises in next sprints & it's related to an incorrect formula or logic requested by PO. Shall a PO create a defect or a new story for changing the logic?

Once a story is accepted, it is closed. It is a poor practice to re-open such stories post-sprint. My suggestion would be to have the PO create a new story to address the incorrect requirement.

Source:

Contents

Clone this wiki locally