曹竹 BOOK REPORT:Perfect Software
BOOKNAME:
Perfect Software
AUTHOR:
Gerald M. Weinberg
The book is about what we can expect from testing and what are the main challenge and what is wrong with common practice and attitudes. In a word, it is a good introduction to the reality of software testing, both software projects and product. It elucidates things that is needed in creative activities(not only limited to software developing).
It starts with Jerry's definition of Testing a System: "a process of gathering information about it with the intent that the information could be used for some purpose." Gathering information is important. When test fails, something is also learned, which is the imformation why the test failed. The second half of definition is about using imformation. Everyone know the old saying "Information is power." Some wise people has strong desire for imformation while most people fear of overwhelmed by the imformation. The book discusses the fear in detail, how to spot the fear, and how to work with the people who are afraid.
Complete testing of software is generally impossible. In all but the most simple of cases the number of possible paths is almost infinite.(In simple cases, like our alpha release testing, it's possible and it's also exactly how we did it) More often , only a tiny percentage could ever be tested. Since humans are wired( I'm again criticising the human nature, forgive me) to making error in software developing. The bugs are inavoidable. And the number of possible paths where a bug can be introduced into a program is very large which make a bug-free program vitually impossible mission.
But the needs for software never stop. Huge number of programs must be released into the market every year. In this background, developers who wants to be responsable to the customer 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.
The book tells us making the choice to do very little testing is bad. To cover it, one might say no one will experience that bug or redefine the bug as a feature. But it's not ethical and it doesn't satisfy the custommer. In the book, it gives examples about some of the circumstances where people simply deny there was a problem and if the denying is not persuative, they try to condemn someone else for the problem.
After all what is said, the book moves on to the solution. It starts with eliminating all delusions and consider what software testing can do. After that, one develops a testing process that is executed simutaneously with the development of the software. The first step is to test the modules by creating a set of reasonable coverage test values. With respect to each specific module, this set should cover the most likely, the most bizarre and the ones on the limits of designed target. After 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 test operations should be created and executed. In each case, What the software is supposed to be should always be in mind while making the testcases.
In conclusion, this is the right way of testing and I can't agree more with it.