This isn't one of those jargon-filled tomes that cannot be read from start to end without investing a lot of time and effort. The book is relatively short and easy to read through. Coming from a non-MS world and having worked on a contrasting set of technologies, it was still useful for me to go through the chapters and pick up some useful insights on development practices. Being a testing professional myself, i did have some disagreement with the way testing was presented. It is hard to please a tester ! Chapter 6 is devoted to testing and it appears to me to be a fairly simplistic view of the testing function that can probably act just as a very basic primer into testing. While the general comfort level with the content of this chapter is not too high, some points stand out and i thought i'd mention them here.
Chapter 6 includes a section on Code Coverage analysis and tends to imply that performing code coverage analysis will answer the question "Did we test everything?". This i would say is incorrect and an improper way to judge test coverage. From a business perspective, a code coverage number or percentage can be meaningless. What would be useful is to verify that of all the requirements - functional and non-functional including usability have been covered. While code coverage measurements have some value, excessive focus on using this to measure testing is fraught with dangers. You get what you measure and reward. It does not take much for the testing organization to orient testing and tests development to achieve higher coverage numbers without adding much value. The focus is also on verifying what the developer has done and not about validating if what is being developed is what is needed by the customer/user. There's a lot of literature on code coverage and testing and so i will not get into that here. Suffice it to say that code coverage should be one of the metrics that you use and use it after understanding it. However, it should not be the one / sole metric to answer if you have "tested everything".
Also, in the same chapter there is a section on "testing phases and efforts" that states that, "Unit testing is commonly performed by developers on an ad-hoc basis as they code, and may include ad-hoc tests as well as tests from formally defined test cases". This paints a poor picture of unit testing and seems to indicate that this is the norm and may be followed by others. Unit testing is an important activity that needs to be followed with due rigor and discipline. Ad hoc unit tests are a bane of development that runs contrary to the development practices that the book recommends. Also, few testing types are covered and that too in a simplistic manner. Some statements may not truly and fully reflect the exact picture about testing. However, my recommendation to readers who know about testing is to skip the chapter and for the newbies to read it to gain a general overview of testing but realize that you'll get better and more detailed views on testing elsewhere.
Wrapping up, most of the description of phases and activities in the book seems to coincide with the sequential lifecycle models. Today development organizations follow different models, including the popular agile models of development. There is a difference in how development and testing occur across the different models and the set of challenges they face. However, the book does offer practices that can serve as useful guidelines for developers and more so for developers using the Microsoft tools and technologies. The coverage of Microsoft tools seems extensive and is something that a developer coming from the MS world will appreciate.
The book is available for download at http://nexus.realtimepublishers.com/dgbcq.php?ref=grm
