| || |
Handling 2 SQA environments for the same app
I'm currently a BA that is part of both release cycles and production support for a web portal application. The company has not previously had a production support team for this app, so I'm helping to define it.
Our normal release cycle has been about every 3 months. Obviously, a user does not want to wait 3 months to have his/her issue resolved, so we are looking at moving our production cycle up to every 3-4 weeks. We currently have only 1 QA environment. This environment is generally unstable, so there was a decision to implement a second QA environment.
However, because of the application we use to handle the build process and pains of backout, it seems as if release items and production items are stepping all over each other. I am recommending we have 1 QA environment for release items, and use the second QA environment for production items, and let them go on their own schedules, rather than vieing for the same deployment date.
But after giving that some thought, is that really viable? How would the QA environments be kept in sync to mimic production, if prod items are in one and release items in another?
Maybe that's not a good use of 2 environments, which is why I ask. How then is your company/organization using 2 QA environments -- simply as backup when the other environment fails? Do you consider one environment being solely for BA/Internal testing, and the other for UAT? Are 2 environments too much too maintain?
I'd like to get others' opinions and suggestions for dual environments.
Re: Handling 2 SQA environments for the same app
I see a couple of different problems here.
1) Why is QA unstable? If its unstable now, do you know enough about why so the 2 environments you propose do not end up in this state?
2) Why two? If you are releasing every 3-4 weeks, then you should be able to move forward with 1 environment.
3) You seem to think that compounding the problem will resolve it, when you don't really seem to be addressing the initial issue.
I've never really used multiple environments, nor had a need to do so, why you have release and production items stepping over each other makes no sense to me. Release and Production items are the same in my world, so maybe I do not understand yours enough in that respect to see your problem as you do. Although, I would advise, since you are looking to basically be doing short release cycles to focus on one environment and keep it up to date by running your testing in it before things get released. It's not hard, depending on why you had things get out of sync. You can always schedule your releases to be when its good for you, and make sure you manage the packages that come each cycle, you do not want a package that will take you 6 weeks to test when you only have 4.
If you need to have two environments you can use one for staging, where you test in one and when its ready for Production move to staging and then test with more realistic production data. Or perform usability testing with other people, such as Customers, to see if the issue they saw was really resolved. For concurrent testing environments, I think you are asking for trouble and more work than you really need.
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
Now wasting blog space at QAForums Blogs - The Lookout