Some managers consider Testing Automation to be the gravy of the testing process –something nice to have– but not necessary. The reason is that most automation projects fail. They start with a lot of fan fair but fail to deliver on the promise of “pushing a button at the end of the workday, running all night, and the next day to find the results”.

We’ll take a retrospective look at projects that have failed and succeeded, to find practices, processes, and individuals who contribute to the success of an automation project.

Part of the problem is management and tool vendors, and the other is that we –as automation engineers– fail to fulfill the business goal on time. Companies cannot wait months for a Proof of Concept when they only have days. This presentation focuses on the 7 pillars of automation that have enabled me to deliver a solution to the business, not just a bunch of code.

These pillars are the results of my own experience of over 25 years, through failures and successes, across 10 companies and 8 industries. Pillars that are tool and language independent and have proven the test of time.

These pillars are:
Plan of Execution
Do you have a convincing plan for management?

Commitment from Management
Without management support, all automation projects will fail

Robust Business Automation Framework
Much is said about technical development frameworks, what about a business framework?

Data Architect
Data tests the application, do you have a point person that is responsible for good test case data.

Data Refresh Strategy
To test an application, you need to start from scratch. Do you have consistent data?

Quality of Test Cases
Are your test cases valuable to the business? Do they provide a good baseline of functionality?

Developers Develop, Testers Test
A good automation engineer creates code, not good Test Cases. A good tester creates Test Cases, not code.