Simplify browser testing with k6

[ankur22]

trafficstars

Customer problem

Many of the users who use k6 browser, especially in the cloud, primary concern is not necessarily the underlying API.

Browser testing presents inherent difficulties irrespective of the tool employed. Similar issues, such as challenges with selectors—where documentation is often inadequate, either overly technical or insufficiently detailed—arise when using Playwright and the k6 browser module. Developing reliable scripts necessitates:

• An understanding of the website architecture (DOM).
• An understanding of how browsers work.
• Skills in writing/groking scripts.

While tools like Playwright’s codegen (within their VSCode plugin) can aid in script creation, script comprehension and modification remain necessary due to website dynamism. Consequently, all users encounter difficulties in producing reliable and deterministic scripts, regardless of the tools used.

Another demographic includes users who have already integrated Playwright into their workflows, and their needs must also be considered. They want to be able to easily migrate across their Playwright scripts to k6. Today this is quite a challenge, and requires a deep understanding of the Playwright APIs.

Why does it matter?

Users often lack the specialized expertise required to comprehend the intricate complexities of websites, browsers, and scripting. Consequently, the API must be simplified to accommodate this user demographic.

Furthermore, it is imperative to achieve closer parity with the most commonly utilized Playwright APIs. This will facilitate a smoother migration path from Playwright to k6 and enable users to leverage existing tools and processes developed for Playwright.

What are we building?

We want to provide the flexibility and familiarity to the more advanced users that are already using k6 by providing more Playwright APIs, but at the same time we want to move towards working with simpler APIs which require less expertise in websites, browsers, and scripting.

What’s the desired outcome?

The desired outcome is to provide a simple, high-level API that does not require extensive knowledge of website architecture (DOM), browser component abstraction (like browser context), or complex scripting skills. Additionally, the goal is to simplify migration from Playwright to k6, enabling customers to use existing Playwright developer tools (and those developed by k6), such as debuggers, for creating and maintaining k6 scripts. This should satisfy the requirements for a large user base such as advanced users, experienced DevOps teams and the less experienced users (both in frontend/Javascript, as well as scripting/programming in general).

Next steps

• [ ] Data points to help us understand how k6 is used to help support our assumptions, especially around Playwright parity.
• [ ] A wording better than "roughly compatible with Playwright" that closely matches our desired state/goal.
• [ ] https://github.com/grafana/k6/issues/4248
• [ ] https://github.com/grafana/k6/issues/4502
• [ ] Analyse Playwright scripts to identify commonly used APIs that we should consider to implement in k6. This data should be visualised in an issue or graph form to allow for an easier migration to k6.
• [ ] Exploration into LLMs to see if we can add more context to help make migrating a Playwright script to k6.
• [ ] Exploring other tools to see how they have simplified their APIs -- e.g. Testing Library (comment).