UAT in an Agile Environment

In my previous discussion, I talked about Product owners being involved in the testing process. In some way, shape or form they are, whether they realize it or not. So with the current topic, it is a perfect segue: UAT in Agile testing. Depending who you talk to or read, there are different opinions, the yes and no side.

Yes, side:

With the user involved within the team, it makes sense for them to play with what is being changed so they can provide the feedback sooner.

No side:

Takes time, and the feedback loop occurs during the demo at the end of the sprint for future planning.

There are a lot more detailed arguments for both sides, and I don’t want to delve too deep into each before I discuss my thoughts on the topic. If you are at the QUEST 2017 conference in Chicago may be, we can meet up for a discussion over some beverages.

So here it is, what I think: I am on the yes and no side. Makes sense? Probably not, let me walk you through my logic and hopefully, it makes sense in the end.

If we look at it from a pure Static Testing view, it is most definitely a yes. Reviews and assurances that the stories have sufficient detail or will have enough detail as the sprint moves along are critical to have what you want in the end. In the beginning, it is a vague idea of what is wanted:

“As a (someone), I want (something), so that (there is a benefit)”

That at the beginning is pretty vague, although what happens is ideas start to flow, and things get into motion. When that happens, the vagueness lifts and more details are needed to ensure the endpoint. The key to all this is the fact that although there is no physical program to use in the early stages, the fact that the feedback loop early is a form of testing that the user has a lot of involvement.

So the code is done and being test within the team, what does the user do now? Aside from planning what is needed in the next few sprints, why can’t they start to look at what is being developed early? The caveat with this is that they need to be aware that it is first, and it may not correctly work as planned due to multiple reasons like environment, data availability, or general issues. From there, they can get that sneak peek that may help clear that picture up early.

In the end, is all about the planning and timing of what can be done and by whom. Regardless of what methodology is followed, planning is needed, formal or informal, and as long as that plan allows for flexibility, great things can be easily achieved.

Now on to the No side. Sometimes the timing just doesn’t allow it, and the demo is the only time users would see what was developed during the sprint and provide the feedback needed. Or there is the preparation for future races that take up the time available to look at something early. These scenarios fall within scheduling and planning. Depending on how the team or organization operates, it might not be suitable for a valid form of UAT to occur. Now they could still do the Static type of testing, and that is usually what will happen to help improve the quality, there just won’t be any Dynamic testing.

The other reason it may not occur during a sprint could be that the changes are strictly back end or architecture in nature, and there would be really nothing for the user to see or do. They may play with the front end to see nothing has changed, yet that would be a quick set of activities.

Something that could occur is taking a sprint for full-on UAT when everything is completed, very counter-intuitive to what Agile is. That one clean cycle that shows that everything that was requested is there and working as expected. Usually, it would be a Beta test in the end.

It is all about planning, comfort level and maturity of a development group that would determine in the end if or when UAT occurs.