Playwright 13 min read

Tech Chat – Playwright for Beginners – Live from Sweden with Helen Galan

raptatinha

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

In this Tech Chat, I was joined by Helen. She’s a professional with extensive experience outside of Brazil. She graduated in Sweden and works in development and testing. She tells us about her experience with Playwright as a beginner with the tool. And this Tech Chat turned out really great because she shared some tips that might be useful for other beginners.

Helen, this is one of my favorite Tech Chats! Congratulations on your determination, and thank you for sharing your experience.

1. Tell us a little about yourself and the project you’re working on with Playwright.

Helen:
I was born in São Paulo and have been living in Nyköping, Sweden, for almost 6 years. I’ve been a QA for 4 years and recently became a Junior Developer. What I enjoy most is learning the system and writing test cases. What I like least is not being heard or being seen as “the one who points out” human errors.
The project is a ticketing website; the project itself is small, but our system is huge. We use C#, and right now there are 10 of us, though that number changes quite a bit. I’m not working with other QA testers at the moment, but there are plans to bring us closer together with the team in the United States. We release about one update every two weeks, though that can vary.


Renata: That’s
really cool, Helen! Congratulations on your journey! I can’t wait to visit you in Sweden :). It’s
interesting when you say, “What I like most is learning the system and describing the tests”—that really reminds me of the beginning of my career. Over time, I’ve realized that today I dedicate myself much more to learning testing techniques than to the system itself. Learning the system is essential, right?! Don’t get me wrong. It’s just that, in many situations, there isn’t time to learn the system as a whole, and you still have to deliver results. My perspective is that, more and more, the focus will be on “how to test” rather than “what to test.” I’m a big advocate for sharing responsibility for quality, which means that the entire team should be capable and accountable for performing tests; the role of the quality assurance specialist is more about guiding and teaching than actually executing the tests themselves. This is especially true because when we think about scalability, we need testing at different levels, and we’ll often use different technologies to achieve this. Therefore, we’ll need professionals with experience in different languages and frameworks. And this is where I see us acting more as guides, teaching how to apply these techniques across different frameworks.

As a reference, ISTQB certifications cover several of these techniques (in Brazil, the representative body is BSTQB). Another recommendation is the book *Agile Testing*, which combines the principles of agility with the fundamentals of testing.

2. When did you start working with Playwright, and what was the decision-making process behind choosing this framework?

Helen:
I’ve been using Playwright since around February 2023. We don’t have automation at the company, and I was looking for a framework to use for my college thesis. My internship mentor suggested it, and I’ve been using it ever since. Today, my project is still under development, and I know the team in the United States is using it in parallel as well.

Renata:
It’s really great and important to have mentors who support us along our journey. These days, there are so many tools, so many techniques, and so many solutions that it’s really hard to know everything—and having guidance makes things so much easier. An additional tip I usually give is that we shouldn’t get too attached to any one tool. Playwright does have many features that other frameworks don’t; but it has limitations, and it’s certainly not the best framework for every system. I always recommend conducting a POC (proof of concept) to evaluate one or two additional tools and decide which one is best for the team. Furthermore, it’s important to understand the problem you want to solve by automating tests and what infrastructure is available. Simply “implementing” tests doesn’t solve the problem. We also need to have a regular execution routine so that the tests can identify errors and, of course, an appropriate communication channel so that the team is notified (as soon as possible) in the event of failures.

For further reading, I recommend this article I wrote: “How to Choose an Automation Framework,” and Angie Jones’s free course—“Setting a Foundation for Successful Test Automation.” With these resources, any decision you make regarding framework selection will be well-informed and will help prevent future problems.

3. Regarding the pipeline, what is its structure?

Helen:
It’s not in production yet, and I don’t have much knowledge about pipelines. But the plan is to run it with every deployment and release.

Renata:
It’s very important to add tests to the pipeline from the very beginning. It’s better to have 5 tests running reliably than 10 implemented that no one uses. I recommend setting up the pipeline to run right from the first test. This provides visibility into the project and adds value for the team. Sometimes we spend a lot of time implementing new tests, but no one ever sees them. This also gives our department a “bad reputation.” The rest of the team will “learn” that this is the norm, and often this doesn’t help enhance the value of our quality department. Angie talks about this in her course. There are also references in several other sources that I’ve cited here. Returning once again to the idea that “quality is everyone’s responsibility,” in this case, you can reach out to the company’s DevOps team to help you with this. It’s important to emphasize that we need to clearly understand what we’re asking of this team and foster a healthy working relationship, since the interaction between quality and DevOps is one of the strongest bonds in a high-performance team. This is now so common that a new role called “TestOps” has been created, dedicated to the entire software development lifecycle through to delivery. In this role, the focus is on creating testing experiences that are faster for your team—such as unit, API, and UI testing frameworks—so that all team members can quickly add tests, and especially on managing and optimizing pipelines to provide greater stability in releases. We cannot leave out “Observability,” which involves monitoring and alerting in the event of failures, as well as defining recovery strategies should they occur.

As a reference, here are some free training courses:

Specifically for Playwright, I discuss continuous integration and observability with GitHub Actions and Slack in the Advanced Playwright course: https://testautomationu.applitools.com/playwright-advanced/chapter6.html 

4. Have you noticed any added value to the project since you started using Playwright?

Helen:
As I mentioned earlier, it’s not in production yet, but just by having to run the tests many more times to write the automation, I’ve already discovered other bugs.

Renata:
In addition to the points I mentioned in the previous question, another important factor to consider when evaluating the “value added to the project” is code maintainability, test stability, and test performance. It’s important, from the very beginning, to define a sensible architecture, use design patterns (Page Object Model, etc.), adopt a good code review process, and make use of static code analysis tools (ESLINT, SonarQube, etc.).

For further reading, I have an article on the Page Object Model and plan to add a few others, as well as a course on Test Architecture. One of the Playwright Ambassadors who shares the most content on this topic is Butch Mayhew.

5. Do you have experience with other frameworks? In what ways does Playwright generally stand out?

Helen:
I only used Specflow alongside Playwright while writing my final project, but I stopped using it after a while. It didn’t seem feasible for our company.

Renata:
I’ve never used Specflow, but I’m glad you already dropped it, lol. Playwright on its own is already quite robust, so I don’t think it’s necessary to use other frameworks alongside it. At least for UI and API testing. 🙂

6. Is there anything you think still isn’t quite right with Playwright?

Helen:
I wish there were more resources using C#, .NET with MSTest, and Visual Studio 2022. It makes things easier for beginners like me. 🙂

Renata:
Yes, I understand. The Playwright team prioritizes Node.js since most users come from that environment. I believe that, in this regard, one alternative is to engage more with the community. The Playwright Discord is very active, and the Playwright team participates actively there. I recommend using it frequently to expand your knowledge.

It’s also important to remember that when choosing a testing framework, you should evaluate which language it supports best. I have an article discussing how to choose a language for Playwright.

7. What’s your favorite feature of Playwright?

Helen:
Since I’m still very new to this, Codegen makes things a lot easier.

Renata:
Going back to the issue of code quality and maintainability, I personally don’t recommend Codegen for beginners. Any automated code generation tool simply can’t take into account the project’s context and these factors. And that leads to common errors that will have major impacts in the not-too-distant future (usually within 6 months to a year, you’ll start to see instability and performance issues, not to mention the difficulty of maintaining the code, which often snowballs into a situation where you end up having to add new tests for every scenario, since updating existing scenarios becomes nearly impossible). Codegen is unnecessary if you have a good understanding of how to use locators and how to handle the framework’s commands.
My favorite features of Playwright are: automatic retry, automatic parallelism, autowait on commands, built-in reporting, and the Trace Viewer!

For further reading, I recommend:

8. What IDE do you use to develop tests? And do you use the command line more, or the Playwright plugin in the IDE?

Helen:
I use Visual Studio 2022 exclusively.

Renata:
Cool! IDEs these days are also very robust and let us do almost everything through them. Other IDEs commonly used for Playwright are VSCode and Aqua. I also think it’s important to have a good understanding of how to run tests via the command line because if you switch languages or frameworks, it’s helpful to understand what’s happening behind the scenes, lol. In that case, you just have to read the framework’s documentation.

9. What do you think of Playwright’s Codegen?

Helen:
It’s a good tool, but sometimes it’s not very clear.

Renata:
Nothing to add here—I already shared my perspective in question 7 🙂

10. Have you ever used GitHub Copilot to implement tests? And have you used artificial intelligence to create any tests or functions (such as a page object model) in your project? Do you have any thoughts on these points?

Helen:
I don’t have anything on Git yet, but I started using POM after your tips and those from the automation engineer in the U.S. division. I haven’t formed an opinion yet because I still have a lot to learn.

Renata:
Git, GitHub, and GitHub Copilot are different things (and POM isn’t directly related to these topics, but it can be generated using AI).

Git is a distributed version control system. In other words, when you’re working on a team, it’s common to have a place where you “commit” the code you’re working on (called a repository), create branches, download code updates submitted by others, and so on. 

GitHub is a cloud-based platform that enables and facilitates the use of the version control system. In addition to GitHub, there are, for example, GitLab, BitBucket, etc. These platforms run on top of Git. Once you have a Git repository, you make the code available for use through these platforms. In short, GitHub allows you and others to interact with Git projects. Without GitHub, you would only be able to access everything via the command line and locally.

GitHub Copilot is an AI product from GitHub that helps you write code. As you type, GitHub Copilot will suggest a block of code using GenAI. In addition, it offers a chat feature where you can ask questions related to the code, and it will also flag errors and provide explanations on how to resolve them.

In addition to GitHub Copilot, many professionals have been using Prompt Engineering to migrate from one language to another (for example, in this article I used ChatGPT to convert Playwright code to Cypress since I don’t have any knowledge of Cypress). Another use is to describe test scenarios based on documentation or a URL. Another example is to create POMs by passing a URL.

My opinion here is similar to Codegen’s. I do not recommend the use of Artificial Intelligence for beginners. To use AI effectively, you need to know prompt techniques to achieve more accurate results. Still, it’s important to know what you’re looking for in order to evaluate the response, since it is, after all, ARTIFICIAL intelligence. At the same time, it’s a good idea to familiarize yourself with the tools available on the market, and especially the fundamentals of Artificial Intelligence, since it’s likely to greatly accelerate the development of tasks in the software field (and in other fields as well, right?!).

Bibliography: 

11. What would be your top tip for people thinking about using Playwright?

Helen:
Learn it and use it—I’m still very hopeful that I chose the best framework for my project. It’s fast, and it doesn’t seem that complicated once you get the hang of it.

Renata:
Not just for Playwright but for any other framework, remember that the framework itself doesn’t solve any problems. Along with the framework, there are all the testing techniques and software development quality standards that must be followed to achieve a successful outcome. Learning takes time. Don’t be too hard on yourself—start slowly. And understand that it will take about 5 years or even longer before you start grasping things with ease. It’s like that with everything in life: learning to walk, talk, drive, cook, speak another language, apply makeup, and everything else. Enjoy the journey, surround yourself with good people, and above all, be humble enough to admit when you don’t understand something. We’ve all needed help at some point—it’s normal! There’s even a free mentoring program with professionals from various fields and around the world: https://adplist.org/

Additional Resources:

tags:
#.net #playwright #tech-chat #test-automation #testing-framework
author

raptatinha

Related posts