 |
Home > Detail: When Should a Test Be Automated?
|  | |
When Should a Test Be Automated?
By Brian Marick
  
Summary: I want to automate as many tests as I can. I'm not comfortable running a test only once. What if a programmer then changes the code and introduces a bug? What if I don't catch that bug because I didn't rerun the test after the change? Wouldn't I feel horrible?
Well, yes, but I'm not paid to feel comfortable rather than horrible. I'm paid to be cost-effective. It took me a long time, but I finally realized that I was over-automating, that only some of the tests I created should be automated. Some of the tests I was automating not only did not find bugs when they were rerun, they had no significant prospect of doing so. Automating them was not a rational decision.
The question, then, is how to make a rational decision. When I take a job as a contract tester, I typically design a series of tests for some product feature. For each of them, I need to decide whether that particular test should be automated. This paper describes how I think about the tradeoffs. | | |
|
|
View Content Detail:
• When Should a Test Be Automated?.doc (140 Kb)
This paper was originally presented at STAREAST '99 — a conference produced by Software Quality Engineering. For more information on this conference, visit the current STAREAST Web site.
About the Author
Brian Marick has worked in testing since 1981. He concentrates on developer testing, the interface between developers and independent testers, the criteria for objective test evaluation, and helping teams and projects understand and manage the tradeoffs inherent in software assurance. Brian founded Testing Foundations: Consulting in Software Testing in 1992. He is the author of The Craft of Software Testing (1995), and is technical editor for STQE magazine. Contact Brian at marick@exampler.com.
Back to Top
|
