Playwright Automation Project for Beginners (Step-by-Step Guide)

by

This guide explains how to create a production-ready Playwright Automation Framework using TypeScript while following industry standards. It also includes best practices, framework standards, folder structure, and interview questions.

Table of Contents

  1. Introduction to Playwright
  2. Prerequisites
  3. Install Playwright
  4. Create Project Structure
  5. Configure Playwright
  6. Create Test Data
  7. Create Page Objects
  8. Create Utility Classes
  9. Create Base Framework
  10. Write Test Cases
  11. Execute Tests
  12. Generate Reports
  13. Logging
  14. Screenshots & Videos
  15. CI/CD Integration
  16. Framework Standards
  17. Coding Standards
  18. Common Mistakes
  19. Automation Project Interview Questions

Step 1: Understand Playwright

Playwright is Microsoft’s modern end-to-end automation framework that supports:

  • Chromium
  • Firefox
  • WebKit
  • Mobile Browsers

Supports

  • TypeScript
  • JavaScript
  • Python
  • Java
  • .NET

Step 2: Install Node.js

Verify installation

node -v

npm -v

Step 3: Create Project

mkdir PlaywrightFramework

cd PlaywrightFramework

npm init -y

Step 4: Install Playwright

npm init playwright@latest

Choose

TypeScript

tests folder

GitHub Action → Yes

Install Browsers → Yes

Step 5: Project Folder Structure

A recommended enterprise structure:

PlaywrightFramework
│
├── tests/
│     Login.spec.ts
│     Dashboard.spec.ts
│
├── pages/
│     LoginPage.ts
│     DashboardPage.ts
│
├── fixtures/
│     baseFixture.ts
│
├── utils/
│     Logger.ts
│     ExcelReader.ts
│     JSONReader.ts
│     Screenshot.ts
│     WaitHelper.ts
│
├── test-data/
│     login.json
│
├── locators/
│     LoginLocator.ts
│
├── constants/
│     URL.ts
│
├── reports/
│
├── screenshots/
│
├── videos/
│
├── traces/
│
├── global-setup.ts
│
├── global-teardown.ts
│
├── playwright.config.ts
│
├── package.json
│
└── README.md

Step 6: Configure Playwright

Example:

import { defineConfig } from '@playwright/test';

export default defineConfig({

  testDir: './tests',

  timeout: 60000,

  retries: 1,

  reporter: [
    ['html'],
    ['list']
  ],

  use: {

    browserName: 'chromium',

    headless: false,

    screenshot: 'only-on-failure',

    video: 'retain-on-failure',

    trace: 'retain-on-failure'
  }
});

Step 7: Create Test Data

Instead of hardcoding

❌ Bad

page.fill("#username","admin");

Use JSON

{
 "username":"admin",
 "password":"admin123"
}

Advantages

  • Easy maintenance
  • Reusable
  • Supports multiple environments

Step 8: Create Page Object Model

Example

pages/

LoginPage.ts

Methods

login()

enterUsername()

enterPassword()

clickLogin()

verifyLogin()

Each page should contain only methods related to that page.

Step 9: Create Locator Files

Instead of

page.locator("#username")

Create

LoginLocator.ts
username

password

loginButton

Benefits

  • Centralized maintenance
  • Easy updates

Step 10: Create Utility Classes

Common reusable methods:

WaitHelper

DateUtil

RandomGenerator

Logger

Screenshot

ExcelReader

JSONReader

APIHelper

EnvironmentReader

FileUpload

FileDownload

Never duplicate code.

Step 11: Create Base Fixture

Create

fixtures/baseFixture.ts

Purpose

  • Launch Browser
  • Login once
  • Common setup
  • Common teardown
  • Reusable objects

Step 12: Write Test Cases

Example flow

Launch Application

Login

Navigate

Perform Action

Validate

Logout

Every test should be independent.

Step 13: Assertions

Always validate

Example

URL

Title

Text

Visibility

Enabled

Disabled

Count

Attribute

CSS

Without assertions, automation has limited value.

Step 14: Reporting

Supported reports

  • HTML Report
  • Allure Report
  • JSON Report
  • JUnit Report

Generate

npx playwright show-report

Step 15: Screenshots

Capture

  • On Failure
  • Before Action (optional)
  • After Action (optional)

Never capture every step unless debugging.

Step 16: Videos

Retain only failed videos.

video:'retain-on-failure'

Step 17: Trace Viewer

Enable

trace:'retain-on-failure'

Open

npx playwright show-trace trace.zip

Step 18: Logging

Recommended

INFO

DEBUG

WARN

ERROR

Example

Launching Browser

Opening Login Page

Entering Username

Click Login

Dashboard Loaded

Step 19: Environment Files

Use

.env

.env.dev

.env.qa

.env.uat

.env.prod

Never hardcode

  • URLs
  • Credentials
  • Tokens

Step 20: Multiple Environments

QA

UAT

DEV

PROD

Read dynamically using environment variables.

Step 21: Test Data Standards

Keep separate

Positive Data

Negative Data

Boundary Data

Invalid Data

Step 22: Naming Standards

Test Files

Login.spec.ts

Dashboard.spec.ts

Order.spec.ts

Pages

LoginPage

DashboardPage

CartPage

Methods

login()

logout()

searchProduct()

addToCart()

Variables

Good

userName

password

searchText

Avoid

a

b

temp

Step 23: Framework Standards

1. Use Page Object Model

Never write locators directly inside tests.

2. Separate Test Data

Never hardcode values.

3. Use Fixtures

Avoid duplicate setup.

4. Keep Tests Independent

Tests should not depend on execution order.

5. Follow DRY Principle

Don’t Repeat Yourself.

6. Use Explicit Assertions

Validate expected outcomes.

7. Handle Waits Properly

Prefer Playwright’s auto-waiting and explicit expectations. Avoid unnecessary fixed waits (waitForTimeout).

8. Capture Evidence

  • Screenshots
  • Videos
  • Traces

9. Logging

Every important action should be logged.

10. Maintain Readability

Readable code is easier to review and maintain.

Coding Standards

Use Meaningful Test Names

Good

Verify successful login with valid credentials

Bad

Test1

One Assertion Purpose Per Test

Each test should validate one business scenario.

Reuse Components

Avoid duplicate code.

Small Methods

Avoid methods larger than 50–100 lines. Break complex logic into reusable functions.

Remove Dead Code

Delete unused methods and variables.

Git Standards

Commit frequently.

Example

Added Login Page

Implemented Dashboard Page

Added API Utility

Fixed Login Bug

Avoid

Final

Latest

Update

Branch Standards

main

develop

feature/login

feature/cart

bugfix/login

release/v1.2

Folder Standards

Separate

Pages

Tests

Utilities

Fixtures

Reports

Screenshots

Locators

Data

Never mix them.

Reporting Standards

Store

HTML

JSON

JUnit

Allure

Archive reports for CI builds.

CI/CD Standards

Run

  • Smoke Suite
  • Regression Suite
  • Parallel Execution
  • Cross Browser
  • Upload Reports
  • Publish Artifacts

Common Mistakes

❌ Hardcoding credentials

❌ Duplicate locators

❌ Duplicate methods

❌ Static waits

❌ Very long test methods

❌ Dependent tests

❌ No assertions

❌ No logging

❌ Ignoring failed screenshots

❌ Large Page Object classes containing unrelated functionality

Sample Automation Flow

Test

↓

Fixture

↓

Page Object

↓

Locator

↓

Utility

↓

Playwright API

↓

Browser

↓

Application

↓

Assertions

↓

Report

Playwright Automation Framework Interview Questions & Answers

1. Why do you use the Page Object Model?

Answer:
POM separates test logic from page interaction logic, making the framework easier to maintain, reusable, and scalable. Changes to page locators are usually made in one place instead of every test.

2. Why do you use fixtures?

Answer:
Fixtures manage reusable setup and teardown logic, such as browser creation, authenticated sessions, and test data initialization. They reduce duplication and improve test consistency.

3. Why should locators not be written directly in test files?

Answer:
Keeping locators in page objects or dedicated locator files centralizes maintenance. When the UI changes, updates are required in only one place.

4. Why separate test data from test scripts?

Answer:
External test data (JSON, CSV, Excel, etc.) makes tests reusable, supports multiple datasets, and allows non-developers to update test inputs without changing code.

5. Why avoid waitForTimeout()?

Answer:
Fixed waits slow down test execution and can make tests flaky. Playwright provides automatic waiting and assertion-based waiting that are generally more reliable.

6. What is the purpose of playwright.config.ts?

Answer:
It centralizes framework configuration such as browser settings, retries, reporters, timeouts, projects, base URL, and execution behavior.

7. Why use baseURL in Playwright?

Answer:
Using a baseURL allows tests to navigate with relative paths, making it easier to switch environments without changing test code.

8. How do you execute tests in parallel?

Answer:
Playwright supports parallel execution through workers and projects. Independent tests can run simultaneously to reduce execution time.

9. Why use traces, videos, and screenshots?

Answer:
They provide diagnostic information for failed tests, making it easier to identify the cause of failures without rerunning the tests.

10. How do you handle different environments?

Answer:
Store environment-specific values (such as URLs and credentials) in environment files or configuration, and load the required configuration based on the execution environment.

11. How do you make Playwright tests stable?

Answer:
By using resilient locators, relying on Playwright’s built-in waiting mechanisms, writing independent tests, avoiding fixed delays, and using proper assertions.

12. How do you organize a large Playwright framework?

Answer:
A scalable framework separates responsibilities into folders such as tests, pages, fixtures, utils, test-data, reports, and config, following the Single Responsibility Principle.

13. What is the difference between beforeEach and fixtures?

Answer:
beforeEach is useful for simple per-test setup, while fixtures provide dependency injection, composability, type safety, and reusable setup/teardown across the framework.

14. How do you manage authentication efficiently?

Answer:
Use Playwright’s storageState to save an authenticated session after login and reuse it across tests, avoiding repeated login steps.

15. What standards do you follow while building an automation framework?

Answer:

  • Page Object Model
  • Independent test cases
  • Externalized test data
  • Centralized configuration
  • Reusable fixtures and utilities
  • Meaningful logging
  • Robust reporting
  • Version control best practices
  • CI/CD integration
  • Consistent coding standards
  • Minimal code duplication (DRY)
  • Clear folder structure
  • Proper assertions and error handling

Final Framework Checklist

Before considering your Playwright framework production-ready, ensure it includes:

  • ✅ Well-defined folder structure
  • ✅ Page Object Model
  • ✅ Custom fixtures
  • ✅ External test data
  • ✅ Environment-specific configuration
  • ✅ Reusable utility classes
  • ✅ Centralized configuration
  • ✅ HTML and Allure reporting
  • ✅ Automatic screenshots, videos, and traces on failure
  • ✅ Logging support
  • ✅ Parallel execution
  • ✅ Cross-browser testing
  • ✅ Authentication using storageState
  • ✅ GitHub Actions or other CI/CD integration
  • ✅ Linting and code formatting (ESLint and Prettier)
  • ✅ Meaningful test names and documentation
  • ✅ Stable, independent, and maintainable test cases

Advanced Playwright Automation Framework Standards

The following practices are commonly followed in enterprise-level automation projects to build scalable, maintainable, and reliable Playwright frameworks.

Step 24: Test Design Standards

A good automation framework starts with well-designed test cases.

Follow AAA Pattern

Every test should follow the Arrange → Act → Assert pattern.

Arrange
    ↓
Launch Browser
Load Test Data

Act
    ↓
Perform User Actions

Assert
    ↓
Verify Expected Result

Example Structure

test('Verify user can login successfully', async ({ loginPage }) => {

    // Arrange
    const user = loginData.validUser;

    // Act
    await loginPage.login(user.username, user.password);

    // Assert
    await expect(loginPage.dashboardTitle).toBeVisible();

});

Step 25: Naming Convention Standards

Project Name

playwright-ecommerce-framework

playwright-bank-automation

playwright-insurance-framework

Test File Names

Good

login.spec.ts

checkout.spec.ts

orderHistory.spec.ts

Avoid

abc.spec.ts

test.spec.ts

new.spec.ts

Page Object Names

LoginPage

DashboardPage

CartPage

CheckoutPage

PaymentPage

Utility Class Names

ExcelUtility

JsonUtility

ApiHelper

LoggerUtility

RandomDataGenerator

Constant File Names

URLs.ts

Messages.ts

Timeout.ts

Environment.ts

Step 26: Locator Strategy Standards

Always use stable locators.

Best Locator Priority

1. getByRole()

2. getByLabel()

3. getByPlaceholder()

4. getByText()

5. getByTestId()

6. CSS

7. XPath (last option)

Good Example

page.getByRole('button', { name: 'Login' });

Better Example

page.getByTestId('login-button');

Avoid

//*[@id='content']/div[2]/div[3]/table/tr[4]/td[2]

Long XPath expressions are fragile and difficult to maintain.

Step 27: Wait Strategy

One of the biggest causes of flaky automation is poor synchronization.

Recommended Waiting Order

Auto Waiting

↓

expect()

↓

waitForURL()

↓

waitForLoadState()

↓

waitForResponse()

↓

waitForTimeout() (Avoid)

Good

await expect(page.getByText("Welcome")).toBeVisible();

Better

await page.waitForLoadState("networkidle");

Avoid

await page.waitForTimeout(10000);

Step 28: Assertion Standards

Every test should verify business behavior.

Examples

Verify

  • Title
  • URL
  • Text
  • Visibility
  • Enabled
  • Disabled
  • Checkbox state
  • Dropdown values
  • API response
  • Database values (if applicable)

Good

await expect(page).toHaveURL(/dashboard/);

Good

await expect(successMessage).toContainText("Successfully Saved");

Step 29: Test Data Management

Store data separately.

test-data

    qa

        login.json

        orders.json

    uat

        login.json

    prod

        login.json

Never Hardcode

Avoid

await page.fill("#username","admin");

Preferred

loginData.username

Step 30: Environment Configuration

Use .env files.

.env.dev

.env.qa

.env.uat

.env.prod

Example

BASE_URL=

USERNAME=

PASSWORD=

Step 31: Logging Standards

A professional framework logs important events.

Log

Browser Launch

Navigation

Login

Click

Validation

Logout

Browser Close

Sample Log

INFO Browser launched

INFO Login page opened

INFO Username entered

INFO Password entered

INFO Login successful

INFO Dashboard loaded

Step 32: Exception Handling Standards

Instead of allowing tests to fail silently, capture useful information.

Example

Take Screenshot

Save Trace

Log Error

Close Browser

Generate Report

Step 33: Retry Standards

Use retries only for unstable environments.

Example

Retry = 1

or

Retry = 2

Avoid large retry counts because they can hide genuine defects.

Step 34: Screenshot Standards

Capture screenshots

On Failure

Before Critical Action

After Critical Action (if needed)

Naming Example

LoginFailure_20260723.png

CheckoutFailure_20260723.png

Step 35: Video Recording Standards

Recommended

retain-on-failure

Avoid recording every test unless required.

Step 36: Trace Standards

Enable trace collection.

retain-on-failure

Trace contains

  • Network
  • DOM
  • Console
  • Actions
  • Timing

Step 37: Test Tagging Standards

Use tags for easier execution.

Example

test('@smoke Verify Login', async () => {})
test('@regression Verify Checkout', async () => {})
test('@sanity Verify Logout', async () => {})

Execute

Smoke

Regression

Sanity

API

UI

Critical

Step 38: Parallel Execution Standards

Group tests logically.

Example

Authentication

↓

Orders

↓

Payments

↓

Reports

Avoid shared test data between parallel tests.

Step 39: Browser Standards

Execute on

Chromium

Firefox

WebKit

Optionally include

Mobile Chrome

Mobile Safari

Step 40: CI/CD Standards

A professional pipeline should

Checkout Code

↓

Install Dependencies

↓

Install Browsers

↓

Run Lint

↓

Run Smoke Tests

↓

Run Regression Tests

↓

Generate Reports

↓

Publish Artifacts

↓

Notify Team

Step 41: Code Review Checklist

Before raising a Pull Request

  • No hardcoded values
  • No duplicate methods
  • No unused imports
  • No commented code
  • No static waits
  • Meaningful variable names
  • Proper assertions
  • Clear comments only where necessary
  • All tests passing
  • Lint checks passing

Step 42: Folder Responsibility

tests/

Contains only test scenarios.

Never store locators here.

pages/

Contains

  • Methods
  • Actions
  • Assertions (optional)
  • Page-specific locators

utils/

Contains reusable helper classes.

Examples

Date Utility

Excel Reader

Logger

Random Data

API Helper

Encryption Helper

fixtures/

Contains

Setup

Teardown

Shared Browser

Shared Context

Shared Login

test-data/

Contains

JSON

CSV

Excel

XML

YAML

reports/

Contains

HTML

Allure

JUnit

JSON

Step 43: Common Utility Classes

Enterprise frameworks usually include utilities such as:

APIUtility

BrowserUtility

CookieUtility

DateUtility

DownloadUtility

EncryptionUtility

EnvironmentUtility

ExcelUtility

FileUtility

JsonUtility

LoggerUtility

MailUtility

PDFUtility

RandomDataGenerator

RetryUtility

ScreenshotUtility

WaitUtility

WindowUtility

Step 44: Framework Architecture

                 Test Scripts
                      │
                      ▼
              Base Fixture Layer
                      │
                      ▼
               Page Object Layer
                      │
                      ▼
               Utility Layer
                      │
                      ▼
           Playwright Framework API
                      │
                      ▼
                 Browser Engine
                      │
                      ▼
                Application Under Test

Step 45: Automation Lifecycle

Requirement

↓

Understand Business Flow

↓

Prepare Test Cases

↓

Create Test Data

↓

Implement Page Objects

↓

Write Test Scripts

↓

Review Code

↓

Execute Tests

↓

Analyze Failures

↓

Fix Issues

↓

Generate Reports

↓

CI/CD Execution

↓

Maintenance

Enterprise-Level Best Practices

1. Follow the Single Responsibility Principle (SRP)

Each class should have one responsibility.

Good

LoginPage

CartPage

OrderPage

Avoid creating one large page object containing multiple unrelated pages.

2. Keep Page Objects Clean

A page object should contain:

  • Locators
  • User actions
  • Page-specific validations (if your team’s standard allows)

Avoid placing business workflows that span multiple pages inside a single page object.

3. Use Meaningful Method Names

Good

login()

logout()

searchProduct()

applyCoupon()

placeOrder()

Bad

doLogin()

click1()

abc()

method2()

4. Keep Methods Small

Instead of

loginAndNavigateToDashboardAndSearchAndLogout()

Split into

login()

navigateToDashboard()

search()

logout()

5. One Test = One Business Scenario

Good

Verify user can login successfully

Bad

Login

Search

Add Product

Delete Product

Logout

Verify Reports

Verify Settings

6. Independent Test Cases

Every test should

  • Create its own data (or use isolated test data)
  • Clean up after itself if necessary
  • Run successfully regardless of execution order

Avoid dependencies such as “Test B requires Test A to pass.”

In the next section, we’ll cover advanced framework design, including:

Enterprise-level interview questions for 3–8 years of Playwright automation experience

Custom Playwright fixtures with dependency injection

storageState Authentication for login reuse

Multi-user session handling

API + UI hybrid automation

Data-driven and keyword-driven approaches in Playwright

GitHub Actions CI/CD implementation

Advanced Playwright Framework Design (Enterprise Level)

This section covers advanced topics used in real-world automation projects. These concepts are commonly discussed in interviews for 3–8 years of QA Automation Engineer / SDET roles.

Step 46: Custom Fixtures

What are Fixtures?

Fixtures provide reusable setup and teardown logic that can be injected into tests. They help avoid duplicated initialization code and improve test maintainability.

Instead of writing:

Launch Browser

Create Context

Open Page

Login

Run Test

inside every test, you create fixtures once and reuse them.

Enterprise Folder Structure

fixtures/

    baseFixture.ts

    loginFixture.ts

    apiFixture.ts

    databaseFixture.ts

Why Use Fixtures?

Benefits include:

  • Code reuse
  • Cleaner test scripts
  • Dependency injection
  • Centralized setup and teardown
  • Easier maintenance
  • Better scalability

Fixture Flow

Test Starts

        │

        ▼

Fixture Initializes

        │

        ▼

Browser Launches

        │

        ▼

Context Created

        │

        ▼

Page Created

        │

        ▼

Login (Optional)

        │

        ▼

Execute Test

        │

        ▼

Cleanup

        │

        ▼

Browser Closed

Step 47: Base Test Pattern

Most enterprise frameworks extend the default Playwright test object.

Example architecture:

Playwright Test

        │

        ▼

Base Fixture

        │

        ▼

Custom Fixtures

        │

        ▼

Page Objects

        │

        ▼

Test Files

This enables tests to receive page objects directly through fixtures.

Step 48: Authentication Using storageState

One of the most common enterprise optimization techniques is reusing authenticated sessions.

Without storageState

Every test performs:

Launch Browser

↓

Open Login Page

↓

Enter Username

↓

Enter Password

↓

Login

↓

Execute Test

Problems:

  • Slow execution
  • Duplicate login code
  • Increased maintenance
  • More authentication traffic

With storageState

Login once.

Save authentication state.

Reuse it for every test.

Flow:

Global Setup

↓

Login

↓

Save Session

↓

All Tests Reuse Session

Advantages:

  • Faster execution
  • Less duplication
  • Stable authentication
  • Cleaner test code

Step 49: Global Setup

Global setup runs before the test suite begins.

Common tasks:

  • Login
  • Generate authentication state
  • Create test users
  • Seed test data
  • Load environment configuration

Step 50: Global Teardown

Runs after all tests finish.

Typical responsibilities:

  • Delete temporary users
  • Remove uploaded files
  • Archive reports
  • Release resources
  • Clean up test data

Step 51: API + UI Hybrid Automation

Enterprise automation often combines API and UI testing.

Example flow:

API

Create Customer

↓

API

Create Order

↓

UI

Login

↓

Search Order

↓

Verify Details

Benefits:

  • Faster execution
  • Reduced UI dependency
  • Better test reliability
  • Easier data setup

Step 52: Data-Driven Testing

Instead of writing multiple similar tests:

Login Test 1

Login Test 2

Login Test 3

Login Test 4

Create one reusable test that reads multiple datasets.

Data sources can include:

  • JSON
  • CSV
  • Excel
  • Database
  • API

Benefits:

  • Less duplicate code
  • Easier maintenance
  • Better coverage

Step 53: Configuration Management

Separate configuration from business logic.

Example configuration values:

Application URL

Browser

Username

Password

Timeout

Retry Count

API URL

Never hardcode these values inside page objects or tests.

Step 54: Browser Context Management

Understand the hierarchy:

Browser

      │

      ▼

Browser Context

      │

      ▼

Page

Browser

  • Launches the browser engine.

Browser Context

  • Represents an isolated browser session.
  • Has independent cookies, storage, and cache.

Page

  • Represents a browser tab.

This isolation enables multiple users or sessions to be tested simultaneously.

Step 55: Multi-User Testing

Example scenario:

Admin Login

        │

        ▼

Approves Order

        │

        ▼

Customer Login

        │

        ▼

Verifies Approved Order

Use separate browser contexts for each user to keep sessions isolated.

Step 56: Parallel Execution Strategy

Enterprise suites typically organize execution by feature or risk level.

Example:

Worker 1

Authentication Tests

------------------------

Worker 2

Order Tests

------------------------

Worker 3

Payment Tests

------------------------

Worker 4

Reporting Tests

Guidelines:

  • Avoid shared mutable test data.
  • Ensure tests are independent.
  • Clean up created data.

Step 57: Test Categorization

Large frameworks categorize tests for faster execution.

Common categories:

Smoke

Sanity

Regression

Critical

API

UI

Integration

End-to-End

Performance (where applicable)

Benefits:

  • Faster release validation
  • Targeted execution
  • Better CI/CD pipelines

Step 58: Smoke Suite

Purpose:

Verify that the application is stable enough for deeper testing.

Typical checks:

Application Launch

Login

Dashboard

Logout

Basic Navigation

Should complete within minutes.

Step 59: Regression Suite

Purpose:

Verify that new changes have not broken existing functionality.

Includes:

Authentication

Orders

Payments

Reports

Profile

Settings

Typically executed:

  • Nightly
  • Before releases
  • After major changes

Step 60: Test Execution Pipeline

Developer Commit

        │

        ▼

Git Push

        │

        ▼

Pull Request

        │

        ▼

Code Review

        │

        ▼

Build

        │

        ▼

Install Dependencies

        │

        ▼

Execute Smoke Tests

        │

        ▼

Execute Regression Tests

        │

        ▼

Generate Reports

        │

        ▼

Publish Artifacts

        │

        ▼

Notify Team

Step 61: Logging Standards

A useful log should answer:

  • What happened?
  • When did it happen?
  • Which test executed it?
  • Was it successful?
  • If it failed, why?

Example log sequence:

INFO  Browser launched

INFO  Login page opened

INFO  Username entered

INFO  Password entered

INFO  Login successful

INFO  Dashboard verified

INFO  Test passed

Avoid excessive logging of trivial actions.

Step 62: Error Handling

When a test fails:

Capture:

  • Screenshot
  • Video (if enabled)
  • Trace
  • Browser console logs (if helpful)
  • Network logs (for debugging API issues)
  • Error message
  • Stack trace

This significantly reduces debugging time.

Step 63: Framework Scalability

A scalable framework should support:

  • Hundreds or thousands of tests
  • Multiple applications
  • Multiple browsers
  • Multiple environments
  • Multiple user roles
  • Parallel execution
  • CI/CD integration

Without major architectural changes.

Step 64: Maintainability Checklist

A maintainable framework should:

  • Minimize duplicated code
  • Use reusable components
  • Centralize configuration
  • Use clear naming conventions
  • Keep page objects focused
  • Keep utilities generic
  • Use meaningful comments only where needed

Step 65: Enterprise Framework Layers

                 Test Layer
                      │
                      ▼
               Fixture Layer
                      │
                      ▼
             Business Workflow Layer
                      │
                      ▼
             Page Object Layer
                      │
                      ▼
              Utility Layer
                      │
                      ▼
          Playwright Framework Layer
                      │
                      ▼
                Browser Engine
                      │
                      ▼
           Application Under Test

The optional Business Workflow Layer contains reusable business processes (for example, “placeOrder” or “createCustomer”) that span multiple page objects while keeping page objects focused on individual pages.

Step 66: Enterprise Automation Checklist

Before releasing an automation framework, verify:

  • ✅ Clear folder structure
  • ✅ Page Object Model implemented
  • ✅ Custom fixtures
  • ✅ Externalized test data
  • ✅ Environment-specific configuration
  • ✅ Authentication reuse with storageState
  • ✅ Robust logging
  • ✅ HTML and/or Allure reporting
  • ✅ Screenshots on failure
  • ✅ Trace collection on failure
  • ✅ Video retention on failure (optional)
  • ✅ Parallel execution support
  • ✅ Cross-browser execution
  • ✅ API integration where appropriate
  • ✅ Linting (ESLint)
  • ✅ Code formatting (Prettier)
  • ✅ GitHub Actions or other CI/CD integration
  • ✅ Documentation (README.md)
  • ✅ Stable, independent test cases

Advanced Playwright Interview Questions & Answers

1. What is the purpose of custom fixtures in Playwright?

Answer:
Custom fixtures encapsulate reusable setup and teardown logic, provide dependency injection, and reduce duplication. They simplify test code by supplying ready-to-use objects such as authenticated pages or page objects.

2. What is storageState?

Answer:
storageState stores browser authentication information, including cookies and local storage. After logging in once, the saved state can be reused across tests, eliminating repeated login steps and improving execution speed.

3. Why use Browser Context instead of multiple Browser instances?

Answer:
Browser contexts are lightweight, isolated sessions within the same browser process. They consume fewer resources while providing separate cookies, storage, and cache, making them ideal for multi-user testing.

4. What are the advantages of Playwright over Selenium?

Answer:

  • Built-in auto-waiting
  • Native support for Chromium, Firefox, and WebKit
  • Fast parallel execution
  • Built-in tracing, screenshots, and video
  • Network interception
  • Reliable locator APIs
  • Multiple isolated browser contexts
  • Rich TypeScript support

5. How do you make Playwright tests less flaky?

Answer:

  • Use stable locators (getByRole, getByTestId, etc.)
  • Avoid fixed waits
  • Rely on Playwright’s auto-waiting and assertions
  • Keep tests independent
  • Use isolated test data
  • Retry only when appropriate
  • Capture traces and screenshots for debugging

6. What is the difference between a Browser, Browser Context, and Page?

Answer:

  • Browser: The browser engine instance.
  • Browser Context: An isolated browser session with its own cookies and storage.
  • Page: A single browser tab within a context.

7. Why should test cases be independent?

Answer:
Independent tests can run in any order, execute safely in parallel, and are easier to debug because failures are isolated to a single scenario.

8. How would you design a Playwright framework for a large enterprise application?

Answer:
I would use a layered architecture with Page Object Model, custom fixtures, reusable business workflows, externalized test data, environment-based configuration, authentication reuse via storageState, centralized logging and reporting, parallel execution, CI/CD integration, and clear coding standards.

Leave a Comment