Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design (英語) ペーパーバック – 2009/8/25
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
How to Find and Fix the Killer Software Bugs that Evade Conventional Testing
In Exploratory Software Testing, renowned software testing expert James Whittaker reveals the real causes of today’s most serious, well-hidden software bugs--and introduces powerful new “exploratory” techniques for finding and correcting them.
Drawing on nearly two decades of experience working at the cutting edge of testing with Google, Microsoft, and other top software organizations, Whittaker introduces innovative new processes for manual testing that are repeatable, prescriptive, teachable, and extremely effective. Whittaker defines both in-the-small techniques for individual testers and in-the-large techniques to supercharge test teams. He also introduces a hybrid strategy for injecting exploratory concepts into traditional scripted testing. You’ll learn when to use each, and how to use them all successfully.
Concise, entertaining, and actionable, this book introduces robust techniques that have been used extensively by real testers on shipping software, illuminating their actual experiences with these techniques, and the results they’ve achieved. Writing for testers, QA specialists, developers, program managers, and architects alike, Whittaker answers crucial questions such as:
• Why do some bugs remain invisible to automated testing--and how can I uncover them?
• What techniques will help me consistently discover and eliminate “show stopper” bugs?
• How do I make manual testing more effective--and less boring and unpleasant?
• What’s the most effective high-level test strategy for each project?
• Which inputs should I test when I can’t test them all?
• Which test cases will provide the best feature coverage?
• How can I get better results by combining exploratory testing with traditional script or scenario-based testing?
• How do I reflect feedback from the development process, such as code changes?
James Whittaker has spent his career in software testing and has left his mark on many aspects of the discipline. He was a pioneer in the field of model-based testing, where his Ph.D. dissertation from the University of Tennessee stands as a standard reference on the subject. His work in fault injection produced the highly acclaimed runtime fault injection tool Holodeck, and he was an early thought leader in security and penetration testing. He is also well regarded as a teacher and presenter, and has won numerous best paper and best presentation awards at international conferences. While a professor at Florida Tech, his teaching of software testing attracted dozens of sponsors from both industry and world governments, and his students were highly sought after for their depth of technical knowledge in testing.
Dr. Whittaker is the author of How to Break Software and its series follow- ups How to Break Software Security (with Hugh Thompson) and How to Break Web Software (with Mike Andrews). After ten years as a professor, he joined Microsoft in 2006 and left in 2009 to join Google as the Director of Test Engineering for the Kirkland and Seattle offices. He lives in Woodinville, Washington, and is working toward a day when software just works.
Most software organizations split up testing responsibilities in a way where one test engineer is assigned a feature, and then he tests that feature from a lot of different angles - acceptance tests, error tests, stress tests, etc. Whittaker's approach, as espoused in this book, is to turn things 90 degrees around. Instead of the classic way, give a test engineer one angle and then have him test all features from that angle. This exercises connections between features, which is where more bugs (supposedly) live.
That's the thesis, and most of rest of the good part of the book is material to help explain that and flesh it out. Unfortunately, there's also a lot of material that's just filler, like poorly-written blog articles from Whittaker's coworkers. A lot of the rest of it sounds like his own blog posts, too, and one whole appendix is literally that! As an aside, I've gotta say that's a great job if you can get it - reuse material you wrote at your day job, and get paid a second time to publish it in a book. Awesome!
Unfortunately, for such a detail-oriented guy in a detail-oriented field like software testing, there are a lot of mistakes in Whittaker's text. The editor, assuming they actually paid one, did a distractingly poor job, at least on the Kindle version of the book. And the sections written by Whittaker's non-writer coworkers read just like emails - typos, grammar errors, inconsistencies, and all (the guy who uses backslashes when he means forward slashes is adorable when you consider he's paid by Microsoft). The writing feels very authentic for a blog, but not up to professional-grade standards for a book.
Inside this tiny book is a focused 60-page monograph struggling to meet an editor who can dig it out and reveal its genius to the world. There's some good stuff in here, but you'll have to work for it.
EDIT: Apparently I put this review on the paperback version of the book. I actually read the Kindle version of the book. I assume the text is the same, and since I didn't comment on the binding or page material, this review should be just as relevant.
I would not suggest this book to anyone who has more than 10 years on the QA field.