What are the steps/action plan to introduce Test Automation in a company?

Question

My colleague and I have been given the task of Piloting Test Automation in our company.

We need help deciding on the Action Plan.

Some Actions we noted are as below :

• Design an Architecture of "Test Automation" that would include defining proper naming convention, maintaining source code, maintaining version history and control
• Selecting Stable Application for Test Automation. And also select the chunk of Test Cases based on priority for Automation.
• Creation of robust - scalable framework that includes a set of rules for writing the test scripts, so as to bring the requirement of maintenance to a minimum. Also, the scripts should be written in a way that they have the ability to cope with minor changes in the application without the need for re-writing them.
• Identify and assign tasks to Test Automation Engineers with predefined goals and milestones.

Are these points enough for us to go ahead and do the Test Automation in our company or are we missing out on any points ?

Answer 1

Agile Pilot:

• Automate a test in the simplest way possible
• Automate another test
• Repeat and evolve into a robust framework

Your plan sounds traditional and will probably result in a lot of research and over-engineering. Start simple and let your tests form around your application and business. Tackle uncertainties as soon as possible. Don't make your plan too big without enough information. Start getting experience and feedback as soon as possible

Answer 2

Hearing that your company is tasking you with creating a test automation suite/framework fills my heart with joy, congratulations!

Now, on to my thoughts...

Design an Architecture of "Test Automation" that would include defining proper naming convention , maintaining source code , maintaining version history and control

As to the design, make sure that it is implemented in the most basic way to start. Niels mentioned this above, and he is correct. You can add complexity and refactor later. Don't waste too much time on identifying naming conventions: if your dev team has them, follow those. If they don't, there are plenty of resources out there that can guide you.

Selecting Stable Application for Test Automation. And also select the chunk of Test Cases based on priority for Automation.

This is something that you will need the whole team to help you with. Your definition of 'stable' may vary from others. Also, make sure that everyone understands what the point and value of automation is: to support the manual testers. Also, I would suggest NOT picking which things you automate based on priority at first. Rather, I would make the first pass of test cases based on utility; does it solve an immediate problem.

Creation of robust - scalable framework that includes a set of rules for writing the test scripts, so as to bring the requirement of maintenance to a minimum. Also, the scripts should be written in a way that they have the ability to cope with minor changes in the application without the need for re-writing them.

I like where your head is at here, and I think there is some value to your line of thinking. Advice I could give you here is, "let the framework scale itself at first". What I mean by that is, automation should be a living/breathing thing. It should always be in motion whether that is adding new tests, sunsetting old ones or refactoring existing tests. Maintenance will always be there because even the best of teams sometimes forget to mention a change that could break a test or two (or more).

Identify and assign tasks to Test Automation Engineers with predefined goals and milestones.

This is 100% correct. Do not let your team view you as an island. Track your work with tickets and milestones.

Answer 3

Tool selection, protocols to support (web, Java etc) costs/budget.

Mark Smith.