Useful but dated
|
|
Contains some useful ideas and comments on the theory and practice behind software testing but as previous reviews have noted, it is maybe starting to show its age a little bit and is probably due a revised edition. Not everyone will find all chapters of this book interesting or relevant with seemingly unecessarily large volumes of text on things like; the in and outs of testing printers, creating in-house bug tracking and reporting processes, managing testing teams and legal aspects of software testing (based almost entirely in US law). Overall, if you are interested in all aspects of the testing process you could do worse than buy this book but there are probably better texts available.
|
|
|
difficult to see past the outdated examples
|
The principles this book illustrates are good, but it's very difficult to focus on what it's trying to say without being distracted/put off by the outdated examples.
Large portions of the book constantly refer to driving hardware devices (e.g. handling keyboard input, refreshing the screen in error recovery procedures, observing the [text] console while it's being updated in order to spot any irregularities, and one of the tips given is that if the screen is updated too quickly for you to be able to see an irregularity you should try running the program on a slower computer!)
Is it necessary to advise the reader about the design of a bug tracking system? (there are so many commercial and even free products available). Once again there is useful information in this chapter - you just need to apply it in *selecting* one of the available bug tracking systems.
If you're willing to put in some hard work [distilling the principles] then you might get something out of this book, but for most people my advice would be to give this one a miss.
|
|
Full of good ideas
|
|
The first chapter gave a bit of a bad impression. It's written in the past tense from the perspective of something that the reader has experienced, but probably has not. Thankfully it's a short chapter, and the book improves rapidly. It seems to cover everything that you might want to know about testing, though with a couple of idiosyncracies. Firstly, there's a slant to testing DOS software printer drivers, probably something that very few people do these days. Secondly there's an interesting chapter on the legal aspects of testing which isn't perhaps entirely pertinent to the testing itself.
|
|
Everything you need to know about introducing a Testing Dept
|
|
This book is absolutely brilliant for getting you started if you need to introduce Testing as a discipline to your company. If you are facing barriers, this book will help remove them with sound and practical advice on test strategy, some simple processes, an easy bug database, plus much more. After your first project is completed suddenly people will start seeing you as a force to be reckoned with. Respect will begin to flow your way and once-sceptical colleagues will begin to co-operate. This book teaches you a common sense approach to software testing with healthy doses of best practice and practical advice from test strategy through to example bug reports. But if you already have a testing process, why not check this out anyway? You may learn something new. Problems with sensitive Designers or Developers? Then read about non-confrontational bug reporting. 40% of all bugs found in Requirements specs... learn where testing really should begin - at design not after beta release. I can't recommend this book highly enough. Without it I could not have established and managed a testing department of ten, that achieved half of the CMM within 6 months.
|
|
|
Good text...excellent coverage...bad philosophy...
|
|
I first read this text back in the early '90's and believed it to be incredibly incisive and perceptive. It seemed to illuminate problems before they existed for me! I felt I had an 'inside edge' on the other guys. However, as time went on, I began to realize that the text espouses placing my proverbial fingers in the holes of our crackling dam. I now use the book as a starting place on designing logical test cases. However, that is where the book stops. See, in producing software for the government, there are these things known as REQUIREMENTS which must be verified and validated via inspections and a traceability matrix, respectively. I suppose this situation is also prevalent in corporations who wish to sell software to the burgeoning EU, Japan, and Australia. With standards such as ISO 9000.3 and the CMM becoming more and more important, I would like to see Mr. Kaner et. al. attempt to incorporate these standards (which are ensconced in Quality control) into their up coming revision. Who knows? Maybe it is possible to actually perform great testing in both the logical-based and requirements-based arenas?
|
|
|
United States | 
United Kingdom | 
Canada