Specifying test Environments
Good morning all!
I've been in the fortunate position in previous roles, that the environments provided for testing have been close matches to those in live. Often we have less space, lower performance, but in general the test environments have been fine for functional testing, if not performance testing.
Here though, they're relatively new to the idea of testing done properly, and I've been asked to specify what we need in terms of test environments, and to justify my claims.
I'm having a go at putting something together, but it occurred to me that I'm probably reinventing the wheel a bit and people far more eloquent than me have already written extensively about this. Has anyone got any pointers to decent articles or blogs on this subject?
Re: Specifying test Environments
I think its mostly making the case in your environment, and a matter of how much they really are committed to testing. But some things I usually point out when trying to get a different environment:
- Shared spaces don't always work, you can't install new packages into a shared space and be sure you have everything that would get to Production
- Often Developers in the same environment step on each others toes, Testing can do that in a worse fashion
- Having an environment close to production gives you a place to verify issues, without affecting customers, and a place to verify fixes
I could go on, but those are my top three. Usually a reasoned discussion works, maybe you can see what the issue is as to why you need to specify and justify. If its cost, then no amount of justification will help if they are not willing to bear the cost of another environment.
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