Managing Test Environments
QA is built from scratch in our company, our developers are spoiled and QAT was never done in an efficient way (if it was ever done at all...) until now. I've got plenty of valuable visions but getting them realised with that many hurdles is something else.
One of the changes that need to be done from the testing perspective is to get the test environments sorted...
Our test environments are used for several other projects which can have as a consequence that other testers modify data which can interfere with my tests... Currently we have 25 projects going on and just +/- 4 fully usable QAT environments.
I think that the optimal plan would certainly be to manage environments / DB's per project but that would mean that loads of environments with separate DB's are needed. That is not possible on our current test box.
Nor would that relatively huge amount of environments be manageable as per discussion with our budget-focused VP. I guess it would be manageable if the leadership is taken by the QA "Team" but again - The QA team basically consists of me, myself and I and I can't handle it all... The only projects coming onto my plate are the major ones, the others are tested by developers and users.
What do you think would be the best way to tackle that if communication, support as well as getting time (= budget) is a true challenge within our company?
Thanks again for your help!!
Committed QA Analyst newbie with plenty of valuable plans but few support...
Re: Managing Test Environments
I've been in this situation many times before, usually what I end up doing first is maintain control over my environment/lab. Get to people to know that no changes go on that I don't know about, otherwise it affects my test and the schedule gets longer and the release gets delayed. Sometimes taking a hard line is the best, but in a company with bad communication is tough to send out this message in a way to not **** people off.
I'd manage the environments by project, with separate DB's (that at least is managable), with backups available to put in quickly when needed. It's work, but it was the only way in the past for me to handle the work that needed to be done. For separate environments can you use one of the multi-boot programs?
Since you mention the development group, how about IT? Are you on good terms with them? When I have been in similar situations it was helpful to have friends there to give me assistance, or loan me the CD's I needed to reinstall what I needed on my box.
As to persnickety developers, that is always a political game. If you are coming in as the new QA person you are not yet "proven", at least that has been my experience, so you need to show them that you are there to do a job and help them. Push the service end, they are your Customers so you need to know where they need your help, giving them some initial input will help get them on your side. Then you can start pushing some procedures, if they are truly smart developers who haven't had a Testing Organization before, they just need to realize the value you bring. I've successfully handled that in a couple of places, including my current one where its all a bunch of MIT/Harvard grads and doctorates who enjoyed their free-range developing before QA was brought in.
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
Re: Managing Test Environments
What I would do is to insist that all tests run within the testing environment must, at the end of each test, test set, or Test cycle, clean up after itself. This is common courtesy for testers. If data is changed, it must be reset to its original state prior to test completion. If you could get that enforced, you would be on the way to environment management.
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~
Re: Managing Test Environments
Thanks for your input, guys...
Most of our changes are done to our major AS/400 based application. Testing for all projects takes place on one development box which has limited capacity and hosts other applications as well. Environments and databases eat up space and performance and in the near future, there will not be budget to get the box upgraded.
The server is located in our headoffice in the US which does not facilitate things either. The backup procedure is strict, restoring the complete application is almost impossible. Refreshing the databases is difficult as well because they are used for several projects.
Our box has around 20 environments in total (when including the ones for the other application) but they seem to be badly arranged...:
We promote changes in levels. The first level is purely for development with few test data, the next level is said to be for business analysts with a bit more test data and the last level are the QAT environments with a snapshot of the production system. Honestly, that one is barely used... Waste of space. Therefore we're redefining the usage of the 2nd level so that this one is big enough for the testing done by the developers and business analysts. Some people less on the QAT environment.
For the time being we have to find a way to make sure that each project and their testers have their specific range of test data which noone else is supposed to be touching (as far as that's possible). Requires loads of communication but we have to start somewhere.
Another step would be to get a separate environment and DB at least for the future major projects which will be managed and accessed by QA only.
As for credit from the developers... They've already noticed of how much use I am for them. The developers themselves are for most part also not the problem - it's their stubborn unflexible manager.
And that is one level too high for me.
That's why I have to precisely specify and document all of my concerns for the freshly hired PMO manager so that he can start to get things sorted. He is in a bad position as well because he's new...
Politics, indeed. And I have never been good at that...