March 24, 2021 at 3:02 am
When it comes to databases the concept of cloud computing eliminates any possibility of proper testing.
In an ideal world databases must be future proof, so the testing must be performed against a “future” set of data, like it would look after couple of years in production, including its variety and scale.
But the main feature of cloud computing is “buy as you grow”. Startups are reluctant to pay for hosting that much data as they will have only after 2 or more years. May be. If it all goes right.
Therefore - wherever you see a new product with its database hosted on cloud - you know it’s never been properly tested.
Which is pretty much every product deployed nowadays.
_____________
Code for TallyGenerator
March 24, 2021 at 4:55 pm
Therefore - wherever you see a new product with its database hosted on cloud - you know it’s never been properly tested. Which is pretty much every product deployed nowadays.
Fascinating...and troubling. Hadn't thought of this before, but makes plenty sense.
Trying to figure out the world of SQL as marketing consultant for SQL Solutions Group https://sqlsolutionsgroup.com/
March 24, 2021 at 6:35 pm
Startups are reluctant to pay for hosting that much data as they will have only after 2 or more years. May be. If it all goes right. Therefore - wherever you see a new product with its database hosted on cloud - you know it’s never been properly tested.
Over my career I've rarely seen anywhere with an "as live" environment that wasn't production. For that reason I don't particularly think this is a cloud only or even start up only DB problem.
Cloud computing cost tends to be a mix of bytes scanned, ongoing execution time and egress charges. Keeping an entire "as live" environment up and running is expensive so that is why you don't do it. Using tools like Terraform you can script your infrastructure and a fair amount of other resources too so entire environments can be spun up and torn down to do what they have to. You can perform stress tests at a far higher level than you would normally endure and shut it all down after an hour or so. Set up correctly this can be relatively inexpensive and more robust.
The separation of storage from compute also allows huge amounts of data to be stored for testing purposes, again at low cost. The pain for moving that data around is intense but short.
The problems I see are where people try and lift/shift a system that wasn't written for the cloud and treating the cloud as if it was part of the company data centre. You have to think about things differently unless you want a money pit
March 25, 2021 at 3:58 am
Over my career I've rarely seen anywhere with an "as live" environment that wasn't production. For that reason I don't particularly think this is a cloud only or even start up only DB problem.
I must be one of those rare exemptions.
when working on long term projects we used to have 3 envorinments.
1. QA, which was effectively "shared DEV". Worked like "throw it in and see what's happening".
Databases were copies from either Testing or Production, or sometimes special databases generated from a script.
2. Testing. Controlled environment. But still DEV hands allowed into it in certain circumstances.
In terms of code it was a copy of Prod plus approved changes from the VC system.
But the data were more than that. There were specially designed test cases which did not exist in production, but could appear there any time.
It was also exposed to the customer's, so they could make up accounts, submit trial orders, and so on.
our test Server was pretty ridiculous, which helped to identify the new code causing performance issues. 🙂 But the size of test databases was usually bigger, in some cases - times bigger than production. So we did not have surprises with degrading performance in Production.
3. Production. Well, Production. Controlled environment, DEV hands off, scripted deployments, data belongs to Customers.
You can perform stress tests at a far higher level than you would normally endure and shut it all down after an hour or so. Set up correctly this can be relatively inexpensive and more robust
I'm not sure what you mean by "stress test", but I don't think you can generate and put into database 3 years worth of data within an hour. With such a small database you may not to worry about any kind of scalability tests.
_____________
Code for TallyGenerator
March 30, 2021 at 7:50 am
This was removed by the editor as SPAM
April 7, 2021 at 9:53 am
This was removed by the editor as SPAM
April 8, 2021 at 12:00 am
Comments posted to this topic are about the item Poor Software Testing
September 8, 2021 at 11:21 am
This was removed by the editor as SPAM
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply