This year we’re actively working to create a curriculum focused on automation that is created with feedback from the testing community. We’ve already run a series of activities that have helped us identify a list of key tasks that someone working in the automation space have to carry out. The first task is:
Create an automation strategy
Myself and Richard have taken this task and then listed the different steps you have to take to successfully create an automation strategy. Which are listed below:
Learn about testability of a given context
Model context based on what is learnt
Identify and set automation goals
Communicate the strategy and ask for feedback
Update strategy based on feedback
Seek sign off / buy in into strategy
What we would like to know is what do you think of these steps? Have we missed anything? Is there anything in this list that doesn’t make sense?
What are your thoughts on these steps? How do you go about creating an automation strategy?
Where are we in the products lifecycle is often my first question.
for example if its a new product you are building from scratch I generally go with full on developer automation coverage, at this stage I do not think I’ve been ever convinced tester automation is a better choice, ever. This changes massively who is involved in the discussions and who takes lead.
Then again if the product is already up and running and the team did not adopt early automation and you now have regression risk as a big red flag, tester automation with ideally a hand over consideration back to developers is often a good choice.
Perhaps this is covered by the context discussions but sometimes you do not have the right people involved in those discussions so your hands are tied and you cobble together a solution with the lack of right people constraint. What are your constraints is a good early question, are we solving the right problem, number 3 might be too late.