2

I've read through some very good resources on the internet trying to find out if my initial proposed testing process is a valid option. So please any advice or recommendations are appreciated.

Currently we have a Dev and Test environment which has served our needs fairly well so far. We are having QA and UAT test off the same Test environment, however our QA testers are complaining that having both teams test in the same environment is causing problems with verifying test scripts and I can see how this could be a problem. However, I don't want to have to wait for QA to be done testing before UAT even takes a look at it, this seems to be against the ideal's in agile development.

I suggested the following new process/architecture to allow parallel QA and UAT testing:

Have separate QA and UAT environments that allow different modules/versions to be tested in parallel. So we can have QA testing ModuleA while UAT is testing ModuleB.

We basically need/want them to test different modules (or the same) in parallel without interfering with each other.

I presented this to our Systems Engineers (so they can build the environment) and they said that UAT should never happen until QA is done. From my understanding of the agile process at this time, I would like to push my proposed process further, but maybe I'm overlooking something?

Thanks!

Improve this question

    2 Answers 2

    Reset to default
    2

    Your system engineers are right; in practically any SLDC including Agile, your users should not be given a version of the software for their testing until QA green-lights it.

    However, Agile allows for the development of software in sprints, and when each sprint is complete and green-lit by QA, it should be pushed to UAT for the users to bang on and give feedback. This is as compared to Waterfall or similar SLDCs where the deliverables are spread further apart and the user doesn't get software to test until initial development is very near complete.

    So, I say in this situation both parties are right, but you're more right. You need separate UAT and QA environments so that QA can test what they're testing and UAT can test what QA has green-lighted for UAT release. These will almost certainly be different release versions of the software; QA should be one or two iterations ahead of UAT, and Dev should probably stay at least one sprint ahead of QA.

    Improve this answer
      1

      The continuous delivery book makes the point here that it makes sense to 'fan out' software into parallel environments as it gives you more throughput and flexibility in your testing.

      http://continuousdelivery.com/wp-content/uploads/2010/09/optimized_pipeline.png

      This sounds nice on paper, but the obvious downside of doing this is that you might UAT test a build that will be rejected by QA.

      For this reason, I would probably stick with the serial pipeline and add a new UAT environment, but place builds in there AFTER the QA testing.

      I say this because the last thing you want get into a situation where you UAT and sign off build X, and then have to go live with build X + 1 which includes just a small fix to satisfy the QA team.

      Improve this answer
      1
      • Thanks for the included resource, looks like another book that is a must read.
        – MisterIsaak
        CommentedMay 3, 2012 at 2:13

      Start asking to get answers

      Find the answer to your question by asking.

      Ask question

      Explore related questions

      See similar questions with these tags.