Exploratory Software Testing |
Author: James A. Whittaker Publisher: Addison Wesley, 2009 Pages: 256 How you react to this book will depend on your personality and on your concern about exploratory testing. The basic idea is that you test software by using your knowledge of programming to work out ways of making it fail. Notice that this isn’t the same thing as unit testing which provides a framework that allows you to change your program without having to worry that you might have done something to break it or any other sort of testing. In many ways exploratory testing is the real test of your code and is more in keeping with what the end user of the code is likely to experience. For every aggressive test that exploratory testing invents, some poor innocent user will eventually apply to your code by accident, stupidity or just by being clueless. The most important thing to say about this book is that it is fun and well written. You shouldn’t have any trouble reading it and finding things that make you smile. I particularly liked the idea that a vague error message is probably the result of exception handling and a precise error message is probably the result of a conditional test – if you think about it then it makes good sense but you might not have formalised it. I was less enthusiastic, however, when the task of exploratory testing was likened to taking a series of city tours – the morning commute tour – test startup, Supermodel Tour – the UI and so on. Some of these metaphors are cute enough to work but even in these cases they are unnecessary and don’t add anything in terms of understanding or guiding the testing process. You could do the same thing with a check list of testing profiles – test the User Interface, test using random or aggressively wrong inputs and so on. You could try creating some patterns and anti-patterns, which is in many ways the role that the “tour” idea is reinventing. I was also disappointed by the final chapter “The future of software testing” which seemed strangley disconnected from the rest of the book. Surely we must have some better ideas how to create automated tools for exploratory software testing than what is presented here? If this really is the state of things then we need something radically new and the final chapter give no hint that anything radical is on the horizon. The biggest problem with the book however is that fact that its main content only takes about 130 pages. The rest is padded out with appendices on testing as a career and pages of quotes from the authors blog. This is a book that just misses the mark. It's well written, occasionally interesting but there simply isn’t enough useful content. |
Last Updated ( Wednesday, 02 December 2009 ) |