Heh. Great list. There are other tests too, like Protocol/Standards Certification tests, Code-Coverage tests, Timing-Delay/Jitter tests, Quality/Customer/Play Tests and Performance Testing.

There are also various model for test, including Goldenmodel Comparision testing, Blackbox Testing, Whitebox Testing, Directed Tests, Cornercase Testing, Hardware/Software Emulator Tests and Random Stimulus (You mentioned this, though why limit it to 24 hours? ;)).

And then of course the tests that test the tests that test the tests that test the tests... :)

Personally, I came to programming as a vehicle for testing hardware models (which were actually software models of what would be made into hardware... heh.) And the majority of the tests you mention above were necessary to insure that the price of developing a chip were kept to a minimum. In that model, it pays to test thing exhaustively because the cost of additional tapeouts (essentially bugfixes on a chip) are prohibitively high (around a million bucks a turn at the time). In that developer paradigm, the price of a bug was so high, that even the dopiest management saw the value in early frontloading of the test teams--and we divided those who wrote the tests from those who did the development. On the best-tested projects we developed test suites in parallel with the developers from day one of the design.

Perhaps I'm paranoid, but working with my latest developers has not been anywhere close to the level of testing discipline. And "amazingly enough" the software is remarkably brittle.

One nice thing about Perl is that it enables me to throw a lot of data around without getting in the way of the test object and in a timely manner.