Verify/ATI Conference Site

Linda Hayes, Worksoft, Inc.

Although almost every company professes to want test automation, not all are willing to invest what it takes to get it done. But don’t give up, get creative! Learn about real life examples of automation entrepreneurs who found unexpected sources of funding that led to expanded opportunities across – and outside - the enterprise.

This session will present four scenarios for expanding your horizons by capitalizing on the value of your automation skills. Attendees will learn how to: 1) Leverage existing automation to get more budget, 2) Identify new automation opportunities outside of IT, 3) Convert an automation project into a product, 4) Turn a job into a company

Burt LeJune, Innovative Defense Technologies

Description forthcoming.

Dorothy Graham, Software Consultant

There is a view that testers should be technical (i.e. have programming skills), especially if they are involved in test automation.

Although this can work well, particularly in an agile team, not all testers need or want to be technical, especially those with a business or application background – it is my belief that this should not preclude them from using test automation!

A tester who is also a software developer is, of course, a very useful person to have on the team. They are able to work with test automation scripts and understand both the testing aspects and the technical aspects of the automation code. But just because this has benefits in some cases, does not mean that this is the best in all cases.

The programming skills needed to work directly with a test automation tool do not need to reside in someone who is also a tester. The testing skills needed to produce good quality tests, those that will find bugs, give confidence and reduce risk, do not need to reside in someone who is also a developer. These are separate skills sets, separate roles.

Skilled testers should not be forced to abandon their vocation, to the detriment of their organizations, because tests are being automated. This presentation addresses how and why technically skilled test automators can and should support and enable non-technical testers to write and run automated tests.

Peter Varhol, Seapine Software

When do you ship an application under development? The question seems simple; you ship it when it's complete, right? But that begs the question "what does it mean to be complete." There are many possible definitions of complete and it is critical that teams and users agree on a definition before any work is done. This presentation will provide measurable criteria for determining when an application is ready to ship. It will discuss how to create objective measures of completeness and how to collect data and track progress toward that end. Peter Varhol will explain how testers and quality professionals may work with application stakeholders to contribute to both the definition and automated measurement that determines if an application is fit for its intended purpose.

Gurinder Negi, Statefarm Insurance Companies

Are you faced with inefficient test automation processes that leave your organization struggling to find consistent answers to questions such as, “where are the test scripts from a previous release?”, “what and how much should be automated?”, and “what concrete benefits have we received from all of our efforts?” A process framework for test automation enables different areas within your IT department to think in a consistent manner about automation. It can make execution of automation easy and collection of metrics for reporting even easier. Such a framework will allow for better testware management while also improving maintenance and execution of scripts. Some of the processes to be highlighted in this presentation include an automation backlog process for documenting and prioritizing automation tasks, an ROI estimation process for estimating/relaying automation ROI, an early engagement process for getting automation involved earlier in the system lifecycle, and an automation inventory management process for source control and configuration management of automation artifacts.