Many companies I’ve worked for or interviewed with have faced a common challenge: successfully initiating a test automation project. During interviews, it’s common for interviewers to mention that they’ve attempted test automation in the past, but it didn’t yield the desired results. They often ask how you would approach starting a test automation project differently to ensure its success. In this blog post, I’ll share my insights and the approach I would take to effectively tackle this challenge.

Why it didn’t work.

Before we dive in, let’s take a look at some of the common issues I’ve encountered:

  • Test automation is often initiated by developers who may lack specialized expertise in this area. Due to time constraints, they tend to follow only basic guidelines, which can result in code duplication and a maintenance nightmare down the line.
  • Test automation is sometimes started by QA teams with limited programming skills and automation experience. This often happens in companies where manual testers are suddenly tasked with writing automation, leading to suboptimal results and challenges in maintaining the automation suite.
  • The test automation framework lacked proper planning and was built by a single individual within the organization. This often leads to unnecessary complexity and over-engineering. Such projects are typically difficult to scale, as they become heavily reliant on a single person or a small group of 2-3 SDETs, making them vulnerable and hard to maintain in the long term.
  • Test automation was built on top of a fragile environment with numerous dependencies on third-party services. For instance, consider an e-commerce application that relies heavily on external payment services. This setup can lead to unreliable test results, making the automation process more cumbersome and less effective.

What we can do differently

Gathering Insights:

  • The organization seeks a more reliable and efficient test automation framework.
  • Previous attempts at building frameworks may not have achieved desired outcomes.
  • Start by conversing with key stakeholders to understand what has worked and what hasn’t.
  • Use these insights to guide a more effective approach.

Let’s assume that a test automation framework was already in place before you joined, but the organization now seeks something more reliable and efficient. Often, these organizations have attempted to build frameworks in the past but didn’t achieve the desired outcomes. A good starting point in this scenario is to have conversations with key stakeholders to gather data on what has worked and what hasn’t in previous efforts. This insight will help guide a more effective approach moving forward.

Understanding the Product:

  • Gain a thorough understanding of the product and its infrastructure.
  • Ensure you have a grasp of the application architecture and potential roadblocks.
  • Avoid rushing into building the framework without considering key constraints.
  • Addressing constraints early prevents costly refactoring later.

Once you have those insights, it’s crucial to gain a thorough understanding of the product and its underlying infrastructure. Having a general grasp of the application architecture and potential roadblocks is essential. In my past experience, I’ve sometimes rushed to build a testing framework, only to discover later that my implementation didn’t account for key constraints. This often leads to costly and potentially infeasible refactoring efforts down the line.

Designing the Framework:

  • Outline constraints and define the path forward for the framework.
  • Include considerations for data setup, cleanup, infrastructure, CI/CD pipelines, reporting, and design patterns.
  • A well-thought-out design ensures robustness, scalability, and alignment with project needs.

The next step is to design your test automation framework. This involves outlining all the constraints and defining the path forward, including data setup and cleanup, the application under test infrastructure, CI/CD pipelines, reporting, feedback cycle expectations, and common design patterns and architecture. A well-thought-out design will ensure that the framework is robust, scalable, and aligned with the project’s needs

Requesting Feedback:

  • Run the framework design through rounds of RFC (Request for Feedback and Comments).
  • Start by gathering feedback from the QA/SDETs team and refine the design accordingly.
  • Present the revised design to a larger audience, including the Engineering group.
  • Iterative feedback ensures the framework meets the needs of all stakeholders.

Once you have the system design in place, it’s crucial to run it through rounds of RFC (Request for Feedback and Comments). I recommend doing this in cycles: first, gather feedback from the QA/SDETs team to refine the design. After addressing their feedback, present the revised design to a larger audience, including the Engineering group, which may consist of Software Engineers, DevOps, and Engineering Managers. This iterative process ensures that the framework is robust and meets the needs of all stakeholders.

Involving Users:

  • Understand who will use the framework and involve software engineers early.
  • Early involvement helps make the framework user-friendly and integrates well with existing workflows.
  • Collaboration often leads to a more successful and widely adopted framework.

Additionally, make sure to understand who will be using the framework. Ideally, you want to shift everything left by involving software engineers early in the process. Their involvement can help ensure that the framework is user-friendly, integrates well with existing workflows, and addresses their needs effectively. This collaborative approach often leads to a more successful and widely adopted framework.

It’s true that resistance from engineering teams is common, as they often feel overwhelmed with their existing responsibilities. Adding test automation to their workload can make it seem like an additional, equally important task among many. Test automation can be perceived as an unnecessary burden that introduces complexity. However, it’s important to address concerns constructively and ensure that the team provides actionable feedback. As highlighted in The DevOps Handbook, if there’s only one idea on the table, it’s the best idea that you have and it worth giving it a try, even if it’s met with some initial resistance.

Handling Resistance:

  • Recognize that engineering teams may resist additional tasks due to existing responsibilities.
  • Test automation can be perceived as an unnecessary burden and added complexity.
  • Address concerns constructively and seek actionable feedback.
  • Emphasize transparency, simplicity, and trust in the framework.
  • Regular polls with engineering groups can align expectations and address concerns.
  • Embrace feedback as a gift and look forward to receiving it.

Overcoming resistance involves being transparent, simplifying processes, and building trust in the framework. Regular polls with engineering groups can help align with their expectations and address any concerns. As one of your previous employers wisely said, “Feedback is a gift”, so always look forward for getting occasional gifts in a form of feedback.