3 ms·
In my experience reliance on these kinds of "test" environments stems from a massively over estimated ROI on manual testing. (Remember, to compete you can't jus
by maerF0x0 4y ago
In my experience reliance on these kinds of "test" environments stems from a massively over estimated ROI on manual testing. (Remember, to compete you can't just have positive ROI, you must have optimal ROI or you'll be out capitalized)
There are plenty of automated and technology driven ways to assert the quality of a system, which are far more reliable, faster, widespread (across more of the system) than preview envs. A lot of testing involves creating chains of logic to make resultant assertions. If A works, and B works when A works, then B works.
And things like compile time checkers (eg types), linters, and TLA+ so I've heard, are examples of things that are better than humans, rapid once setup, and in my experience give massive ROI.
I had a manager the other day say every PR needed a manual "smoke" test before release. I challenged him why would I spend 15-60 minutes manual testing one PR when I could spend that time writing tests that check _every PR_ ? He essentially told me to just fall in line and do as I was told. (No rational rebuttal)