Effective Software Testing: 50 Specific Ways to Improve Your Testing [Paperback]

If I had to pick one nitpick (and in the grand scheme of things it is probably a relatively small one), one thing I could probably do without was the use of the word "nonfunctional testing". That is, unfortunately, a term all too often used in the discipline of testing and it should not be. For example, performance testing in the book is placed under the "nonfunctional" category and yet it is all about functionality: how quickly the functionality performs! The same thing with security: this is about how secure the application/site functions! (In other words, how secure the functionality is.) So this term is, I feel, incorrectly applied and as such will be used by more and more testers and this is often the stumbling block because usage of the term "non-functional" really often covers up what are, in effect, quality requirements and cost constraints. With that said, however, the material under the section on non-functional testing is well laid-out and is accurate in every respect, as far as I was concerned.

The breakdown of the book in terms of chapters and then items within the chapters is right on the money. And some of the items are wonderful kernels of knowledge that all testers should keep in mind. For example, Item 17 is "Verify that the System Supports Testability". This is a key concept that way too many testers seem to forget about early on and then have to deal with the ramifications of explaining why they cannot adequately test something later on. Yet another excellent element is Item 22, "Derive Effective Test Cases from Requirements". My immediate thought is: okay, but what if there are no requirements? Well, the author covers that very point in an excellent manner. In fact that is what all the items do: they provide a solid reference point for a variety of topics that can be researched by the conscientious tester or analyst. This book is a distillation of a broad array of concepts, from requirements analysis to automated testing tools to evaluating how effective a tester is. This wide scope will, I think, give the book a broad appeal and it serves to make it clear that there is quite a bit going on in the world of testing.

Overall, I think this is an excellent reference book for the average test group within an organization and is certainly worth having in your library if you in any way deal with the world of quality assurance or quality testing. It is rare that I give any book five stars (much less a testing book) but this one deserves it. Will you be an effective tester with this book? That all depends on how you apply what it talks about. But I can almost guarantee you will be an ineffective tester if you do not take much of what this book has to say seriously. Highly recommended.

* Requirements phase.
* Test planning.
* The testing team.
* The system architecture.
* Test design and documentation.
* Unit testing.
* Automated testing tools.
* Automated testing: Selected best practices.
* Nonfunctional testing.
* Managing test execution.

As you can see, the concept of testing is included from the very first stages of the project. This is essential, as it is very possible to incorporate something into the design that will make effective testing difficult or even impossible. Experienced software testers should be included in the planning from the first day of construction.
I consider this book to be a companion volume to those that emphasis testing as part of coding. With this book and one of the others, you can raise the level of your software quality quotient, which makes the life of everyone much easier.

The book is divided into chapters that address a specific phase in the testing process, starting with requirements through to text execution. I won't dwell on the content that will be of particular interest to QA practitioners because the entire book applies. Instead, I'll cite the information that other stakeholders in application delivery will find useful because I believe this book has a much wider audience than just QA:

- Chapter I (Requirements) should be read by project managers and the requirements team. It underscores the importance of integrating the QA team at the earliest stage of a project.

- Chapter IV (System Architecture) shows the importance of communications between the architects and design team and the QA team. Specifically, if QA isn't working closely with architecture, designs may not be testable, which will impose significant costs downstream in the applications delivery process.

- Chapter VI (Unit Testing) gives advice on how to effectively engage the development team in the overall quality strategy.

- Chapter X (Managing Test Execution) has excellent advice on managing defects, which has a plethora of stakeholders and roles, from support, business and development domains. In addition, the guidance on bounding the test execution cycle is not of primary interest to project managers, but also to business stakeholders. It's a sad commentary on the way some organizations manage the test environment when advice for separating the test and development environments need to be included, but this commingling happens too often and I was happy to see it included in this chapter.

This is not a 'how to test' book, it is a compilation of pitfalls and how to avoid them. It is a welcome addition to the growing software quality body of knowledge and one that I recommend highly.