The Role of Software Test Automation Engineers in Dev Teams vs. Centralized QA Teams

Software Test Automation Engineers (SDETs) play an important role in modern software development, as a bridge between development and testing. The organizational location of this role — whether it should be in a development (DEV) team or a centralized QA team — has always been a matter of great debate. As a test automation engineer, I have had the opportunity to work in both teams. Based on my experience in both development and centralized QA teams, I will try to give an optimal teaming approach for the test automation engineer role in this article.

Benefits of Working as an SDET in a DEV Team

Since test automation processes are no different from development processes, it doesn't make sense to consider them separately from development processes. Test automation is a purely technical task that requires a lot of technical knowledge and skills. Therefore, it requires the development team to support test automation processes and knowledge transfer at all times. In short, being an SDET development team member has many advantages that make both technical and collaborative processes faster and more effective.

Let us examine these advantages in a little more detail below.

Close Collaboration and Communication

• Direct Access to Developers: During my days as a development team member, I built strong relationships with developers and had direct and fast access to their support in test automation tasks, I overcame many tasks that I could not have overcome alone with the direct support of developers. For example, we created a test library that simulates all the dependencies of other systems necessary to test a system in isolation as mock systems together with developers and we still use it in our tests. I also received fast support in solving any issues or problems I encountered in test automation.
• Elimination of Bureaucracy: Bureaucracy is simply the enemy of the Agile approach. When I worked in the Dev team, requests for tool licenses or additional resources required for test automation were handled quickly because the team owned the problems and created solutions together. Thus, test automation processes were not subject to bureaucracy between teams.

Integration of Test Automation into Development Processes

• Test automation processes were naturally handled as part of the development team’s workflow and were constantly gaining priority. On the other hand, the dev team took responsibility for meeting the expectations from test automation, and the existing problems were solved with teamwork.
• By including test automation tasks during sprint planning, individual workload was reduced and shared responsibility was encouraged. Since I was part of the DEV team as a test automation engineer, I was often able to work with developers on test automation problems for hours at a time. This work was taken into account when planning the workflow and sharing work between developers. Thus, test automation processes became a team effort rather than being the sole responsibility of SDET.

I’m sure some people will have a question here. Doesn’t it make their already heavy workload even heavier for developers to deal with test automation problems?

This is certainly a pertinent question. It would be ideal if all the problems encountered in test automation processes were solved by SDET and the DEV team was not burdened with these problems.

But this is not possible. Because the problems encountered in test processes are often related to the infrastructure and the applications under test and the testability of these applications, regardless of SDET’s knowledge and expertise. In this case, it is inevitable to get help from developers. In any case, the approach that SDET should solve all problems alone is both unrealistic and has no place in methods such as Agile. On the other hand, as I tried to explain above, when Developers were dealing with test automation problems, they did not see this as an additional workload, on the contrary, these responsibilities were taken into account in the business planning process. Therefore, I can easily say that in cases where SDET is part of the DEV team, this work planning can be easier and more effective than in other cases.

Personal and Professional Development

• Training Opportunities: As I mentioned above, test automation is a technical job and cannot be separated from dev processes. It requires regular training and knowledge transfer. Working closely with developers allowed me to learn new programs and tools, and I had the opportunity to directly participate in knowledge-sharing processes within the DEV team. I also had the opportunity to participate in various trainings with the DEV team.
• Shared Goals: Annual goals often included collaborative objectives for both developers and test engineers, resulting in higher-quality test automation processes and tools.

What are the disadvantages of SDET working in the DEV team?

Decreased Quality Prioritization: In DEV teams, development processes are unquestionably always prioritized. This is not to say that Developers don’t care about quality or testing, but often testing processes take a back seat to the delivery schedules of the development team. This can be reflected in test automation processes, which is not desirable. Test automation should not be rushed, and care should be taken when creating reusable automated tests. Since this sometimes blocks DEV processes, test automation processes may be rushed and quality priority may not be given due importance. The most common problem I encountered when I was working in the DEV team was that only happy path tests were focused on test automation and negative tests and validation tests were usually put on the back burner. However, most bugs are found through negative tests because developers typically do not make mistakes on a happy path.

Lack of Standards, Tools, and Process Management: The biggest disadvantage of SDET being independent of a centralized QA team is the lack of standards across projects. Each team defining its testing processes is a barrier to consistency and achieving high-quality standards. Imagine there are multiple DEV teams and different SDETs are responsible for them. This often leads to differences in the test automation framework used, the writing of test cases, and even the strategy for running tests. This poses a great risk for knowledge transfer and standardization. At first glance, it may seem trivial for teams to use different methods for test automation if it works. However, having standards for controlling, improving, maintaining, transferring to new colleagues, and maintaining test automation processes is essential.

Advantages of Centralized QA Teams for SDET

The Centralized QA Team is usually an independent unit that manages Quality Assurance activities for all projects and development processes in a large organization, standardizes all QA processes, and controls testing practices.

As a Software Test automation engineer, I play a role in a Centralized QA team in the organization where I am currently working. I will try to explain the contributions of this process to me as follows.

Exposure to a Wide Range of Knowledge and Projects

The first thing that changed after I moved to the Centralized QA team in the company I work for was that I had information about almost all projects. With our daily meetings, I became aware of all the QA activities taking place within the company at a high level. At the same time, I had the opportunity to participate in test automation processes in more than one project. While in the DEV team, we were only aware of the projects we were responsible for, the QA team increased this level of knowledge a lot. This provided a more general view of all projects within the company from a QA perspective and allowed me to spread the advantages of test automation to a more general level.

Focused and In-Depth Testing Work

When working with the Dev team, my primary focus was on developing the test automation framework. Naturally, with the energy and collaboration of the Dev team, I concentrated more on development. I can say that this perspective changed when I started working with the centralized QA team. With the QA team, I began to work more test-oriented in test automation processes. This allowed me to expand the scope of automated tests. In addition to focusing on test automation, I had more opportunities to focus on test-related processes such as test cases, test plans, test concepts, regression testing, and acceptance testing. Consequently, I put effort into developing test automation in alignment with these processes.

Collaboration and Know-how Transfer

Regular know-how transfers within the centralized QA team contributed to gaining new knowledge and skills in addition to improving test automation. During this process, I had the opportunity to share my test automation knowledge with my teammates and collaborate on task distribution. At the same time, I learned new tools from my teammates, which allowed me to enhance my knowledge and skill set further.

Standardization of Test Automation processes

I believe it wouldn’t be wrong to say that there is conceptual confusion in the testing world. However, I find this entirely normal. Even for fundamental concepts like test cases and test scenarios, it is possible to see different definitions and implementations from one company to another. While ISTQB has undoubtedly done an excellent job of standardizing all testing concepts, this remains largely theoretical. In practice, different organizations still use varying definitions and implementations. As I mentioned earlier, it is entirely natural for each organization to define its testing processes according to its specific needs and challenges.

When I started working in the centralized QA team, I noticed that great importance was placed on these definitions. Questions such as “How should a test case be written?”, “What should we understand from a test plan?”, “What should a test concept look like?” and “How should test processes be planned when starting a new project?” were carefully addressed. This approach established a common language for QA processes not only within the team but across the entire company. Naturally, this also introduced a standardization to test automation processes. I find this standardization crucial for various aspects such as knowledge sharing, maintenance, development, and execution of test automation. Additionally, this standardization made it easier to control and review QA activities.

Challenges of Working as an SDET in a Centralized QA Team.

Working in a centralized QA team, as I mentioned above, has many advantages. However, it would not be realistic to say that there are no challenges for an SDET in such a setup. The QA team’s implementation I am part of closely resembles a hybrid approach. In other words, our QA team does not manage testing processes in complete isolation or independence from Dev teams but rather aims to strengthen collaboration between Dev and QA by actively participating in scrum teams.

Despite this collaborative approach, transitioning from a Dev team to a QA team introduced certain challenges related to test automation processes. I will try to explain these challenges below.

Reduced Collaboration with Development Teams

After transitioning to a centralized QA team, I noticed a visible decrease in collaboration with the development team regarding test automation. Test automation had now become the responsibility of the centralized QA team, and although the Dev team still considered test automation during planning processes, it was not as strong as it used to be. I was still attending all scrum meetings and working with the Dev team, but invisible yet strong boundaries had formed between the teams. Test automation was now considered the responsibility of a different team. I can say that I no longer felt the same level of support from the Dev team for test automation as I did before. Previously, I mentioned that we had developed a test library with the Dev team for isolated tests. After moving to the centralized QA team, I wouldn’t say that such collaborations with the Dev team are impossible, but I would argue that long-term collaborative efforts like these have become more challenging. Additionally, coordinating with the Dev team to meet technical requirements for test automation processes is not as seamless as it used to be.

Recently, I encountered a technical infrastructure challenge related to microservices testing processes. While this issue could have been resolved very quickly with the support of the Dev team in the past, now, due to the Dev team’s workload, they were unable to allocate time for this assistance. Understandably, this test automation problem was seen as an additional workload for the developers. This made it more difficult to establish the coordination and collaboration needed to solve the problem.

Bureaucratic Processes

As I mentioned earlier, bureaucracy is a major challenge in Agile methodologies, and all Agile practices aim to minimize it. After transitioning to the QA team, I began encountering many bureaucratic obstacles that I had not experienced while working with the Dev team. Previously, if I needed access to any application or tool for test automation, the team would handle it internally and quickly. Now, this process has become significantly longer compared to before.

I even encountered situations where small requirements got stuck at the boundaries between teams. Due to the teams’ workload, I had to wait through lengthy approval processes. Of course, this is a natural result of maintaining organizational functionality and structure. However, at times, this bureaucracy can be exhausting and reduce productivity.

When I was working in the Dev team, I had the opportunity to participate in many technical training and knowledge transfer sessions. After transitioning to a different team, benefiting from these opportunities became more challenging. The Dev team no longer considered the Test Automation Engineer as prominent in technical training or knowledge transfer sessions as they used to.

Of course, if you request to join, no one opposes your participation in these trainings. However, various approvals would be required. Additionally, I was not as easily informed about training sessions related to topics indirectly connected to test automation. This ultimately led to missed opportunities to benefit from several technical training sessions.

The Balance Between Standardization and Flexibility

The decrease in collaboration mentioned earlier is not solely due to the Dev team. Having an SDET in a centralized QA team instead of the Dev team, as I mentioned before, brings various standards along with it. This can sometimes create a strong sense of QA standard enforcement on the Dev team.

In my personal opinion, test automation should be fully integrated as part of the Dev process. Therefore, QA standards should not be so rigid as to hinder the integration of test automation processes with Dev workflows. For instance, in an Agile environment, developers’ workloads and priorities are constantly changing. Test automation should adapt to this variability and dynamism.

Being part of a QA team, however, can sometimes reduce this adaptability due to a tendency to strictly adhere to standards. In such cases, balance must be maintained. The QA team, like the Dev team, must also operate in an Agile manner.

Diverging Responsibilities

A centralized QA team is responsible for all quality control processes within the organization. Naturally, this entails task distribution within the team. In a centralized QA team, an SDET may encounter workloads beyond test automation, which can lead to a loss of focus on automation tasks. Test automation is a specialized role, and adding additional responsibilities can not only delay automation processes but also negatively impact their quality.

I often see many colleagues attempting to handle both test automation and manual testing simultaneously. In my personal opinion, this is not feasible. Test automation and manual testing require different sets of knowledge and expertise. Manual testers’ workload and workflows will likely leave no time for automation. On the other hand, an SDET focused on test automation will not be as effective as dedicated manual testers in handling manual testing processes.

In the centralized QA team I am part of, we treat manual testing processes and test automation as separate workloads and implement them in a way that supports each other. This approach results in everyone performing efficiently within their area of expertise.

On the other hand, as I mentioned earlier, being part of a centralized QA team inevitably brings new responsibilities. In my case, this was performance testing. Alongside test automation, I began to take part in performance testing processes. Since performance testing was a completely new area for me, the team provided sufficient time and resources for me to learn and apply it.

While acquiring and learning new skills is undoubtedly a benefit, the time I spent on performance testing somewhat shifted my focus away from test automation.

Key Considerations for Successful Implementation of the SDET Role

One of the most common implementations of the SDET role, and the one I am currently part of, is perhaps a hybrid approach. In this setup, there is a centralized QA team, and the SDET is a member of this team but works closely with developers and participates in Agile Scrum processes. While this approach has many advantages, as I have explained above, it also comes with certain challenges.

Here, I want to question why the SDET role must necessarily belong to a specific team. Why should an SDET, who is inherently a cross-functional team member, be tied to a single team? With this perspective, I aim to outline some key considerations for how the SDET role should be positioned, as detailed below.

Cross-Functional Mindset: The SDET role should not be confined to any single team but should work closely with both QA and Dev teams. This approach eliminates the constraints of team boundaries. Additionally, the SDET role ensures alignment with QA standards while effectively integrating test automation into the development lifecycle.

In this setup, the SDET should participate in all Agile Scrum ceremonies for both teams, acting as a part of both QA and Dev teams while serving as a bridge between the two.

Shared Goals: It is also important to prevent the limitations of team boundaries by ensuring that the SDET role is not confined to any single team but instead becomes part of the shared objectives of both the Dev and QA teams. This allows the SDET to align with developers on common goals, fostering continued collaboration. At the same time, the QA objectives assigned to the SDET encourage maintaining test automation within QA standards.

Shift-Left Testing and Dynamic Role Adaptation: It is crucial for test automation to be considered from the earliest stages of the development lifecycle and to be integrated into all steps of design and implementation. Therefore, any barriers preventing the SDET role from collaborating with the Dev team during the design and planning phases must be eliminated. Additionally, the SDET role should adapt to Agile workflows, balancing a workload that addresses the immediate needs of the Dev team and the long-term requirements of the QA team.

Training and Knowledge Sharing: The SDET role should be encouraged to participate in all training sessions and knowledge-sharing activities organized by both the Dev and QA teams. This will enhance their technical knowledge and skills while providing insights into projects from a QA perspective. Both teams should consider the SDET a natural team member during these training and knowledge-sharing sessions.

Transparent Communication: While the SDET role’s close collaboration with both teams contributes to transparent communication, it may not be sufficient on its own. The SDET should share feedback related to test automation with both teams. They must be responsible for providing clear and transparent updates on test automation processes and their current status to both the Dev and QA teams.

Compact Decision Flowchart for SDET

Certainly, the positioning of the SDET role may vary significantly across organizations. Below, I will attempt to consolidate all the scenarios mentioned earlier into a structured algorithm.

Step 1: Analyze the Organization and Project

In the first step, the size and needs of the organization and project must be analyzed. In larger organizations, teams and roles tend to become more specialized, which will undoubtedly influence the positioning of the SDET role.

Step 2: Determine the Development Lifecycle Methodology

The second step focuses on the methodology used for the development lifecycle. Is Agile being used, or is it another methodology? This also plays a critical role in determining the SDET’s position.

Step 3: Assess Cross-Functional Team Utilization

In the third step, it should be evaluated whether a cross-functional team approach will be adopted in the project. If this is possible, in my opinion, the SDET should take on a cross-functional role.

Step 4: Determine Shift-Left Testing Priorities (If No Cross-Functional Team)

If a cross-functional team is not possible, another question arises: Is Shift-Left testing prioritized?

• If the answer is yes, the SDET role will benefit most from being positioned within the DEV team.
• If the answer is no, the algorithm continues with another question.

Step 5: Evaluate Quality Assurance Focus

Are tests focused on broader quality assurance goals?

• If the answer is yes, the best placement for the SDET is within the QA team.
• If the answer is no, the algorithm proceeds to assess the engineer’s capacity.

Step 6: Assess Dual-Role Capacity

Can the Test Automation Engineer handle a dual role?

• If yes, a Hybrid Approach would be suitable, with the SDET contributing to both DEV and QA teams.
• If no, the QA team is the most appropriate placement.

Conclusion

In this article, I aimed to explain, based on my own experiences, the advantages and disadvantages of the Test Automation Engineer role depending on its positioning, and how it should be integrated into Dev and QA teams for more effective collaboration. I tried to summarize this algorithmically and share what I believe to be the best practice for positioning the SDET role.

The role of test automation and the SDET has undergone significant transformation since its inception. Its responsibilities and impact on QA and Dev teams have continually evolved. Undoubtedly, this evolution will continue, bringing us back to the question of how to position the SDET role most effectively to maximize its benefits soon.