Managing UAT – Test Early

This content is syndicated from Agile Testing | Tester Troubles by Ray Claridge. To view the original post in full, click here.

WhisperIn 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!

Leave a Reply

Your email address will not be published. Required fields are marked *

one × four =