Rating: 
Summary: A must have tool for anyone who is entering into this field.
Review: I found this book very informative and helpful as a beginning software tester. The authors were very pragmatic and concise in defining different methods and systems to use for testing, and because of this, it is an excellent testing handbook for those people who do not have formal training and need to know where to begin and how to procede in a logical manner. It is also a great reference manual for testing terms that are new to a beginner. Overall, I would highly recommmend this as an excellent textbook for software testing.
Rating:
Summary: Excellent resource for all programmers and students
Review: I ordered and used this textbook for four classes on Quality Assurance in the John Abbott College Programmers' course in the Montreal area between 1997 and 1998 and all of us -- students and myself as teacher -- appreciated its excellent coverage of the field and practical orientation. -- M. E. Kabay, PhD, CISSP
Rating:
Summary: A computer classic - still valuable
Review: I've had the 2nd edition for about 7 years and still enjoy re-reading this book. Sure, the examples are getting dated now, but in some ways that makes it more interesting (the description of how to populate a printer test room by begging demo printers from the manufacturers always makes me smile). But don't be misled - the core text and concepts are absolutely as relevant today as they ever were.Software testing and quality can be SUCH dry subjects, but the authors do a wonderful job of bringing them to life. This is a very practical book in the sense that testing processes are described from the point of view of someone who has tried almost everything and knows which approaches are great in theory vs those which actually work. Unlike many others, the book doesn't skirt around human resources issues (such as internal politics, motivation and staff retention) but tackles them head on in the last chapter (it really is worth reading cover-to-cover!). It is not really a step-by-step instruction manual, more a series of ideas and tips bound together by a coherent story. Us readers really need to think about the topic and work out for ourselves which aspects to apply. That said, some parts are more like a cookbook - there's a good description of a bug tracking process, for example, with some example bug reporting forms and, as always, some excellent advice about cooking your own. Testing Computer Software has been a great help to me in my role as a computer auditor dealing with numerous application development groups. Project teams rarely have the skills to plan and manage testing properly, and never (in my experience) get the resources to do everything that "needs" to be done before the product ships (just how many groups never really get around to completing the documentation they promised so many months before?). Testing comes at the most time-critical point in the project lifecycle, when everyone is under intense pressure to deliver, fast. This book helps the team plan ahead, preparing the testing organisation and processes to make the inevitable nightmare period pass as smoothly as possible. That includes the audit team, by the way! The appendix lists 400 types of bugs with their descriptions. As I write this note, I'm using the list to think about tests planned by the project teams I'm currently auditing, looking for holes in their test coverage (no, not 'tick and bash' - I'm trying to help!). The bottom line: a must read for anyone involved in releasing software.
Rating: 
Summary: Excellent Review of History
Review: If you are maintaining software created from 1979 to 1984, or creating new software based of software from this era, this is the book for you. It is an excellent review of history. It is an outstanding source of lists. If it is updated to modern software programming, programming techniques, and philosophy, it has potential.
Rating: 
Summary: good
Review: It does describe lot on using testing tools but fails to Provide the implementation Details.
Rating:
Summary: Excellent book for PC/Client-Server software testing!
Review: Lately I have read a lot of computer books. I have been in the software development business only about two and a half years. This is the best and most useful book I have read. I have tested, and am testing, software. This book is perfect for any tester or manager of testers. The authors are truly enlightned and experienced and best of all, they transmit their experience and knowledge to the reader in a most organized, logical and concise manner. A "must" for anyone involved in testing in any way.
Rating:
Summary: Single best book on practical software testing
Review: One great testing book. What makes it great? It is pragmatic from start to finish. It addresses real problems in the world of software testing. And does so acknowledging that there's never enough time to do everything you want let alone trying to fulfill the overblown government perscriptions of ISO, SEI, and CMM.
Rating:
Summary: An excellent book, and a great time for republication
Review: One of the best computer books I have read. Very informative for software pros as well as novice software testers. Includes everything you need to know about testing and the National Software Testing Standards plus Dr. Kaner's legal comments. Lots of references to other publications. I believe it is a great time to republish this book with inclusion of the "Year 2000 software testing methodes". I would like to be first to know if authors decide to republish "Testing Computer Software".
Rating: 
Summary: Too broad of an overview with some outdated perspectives.
Review: Suddenly thrust into a QA management position after a decade in software technical writing, I scrambled to find good information about the task before me. I have some familiarity with the software QA process after this many years in the industry, and was therefore very surprised that this book does *not* cover some topics I had hoped to find, such as smoke testing and negative testing. This book makes some assertions about process that actually vary from company to company. This could confuse those inexperienced in the software industry. For example, the book says that as software nears Alpha test, the "documentation plan is probably ready for review." Where I work, the the *documentation itself* better be substantially complete by Alpha test, or there's no hope of the documentation shipping with the product. The chapter on testing documentation misses the mark, as well, focusing heavily on user manuals. Traditional user manuals are decreasingly common as usage information moves online. The book barely discusses online help and overlooks embedded user assistance and electronic performance support tools. Finally, I wish this book had been organized in a more expository manner. Chapters are loosely grouped by general subject. I had hoped to begin reading on page one and let the book teach me about testing. Instead, this book seems to be better suited for use as a reference guide when I need information about a particular subject. Given that I have not found information about some subjects, as I mentioned earlier, my confidence in this book's ability to help me is very low.
Rating: 
Summary: Author's comments on Testing Computer Software
Review: Testing Computer Software is about black box software testing. The approach is pragmatic, and intended to reflect the engineering style followed in Silicon Valley.
I started writing this book in 1983, while working at MicroPro (WordStar) as the Testing Technology Team Leader. The books, courses, and standards available to us didn't reflect our style of engineering, or the role of the Software Testing Group in our company. This was a widespread problem--our development style was typical of the best mass-market software developers in Silicon Valley.
Testing Computer Software reflects several realities:
First, the software is usually developed from very abbreviated specifications. You can't base a test plan on detailed internal and external specs because they don't exist, or they are impossibly out of date.
Second, the product is being developed for mass-market customers, not for a single customer who is paying for custom engineering. The single customer approves specs, signs off on them, and agrees to pay for a product that meets the spec--even if it's hard and disappointing to use. In contrast, in the mass market, customers don't look at the program until after you start selling it, and they don't buy it unless they want to.
Third, because the mass market's expectations change over time, the software's design, including feature set, will change significantly throughout the development of the product. Changes will reflect new market requirements and better understanding of the customer's needs for usable software. The solution isn't a bureaucratic change control system--you want to stand in front of a fast-moving train? OK, but you'll get run over. The NEXT test group manager will know that the real solution is to change your testing approach so that you can cope with continuing change. I'm not saying that we should embrace chaos. I'm saying that in the mass market software world, we have to expect and deal with a lot of change. Processes based on the fantasy that the "quality assurance" group can exercise extensive change control will not work.
Fourth, the typical testing group does BLACK BOX testing. The test group has little or no access to the source code. Test planning and test case design strategies that depend on knowledge gained from this access are unrealistic. By the way, this isn't a bad thing. Programmers do a lot of glass box testing, and they find a lot of bugs. By analyzing the product from the customer's viewpoint, black box testers often find several problems that glass box testers would miss.
Fifth, the book accepts the fact that software companies don't fix all the bugs that they find, before releasing the product to customers. I talk about advocating for bugs, reporting bugs in ways that will increase the probability that they're fixed. And I talk about setting up good bug tracking systems so that bugs don't go unfixed by mistake or by the whim of a single programmer. Testing Computer Software was apparently the first book on software testing/quality that accepted this reality and talked to testers about how to deal with it. Since then, that acceptance--and a responsible approach to risk management for analyzing the bugs and the areas of the program that will be undertested--has been called the "Good Enough Software" movement.
Testing Computer Software has been controversial. A very senior expert in the field tried to get the original book suppressed, writing to the publisher that that it was a "puerile, non-professional approach to software development," that it glorified the work of hackers "who are responsible for the disgusting lack of software quality that pervades this industry". He said the book would sell to a "market of amateur and subprofessional programmers and 'testers' for this kind of garbage."
Over the years, and through the next edition, Testing Computer Software has become more widely accepted. My publisher recently advised me that it's now the best selling book on software testing. I think that its success has rested on the belief that it reflects, that quality improvement isn't about preaching and moralizing about quality, and it isn't about mindlessly filling out forests worth of paperwork in a vain effort to regulate creative design. Quality improvement starts with an understanding of how we do things today, and of what works well in what we do today. From there, we can improve. Without that grounding in reality, we are lost.
| 
