In a previous post I discussed how I managed to do UAT badly in the past. Now I will discuss a generalised model formed from those (and other) experiences, which should allow me to make fewer UAT mistakes in the future.
Previous Post on How to do UAT Badly
The problem was, I looked at the wrong words
I think my fundamental problem occurred because I read “USER acceptance TESTING” when I should have read “user ACCEPTANCE testing”.
I really don’t like the phrase “User Acceptance Testing”. We do not accept the user by testing them, so I find the phrase ambiguous. The phrase misses out the important part of ‘accepting what?’ and ‘what does acceptance mean?’
I would prefer the phrase “System Acceptance Testing” - at least that tells me what thing we want to ‘accept’ (although I still don’t know what acceptance means). And then we can say “User conducted System Acceptance Testing” or “User specified Acceptance Testing”.
If you like the phrase “User Acceptance Testing” then why not also have “User Acceptance Review”, or “User Acceptance Demo” or “User Acceptance Walkthrough” - why would ’testing’ result as the most relevant process.
A Generalised Model
- Focus on the Acceptance.
- Work out who needs to accept something, and what it means to accept something.
- Choose the most appropriate mechanism for accepting something.
accept some thing by having some people do some process
And yet more mistakes
And in the spirit of learning from mistakes - I’ve managed to make mistakes learning how to implement this model too.
I really don’t just mean - let the users decide what to do.
On one project I wanted to avoid the horrible notion of just passing on system tests to execute so I got the BA to work with the users and describe high level scenarios, and I got involved too. But they didn’t know when to stop or what level of detail to do down to. I didn’t know enough about their business to know if they had done enough. A messy mess. I didn’t focus on the fundamentals. We still focused on trying to do ’testing’.
How to implement the model
Now, I get people to work out what they consider as their acceptance criteria. What do they consider as their convincers?
“How will you know?”
The question I now give people to help them understand what I try to explain through all the above text. “How will you know?”
- How will you know that the system has met your requirement?
- How will you know if the system supports your business process?
That leads on to other questions:
- What do you have to see happen?
- What do you have to do?
- What do you have to look at after you have done that?
Then when you have a whole bunch of answers. Step back and survey that set of ’things to do and see’ and say - “so if we did all of this… would you feel convinced?” and if we get a “hmmm… no” answer - then you have managed to identify more items for your acceptance process.
