We don’t need to test.
I am the sole developer for an in-house fully custom CRM. It was developed by an amateur and was clunking along managing a mid-sized company’s affairs. It was undocumented, messy, and riddled with tricky bugs. I was brought in to maintain and extend it.
The first thing I wanted to do was document it, clean it up. Nope. “That’s not what we’re paying you for” I was told. “We need you to fix the big problems and add features, and we need you to do it fast.”
I made a herculean effort to give every senior employee every item on their wish list, no matter how nonsensical. The timeframe I was given was something like half of what I needed to do a good job, so I half-assed it. I’d write a new feature, test it once, and call it good.
Months down the line, I’m still getting so many requests for new features and behaviour tweaks that I have absolutely no time to make sure my code works well. Occasionally, something will fail spectacularly and I’ll have to scramble to fix it. My boss will not allow me the time to slow down and do a better job, and when asked if I could have a tiny percentage of someone (anyone!)‘s time in the office so that I could have SOME kind of QA I was told that my code shouldn’t have bugs in the first place. This was accompanied with some pointed words about my upcoming personnel review. I attempted to explain that ALL software has bugs, and that QA (and documentation!) are a necessary part of the process. No joy.
The lesson here, fellow trenchermen, is twofold, number one, INSIST on the time and resources you need to do your best work. If you do not get what you require, communicate that you will not be responsible for problems down the line. Put it in writing. The second lesson is don’t work for a boss that can’t code. It sucks big fat hairy monkey balls.