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!

Також купити книгу Beautiful Testing: Leading Professionals Reveal How They Improve Software (Theory in Practice), Tim Riley, Adam Goucher Ви можете по посиланню