Chapter 1 - The six essentials of software testing
Chapter 2 - The state of the art and the state of the practise
Chapter 3 - The clean-sheet approach to getting started
Chapter 4 - Establishing a practical perspective
Chapter 5 - Critical Choices: what, when and how to test
Chapter 6 - critical disciplines: framework for testing
Chapter 7 - verification testing
Chapter 8 - Validation Testing
Chapter 9 - controlling validation costs
Chapter 10 - testing tasks, deliverables, and chronology
Chapter 11 - software testing tools
Chapter 12 - measurement
Chapter 13 - organizational approaches to testing
Chapter 14 - current practices, trends, challenges
I read this book when it came out and thought it excellent. I read it again after 4 years and no longer felt quite the same. Obviously the book has not changed, but the testers' bookshelf has.
When this book first came out there were few testing books (books with testing in the title) which addressed the process of testing, most were very technique focused. In recent years we have seen more and more books aimed at the higher level.
This is a very high level book with a very broad scope. Testing as defined by this book as the searching for bugs and encompasses both Validation and Verification.
I do think that this is a useful book to read, certainly at one point in my career I thought the book very worthy indeed. It may well work best as a reference text. Each of the chapters is fairly short and well sectioned.
I enjoyed reading the introductory chapters of part 1.
There are plenty of references to the numerous standards that abound for testing and development - this is continued throughout the book.
The book tries to summarise as much as possible which can lead to axioms being presented very authoritatively but sometimes without enough explanation to back them up.
Part 4 has some interesting management focused sections although again I found some of the text leading me the wrong way. I do not believe that developers are incapable of testing their own code and I don't believe that Mr Kit does either, although he says it, and then later on says that they should. Presumably he means that developers should not be the ONLY person testing the code which I do agree with.
There is wise counsel contained within.
This is a book I shall read again and I think I will get something different from it each time.