Tech Chat – Migrating to Playwright from Selenium – with Bruna and Albino

This page was machine-translated from Portuguese and may contain mistakes. Read the original

In this Tech Chat, I was joined by Bruna and Albino. They also spoke at TDC Innovation 2023 and tell us a little more about the process of migrating from Selenium to Playwright.

Bruna started in the IT field as a junior apprentice in 2007 and, along the way, worked in various areas before joining the Quality department around 2018 (about 5 years ago), where she continues to work today. She’s curious and loves exploring new things.

Albino has been working in software quality since 2008 (15 years ago) and currently serves as a quality analyst at Central Ailos in Blumenau, Santa Catarina. He holds a bachelor’s degree in Information Systems from FURB. His focus and work have always been centered on automation; he considers himself passionate about test automation, especially after discovering the Playwright S2 tool.

Thank you, Bruna and Albino! It’s great to have you here on Tech Chat!

1. What was your old framework, and what was the main problem you had with it?

Old framework: Selenium
Main problem: Since Selenium doesn’t have automatic wait handling, and given the instability of our environment, this required a lot of code maintenance to address this issue.

2. How did the idea to migrate to another framework come about?

The need arose when the amount of maintenance increased significantly and also due to the security restrictions we have at the company, which even made it difficult to configure Selenium automation in the Azure DevOps pipeline.

3. How did the decision-making process for Playwright unfold?

First, we conducted a search for web automation tools, and based on the results, we analyzed the pros and cons of each tool to identify the one that best fit our context—both in terms of our environment and the challenges we were facing. After our research, we conducted a proof of concept (POC) using both Cypress and Playwright; we ultimately chose Playwright because of its ease of use and the configuration options it offers (with Cypress, we encountered issues with our company’s internal security protocols, and the language was also outside the context of our work).

4. Playwright supports multiple languages. Which language do you use, and what led you to choose it?

We use .NET because the teams use this language and the ecosystem we operate in is Microsoft’s.

5. How did you structure the migration (how long it would take, who would participate in the project, and what test prioritization technique was used)?

After conducting studies and automating an external website to verify how the tool’s configuration and parameterization worked, we created a one-month schedule.
Initially, the project involved three people during the migration of critical test scenarios, and the rest of the team was involved in the migration of all scenarios.
The steps carried out during the migration were:

  • Migration of critical test scenarios (1 week);
  • Deployment of the Azure DevOps pipeline with the critical test scenarios (and for one week, the tests ran on the pipeline so we could analyze performance and stability);
  • Migration of all other existing scenarios (2 weeks)

6. When you began the migration, how long did it take to see significant results?

We noticed significant results during the initial migrations of critical test scenarios, but we were certain of concrete results once we deployed the pipeline and test execution stabilized.

7. What was the most valuable outcome of adopting Playwright?

The tool’s performance (faster than the others we tested in POCs or had deployed) and the stability of the test runs.

8. What feature do you like most about Playwright?

Definitely Auto-waiting.

9. What’s still not quite right with the testing project after the migration?

Playwright’s limitations regarding .NET, since most Playwright implementations are released for Node.js.

10. Is there anything you would do differently?

If it weren’t for the security restrictions and the fact that it isn’t our default language, we probably would have implemented the automation using another programming language (JavaScript or TypeScript) to take full advantage of the tool’s features.

Additional References: