9 ms·
Reminds me of what we ended up doing at a previous job. We built in-house software for analyzing complex engineering systems. We had some unit tests and develo
by ufmace 5y ago
Reminds me of what we ended up doing at a previous job.
We built in-house software for analyzing complex engineering systems. We had some unit tests and developer tests for basic sanity, but it's tough to cover really working with the app with those. We tried to set up a User Testing environment and have the normal engineer users test there, but we never could get them to spend enough time doing elaborate enough things to really find everything. After a while, we decided it was a waste of time and did all releases directly to Production, but only for a single client out of a dozen. It worked pretty well - we found the bugs in Production like before, but only for that one client, and were able to fix them before updating everyone, and we no longer wasted time doing pointless User Testing.
There's no general lesson IMO except to not get too tied down to any one process like it's a religion. Embrace things that add value, and abandon processes that don't add enough value in practice. If Production is the only place you can get real tests, then figure out how to make it reasonably safe to do that and embrace it.