Perfect Software--And Other Illusions about Testing

As a software testing consultant, I have had the same mentoring session about one thousand times (or at least it seems) with different IT, development and testing managers. These conversions are on the same topics as Jerry covers in this book and the insights he gives are ones I will be adding in my consultations. The value of this book in my view is that it concisely cuts to the key issues in getting software right. Too many people in decision-making capacities hold misconceptions about what it takes to have a successful software project and/or product. The biggest misconception, which is why the book is titled as such, is that perfect software is possible. Companies hire testers to "find all the defects." When they don't, the testers get blamed and perhaps fired. This book explains the reasons why we don't have perfect software, but gets much deeper. It's funny that when people want "to go deeper" in their understanding of testing, they want to learn about tools and techniques. This book beautifully explains the deeper issues of software testing by how we think and communicate about this very important aspect of software development. My copy is now tattered after carrying it from trip to trip, but I keep finding the gems of wisdom. It is easily readable, but will make you think about what we do in testing - and why we do (or don't do) things. I highly recommend it to testers and the people who manage them - all the way up to CIO!

If you've been in testing long, you've probably heard the standard impossible questions: "Why didn't you find that?" "Why would we hire a human to test when we can automate our testing?" "This NEEDS TO WORK. And we need it next week. Period" If you drank the deep draught of testing, if you've struggled with it, wrestled with it, and gotten good at it, I have only one thing to say: This probably ain't the book for you. This book is for the people who are asking you the impossible questions. Seriously. This is a nice evening read and will provide an executive, manger, or developer with enough information about testing to (A) understand some of the challenges of the role, (B) set appropriate expectations, and (C) communicate those expectations clearly. In other words, it can be the difference between a sane life and an insane one - if only you can get the right people to read it. Now, the style of the book is plain prose and folsky story - it's the kind of thing you can read in an comfortable evening, or perhaps, two. It doesn't have fancy metrics and graphs, but we all know what Mark Twain said about that. So if you are a seasoned tester, this book might not be for you - it's for your boss, your bosses boss, the customer, the CEO, and The New Guy. I wanted to get my management team the book as a Christmas present, but somehow all those folks had read it before Christmas ... I suspect a co-worker. Absolutely great for it's niche. Top Flight. Buy two copies to give away today!

Exhaustive testing of software is generally impossible; in all but the most simple of cases the number of possible paths is effectively infinite. By that I mean that while the number is finite, it is so large that only a tiny percentage could ever be tested. So in practice the number is infinite. Since humans are prone to error and the number of possible paths where a bug can be introduced into a program is also very large, the bug-free (perfect) program is an unattainable goal. It is no fun, but that is just the way things are. Being driven by optimism and necessity, humans still create millions of lines of code every year and many of these programs are released into the untamed wilderness known as the customer base. Therefore, conscientious developers have no choice but to develop a testing program that will have a reasonable chance of identifying the most significant and likely bugs in the software. As Weinberg points out, some people do make the choice to do very little testing, sometimes relying on an approach like "If we get lucky, no one will experience that bug." Others simply redefine the bug as a feature and move on. Neither of these approaches is ethical nor will it provide you with legal cover. In a very witty yet understated style, Weinberg describes some of the circumstances he has encountered where people simply denied there was a problem and if that failed tried to hoist the problem onto someone else. As is the case in most areas of software development, the solution lies more in the realm of group psychology rather than technical expertise. Having authored the classis "The Psychology of Computer Programming" Weinberg is an expert at finding what solutions are available to this seemingly impossible problem. It starts with eliminating all illusions and delusions and accepting the inherent limitations of what software testing can do. After that, one develops a testing process that is executed concurrently with the development of the software. The first step is to test the modules by creating a set of reasonable coverage test values. Varying from module to module, this set covers some of the most likely entries as well as the bizarre ones and the ones on the limits. Once the tests on the modules are complete, the next step is to integrate the modules into a functional unit. Once the unit is stable and can be run, an additional set of reasonable coverage test operations is created and executed. In each case, detailed knowledge of what the software is supposed to is used to develop the sets of test values. Weinberg is also forceful in debunking the current state of the automated testing of software, a tactic that he dismisses. The strongest argument against using software to test software is grounded in human psychology, namely the easily adopted assumption that if it came from a computer then it must be right. This belief in the infallibility of technology has a strong tendency to dumb-down humans and that is to be avoided if at

Although new, Jerry Weinberg and his previous book, The Psychology of Computer Programming: Silver Anniversary Edition, should be well known to anyone sufficiently interested in software development or testing to have read this far. This book is one of the 6 (not 5) books highlighted in Bruce F. Webster's Baseline Magazine article, "The 5 Books Every IT Manager Should Read Right Now" which can be found online at [...]. All six are included in Webster's recommended reading list, at [.....] Although this book stands alone and can certainly be profitable to read independently, you should consider first reading either the original edition, The Psychology of Computer Programming, or the 1998 edition, The Psychology of Computer Programming: Silver Anniversary Edition, of Jerry Weinberg's most well-known book. Doing so will help every reader understand Weinberg's mindset. It would not surprise me if, just like The Psychology of Computer Programming, this book goes on to become one of the great works ostensibly relevant only to computer programming that stay at the top of recommended reading lists for people who are not directly engaged in computer programming or any other IT activity. I observe that most references to Fred Brooks's well-known book, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), that show up in the ongoing Google Alerts for Dr. Brooks or his book originate not from IT-oriented web sites and people, but from disciplines outside of IT, such as management, productivity, politics, HR, psychology and non-IT engineering; they seem to rediscover it in waves, every five years or so. Consequently, this is not just a book for QA engineers whose businges is testing software, but one that contains useful lessons for anyone engaged in developing or testing anything, especially intangible objects like software and processes, that need to be tested. This includes, of course, software developers of all types. The examples and lessons are naturally drawn from the world of computer software testing, but they are applicable to any similar human endeavor. Besides, as is the case with Jerry Weinberg's other works, this book is interesting and entertaining to read, and elucidates many things that are in common to all that are engaged in creative efforts. You don't have to be a computer programmer or QA engineer to enjoy this book.

A really useful book. Testing is the most misunderstood of software related activities. Even by software development professionals. The book explains what we can expect from testing, what are the main challenges, and what is wrong with common practices and attitudes. Short, well written (as always with Gerald Weinberg's books), easy to read, without technical details, this book is a good introduction to the realities of software testing, for every stakeholder of software projects and of software products.