Managing an automation project is overlooked at times, I feel perhaps, owing to the technicality of it, undermining some essential fundamentals is a mistake all to common.\u00a0@Katrina<\/a>\u00a0shared a beautiful presentation titled\u00a0Automation and Management<\/em><\/a>\u00a0<\/em>at the\u00a0#AutomationGuild<\/a>\u00a0conference 2017. There was a whole lot content, along with my reflection on the topic for one post. Follow up posts will cover the complete session. In this post, summarizing my leanings from her talk and my thoughts around deciding what to automate.<\/p>\n Drifting along without a concrete decision making criteria on what to automate will not render optimal utilization of automation efforts. Automating everything is not a good idea either, so how to \u201cDeciding what to automate\u201d that will fit the bill?<\/p>\n How is the product being pitched in the market \/ the competitive advantage? What features are important to customers and the business, giving an idea of what\u2019s important in the overall strategy.<\/p>\n Is the product in its growth stage? If so lots of changes are in store, for products in the maturity phase of the product\u2019s life cycle, drastic changes might not be expected. What areas are planned for changing and what does the release plan look like.<\/p>\n The best phrase I learned here was \u201cTesting is reputation assurance, to protect corporate image\u201d. Automation can provide a big boost to build that credibility. To do that, find out what application features can be marked as high risk<\/em>. She recommended a great article by\u00a0@James Back<\/a>\u00a0on the topic\u00a0Heuristic Risk-Based Testing<\/a>\u00a0to identify risk areas and make them a priority in automation.<\/p>\n The usual goals are increase test coverage and reduce time to market. However each product \/ company has their own unique challenges as well. Take them into consideration as well.<\/p>\n Few places where I kicked off automation, they had no formal test scenarios. Having formal test scenarios would have a great benefit to them, which we added as a goal in our automation effort.<\/p>\n Further goals should be quantifiable. The analogy given was ‘you should be able to add it to a check list and check it off once done’. Everyone mentions SMART goals, but creating one is not easy, not impossible either.<\/p>\n One of the best practices in automation has always been to make code reusable. Take that to higher layer of abstraction, at the requirements layer. Serenity, a tool which helps with that, I heard for the first time at the conference can help. Behavior Driven Development also allows repetition to some extend, however is not designed for that purpose.<\/p>\n Could be done without a tool or framework also, as done in one of the automation projects I worked on. Functional points were automated as independent units, making them reusable to construct larger scenarios. The thought process has to be there, you can then mold any tool \/ framework in use to achieve that.<\/p>\nUnderstand your product\u2019s strategy<\/h3>\n
Risk<\/h3>\n
Goals of your automation<\/h3>\n
Repetition<\/h3>\n
Time<\/h3>\n