CAIRO BOOKS's Description
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 generators
All 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 Schröder Clint Talbert Scott
Barber Kamran Khan Emily Chen Brian Nitz Remko Tronçon 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!