An often-quoted statistic is that 70% or greater of software development projects end in failure. While that could be disputed as an apocryphal statistic, the author suggests that many automated test development projects have an even higher failure rate. And why is that? Is it due to the available tools not being up to the task? Is it the lack of ability of the SDETS to work on the project? The author suggests that it is typically not for technical reasons, but is due to strategic errors in not understanding the return on investment needs of the business at the outset. This presentation discusses the benefits of ascertaining and measuring the business return on investment before any lines of code are written. It will also go over some of the tangible benefits when the return on investment is kept in mind vs. the siren songs and myths that eventually lead to disappointing results.

Takeaways from the talk:

• Determining what the business is really asking for when they fund an automated test project
• What are some of the main ROI items that should be considered when strategically designing an automated test project
• What are some of the tangible benefits when the ROI is considered in the strategic design of an automated test framework
• What are some of the siren song distractions (that the business may even ask for) that will result in poor ROI in the long run