There are many instances where it has been seen that organizations complain of not getting enough ROI from their automation initiatives. When they get to identify this, the blame game starts and people start pin pointing the test automation team for not creating the right strategy beforehand.
One of the major issue that I have seen is that many a times people are reluctant to admit that there needs to be a dedicated effort and plan in place for automation. They feel that if they outsource the work of framework development to any third party contractor / vendor and then ask the vendor to train the current manual/business team, the job will be easy. In case of optimization of efforts, they might be correct, but they fail to understand that this will put a lot of burden on the automation solution and it might not be best designed based on product needs.
Another issue that I have seen is that the current testing team (with manual mindset) is asked to upgrade the knowledge and start the automation work in their free times. This again puts a lot of risk on the whole initiative and at last it does not work for the long term.
We all definitely need to understand that the automation is not a part time activity that can be done by part time people. It is a niche skillset that is equivalent to development. As any product success depends on a good architecture and team, automation solution is also dependent on a good framework architecture and good team.
On a high level, the automation plan / initiative should consider the following from team perspective
- What do we want to achieve from automation?
- How will we achieve it? Do we need to hire from outside or do we have experts inhouse?
- If we hire the complete team from outside, what will people do once automation implementation is completed?
- Can we hire experts using subcontracting? What is the rampup and rampdown plan?
- How to handle the maintenance phase?