Greetings!
This question was posed to me by a QA colleague recently; 'Shouldn't you be able to run UAT testing within the confines of the Agile/SCRUM methodology?'
Fascinating - huh! ..... Or do I just need to get out more often.
If you stop to think about it for a moment, it kind of makes sense. At the the conclusion of every sprint cycle, there should be a completed effort - inclusive of QA testing and documentation. Right?
So why not incorporate UAT into the process? Couldn't use cases be modified to just test the functionality inherent in just that sprint cycle - as well as cases that may tie into functionality from past sprint cycles?
I know, enough with the rhetorical questions. Truth of the matter is that UAT, by it's very nature, can only be accomplished after the last sprint cycle. When the system or solution is nearly ready to be deployed.
But, isn't true you can exercise a use case or three as long as the requirement functionality is present. Absolutely! Won't the chance to discover defects earlier in the development cycle reduce cost (i.e. cost of quality)? Probably.
But here's the thing. Figuring out exactly what to test could become quite time consuming - largely due to the fact the UAT analyst is focused on business requirements - not functional requirements. The analyst also may not have the expertise to separate the functional 'wheat' from the business 'shaft', and will need development and QA help to do so - taking time from their own efforts. Yes, you may be able to execute a few use cases - but with changes post sprint, time lost by associated parties, along with the need to possibly regression test (which is largely outside the scope of UAT), negates any value of testing during each sprint cycle.
If the UAT analyst were able to apply a testing 'centrifuge' to the process that magically determined what to test, then maybe you would have something there (just make sure you patent the thing first!).
Next topic: Quality is Everywhere: The secret purpose of meetings
0 comments:
Post a Comment