Sean M. Beatty says in "Where testing fails" article that "deadlocks, stack overflows, race conditions and timing problems cannot be detected by testing (whether it is code inspection, whide-box structural and black-box functional)". Beatty, therefore, recalls some special but well-known methods to detect these specific issues.
How do you call the proposed activity if not testing?
Why is it excluded from the test?
This is a terminology issue: what Beatty is saying is that conventional testing methods are unable to detect those conditions.
Essentially, they don't manifest in typical testing activities (and detection requires detailed analysis of the code base by someone with access to and knowledge of the code - which many testers lack). Certainly in my career I've never been in a position to detect any of those conditions short of stumbling across them by chance.
"Testing" in Beatty's article is used to mean "conventional testing" - Security testing falls under the same umbrella as the activities Beatty proposes to track down deadlocks and the like: a specialist activity which someone employed as a tester probably isn't qualified to perform.
Hopefully that helps explain things.
actually the article starts by saying "Testing, alone, cannot find all potential failure points", I don't think anyone here can argue with that- we don't presume to catch all failures in any system.
The proposed activity is called "Code Review"
I totally disagree. Running the same test on the same machine will not do much but running integration tests and running on different environments you will surface some of the racing conditions (works especially for desktop apps)
Another great way to iron out race conditions and the such is to perform load testing - works especially for services and websites. The extra load will force the threat scheduler to adopt different patters in allocating threads. For database level deadlocks you can monitor performance counters that relate to this. For the service level - well you'll most likely get some exceptions that are very difficult to reproduce - I recommend taking a look at a historical debugger such as IntelliTrace if you are in the .net world.
Also, check out a research product from Microsoft called Chess - it essentially changes the thread scheduler of a process on every test run - that should trigger quite a few of the race conditions.
