By comparison with Test-Driven Development by Example this book tackles the other end of testing; that associated with accepting a product. The book does give some coverage of unit testing but is more concerned with the other aspects of testing.
The book is aimed at those who are new to testing and those who are responsible for mentoring new testers. This is a valuable objective. It is easy to say that software should be tested and simply assume that everyone knows what that means. But in practice it is very easy to write tests that actually assume things about data that may not be true. It is easy to test that software does what it is supposed to do, but what about testing that it handles cases for which it was not designed? How careful has the programmer been with assumptions? For example, it is a common assumption in the US that a social security number uniquely identifies a person. The hidden assumption in that statement is that you mean 'living person'. But how do you test that the writer of some software has not made that assumption? Yes complete testing is hard. Testing multi-threaded code is hard. Testing software that must run in a multi-tasking environment is hard. Testing software that reads in files is hard (remember that the file might be corrupted, a point completely ignored by MS Word 6 which would pull everything down if provided a
.docfile that had got truncated or otherwise corrupted).
The point that I am trying to make is that understand what and how to test is not some innate knowledge that we acquire by osmosis, it is something we have to learn along with learning to write software and to write documentation. How many Computer Science courses teach software testing alongside programming? Some do, but most do not (just as many teacher training courses never teach how to test pupils.)
Maybe you are a programmer and just wish that the test department would go away and stop bugging you. You are wrong to think that way. You should want those responsible for doing the testing to test properly and so point to the failure points in your work. At the same time those in the test department should appreciate being told how they can better test software (yours included). That way the product you are jointly responsible for will better meet the needs of the customer.
This book is not a casual read. It is the kind of book that, in my opinion, is best read a few pages at a time followed by giving careful thought to what you have just read. It is important to understand what testing is about and the responsibilities the tester has to both the writers of software and the consumers of the results. It is the job of a tester to help the software writer to produce a better result. It is also the job of the tester to ensure that the result meets the needs of the client. I think the author of this book tackles these twin responsibilities effectively.
Whether you are about to transfer to the testing side or you want your work better tested you need to put in some time studying how to do it and do it better. This book is an excellent place to start your studies.
