Why Would Anyone Want To Implement Automated Testing?

Moreover, why does anyone even want to test their software at all? They just want it to work. But most know better, and so they test. But does management care if testing is manual or automated? Should testers care if their testing is manual or automated? My guess is that management cares about automated testing if they think testing is going to cost less and provide faster results. Tester's will consider automated testing if it increases coverage while making them more efficient.

The reason I'm writing about this subject is because of articles posted on Bj Rollison's blog about calculating ROI for automated testing. In Rollison's first article on the subject, Measuring Test Automation ROI, he says this about ROI:

I have 2 essential problems with ROI calculations within the context of test automation. First, if the business manager doesn’t understand the value of automation within a complex software project (especially one which will have multiple iterations) they should read a book on managing software development projects. I really think most managers understand that test automation would benefit their business (in most cases). I suspect many managers have experienced less than successful automation projects but don’t understand how to establish a more successful automation effort. I also suspect really bright business managers are not overly impressed with magic beans.

Harsh comments but probably a realistic view of things. But it makes things difficult for anyone wanting to bring automated testing into their QA processes, given that there's a need to explain benefits versus cost. The follow-on Part 2, further condemns ROI calculations to being a silly waste of time. What Rollison does offer is why he automates tests, as well as points to a set of questions useful in deciding when to automate. Rollison identifies 4 reasons he chooses to automate tests:

1. Free up my time,
2. Re-verify baseline assessments (BVT/BAT, regression, acceptance test suites)
3. Increase test coverage (via increased breadth of data or state variability),
4. Accomplish tasks that can’t easily be achieved via manual testing approaches.

In addition to his list, he praises Brian Marick's paper on When Should a Test Be Automated. Rollison lists Marick's 3 key questions one should ask before automating:

1. Automating this test and running it once will cost more than simply running it manually once. How much more?
2. An automated test has a finite lifetime, during which it must recoup that additional cost. Is this test likely to die sooner or later? What events are likely to end it?
3. During its lifetime, how likely is this test to find additional bugs (beyond whatever bugs it found the first time it ran)? How does this uncertain benefit balance against the cost of automation?

I think these questions and the process by which one answers them, is an effective way to inform one's decision as to automate or not. Neither Rollison or Marick offer answers, nor should they. As Rollison puts it: "Unfortunately, there is no single cookie-cutter approach in deciding what tests to automate. Different projects have different requirements and expectations, and, of course, not all tests are equal."

What I take away from these questions is a process for making logical decisions about automated tests with the ability to explain why the automation effort will benefit the organization's testing goals - if it improves testing it should be worth the investment, so long as that improvement fits within your goals.