[julienzaegel]

(I'm the author of the aforementioned article)

Yes it was a throwaway :-) But I mean "untested" as not tested at all, by any means; code that has went through automated testing (unit tests and the like) has been tested quite a bit, so when QA receives it, the defect rate is not so overwhelming (5% or so as you say). I maintain that the code I write almost never works if I don't write automated tests for it (which is why I always write tests now :-))

You're right about the importance of "looking for undesired behavior outside the requirements". I'll think about an update of the article about manual tests. Thanks for the input!

[geoelectric]

I was QA prior to the advent of mandatory unit test for commit (I'm actually an SDET or tools/infra SWE nowadays, depending on hat) and, even then, untested code was mostly fine, as evidenced by the fields of green "PASS" spreadsheets.

Those spreadsheets either meant it was good when you got it or you did a crappy job testing it, and either way it was fine before being tested. Regression testing in particular is an exercise in generating "PASS" results, and historically QA practice has been dominated by regression testing.

Luckily, SW practices have changed enough that (as you say) most code is at least minimally tested by the developer and, maybe more importantly, some minimal level of unit testing is expected now as a basic professional standard. Hopefully we never move backwards again.