To expand on the internal tool case from the GP: If your software is designed to support, augment, or automate some sort of internal need for non-IT teams, the

To expand on the internal tool case from the GP: If your software is designed to support, augment, or automate some sort of internal need for non-IT teams, there's a significant chance that there's already an inefficient, error-prone process in place as-is. Because even without your software, they still have to get their job done. And they're used to having a "good enough" mindset because they're used to making due with whatever tools/capabilities they have, regardless of fit. As long as your software addresses their needs[1] and isn't any more error prone than whatever they're currently doing, they'll be happy. That said, whenever possible you do want to code your failure conditions or edge cases to fail hard and visibly or expose visible checks for the user. If it covers 80% of their needs, but they have to fall back to their old process for the other 20% of their needs, business users are generally happy with that. But if it pretends to work 100% of the time, but subtly and silently causes problems 20% of the time (and they don't know what 20%), then they'll be distrustful of it and resist (or resent) adopting it. For externally-exposed software, I'd be a bit more wary of not having any tests at all. But for internal tools, I've seen far more systems without tests than with them.