Chapter 1 of “How to break software”

The opening salvo of this book was quite a good read. The author skimmed over various topics such as the types of testing (acceptance testing, conformance testing, etc), and emphasized more on topics he intends to explore further in later chapters.

I liked the way the author stressed some points that are usually considered as common sense. For example:

-       Testers must base their tests on a written description of the software, which can be the SRS or even the user manual.

-       When writing tests, you must have a goal in mind. You need to know what you’re looking for and understand the results of your tests.

-       Testers should never forget that one of the goal of their tests is to ensure that the software does what it is expected to do (as per SRS) without failures.

The authors also introduced a concept I was not too familiar: the fault model. This model is based on understanding the environment in which the software system operates, as well as software’s capabilities.

The authors stressed the importance of distinguishing between the various types of users. As a software developer, when I hear (or read J)  ‘user’, I immediately think of human users (e.g. Admins, power users, regular users, etc). But that is neglecting the other real users of the system. The classification proposed by the author is as follows:

-       Operating system user

-       File system user

-       Human user

-       Other software user (databases, DLLs, etc)

Interesting isn’t it? Further details on each of these users and how to write tests based on that can be found in the book.

Another concept I did find interesting is “freestyle testing”. As mentioned in the book, it is about setting “modest, achievable goals focusing on specific software capabilities”. Waging war one battle at a time. Not trying to chew too much.