Successful software depends as much on scrupulous testing as it does on solid architecture or elegant code. But testing is not a routine process, it's a constant exploration of methods and an evolution of good ideas. Beautiful Testing offers 23 essays from 27 leading testers and developers that illustrate the qualities and techniques that make testing an art. Through personal anecdotes, you'll learn how each of these professionals developed beautiful ways of testing a wide range of products -- valuable knowledge that you can apply to your own projects. Here's a sample of what you'll find inside: Microsoft's Alan Page knows a lot about large-scale test automation, and shares some of his secrets on how to make it beautiful Scott Barber explains why performance testing needs to be a collaborative process, rather than simply an exercise in measuring speed Karen Johnson describes how her professional experience intersected her personal life while testing medical software Rex Black reveals how satisfying stakeholders for 25 years is a beautiful thing Mathematician John D. Cook applies a classic definition of beauty, based on complexity and unity, to testing random number generatorsAll author royalties will be donated to the Nothing But Nets campaign to save lives by preventing malaria, a disease that kills millions of children in Africa each year. This book includes contributions from: Adam Goucher Linda Wilkinson Rex Black Martin Schrder Clint Talbert Scott Barber Kamran Khan Emily Chen Brian Nitz Remko Tronon Alan Page Neal Norwitz Michelle Levesque Jeffrey Yasskin John D. Cook Murali Nandigama Karen N. Johnson Chris McMahon Jennitta Andrea Lisa Crispin Matt Heusser Andreas Zeller David Schuler Tomasz Kojm Adam Christian Tim Riley Isaac Clerencia 5 Key Tips and Tricks for Testing by Tim Riley 1. If you are going to run a test more than 3 times, think hard about automating it. The time saved is more than worth the front-end investment. 2. Test the riskiest, most changed, and most complex areas first, since they are most critical. These may be tests #10, #35 and #99. But if you start at test #1 and methodically work you way towards test #100 you may never get to #35 and most likely not #99. 3. Always take time to think through the testing before jumping in. This is the "Ready"part of Ready, Aim, Fire. Many testers jump straight to "Fire" and don't know what they are shooting at. This includes talking to the developer, talking through the testing with others, and writing down a plan and asking for feedback. This provides a way to see if you achieved what you originally planned and gives you something to build on in the future. 4. Have the tests ready _before_ the feature is done, or at least very soon after. Testing a week after a feature is done is a hundred times better then testing it a month later. And a thousand time better then testing is 6 months later. 5. Get to know your developers. Not just to show them your test plan and send them bug reports. Go to lunch with them. Walk to meetings with them. Make sure you know what they are working on and what their plans are. And make sure they know what you are working on and what your plans are. By having a richer working relationship, they will remember to include you when new features come alone, requirements change, and plans are updated. And they will eagerly help you out when developing test cases!