Perfect Software: And Other Illusions About Testing

I bought this book on the advise of a colleague. Part way through the first chapter I was hooked. I didn't really learn a whole lot about testing, but I did learn a lot about myself as a tester. Chapter 7 almost hurt me with the realization more than a few times of "I've done that", although also provided a deeper understanding of how to deal with people's defensive reactions.I do recommend that most testers give the book a read, and then give it to your manager. Many developers, business analysts, test managers, and executives could learn much from this. I'm now planning on buying this book for a few friends on previous teams that still struggle with some of the points within.

This is a short, but amazing read! It addresses so many misconceptions and misunderstandings about software from all angles: from the software tester, to the developers, to the managers, to the customers/users. Weinberg provides meaningful anecdotes to drive home his points. At the end of each chapter, there is a concise summary and a list of common mistakes based on the topic of the chapter, which gives the reader the opportunity to take these points home (or to work). A must for anyone who develops, tests, managees, or uses software!

Like many who follow Jerry Weinberg's works, I love the humanity of this book. The ineraction and people seem like many I work with, facing these same challenges.I love the book... and don't wish Jerry to change it.I would like readers to consider these thoughts ....Nevertheless there is a gap between this book and the realities of verifying the correctness of software. This area is one many software developers and many testers and quality leads are unaware of.1) Proof: For example, It is a profound truth that like some logic, software logic can be proven correct. Some software can be proven correct mathematically (and indeed must be). The approach to prove correctness (or the lack of incorrect properties) is called formal methods. Some software developers write proofs of linear time logic which is converted to c or java. Software that meets all necessary properties and has no undesirable states could be considered "perfect" when proven so. (Example a dishwasher control program could be proven correct for all time, and meet all requirements for that system.) The barrier to reach perfection (satifaction of all requirements and the application cannot attain states).2) Types of verification : What should the tester know about profiling and instrumenting software for reliable software.3) Where the numbers are and where does software break: What in software systems provide metrics of performance and correctness in testing! Example testers should know that databases keep statistics on query performance. Testers should know that developers and tests can validate the lack of memory leaks and deadlocks. Testers should know how to keep performance history.4) Tools for software quality: What are the types and how are they used. (Example what are static analysis tools (e.g. PMD for java). What are dynamic analysis tools.5) Defending the test environment and test harnesses: Testers should know how to present the benefits of maintaining the testing environment and test tools.6) When can something be tested. What is maturity in software. When does the many eyes model fail.A good introduction is The Spin Model Checker by Holzmann. The SPIN Model Checker: Primer and Reference Manual Thanks

this was a good read, and provided useful information and thought patterns to those who already question the ISTQB formulaic approach to testing.However I don't think that it will change anyones mind if their mind is not already questioning.

I am a software test engineer. I read this book because I was hoping to get some ideas for how to improve my testing, and also to help myself cope with the stresses of the job a little better.I appreciated the author's sentiment that "not just anybody off the street can do testing". While the idea that "anybody could test this" is not often spoken in the workplace, it is one that is sometimes felt by testers, by the way that other people can treat testers. Sometimes we need someone to tell us, it's okay! We do have a hard job, and sure, anybody could try to do it, but not just anybody can do it WELL. Kinda like how, I could try to be a developer, or a consultant, or any other job I am not trained in, but that doesn't mean I'd do a good job at it.Also liked the idea of "apply testing techniques to things outside of the software" that the author expressed a lot throughout the book. You can apply testing techniques to processes in business, you can even apply testing techniques to your every day life. The more that you think about things in terms of testing, the better tester you will be.One of the negatives about this book was, it seemed like the author tried to cover too much in the book. Every chapter had like 10 examples of common mistakes, and there were around 10 chapters. There is no way that I will be able to remember and apply all of those examples. I wish that he had had fewer examples and elaborated more on those few, instead of trying to put all the examples he could think of into the book.Another thing I didn't like was, there were all these examples of mistakes that people make when asking testers to test, but there wasn't a chapter talking about, well here's a software company doing it right! I feel like, I know all the things NOT to do, but I'm not really sure what the "right" way to go about testing is, at least in this author's opinion. It actually seemed like a tester's way of writing a book - find all the "bugs" with a typical software company's way of looking at testing.Finally I found this author's writing style a bit confusing at times. I didn't really understand all of the mistakes and reasons why they were mistakes, probably only understood like 50%. I would have to carefully reread portions of the book that I really wanted to understand. There were anecdotes which were supposed to be funny (I think?) but I didn't get the joke. And there were times when he would go on and on about something when I was like, ok I got your point 10 pages ago (like the part where he talks about excuses people make not to do a code review).Overall, I liked this book, and got a few good ideas for how to improve my testing, and I will probably keep it around to look through when I run into difficulties in my job. But I didn't feel like I got as much out of it as I was hoping to.

Great work Gerald. Plenty of insight into an ever growing, but challenging industry.

An excellent discussion on why there are defects in software.

Good Read. Its well known as a classic in the field and it holds up. I'd recommend this to students in software quality, or anyone interested in any area of software quality. Still useful in the automation days.

I really enjoyed reading this book. Enlightening on the real purpose of software testing, it will help any project manager on better planning for tests and to make the most out of it.I would encourage anyone involved in software development, at any level, to read this book.

Herr Weinberg erzählt ein paar "Geschichten aus seiner Praxis", wobei die so überspitzt sind, das nun wirklich niemand mehr drüber lacht. Vor ein paar Jahren, ja, vielleicht, aber mal ehrlich, wie oft haben wir schon gehört, dass das Management nicht versteht, dass man "alles testen" kann? Traurig trifft man das tatsächlich (selten) noch an, aber drüber schreiben muss man nicht noch mal.Für Tester ist das Buch absolut ungeeignet, da gibt es nichts zu lernen.Für Manager? Vielleicht, wenn sie Null IT-Ahnung haben und keinen PL, der es ihnen beibringt...