Some best practices to handle User Acceptance Testing effectively in Scrum
UAT (User Acceptance Testing) is an important aspect of the software development life cycle. It serves as a crucial toll gate where actual users test the application, ensuring its functionality aligns with requirements. Additionally, it certifies whether the application is ready to go into production. This process is very critical in terms of providing quality products to the customers.
Photo by Alvaro Reyes on Unsplash
A few important questions about User Acceptance Testing:-
1. Should UAT be inside the sprint?
2. Should User Acceptance Testing be part of DoD?
3. How to handle User Acceptance Testing along with current sprint stories?
4. How are stories planned if UAT is happening outside the sprint?
5. How to handle changes that come post UAT? or how to handle UAT defects?
I will try to answer these questions one by one based on my experience.
Whether User Acceptance Testing should be done inside the sprint?
The team expected to deliver a shippable product each sprint(as per Scrum Guide). Practically it does not happen. Team delivery to production may be monthly or quarterly. Some external users typically perform UAT. A team may not have a UAT tester as part of the team.
There are dependencies on an external team. A team can’t complete UAT testing within the sprint time box. The team needs to discuss with stakeholders and have UAT outside the sprint scope or DoD.
Whether User Acceptance Testing should be part of DoD?
If a dedicated UAT tester is available with the team, it is ok to have UAT as part of DoD. The team can have scope for sprint, usually, that is not the case. Having it outside of DoD is the only option else team would not be able to meet DoD and it would cause spill over of stories.
How to handle User Acceptance Testing along with current sprint stories?
If a UAT tester is available within the team, and the team is planning to include UAT as part of the Definition of Done (DoD), consequently, you should incorporate UAT tasks as part of the story. Tasks should have an estimation. UAT tester should own the story/tasks. The tester can mark the UAT story done if all the sub-tasks are done.
How to plan stories when UAT is happening outside the sprint?
How to handle changes that come post UAT? or how to handle UAT defects?
UAT is done by an external team; consequently, the team has no control over it. There should be an agreement between the team and stakeholders on how to handle UAT.
The best approach would be to have DoD defined clearly. DoD should not include UAT as part of the completion criteria. Stories can marked done without UAT. Stories demoed to PO and stakeholders in sprint review.
The team can have support stories for UAT if it is happening anytime after the sprint. These stories can be estimated with story points. The team can plan these stories in the current sprint. The team can track whatever bugs are coming or whatever support the UAT testing team would require with these stories.
Hope this will help you in handling UAT(User Acceptance Testing) in a better way for Agile projects.