I bought this book almost 20 years ago with some skepticism. The title made it sound like it was another book for Dilbert's boss.

But this is a great book. It offers readable insights into why tests are performed, and what tests are appropriate at major phases in a software product. And it doesn't oversell the developer's ability -- **nor the tester's**. A little excerpt to illustrate the balance this book strikes:

"If the programmer just produces a working routine without prood and documentation and all but the primary goals are ignored, its quality cannot be measured and management is impossible. Conversely, if the subsidiary and auxiliary goals dominate, management and quality assurance may seem satisfied, but there's little or no working code to evaluate and manage! You can't burden programmers with filling out thousands of forms -- you can try, but it won't work."

I've read this book to build up my software testing knowledge base while I was working for Logitech,CA. Though these're many new tools and papers coming in these years , I 'll still love to recommend this book as an entry book in this field(even this book is out of print).

Every professional and commercial software development organization spends a great deal of time in the testing and validation of their software. The testing process, driven either by legal or financial requirements, can be expensive and may thwart the planned deployment of the application. Many studies indicate that the testing process can even take three times as long as the actual coding itself. Indeed, software development done under the ISO 9000 or FDA auspices can be extremely time intensive.

This book gives a lengthy and fairly comprehensive overview of software testing that emphasizes formal models for testing. In the introduction, the author gives a general overview of the testing process and the reasons and goals for testing. He carefully distinguishes between testing and debugging, and advocates these as separate activities. Testing according to the author is done to find bugs; whereas debugging is done to find the origin of the bugs and fix them. The author characterizes testing as either functional or structural. Functional testing treats the program from the user's point of view, with inputs given to the program, and then the outputs are checked for conformance to a specified reference. Structural testing examines how the program is implemented, in terms of programming style, design, etc. The notion of an oracle is defined as any program or process that specifies the expected outcome of a collection of tests. The author clearly identifies and characterizes the different types of tests that arise in development organizations, such as unit testing, regression testing, stress testing, and integration testing.

In chapter 2, the author classifies the different types of bugs that could arise in program development. Bugs are classified according to functional, structural, data, coding, system, and design and test bugs. He stresses the need to not have a religious attitude about bugs, namely that all software will have them to some degree, and therefore it is the quality measure of the software that is important in deploying the application. If a minor bug requires a major software rewrite for example, it would not be advantageous to fix this bug.

Chapter 3 takes up the notion of path testing, which, according to the author, is based on the use of the program's flow control. The tester selects a set of test paths through the program with the goal of executing every statement and branch of the program at least once. The author summarizes well the flowgraph and process block techniques used to implement path testing.

In chapter 4, the author introduces the concept of a transaction flow as a representation of a system's processing. The flowgraphs developed in chapter 3 are used here to create a transaction flowgraph for functional testing. The transaction flow representation gives a way to model the system's behavior. The author's treatment here is very detailed, and he gives several useful tips on how to conduct this kind of testing.

The next chapter covers the topic of data-flow testing, where again flowgraphs are used, but this time the focus is on exploring the things that can happen to data. Data objects should be initialized prior to program execution, and selecting paths to insure this is the goal of data testing. The author does a good job of defining and characterizing data anomalies, and the strategies employed in static and dynamic anomaly detection. This is followed by a good overview of domain testing in chapter 6. This kind of testing, more mathematical in nature than others, attempts to test whether the inputs to programs are fulfilling some prior classification or specification. The author uses concepts from vector spaces and convex geometry to describe domain testing.

In chapter 7, several attempts are discussed to quantify program complexity, such as Halstead's metrics and token counts. This chapter is somewhat more theoretical at first glance, but a lot of these ideas have found practical application in development, particularly the measures for subroutine nesting. This is followed in the next two chapters by more abstract discussion involving paths, regular expression, and syntax testing. The discussion however is useful, for it trains the reader about how to think about a program in more general, linguistic terms. Such thinking is always useful when attempting to show a particular program is acting in ways other than that which it was designed for.

Logic-based testing, via Boolean algebra, is the topic of chapter 10. The author uses Karnaugh-Veitch charts to reduce the algebraic manipulations to a useful graphical representation. Finite-state machines, so useful in all areas of software engineering, are the topic of chapter 11. The concepts are presented very effectively by the author, and the reader should take away an appreciation of how these constructions are employed in software testing.

The next chapter reads like one straight out of a book on discrete geometry, wherein graph matrices are employed to give matrix representations in software. Linked lists are used to represent the graphs in a computer, and it is shown how testing problems can be represented as a graph problem.

The last chapter discusses how to implement software testing based on the strategies discussed in the book. The three-phase test scenario is described, namely unit, integration, and system testing. An overview of commercial testing tools is also given, with CASE mentioned, but the author chooses not to review the actual packages, citing the dynamic nature of the commercial situation. However he does give a useful discussion of the different characteristics of current testing tools.

If a foreigner taking English as a second language could easily catch what author wanna present , then you should treat this book as a textbook for new entry . This book covers all the basic topics of software testing .

Software Testing Techniques by Boris Beizer is an absolute must for anyone who has a serious interest in software testing. This 549-page book covers nearly every aspect of the process of finding errors in computer programs, moving from basic definitions and terminology through detailed and easy-to-understand explanations of most testing strategies in use today, finishing with a chapter on implementing testing strategies in a development organization.

This book is written with the practitioner in mind, but can equally well be used by students in software engineering curriculums. It presents both theory and practice in a thorough and clear manner, illustrating both concepts and practical techinqes with numerous realistic examples.

All in all, in this reviewers mind, this is a very good book on software testing, in particular for the active practicioner, but could definitely be used by students of software engineering.

Dr. Beizer appears to use the medium of a textbook on black box testing, which is the domain of testers without knowledge of source code or design, to promote the opinion that independent testing is useless except to protect the independent tester. Later, he admits that 80 percent of an average product lifecycle is maintenance phase, which he admits is an appropriate use of independent testers, as he admits also their use for specialized testing tools such as performance tools. His techniques may be effective but an executive level review of this book could be dangerous to the future of quality software engineering practices.

While this is a well put together book, it's reliance on the US IRS Tax Form for all examples, makes it doubtful that anyone not familiar with the form will gain much. This book is probably fine for a US Citizen, but for the rest of the world, his other books are far more accessible.

I agree with the review above: It's a little dry. However, it is certainly thorough, and if you're willing to sit and work through the examples, it's extremely informative. Ironically, I found a number of errors in the examples. Guess he should have applied his own methodology...