Project Technical Environments

[flicg]

Hi - I'm planning my project roles and responsibilities - specifically those responsibilities concerning data and technical environments. I was always taught that you need to keep your development, system test, UAT and training databases separate. That is great if you will be able to have a dedicated training environment with proper training data setup, but we won't get that. I'm wondering if there's any reason why we shouldn’t re-use our systems test environment for UAT and later for training? The UAT db will be populated with at least some data from systems integration testing which will have got it's data from data migration. I plan that the Data Migration Manager, the Technical Integration Manager and the Technical Environment manager will agree how much data goes into the systems integration testing environment. Another advantage of reusing the systems test envt for UAT and Training is that all the integration will be already setup and we wont need to rebuild it.

Does this sound ok?

 

[johnherman]

We have used UAT for Training, esp for new systems. I don't like the idea of using the systems test area for UAT unless a complete refresh of the data is done. I am also assuming that you do not have multiple versions of your software in various stages of development and test, otherwise you would not even consider doing what you have proposed.

-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright

 

[PDQBach]

Some random thoughts:

Development, Unit Test and Integration testing dbs are intended to test broadly and deeply especially when it comes to "edge" cases.

The training db is intended to teach users who are inexperienced (in the new system) how to handle the 20/80 part of transtions (the 20% of transactions they will see 80% of the time).

In the former case, you want to see what happens when you attempt to access a non-existent customer number or attempt to access an order that has a header but no detail lines; in the latter, what happens when you access Joe's customer record or when you access an order that has some partially filled (i.e., order 5, supply 2, back order 3) detail lines.

As JohnHerman points out: data refresh is a key element. For training purposes, you (or someone) needs to carefully develop appropriate demonstration cases, put them into a clean database and then back it up for regular reinstall/refresh on each training session. Those cases are not likely to be really useful for various testing purposes.

Finally, from an audit perspective, I rather doubt you'll get signoff if the production, test and training databases aren't entirely separate entities.

 

[flicg]

Thanks both. I would love to keep the environments separate, but my organisation doesn't have that concept at all, and I have never heard of anyone auditing project environments here. I want (and it is accepted here) for the business to be responsible for UAT and Training (except IT will provide the application). That means the business need to do the data population. They are best placed, because they will define the training demos and practice scenarios etc. But I just know the business wont be geared up to do that, hence the pragmatic, if not ideal solution of offering them UAT for training if they don't come up with anything themselves. I see now the need for separate int. test and uat envts: we need uat bugs to go thro IT. before they're released onto UAT. Would it be ok to fix the int. and UAT bugs on the dev. envt or do we need some way of keeping a dev/fix envt with the latest version of the envt where we're doing the testing?