|
This can be a complete disaster if done wrong - because your masking script can either make the data indexes invalid (if you mask everything to the same value) or different to production if your masking results in highly random data.
|
|
|
|
|
I have learned that proper "data masking/test data" is an art form, really. I have seen it done very poorly, thus my opinion.
|
|
|
|
|
In our case we need checkboxes instead of radiobuttons.
We work on a per project basis were money is allocated for a limited period of time. In my first project we had two (identical) servers so I was free to build a production and test environment, but most projects don´t get that money or even more often, the managers of that project don't see the need to waste money on "testing" environments... 
|
|
|
|
|
If anything we're testing the user's patience 
|
|
|
|
|
One reclining love seat and a laptop.
|
|
|
|
|
We do all of our development in Production. I never understood why someone would need more than one environment. This isn't Minecraft you know.
sheesh
modified 28-Mar-16 13:28pm.
|
|
|
|
|
I use VM for this too - but not in all projects, only where I see fit...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Trust me, even with unit testing, coding standards, superior intellect... it doesn't matter, if there is a way to muck-up software, the customer will find a way on their machine. 
It was broke, so I fixed it.
|
|
|
|
|
The best environment I ever worked with though was where we had..
1. Unit Test/Development testing - This at one time had been a full copy of production, but the data on it wasn't updated too often. It was enough to get by with.
2. UAT Test Environment - this was a full copy of production, updated by a full refresh prior to each major test run (we typically had 2 a year, sometimes more).
3. We also had a "Model Office" that was used for training and occasionally for understanding any issues. This was rarely refreshed as it contained specific scenarios for the training scripts (schemas were kept up to date though). It did mean that devs did not interfere with training (which was an on-going thing) and vice versa.
All of these had drive remapping scripts so from the user perspective they still went to drive "X" to find the apps they needed.
The worst scenario I ever worked with was having no test environment at all - I had to use my own development machine and a lot of time was wasted trying to "de-productionise" any data I copied over.
As the title of this post suggests I've had to use the full range in between - you can imagine the difference in quality of the finished product in each case.
|
|
|
|
|
At various times for various projects I've used all of these:
We have a test environment that is a replica of our production system
We have a test environment that is a scaled down (but similar) version of production
I use my development machine
I have no test environment I can use
as well as:
We use the production server in development/test. (A stupidly expensive solver platform that was licensed in a way that we'd have to buy a second stupidly expensive license to have a separate development server to test the back end with.  )
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
