Chapter 2 of “How to break software”

One key point I got out of this chapter is that it is important (perhaps even critical) to understand what the software under test does. Reading the SRS can help when it is available. If you don’t have access to the SRS, use all other documentations you can find like the user manual, or even look at the competing software or the prior versions of the software under test. Spend time using the application to familiar yourself with it. Another one is being reasonable with test cases you write. The author proposed several “attacks” to test the software based on its inputs and outputs. This pretty much amounts to blackbox testing. These attacks include forcing all error message to occur so as to ensure that developers did implement error code, making the software “forgets” its default value and see how the software handles it, testing how the software handles “special inputs” (reserved keyword, etc), overflowing the input buffers to ensure the developers did put a size constraint, and many more. I really liked the examples used by the author to show instances of bugs that can be found using those attacks. One thing I believe is missing from this chapter is the concept of “equivalence partition”, which is a time saving approach for determining which input to use to test the software.