Project Brief — Cross-Browser Test Suite for a Banking Application

This capstone is the most ambitious project of the course. You'll build a comprehensive Playwright test suite for SecureBank, a fictional retail banking web app that exercises every concept across the previous nine chapters: locators, fixtures, page objects, network mocking, API testing, multi-browser execution, visual regression, accessibility audits, parallel CI, and trace-based debugging. The goal is not 30 tests for the sake of 30 — the goal is a portfolio piece that, when shown to a hiring manager or test-architect interviewer, says "I can stand up a production-grade Playwright suite from scratch." This lesson is the brief: the application's surface area, the deliverables, the required test coverage, and the stretch goals for those who want to go further.

The application

SecureBank is a retail banking app with the following surface area. You don't need to build the app — for the capstone, point your tests at any banking-style demo (e.g., a Sauce Demo or ParaBank style sandbox) or stand up a small mocked backend. The point is to design a suite as if the app were real.

Authentication. Email + password login with multi-factor authentication (MFA) via a 6-digit code. Logout button in the header. Inactivity-based session timeout after 10 minutes — the user is redirected to login with a "session expired" notice.

Dashboard. Total balance card, list of accounts (Checking, Savings, Credit Card), three "Quick Action" buttons (Transfer, Pay Bill, Deposit), a list of the most recent 10 transactions, a notifications dropdown.

Transfers. Pick a source account, pick a destination (own account, saved payee, new payee), enter an amount, optional memo, confirm. Validation: insufficient funds, amount above daily transfer limit ($10,000), amount under minimum ($0.01). Confirmation step shows a summary; success screen shows a transaction reference.

Bill payments. Pick a payee from the saved list (electric, gas, internet, credit card), enter an amount, schedule (now, future date, recurring monthly). Recurring payments show in a "Scheduled Payments" tab where they can be cancelled.

Transaction history. Searchable, filterable list (by date range, account, type). Click a row → details modal. CSV export button.

Account settings. Change password, change email, manage MFA devices, manage saved payees, close account (the dangerous-zone test).

Customer support widget. A chat widget mounted in an iframe in the lower-right corner of every page — used for Chapter 3's iframe practice.

This is more surface area than a typical course capstone. That's intentional — real applications are large, and your tests should be designed for an app of this size, not a toy.

Required deliverables

Ten components, all in a single Playwright project:

1. TypeScript-first project setup. tsconfig.json set to strict mode, ESLint configured. playwright.config.ts with three projects (Chromium, Firefox, WebKit), baseURL, trace: 'on-first-retry', retries: process.env.CI ? 2 : 0, fullyParallel: true.

2. Page Object Model. Page objects for each major page: LoginPage, MFAPage, DashboardPage, TransferPage, BillPaymentPage, TransactionHistoryPage, SettingsPage. Each exposes typed locators (private) and high-level actions (public). No test reaches into a page's DOM directly.

3. Custom fixtures with storage state. Three authenticated user fixtures: adminPage (full privileges), standardPage (regular customer), readOnlyPage (audit user, can view but not transact). Each is created via auth.setup.ts storage-state files so tests skip the login UI.

4. API testing with the request fixture. Direct HTTP tests for the /api/accounts, /api/transfers, /api/payments endpoints. Each test bypasses the UI entirely — bearer token, JSON body, response assertions.

5. Network mocking for edge cases. page.route mocks for: a transfer that takes 8 seconds to complete (slow API test), a payment that returns 500 (failure UX test), a /auth/refresh call that returns 401 (session timeout test).

6. Visual regression coverage. toHaveScreenshot baselines for the dashboard, the transfer page (clean state), and the success screen. CI uses --update-snapshots only when explicitly requested via a workflow input.

7. Accessibility audits. @axe-core/playwright scans on the dashboard, transfer page, and bill payment page. Tests fail on any serious or critical violations; moderate and minor violations are logged but allowed.

8. At least 30 tests across categories. The breakdown:

• Authentication (5) — valid login, invalid credentials, MFA prompt, session timeout, logout.
• Dashboard (5) — balance display, account cards, recent transactions list, quick actions, notifications dropdown.
• Transfers (5) — valid transfer with API verification, insufficient funds, exceeds daily limit, invalid amount, confirmation/success flow.
• Bill payments (5) — one-off payment, scheduled future payment, recurring monthly, cancel scheduled, payment failure (mocked 500).
• Cross-browser (5) — login, dashboard render, transfer flow, bill payment flow, settings — each tagged to run on all three browsers.
• API (5) — /accounts list, /transfers create, /transfers read, /payments create, /payments cancel.

9. CI/CD via GitHub Actions. A workflow running 4 shards × 3 browsers, with fail-fast: false, blob reporter on each shard, a merge-reports job that produces the unified HTML, and artefact uploads for both the report and any failure traces. Trigger: every push and PR.

10. Trace configuration. trace: 'on-first-retry' so every CI failure has a downloadable, replayable trace. The README documents how to download and open it.

Required quality gates

The suite isn't done because it runs — it's done because it's trustworthy. Two gates:

• Flaky rate under 2%. Run --repeat-each=5 --workers=4 once before submitting. Any test that flakes is fixed (per the previous chapter's playbook), not retried.
• No secrets in code. API keys, test passwords, Slack webhooks all live in environment variables. The .env.example file documents what's needed; the real .env is git-ignored.

Stretch goals (optional)

For learners who want to go further, in roughly increasing difficulty:

1. Mobile emulation. Add a mobile-chrome project using devices['Pixel 7'] and run a subset of flows on it. The login and dashboard tests should pass on mobile too.
2. Allure reporting. Add the Allure reporter alongside HTML, tag tests with epic / feature / severity, and produce a stakeholder-ready report.
3. Trace-based performance assertions. Use page.route timing or performance.timing to assert dashboard load is under 3 seconds and transfer API response is under 1 second.
4. Dockerised CI. Run the suite using mcr.microsoft.com/playwright:v1.50.0-jammy. Compare the runtime vs. the install-on-runner approach.
5. Slack reporter. Wire up the custom Slack reporter from the previous chapter so failures post to a Slack channel with the test title, browser, and a link to the report.
6. Chromatic-style PR comments. Use gh pr comment from a workflow step to post the merged report URL and a pass/fail summary onto every pull request.

Stretch goals are optional but signal real seniority on a portfolio.

How everything connects

Submission and self-assessment

When you're done, push the project to GitHub and write a README with:

• The architecture (where page objects live, how fixtures are organised, how storage state is generated).
• How to run locally (npm install, npx playwright install, npx playwright test).
• How to interpret CI failures (download artefact, open trace).
• Any environment variables required.
• Screenshots of the HTML report and the Allure report if you did the stretch.

The repo is the artefact. A good repo, well-documented, signals seniority better than a generic resume bullet of "wrote Playwright tests."

Coming from Cypress?

The Cypress equivalent project would have a similar shape: page objects, fixtures, custom commands, network stubs via cy.intercept, plugins for accessibility and visual testing. The capstone-level differences:

• Cypress's parallel execution requires Cypress Cloud (paid). This capstone's CI uses native sharding for free.
• Cypress's component-test mode is a major feature you'd often include in a portfolio piece; Playwright has a similar component-testing mode but it's less mature and not part of this capstone.
• Cypress's time-travel runner is great in development; Playwright's trace viewer is great in CI. The capstone is built around CI-first debugging because that's where most of the production work lives.

⚠️ Common mistakes

• Skipping the flaky-rate gate. Submitting a suite with a 10% flaky rate looks worse on a portfolio than no suite at all. Spend the last day of the project on --repeat-each and trace-driven flake fixing.
• Putting all logic in test files. A capstone with 30 tests and zero page objects shows you can write Playwright but not architect a suite. Page objects, fixtures, helpers — these are what reviewers look for.
• Hard-coding test data and credentials. Passwords and API keys in source files are an immediate red flag. Use .env, document it in .env.example, and check that .gitignore covers .env.

🎯 Practice task

This entire chapter is the practice task. Read the brief now; the next two lessons walk through implementation and review.

1. Pick your target backend — a public banking demo, a Sauce Demo style sandbox, or a small Node + Express mock you write yourself. Document the choice in your README.
2. Set up the empty repo: npm init -y, install Playwright, configure playwright.config.ts with three browsers and tracing, commit the scaffold.
3. Sketch the test list (30+ items) in a TESTS.md file. Group by category. This is your roadmap for the next lesson's walkthrough.
4. Decide which stretch goals (if any) you'll attempt. Write them at the bottom of the README so reviewers can see your scope ambition.

The next lesson is the guided walkthrough — fixtures, page objects, sample tests, and the GitHub Actions workflow, with full code for each component you can adapt to your own version of SecureBank.