How We Manage Test Automation in Our QA Team: Process, Reviews, and Best Practices

Test automation is not just about writing automated tests; it is also about establishing an efficient process that enables the team to collaborate effectively and deliver consistent results. In this blog post, I would like to share the test automation workflow we have established within our team at Therap.

Before diving into the details, I want to emphasize the importance of having a well-defined workflow. A strong workflow not only improves team efficiency and productivity but also has a direct impact on the quality of the final outcome. Additionally, a streamlined process enables new team members to onboard more quickly, adapt to the team’s practices, and contribute effectively from an early stage.

I designed the test automation framework currently used by our team. The framework is built using Java, Playwright, REST Assured, and Allure Report. This technology stack was selected based on my previous experience, along with discussions and feedback from two senior QA engineers on the team. As a result, I am primarily responsible for introducing framework enhancements, architectural improvements, and technical upgrades whenever necessary.

When we began our automation journey, the two senior QA engineers and I agreed that regression testing should be our primary focus. We first identified the features that would benefit most from automation and created a roadmap of regression test scenarios to cover. Afterward, automation tasks were distributed among team members through collaborative discussions.

Not every regression scenario can be fully automated. In such cases, we maintain clear documentation indicating which test cases are covered by automation and which still require manual testing. Our approach is incremental. If a feature or a portion of a feature cannot be automated immediately, we revisit it later and conduct additional research and experimentation to determine whether automation has become feasible.

Once a QA engineer is assigned an automation task, their first responsibility is to develop a high-level implementation plan and discuss it with either me or one of the senior QA engineers. During this discussion, we review the scope of automation coverage, identify any limitations, evaluate missed test scenarios, and discuss implementation strategies and design considerations. This collaborative planning stage helps ensure alignment before development begins.

After the implementation is completed, the engineer announces in our dedicated Google Workspace channel that the work is ready for review. At this stage, we conduct a test case review rather than a code review. A reviewer is assigned to evaluate the automated test coverage, validate the selected scenarios, and provide feedback on any missing or incorrect test cases. The assignee then addresses the feedback and updates the implementation accordingly.

Only after all test case review feedback has been resolved does the assignee notify the team that the pull request is ready for code review. We typically invite all team members involved in automation to participate in the review process. Since our automation team currently consists of six members, this approach remains manageable and encourages knowledge sharing across the team.

During code review, reviewers focus on code quality, framework standards, maintainability, and implementation best practices. Any feedback received is addressed by the assignee until all concerns are resolved. Once all reviewers approve the pull request, the changes are merged into the develop branch.

This workflow has helped us maintain high-quality automation code, encourage collaboration, and ensure that both test coverage and code quality are thoroughly reviewed before any changes become part of the framework.