Mano de un robot sobre una pantalla digital, en el centro se muestra una etiqueta con el texto en inglés: Building Better Automation Frameworks

Over the past 15 years, I’ve had the opportunity to work on test automation frameworks in many different contexts: creating them from scratch, maintaining existing ones, and adapting solutions for diverse industries. My experience spans a variety of tools, from low-level implementations in C++ for desktop applications to modern frameworks like Playwright and Cypress.

I’ve also had the privilege of working with teams across multiple countries and cultures, from Latin America to Europe and North America. Each project brought unique challenges and lessons, especially in building frameworks that are both effective and maintainable over time.

In this post, I want to focus on two big problems I’ve noticed and share tips to avoid them.

Common Problems in Developing Automation Frameworks

1. Frameworks Too Complex

One common problem I have seen is frameworks that are too complex, often created by developers with strong technical skills but limited experience in test automation. These frameworks may look impressive but are usually very hard to update when the app under test changes.

  • The first time I faced this problem was with an automation framework that had a highly complex structure based on graphical UI components. Adding a new component required changes across multiple classes, and debugging an issue could take days. For instance, to handle a new type of dropdown menu, I had to modify several layers of the framework, making the process slow and prone to errors.

Solution: By simplifying the architecture and focusing on the standard test automation framework layers, we were able to reduce the number of dependencies between components. Following automation design patterns is a key to make changes faster and easier.

  • Another challenge is automating too many E2E tests. We had over 12,000 automated tests, and when 5% failed in CI/CD, the team had to investigate more than 600 failures. This slowed down feedback and delayed releases.

Solution: Prioritize which tests should be automated at the E2E level. Keep only the most critical scenarios and remove outdated or redundant tests.

2. Frameworks Too Simple

On the opposite side, some frameworks are too simple, often created under tight deadlines or by QA engineers with limited programming experience. While these frameworks work initially, they become difficult to scale as the number of tests grows.

  • The main characteristic of this type of framework is that the automation framework is essentially composed of test code only, lacking a well-designed architecture to enable efficient test implementation. This issue usually leads to duplicated code and flaky tests. In my experience, another problem with this type of framework was running tests in parallel, as it often led to random test failures caused by inadequate handling of shared resources and test data.

Solution: Applying key programming principles such as SOLID helped us structure the framework and enhance its reliability. By incorporating design patterns like Singleton and implementing a dedicated module for managing test data, we successfully enabled parallel test execution without conflicts.

It’s important to note that creating a good framework is challenging for anyone. Even experienced developers can struggle to balance technical complexity with practical usability for test automation particularly at the e2e level. The key is to learn, share knowledge, and adapt the framework to the project’s specific needs.

How to Build Successful Frameworks

Here are five recommendations based on my experience:

  1. Follow Best Practices and Standards: Use design patterns like Page Objects or Screenplay. If you’re new to automation, dedicate at least two weeks to learning best practices and standards for your chosen tool.
  2. Write Clean Code: Apply programming principles such as SOLID and consider reading Clean Code by Robert C. Martin.
  3. Keep It Simple: Avoid over-engineering. A simpler framework is easier to maintain and scale.
  4. Refactor Regularly: Improving your framework over time is essential. Refactoring by Martin Fowler is an excellent resource for this.
  5. Focus on Priorities: Prioritize addressing flaky tests and major issues before focusing on optimizing minor details, such as improving method performance. Although this may seem obvious, it is a surprisingly frequent mistake.

Final Thoughts Building an automation framework that adds real value takes time and collaboration. It’s not about avoiding mistakes but learning from them to create a solution that supports the team and evolves with the project.

What has been your experience with automation frameworks? Let’s share insights and grow together!