Stop Over-Engineering and Stop Wasting Time
1 hour ≠ 10 hours. This is a simple fact, yet myself and many others have spent 10 hours or more automating a solution that could have been completed in just one hour. Sometimes this is a good thing as the code is better and more resilient, but other times we follow this drive to optimize when it's just overkill.
No this isn't inherently a problem as code written with time and purpose should be better, but what makes some automation better than others? When does efficient and scalable code go too far? I have asked myself all these questions over the past couple of years as I have worked very hard to restrain myself from over-engineering. I began by trying to learn what made automation great.
Maintainability and Resiliency
There is a big difference between good automation and great automation in my eyes. Automation should be readable, clean, concise, following best practice, and maintainable. As programmers we generally are already used to creating maintainable code, but automation should be hyper-considerate about maintainability. For the purpose of this post:
Maintainable Automation - Automation that is easy to update, understand and maintain during the lifetime of a project.
I call attention to this because I feel like good automation I've seen is already maintainable, but what makes automation great is being resilient.
Resilient Automation - Automation that requires little changes when unexpected changes impact the application.
The difference between the two is pretty simple at the end of the day. Maintainable automation is easy to change for all expected changes like adding new automation for a new UI element from the latest user story. Resilient automation should handle the unexpected changes such as a massive page rework that changes all selectors for UI elements. UI selectors for Selenium shouldn't have to be updated every time the page is changed by dev.
Automation shouldn't require massive rework and hours of updates with every deploy. If a large portion of your time is spent updating automation, there is likely room for improvement.
Where's the Line?
Automation should be great, but being a software consultant has taught me that time should be considered with every action you take. I, as a consultant, should never be wasting my client's time and it is morally wrong to knowingly waste it. I began my career thinking that it's very simple to not waste time, just work and don't watch cat videos!
In reality I started out wasting time fairly regularly while still being diligent and focused. The time waste would slip in whenever I began a new task, as I would begin trying to make the automation as efficient as possible. I would try to mix in every single trick I could to cut down on memory and reduce by Big O runtime. I would begin every task with the goal of efficient automation.
This wasted hours of time and provided little value, but how could faster automation provide little value? It's very simple, my basic workflow to open a mobile app, login and check the welcome message took over 40 seconds to run. The automation was already slow as we were tasked to use Appium on an outdated mac, and any standard optimizations would provide no value to my client. The tests would still take a very long time to run.
The line is really drawn when your time is better spent elsewhere, because when it comes to automation it's largely better to test more workflows and scenarios sooner with less optimized code as long as it's still just as resilient and maintainable.
The Balance
Eventually I realized my time was better spent on actually providing value to my project and the client. I stopped pre-optimizing and instead started populating data for all prerequisite screens in the database before a test would start. This cut down a test from 13 minutes to only 5. I started using the basic framework I created to test more scenarios for negative testing instead of making the acceptance criteria testing more optimized. My bugs created by automation skyrocketed when I changed my approach, and the UAT team really appreciated getting better builds as the automation was finally providing strong value outside of stock acceptance testing.
Your time is valuable so everything you automate should in some way have value. And the value provided should be worth the time investment, because without time as a factor every test and line of code should be perfect. Programming is a great iterative task, and creating automation is no different. Start with the basics and improve as you go. There are plenty of reasons to optimize for performance, but save that for when it's needed or every other task provides less value.
Simple tests and problems should always begin with simple answers. The time and effort is better spent on larger problems so keep the automation simple where it needs to be.
When Over-Engineering Goes to Far
I was brought into a new client to help this client's internal QA lead improve their existing automation. The existing project was a perfect example of over engineering. Someone at the client started this solution and wanted to make the automation highly efficient and to this day some of the most complex code I have ever seen.
This solution was near unreadable and was neither resilient or maintainable. Every deploy took multiple days to update the solution to basic changes but it ran very fast and to my knowledge was highly memory efficient. The problem quickly becomes that time and memory saved by the computer running the code or on the cloud is trivial compared to real hours spent by a human to maintain it.
The entire solution could have been a fairly straightforward solution but over engineering brought it to the point of wasting thousands of dollars. This is a real life example of 1 hour ≠ 10 hours.
Final Thoughts
Simple problems should require simple resilient and maintainable solutions. Optimization can always be done later, as pre-optimizing can waste more time than it saves. Every moment you put into creating automation has a cost, and in a professional position that cost is money, as every second spent has a monetary cost to it. Make sure you and your project are investing that cost into great automation.