Permanent automated testing / UAT incorporated in sprints

[cgi cgi]

I got a question regarding integration of automated testing into sprints. I am in a very large bid from my company and my guy from internal revision wants that we put a „full blown“ UAT at the end of the development -> what will not work with Scrum as all the benefits go away. It‘s about a portal project (web portal) with an estimated development volume of about 3 Mio. US$.

My internal guy wants a real (anonymised) plan from a ScrumMaster who did these kind of projects in the past (how to plan automated testing up to UAT into the sprints). Do you know anybody I could ask in regards of such a real sprint planning / project plan?

Hope I described my topic understandable. Thx for some Feedback. Christian

[Wouter Lagerweij]

Hi Christian,

A 'UAT' can have different goals. It can be aimed at testing whether functionality works as intended and it can be aimed at getting agreement and feedback from the customer/end-users.

An agile approach would of course handle both of those goals in an iterative way. Not a plan, just apply a good process.

Let's start with getting feedback from customers/end-users. The way we do that in Scrum is to have short (1-2 week) sprints and involve end-users in both the refinement of stories in preparation for the sprint, and in getting feedback from during the sprint review. This particular practice is so core to the agile ideas that it would be difficult to call anything agile without including it.

Then the other goal: testing whether functionality works as intended. Scrum, of course, is built around the idea of delivering working, tested software each and every sprint. This is what makes the previous point possible. There's different ways to get to this point, but there are some fairly accepted practices that will get you there:

- Unit testing and TDD

- BDD (aka ATDD, aka Specification by Example): a structured way of working closely with your customer to specify acceptance criteria, and then implement them against the production code.

- Exploratory testing during the sprint, to find the cases that were not anticipated...

- A stop-the-line, bugs-are-always-fixed first culture. If at any time you find the need to 'triage' defects, you're a long way down a slippery slope that you'll probably never manage to scramble back up again...

Basically, you keep quality high throughout, get the customer closely involved. No one will feel the need for a 'UAT' period at the end of that.

Wouter

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To unsubscribe from this group and stop receiving emails from it, send an email to scrumallianc...@googlegroups.com.
To post to this group, send email to scruma...@googlegroups.com.
Visit this group at https://groups.google.com/group/scrumalliance.
For more options, visit https://groups.google.com/d/optout.

--

Wouter Lagerweij          | wou...@lagerweij.com

http://www.lagerweij.com  | @wouterla

linkedin.com/in/lagerweij | +31(0)6 28553506