Review and Stretch Goals

You've finished the TaskMaster capstone — a 25-test suite covering UI, API, network mocks, visual regression, accessibility, and CI/CD. This last lesson is the part most courses skip: the honest review. We'll walk through a self-assessment checklist, the reflection questions that surface what you actually learned vs what you copy-pasted, the stretch goals that take the capstone from "course exercise" to "portfolio piece," and the courses on qa.codes that build on the foundation you just laid.

Self-assessment checklist

Run the suite locally and in CI, then go through these. Mark each honestly — there's no grade, but the gaps you find are the things to revisit before you put the project on a CV.

Foundation

• Project structure matches the chapter 8 convention (pages/, tests/, utils/, fixtures/).
• pytest.ini registers every custom marker and sets filterwarnings = error::pytest.PytestUnknownMarkWarning.
• .gitignore excludes .auth/, reports/, test-results/, and __pycache__/.
• All page objects inherit from BasePage and hold typed Locator fields.
• Locators prefer get_by_role, get_by_label, get_by_text over CSS classes or XPath.

Test design

• Every test creates its own data via factories — no hardcoded emails or task titles.
• Auth uses session-scoped storage state, not UI login per test.
• API setup is preferred over UI setup wherever the test isn't about the UI flow.
• Web-first assertions (expect(...).to_be_visible()) replace snapshot-style asserts (assert text_content() == ...).
• time.sleep and page.wait_for_timeout appear nowhere in the suite.
• Parametrize is used for at least one auth scenario and one filter scenario.

Coverage

• At least 25 tests across the five buckets.
• Each bucket has a smoke test tagged @pytest.mark.smoke.
• Network mocking covers empty, error, and slow states.
• Visual baselines exist for at least two pages, with masks for dynamic content.
• axe-core scans gate on critical and serious only — not on every minor violation.

CI/CD

• GitHub Actions workflow runs on push and pull_request to main.
• Matrix strategy fans the suite across at least two browsers in parallel.
• Browser binaries are cached across runs.
• pytest-xdist runs tests in parallel within each runner.
• Allure results upload as a CI artefact.
• Failed runs upload screenshots, traces, and the HTML report (via if: always()).

If you're at 22+ checks, the project is done. 18-22 means there are real gaps; pick the most painful and address them. Below 18 means a meaningful chunk of the course material isn't yet in your muscle memory — go back to the chapters covering the gaps.

Reflection questions

Three questions worth thinking through honestly.

Where did you copy-paste from the walkthrough vs build from scratch? The parts you copied work; the parts you built from scratch are the ones you actually understand. If the answer is "I copied most of it," redo one bucket (e.g., the Filtering tests) without looking at the walkthrough — and watch what your hands actually remember vs what they don't.

Which tests caught a real bug, and which exist only to exercise the code? A test that's been green for a year because it's fundamentally unbreakable adds maintenance overhead with no signal. A test that fails the first time the assertion is wrong, then catches the same regression again two months later, is gold. Audit your 25 tests and ask: which are which?

If a teammate joined tomorrow, what would they struggle with? The README, the test data convention, the conftest hierarchy, the fixture names. Whatever your answer, that's the thing to fix or document next. The capstone you can't onboard someone onto isn't a finished project.

Where to go next

Pick the path that fits where you want to go next:

• Heading toward AI-augmented testing? Playwright MCP (covering LLMs that generate tests, debug flakes, and maintain locators automatically) is the natural follow-on. The capstone is the foundation MCP builds on.
• Want to go deeper on APIs? The API Testing Masterclass covers schema validation, contract testing, OAuth, GraphQL, and the patterns this course's page.request chapter only sketched.
• Need to think about scale? Performance Testing with K6 is the parallel discipline — your 25-test suite verifies correctness; load tests verify behaviour under traffic.
• Ready for production CI/CD chops? A dedicated CI/CD for QA Engineers track goes beyond the GitHub Actions chapter into multi-stage pipelines, deployment gates, and the operational patterns large teams rely on.

Stretch goals — pushing the capstone further

If you've got more time and want to keep building, here are five expansions that meaningfully strengthen the project. Each is a 1-2 hour effort.

1. Dockerise the suite. Build a Dockerfile based on mcr.microsoft.com/playwright/python:v1.44.0-jammy. Confirm docker run produces identical results to local pytest. Add a docker-compose.yml that brings up the TaskMaster app and runs tests against it in a single command. Update the GitHub Actions workflow to use the container: block instead of setup-python + playwright install. Result: one-command local runs, identical environment locally and on CI.

2. Multi-browser visual testing. Currently your matrix runs Chromium and Firefox. Add WebKit. For visual tests specifically, generate per-browser baselines and commit them to git — three baselines per visual test. Run the visual tier nightly and gate the smoke tier on Chromium-only visuals to keep PR speed high. Result: catches Safari-specific visual regressions that desktop-only suites miss.

3. Custom Allure categories for failure types. Drop categories.json in allure-results/ (the example from chapter 9 part 2). Configure regex matchers for "UI failures", "API failures", "Visual regressions", "A11y violations". Run the suite, force failures of each kind, confirm the Allure dashboard buckets them correctly. Result: failures group by type in the report, making them readable for non-engineers.

4. Performance assertions via page.tracing. Use Playwright's tracing API to capture timing on critical flows. Wrap the task-list load in a trace, parse the resulting events for first-contentful-paint, and assert the page renders in under 2 seconds. Add a @pytest.mark.performance marker so these run nightly, not on every PR. Result: the suite catches performance regressions, not just correctness regressions.

5. Worker-isolated test data with pytest-xdist. When running with -n 4, each worker gets its own database namespace via the worker_id fixture from chapter 7. Combined with the UUID-suffixed factory data, four workers can run the suite simultaneously with zero collisions. Demonstrate this works by running the suite repeatedly — pytest -n 4 --count 5 — and confirming no flakes. Result: the suite scales horizontally without test-data engineering.

What you've built

Step back. The repo on your laptop has:

• A fully-tested fictional product, with auth, CRUD, collaboration, and filtering — driven by 25+ Python tests.
• Page objects, fixtures, factories, and constants organised the way real teams organise them.
• Visual regression baselines, a11y gates, and CI artefact uploads that surface failures in a way reviewers can act on.
• A GitHub Actions workflow that runs the whole suite on every PR, in parallel, across multiple browsers, with Allure reporting that anyone in the team can browse.

That's a real-world test framework. Most QA engineers in their first job inherit something messier. You built one cleanly from scratch.

A note on shipping the capstone publicly

If you're building this for a portfolio or as part of a job application:

• Polish the README. Title, one-paragraph description, "What this is," "How to run," "Project layout," "What I learned." Keep it under 300 words; longer is reviewer-fatigue territory.
• Pin every dependency. playwright==1.44.0, not playwright>=1.0. Reproducibility is a feature.
• Make the CI badge prominent. A green build badge at the top of the README is the most credible signal you can give. If the CI is red, fix it before linking the repo anywhere.
• Strip the secrets. No real API keys, no real staging URLs, no real test users with leakable passwords. Use secrets.MOCK_BASE_URL = http://localhost:8000 and a fake email domain like taskmaster.test.

The capstone is yours now. You wrote a complete Playwright Python test framework — installation through CI, locators through a11y, fixtures through Allure. That's the skill the rest of your QA career builds on. Take what you learned, ship the next thing, and remember: the test is the spec; the failure is the bug; the framework is the team's productivity.