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!
Parallel Testing options in Agile Development?
agile;testing;qa;sdlc
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.