In a previous post I wrote about the tester writing user stories which in effect becomes the earliest form of testing. So what about UAT, how early can this start?
Traditionally, the business/product owners are involved early in the requirement gathering process, but they don't see the software until it's been developed and gone through system testing. Personally I think this is bad practice for a number of reasons:-
- Software development sometimes feels like a game of Chinese Whispers.
- I've lost count on the times I've heard "that's not what I asked for".
- No matter how good a static design might look, it's not until you see the feature in action, do you realise it's not going to work.
- Spending cycle after cycle testing software to eradicate all defects, only for the business to request a bunch of changes.
As someone who is responsible for the STLC (software testing life cycle), I practise what I like to call "pre-UAT". The following measures can help to avoid the common issues above and also improve business relationships:-
- Encourage your development team to build prototypes.
- If prototyping is not possible, encourage your development team to demo work-in-progress to the business/product owners.
- Encourage the business/product owners to perform a pre-UAT cycle by giving them access to QA/Systest (even if defects still exist).
This way, if there's any functional misunderstandings or design issues, making a change at this stage is not the end of the world (and costly). It also means I can be confident that when a user story/feature passes system testing and goes to formal
UAT, it's not coming back!
In a previous post I wrote about the tester writing user stories which in effect becomes the earliest form of testing. So what about UAT, how early can this start?
0 comments »
Post a Comment