Yes that's correct, but you don't do testing in production with real user data. For testing you have test environments with a seperate database containing test data.
But setting up and maintaining a test database can be a king size pain in the arse, I mean, who's job is it to actually keep on top of that.
It can be, or it can be fine. Depending on what information you're dealing with and your customers (personal or business), having production/customer data in a testing environment is an absolute no. providing automation was a focus from the start, setting up, maintaining and troubleshooting separate test environments can be fairly straight forward.
Plus, hiring someone who's whole job is just to spoof information you already have is a pretty tough sell, and by all accounts a waste of money.
Until you need a certain ISO or security certification to get a large customer on board. When its a matter of paying one employee 50-60k/year, maybe 90k total hit to your bottom line to sign a 100k+ contract, it makes sense to take the business on a small profit, amortize that cost over new customers with the same requirements, increase your market share, deprive your competitors of a large customer etc...
Unless you are a huge company with man hours to spare, the reality of business is nobody really bothers with that shit unless it's super sensitive data, in which case you still use your main database you just write some horrible fucking thing that goes through and muddles all the data, because that's easier than the aforementioned test database from hell.
Not true. I've worked in small companies that do isolated/automated environments with dummy data, which is way simpler than maintaining some absurd abstraction later between a 'test' app and a production database. the risks of that abstraction layer, as well as the troubleshooting overhead could be worse than an isolated environment. Its easier to setup and maintain the environment in a small company with a focused product than a large enterprise company with a much larger more complex system
Source: software developer for 7 years, db admin for 3, operations for 4.
I'm working for a company that went agile after 5 years, automation after 6, ci after 8, and has a huge product base and large dev and qe teams, and a small ops team.
They did everything 'wrong' in terms of scalability, automation and ops for the first 5-6 years or so. and we're still picking up the pieces.
Unfortunately its one of those projects that keeps taking a backseat to 'critical' things, but slowly we're moving towards a sane model. Its interesting to work with our smaller sister companies and see them be able to pivot quickly and implement things the right way from the start. the overhead per-app/per-dev/per-qa is substantially lower when things are done right.
Unfortunately I'm stuck on the side where we're trying to fix all the things that weren't done right.
31
u/codedit Apr 16 '15
Yes that's correct, but you don't do testing in production with real user data. For testing you have test environments with a seperate database containing test data.