-1

We currently do User Acceptance Testing (UAT) at the end of the every sprint. I circulate an email to the team letting them know the features that have been developed. The idea is for them to report any bugs to the dev team for the features developed in that sprint.

I need to put a process in place to ensure that the team are doing UAT properly, since the team has trouble doing UAT. What checklists should I give the team?

  • 1
    Can you state more specifically what the users are doing incorrectly? – David Espina Nov 7 '16 at 12:09
  • 1
    Hi, the question as it stands is way too broad to be properly answered. Could you please let us know the actual problems you're trying to address? – Tiago Cardoso Nov 7 '16 at 12:16
  • 2
    Who on your team is doing UAT? To whom do you send this email? What process are you using to ensure that the team is doing UAT properly? What is "properly"? I'm not trying to be a jerk, I'm just trying to get more details to help me to understand the question. I have the feeling that there are are some assumptions that I'm missing, and if they were clarified, I'd have an "AHA!" moment. – Mark C. Wallace Nov 7 '16 at 12:56
  • 1
    So, after you send out the e-mail, what are your observations that lead you to believe they are not performing UAT properly? – David Espina Nov 7 '16 at 18:23
  • 1
    I think everyone is asking great clarifying questions, but at heart this is an X/Y problem because the team (including the PM or Scrum Master) should not be creating their own UAT criteria. – Todd A. Jacobs Nov 7 '16 at 18:27
4

I agree with @CodeGnome but not just with Agile. No matter the method, the product, or even the domain, UAT needs to belong to the users, in scope, conduct, and outcome. The client side needs to define how to conduct UAT, the scenarios it will run, procedures, training people, how to document findings, any criteria needed, etc. After all, UAT is a client risk and quality action.

The only caveat I would have to this is if their UAT action, or inaction, is adversely impacting your ability to get to production in some way. This is why I keep asking what you are observing in the comments above.

  • +1 for noting that UAT isn't just about agility, and that the users always own the effectiveness of the UAT process. I couldn't agree more! – Todd A. Jacobs Nov 7 '16 at 18:42
  • My PO basically wants people the team to do UAT to try and find bugs and give feedback about the features based on the acceptance criteria. Right now, he feels that it is not taken seriously enough, since he is the only one doing it after I circulate an email asking for everyone's feedback for the features implemented in that week. If the PO just does UAT (which I think he should do to check if everything is passing the acceptance criteria), the process is very smooth, since we get relevant feedback about the features we have developed. – bobo2000 Nov 8 '16 at 14:16
  • Your PO needs to get your project sponsor involved. The users clearly are not motivated to do the work. This is the sponsor's role to get them motivated. If your PO is the sponsor, then he is not the right guy since he doesn't seem to have the authority to the users to jump. Find the right sponsor and get him/her to act. – David Espina Nov 8 '16 at 14:20
3

UAT Checklists Should Come From Users or Their Proxies

What checklists should I give the team?

From an agile perspective, you should not be giving the team a user acceptance testing (UAT) checklist at all. Your product's users (or at least a Product Owner or business analyst if you're not agile enough to work directly with your users) should be working with the development team to develop acceptance tests prior to the development of the feature.

Ideally, these acceptance tests should be executable (if software) or automatable (for example, via computer-vision validation). That way, there's no subjective question about whether the right thing was built, since the desired result was defined up front.

Even in legacy shops where UAT isn't automated, and basically involves a great deal of subjective poking around rather than formal validation, the criteria for what should be delivered—and perhaps more importantly, how it will be measured—absolutely must be defined first to ensure an effective delivery pipeline.

  • And testing needs to happen as absolutely close to when the work is done as possible. Waiting until the end of the sprint just means anything that fails gets moved to the next sprint. Build it, Test it, Finish it. Then move to the next item – Joel Bancroft-Connors Nov 7 '16 at 22:23
  • We have acceptance tests, the problem is where we will find bugs after the stories have been implemented. Due to a lack of mock ups too, there is always subjectivity from the PO about design aspects. We do not do automated testing at all, the company I work for doesn't want to do it since it slows development time writing the tests first then the features. Joel - we get everything implemented by Thursday, then use Friday for bug fixing. I know this is not 100% orthodox agile, but it does work quite well for us – bobo2000 Nov 8 '16 at 14:20
0

You are getting UAT done to check the functional flow of the program. The way is to get the test cases prepared by end user who has given the requirements. Request him/her to run through the cases during testing. This must include the additional cases which you should add during impact analysis. In case of a bug fix, user should test test cases prepared by you. UAT sign off should be only if the test passes through all test cases.

Don't forget to ask for all artifacts(screenshots) of test done.

Add these as RFC checklist before production release.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.