Written tutorials are great for reference. You bookmark them, copy the code blocks, and come back when you need a refresher. But some things just click faster when someone walks you through the reasoning - why this approach and not that one, what trade-offs were made, and what the architecture actually solves.

That's why I created ArchQA - a YouTube channel where I break down the fundamental architecture behind every decision, so you don't just copy the code - you understand why it works.

🎬 Why Video?

I've spent a lot of time trying to make my articles as practical as possible. Code blocks, correct vs. incorrect examples, real project structures. But there's a gap that text can't fully close.

When you read about setting up a Page Object Model, you get the pattern. But when someone explains why that pattern exists - what problem it solves, what falls apart without it, and how it connects to the bigger architectural picture - that's when it truly clicks.

Understanding the "why" is the difference between following instructions and making your own decisions. That's the experience I wanted to create. Not surface-level tutorials - detailed explanations of the reasoning behind every architectural choice, so you can apply the same thinking to your own projects.

📺 What's on the Channel

The channel launches with three playlists, each covering topics my readers already care about - but going deeper into the "why" behind every decision.

TypeScript for Automation QA (Without the Fluff)

Not just syntax. The video playlist digs into why TypeScript matters for QA, how the type system protects your tests, and what architectural patterns make your automation code maintainable long-term. You'll understand the fundamentals, not just follow along.

Playwright Framework

Building a professional framework isn't about copying a folder structure. The video series explains the architecture behind every layer - why Page Object Model is structured this way, why fixtures solve dependency injection, why certain patterns scale and others collapse. You'll walk away understanding the reasoning, so you can make your own informed decisions.

Playwright Tips & Tricks

33 self-contained, practical techniques. Each video focuses on one tip - short, focused, and immediately applicable. API interception, schema validation with Zod, visual masking, time travel - the kind of things that take your framework from "works" to "works well".

🤝 Blog + Channel = The Full Picture

The blog isn't going anywhere. If anything, the two formats make each other better.

The articles give you the practical reference - code blocks, patterns, step-by-step guides. The videos go deeper into the architecture and the thinking behind those patterns. Together, you get both the "how" and the "why."

If you want a structured path through all the written content, the Complete Roadmap to QA Automation & Engineering has everything organized by series and learning order.

🚀 Come Along for the Ride

The channel is brand new. No backlog of hundreds of videos, no algorithm magic. Just me and topics I genuinely care about explaining well.

If you've found value in the articles, I think you'll find even more in hearing the full reasoning behind the concepts.

Subscribe to ArchQA on YouTube - and if there's a topic you want to see covered as a video, let me know in the comments.

🙏🏻 Thank you for reading! This is just the beginning. More playlists, more deep dives, and more practical content are on the way. See you on the channel.

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

In the second article, we saw what makes an AI agent different from a chatbot. It reads your code, takes actions, and works inside your project. But here's the catch: an agent is only as good as the instructions it follows.

In the third article, we saw how CLAUDE.md gives the agent its rules and workflow. But rules without depth only get you so far. "Use the Page Object Model" is a rule, but how exactly do you structure a page object? What's the difference between a locator getter and an action method? How do you compose components into page objects?

In the fourth article, we gave the agent deep expertise through skill files. Now it knows how to build page objects, selectors, and fixtures. But there's still a gap: the agent has never seen your application.

Everything in this series has been building toward this moment. You have a scaffold with clear structure. An AI agent that reads your rules. Skills that give it deep expertise. And in the fift article, a browser tool that lets it see your application.

Now let's watch it work.

🎬 The Scenario

Your team has just shipped a user registration feature. You need:

• A page object for the registration form

• A Faker factory for user data

• A smoke test for the happy path

• A regression test for validation errors

Before agentic QA, this would be half a day of boilerplate. Inspecting the DOM, writing locators, setting up factories, wiring fixtures, writing tests, debugging failures.

With an agent, your entire input is this:

"The app has a new user registration page at /register. Create a page object, a user factory, a smoke test, and regression tests for validation errors".

🔄 What the Agent Does: Step by Step

Step 1: Read the rules

The agent opens CLAUDE.md first. It notes the mandatory rules, the workflow, and the skills it needs to load. For this task: playwright-cli, selectors, page-objects, test-standards, and data-strategy.

Step 2: Explore the application

Agent → playwright-cli:
"Navigate to /register. List all form fields (role, label, placeholder),
buttons (role, name), headings, and any validation messages visible."

Discovery result:

Heading: "Create your account" (role: heading, level: 1)
Input: label "First name" - required
Input: label "Last name" - required
Input: label "Email address" - required, type: email
Input: label "Password" - required, type: password, placeholder: "At least 8 characters"
Input: label "Confirm password" - required, type: password
Button: "Create account" (role: button)
Link: "Already have an account? Sign in" (role: link)

Step 3: Check existing patterns

The agent reads pages/app/ to see how existing page objects are structured. It reads test-data/factories/app/ to see how existing factories are formatted. It confirms the import paths and naming conventions.

Step 4: Generate the page object

// pages/app/registration.page.ts
import { Page } from "@playwright/test";

export class RegistrationPage {
  constructor(private readonly page: Page) {}

  get firstNameInput() {
    return this.page.getByLabel("First name");
  }

  get lastNameInput() {
    return this.page.getByLabel("Last name");
  }

  get emailInput() {
    return this.page.getByLabel("Email address");
  }

  get passwordInput() {
    return this.page.getByLabel("Password");
  }

  get confirmPasswordInput() {
    return this.page.getByLabel("Confirm password");
  }

  get createAccountButton() {
    return this.page.getByRole("button", { name: "Create account" });
  }

  get firstNameError() {
    return this.page.getByText("First name is required");
  }

  async register(user: RegistrationData) {
    await this.firstNameInput.fill(user.firstName);
    await this.lastNameInput.fill(user.lastName);
    await this.emailInput.fill(user.email);
    await this.passwordInput.fill(user.password);
    await this.confirmPasswordInput.fill(user.password);
    await this.createAccountButton.click();
  }

  async goto() {
    await this.page.goto("/register");
  }
}

Step 5: Register the page object

The agent adds registrationPage to fixtures/pom/page-object-fixture.ts so tests can access it via dependency injection.

Step 6: Generate the factory

// test-data/factories/app/user.factory.ts
import { faker } from "@faker-js/faker";

export function createUser() {
  const firstName = faker.person.firstName();
  const lastName = faker.person.lastName();
  return {
    firstName,
    lastName,
    email: faker.internet.email({ firstName, lastName }),
    password: faker.internet.password({ length: 12, memorable: false }),
  };
}

Step 7: Generate the smoke test

// tests/app/functional/registration.spec.ts
import { test, expect } from "fixtures/pom/test-options";
import { createUser } from "test-data/factories/app/user.factory";

test(
  "new user can register successfully",
  { tag: "@smoke" },
  async ({ registrationPage, dashboardPage }) => {
    const user = createUser();

    await test.step("Given the user is on the registration page", async () => {
      await registrationPage.goto();
    });

    await test.step("When they fill in valid details and submit", async () => {
      await registrationPage.register(user);
    });

    await test.step("Then they are redirected to the dashboard", async () => {
      await expect(dashboardPage.welcomeHeading).toBeVisible();
    });
  },
);

Step 8: Generate the regression tests

import validationCases from "test-data/static/app/registrationErrors.json";

for (const { field, value, error } of validationCases) {
  test(
    `shows error when ${field} is invalid`,
    { tag: "@regression" },
    async ({ registrationPage }) => {
      await registrationPage.goto();
      await registrationPage.submitWithInvalid(field, value);
      await expect(registrationPage.errorFor(field)).toHaveText(error);
    },
  );
}

Step 9: Run the tests

npx playwright test tests/app/functional/registration.spec.ts

Running 1 test using 1 worker
  ✓ new user can register successfully (2.3s)
  ✓ shows error when email is invalid (1.1s)
  ✓ shows error when password is too short (1.0s)
  ✓ shows error when first name is empty (0.9s)

  4 passed (6.2s)

The agent reports back: all tests pass. Task complete.

👀 What You Review

You didn't write any of that. But your job isn't done. You review it.

What you're looking for:

• Do the locators match what you see in the app? The agent used real discovery, but you know your application.

• Is the test actually testing the right thing? The happy path asserts the dashboard heading. Is that the right success indicator?

• Are the edge cases covered? The regression tests came from a static JSON file. Did the agent create sensible validation cases?

• Does it fit the codebase style? Compare against existing tests. Does this look like it belongs?

This review takes 5-10 minutes. Writing everything from scratch would have taken half a day.

🌱 Growing the Framework With AI

This workflow doesn't just apply to new features. The same pattern works for:

• Refactoring. "The navigation component was moved to a sidebar. Update the relevant page objects".

• New API endpoints. "The /users endpoint now returns a role field. Update the schema and any affected tests".

• Cleanup. "There are three page objects with duplicate navigation methods. Extract them into a shared component".

The agent reads the current state of the codebase, makes targeted changes, runs the affected tests, and confirms nothing broke. You review the diff.

Over time, your role becomes less about writing tests and more about defining what should be tested. The thinking part of QA, not the typing part.

🎯 The Bigger Picture

The scaffold, CLAUDE.md, the skills, the explore-first workflow are not a sorcery. They're just a well-designed system that makes it easy for an agent to do the right thing.

The insight at the heart of agentic QA is simple: AI is most useful when it has clear constraints. A blank slate produces inconsistent results. A scaffold with rules, skills, and a workflow produces output you can trust.

You're not replacing the QA engineer. You're giving the QA engineer a tireless, fast, rule-following colleague who never complains about writing boilerplate.

🚀 Get Started

You have complete instructions to get started with the AI-assisted development.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

🙏🏻 Thank you for reading this series! If you've made it to the end, you now have a complete picture of how agentic QA works, from the scaffold that makes it possible to the moment the tests go green. The tools are here, the patterns are proven, and the only thing left is to start building.

If this series helped you, I'd love to hear about it. See you in the community.

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

In the second article, we saw what makes an AI agent different from a chatbot. It reads your code, takes actions, and works inside your project. But here's the catch: an agent is only as good as the instructions it follows.

In the third article, we saw how CLAUDE.md gives the agent its rules and workflow. But rules without depth only get you so far. "Use the Page Object Model" is a rule, but how exactly do you structure a page object? What's the difference between a locator getter and an action method? How do you compose components into page objects?

In the fourth article, we gave the agent deep expertise through skill files. Now it knows how to build page objects, selectors, and fixtures. But there's still a gap: the agent has never seen your application.

Here's a scenario every automation engineer knows. You ask an AI to generate a page object for your login page. It confidently produces:

get loginButton() {
    return this.page.getByTestId('login-btn');
}

You run the test. It fails. The button doesn't have that test ID. It never did. The AI made it up because it had no way to know the real structure of your page.

This is the core problem with AI code generation for UI testing: the AI is writing about a UI it has never seen. The result is locators that look generally correct but don't work.

The scaffold's answer to this is a principle called explore first, and a tool called playwright-cli.

🤔 What Is playwright-cli?

playwright-cli is a browser automation CLI that lets the AI agent control a real browser. Navigate to URLs, read the page's DOM, discover element roles and labels, take screenshots, and extract structured information.

When an agent has playwright-cli, it doesn't have to guess what's on your login page. It can go look.

# The agent runs something like this before generating code
playwright-cli "Navigate to https://myapp.com/login and list all interactive
elements: their role, accessible name, and any associated label text"

What comes back is a real inventory of the page:

- role: heading
  name: "Sign in"
  level: 1
- role: textbox
  name: "Email address"
  required: true
- role: textbox
  name: "Password"
  required: true
- role: button
  name: "Sign in"
- role: link
  name: "Forgot your password?"
- role: link
  name: "Create an account"

Now when the agent writes a page object, it uses real information:

get emailInput() {
    return this.page.getByLabel('Email address');
}

get passwordInput() {
    return this.page.getByLabel('Password');
}

get signInButton() {
    return this.page.getByRole('button', { name: 'Sign in' });
}

These locators work on the first run. No guessing, no iteration, no debugging brittle selectors.

🗺️ The Explore-First Workflow

The scaffold's CLAUDE.md makes exploration a required step before any code generation:

For UI pages:
1. Use playwright-cli to navigate to the target URL
2. Discover: element roles, accessible names, label text, form structure
3. Note any dynamic content or state-dependent elements
4. Only then: generate the page object

For API endpoints:
1. Make a real request to the endpoint
2. Capture: field names, data types, optional vs required fields
3. Note the exact error response structure
4. Only then: generate the Zod schema

Skip exploration only when the user has already provided the exact structure. Everything else, the agent goes to look first.

🧩 What the Agent Discovers Beyond Selectors

A browser exploration session doesn't just find locators. A thorough agent also discovers:

• Navigation flows. What happens after you click "Sign in"? Where does the page go? What element should the test assert against to confirm success?

• Form validation. Does the form validate on blur or on submit? What do the error messages actually say? ("Email is required" or "Please enter your email address"?)

• Dynamic content. Is there a loading spinner? A toast notification? An element that only appears after an API call? These affect how the test should wait for state.

• Page structure. Is the "Settings" link in a sidebar, a dropdown, or a navigation bar? This determines whether it belongs in the page object or a shared component.

All of this context shapes better tests, tests that reflect how the application actually works, not how the agent imagined it might work.

🔌 Exploration for APIs

The same principle applies to API testing. Before the agent writes a Zod schema (if the API documentation is not available), it makes a real request to the endpoint:

# The agent calls the actual API
POST /auth/login
{ "email": "test@example.com", "password": "secret" }

Response:

{
  "id": 42,
  "email": "test@example.com",
  "firstName": "Test",
  "lastName": "User",
  "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expiresAt": "2026-03-01T00:00:00.000Z"
}

Now the schema is built from reality:

export const LoginResponseSchema = z.strictObject({
  id: z.number(),
  email: z.string().email(),
  firstName: z.string(),
  lastName: z.string(),
  token: z.string(),
  expiresAt: z.string().datetime(),
});

Every field name is correct. Every type is verified. z.strictObject() means if the API later adds an unexpected field, the test flags it immediately.

⚠️ When Exploration Reveals Surprises

Sometimes what the agent finds is not what you expected, and that's valuable information.

The label on the form says "E-mail" (with a hyphen), not "Email". The button says "Log in", not "Login". The error message says "Your password is incorrect." with a trailing period. These small differences matter for locators and assertions.

Without exploration, the agent would have guessed and been wrong. With exploration, it finds the truth, and so do you.

🧑‍💻 Your Role in the Explore-First Loop

With this workflow, your job shifts. You're not writing locators. You're directing exploration.

Before: You open DevTools, inspect the DOM, copy selectors, paste them, test them, adjust them.

After: You tell the agent what page to explore and what to generate. You review the output, confirm the locators look right, run the tests.

The agent does the tedious part. You do the thinking part.

🙏🏻 Thank you for reading! The explore-first principle is what makes AI-generated tests reliable instead of plausible. In the final article, we bring everything together: a complete end-to-end example of an agentic QA session from prompt to passing test.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

In the second article, we saw what makes an AI agent different from a chatbot. It reads your code, takes actions, and works inside your project. But here's the catch: an agent is only as good as the instructions it follows.

In the third article, we saw how CLAUDE.md gives the agent its rules and workflow. But rules without depth only get you so far. "Use the Page Object Model" is a rule, but how exactly do you structure a page object? What's the difference between a locator getter and an action method? How do you compose components into page objects?

CLAUDE.md gives the agent its rules and workflow. But rules without depth only get you so far. "Use the Page Object Model" is a rule, but how exactly do you structure a page object? What's the difference between a locator getter and an action method? How do you compose components into page objects?

This is where skill files come in.

🤔 What Is a Skill File?

A skill file is a detailed, focused markdown document that covers one area of your testing framework in depth. Where CLAUDE.md tells the agent what to do, skills tell the agent how to do it.

The scaffold comes with 13 skills, all living in .claude/skills/:

.claude/skills/
├── selectors/SKILL.md        → Locator priority, forbidden patterns, examples
├── page-objects/SKILL.md     → POM structure, getters vs actions, registration
├── fixtures/SKILL.md         → DI pattern, fixture creation, merging
├── test-standards/SKILL.md   → Test structure, imports, tagging, steps
├── api-testing/SKILL.md      → apiRequest fixture, schema validation
├── data-strategy/SKILL.md    → Factories vs static JSON, Faker usage
├── type-safety/SKILL.md      → Zod schemas, TypeScript strict mode
├── enums/SKILL.md            → Enum conventions and naming
├── config/SKILL.md           → Config patterns, environment variables
├── helpers/SKILL.md          → Helper functions, auth helpers
├── browser-use/SKILL.md      → Live app exploration with browser automation
├── common-tasks/SKILL.md     → Prompt templates, verification checklist
└── refactor-values/SKILL.md  → Safe refactoring of enums and static data

Each one is loaded on demand, not all at once. The agent reads only the skill that's relevant to what it's currently doing.

🧠 Why Not Put Everything in CLAUDE.md?

A single giant instruction file has a real problem. The further down the page a rule lives, the less likely the AI is to apply it consistently. Context windows have limits, and even when they don't, a 5,000 word instruction file is harder to reason about than a 300 word one.

Skills solve this with lazy loading. The agent reads the orchestrator (CLAUDE.md) first. Short, high-level, fast. When it needs to work on a specific area, it reads the relevant skill. Deep expertise, loaded exactly when needed.

Agent working on a page object:
  → CLAUDE.md: "Read selectors and page-objects skills for pages/**"
  → Loads selectors/SKILL.md
  → Loads page-objects/SKILL.md
  → Now has full expertise for this specific task
  → Generates code confidently and correctly

📖 What's Inside a Skill File?

Let's look at what the selectors skill actually contains:

The priority rule with reasoning:

Priority order:

1. getByRole() - Tests behaviour, survives CSS/ID changes
2. getByLabel() - Tied to accessible form labels
3. getByPlaceholder() - Tied to input hint text
4. getByText() - Matches visible text content
5. getByTestId() - Last resort, when no semantic option exists

Forbidden: XPath, CSS class selectors (.btn-primary)

Examples of correct vs incorrect usage:

// ✅ Correct
page.getByRole("button", { name: "Submit Order" });
page.getByLabel("Email address");

// ❌ Wrong: fragile, will break on CSS changes
page.locator(".submit-btn");
page.locator("#email-input");
page.locator('xpath=//button[@class="btn"]');

Edge cases:

- Buttons with icons only: use getByRole('button', { name: /icon label/i })
- Dynamic text: use getByRole with partial name match
- Inside a shadow DOM: note the limitation, escalate to human review

A skill file is essentially what you'd tell a new team member on their first code review. "We do it this way, here's why, here are the gotchas".

🔗 The common-tasks Skill

One skill deserves special attention: common-tasks. It contains prompt templates, pre-written instructions for the most frequent tasks an agent performs:

## Create a Page Object

Before starting:

1. Read selectors/SKILL.md and page-objects/SKILL.md
2. Navigate to the page using browser-use
3. Discover: button names, label text, heading roles

Generate:

- pages/{area}/{name}.page.ts
- Register in fixtures/pom/page-object-fixture.ts

Verification checklist:

- [ ] No XPath
- [ ] No hardcoded strings in test files
- [ ] No `any` type
- [ ] Linting passes
- [ ] Tests run and pass

This is the agent's playbook. Instead of reasoning from scratch about how to create a page object, it has a structured checklist to follow. The output is consistent because the process is consistent.

📝 Writing Your Own Skill Files

The skills that ship with the scaffold are a starting point. As your project grows, you'll discover new conventions that need documenting, and new anti-patterns that need blocking.

A good skill file has four parts:

1. The rule: What the agent should do (or not do) in this area

2. The reasoning: Why the rule exists (helps the agent generalize)

3. Code examples: Correct and incorrect, clearly labeled

4. Edge cases: The situations where the rule gets tricky

Keep them short. A skill file that is short and concise will get used. One that is long and verbose won't.

🔄 Skills as a Team Knowledge Base

Here's something that's easy to miss. Skill files aren't just for AI. They're documentation of your team's decisions.

When a new colleague joins your team, they can read the skill files to understand why things are done the way they are. When you make a decision in a code review ("we always use z.strictObject() because here's what happened that one time"), you add it to the relevant skill file. The AI and the humans stay aligned.

Over time, the .claude/skills/ folder becomes a living record of your team's accumulated QA knowledge.

🙏🏻 Thank you for reading! Skills are what separate a consistent AI-generated codebase from a chaotic one. But rules and skills only get the agent so far. It also needs to see the actual application before writing code for it. That's the subject of the next article.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

In the second article, we saw what makes an AI agent different from a chatbot. It reads your code, takes actions, and works inside your project. But here's the catch: an agent is only as good as the instructions it follows.

Every team has conventions. Use this selector pattern. Put files here. Never do that. Import from this file, not that one.

The problem is that conventions live in people's heads. A new team member, human or AI, doesn't know them until they make a mistake. With humans, you do a code review and explain. With AI, you get the same mistake every single time, because it resets to zero with every new conversation.

CLAUDE.md solves this. It's a file that the AI reads at the start of every session, every time, before generating a single line of code.

🤔 What Is CLAUDE.md?

It's a markdown file at the root of the project, but it's not documentation for humans. It's an instruction set for an AI agent.

When Claude Code (or any Claude-based agent) opens your project, it reads CLAUDE.md first. Everything in that file shapes how the agent behaves throughout the session. What patterns it follows, what it checks before writing, what it refuses to do.

Think of it as onboarding documentation that actually gets read.

Not just for Claude. The scaffold provides the same rules in three formats: CLAUDE.md for Claude Code, .cursor/rules/ for Cursor, and .github/copilot-instructions.md for GitHub Copilot. Same architecture, different file paths. This article uses CLAUDE.md as the example, but the pattern applies regardless of which AI tool you use.

🏛️ The Constitution Pattern

The scaffold organizes CLAUDE.md around three tiers of rules, a structure borrowed from how legal systems separate mandatory law from guidance to prohibition:

MUST    → Mandatory. No exceptions, no debate.
SHOULD  → Recommended. The agent prefers this unless there's a reason not to.
WON'T   → Forbidden. The agent refuses to do this regardless of what's asked.

This three-tier structure is important. If everything is mandatory, the agent has no room to exercise judgment. If everything is flexible, the agent defaults to its own habits, which may not match yours. The tiers give the agent a clear mental model of what's negotiable and what isn't.

✅ The MUST Rules

These are non-negotiable. The scaffold's mandatory rules cover the things that, if violated, break the architecture:

| Rule                 | Requirement                                                   |
| -------------------- | ------------------------------------------------------------- |
| Dependency Injection | Never use `new PageObject(page)` in tests                     |
| Imports              | Import `test` and `expect` from fixtures/pom/test-options.ts  |
| Selectors            | getByRole() > getByLabel() > getByPlaceholder() > getByText() |
| Type Safety          | Use Zod schemas in fixtures/api/schemas/, no `any` type       |
| Strict Schemas       | Always use z.strictObject(), never z.object()                 |
| Assertions           | Web-first assertions only, never waitForTimeout()             |

Notice how specific these are. "Use semantic selectors" is too vague. The agent has to interpret what that means. "Use getByRole() before getByLabel() before getByPlaceholder()" is unambiguous. The agent follows a decision tree.

💡 The SHOULD Rules

These are recommendations for when the agent has a choice:

| Rule            | Recommendation                                                |
| --------------- | ------------------------------------------------------------- |
| Explore First   | Navigate to the page or endpoint before generating code       |
| Data Generation | Use Faker via factories for all happy-path test data          |
| Test Isolation  | Tests should be independent. Use beforeEach, not shared state |
| Test Steps      | Use Given/When/Then structure with test.step()                |

"Explore First" is here rather than in MUST because there are legitimate cases where you've already provided the element structure. The agent uses its judgment.

🚫 The WON'T Rules

These are hard blocks, things the agent should refuse to do even if you ask nicely:

| Rule                 | Violation                                      |
| -------------------- | ---------------------------------------------- |
| No XPath             | Never use XPath selectors                      |
| No Hard Waits        | Never use page.waitForTimeout()                |
| No `any`             | Never use TypeScript's any type                |
| No Multiple Tags     | Each test has exactly ONE tag                  |
| No Hardcoded Content | Never hardcode test strings. Use Faker instead |
| No Loose Schemas     | Never use z.object(), always z.strictObject()  |

The WON'T list is where institutional knowledge lives. These are the mistakes your team has made (or seen others make) and decided to never repeat. Writing them down here means the AI inherits that hard-won experience.

🗺️ The Workflow Section

Beyond rules, CLAUDE.md also defines a step-by-step workflow the agent follows for every code generation task:

1. Read this file (always loaded)
2. Explore the application (navigate or make API requests)
3. Find existing code to follow as a pattern
4. Use fixtures, never manual instantiation
5. Generate data with factories
6. Check against the WON'T rules
7. Run the tests. Don't report done until they pass

Step 7 is particularly important. Without it, the agent might generate code that looks right but fails at runtime. With it, the agent runs the tests and confirms they pass before telling you the task is done.

📁 The Skills Index

CLAUDE.md also acts as a map to the skills files. Rather than cramming every detail into one file (which would be overwhelming), it tells the agent: "When you're working on page objects, read the page-objects skill. When you're working on API schemas, read the api-testing skill."

| Skill          | Read When Working On               |
| -------------- | ---------------------------------- |
| selectors      | pages/\*\*                         |
| page-objects   | pages/\*\*                         |
| fixtures       | fixtures/\*\*                      |
| test-standards | tests/\*\*                         |
| api-testing    | fixtures/api/**, tests/**/api/\*\* |
| data-strategy  | test-data/\*\*                     |

This keeps CLAUDE.md focused and fast to parse, while the detailed expertise lives in dedicated skill files. That brings us to the next article.

✍️ Writing Your Own CLAUDE.md

You don't have to start from scratch. The scaffold's CLAUDE.md is a template. To adapt it to your project:

1. Change the file paths to match your actual folder names

2. Add your team's specific WON'Ts: the anti-patterns you've personally seen cause problems

3. Update the workflow if your project has a setup step or a specific CI check to run

4. Keep it honest: don't add rules you don't actually enforce, or the agent will contradict your existing codebase

The goal isn't a perfect document on day one. It's a living file that gets better every time you catch the agent doing something you don't want.

🙏🏻 Thank you for reading! CLAUDE.md is the file that turns a general AI into a specialized team member. But rules alone aren't enough. The agent also needs deep expertise for specific tasks. That's what skill files provide. See you in the next one.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

"I asked Claude Code to write a test and it gave me something that kind of works"

Sound familiar? That's AI as a code suggester. Useful, but not transformative. You still have to know what to ask, verify what it wrote, adapt it to your project, and repeat for every file.

Agentic QA is different. Instead of an AI that answers questions, you have an AI that takes actions. It reads your codebase, opens a browser, navigates your application, discovers elements, and generates code that fits directly into your existing structure.

The difference is the difference between a search engine and an employee.

🤔 Agent vs Chatbot: What's the Actual Difference?

A chatbot responds to a single message. It has no memory of your project, no access to your files, and no ability to take actions beyond generating text.

An agent operates in a loop:

1. It receives a goal (create a test suite for the registration page)

2. It takes actions to gather information (reads files, navigates the browser)

3. It uses what it found to produce an output (generates the page object, Faker factory, test suite, etc.)

4. It verifies the output (runs the tests, checks for linting errors)

5. It iterates if something is wrong

The agent isn't just writing code. It's operating inside your development environment, making decisions based on real information.

You: Add a e2e test for the checkout flow

Agent:
  → Opens browser, navigates to the product page
  → Discovers: all the necessary actions to complete the checkout flow
  → Reads pages/ to understand existing page object conventions
  → Reads tests/ to understand the test structure and imports
  → Reads .claude/skills/test-standards to check test standards
  → Generates checkout.page.ts, checkout.spec.ts, factory functions, Zod schemas, etc.
  → Runs the test: npx playwright test checkout.spec.ts
  → Confirms: 1 passed, 0 failed
  → If something is wrong, it reads the error and iterates again

That entire loop happens without you writing a line. The agent is doing all the work.

🎯 Why Test Automation Is a Perfect Fit

Not every software task is well-suited for agents. But test automation has properties that make it almost ideal:

• It's highly structured. Tests follow patterns. Page objects follow patterns. Data factories follow patterns. Patterns are exactly what AI agents are good at recognizing and reproducing.

• It's verifiable. After generating a test, the agent can run it. A passing test is objective confirmation that the output is correct. The agent doesn't have to guess. It can check.

• It's repetitive. Writing a page object for the tenth page in your app involves the same thinking as the first. That repetition is tedious for humans and trivial for agents.

• It requires codebase context. A good test has to fit the existing project. An agent that can read your files produces output that integrates cleanly. A chatbot produces output you have to adapt manually.

Important to note that "Human in the loop" is still mandatory. The agent is not a replacement for a human. It is a tool to help you do your job faster and better. You still need to review the output and decide what to do next.

🧠 The Mental Shift

The biggest change is not technical. It is how you think about your role.

Before agentic QA: You are the writer. You design the test, write the page object, wire up the fixture, create the factory, run the tests.

With agentic QA: You are the reviewer and director. You built the architecture. You define the goal, review the output, catch anything the agent missed, and decide what to test next.

This doesn't mean less work. It means different work, higher-level work. You spend more time thinking about what to test and less time typing boilerplate.

🛠️ What Makes an Agent Reliable?

Here's the thing nobody tells you. A raw AI agent, pointed at your codebase with no guidance, will produce inconsistent results. Sometimes good, sometimes generic, sometimes wrong in subtle ways.

What makes an agent reliable is context and constraints:

• Rules about what it must always do

• Rules about what it must never do

• Detailed expertise for specific tasks

• A workflow it follows before generating code

In this scaffold, all of that lives in two places: CLAUDE.md (the orchestrator) and .claude/skills/ (the expertise files). Together they turn a general-purpose AI into something that behaves like a senior QA engineer who has been on your project for months.

That's exactly what the next two articles are about.

🙏🏻 Thank you for reading! The concept of agentic QA sounds futuristic, but the tools exist today and the scaffold is built to use them. Next up: how CLAUDE.md works and why it's the most important file in the project.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

Most teams answer these questions ad hoc, and end up with a different answer every time. After a few months the codebase looks like that - a mix of conventions, inconsistencies, and copy-pasted patterns that no one quite owns.

A scaffold solves this before it starts. But the one we're exploring here was designed with a twist. It wasn't just built for humans. It was built for AI agents to work with.

🤔 What Is a Scaffold?

A scaffold is a pre-built project structure that answers all the "where does this go?" questions upfront. Before you write a single test, you already have:

• A folder for page objects

• A folder for test data

• A single import point for all fixtures

• Conventions for selectors, naming, and test structure

Think of it like a city grid. Before buildings go up, the streets are laid. You always know how to get from A to B because the plan was made in advance.

pages/          → UI page objects and components
tests/          → Test scenarios, organized by area and type
test-data/      → Factories (dynamic) and static JSON (edge cases)
fixtures/       → Dependency injection: wires everything together
enums/          → No hardcoded strings anywhere
config/         → URLs and environment settings
.claude/        → AI instruction files: skills and the orchestrator

🧱 What the Scaffold Gives You

Beyond folder structure, the scaffold comes with working patterns for every layer of a test suite:

• Page Object Model: UI pages represented as TypeScript classes. Locators and actions in one place. When a selector changes, you update one file. POM

• Fixtures and Dependency Injection: Page objects arrive in tests already instantiated. No new LoginPage(page) boilerplate, no manual setup.

• Type-Safe API Testing: Zod - a runtime type validation library - validates API response shapes. If the backend changes a field name, the test fails immediately. Zod

• Smart Test Data: Faker - a library for generating realistic dummy data - creates unique values every run. Static JSON handles edge cases and invalid inputs.

• Strict Linting: ESLint and Prettier enforce conventions automatically. Pre-commit hooks block anything that doesn't meet the standard. If you want to see this in action, the Never Commit Broken Code Again article walks through the full setup.

🤖 But Here's the Real Point

All of that is table stakes for a modern Playwright project. What makes this scaffold different is the .claude/ folder.

On the root level of the project, there is a file called CLAUDE.md and a .claude/ folder. Inside it lives a separate folder for each skill, along with a file for each one. Together, they define a complete instruction set for an AI agent. Every rule, every pattern, every forbidden anti-pattern is written down in a format that an AI reads before generating a single line of code.

The scaffold was designed so that an AI agent can build and extend it correctly, without supervision.

The rest of this series is about exactly that: how agentic QA works, what those files contain, and how you can use AI to build a professional test automation framework faster than you thought possible.

🔌 Works With Your Tools

The scaffold isn't locked to a single AI tool. The same rules and skills are provided in three formats:

• Claude Code reads CLAUDE.md and .claude/skills/

• Cursor reads .cursor/rules/ and .cursor/skills/

• GitHub Copilot reads .github/copilot-instructions.md and .github/instructions/

Same architecture, same conventions, same guardrails. You pick the tool you prefer and the scaffold works with it.

🐳 One Command to Start

The scaffold ships with a Dev Container configuration. If you have Docker installed, you open the project and everything is ready: Node, Playwright browsers, Python, browser-use, and AI CLIs. No manual setup, no dependency hunting, no "it works on my machine". One command, fully configured environment.

🙏🏻 Thank you for reading! This article was the setup. Starting from the next one, we get into the part that changes how you think about test automation. That's the AI side of it. See you there.

You can find the Public README.md file for the scaffold on GitHub: Playwright Scaffold

You can get access to the private GitHub repository here: Get Access

Every coffee you buy ☕ directly contributes to keeping this resource open and growing for everyone.

Due to recent platform updates, some article series may appear out of order in the sidebar. This page serves as the definitive, chronological index for all my major educational series.

Bookmark this page (or pin it) to keep track of your learning progress.

🎬 Now on YouTube

The articles give you the patterns and the code. But I always felt something was missing - the deeper architectural reasoning behind every decision. That's why I started ArchQA, my YouTube channel where I break down the fundamentals so you don't just follow along, you understand why.

Three playlists are live:

TypeScript for Automation QA

Playwright Framework

Playwright Tips & Tricks

Subscribe to catch every new video.

🤖 Series: Agentic QA

A beginner-friendly series about using AI agents to build and maintain a professional Playwright test automation framework - from project scaffold to passing tests.

1. The Scaffold: Playwright Project Structure Built for AI

   • A pre-built Playwright project structure designed for AI agents to build and extend correctly

2. What Is Agentic QA and Why It Changes Everything

   • The difference between an AI that answers questions and one that takes actions in your codebase

3. CLAUDE.md: Teaching the AI Your Rules

   • How a single markdown file turns a general AI into a team member that follows your conventions

4. Skills: Domain Expertise on Demand

   • How focused skill files give your AI agent deep expertise exactly when it needs it

5. Explore First: Why the Agent Looks Before It Writes

   • How exploration gives your AI agent real page context before it writes a single locator

6. Prompt to Passing Test: A Complete Agentic QA Session

   • Watch an AI agent go from a single prompt to page objects, factories, and passing Playwright tests

🏗️ Series: Building a Playwright Framework Step-by-Step

A hands-on, code-heavy guide to building a scalable test automation framework from scratch using Playwright and TypeScript.

1. Initial Setup

   • Setting the foundation for a professional framework.

2. Create User Snippets

   • Boosting productivity with snippets in IDEs.

3. Setup Environment Variables

   • Managing sensitive data and configurations securely.

4. Setup Design Pattern

   • Structuring your project for maintainability.

5. Implementing POM as Fixture and Auth User Session

   • Advanced Page Object Model usage and handling state.

6. Implementing UI Tests

   • Writing robust end-to-end UI scenarios.

7. Implementing API Fixtures

   • Setting up reusable API components.

8. Implementing API Tests

   • Validating backend logic directly.

9. Implementing CI/CD

   • Automating execution with continuous integration pipelines.

10. Never Commit Broken Code Again: A Guide to ESLint and Husky in Playwright

    • Enforcing code quality automatically.

📘 Series: TypeScript for Automation QA

Stop guessing and start typing. This series bridges the gap between basic scripting and professional software engineering.

1. Your First Steps in TypeScript

   • Why TS matters for QA and how to start.

2. How to Use Arrays and Objects

   • Data manipulation essentials.

3. Master Fundamental TypeScript Logic

   • Writing smarter, logic-driven tests.

4. A Practical Guide to Custom Types

   • Defining strict contracts for your data.

5. Stop Writing Brittle Tests: Scalable POM

   • Refactoring Page Objects for stability.

6. Stop Writing Flaky Tests: Async in Playwright

   • Handling promises and awaits correctly.

7. Build a Scalable QA Framework with Advanced Patterns

   • Taking your architecture to the next level.

8. Understanding OOP in Automation QA

   • Applying Object-Oriented principles to tests.

9. Upgrade Playwright Tests: Mixin Design Pattern

   • A guide to flexible class composition.

🧠 Series: Quality Engineering

Moving beyond "writing scripts" to defining quality culture, strategy, and leadership.

1. The Complete Quality Engineering Roadmap

   • The big picture of modern QA careers.

2. Creating a Robust Software Quality Foundation

   • Establishing culture, roles, and mindset.

3. Proactive Strategies for Pre-Development Success

   • Shift-left testing and requirements planning.

4. Mastering In-Sprint Quality

   • Code reviews, collaboration, and faster releases.

5. Developing a Powerful Test Automation Strategy

   • Aligning tools and frameworks with business goals.

⚡ Series: Productivity

Tools to make you a more effective engineer.

1. One File to Rule Them All: Cursor, Windsurf, and VS Code

   • Optimizing your IDE setup.

2. The AI Shift: Why Specialized Models are the Next Wave

   • How AI is reshaping technical teams.

3. Hyped vs. Reality: AI in QA and Development

   • Pragmatic approaches to AI tools.

4. AI for Test Case Generation

   • Practical guides to empowering your team.

5. You're Not Chatting with AI, You're Giving it a Job

   • Prompt engineering techniques for engineers.

🚀 Personal Project

Gemini-Powered Test Case Generator App

• Free Test Case Generator, utilizing Gemini by providing API Token

The AI-Native Playwright Scaffold: Built for the Orchestrator Pattern with Cursor Rules

• Production-ready test automation framework built with TypeScript and Playwright

• Providing a solid foundation for UI, API, and E2E testing.

• Features a Page Object Model architecture, fixture-based dependency injection, Zod schema validation for APIs, and pre-configured authentication handling.

• Includes ESLint, Prettier, and Husky for code quality, along with multi-browser support and comprehensive HTML reporting with traces and screenshots.

Master Playwright: 33 Tips & Tricks for Robust Automation

• 33 self-contained, copy-paste ready TypeScript snippets designed to instantly upgrade your Playwright framework.

• Organized into 7 practical categories, it teaches you advanced techniques like API interception, schema validation with Zod, global authentication setup, time travel, and visual masking.

• All in a clear format you can immediately apply to your real-world projects.

• Start building robust, stable, and intelligent quality tests today.

AI-Native Playwright Scaffold: 13 Skills. Zero Config. One Command

Public Repository

• 3 Modular AI Skills: AI activates specific rules (POM, API, data-strategy) only on matching files. No more flat, generic prompts.

• The "Constitution": Strict guardrails (No XPath, no hard waits, strict Zod) enforced across AI instructions, ESLint, and Husky.

• Zero-Config Dev Container: One-click Docker setup with Node, Playwright, Python, and AI CLIs pre-installed.

• Browser-First AI: Built-in tools let your AI explore the live application's real DOM to generate accurate locators instead of guessing.

• Enterprise Architecture: Zod 4 type-safe API tests, clean Playwright fixture injection, and Faker-driven, parallel-safe data strategies.

📬 Stay Updated

If you found these roadmaps helpful, subscribe to the newsletter to get notified when new chapters are added to these series.

In the world of software development, new trends hit like waves. And the current AI wave is a tsunami.

Just like with cloud computing, mobile-first, or Agile, this trend is governed by the classic Technology Adoption Curve.

History shows us that a significant portion of professionals (roughly 50%) fall into the "Late Majority" or "Laggards" categories. These are the groups who resist, wait, or just hope the new, disruptive way of doing things is a temporary fad.

But as tech professionals, we know it's never a good career move to ignore the elephant in the room.

The "Innovators" and "Early Adopters" understand this. They're already using AI to drive real ROI. They aren't the ones worried about layoffs. Instead they're the ones creating new value.

But here’s the uncomfortable truth. Just as the Laggards are finally starting to use ChatGPT for basic tasks, the trend is already shifting.

🌊 The 5 Groups on the Adoption Curve

To understand where you and your team stand, it helps to know the classic definitions. Every new technology is adopted in this order:

• Innovators (2.5%): The visionaries and tinkerers. They are actively building the new tech itself.

• Early Adopters (13.5%): Tech leaders and evangelists who see the potential and are willing to experiment with new tools to gain a competitive edge.

• Early Majority (34%): The practical-minded group. They adopt a new technology once its benefits have been proven by the Early Adopters. This is when the tech "crosses the dip"

• Late Majority (34%): The skeptics. They only adopt new tech when it's become the new standard, often out of necessity or peer pressure.

• Laggards (16%): The resistors. They are highly resistant to change and are the very last to adopt, often when the old way is no longer supported.

The first wave, driven by massive, general-purpose models like GPT-4, Gemini, and Claude, is now being adopted by the Early Majority. But the next wave is already being built by the Innovators.

👑 The King is Dead: The Peak of Giant AI

The "first King" was the massive, all-purpose model. The leap from GPT-2 to GPT-3 was staggering. The leap to GPT-3.5 and 4.0 gave us powerful, human-like chat interfaces that changed everything.

But now, we're seeing diminishing returns.

The difference in practical output between the latest models (like GPT-4 and its successors) is becoming smaller, while the cost to train and run them is exponentially higher. They are fantastic generalists, but they are not specialized masters.

Think of it this way:

A great chef doesn't use a Swiss Army knife to run a world-class kitchen. A Swiss Army knife is a brilliant general tool, but it can't outperform a specialized sashimi knife, a boning knife, or a paring knife for specific, high-stakes tasks.

We are entering the "Chef's Knife" era of AI.

🚀 Long Live the King: The Rise of Specialized AI

The new "King" is specialization.

The future isn't just one giant model trying to do everything. It's a collection of smaller, specific, and hyper-efficient models tailored for precise contexts and needs.

These specialized tools are built to do one thing perfectly, rather than a million things "pretty well”.

Why Specialized Models Win

For developer, QA, and leadership workflows, specialized AI offers clear advantages:

• ⚡ Peak Performance & Accuracy: A model trained only on your private 2-million-line codebase will always be better at refactoring that code than a general model trained on the public internet.

• 💰 Lower Cost: Running a smaller, focused model is significantly cheaper than paying for API calls to a massive, general-purpose one.

• 🔒 Enhanced Security & Privacy: You can often run these models locally or in your own Virtual Private Cloud (VPC), meaning your proprietary code and sensitive data never leave your control.

• 💨 Speed: Specialized models are optimized for one task, making them faster and less resource-intensive.

Examples of this trend are everywhere:

• For Developers: AI tools trained specifically on UI/UX best practices to generate front-end code, or assistants fine-tuned on your specific database schema.

• For QA: Agents designed to generate test cases from your requirements, or models that learn your app's flow to intelligently generate end-to-end test scripts.

• For Leaders: A custom tool that analyzes your team's pull requests and project management data to help predict project bottlenecks before they happen.

🏄 How to Catch the Next Wave

I truly believe that AI won't replace all humans.

But I am 100% sure that professionals who understand how to leverage the right AI for the right job will replace those who don't.

The only way to stay ahead is to get your hands dirty. The key to success is relentless experimenting and testing. A good surfer doesn't waste time watching the wave they just missed. They get busy positioning for the next one.

Here’s your action plan:

1. Start Small: Master Your Prompts. Treat prompt engineering as a core skill. Don't just ask basic questions. Learn to curate your prompts with deep context, few-shot examples, and specific role-playing. This is the first step from being a consumer of AI to being a power user.

2. Go Big: Build Your Own Tools. Start thinking about your team's unique problems. What's a repetitive, high-value task that a general AI struggles with? Start designing and implementing specific tools for your team. This could be as simple as a fine-tuned model using an open-source framework or as complex as a custom-built agent.

💡 Your Next Move

The "Late Majority" will wait for permission. The "Laggards" will hope it all goes away.

The winners, the Early Adopters and Early Majority, will be the ones who see this shift happening right now.

Don't rely on hopes. Do the hard work of experimenting today so you and your team can be the ones receiving the benefits tomorrow.

Welcome to Phase 4: Formal Testing & Automation. 🤖

This phase isn't about finding quality. It's about validating it at scale. The goal is to build a strategic, automated safety net that provides the team with high confidence before every release. It’s about leveraging technology to ensure the product is not only functional but also stable, performant, and secure.

Implementing the End-to-End (E2E) Testing Strategy

• WHAT it is: A deliberate plan for a small number of automated tests that simulate complete, critical user journeys from start to finish, just as a real user would.

• WHY it matters: The goal is to get the maximum value from the minimum resources. E2E tests are powerful, but they are also the most expensive to run and maintain. A strategy of trying to automate everything with E2E tests will quickly lead to a slow, flaky, and unmanageable test suite that no one trusts.

• HOW to do it:

  • Start with the money: Identify the 3-5 user journeys that are most critical to your business. These are often part of the Acceptance Criteria for major features, like the user registration flow, the main checkout process, or creating a core document.

  • Use a risk-based approach: Ask, "What's the most damaging thing that could break?" and add tests for those scenarios. The goal is to have a small suite of E2E tests that, if they pass, give you high confidence that the core business is functional.

Building a Scalable & Maintainable Automation Framework

• WHAT it is: The underlying architecture of your test code, designed with the fundamental intention that the application you're testing will constantly change.

• WHY it matters: The number one reason test automation projects fail is because they become a maintenance nightmare. If your tests are brittle and break with every minor UI change, your team will spend more time fixing old tests than writing new ones, and the project will eventually be abandoned.

• HOW to do it:

  • Architect for change: The most important principle is the separation of concerns. The test logic (the "what," e.g., "log in") must be separate from the page interactions (the "how," e.g., click('button')).

  • Use design patterns: Patterns like the Page Object Model are popular because they enforce this separation. By doing this, if a button's ID changes, you only have to update it in one place, not in 50 different test scripts. This makes your framework resilient and easy to maintain.

A Stable & Consistent Test Environment Strategy

• WHAT it is: A dedicated, production-like environment for running automated tests that is reliable, predictable, and isolated from the chaos of active development.

• WHY it matters: A flaky test environment makes your test results meaningless. If a test fails, the team must be 99% confident that it's a real bug in the application, not a random glitch in the environment. Without this trust, the entire automation suite loses its value.

• HOW to do it: This is a whole-team responsibility.

  • Automate the infrastructure: Use Infrastructure as Code (e.g., Terraform, Ansible) to define and deploy your environments so they are consistent every time.

  • Manage the data: Have automated processes to refresh the environment with clean, sanitized data on a regular basis.

  • Establish clear rules: Define who can deploy to the environment and when, to prevent unexpected changes from derailing test runs.

Robust Test Data Management

• WHAT it is: The strategy for ensuring every single automated test has the precise, clean, and isolated data it needs to run successfully, every single time.

• WHY it matters: Garbage in, garbage out. Poor data management is the leading cause of flaky tests. If one test changes a piece of data that another test depends on, you'll be stuck debugging frustrating false negatives.

• HOW to do it:

  • Make tests self-contained: The industry best practice is to have tests create their own data.

  • Use APIs for setup and teardown: Before a test runs, use an API call to create the exact user, product, or state it needs. After the test is finished, use another API call to delete that data. This ensures every test is independent and can be run in any order without side effects.

Integrating Automation into the CI/CD Pipeline

• WHAT it is: A tiered strategy for running the right tests at the right time to get fast, relevant feedback without slowing down development.

• WHY it matters: Running a 45-minute E2E test suite on every commit would bring development to a halt. A tiered approach intelligently balances the need for speed with the need for confidence.

• HOW to do it:

  • On Pull Request: Run the fastest tests: linters, unit tests, and a small "smoke suite" of critical API checks. The goal is feedback in under 5 minutes.

  • On Merge to Main Branch: Run a larger "regression suite" of integration and UI tests that cover more functionality. The goal is feedback in under 30 minutes.

  • Nightly/Scheduled: Run everything else: the full E2E suite, performance tests, and security scans. This is the final, deep validation that runs when it won't block developers.

Defining a Performance Testing Baseline

• WHAT it is: The process of measuring and recording your application's performance under a simulated load to establish a "normal" benchmark.

• WHY it matters: You can't know if your application is getting slower if you don't know how fast it is today. This baseline is used to detect performance regressions before your customers complain.

• HOW to do it:

  • Pick a critical flow: Choose something like the API login or a key search query.

  • Run a simple load test: Use an accessible tool to simulate a realistic load (e.g., 50 users for 5 minutes).

  • Measure and record: Capture the key metrics: average response time (latency) and requests per second (throughput). This is your baseline. Integrate this test into your nightly build to ensure these numbers don't get worse over time.

Implementing a Basic Security Testing Checklist

• WHAT it is: Integrating automated tools that scan your code (SAST) and your running application (DAST) for common security vulnerabilities listed in resources like the OWASP Top 10.

• WHY it matters: Security is a critical component of quality. Automatically catching a common vulnerability like SQL Injection or Cross-Site Scripting (XSS) in your pipeline is infinitely cheaper than dealing with a data breach.

• HOW to do it:

  • Integrate free tools: Add a tool like OWASP ZAP to your CI/CD pipeline (the nightly build is a great place for it). This provides a valuable first layer of defense and can catch low-hanging fruit without needing a dedicated security expert.

Cross-Browser & Cross-Device Testing Strategy

• WHAT it is: A deliberate plan, based on real user data, for ensuring your application works correctly on the browsers and devices your customers actually use.

• WHY it matters: Developers often work exclusively in one browser. This can easily lead to CSS or JavaScript bugs that break the experience for a significant portion of your user base on other browsers or mobile devices.

• HOW to do it:

  • Let data drive your decisions: This should be decided upfront based on customer needs. Use your analytics tools (like Google Analytics) to identify the top browsers, operating systems, and screen sizes that represent 90%+ of your traffic.

  • Focus your efforts: Prioritize your testing on that specific set of configurations.

  • Use cloud services for scale: Leverage a service like BrowserStack or Sauce Labs to run your automated tests across all your target configurations in parallel, giving you broad coverage without a massive time investment.

Conclusion: Building Unshakeable Confidence

Phase 4 is about building unshakeable confidence in your product through smart, strategic validation. This automated safety net doesn't just catch bugs. It allows your team to develop and release with greater speed and less fear.

With our product now thoroughly inspected and secured, it's time for the moment of truth. In our final article, we'll explore Phase 5: Release & Post-Release, where our software meets the real world and our quality journey continues.

Phase 3: In-Development Quality is all about the practices that happen during a sprint. This isn't a phase that happens at the end. Instead it's the engine room of quality, running continuously. The core principles here are fast feedback loops and deep collaboration. These are the activities that ensure quality is built directly into the product as it's being assembled.

A Fast and Reliable Continuous Integration (CI) Pipeline

• WHAT it is: A CI pipeline is an automated process, triggered on every code change, that builds the software and runs a suite of automated tests to ensure the change didn't break anything. It's the team's first line of defense.

• WHY it matters: The value of a CI pipeline is directly tied to its speed and reliability.

  • Slow Feedback Kills Momentum: If a developer has to wait 30 minutes for feedback, they've already moved on to another task. When the failure notification finally arrives, they've lost all mental context, making the fix five times harder. A fast pipeline (under 10 minutes) provides immediate feedback while the code is still fresh in their mind.

  • Flaky Tests Destroy Trust: A flaky pipeline that fails randomly is worse than no pipeline at all. When the team can't trust the results, they start ignoring failures. This completely defeats the purpose of having an automated safety net.

• HOW to achieve it:

  • Parallelize your tests: Run different suites of tests simultaneously to drastically cut down execution time.

  • Optimize your build: Use caching for dependencies so you aren't downloading the internet on every run.

  • Enforce a zero-tolerance flaky test policy: If a test is flaky, it's a bug. Immediately quarantine it or fix it.

Enforced Code Quality Standards & Static Analysis

• WHAT it is: Using automated tools, known as linters (like ESLint for JavaScript), to automatically scan code for stylistic errors, potential bugs, and adherence to team-defined standards.

• WHY it matters: This is about cognitive load. Humans are slow, inconsistent, and error-prone when performing repetitive, detail-oriented tasks like checking for correct indentation or unused variables. Offloading this work to a machine frees up precious human brainpower during code reviews to focus on what truly matters: the logic, the architecture, and the user experience.

• HOW to do it:

  • Integrate into the editor: Configure the linter to run directly in every developer's code editor, providing instant, private feedback as they type.

  • Make it a required check: Enforce the standards by making the linting step a mandatory pass/fail check before every commit. This ensures no non-compliant code ever makes it into the repository.

Mandatory, Effective Peer Reviews (Pull Requests)

• WHAT it is: The practice where at least one other team member must thoughtfully review and approve a developer's code changes before they can be merged into the main codebase.

• WHY it matters: While finding bugs is a benefit, the primary goal of a code review is knowledge sharing. It's the single most effective way to spread context throughout the team, prevent knowledge silos, improve code consistency, and collectively elevate the team's skills.

• HOW to make them effective: The tone and focus of the comments are everything. A good review is a dialogue, not a judgment.

  • ❌ Bad Comment: "This is inefficient. Use a hash map." (A command)

  • ✅ Good Comment: "This is an interesting approach. I'm wondering if a hash map might be more performant here for the lookup. What are your thoughts on that?" (A collaborative question)

In-Sprint Dev-QA Collaboration & Pairing

• WHAT it is: Direct, real-time collaboration between developers and QAs throughout the lifecycle of a feature, most powerfully realized through pair-testing sessions.

• WHY it matters: This practice demolishes the "us vs. them" wall. It creates a tight, immediate feedback loop that resolves ambiguities in minutes instead of days. It fosters a powerful sense of shared ownership over the quality of the feature.

• HOW to do it: The pair-testing session is the key ritual.

  1. Schedule a short meeting: Book a 15-minute session once the developer has a working version of the feature.

  2. Dev demonstrates: The developer shares their screen and explains what they built and how it's implemented. This is a mini knowledge-transfer session.

  3. Test together: Both the dev and QA perform a few key tests together, discussing the results in real-time.

  4. Handoff: This session brings instant clarity and serves as the perfect handoff. The QA can then take over to perform deeper, more comprehensive exploratory testing, already armed with full context.

Early and Continuous Exploratory Testing

• WHAT it is: A creative, unscripted, and human-driven approach to testing. It's a "tour" of the feature where the tester uses their knowledge, curiosity, and intuition to discover how the software actually behaves. It’s about investigation and learning, not just script execution.

• WHY it matters: Automation is excellent at verifying that the software does what you expect. Exploratory testing is essential for discovering what the software does when you do something unexpected. It allows you to feel the application, uncovering usability flaws, confusing workflows, and complex state-related bugs that automation will always miss.

• HOW to do it:

  • Start early: As soon as a piece of functionality is available, start exploring it.

  • Use charters: Give your testing a mission. Instead of just randomly clicking, create a goal like, "Investigate how the application handles a user losing their network connection while updating their profile."

Definition of "Ready for QA/Review"

• WHAT it is: A simple checklist, formally part of the team's Definition of Done (DoD), that confirms a piece of work is truly ready for deeper testing and review.

• WHY it matters: This checklist prevents the frustrating "ping-pong" where a ticket is passed back and forth because of missing information, a broken build, or unmet requirements. It creates a smooth, efficient, and respectful handoff process.

• HOW to implement it: This checklist is the final gate before the pair-testing session. It should live as a template in your tickets or pull requests and include items like:

  • ✅ All Acceptance Criteria have been implemented.

  • ✅ The CI pipeline is green.

  • ✅ The feature is deployed to the shared testing environment.

  • ✅ A 15-minute pair-testing session has been scheduled.

Conclusion: The Engine of Quality

Phase 3 is the engine room where the blueprints from Phase 2 become a tangible, working product. Powered by the fast feedback of CI and the deep collaboration of pairing and code reviews, these in-sprint practices are what transform a plan into high-quality, functional software.

Now that we've built the feature with quality baked in, it's time to validate our confidence at scale. In the next article, we'll dive into Phase 4: Formal Testing & Automation, where we'll build the strategic, automated safety net that protects our product and our users.

Welcome to Phase 2: Pre-Development. This is the architect's table.

This phase is about designing quality into your product from the very start. Every activity here is designed to prevent entire classes of bugs before a single line of code is written. This is where an hour of careful planning saves ten hours of painful debugging later. Let's dive into it.

Crafting High-Quality, Testable User Stories

• WHAT it is: A high-quality user story clearly and concisely describes a feature from an end-user's perspective. It's not a technical task list, but a statement of user value.

• WHY it matters: Vague stories are the root of most misunderstandings. They force developers and QAs to make assumptions, which leads to building the wrong thing, extensive rework, and features that completely miss the user's needs.

• HOW to do it: You can use the standard BDD (Behavior Driven Development) style As a [persona], I want [action], so that I can [achieve an outcome] format. This structure forces clarity. Now, compare a bad story to a good one:

  • ❌ Bad: "User login"

  • ✅ Good: "As a registered user, I want to log in with my email and password so that I can access my account dashboard."

The second version is instantly testable and leaves no room for guessing who the user is or what the goal is. A good approach is to use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) as a checklist for every story.

Defining Concrete Acceptance Criteria (ACs)

• WHAT they are: Acceptance Criteria are a set of specific, binary (pass/fail) conditions that a user story must meet to be considered "done". They are the formal contract for the feature.

• WHY they matter: The greatest strength of binary ACs is that they eliminate assumptions. When an AC is subjective ("The page should load fast"), it leads to arguments. When it's binary ("The page must load in under 2 seconds on a 4G connection"), it's a simple, verifiable fact. This robustness is key to shipping with confidence.

• HOW to write them: Focus on clear, testable outcomes. While a format like Gherkin (Given/When/Then) can be useful, the principle is more important than the syntax.

  • ❌ Bad: "The login process should be user-friendly." (Subjective)

  • ✅ Good: "When the user enters an incorrect password, the error message 'Invalid credentials' is displayed." (Pass/Fail)

  • ✅ Good: "Upon successful login, the user is redirected to the /dashboard page." (Pass/Fail)

Implementing "Three Amigos" Sessions

• WHAT it is: A focused working session bringing together the three key perspectives: Product (what is the problem to solve?), Development (how can we build a solution?), and Quality (how could this solution break?).

• WHY it matters: This session is the ultimate defense against ambiguity. It demolishes silos and ensures a shared understanding of the feature, its requirements, and its risks before the first line of code is written. It’s a high-leverage activity that prevents countless hours of wasted work.

• HOW to run it:

  • Keep it small: It's the "Three Amigos", not the "Thirty Amigos". Only the three core perspectives should be present.

  • Have a strict agenda: Start with the initial user story requirements and ACs as a foundation. The goal is to brainstorm the story requirements and to set ACs foundation.

  • Define responsibilities: The Product representative clarifies requirements, the Developer discusses implementation strategy, and the QA probes for edge cases and testability. The goal is to leave the session with crystal-clear, agreed-upon ACs.

Identifying Edge Cases & Negative Paths Upfront

• WHAT it is: The practice of systematically thinking through what happens when things go wrong or when users behave unexpectedly (e.g., entering bad data, losing network, clicking things out of order). This is a critical activity for story grooming sessions.

• WHY it matters: Thinking about negative paths is a core "shift-left" activity. Uncovering a major edge case in a 15-minute grooming session is infinitely cheaper and faster than discovering it through a production bug that impacts thousands of users. This is where a QA's mindset adds immense value.

• HOW to do it: The QA should lead this by asking probing "What if...?" questions.

  • "What if the user tries to register with an email address that already exists?"

  • "What if the API call fails while they are submitting the form?"

  • "What if the user's session times out while they have items in their cart?"

Defining and Integrating Non-Functional Requirements (NFRs)

• WHAT they are: NFRs define how the system should operate, rather than what it should do. The most common examples are performance, security, and accessibility.

• WHY it matters: Leaving NFRs until the end is a recipe for disaster. You can't "add" security or performance to a product after it's built. It has to be designed in. Thinking about NFRs while planning the functional story is crucial because you have the full context to make smart architectural decisions.

• HOW to do it: NFRs can be tracked as their own stories, but they must be discussed alongside the related functional story. For example, while grooming a "File Upload" story, ask:

  • Performance: "What is the maximum file size we need to support? What's the target upload time?"

  • Security: "What file types are allowed? How will we scan for viruses?"

  • Accessibility: "How will a screen reader announce the upload progress?"

Risk-Based Prioritization of Quality Efforts

• WHAT it is: A strategy to focus your most intense testing efforts on the areas of the application that pose the greatest risk to the business and your users.

• WHY it matters: You can't test everything with 100% depth, since it's not practical or economical. This approach ensures your limited time is spent where it matters most. It’s about being effective, not just busy.

• HOW to do it: Use a simple Impact vs. Likelihood matrix to categorize features and guide your testing strategy.

  • High Impact / High Likelihood (e.g., the main payment flow): This requires deep, rigorous testing, including end-to-end automation and extensive exploratory testing.

  • High Impact / Low Likelihood (e.g., data restoration from a backup): This needs a clear test plan for key scenarios but doesn't require exhaustive daily testing.

  • Low Impact / High Likelihood (e.g., a form validation error): This is a perfect candidate for lightweight, automated checks.

  • Low Impact / Low Likelihood (e.g., updating a profile's bio): This can be covered sufficiently by quick exploratory testing.

Making Quality a Factor in Story Estimation

• WHAT it is: The practice of including all quality-related activities (writing unit tests, developing automation test scripts, pair testing, exploratory testing, etc.) within the story point estimation for every user story.

• WHY it matters: Testing is not a separate phase, It's part of the development work. Creating separate "testing tickets" breaks the "Whole Team" mentality and hides the true cost of delivering a feature. Including it in the estimate makes it clear that a story isn't "done" until it's "done and high-quality".

• HOW to do it: During estimation, the team must explicitly discuss the effort required for quality. A developer might say a story is "3 points", and the QA can then ask, "Does that estimate include the time to write the new automated tests and for us to do a 30-minute exploratory session together?" This conversation ensures the full scope of work is accounted for.

Early Test Data & Environment Planning

• WHAT it is: The strategic process of defining the specific data and infrastructure needed to properly test a feature, and doing so before development begins.

• WHY it matters: "Blocked by test data" or "The test environment is broken" are two of the most common and frustrating bottlenecks in the development cycle. They are almost always preventable with upfront planning.

• HOW to do it: Before a story is considered "ready for development", the team must be able to answer these questions:

  • Data: What specific data states do we need? (e.g., A brand new user? A user with 1000+ orders? A user with an expired subscription? A user in a different country?)

  • Environment: Does this feature depend on a new third-party service or a change in our infrastructure? If so, how will we make that available for testing?

Conclusion: From Foundation to Framework

Phase 2 transforms the cultural values from Phase 1 into a concrete plan of action. By focusing on clarity, collaboration, and risk mitigation before development, you build a sturdy framework that prevents defects and ensures you're building the right product, the right way.

With the blueprints now finalized, it's time to pick up the tools and start the construction. In our next article, we'll dive into Phase 3: In-Development Quality, where we'll explore the in-sprint practices that ensure quality is built in, not bolted on.

This leads to deep and rigid inheritance chains. An ArticlePage might inherit from NavPage, which inherits from BasePage. This is not only complex but also violates the single responsibility principle.

What if we could build our Page Objects with components just like we build modern web apps? This is where the Mixin Design Pattern comes in, favoring flexible composition over rigid inheritance.

What's the Problem with Inheritance?

Traditional inheritance (class A extends B) is powerful, but it has limits. A class can only extend one other class.

So, what happens when your ArticlePage needs navigation and table-handling logic, and your HomePage needs navigation and table logic? You can't extend NavPage, TablePage. This forces you to either cram everything into a single BasePage or create convoluted inheritance chains.

The Mixin Solution: Composition

The Mixin Design Pattern lets you create reusable "feature packs". They are small classes focused on a single piece of functionality (like navigation or table handling). You can then "mix" these feature packs into any Page Object that needs them.

This approach allows you to:

• Share functionality across unrelated classes.

• Avoid deep inheritance chains, keeping your code flat and manageable.

• Keep Page Objects clean and focused on their primary purpose.

In modern front-end development, which is heavily component-based, our testing frameworks should evolve too. By using the Mixin Design Pattern, we can build a more modular, reusable, and maintainable test suite.

🚀 Implementing Mixins in Playwright with TypeScript

Let's walk through a practical example of adding shared navigation functionality to a HomePage object without using inheritance. All examples are made for tha app that I am always using - Conduit (huge shoutouts to mr. Artem Bondar) and there is a complete Repository.

Step 1: The applyMixins Helper Function

TypeScript doesn't have a native mixin keyword. So, first, we need a small utility function that does the heavy lifting. This function copies the properties and methods from our "feature packs" to our target class.

Think of this as the engine of our pattern.

TypeScript

// helpers/mixin.ts

/**
 * Mixin function to combine multiple base classes into one.
 * This function copies all properties and methods from source classes to the target class.
 *
 * @param derivedCtor - The target class that will receive the mixed-in functionality.
 * @param constructors - Array of source classes to mix in.
 */
export function applyMixins(derivedCtor: any, constructors: any[]): void {
    constructors.forEach((baseCtor) => {
        // Get all property names from the source class prototype
        Object.getOwnPropertyNames(baseCtor.prototype).forEach((name) => {
            // Skip constructor to avoid conflicts
            if (name !== 'constructor') {
                // Copy the property descriptor (including getters, setters, methods)
                Object.defineProperty(
                    derivedCtor.prototype,
                    name,
                    Object.getOwnPropertyDescriptor(baseCtor.prototype, name) ||
                        Object.create(null)
                );
            }
        });
    });
}

Step 2: Create the "Feature Pack" - NavPage

Next, we create our mixin. In this case, it's a NavPage class that encapsulates all locators and methods for interacting with the website's main navigation bar, a component present on almost every page.

This class is our reusable piece of code.

TypeScript

// pages/clientSite/baseClasses/navPage.ts

import { Page, Locator, expect } from '@playwright/test';

/**
 * This is the page object for the Navigation functionality.
 */
export class NavPage {
    constructor(protected page: Page) {}

    // ... Locators for navBar, homePageLink, settingsButton, etc.

    get signInNavigationLink(): Locator {
        return this.page.getByRole('link', { name: 'Sign in' });
    }
    get emailInput(): Locator {
        return this.page.getByRole('textbox', { name: 'Email' });
    }
    get passwordInput(): Locator {
        return this.page.getByRole('textbox', { name: 'Password' });
    }
    get signInButton(): Locator {
        return this.page.getByRole('button', { name: 'Sign in' });
    }

    /**
     * Logs in the user.
     */
    async logIn(email: string, password: string): Promise<void> {
        await this.navigateToSignInPage();
        await this.emailInput.fill(email);
        await this.passwordInput.fill(password);
        await this.signInButton.click();
        await expect(
            this.page.getByRole('navigation').getByText(process.env.USER_NAME!)
        ).toBeVisible();
    }

    // ... other methods like navigateToSignInPage(), logOut(), etc.
}

Step 3: Compose the HomePage with the NavPage Mixin

Now for the magic. We create our HomePage object, which is responsible only for elements unique to the home page. Then, we use our applyMixins helper to blend in the NavPage functionality.

TypeScript

// pages/clientSite/homePage.ts

import { Page, Locator, expect } from '@playwright/test';
import { applyMixins } from '../../helpers/mixin';
import { NavPage } from './baseClasses/navPage';

/**
 * This is the page object for the Home Page.
 */
export class HomePage {
    constructor(protected page: Page) {}

    get homeBanner(): Locator {
        return this.page.getByRole('heading', { name: 'conduit' });
    }
    get yourFeedBtn(): Locator {
        return this.page.getByText('Your Feed');
    }

    /**
     * Navigates to the home page as Guest.
     */
    async navigateToHomePageGuest(): Promise<void> {
        await this.page.goto(process.env.URL as string);
        await expect(this.homeBanner).toBeVisible();
    }
}

/**
 * Interface declaration that tells TypeScript that HomePage
 * also has all the methods and properties from NavPage.
 * This enables IntelliSense and type checking.
 */
export interface HomePage extends NavPage {}

/**
 * Apply the mixin at runtime.
 * This actually copies all NavPage methods to HomePage's prototype.
 */
applyMixins(HomePage, [NavPage]);

Notice two key parts here:

1. export interface HomePage extends NavPage {}: This is crucial for TypeScript's type-checking. It tells the compiler, "Trust me, an instance of HomePage will also have all the methods of NavPage", giving us that sweet, sweet IntelliSense autocompletion.

2. applyMixins(HomePage, [NavPage]): This is the runtime execution. It takes all the methods from NavPage and attaches them to HomePage. If you want to attach methods from more than one baseClass, you can list them in the array.

Step 4: Use the Composed Page Object in a Test

Finally, let's see it in action. In our test file, we can instantiate HomePage and call methods from NavPage directly on it, like logIn().

TypeScript

// tests/auth.setup.ts

import { test as setup } from '../fixtures/pom/test-options';

setup('auth user', async ({ homePage, page }) => {
    await setup.step('create logged in user session', async () => {
        await homePage.navigateToHomePageGuest();

        // Calling a method from NavPage on a HomePage instance!
        await homePage.logIn(process.env.EMAIL!, process.env.PASSWORD!);

        await page.context().storageState({ path: '.auth/userSession.json' });
    });
});

It just works! Our HomePage is clean and focused, yet it has all the power of the navigation functionality when needed.

A Note on Potential Downsides

While powerful, this pattern has trade-offs. The main one is the potential for method name collisions. If you mix in two classes that both define a method called clickSubmit(), the last one applied will overwrite the previous ones. Additionally, it can sometimes be less obvious where a method originates compared to a clear extends chain.

Summary

By embracing a composition over inheritance mindset with the Mixin pattern, you can build a far more flexible, modular, and maintainable Playwright test automation framework.

Your Page Objects become cleaner, your code becomes more reusable, and you avoid the architectural headache of the monolithic BasePage. This approach better mirrors modern, component-based web development and leads to a more robust and scalable test suite.

This isn't just a philosophical discussion. This is a practical guide to Phase 1: Culture, Roles, and Mindset. We'll break down each foundational principle and give you a clear framework for what it is, why it's a non-negotiable part of success, and how you can actually implement it with your team, starting today.

A Shared Definition of "Quality"

• WHAT it is: A shared definition of quality is a clear, explicit agreement across the entire team (product, design, development, and QA) on the specific attributes that make your product "good". It’s a consensus on the target you are all aiming for.

• WHY it matters: Without a shared definition, everyone operates on assumptions. A developer might define quality as "bug-free, performant code". A product manager might see it as "shipping features that meet business goals". When these definitions clash, you get chaos and a product that excels at nothing. A shared definition aligns everyone's efforts toward the same outcome.

• HOW to create it: Run a "Quality Definition" workshop. Get everyone in a room and ask probing questions:

  1. For our customers, what does quality feel like? Is it speed? Reliability? Ease of use? Security?

  2. Who are our main competitors, and what is their quality bar? Where must we be better?

  3. Write down the results. List the top 3-5 attributes that are a must for your product and post them visibly for the whole team.

Quality is Everyone's Responsibility

• WHAT it is: This is the principle that quality is not the job of a single department ("QA team"). Instead, it is a core competency and a daily responsibility for every single person involved in building the product.

• WHY it matters: When quality is siloed, it becomes a gate at the end of the process. This creates an "us vs. them" mentality, where developers "throw code over the wall" for QAs to "catch the bugs". This is incredibly inefficient, as issues are found far too late. Shared responsibility makes quality an ongoing activity, not a final inspection.

• HOW to implement it:

  • Integrate quality into rituals. During sprint planning, ask "How will we ensure this story is high-quality?" not just "How long will it take?"

  • Eliminate the "Ready for QA" column. Treat quality as a continuous conversation where developers and QAs collaborate throughout the development of a feature.

  • Share quality metrics with everyone. Make bug counts, performance data, and uptime visible to the entire team. What gets measured and seen gets improved.

Psychological Safety

• WHAT it is: Psychological safety is a shared belief that team members can take interpersonal risks without fear of being punished or humiliated. It's the confidence to speak up, ask questions, admit mistakes, or challenge the status quo.

• WHY it matters: This is the bedrock of a healthy culture. Without it, you are just gambling. Team members will hide mistakes and stay silent about risks. This silence is where bugs, security vulnerabilities, and bad architectural decisions are born. Psychological safety turns silence into valuable information.

• HOW to build it: This is primarily the leader's responsibility.

  • Model vulnerability. Acknowledge your own mistakes. "I was wrong about that assumption" is one of the most powerful things a leader can say.

  • Treat questions as a gift. When someone asks a "dumb" question, thank them. It's likely others had the same question but were afraid to ask.

  • Focus on the process, not the person. When a mistake happens, ask "How can we prevent this in the future?" not "Why did you do that?"

Visible Leadership Buy-In

• WHAT it is: This is tangible, consistent proof from leadership that quality is a top-tier business priority, not just a talking point. It’s action, not just words.

• WHY it matters: Teams take their cues from leadership. If a leader says quality is important but then consistently pushes the team to cut corners to meet a deadline, the message is clear - speed matters more. Visible buy-in empowers teams to do the right thing.

• HOW to spot it (and do it):

  • Budgeting: Leaders allocate time and money to address technical debt. They approve the purchase of better tools and training.

  • Prioritization: When a critical bug is found, they prioritize fixing it over starting the next new feature.

  • Reinforcement: They publicly praise teams for a smooth, high-quality release, not just for shipping a feature fast. They back the QA's decision when a serious risk is flagged.

The Blameless Retrospective

• WHAT it is: A structured meeting following an incident (like a production outage) where the entire focus is on understanding the systemic causes and improving the process. Blame is never the objective.

• WHY it matters: A culture of blame stimulates hiding the truth. If people are afraid of punishment, they will never be fully transparent about what happened. Blamelessness creates an environment where the team can dissect a failure honestly to find the root cause and ensure it never happens again.

• HOW to run it:

  • Have a neutral facilitator. This person's job is to keep the conversation focused on the process.

  • Ask "how," not "who." The guiding question is always, "How did our process allow this to happen?"

  • Focus on actionable system improvements. The output should be things like "Add a new CI check" or "Improve our deployment runbook," not "Dave needs to be more careful".

Redefining the QA Role: From Gatekeeper to Coach

• WHAT it is: The evolution of a Quality Assurance professional from a "bug finder" at the end of the line to a "quality coach" and advocate embedded within the team from the very beginning.

• WHY it matters: Finding bugs late is expensive. The gatekeeper model creates bottlenecks and an competitive relationship. A coaching model prevents entire classes of bugs from ever being written by clarifying requirements and identifying risks upfront. It is proactive, not reactive.

• HOW to make the shift:

  • Get QAs in the room, early. QAs must be part of initial planning and "Three Amigos" sessions to ask probing questions before a line of code is written.

  • Focus on enablement. The QA's job is to enable developers to test better by championing best practices, maintaining test infrastructure, and pairing with them.

  • Change the metrics. Success isn't "bugs found." It's "preventing bugs" and "increasing team confidence in the release".

Defining the Developer's Role: True Ownership

• WHAT it is: This is the principle that developers are the primary owners of the quality of their own code. The QA role is a partnership, not a safety net for sloppy work.

• WHY it matters: The person writing the code has the most context to build quality in from the start. Relying on an external check creates a diffusion of responsibility. When developers own quality, they write more resilient, maintainable, and well-tested code.

• HOW to foster it:

  • Go beyond unit tests. Ownership includes writing good logs, considering edge cases, and ensuring code is clean and maintainable.

  • Implement Pair Testing. Have a developer and QA test a feature together. This builds empathy and creates a powerful, immediate feedback loop.

  • Make quality part of code reviews. Reviews should check for more than just style. They should ask "Is this functionality robust? Is it well-tested?"

Understanding the Domain In-Depth

• WHAT it is: This means the QA is not just an expert in testing techniques, but also a deep expert in the business domain, the product's features, and the customer's problems. They are the "glue" between business and technology.

• WHY it matters: You can't test what you don't understand. Deep domain knowledge allows a QA to identify risks that developers or product owners might miss. They can design tests that simulate real-world usage, not just technical correctness.

• HOW to develop it:

  • Be relentlessly curious. Research the biggest user pain points for a similar products.

  • Ask "why" five times. Understand the root business need behind every feature.

  • Become the user. Use your product regularly, trying to accomplish the same goals your customers do.

Establish Equal Authority

• WHAT it is: This means that the QA's voice and professional judgment on matters of quality risk carry the same weight as a developer's voice on technical implementation. It is a partnership of equals.

• WHY it matters: If there's a power imbalance, quality concerns will always be overruled by delivery pressure. The QA becomes the "little brother" whose warnings are ignored. This leads to a culture where known risks are accepted and shipped. Equal authority ensures a balanced decision-making process.

• HOW to achieve it:

  • Structurally: QA should report through the same management chain as development, not as a subordinate function.

  • In practice: In meetings, leaders must explicitly give equal speaking time and weight to QA perspectives. A developer shouldn't be able to merge code if the QA has raised a valid, blocking concern that hasn't been addressed.

Conclusion: The Groundwork is Laid

Quality Engineering is a mindset, not a role. By establishing this cultural foundation, you stop treating quality as an accident and start building it by design.

With this solid cultural foundation in place, you are no longer guessing about quality. You are ready to design it. The next step is to implement “Proactive Strategies for Pre-Development Success - Requirements, Stories & Planning” that prevents bugs before a single line of code is ever written.

Teams talk about "shifting left" and "quality culture," but these are just empty buzzwords without a plan. You wouldn't build a house by putting up the roof first, right? You start with a solid foundation, then the walls, then the roof, and after all that you continue with the systems inside. Building quality is no different.

This isn't just a roadmap for QAs. It's for every single person involved in building software who is tired of the cycle of shipping fast and breaking things.

Phase 1: Foundation (Culture, Roles & Mindset)

Everything starts here. You can hire the most expensive professionals and you can buy the most expensive tools, but if your culture is broken, you're just accelerating your ability to produce garbage. This phase is non-negotiable.

• A Shared Definition of "Quality": Before you write a line of code, the team must agree on what "quality" means for your product. Is it speed? Reliability? A bug-free UI? If everyone has a different definition, you're all aiming at different targets.

• Quality is Everyone's Responsibility: The "Whole Team" approach is the only way. Quality is not a department you send things to. It's a collective standard that everyone upholds.

• Psychological Safety: This is non-negotiable. Team members must feel safe to say, "I'm concerned about this," without fear of blame. Without this, you're blind to the biggest risks.

• Visible Leadership Buy-In: Leaders must actively champion quality. When they prioritize fixing tech debt over rushing a new feature, they show the team what truly matters.

• The Blameless Retrospective: When something goes wrong, the question is never "Who did this?" It's "How did our process allow this to happen?" Every mistake is a full team responsibility, and the goal is to remediate the system, not the person.

• Redefining the QA Role: The shift from gatekeeper to quality coach is critical. Stop finding bugs at the end. Start asking questions at the beginning. You are a quality advocate embedded in the team from day one.

• Defining the Developer's Role: Developers own the quality of their code. Period. This means writing clean, maintainable code and owning foundational testing like unit and integration tests. The QA role is not a safety net for sloppy work. By inspection you cannot improve quality, you can only characterize it.

• Understanding the Domain In-Depth: QAs are the glue between business and technology. They should actively breaking down siloes on the team.

• Establish Equal Authority between Devs and QAs: They need to be on equal footing, otherwise it is little brother telling big brother what they can and cannot do.

Phase 2: Pre-Development (Requirements, Estimation & Planning)

With a solid foundation, you can start drawing the blueprints. This is where you prevent entire classes of bugs before they are ever written.

• Crafting High-Quality, Testable User Stories: A story that is vague or untestable is a recipe for disaster. Teams must establish clear standards for what makes a story "ready for development."

• Defining Concrete Acceptance Criteria (ACs): Good ACs are explicit and binary—they either pass or fail. This removes ambiguity and ensures everyone is on the same page about what "done" means.

• Implementing "Three Amigos" Sessions: These can't be passive review meetings. Make them active working sessions. The goal is to leave with a shared understanding and clearly defined ACs, not just to pretend we accomplished something.

• Identifying Edge Cases & Negative Paths Upfront: This is a primary task for a QE. Your job is to think like a user who will do everything wrong. What happens with invalid input? What if the network fails? Answering these questions now saves days of rework later.

• Defining and Integrating Non-Functional Requirements (NFRs): Don't let performance, security, or accessibility be an afterthought. These NFRs must be discussed and integrated into user stories from the beginning.

• Risk-Based Prioritization of Quality Efforts: You can't test everything with the same depth. Use risk analysis to focus your efforts on the most critical and fragile parts of the application.

• Making Quality a Factor in Story Estimation: Quality isn't free. The effort for writing tests, pairing, and exploratory testing must be included in story points. It's a bad practice to miss this, as it just hides the true cost of work.

• Early Test Data & Environment Planning: Before a single line of code is written, you should be asking, "How are we going to test this?" This means planning for the necessary test data and environment access upfront.

Phase 3: In-Development (In-Sprint Quality)

This is the construction phase. Quality is built-in, not bolted on. These items are the engine of in-sprint quality.

• A Fast and Reliable Continuous Integration (CI) Pipeline: Every commit should trigger an automated build and a fast set of tests. This provides immediate feedback and prevents integration hell.

• Enforced Code Quality Standards & Static Analysis: Use automated tools like linters and static analysis to catch bugs and style issues before they ever reach a human reviewer. This is your first line of automated defense.

• Mandatory, Effective Peer Reviews (Pull Requests): Code reviews are not just for finding bugs. They are for sharing knowledge, ensuring maintainability, and upholding team standards. Make them mandatory and constructive.

• In-Sprint Dev-QA Collaboration & Pairing: This is a game-changer. Pair-testing—a dev and QA working together on a feature—creates an immediate feedback loop and demolishes the "us vs. them" wall. It is extremely helpful.

• Early and Continuous Exploratory Testing: As soon as a piece of a feature is usable, a QA should be exploring it. This is creative, human-driven testing that finds the bugs automation will always miss.

• Definition of "Ready for QA/Review": This should be part of your Definition of Done. It's a simple checklist that prevents friction and ensures smooth handoffs.

Phase 4: Formal Testing & Automation

Notice how late this phase is? Building automation on a broken process is a waste of money. Only with the other phases in place you can build a strategy that provides real value.

• Implementing the End-to-End (E2E) Testing Strategy: Don't try to automate everything. Focus E2E tests on the most critical user journeys that provide the highest value.

• Building a Scalable & Maintainable Automation Framework: The two silent killers of any automation effort are bad architecture and poor test data management. I use Playwright with TS and the Page Object Model, but the tool is less important than the principles of clean, maintainable design.

• A Stable & Consistent Test Environment Strategy: A flaky test environment makes your test results meaningless. The environment must be reliable and as production-like as possible.

• Robust Test Data Management: If you spend more time managing test data than writing tests, your strategy has failed. You need a clear, repeatable process for getting the data you need.

• Integrating Automation into the CI/CD Pipeline: Strategically run your tests. Run quick smoke tests on every PR, a larger regression suite on every merge to main, and full E2E runs before a release.

• Defining a Performance Testing Baseline: You don't need a massive performance team to start. Run baseline load tests on critical user flows to ensure you don't introduce major regressions.

• Implementing a Basic Security Testing Checklist: Integrate automated security scans (SAST/DAST) into your pipeline to catch common vulnerabilities early.

• Cross-Browser & Cross-Device Testing Strategy: Define what browsers and devices you officially support and have a clear strategy for ensuring a consistent experience across them.

Phase 5: Release & Post-Release

Your job isn't done when the feature ships. The ultimate measure of quality is how your product behaves in the hands of real users.

• A Staged Rollout Strategy: Minimize risk with canary releases or blue-green deployments. Roll out new features to a small percentage of users first to ensure stability before a full release.

• Comprehensive Production Monitoring & Alerting: This is your product's insurance. It should tell you there's a problem long before a customer does.

• Effective Log Management & Analysis: When an issue occurs, structured, searchable logs are your best tool for rapid root cause analysis.

• User-Facing Feedback Channels: Make it easy for users to tell you when something is wrong. An in-app feedback form or a dedicated channel is a direct line to the user experience.

• A Culture of Continuous Improvement: Use all the data from production—monitoring alerts, user feedback, performance metrics—to feed back into the development process.

Conclusion

Quality Engineering is a mindset, not a role. For a proper implementation in the software development lifecycle, we, as QEs, must follow best practices and improve the process step-by-step as we spread the values and benefits of it.

And if you're at a startup thinking, "This is too slow and heavy for us" let me ask you a simple question.

You created this startup to win in the market, right? If you put garbage in the market, you will receive the same from it.

Preface

One side hustle of mine is Investing. Initially, I was fascinated by it’s THEORY and PSYCHOLOGY. One of the most famous quotes in the field is: "The trend is your friend."

I absolutely belief that DELAYED GRATIFICATION is the path everyone should embrace. But…we are living in a world, where the latency of 3s, can drive us crazy. We want everything, here, now. We don’t want to sweat, we don’t want to work hard. Instead, we just want vacations, dopamine and a coctail - just for style. Familiar?

In every field there are so few people that actually succeed. No hard statistics, but probably 1 %. Why? Cuz they are just doing that 99% of the people refuse to do.

AI Coding <=> Investing

Let’s talk a bit for the elephant in the room. To be honest, we are all here for that, right?

I just want to add something about the TREND from the INVESTING stand point, because I am trying to make “bad” reference to AI CODING. Here's an explanation of what a TREND is - a direction in which something is developing or changing.

Trend Stages as Emotion

For quite some time, everyone has been milking the cow named AI CODING. There is nothing wrong with it, but as always, it is a trend, and it moves in waves.

On the surface, it is fantastic, but let’s not forget about the technical debt we bring to the table by using it.

Back a few weeks ago, when I stated that we are officially passed the EUPHORIA stage and we entered the ANXIETY one. I am using LLMs to learn, brainstorm and develop automation frameworks for more than 2 years, and as a QA I am always skeptical. I try to verify everything that is presented to me. Sometimes, the truth is well covered, and sometimes, it is actually denied. That’s why I do believe that the AI CODING has a dark side attached to it. I already mentioned the technical debt, but the bigger issues are that it ruins problem solving skills, critical thinking and actual collaboration between engineers. The worst part is that we start thinking we DO NOT need juniors. Are we thinking that current Mid and Senior Developers are enough to lead the Earth to greatness? Seriously?

LLMs in QA Field

I try many experiments with Playwright, it’s MCP server, different LLM’s, different IDEs and I can stated that all these tools are helpful. They limit the manual work that I have to do, and they speed my productivity (coding, test case preparation and writing documentation) 3-4 times. But….and there is a BIG BUT, this actually doesn’t speed releasing. It doesn’t speed releasing, because, as before these tools, I spend most of my time discusing requirements, technical implementation, bugs, features, etc.

Currently, I am using Cursor and claude-sonnet-4/chatGPT 5/gemini 2.5 pro as an LLMs, but I limit it in the following:

1. Tab autocompletion - this workflow gives me the opportunity to keep everything under control, but still improves my speed drastically.

2. Develop Factory and Helper fuctions - the LLMs are great in short, specific, one function tasks. You can describe your problem well enough, and someone on the world has already solve your exact problem. LLM’s job is just to find the right piece of code and provide it to you. Just like a few years back, but without manually grinding google and Stack Overflow.

3. Brainstorming Ideas - no doubt that LLMs are great partners in that.

4. Creating documentation about testing and coding - again no doubt that LLMs are great partners in that.

But what about all the hype about MCP servers giving context to the LLMs, Agentic tools for creating tests alone, and tools, that create test cases from natural language? All these things work only on POC/Demo sites. MARKETING SUGAR COATING.

Nothing of these works in actual Real-World Complex App in development, because the worst thing that can happen to an LLM is to change the context (aka change the requirements of already developed/tested feature). Just do it a few times, and watch the “Michelin Italian Chef” named ${your choosen LLM name} preparing a brilliant piece of spaghetti for you.

Conclusion

My current feeling is telling me that we already passed the ANXIETY phase and we are officialy in DENIAL phase of the wave. This absolute doesn’t mean that LLMs for coding is not helpful. We just start to realize their real value….and real COST.

Before fallin in the trap, ask your self one simple question. Is this an ORGANIC GROWTH or it is a BUBBLE?

Visual Representation of forming and bursting a bubble

If you are actually changing the World (doesn’t matter the World or your World) by the use of any LLM, don’t stop! Just be aware of PROS and CONS of it.

Below, you can find my notes and presentation, I used to prepare for my first Live Session. Hope you can find them helpful, since the lecture was held in Bulgarian.

Greetings

Hey friends! It's awesome to be here at SoftUni. Thanks for joining. We're going to talk about something I'm really passionate about today - building testing frameworks that people actually want to use.

The audience is from all levels, but my goal here isn't a boring lecture. I want to start a conversation and show you just how simple and elegant testing can be when you have the right tools and the right mindset.

Agenda

The Two Sides of an Application

Alright, let's start with the absolute basics. Every modern application you use, from a social media app to your online banking, has two main parts.

First, you've got the Front-End. That's the part you see and interact with. The buttons, the forms, the pretty charts. It’s the user interface.

Then, you've got the Back-End. This is the engine. The brain. It's where the real work happens—all the business logic, the calculations, talking to the database.

Communication Between the Two Sides

So how do they talk to each other? They use an API—an Application Programming Interface.

Based on user actions, the front-end makes a request, sends it to the back-end via API, then the back-end does the work and sends a response to the front-end again via API. Lastly, the front-end processes the response and visualize it to the customer.

Where and What Do The Bugs Hide?

Front-End vs Back-End Bug Distribution

The data can vary significatly due to different factors such as complexity, team maturity, domain, etc. but we can safely assume that the distribution is somewhere in the range of 70% FE vs 30% BE. And it is logical, because there is no such factors as User Environment, Front-End tech Stack, Interactive Natature of the FE, in the BE.

The Nature of Bugs: A Volume vs. Severity Profile

Despite the fact that most bugs are in the FE, the sevier ones can be found in the BE. And it makes sense! That’s where the complexity is. That's where data gets validated, where security is handled, where the core business rules are executed. A bug in the UI is an inconvenience. A bug in the API can be a catastrophe—data corruption, security vulnerabilities, you name it.

The above absolutely NOT means that UI bugs are not important - we all can agree that if the user is not satisfied by his experience, most probably he won’t return to our app.

The Escalating Cost of Bug Remediation by Development Stage

It's no secret that the later a bug is found, the more costly the remediation actions will be.

API Testing

API Theory

REST API communication is a Stateless Client-Server Communication, which means, every single request should contain the whole context.

These are the main components of an REST API Request and Response.

We will begin with these from the Request. Endpoint is a combination of Base Url and the Path of the resource, you are trying to interact with.

These are the most common Methods, used in REST API, responsible for CRUD (Create, Read, Update, Delete) operations.

The requst headers and body are used to specify what actions the User wants to perform - autorization and data.

The Status Code of the Response is always presented, and it can be used as a clear sign of the outcome. You can see on the image how the statuses are categorized.

In addition to the Response Status Code, you can find Response Headers, and optionally - Response Body. This is the message Server delivers to the Client.

The Importance

With testing the APIs, we can verify that it works functionally, it is fully integrated in the system, it covers the security standarts, that are set and that the performance is acceptable.

The Power of a Unified Tool

Okay, so when you hear 'Playwright', you probably think of UI testing. Automating a browser, clicking buttons, filling forms... and you're right, it is absolutely world-class at that.

But its real power, the thing that changes the game, is using it as a single, unified tool for your entire testing suite. UI and API, together.

Why is that such a big deal? Four reasons.

Reliability and Speed

First, Reliability and Speed. Playwright enhances test reliability by incorporating auto-waiting mechanisms that ensure actions are only performed when elements are stable, which drastically reduces flaky failures common in other frameworks. By leveraging a modern architecture that allows for test parallelization across multiple browser contexts, Playwright achieves remarkable execution speed, significantly cutting down the time for running extensive regression suites.

CI/CD Simplification

Second, CI/CD Simplification. If you use different tools for front-end and back-end testing, your deployment pipeline gets complicated. Two sets of dependencies, two test runners, two reporting formats. With Playwright for everything, it's one process. One command to run all your tests. One beautiful, consolidated report. Your pipeline becomes simpler, faster, and way easier to maintain.

Seamless End-to-End Testing

Third, Seamless End-to-End Testing. This is where it gets really cool. Imagine a single test that does this

• Step 1: Create a new user by sending a POST request directly to your API. It's fast and reliable.

• Step 2: In the very next line of code, use the browser to log in as that new user through the UI.

• Step 3: Verify their dashboard looks correct.

Developer Experience

Last, but not least, this is for those of you who've built testing frameworks before... we're going to solve the biggest challenge of all: Developer Experience, or DX.

It's not enough for a framework to just work. It has to be a joy to use. Today, we're going to build a custom API fixture that makes writing API tests almost effortless. It will be clean, readable, and type-safe. This is the secret to getting your whole team to write more, better tests.

Developing Playwright Framework for REST API Testing

Finally, we can start with the “interesting” part of the session. As prerequisites. you will need:

1. The Materials - GitHub Link

2. IDE - Cursor (Windsurf, VS Code)

3. Application Under Test (AUT) - Demo App

4. The Final Repo - GitHub Link

So, using Playwright to make a simple API call is easy. You can find that in the docs. But that doesn't scale to a real project with dozens of developers and thousands of tests.

To do this right, you need a scalable and maintainable framework. And the whole point of a good framework is to make the right way to write tests the easy way.

Developer Experience (DX)

Let’s start from improving DX, cuz we can do it before even we initialized our Playwright framework. You can see on the slide why it is important and how can we improve it.

Next task is to build an Abstraction Layer for our API calls.

On the left hand side you can see our plaun-function.ts - a function that receives input parameters and outputs only what we need. And it is doing it in unified way.

On the right hand side you can see our types.ts - a file with all types, which are needed to make TypeScript happy.

The logical next step is to talk about Fixtures in Playwright and how powerful they are.

Implementing Fixtures is quite easy - on the left hand side you can see how we extend the test base with our custom fixture.

On the right hand side it is an optional step, which I am showing, because it is used to merge all separate Custom Fixtures in one.

Last, but not least, we should cover Zod - TypeScript-first validation library.

Live Demostration how the Framework is Developed with Examples

After cloning the initial repo, there is a step-by-step checklist in README.md, that will guide you in the process. If you want, you can jump straight into the final code.

Closing Notes

I really hope that the following notes are helpful to you. As always, if there are any question, please let me know in LinkedIn. I will gladly try to answer to them.

You can find the recording of the session in YouTube. Just keep in mind that it is in Bulgarian.

What if there was a way to build your test suites like engineers build fantastic, scalable applications?

There are a few, and one of them is called Object-Oriented Programming (OOP). This article is your guide to understanding OOP principles and applying them in TypeScript to write clean, powerful, and maintainable automated tests.

🤔 What is Object-Oriented Programming?

At its core, OOP is a way of thinking about and organizing code. Instead of writing long, procedural scripts, you structure your code around objects.

Think of it like using LEGOs. You have different types of bricks (blueprints, or Classes in OOP) that you can use to build specific things (structures, or Objects). Each object has its own properties (like color) and things it can do (like connect to other bricks).

For QA automation, this means we stop thinking in terms of individual lines of code and start thinking in terms of application components, like a LoginPage object or a User object. This shift makes our test automation scalable, reusable, and much easier to maintain.

🏛️ The Four Pillars of OOP in Test Automation

OOP stands on four main pillars. Let's break down each one with a practical example from the world of QA.

1. Encapsulation (📦): Bundling Data and Actions

Encapsulation means bundling the data (variables) and the methods (functions) that operate on that data into a single unit, or "object." It also means hiding the object's internal state from the outside.

In QA Terms: Imagine a login page. It has UI elements (username field, password field, login button) and actions you can perform (entering text, clicking the button). Encapsulation means we create a LoginPage class that bundles the locators for those elements and the methods to interact with them.

If a locator changes, you only have to update it in one place: the LoginPage class. Your actual test script doesn't need to change at all!

class LoginPage {
  // Data (locators) are kept private
  private readonly usernameInput = '#username';
  private readonly passwordInput = '#password';
  private readonly loginButton = '#login-btn';

  // Methods (actions) are public
  public enterUsername(username: string) {
    // Code to find element and type text
    console.log(`Typing '${username}' into ${this.usernameInput}`);
  }

  public enterPassword(password: string) {
    // Code to find element and type text
    console.log(`Typing password into ${this.passwordInput}`);
  }

  public clickLogin() {
    // Code to find element and click
    console.log(`Clicking ${this.loginButton}`);
  }
}

2. Inheritance (🧬): Reusing Common Code

Inheritance allows you to create a new class (a "child") that inherits properties and methods from an existing class (a "parent"). This promotes code reuse.

In QA Terms: Most pages in an application share common elements, like a header, a footer, or a navigation menu. Instead of re-writing the code for these elements on every single page object, we can create a BasePage and have other pages inherit from it.

// Parent Class
class BasePage {
  public getFooterText(): string {
    // Code to find footer element and get its text
    return "Copyright 2025 Intelligent Quality";
  }
}

// Child Classes
class HomePage extends BasePage {
  public getWelcomeMessage(): string {
    return "Welcome to our blog!";
  }
}

class ProfilePage extends BasePage {
  public getUsername(): string {
    return "Ivan Davidov";
  }
}

// Now, both HomePage and ProfilePage have access to getFooterText()!
const homePage = new HomePage();
console.log(homePage.getFooterText()); // Outputs: "Copyright 2025 Intelligent Quality"
const profilePage = new HomePage();
console.log(profilePage.getFooterText()); // Outputs: "Copyright 2025 Intelligent Quality"

3. Abstraction (☁️): Hiding Complexity

Abstraction means hiding the complex implementation details and showing only the essential features to the user. It simplifies a complex system by modeling classes appropriate to the problem.

In QA Terms: Your test script should be simple and readable. It should describe what the test is doing, not how it's doing it.

We can create a high-level method like login() inside our LoginPage class. This one method will handle all the smaller steps: finding the username field, typing, finding the password field, typing, and clicking the login button. The test itself just needs to make a single, clear call.

// Let's add a high-level method to our LoginPage class
class LoginPage {
  // ... previous private locators

  public enterUsername(username: string) { /* ... */ }
  public enterPassword(password: string) { /* ... */ }
  public clickLogin() { /* ... */ }

  // Abstraction in action!
  public login(username: string, password: string) {
    this.enterUsername(username);
    this.enterPassword(password);
    this.clickLogin();
  }
}

// Now, look how clean the test file is:
// In login.test.ts
const loginPage = new LoginPage();
loginPage.login("admin", "password"); // One line, super readable!

4. Polymorphism (🎭): One Action, Many Forms

Polymorphism allows a single action or method to be performed in different ways, depending on the object it is being performed on. The name literally means "many forms."

In QA Terms: This is a more advanced concept, but imagine you have different types of users in your system (e.g., GuestUser, PaidUser) and you want to run a test that searches for an item. The search results page might look different for each user type.

With polymorphism, you could have a single search() function that correctly handles the results verification for whatever user type is currently logged in. To achieve this, we’ll define a common "contract" with an interface.

interface User {
  verifySearchResults(): void;
}

class GuestUser implements User {
  public verifySearchResults() {
    console.log("Verifying search results with 'Sign Up' banner...");
  }
}

class PaidUser implements User {
  public verifySearchResults() {
    console.log("Verifying search results with NO banner...");
  }
}

// Your test can work with any user that fits the IUser interface
function runSearchTest(user: User) {
  // ... code to perform search ...
  user.verifySearchResults(); // This will call the correct method
}

🧩 Putting It All Together: The Page Object Model (POM)

If you've heard of a design pattern called the Page Object Model (POM), you've seen a perfect application of OOP principles.

• Encapsulation: POM uses classes to represent pages, bundling locators and user interactions.

• Abstraction: Tests become clean, calling high-level methods like loginPage.login() instead of low-level browser commands.

• Inheritance: A BasePage is often used to handle common headers, footers, and other shared functionalities.

• Polymorphism: A single test function, like verifySearchResults(), can be written to work with different user types (e.g., GuestUser, PaidUser), where each type handles the verification in its own specific way.

POM is the industry-standard result of applying OOP to test automation, leading to a robust and maintainable framework.

✅❌ Pros and Cons of OOP in Automation

OOP is powerful, but it's important to have a balanced view.

Pros

• ✨ Maintainability: Code is far easier to update. Change a button's ID? You only edit one line in its page class.

• ♻️ Reusability: Share code across tests with inheritance and utility classes, saving time and reducing duplication.

• 📈 Scalability: Your test suite can grow to hundreds or thousands of tests without becoming a tangled mess.

• 👓 Readability: Test cases read like a list of user actions, making them easy for anyone (even non-technical stakeholders) to understand.

Cons

• ⏳ Initial Overhead: Setting up a proper OOP framework takes more time upfront than writing a simple script.

• 🧠 Learning Curve: It requires a solid understanding of these concepts, which can be a hurdle for those new to programming.

• 🚨 Risk of Over-Engineering: For a tiny project, a full-blown OOP framework can be overkill. It's also possible to create anti-patterns like "God Objects"—a single, massive page object that tries to do everything, defeating the purpose of clean separation.

🚀 Your Path Forward

For manual testers and junior QAs, learning Object-Oriented Programming is not just an academic exercise. Instead this is a fundamental step toward becoming a highly effective automation engineer. It's the difference between writing disposable scripts and building a professional-grade, long-lasting test automation framework.

🙏🏻 Thank you for reading! Building robust, scalable automation frameworks is a journey best taken together. If you found this article helpful, consider joining a growing community of QA professionals 🚀 who are passionate about mastering modern testing.

Join the community and get the latest articles and tips by signing up for the newsletter.

💡Significant achievements are rarely solo efforts. The ultimate skill for bringing great work to fruition is Collaboration, fueled by its essential prerequisite: Empathy.

Why Are Collaboration & Empathy So Important❓

🤖 Grounding AI in Human Needs:

AI can optimize a system, but it can't understand a user's frustration or a stakeholder's dream. Empathy—the ability to understand and share the feelings of others—is what ensures the solutions we build with technology are human-centric and truly valuable.

🧠 Building High-Performing Teams:

Collaboration is more than just working in a group—it's about creating synergy where the collective output is greater than the sum of its parts. This is only possible in an environment of trust, respect, and mutual understanding, all of which are built on empathy.

🛠️ Creating Better Products and Solutions:

When you can empathize with your end-users, you build products they love. When you can empathize with your colleagues (developers, designers, marketers), you create a smoother workflow and solve problems more effectively.

🧪 Why Collaboration & Empathy are Core Skills for QA Engineers

The stereotype of the lone, adversarial tester is obsolete. Modern QA is a deeply collaborative and empathetic role.

• 🕵️‍♂️ Building a Bridge with Developers: An empathetic QA engineer doesn't just "throw a bug report over the wall." They collaborate with developers, providing clear information and working together to find the root cause, framing it as a shared goal for quality.

• 🧩 Championing the User's Perspective: Empathy is a QA engineer's most powerful tool. They must constantly put themselves in the user's shoes, asking, "How would a user feel if this happened? Is this experience confusing, frustrating, or delightful?"

• 🧭 Negotiating with Product Owners: When a bug is found, a QA engineer collaborates with the product owner to assess its impact. They use empathy to understand business pressures while clearly advocating for the user's experience.

• 🤖 Fostering a Culture of Quality: Great QA professionals understand that quality is everyone's responsibility. They collaborate across the entire team to build quality into the process from the start, rather than just inspecting for it at the end.

🧑‍💻 How is this skill applied in other IT jobs?

• Backend Developers: They must collaborate effectively with frontend developers to design and agree upon robust API contracts. Empathy for the frontend team's needs ensures they build APIs that are easy to consume and efficient.

• UX Designers: Their entire role is founded on empathy for the user. They conduct research to deeply understand user needs and pain points. They then collaborate closely with developers to ensure the final product is not only beautiful but also technically feasible and intuitive.

• Product Managers: They are collaboration hubs. They must empathize with the perspectives of customers, engineers, designers, and business stakeholders to prioritize features and guide the product in a way that balances all competing needs.

• DevOps Engineers: They build bridges between development and operations. They must empathize with developers' need for speed and autonomy, while also collaborating with them to implement the security and stability controls that operations requires.

🏫 How Can Schools Teach This Skill❓

• 💡 Emphasize True Group Projects: Design projects where success depends on genuine collaboration, with shared goals and individual accountability. This teaches compromise, communication, and shared responsibility.

• 🗣️ Teach Perspective-Taking: In history and literature, ask students to write from the perspective of different characters or historical figures. In civics, hold debates where students must argue for a viewpoint they disagree with.

• 🛡️ Encourage Community Service: Engaging with the wider community exposes students to different life experiences and fosters a deeper sense of empathy for others.

• 🤝 Practice Peer Feedback: Create a structured and supportive process for students to give and receive feedback. This teaches them to critique an idea constructively while respecting the person behind it.

Technology is About People 🚀

In the final analysis, we build technology to serve people. In an era increasingly dominated by algorithms and automation, our most enduring and uniquely human skills will be our ability to understand, connect with, and work alongside each other.

"If you want to go fast, go alone. If you want to go far, go together." — African Proverb

🙏🏻 Thank you for reading! Building robust, scalable automation frameworks is a journey best taken together. If you found this article helpful, consider joining a growing community of QA professionals 🚀 who are passionate about mastering modern testing.

Join the community and get the latest articles and tips by signing up for the newsletter.

My story isn't just about changing jobs. It's about the relentless pursuit of finding work that I can be proud of, and having the freedom to make a real impact.

The core message I want to share is simple: follow your dreams and build a career that truly fulfills you.

🎓 The Foundation: A Civil Engineering Start

When I left high school, the choice was between Civil Engineering and Computer Science. I chose the tangible world of construction, enrolling at the University of Architecture, Civil Engineering and Geodesy. I dreamed of being part of real-world building projects.

The first few years were a slog of dry theory, and my focus wavered. By the third year, when we got into the practical, real-world stuff, everything clicked. My passion for engineering ignited, leading to a pivotal internship designing a Waste Water Treatment Plant (WWTP).

Things moved fast. Before the internship even ended, I had a full-time offer as a Junior WWTP Engineer. At 23, I was working a demanding job while simultaneously writing my Master's thesis—a complete design for a mock WWTP. Thanks to incredible mentors, I not only graduated at 24, but won an award for the best thesis project in WWTP field of the year.

📈 Climbing the Ladder: New Roles, New Responsibilities

My early career was a rapid ascent in the engineering world.

• At 25, WWTP Shift Team Lead: A sudden change threw me into leadership. I went from following orders to leading a team, a shocking but formative experience.

• At 27, Co-Lead Technology Engineer: My passion for design pulled me back. I joined a team to design and build a new WWTP, quickly getting promoted to Co-Lead.

• At 28, Lead Technology Engineer: After the success of the last project, I was appointed to lead the design of a new WWTP

• At 29, Project Portfolio Manager: I took on my biggest role yet, managing a portfolio of ecology projects worth over €100M as part of a major European program.

I had achieved a level of success many would envy. But a questions started to bubble up: Was I truly making a difference in the way I wanted to, and is that the life I want to live?

🔄 The Hardest and Smartest Choice: The Pivot to Tech

At 32, I realized I wasn't happy with my inability to influence the quality and processes around me. The engineering field felt rigid. I saw my friends in the IT industry building, innovating, and improving things with a freedom I craved.

I am the type of person who sits down one evening, reverse-engineers the goal, thinks of possible solutions, makes a choice, and sticks to it. So, I made the leap. The biggest challenge was a deep-seated fear that I couldn't achieve the same level of success I had in engineering. Starting over is daunting.

Since I had enough experience with learning new things and achieving success even when I wasn't 100% ready, I rolled up my sleeves and started from scratch, landing my first tech job as a Manual QA in the highly regulated pharmaceutical software space. It was the perfect place to learn the fundamentals.

⚙️ How Engineering Made Me a Better Tech Professional

My background wasn't a detour; it was a launchpad. The skills I'd honed for a decade were directly transferable and became my secret weapon in tech:

• Systems Thinking: Designing a WWTP is about understanding a massive, interconnected system. Software architecture requires the exact same mindset.

• Complex Problem-Solving: Untangling complex engineering challenges prepared me for debugging intricate software issues.

• Collaboration: Working simultaneously with several project teams taught me how to help people around me, how to communicate my ideas, and how to ask the hard questions

• Project Management: Managing a €100M portfolio taught me how to handle timelines, budgets, and expectations—skills essential for leading any software project.

• Dealing with Regulations: My experience in compliant engineering fields gave me a huge advantage in the regulated world of pharmaceutical software.

🔥 Finding the Fire: The Freedom to Build and Improve

My pivot wasn't just about changing fields—it was about finding work that lit a fire inside me. At 33, an opportunity arose to become a Software Systems QA Owner. It was a demanding job, but my passion for automation kept me awake at nights. I was aware what I have to learn, so I can be ready when the time comes.

Soon after, at 34, I got the chance to lead the development of a testing framework from the ground up. This was it. While I loved the challenge of both civil and software engineering, tech gave me something crucial: the freedom to influence and elevate quality and process directly. I could finally architect solutions and see the immediate impact of my work.

💡 My Advice For Your Pivot

If you're in a non-tech field and dreaming of a change, ask yourself one tough question: Are you ready to pay the price before you get the rewards?

A career change means starting over. It means late nights studying, facing rejection, and battling the fear that you've made a mistake. But if you are willing to put in the work, the reward—a career you are genuinely proud of—is worth every bit of the struggle.

🤯 Here's What I Understand and Embrace

This journey has taught me some core truths that I now consider my guiding principles. They are in no specific order because every single one is as important as the others.

🤝 Nothing Meaningful is Achieved Alone

I know that I would not be where I am WITHOUT my Teachers, Mentors, and Teammates. Success is a team sport, and every achievement is built on a foundation of shared knowledge and support.

💪 There Are No Shortcuts

If you want a truly desirable outcome, you have to be willing to work hard for it. Lasting success doesn't come from cutting corners—it's earned through dedication and persistent effort.

⚖️ Understand the Price of Your Decisions

Every choice has a cost—a trade-off in time, energy, or opportunity. I believe we must understand the price we are going to pay for every decision we make to move forward wisely.

🦁 Have the Guts to Make Hard Decisions

Real growth requires courage. This means being able to make the hard decisions when necessary and, just as importantly, taking full responsibility for them.

⏳ It Is Never Too Late

Don't let your age or current path stop you. It is never too late to do what inspires you. I pivoted my entire career at 32, and it was the best professional choice I've ever made.

🏛️ Master the Fundamentals

The fundamentals in every field are not just fancy theory you can skip. They are the absolute bedrock upon which all advanced skills and true understanding are built.

🚀 Growth Requires Discomfort

To grow as a professional, you must take opportunities you are not 100% ready for. It’s in that space of challenge and slight uncertainty that the most profound learning happens.

🧑‍🏫 Leverage Your Potential by Teaching

The best way to solidify your own expertise is to help and teach others. Lifting up your colleagues reinforces your knowledge and makes the entire team stronger.

🌟 Strive for a Career Worth Sharing

Aim to build more than just a resume. Build a professional story of passion, impact, and growth—a journey that you would be proud to share with others as a source of inspiration.

🧠 Stay Humble and Curious

No matter how much you learn or achieve, the journey is never over. I strive to stay Humble enough to know there's always more to learn, and Curious enough to actively seek that knowledge.

Final Thoughts

Today, I am still learning, still experimenting, and still driven by that same passion to build better solutions. My journey has been anything but linear, but every step, from concrete plants to code, has been essential in building a career I can truly call my own.

🙏🏻 Thank you for reading! Building robust, scalable automation frameworks is a journey best taken together. If you found this article helpful, consider joining a growing community of QA professionals 🚀 who are passionate about mastering modern testing.

Join the community and get the latest articles and tips by signing up for the newsletter.