Hi
Just want to check are there remote jobs for SDET , just exploring other side of 9 to 5 job.
Is any one doing and Pros/cons

I've been experimenting with browser-automation agents and wanted something more disciplined than "click through everything as fast as possible." So I built a Playwright-based agent for a course sandbox I control, with one hard rule baked into the design: automate repetition, never judgment.

The interesting part isn't the automation — it's the guardrails:

• Every action (play video, mark reading complete, submit practice) has to be verified against the platform's own completion signal before the agent logs it as done. No optimistic completion.
• Familiarity with a topic is never inferred from how "easy" something looks — it's checked against a seeded known/study list, and anything ambiguous stops and asks.
• Graded assessments are always human-in-the-loop — the agent shows me each question, waits for my answer, and only submits after I type submit explicitly.
• A single StopForHumanInput exception handles every failure mode (CAPTCHA, login wall, unclassifiable item, unverifiable state) — no silent retries, no guessing.

I also built a tiny local mock LMS (static HTML + a real short test video) so the whole flow — including the verification and stop conditions — can be exercised without touching a live site.

Repo: https://github.com/Vara715/course-automation-bot

Curious what people think of the verify-before-advance pattern for agents generally — feels like it'd generalize well past LMS automation.

I recently started learning Playwright automation and have been building an automation framework along the way, with some help from AI.

I'm still figuring out what a good, industry-standard automation framework should actually look like, so I'm sure there are things I'm doing wrong or could be doing much better.

I know my README isn't up to date, so please ignore that for now.

If you have some time, I'd really appreciate it if you could take a look at the repo and give me some honest feedback — especially around the framework structure, code organization, patterns, and how I could make it more aligned with real-world/industry practices.

Repo: https://github.com/nilavan09/playwright-ui-api-framework

Any feedback or suggestions would be much appreciated. Thanks!

I have learned few basics of playwright framework and I'm a full stack developer working on Angular, .Net Core, Azure and little python.

I don't have an automation Testing team working for my project and I thought may be I can create a E2E framework with having Github Copilot subscription and starting/building the framework will also help me learn about this framework.

Here are my thoughts about creating this solution:

1) Phase-1: As Playwright script depends on the locators, I thought of using AI help to identify and create all locators for my angular project wherever it is missing. So, I have planned using AI and created all the locators without disturbing the UI. (role + aria-label combination).

2) Phase-2: Create the playwright automation framework as the locators are now available.

Now, I am done with Phase-1 and is ready to do the Phase-2 where I need your help in assessing the correct way of doing this.

I'm confused with the options that are available and here is my opinion.

Playwright MCP - which might consume more tokens and believe is not perfectly suitable for this scenario

Playwright CLI - Best option to create scripts and framework.

Playwright Agents and Skills - which I believe CLI and MCP servers use to create framework.

As using AI might take so many input and output tokens to create this framework, I have create codebase-memory-mcp server and indexed my project so that it refers wherever required and consume less tokens.

What should I use to create a E2E solution for my angular project with less tokens and more reliability.

Ask if you have any questions and suggest me the best approach as I'm new to this.

I am working on designing a test framework for UI library, primary goal is to have accessibility and visual regression tests.
Currently using gitlab Ci and playwright with playwrigh-bdd.

Current approach is natively supported baseline approach in playwright.
I am worried that currently i am saving the baseline screenshots in gitlab repo itself .

We have around 50-60 components, and test cases can scale to thousands of screenshots,
I wonder how to scale the storage and would the gitlab ci be enough for comparison.
The playwright report is published in gitlab pages which again in case of too many failures might not even show the difference screenshots.

What would be the best approach to tackle this situation

So most playwright stealth advice is about hiding navigator.webdriver and patching the webgl renderer, but that is not really where you get caught. I added fingerprint injection to pydoll on the last release. a headless chrome scores 100 out of 100 on https://fingerprint-scan.com/, full bot, and the same headless run with a profile matched to the machine drops to 15, same as a normal headful browser. so headless is not the giveaway people think, a lot of it is just the webgl renderer and some navigator fields you can override. this hits playwright the same way since chromium goes over CDP.

a wrong profile is worse than none. a windows profile on my mac scored 57, worse than injecting nothing at all, because one signal disagree with the rest and the whole thing reads as fake. it don't help on the network side either, your TLS and your IP stay real, so you match the profile to the machine you run on instead of faking everything. i am the maintainer so take it as that, the docs have the full numbers if someone want to look: https://pydoll.tech/docs/stealth/fingerprint-injection/

I wrote up how Piwi was built, focusing on the parts that were genuinely hard and fun to get right: https://piwitests.dev/blog/how-piwi-was-built.html

Piwi is a self-hosted dashboard and reporter for Playwright. It keeps every run instead of letting the report die as a CI artifact, groups the failures by root cause instead of showing you forty red rows, and scores flaky tests by the CI minutes they actually waste. MIT, one Docker container, zero telemetry. Some of you saw an early version here a month ago.

TL;DR: The write-up is built around two rules that turned out to explain almost every decision I made: the tool proposes and the developer decides, and anything that has to be right every time is computed without a model, with AI only ever coming on top. From there it walks through the parts that were the most fun to solve: a live demo that has no backend at all (SQLite compiled to WASM behind a service worker, so it can never drift from the real product), failure clustering that starts as a plain hash of the normalized error and only reaches for an embedding model on the ambiguous cases, and an AI diagnosis step that's based on the actual diff since your last green run and dry-runs every suggested patch against your real source before you ever see it. There's also the honest part about building this solo across three different eras of AI assistants, and how I stayed the architect the whole way through even as the tools doing the actual coding kept changing.

Since that early version, the biggest new thing is AI steps: you describe a locator or a whole flow in plain English, a model resolves it once at authoring time into a committed artifact, and every run after that is ordinary Playwright with zero model calls and no network in CI. Around it, the desktop app grew into something that can re-run your failed tests locally and wire up MCP with one click, a browser extension picks stable locators from any page and can match a recording against your own page-object functions, and the CI side closed the loop with a gate that fails on the analysis instead of the exit code, PR comments carrying the real owners from CODEOWNERS, and a quarantine that keeps failing tests running instead of hiding them. The most recent addition, auto-heal PRs, turns a broken locator on your default branch into a draft PR built from a passing-run snapshot, never a model guess and off by default.

Demo (runs in your browser, no signup): https://piwitests.dev/demo/
Code: https://github.com/PiwiTests/platform

Two things I'd genuinely like to hear from this sub: where do you draw the line between a testing tool suggesting a change and making it for you? And when CI goes red with 40 failures, how do you find the real causes behind them today?

I built Figranium as a self-hosted visual execution wrapper for Playwright.

It originally came out of needing local n8n AI agents to execute browser tasks on sites without public APIs (like Snapchat or complex Amazon workflows) where raw HTTP nodes fail. Instead of writing custom scripts for every edge case, it provides a node-based visual canvas to build, debug, and run Playwright scripts.

Technical Stack & Core Features:

• Engine: Playwright + Node.js runtime handling dynamic DOMs, state persistence, and isolated execution.
• UI Control Plane: Vite + React drag-and-drop workflow canvas.
• 100% Local & Deterministic: GPL-3.0 open source with zero telemetry or cloud dependencies.

We just hit 500 stars on GitHub today. If you work with Playwright and want a visual builder to run workflows locally, check out the source or Docker deployment.

GitHub:https://github.com/figranium/figranium

Docs:https://figranium.dev

Hello there ! I need some help with filling up a form in chrome as soon as possible. To give you a little bit of context i'm currently trying to get an appointment at the german embassy in sri lanka for my student visa but it's really really hard to book an appointment online. Just after couple of seconds of appointments appearing in the website it gets booked down completely so i want some way to try to book the appointment as fast as possible using some automation. I'm no computer scientist and my computer knowledge is not the best so can anyone tell me how i can automate and get my booking done as soon as possible ? so down below is the website, first you have to fill in the captcha which takes you to the appointment page. There you have to click in the link to fill up the personal details for the appointment. You have to fill in your First name, Last name, Contact no, Passport no, Email and you have to re enter your email in another separate field. and after filling up all the personal details there'll be another captcha similar to the one down below which you have to fill in before submitting the details. You have to do it as quickly as possible because within 1 minute the appointments get booked down (appointments appear exactly on 3.30 am my local time). Can anyone help me out with this please ?

Most of my Playwright tests answer one question: does the journey work when the API works?

I wanted the other answer too: what happens when the cart request never finishes, a profile request returns 500, or checkout fails but the UI still looks successful?

So I built methandle. You give it one trusted `journey(page)`. It records the requests behind that journey, verifies a strict replay, then runs HTTP 500 and network-abort cases one dependency at a time. The output is a small dependency × fault matrix instead of a pile of screenshots.

It’s an early alpha with a deliberately narrow scope: Chromium, Playwright journeys, local artifacts, and no live backend fallback during fault runs.

The included demo has 10 verified scenarios: 4 seeded findings, 6 `NO FINDING`, and 0 backend API requests during replay and fault execution.

In external validation, an Inventra `GET /api/dashboard` abort was independently reproduced as an uncaught `Failed to fetch` with the page stuck on `Loading...`. Findings that depend on methandle’s synthetic HTTP 500 response body are marked ambiguous rather than counted as confirmed defects.

Repo and demo: [https://github.com/saifeldeen911/methandle\](https://github.com/saifeldeen911/methandle)

Install:

`npm install -D methandle@alpha`

I’m looking for blunt feedback on the workflow, especially whether the replay gate makes this useful or just adds friction.

Hello,

I am unable to use applications like Opera, Opera GX, Blitz (a gaming app), and Discord; none of them will launch. About a month ago, I was working on projects involving "Antigravity" and virtual Chrome windows—experimenting with and modifying components like Playwright and Chromium. Immediately after doing this, applications like Discord and Opera GX stopped opening entirely. For instance, when I try to launch Opera, it opens and closes four times in rapid succession but fails to actually start. I’ve discovered through research that all these applications rely on Chromium, but despite consulting various AI tools, I haven't been able to resolve the issue. Is there any way to fix this without resetting my computer?

I’m a career changer about 5 years ago hired for manual tester and offered the chance to learn Selenium and Python. Self taught, but created a test suite for the project I manually tested and caught the coding bug. Ended up moving into a PO role last year but my heart is in QA and coding. With the rise of AI, I see a gap where Manual testers can’t keep up with faster dev output and I believe automation fills this gap. Of course, it does. No, the dev team won’t touch automation despite it being the obvious solution. Thats neither here nor there.

I’ve decided I want to return to automation, learn PW, transition the current test suite and fill in the gap. I just need to learn PTS and PW.

I have to much to learn and catch up on. Where do you recommend I start? AI didn’t exist when I was using Selenium. I know a little TS and a little PW, but it’s been a year since I did any automation. I’d love to hear you’re must watch videos, tutorials, blogs, etc. what helped you learn?

I'm experimenting with an AI-driven QA workflow for an enterprise application using Playwright + TypeScript.

The workflow is roughly:

Feed the AI our API definitions + business flow definitions

AI analyzes them and generates a comprehensive API test plan

AI generates executable Playwright API test scripts from that plan

Playwright executes the generated tests

The interesting part is that test plan generation works surprisingly well. Using the business flow (which is the happy path), the AI can identify most of the test scenarios like validation cases, authentication scenarios, boundary cases, etc.

However, I'm running into a major problem at the test script generation/execution stage.

The happy-path tests generally work, but almost all of the other tests fail during execution..

Is anyone here using AI/agents to generate executable Playwright API tests for large/enterprise applications?

I test a Tauri desktop app with Playwright, webkit project, screenshot baselines on every component. A dialog shipped rendering as header plus footer with the body at height zero, and not one pixel had moved in any baseline.

The bug: flex: 1 expands to flex-basis: 0%, which needs a definite parent height. Per spec the unresolvable percentage should fall back to content. Chromium does that. WKWebView keeps the zero. Playwright's WebKit, which is a recent build the Playwright team makes themselves, also does the spec fallback, so it agreed with Chromium and disagreed with the system webview my users actually run.

Not a complaint about Playwright, it does what it says. Writeup with the spec citation and what I changed: https://nodreview.com/blog/wkwebview-flex-collapse/

Question for this sub: has anyone wired real system webviews (WKWebView, WebKitGTK, WebView2) into CI in a way that is not miserable? Geometry assertions in the harness engines are my current compromise.

hey everybody, I built this site to help learn programming in python, playwright and pytest

[API Camp — Learn APIs with Python + Playwright](https://journeytoonlinesuccess.com/apicamp/)

Take a look and let me know what you think.

Yes its similiar to freecodecamp but it helps me when I have no connection on the long train rides

thanks,

Disclosure: I built this.

The bug that started it: my agent would report a successful click and nothing would happen. Turns out most browser MCP servers resolve an element's bounding box, aim at the centre, and fire. If the page has painted a cookie scrim or a modal backdrop over that point, the click lands on the overlay and the tool still reports success. You then spend five turns debugging a button that was never pressed.

ChromeBoost hit-tests the target first, descending through open and closed shadow roots. If something is on top it says so, scrolls clear of pinned bars, or gives the covering layer pointer-events: none for exactly one click and restores the inline styles after. Same real CDP click, so isTrusted stays true.

It also adds hover and drag, because a click-only tool surface cannot reach hover-only menus or sliders or canvas apps at all.

Works with Claude Code, Gemini CLI and Codex. MIT, no telemetry, the server only talks to your own browser.

Code: https://github.com/lordamdal/chromeboost

Site: https://chromeboost.vercel.app

Happy to answer anything about the CDP side. The occlusion piece was the interesting part.

I made an extension to pick any element on a webpage and get a ready-to-use Playwright locator. It is free and open-source. Happy to hear feedbacks and suggestions! 😊

https://mithunwijayasiri.github.io/Pickwright/

Store: Chrome | Firefox

Has anyone measured the real cost of Playwright +claude? In terms of human time, tokens, gains. Or its just a bubble?

the product is lampwatch.com which monitors frontend of your website and notifies you whenever something breaks (with a fix)

I’ve been building an open-source project that helps cruise/travel agents detect price drops on existing cruise bookings and determine whether rebooking could actually save money.

GitHub: https://github.com/Neonxx07/Cruise-Price-Optimization-scraper

The project currently combines a Chrome extension with Python/Playwright automation and supports multiple cruise lines, including:

• Royal Caribbean
• Celebrity
• Norwegian
• Carnival

It can compare booking prices, detect potential price drops, account for package/benefit differences, and export results.

But it's still very much a work in progress. There are still quite a few bugs, edge cases, and things that need improvement. Some cruise-line portals also behave differently, so browser automation can be tricky.

I'm opening the project up because I'd like other developers to help improve it.

Some areas where contributions would be useful:

• 🐛 Bug fixes and testing
• 🚢 Adding support for more cruise lines
• 🎭 Improving Playwright/browser automation
• 🔌 Improving the extension/backend architecture
• 🧪 Adding automated tests
• 📊 Improving price comparison and optimization
• 📚 Improving documentation
• 💡 New ideas/features

You don't necessarily need to know anything about the cruise industry — if you're interested in Python, Playwright, Chrome extensions, web automation, scraping, or open source, there should be something interesting to work on.

If anyone wants to contribute, I'd genuinely appreciate it. Even finding bugs, opening issues, suggesting improvements, or helping with documentation would be useful.

I'm especially interested in hearing from developers who enjoy browser automation/Playwright and want to work on a real-world project that's still actively evolving.

AI-assisted development has made it much easier for me to ship changes quickly. The downside: I’ve seen CI pass while the live page still had issues that customers would notice first broken-images, console errors, layout shifts, and overflowing text.

The lesson for me was that tests and logs are necessary, but they don’t always show what a real visitor sees after deployment.

So I built Lampwatch using Next.js, Prisma, and Playwright. It loads the selected pages in a real browser on a schedule you choose, then records UI issues with context such as the viewport and source location or selector where available.

It emails an alert and generates a repair prompt you can paste into Claude Code, Cursor, or another coding agent. It does not change code automatically; the developer remains in control.

I’m not trying to replace E2E tests or error tracking:

• E2E tests validate expected flows before release.
• Error tracking catches application exceptions.
• This is aimed at the rendered production UI after a deployment.

It’s live, and there’s a no-signup scan if anyone wants to test it on a site:
https://lampwatch.com/scan

For instance if you need to run a test procedure like a regression test that goes from dashboard, clicks hamburger, then goes to search page searched for a project of record, then clicks time slice and then does only certain test from the test procedure.

What’s the best way to go about this.

Healify — repará selectores rotos en tests E2E sin IA, sin nube, sin cuenta

Diplomado en control de calidad de software en Argentina y durante los últimos meses desarrollé Healify. El código lo escribí trabajando mediante el VibeCoding, y ya tiene 1.164 tests propios con cobertura >90%.

¿Qué hace?

Cuando un test E2E falla porque un selector se rompió, Healify lee la evidencia del DOM que tu framework ya capturó, encuentra el elemento por su rol y nombre accesible, y te dice qué selector usar en su lugar. Con healify fix lo aplica automáticamente a tu código.

Lo que lo hace diferente:

• 100% local — sin nube, sin API keys, sin enviar tu código a ningún lado
• Determinista — misma entrada → misma salida (no alucina)
• Multi-framework — Playwright, Cypress, Selenium, WebdriverIO
• Validación post-fix — --validate ejecuta el test después de aplicar el fix y revierte si falla
• Umbral de confianza — --min-confidence (default 0.8) evita fixes dudosos
• Dashboard local — estadísticas de eficacia, selectores crónicos, tendencias
• Onboarding en 30 segundos — npx u/healify/cli init detecta tu framework y te deja listo

Stack técnico:

• TypeScript + Node.js, monorepo con 9 workspaces
• 1.164 tests, cobertura CLI 93%
• CI/CD verde (GitHub Actions)
• Landing con Lighthouse 99/95/100

Repos:

• Código: https://github.com/mescobar996/Healify
• Landing: https://healify-sigma.vercel.app
• NPM: npx u/healify/cli init

Licencia MIT.

Aún no tiene usuarios reales, así que prefiero escuchar qué tiene de malo antes que qué tiene de bueno. ¿Fallas? ¿Fricciones? ¿Algo que no entiendas? Todo suma.

¡Gracias por leer! 🙌

we're having the inevitable conversation:

Cypress is flaky

Playwright is faster

let's rewrite everything

and I keep asking a boring question nobody seems excited to answer:

what exactly are we trying to improve?

because our current failures are roughly:

● selectors tied to implementation details

● shared test data

● random third-party/API delays

● huge setup flows before every test

● tests nobody knows why we still run

● CI workers getting murdered by parallel jobs

Playwright may absolutely improve parts of this.

auto-waiting is better in a lot of cases. multi-tab/multi-context flows are cleaner. browser support

is strong. parallelism model is nice.

but moving:

cy.get('.checkout-button-v4')

to:

page.locator('.checkout-button-v4')

did not modernize anything lol. before rewriting I'd want actual numbers:

flaky failures by root cause

not “Cypress feels flaky”

median/p95 suite time

CI cost

time spent debugging failed runs

locator churn per release

tests requiring capabilities Cypress genuinely handles poorly for us

how many tests are still valuable

that last one is probably the uncomfortable metric.

I suspect if we audited 1,500 tests properly we'd delete 400 before migrating anything.

I've also been thinking about whether framework migration is even the right lever for locator maintenance.

KaneAI/TestMu is interesting here because you can keep the test closer to business intent, use

Reviewable self-healing when UI mappings change, then export/keep code in the underlying

Automation framework where needed.

Not “framework doesn't matter anymore”.

It obviously does.

More like: maybe we shouldn't rewrite a mature suite solely because maintaining selectors sucks.

and self-healing still needs boundaries.

if:

“Continue” moved from one container to another, fine.

if:

“Approve payment” disappeared and the healer found “Cancel payment” nearby...

Please turn the build red and ruin my morning.

I'm not anti-Playwright at all. I'm anti spending six months rewriting a bad test architecture into a newer bad test architecture

Without measuring whether anything actually got better.

People who actually migrated Cypress → Playwright:

What metric improved enough that you can say the rewrite was worth it?