Why testing, by definition, cannot find deadlocks and stack overflows?



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2