Home / Services / Playwright training
Playwright training for the team that has to keep the suite
Your engineers learn on the code they already own, taught by a company where all 75 engineers work in this one framework.
Two things are sold here. An engineer of ours goes through your existing Playwright suite with your team in the room, and teaches the conventions document a framework build hands over. Nothing gets written up: the audit is the engagement that sells a report. Billed by the hour, from $100 an hour, with no month attached.
The documentation is thorough and it costs nothing, and a team that wanted the syntax has had it since the day they chose the framework. No published tutorial can open your repository: the sign-in your tests have to get through, the four specs somebody re-runs by hand before a release, the helper module every spec imports and nobody trusts.
Before we scope anything we settle whether there is anything to teach against: a suite, a framework somebody built, or a repository with neither.
Who this is for
Leads who have already chosen Playwright and now have a team that has to live with the choice.
- One engineer wrote the suite and everybody else reads it warily. Every change routes back through that person, and they are the one on holiday when the release moves.
- A migration is landing and the tool changed under the people. The engineers who wrote the old suite still reach for an explicit wait and a custom command, and the project has an end date while the habits do not.
- Four teams write specs four ways, the fourth team's tests are unreadable to the first, and nobody can review across them.
If the deadline is tests on the board rather than people who can write them, this is the slow road to it. A suite built in your repository by us is a project with a scope and an end, and it is the quicker answer to a release nobody trusts.
What has to be true for this to work
Teaching takes or it does not, and most of what decides that sits on your side of the table. Two of the conditions below are reasons to buy something else, so read them before you spend anything.
- Somebody's job description includes the suite. Not as well as their day job. Where the tests are everyone's responsibility and nobody's task, they rot on a schedule you could predict, and no amount of teaching changes the schedule.
- There is something to open. A suite, or a framework somebody built. With an empty repository a session teaches syntax, and the documentation teaches syntax better and for nothing.
- Everyone in the room can run the suite on the first day. Repository and CI access get sorted before we start. A session where nobody can run the tests is a lecture.
- Somebody can accept a convention. Where four engineers can each veto a locator policy, they leave with four opinions and the suite ends up carrying all four.
- The application can be tested as it stands. Where nothing has a stable role, name or test id, the first hours go on instrumenting the product. That is real work and it is a different purchase.
A suite that goes red at random is the case where none of this helps, whatever else is true: nothing gets learned in a session spent arguing about which failures were real. The engagement that ranks the intermittent specs and fixes them is flaky suite repair, and it comes first. Where none of the conditions hold, an engineer of ours working your backlog is the better spend, and there are tests at the end of it either way.
What you get
You are buying hours with your engineers. Neither of them leaves a document behind. Your team keeps the specs they wrote in the session and the argument that got them there.
Your existing suite, read with your team in the room
Somebody who writes Playwright every day opens the suite you have with the people who have to maintain it: which specs flake and what is behind each one, which locators are tied to markup that moves with the next design change, what the config is doing on their behalf. Nothing is written up afterwards. The suite audit sells a report you keep, and that is a separate purchase with a separate price.
The conventions document, taught
A framework build ends at handover and at a conventions document your engineers write specs from. Teaching what is in it — why the fixture exists, what a spec may assume, which decisions are already made and are not worth re-opening — is bought separately, and this is where it is bought.
How it works
The first call
We ask what your team writes tests in today, what there is to open, and who has to be writing specs once we are gone. Who is at the keyboard during the engagement is settled on this call: it is a decision about your team, made with you, and there is no rule we apply to it. You give us the names of the people who will be in the room and what each of them does the rest of the week.
Access, before anything starts
Read access to the repository, one environment that is up, and an hour with whoever can explain what the application does. Everyone attending needs to be able to run the suite on their own machine on the day, because the alternative is people watching somebody else's terminal.
The hours themselves
Your suite on screen, and an engineer of ours reading the code with the people who have to maintain it, saying why each spec will hold or why it will not. Where the conventions came from a framework build we did, the session works through them: the document stops being a file in the repository and starts being the thing a reviewer can point at.
No elapsed time is published here. The things that set it are countable on your side before you write to us: how many people have to be able to write specs afterwards, whether there is a suite to open or a framework or neither, what your team writes tests in today, and how much of the application a test can reach as it stands.
What a review argues about, in code
No client's code appears below. Both samples were written for this page and run before it shipped, and the first is the version a review keeps meeting in a suite that grew one spec at a time.
import { test, expect } from '@playwright/test';
// The version this page argues against. It reads the table once and asserts on what it read.
test('filtering leaves only the Acme invoices', async ({ page }) => {
await page.goto('/invoices');
await page.locator('#filter').fill('Acme');
await page.locator('.filter-form button').click();
const rows = await page.locator('table.invoices tbody tr').count();
expect(rows).toBe(2);
});@playwright/test package at 1.62.1 — in Chromium 151.0.7922.34.
The click returns once the button has been clicked. count() then reads the
table once and hands back a number, and expect(rows).toBe(2) compares it.
Neither line waits for the application to re-render, so the spec is asserting on whatever
the table happened to hold in that millisecond. Playwright puts the warning beside the
method itself: under Asserting count,
the
locator.count() reference says "If you need to assert the number of
elements on the page, prefer expect(locator).toHaveCount() to avoid flakiness."
The version an engineer writes after the review is no longer than the one it replaces:
import { test, expect } from '@playwright/test';
test('filtering leaves only the Acme invoices', async ({ page }) => {
await page.goto('/invoices');
await page.getByLabel('Filter invoices').fill('Acme');
await page.getByRole('button', { name: 'Apply filter' }).click();
await expect(page.getByRole('row').filter({ hasText: 'Acme' })).toHaveCount(2);
await expect(page.getByRole('row').filter({ hasText: 'Globex' })).toHaveCount(0);
});The rewrite re-reads the page until the count settles or the assertion timeout runs out,
and its locators name what a person sees instead of the class names in this week's markup.
Both samples were run against a static page written for the purpose, whose table re-renders
on a timer. When it re-renders synchronously, both specs pass. Give the re-render a
setTimeout — 400 milliseconds, or zero, which is enough — and the
first spec fails with Expected: 2, Received: 3 while the second passes.
The hours go on that argument, held over code your own team wrote.
Where this stops
"Training" is a wide word, and here its edges are Playwright's.
- We teach Playwright. Not testing in the abstract, not a certification syllabus, not how to run a QA function. Where the problem is that nobody knows what to test, that is a different job and it is not this one.
- Mobile means the mobile web. Sessions cover what Playwright emulates — a phone-sized viewport, a user agent, touch input — and they cannot cover a native iOS or Android app, because Playwright drives browsers rather than applications. An emulated mobile browser is a real thing to test and it is not the store build on somebody's phone.
- No load testing and no security testing. We do not teach load or performance testing, because Playwright is not k6, JMeter or Gatling and this company does not sell it. Security testing and penetration testing are not offered here in any framework.
- WebKit is not Safari on somebody's iPhone. Playwright ships a WebKit build and a session covers that; no session turns it into the branded browser on a real device. Internet Explorer sits outside what the framework supports at all, so it is not taught here either.
- No certificate, no exam, no accreditation. Nobody leaves with a qualification, because there is no qualification here to issue. They leave with specs they wrote that survived review.
What it costs
Teaching is billed by the hour, from $100 an hour. The minimum engagement of one full-time engineer for one month does not apply to it: it is bought by the hour, on its own, with no month of anybody's time attached. The audit is bought on the same terms, and everything else this company sells takes the month.
How many hours it takes depends on what your team writes tests in today and how many people have to be able to write specs afterwards. We deliver in all four official bindings, and a session runs in the one your specs are in.
No smallest purchase is published here in hours. How few hours are worth buying is a question for the call. Because there is no month underneath it, the decision to buy more hours is one you make with a session already behind you.
Whoever teaches comes out of the same 75 engineers who do the delivery work, every one of them in Playwright and nothing else. They sit in the United States, Argentina, Poland and Ukraine, which reads as onshore, nearshore and offshore from a US buyer's seat.
Read first
- How to get a team writing Playwright tests. What four engineers have to settle before the first spec, and which parts of Playwright to leave alone for a month.
- Playwright best practices, ranked. The conventions argument, with what ignoring each one costs.
- The page object model. The structural decision a team argues about first, written to hold both positions.
- Fixtures, and when a function will do. The setup model that separates a suite from a folder of scripts.
- Playwright after the quickstart. Where one person starts on their own, before anybody buys anything.
Questions
Can my team just read the documentation?
Yes, and they should: playwright.dev is current, thorough and there for the reading. What it cannot open is your repository. Published material teaches against a demo application: no seeded data, nobody's third-party iframe in the checkout, and a sign-in example the documentation tells you to replace with your own. It stops at the point your suite starts. The same goes for our own Playwright tutorial — it costs nothing and it stops in the same place.
How long before our team is writing tests without you?
We publish no number, because any number here would be made up. What moves it: whether there is a suite to open or an empty repository, what your team writes tests in today, how much of the application a test can reach without a person clicking through first, and whether one person on your side can accept a convention on the day it is proposed. Those are questions we ask on the first call, and they are answerable before you spend anything.
What is the difference between this and hiring one of your engineers?
Whose hands are on the keyboard. An embedded engineer works your backlog inside your repository and the thing you receive is tests; your team picks up what it picks up from reading the diffs. Neither of the two things sold here is us writing your suite: the review is your own code read with your own engineers in the room, and the conventions are taught to the people who have to apply them. Who writes the tests during a training engagement is settled on the first call, and no rule decides it. If what you want is somebody producing specs against a deadline, that is a dedicated Playwright engineer and it is priced on the standard terms.
What does Playwright training cost?
Teaching is billed by the hour, from $100 an hour. The minimum engagement of one full-time engineer for one month does not apply to it: it is bought by the hour, on its own, with no month of anybody's time attached. The audit is the other engagement bought that way, and everything else here takes the month. How many hours are worth buying depends on how many people have to be able to write specs and what there is to open, and it is settled on the call rather than published here.
Do we need the audit first?
No. Most clients arrive knowing the job, and we scope that and start. The audit is a route in and never a gate: it is optional, it is billed by the hour, and how long it takes depends on the project. Where buying it first helps, it is because a report on the suite and the pipeline says what is there before anybody spends an hour teaching against it.
Tell us how many people have to be writing specs
That number and what they write tests in today are enough to scope this, and both are answerable in a sentence. The first call settles the two things this page does not publish: who is at the keyboard during the engagement, and how many hours are worth buying. The work does not wait on an audit: name what your team is short of and we will start from that.