Re: [ActiveDir] Test Environments

[Matt Hargraves]

It sounds like you have a good test environment.  The only problem is that people may be scheduling their testing a little too tightly.  They need to understand that this is a *TEST* environment.  That means it's in a constant state of relative flux and that at any point in time, it could possibly go down for an hour or even possibly a day or two.  It will largely be available, but it's not production and they shouldn't be expecting to receive the level of support and uptime that they receive in the production environment.  If they expect that, they need to find a way to test outside your test environment.  If their schedules are slipping because of the availability of the test environment, then they're not putting enough extra time into their plans and need to start consulting you before deciding when to test and how much time it's going to take.

It may sound like I'm being harsh on them, but it sounds like they are really expecting too much from a test environment and that's because there isn't enough consulting occuring.  It really sounds like you need to possibly make a "Testing calendar" so that everyone (or maybe even just you) have a list of applications that are being tested in the environment and when schema updates and other items which can affect multiple tests that are ongoing occur, the relevant persons can be notified so if they need to reschedule their testing or adjust their testing schedule, they can.

On 7/25/06, WATSON, BEN <[EMAIL PROTECTED]> wrote:

I was hoping to get some input from some of you to better understand how you handle the design of test environments for application testing.  For example, I built a so-called "Offnet" which is a duplicate of our production domain.  We have a couple domain controllers restored from tape backup, we have Exchange running, and various other production services using the same domain name and hostnames providing for a very production-like test environment.  As time progressed, other production servers duplicated themselves into this test environment and we now have quite a number of people doing the majority of their testing in this environment.  Unfortunately, as more and more people have begun to use this environment for testing, we have found that people are beginning to step on each others toes.  For instance, I used this test environment to walk through the domain upgrade to 2003 and when there was some downtime other people were unable to do their own testing.

 

So I was curious, how do you handle providing a working test environment for people that need it?  At this point, we are trying to determine a better way for people to do their testing away from production.

 

Thanks,

~Ben