Build a test suite that runs on every commit, catches real bugs, and doesn't collapse the first time someone redesigns a page.
Manual testing doesn't scale, and most automated suites die within a year — not because the tool was wrong, but because they were slow, flaky, and painful to maintain, so the team switched them off. This course builds one that survives. You'll write end-to-end tests in Playwright and Python tests in pytest, choosing selectors that outlive a redesign. You'll use AI to draft test cases from a spec and to repair the ones a UI change broke. You'll add visual checks that catch what assertions can't see, wire the whole thing into CI as a gate that blocks bad merges, and keep test data clean so runs stop interfering with each other. Everything here is working code you can run today, and each module ends in something worth showing an employer.
Built by Lakshya Kumar
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
Everything the getting-started guide skips — reusable fixtures, intercepting network calls, staying logged in, and tracing a failure.
Fixtures, parametrize, markers, and conftest — the four features that keep a growing Python suite readable instead of copy-pasted.
Hand an AI a requirements doc and get real test cases back — plus the review discipline that stops it inventing coverage you don't have.
Some bugs are invisible to assertions and obvious to the eye. Automate the comparison — across dark mode, breakpoints, and browsers.
A suite nobody runs protects nothing. Wire it into every pull request, split it so it finishes fast, and report failures where people look.
Half of all flaky tests are really data problems. Generate what each test needs, and leave the database exactly as you found it.
Set a number for how slow is too slow, then let CI enforce it — so a performance regression gets caught in review, not in production.
Two techniques that answer awkward questions: will this API break its callers, and would my suite actually notice if the code were wrong?
Most test maintenance is repairing selectors a redesign broke. Automate that away and spend the time on coverage instead.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Build a complete Playwright test suite for a web application (real or demo). Must include: 30+ test cases in Page Object Model, API mocking for at least one test scenario, visual regression for 3 key page states, GitHub Actions CI that blocks merges when tests fail, test data management (unique data per test run), and at least 5 test cases generated using AI prompts (documented in the README). Zero flaky tests over 5 consecutive CI runs.
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
I'm considering 'Automated QA with AI' — a course on building production-grade test automation with Playwright, pytest, Page Object Model, AI test generation, visual regression, CI quality gates, and self-healing tests. 100 challenges in JavaScript/TypeScript and Python. Context: 1. My current automation experience: [e.g. "never written an automated test", "written some Selenium tests", "comfortable with pytest", "write Playwright tests but they're flaky"] 2. My programming background: [e.g. "JavaScript developer", "Python tester", "no coding background", "can read code but not write from scratch"] 3. What I want to build: [e.g. "CI pipeline that blocks bad deploys", "replace 200 manual regression cases", "portfolio piece for SDET job applications", "test suite for my startup"] Answer: - Which 2 modules will give me the highest leverage in the next 3 months? - What will I have built by the end that I can show in a job interview? - Should I do QA Fundamentals first, or can I start here? - What will I NOT be able to do after — e.g. "test mobile native apps", "write API contract tests", "build a full observability platform"?
Pick a real module (auth, payment, or similar). Use an LLM to generate test cases from the source code + specifications. Run the generated tests; measure mutation-testing kill rate. Compare against human-written tests for the same module.
Run an existing test suite N times; identify flaky tests (intermittent failures). For each flaky test, diagnose root cause (race condition, dependency on time, env-specific). Fix or quarantine at least 5; document the policy for flaky-test handling.
Set up a visual regression pipeline (Percy, Chromatic, or DIY with pixelmatch): screenshot critical screens on every PR, compare against baseline, surface diffs. Apply to at least 10 screens; demonstrate catching a deliberate visual regression.
Build a system that uses an LLM to triage incoming bug reports: classify severity, identify duplicates, route to the right team. Evaluate on 100 historical bug reports; report accuracy vs human triage.
Real practices from Google's engineering team. The test pyramid article is essential.