An automation effort is like a project of its own, often under-valued but potentially having an organization wide impact if not played right. Just as a GPS takes into account many parameters in deciding the shortest path that saves time and money, you need to know what parameters should be considered well in advance to reach that automation goal of yours and not let the road define it for you. Without further ado, let me talk about some common mistakes organizations make while rushing an automation project. Some of the DONTs in this article are applicable for any kind of software considered for automation while others are strictly catered to testing e-commerce applications developed using Agile methodology.
1. Don’t Automate for the Sake of Automating:
This sounds very fundamental and yet simple enough to be forgotten. How often do we really take time to think about ROI before automating a feature? Your ROI calculation need not involve complicated formulas and factors to consider (unless you have time to do it and there’s value in it). Perform a rough analysis to define why you chose automation in the first place. Why is this feature a good candidate for automation? What are you automating versus not? How are you automating? What is the maintenance effort? What’s the return for the initial launch of the feature as well as the subsequent release cycles? What would it take to test everything manually in terms of time, cost and quality? Answers to these questions will give you an idea of what you are stepping into and what is the ultimate value. It’s important to understand the value before investing several hours worth of work.
2. Don’t Create New Technical Debt:
Plan development with automation- Automation for new feature development should not be considered as a separate activity, it has to be part of your development process. In order to accomplish that, include your automation estimates as part of your development and testing estimates, allowing automation to be part of your process rather than treating it as a separate stream. Your development and test design should be considered complete/done when automation is done. And yes, this would stretch your development time depending on the nature of your project but the payoff will be huge. Remember, if you don’t plan automation for your new features, you are creating new technical debt meaning a new set of manual test cases are added to your suite that have to be automated someday in the future. It will be a never ending cycle.
3. Don’t Put
Quantity Over Quality:
Yes, your boss would be happy if you tell him/her that your team exceeded the goal by generating 200 additional scripts-but what about the quality of these scripts and the maintenance? Never compromise quality for quantity. When you show metrics to upper management regarding your progress on automation, provide data that would reflect quality of the scripts along with quantity. This would paint a better picture of your work rather than simply saying that 200 scripts were automated.
“ Nature does not hurry, yet everything is accomplished.” ~ LaoTzu
4. Don’t Take a Developer and a Tester Approach to Automation:
If you have a team of developers and testers working on a new feature, then perhaps you may have observed automation being done in two separate streams. Developers tend to take their own approach and testers a different one. Testers don’t know what the developers have automated and vice versa; I have observed this even when they are co-located. This behavior is definitely bad for automation. The team has to take a unified approach to create automated tests especially when they are all working on the same project/feature. Developers and testers should come together taking a collaborative approach to discuss how automation needs to be done for that feature, what kind of tests should be written and who needs to do what. There should be a single automation design and plan for a feature and everyone in the team should be familiar with it regardless of whether they are involved or not. Agile teams will be most effective when everyone is made responsible for both quality and automation.
5. Don’t Automate Without Having a Design for Your Automation:
Automation is similar to programming in a way. Just like how you would develop requirements and design for a feature that you are delivering, your automation needs to have requirements and detailed design as well. If you get your design wrong, you may end up starting from scratch. Obviously your design would require upfront investment but in turn would save tons of development time.
6. Don’t Automate Without Knowing the Code Architecture and Design:
Gone are the days when testers were only expected to know the business requirements, functionality and the domain. A tester working on a feature should also have sound knowledge of the architecture and design of the code. Knowledge such as what components are involved; what logic exists in which layer; flow of information from one component to another; whether a single piece of code is utilized everywhere to display a specific module etc. is important. Without knowing the code design, any automation done will be throw away work; you might as well test the feature manually.
7. Don’t Take UI Automation Approach:
If you are working on a project that involves changes in UI and the layers below it, you start from the layers below. You should have more tests beneath the UI layer based on the logic at each level. It’s easy, convenient and tempting to write all your tests from the front end, keep in mind that these tests are most expensive from a maintenance perspective especially if they use live data Finally get support and buy in from your upper management who makes decisions about priority. Help them understand that automation requires upfront investment, meaning that the effort required to deliver the feature could increase with automation, but the payoff is worth the effort. You can do this by showcasing the cost benefit analysis for a couple of projects that are fully automated. Showing the cost savings and a positive impact on quality will not only buy their interest, it will also keep the entire team motivated.
About the Author
Manju Anandan