Capstone Project — Building a Complete Test Automation Framework from Scratch

You have spent 79 chapters learning testing fundamentals, manual techniques, API testing, Selenium, Playwright, Cypress, CI/CD, security, accessibility, BDD, and SDET skills. This capstone project brings everything together into a single, portfolio-ready deliverable: a complete test automation framework for a real web application. The project follows the five-layer architecture from Chapter 42 and incorporates patterns from every part of the series.

Capstone Project — Scope, Architecture and Planning

The capstone framework targets a public practice application (SauceDemo, The Internet, or similar) and demonstrates every skill from the series.

# Capstone project scope

CAPSTONE_SCOPE = {
    "target_app": "SauceDemo (https://www.saucedemo.com) or equivalent practice site",
    "tool_choice": "Selenium (Python), Cypress (TypeScript), or Playwright (TypeScript/Python)",
    "deliverables": [
        "Complete framework with five-layer architecture",
        "15-20 E2E test cases covering critical user journeys",
        "5-10 API test cases with request/response validation",
        "Page Object Model with BasePage and 4-6 page objects",
        "Data-driven tests with external fixture files",
        "Custom commands/utilities for reusable actions",
        "CI/CD pipeline (GitHub Actions) with parallel execution",
        "Cross-browser configuration (Chrome + Firefox minimum)",
        "HTML test report with failure screenshots",
        "Security test cases (XSS, access control)",
        "Accessibility checks (axe-core integration)",
        "README documentation with setup and run instructions",
    ],
}

# Project structure
PROJECT_STRUCTURE = """
capstone-qa-framework/
  config/
    settings.py (or cypress.config.ts)     # Layer 1: Configuration
    browsers.py                             # Browser-specific options
  pages/ (or cypress/support/)
    base_page.py                            # Layer 3: BasePage with shared methods
    login_page.py                           # LoginPage — locators + actions
    inventory_page.py                       # InventoryPage
    cart_page.py                            # CartPage
    checkout_page.py                        # CheckoutPage
  tests/ (or cypress/e2e/)
    test_login.py                           # Layer 4: Login test cases
    test_inventory.py                       # Product browsing tests
    test_cart.py                            # Cart management tests
    test_checkout.py                        # End-to-end checkout flow
    test_api_products.py                    # API validation tests
    test_security.py                        # XSS + access control tests
  utils/
    driver_factory.py                       # Layer 2: Driver management
    data_builder.py                         # Layer 5: Test data builders
    reporter.py                             # Screenshot + logging on failure
  test_data/
    users.json                              # Login credentials fixture
    products.json                           # Product data fixture
  .github/workflows/
    ci.yml                                  # CI/CD pipeline
  reports/                                  # Generated (gitignored)
  requirements.txt (or package.json)
  README.md                                 # Setup + run instructions
"""

# Planning checklist
PLANNING_CHECKLIST = [
    "1. Choose your tool: Selenium (Python), Cypress (TS), or Playwright (TS/Python)",
    "2. Set up the project: initialise repo, install dependencies, create folder structure",
    "3. Implement Layer 1 (Config): environment variables, base URL, timeouts, browser selection",
    "4. Implement Layer 2 (Driver): DriverFactory or browser fixture with local/Grid support",
    "5. Implement Layer 3 (Pages): BasePage + 4-6 page objects with locators and actions",
    "6. Implement Layer 4 (Tests): 15-20 test cases across login, inventory, cart, checkout",
    "7. Implement Layer 5 (Utils): data builders, reporters, screenshot on failure",
    "8. Add API tests: 5-10 tests using cy.request or requests library",
    "9. Add security tests: XSS payloads, access control checks",
    "10. Add accessibility: axe-core integration in functional tests",
    "11. Configure CI/CD: GitHub Actions with Chrome + Firefox, parallel execution",
    "12. Write README: setup instructions, run commands, architecture description",
    "13. Review and refactor: apply SOLID principles, clean code, consistent naming",
]

print("Capstone Project Plan:")
print(PROJECT_STRUCTURE)
print("\nPlanning Checklist:")
for item in PLANNING_CHECKLIST:
    print(f"  {item}")
Note: The capstone project is designed to be a portfolio piece — a public GitHub repository that demonstrates your QA engineering skills to potential employers. Every component maps to a skill from this series: the five-layer architecture (Chapter 42), Page Object Model (Chapter 38), data-driven testing (Chapter 42), CI/CD integration (Chapter 42/59), cross-browser testing (Chapter 43), API testing (Chapter 56), security testing (Chapter 79), and accessibility testing (Chapter 60/79). A well-structured capstone repository is more compelling in interviews than any certification.
Tip: Choose the tool that aligns with your career goals. If targeting enterprise QA roles, choose Selenium (Python or Java) — it is the most widely required. If targeting front-end-focused or startup roles, choose Cypress or Playwright (TypeScript). If you want to demonstrate breadth, implement the core framework in one tool and add a /comparison folder with equivalent tests in a second tool.
Warning: Do not skip the README. A GitHub repository without documentation is inaccessible to reviewers and interviewers. Your README should include: what the project is, which application it tests, how to install dependencies, how to run tests locally, how to run in CI, the architecture overview, and which chapters from this series each component implements. The README is the first thing anyone sees — make it clear and professional.

Common Mistakes

Mistake 1 — Starting with tests instead of architecture

❌ Wrong: Writing 20 test files with duplicated setup, no page objects, and hardcoded data — then trying to refactor into a framework.

✅ Correct: Setting up the five-layer structure first (config, driver, pages, tests, utils), implementing BasePage and one page object, writing one test, then expanding from that solid foundation.

Mistake 2 — Not committing incrementally to Git

❌ Wrong: Building the entire framework locally and pushing one massive commit at the end.

✅ Correct: Committing after each milestone: “Add BasePage and LoginPage,” “Add login tests,” “Add CI pipeline,” “Add API tests.” The Git history demonstrates your development process and thinking.

🧠 Test Yourself

What makes a capstone QA framework project a strong portfolio piece for job applications?