Only between a test and the specific code for the behavior under test. It's not good between test suites, abstraction layers, APIs, etc.
> #3: It’s good when something is known to be broken.
When compared to it being broken unknowingly, but not really otherwise.
> #15: The same bug almost never “reoccurs” so most “regression testing” is pure waste.
> #48: Writing tests for bugs that are fixed does NOT correlate with catching new bugs when they arise.
What about a situation where you have untested behavior (perhaps incomplete test coverage to begin with), then you find a problem in that code and write a test to prevent regression. When you later refactor the code under test there's a definite possibility of "regression" of sorts, especially if the refactoring is comprehensive.
> #20: “Black box” is a political designation and has no technical meaning.
A black box is a system where you can observe inputs and outputs but not the system performing the transmutation.
> #31: On a Web site with 1 million visits per week,a one-in-a-million event can occur once a week.
Quoted for thought-fodder, this one is awesome.
> #51: Granular and/or comprehensive documentation of a nontrivial Web site is demonstrably impossible.
It certainly feels this way, but what's the solution? Have no docs, write docs knowing they won't be comprehensive, or expect to chase an impossible goal?
> #66: If no one ever finds out about the bug then the bug never existed in the first place.
wink wink ... this simply isn't true!
> #83: Bugs cluster at the interfaces, bugs are not distributed randomly.
Isn't this only true if there's more unit-level testing than integration/functional testing?
> #84: There’s more time grains in 1 year of compute time than there are seconds in the age of the universe.
1 year of compute time for what? All of the computers in the world? A datacenter? A computer with a 1μ grain size has roughly 3.15E+13 grains per year but there are over 4E+17 seconds in the age of the universe.
> #93: More testing doesn’t correlate with better quality, less testing doesn’t correlate with worse quality.
I don't have any specific data but my experience has been that testing (manual or automated) does correlate with quality. Testing might be the developer pressing F5 a lot, writing automated tests, or a stakeholder manually end-user testing. Think about the state of software which was developed but never run. Software rarely executes flawlessly first-run, and every time a developer runs it, it's testing.