Forem: idavidov13

REST API Testing: What Every QA Engineer Must Know

idavidov13 — Thu, 16 Apr 2026 12:18:51 +0000

Imagine this: you test a POST endpoint that creates a new user. It returns 201 Created. You mark the test as passed and move on. Two weeks later, production breaks - the response was missing a required field, a price came back as a string instead of a number, and nobody validated the response schema. Sound familiar?

REST API testing goes far beyond "send a request, check the status code". A solid API test verifies the method, the parameters, the payload, the status code, the response body, and the response structure. Miss any one of those, and bugs slip through.

This guide covers everything you need to test REST APIs thoroughly - from HTTP methods and payloads to status codes and schema validation. No tool-specific code, no fluff. Just the engineering fundamentals that apply everywhere.

🧭 What Is a REST API

Think of a REST API as a restaurant's ordering system. You (the client) send an order (a request) to the kitchen (the server). The kitchen processes it and sends back your food (the response). The menu defines what you can order (the endpoints), and the waiter gives you feedback on how it went (the status code).

REST (Representational State Transfer) is an architectural style where clients communicate with servers over HTTP. Every "thing" in the system - a user, an order, a product - is a resource, identified by a URL. You interact with resources using standard HTTP methods, and data travels back and forth as JSON.

That's it. Client sends a request, server sends a response. Everything we test revolves around this exchange.

📬 HTTP Methods - The Five Actions

Every API request starts with a method. The method tells the server what you want to do with a resource. There are five you'll use constantly.

Method	Purpose	Idempotent	Has Request Body
GET	Retrieve data	Yes	No
POST	Create a new resource	No	Yes
PUT	Replace an entire resource	Yes	Yes
PATCH	Partially update a resource	Usually*	Yes
DELETE	Remove a resource	Yes	Rarely

Idempotent means calling the same request multiple times produces the same result. A GET request for user #42 always returns user #42. A POST that creates an order will create a new one every time - that's why it's not idempotent.

*PATCH is typically idempotent, but not guaranteed. An operation like {"increment": 1} would add 1 every time you call it - that's non-idempotent. Always verify the specific API's behavior.

GET - Retrieves a resource without changing anything on the server. Think of it as reading a menu without placing an order.

Request:

GET /api/users/42

Response body (200 OK):

{
  "id": 42,
  "name": "Jane Smith",
  "email": "jane.smith@example.com",
  "role": "developer"
}

POST - Creates a new resource. You send the data, and the server assigns an ID and stores it.

Request:

POST /api/users

Request payload:

{
  "name": "John Doe",
  "email": "john.doe@example.com",
  "role": "tester"
}

Response body (201 Created):

{
  "id": 87,
  "name": "John Doe",
  "email": "john.doe@example.com",
  "role": "tester",
  "createdAt": "2026-04-16T10:30:00Z"
}

PUT vs PATCH - This is where most confusion happens. PUT replaces the entire resource. If you send a PUT without a required field, the API will most likely reject it with a 400 Bad Request. PATCH updates only the fields you include.

Request:

PUT /api/users/42

Request payload (full resource replacement):

{
  "name": "Jane Smith",
  "email": "jane.updated@example.com",
  "role": "developer"
}

Every field must be present. Miss a required field like role, and the API will either reject the request with 400 Bad Request or set the value to null - depending on the implementation. Both behaviors are worth testing.

Request:

PATCH /api/users/42

Request payload (partial update):

{
  "email": "jane.updated@example.com"
}

Only the email changes. Everything else stays untouched.

DELETE - Removes a resource. Usually returns 204 No Content with an empty body.

Request:

DELETE /api/users/42

Response: 204 No Content (empty body).

What to test for each method:

Happy path - Does the server return the correct success status code? (200 for GET, PUT, and PATCH, 201 for POST, 204 for DELETE)
Side effects - Did the operation actually happen? After a POST, can you GET the new resource? After a DELETE, does a GET return 404?
Response body - Does it contain all expected fields with correct values and types?
Missing or invalid data - Does a POST with a missing required field return 400? Does a PUT with the wrong data type return 400?
Non-existent resources - Does a GET, PUT, PATCH, or DELETE for an ID that doesn't exist return 404?
Authentication and authorization - Does the endpoint return 401 without a token and 403 with insufficient permissions?
Duplicate/conflict - Does a POST with data that already exists (e.g., a duplicate email) return 409 Conflict?
Method not supported - Does sending a DELETE to a read-only endpoint return 405?
Response headers - Does every response return Content-Type: application/json?

📨 Request Headers - The Metadata Layer

Headers are the metadata of your request. They travel alongside the URL and body, telling the server how to interpret the request, who you are, and what format you expect back.

Think of headers like the shipping label on a package. The package contents are your payload, but the label tells the courier where it's going, how fragile it is, and who sent it. Without the right label, even a perfect package won't reach its destination.

Headers every API tester should know:

Header	Purpose	Example Value
`Authorization`	Identifies who you are	`Bearer eyJhbGciOiJIUzI1NiIs...`
`Content-Type`	Tells the server what format you're sending	`application/json`
`Accept`	Tells the server what format you want back	`application/json`
`X-Request-ID`	Traces a request through distributed systems	`req-abc-123-def-456`
`Cache-Control`	Controls caching behavior	`no-cache`

Authorization patterns:

Most APIs use one of these authentication methods:

Bearer tokens - The most common pattern. You send a token in the Authorization header.

GET /api/users/me
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

API keys - Simpler but less secure. Often sent as a header or query parameter.

GET /api/products
X-API-Key: sk_live_abc123def456

What to test for headers:

Missing Authorization - Does the API return 401 Unauthorized when no token is provided?
Invalid token - Does an expired, malformed, or revoked token return 401?
Insufficient permissions - Does a valid token with wrong role return 403 Forbidden?
Wrong Content-Type - What happens when you send JSON but declare Content-Type: text/plain?
Missing Content-Type - Does the API assume JSON, reject the request, or crash?
Accept header mismatch - If you request Accept: application/xml but the API only supports JSON, what happens?

🔍 Query Parameters - Filtering, Sorting, Paging

Query parameters live in the URL after a ? sign. They don't change the resource - they change how you retrieve it. Think of them as filters in an online store: "Show me electronics, sorted by price, cheapest first, second page, 20 items per page."

GET /api/products?category=electronics&sort=price&order=asc&page=2&limit=20

This request says: "Give me electronics, sorted by price ascending, second page, 20 items per page."

A typical paginated response looks like this:

{
  "data": [
    { "id": 21, "name": "Wireless Mouse", "price": 29.99 },
    { "id": 22, "name": "USB-C Hub", "price": 34.99 }
  ],
  "pagination": {
    "page": 2,
    "limit": 20,
    "total": 47,
    "totalPages": 3,
    "hasNext": true,
    "hasPrevious": true
  }
}

When testing pagination, verify all these metadata fields - not just the items in data.

Common query parameter patterns:

Pattern	Example	Purpose
Filtering	`?status=active`	Return only matching items
Sorting	`?sort=createdAt&order=desc`	Control result order
Pagination	`?page=1&limit=25`	Return given page and Limit results per it
Searching	`?q=wireless+headphones`	Full-text search
Field selection	`?fields=id,name,price`	Return only specific fields

What to test:

Missing parameters - What happens when you omit page or limit? The API should use sensible defaults, not crash.
Invalid values - ?page=-1, ?limit=abc, ?sort=nonExistentField. Expect a 400 Bad Request, not a 500.
Boundary values - ?limit=0, ?limit=10000, ?page=999999. Does the API handle extremes gracefully?
Empty results - A valid filter that matches nothing should return an empty array with 200, not a 404.
Combinations - Test filters together. Does ?category=electronics&status=active return items that match both conditions?

📦 Request Payloads - What You Send Matters

The request payload (or body) is the data you send with POST, PUT, and PATCH requests. It's typically JSON, and it needs a Content-Type: application/json header so the server knows how to parse it.

A payload has a defined structure. Each field has a name, a data type, and constraints (required or optional, minimum/maximum length, allowed values). Here's a typical one:

{
  "name": "Wireless Headphones",
  "description": "Noise-cancelling over-ear headphones",
  "price": 149.99,
  "currency": "USD",
  "category": "electronics",
  "inStock": true,
  "tags": ["wireless", "noise-cancelling", "bluetooth"],
  "specifications": {
    "weight": "250g",
    "batteryLife": "30 hours",
    "connectivity": "Bluetooth 5.3"
  }
}

Notice the variety: strings, numbers, booleans, arrays, and objects. Each type needs different testing strategies. And that's exactly what the next section is about.

🧪 Testing Payload Parameters Like a QA Engineer

Sending a valid payload is the easy part. The real value of API testing comes from answering: what happens when the payload is wrong?

A systematic approach tests each field across multiple dimensions. Here's the framework.

Required vs Optional Fields

For every required field, test what happens when it's missing from the payload entirely. The API should return 400 Bad Request with a clear error message - not silently accept incomplete data.

{
  "description": "Missing the required 'name' field",
  "price": 29.99,
  "category": "electronics"
}

Expected: 400 Bad Request with a message like "name is required".

Data Type Violations

Send the wrong type for each field. A price should be a number - what happens when you send a string?

Field	Expected Type	Test With	Expected Result
`price`	number	`"free"`	400 Bad Request
`inStock`	boolean	`"yes"`	400 Bad Request
`tags`	array	`"single-tag"`	400 Bad Request
`name`	string	`12345`	400 Bad Request

Boundary Values

Every field with constraints has edges worth testing.

Test Case	Input	Expected Result
Empty string	`"name": ""`	400 (if name is required)
Minimum length	`"name": "A"`	Depends on min constraint
Maximum length	`"name": "A" × 256 chars`	400 if exceeds max
Negative number	`"price": -10`	400 (prices can't be negative)
Zero	`"price": 0`	Depends on business rules
Very large number	`"price": 999999999.99`	Depends on max constraint

Null, Empty, and Missing

These three are different, and many bugs hide in the distinction.

{ "name": null }
{ "name": "" }
{ }

A field set to null, a field set to an empty string, and a field that's absent entirely may all be handled differently by the API. Test all three.

Special Characters and Injection

What happens when you send <script>alert('xss')</script> as a name? The API should sanitize or reject these inputs, never execute them.

A secure API handles this in one of two ways.

Request payload:

{
  "name": "<script>alert('xss')</script>",
  "email": "test@example.com"
}

Response (rejection approach) - 400 Bad Request:

{
  "error": {
    "code": "INVALID_INPUT",
    "message": "Name contains invalid characters"
  }
}

Response (sanitization approach) - 201 Created:

{
  "id": 88,
  "name": "&lt;script&gt;alert('xss')&lt;/script&gt;",
  "email": "test@example.com"
}

Either response is acceptable. What's never acceptable is storing and returning the raw malicious input unchanged.

Field Interaction

Some fields depend on each other. If currency is required when price is present, test sending price without currency. If endDate must be after startDate, test sending them in reverse order.

The goal isn't to break the API for fun. It's to verify that the API protects itself - and its data - from every kind of invalid input.

🚦 Status Codes - The API's Way of Talking Back

If the request is what you say to the API, the status code is its body language. It tells you immediately whether things went well, whether you messed up, or whether the server had a problem.

Status codes are grouped into three families that matter for testing.

2xx - "Everything went well"

Code	Name	When It's Returned	What to Verify
200	OK	Successful GET, PUT, PATCH	Response body contains the expected data
201	Created	Successful POST	Response body contains the new resource with a server-assigned `id`
202	Accepted	Async operations (background jobs, batch processing)	Response confirms the request was accepted. May include a job ID or status URL for polling
204	No Content	Successful DELETE, or updates that return no body	Response body is empty. Don't try to parse it

The difference between 200 and 201 matters. A POST that returns 200 instead of 201 is technically working, but it's not following REST conventions - and that's a valid bug to report.

204 is the quiet confirmation. The API did what you asked but has nothing to say about it. After a DELETE, this is exactly what you want.

4xx - "You made a mistake"

These are client errors. The request was wrong in some way, and the server is telling you what happened.

Code	Name	Common Cause	Example Scenario
400	Bad Request	Malformed JSON, wrong data types, missing required fields	Sending `"price": "abc"` instead of a number
401	Unauthorized	Missing or invalid authentication token	Calling an endpoint without an `Authorization` header
403	Forbidden	Valid auth, but insufficient permissions	A regular user trying to access an admin-only endpoint
404	Not Found	Resource doesn't exist, or wrong URL	`GET /api/users/99999` when that user doesn't exist
405	Method Not Allowed	Using the wrong HTTP method	Sending a `DELETE` to an endpoint that only supports `GET`
409	Conflict	Resource state conflict	Creating a user with an email that already exists
429	Too Many Requests	Rate limit exceeded	Sending 100 requests per second to an endpoint limited to 10

The distinction between 401 and 403 is critical and often confused. 401 means "I don't know who you are" - provide credentials. 403 means "I know who you are, but you're not allowed to do this" - different credentials won't help unless you have a higher permission level.

What a good error response looks like:

A well-designed API returns structured error responses that help you understand exactly what went wrong.

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Request validation failed",
    "details": [
      { "field": "email", "message": "Invalid email format" },
      { "field": "price", "message": "Must be a positive number" }
    ]
  }
}

When testing errors, verify the response includes all three levels: a machine-readable code, a human-readable message, and field-level details when applicable.

What to test for 4xx codes:

Verify the response includes a meaningful error message, not just the status code
Check that error messages don't leak sensitive information (stack traces, database details, internal paths)
Confirm the server didn't partially process the request. A 400 on a creation endpoint should mean nothing was created
Verify field-level errors point to the correct field name

5xx - "The server broke"

These are server-side errors. The client did nothing wrong, but the server couldn't fulfill the request.

Code	Name	What It Means	Testing Angle
500	Internal Server Error	Unhandled exception on the server	This should never happen with valid input. If it does, that's a bug - report it with the exact request that triggered it
502	Bad Gateway	The server received an invalid response from an upstream service	Common in microservice architectures. Test when a dependency is down
503	Service Unavailable	Server is overloaded or under maintenance	May include a `Retry-After` header. Verify the API returns this during deployments or heavy load
504	Gateway Timeout	An upstream service took too long to respond	Similar to 502 but specifically about timing. Test with slow-responding dependencies

The golden rule for 5xx codes: a properly built API should never return 500 in response to any client input, no matter how bizarre. If you can trigger a 500 by sending unexpected data, that's a bug in the API's error handling. The server should catch internal errors and return an appropriate 4xx with a helpful message.

Here's a quick mental model for the full picture:

Family	Who's at fault?	Your reaction as a tester
2xx	Nobody - it worked	Verify the response body and schema
4xx	The client	Verify error messages are clear and no data was modified
5xx	The server	Report it - this is always a bug

🛡️ Schema Validation - The Safety Net You're Probably Missing

You've checked the status code. You've checked a few fields in the response. But have you checked the entire structure of the response?

Schema validation is like checking your order at a restaurant. The waiter brings your plate and smiles - that's your 200 OK. But do you just trust the smile?

You check that every dish you ordered is actually there, that the steak is steak and not chicken, that the side is fries and not salad, and that nothing extra ended up on the plate. Schema validation does exactly this for API responses.

Why status code alone isn't enough:

A 200 OK response that looks like this is a problem:

{
  "id": 42,
  "name": "Jane Smith",
  "email": null,
  "role": "developer",
  "salary": "85000"
}

The status code says "success," but email is null when it shouldn't be, and salary is a string instead of a number. Without schema validation, your test passes. With it, you catch the issue immediately.

What to validate in a response schema:

Check	What It Catches
Field presence	Missing fields that should always be there
Data types	A number returned as a string, a boolean as `"true"`
Required vs optional	A required field came back as `null` or was absent
Array structure	An array that should contain objects contains strings instead
Nested objects	A nested `address` object is missing the `zipCode` field
Enum values	A `status` field returns `"actve"` (typo) instead of `"active"`
Format	An `email` field contains `"not-an-email"`, a `date` field contains `"yesterday"`

JSON Schema in practice:

JSON Schema is a standard that lets you define exactly what a valid response looks like. Here's a schema for a user response:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "name", "email", "role"],
  "properties": {
    "id": {
      "type": "integer",
      "minimum": 1
    },
    "name": {
      "type": "string",
      "minLength": 1
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "role": {
      "type": "string",
      "enum": ["developer", "tester", "manager", "admin"]
    },
    "createdAt": {
      "type": "string",
      "format": "date-time"
    }
  },
  "additionalProperties": false
}

This schema enforces that id is a positive integer, name is a non-empty string, email follows an email format, role is one of four allowed values, and no unexpected fields are present. If the API returns anything that doesn't match, the validation fails - and your test catches it.

When schema validation saves you:

A developer adds a new field to the response but forgets to update the documentation. additionalProperties: false catches it.
A database migration changes a column type from integer to string. Your schema says "type": "integer" - caught.
A null value sneaks in because of a missing database join. The required array catches it.
An enum value is misspelled. The enum constraint catches it.

Schema validation doesn't replace field-level assertions. It complements them. Check the schema for structure, then assert specific values for business logic.

🗺️ Putting It All Together - The API Test Checklist

Here's the practical checklist you can use for every endpoint. Think of it as the minimum bar for thorough API test coverage.

For every endpoint, verify:

1. Method behavior

Does the endpoint respond to the correct HTTP method?
Does it return 405 Method Not Allowed for unsupported methods?
Is the operation idempotent where it should be?

2. Query parameters (GET endpoints)

Do filters return only matching results?
Do defaults apply when parameters are omitted?
Are invalid parameter values rejected with 400?
Does pagination work correctly at boundaries (first page, last page, beyond last page)?

3. Request payload (POST/PUT/PATCH)

Are required fields enforced?
Are data types validated?
Are boundary values handled correctly?
Is null/empty/missing treated appropriately for each field?
Are field dependencies enforced?

4. Status codes

Does the happy path return the correct 2xx code (not just "any 200")?
Does invalid input return the correct 4xx code with a clear error message?
Can you trigger a 5xx with any input? (If yes, report it - that's a bug)

5. Response body

Does the response contain all expected fields?
Are field values correct (not just present)?
Are related resources updated? (After POST, does GET return the new item?)

6. Schema validation

Does the response match the defined JSON Schema?
Are data types correct for every field?
Are required fields always present and non-null?
Are enum values within the allowed set?

This checklist applies regardless of your tool - whether you're using Postman, curl, Playwright, REST Assured, or any other framework. The principles are universal.

Ready to put this into practice? Implementing API Tests shows you how to build these concepts into a real Playwright test suite with fixtures and schema validation.

For a structured path through more QA engineering fundamentals, the Complete Roadmap to QA Automation & Engineering organizes everything by series and learning order.

🙏🏻 Thank you for reading!

Next time you write an API test, I hope this guide saves you from the "it returned 200, ship it" trap. Test the structure, test the edge cases, and validate that schema.

I Started a YouTube Channel - Here's Why

idavidov13 — Wed, 08 Apr 2026 11:28:19 +0000

After writing 30+ articles about Playwright and TypeScript, I always had the feeling that something was missing. The articles give you the patterns and the code - but the deeper explanations, the architectural reasoning, the "why behind the why" - that needed a different format.

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.

From Prompt to Passing Test: A Complete Agentic QA Session

idavidov13 — Wed, 25 Mar 2026 05:48:57 +0000

Sound familiar? In the first article, we set up a project scaffold designed for AI. But a good structure only gets you so far if the AI is just 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.

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

Explore First: Why the Agent Looks Before It Writes

idavidov13 — Fri, 20 Mar 2026 08:11:28 +0000

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

Skills: Domain Expertise on Demand

idavidov13 — Fri, 13 Mar 2026 06:11:57 +0000

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:

The rule: What the agent should do (or not do) in this area
The reasoning: Why the rule exists (helps the agent generalize)
Code examples: Correct and incorrect, clearly labeled
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

CLAUDE.md: Teaching the AI Your Rules

idavidov13 — Fri, 06 Mar 2026 06:03:57 +0000

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:

Change the file paths to match your actual folder names
Add your team's specific WON'Ts: the anti-patterns you've personally seen cause problems
Update the workflow if your project has a setup step or a specific CI check to run
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

What Is Agentic QA and Why It Changes Everything

idavidov13 — Wed, 04 Mar 2026 06:17:27 +0000

"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:

It receives a goal (create a test suite for the registration page)
It takes actions to gather information (reads files, navigates the browser)
It uses what it found to produce an output (generates the page object, Faker factory, test suite, etc.)
It verifies the output (runs the tests, checks for linting errors)
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

The Scaffold: Playwright Project Structure Built for AI

idavidov13 — Sun, 01 Mar 2026 06:38:01 +0000

Have you ever started a new Playwright project and spent the first two days just figuring out where things go? Where do selectors live? How do page objects get into tests? Where does test data belong?

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

The AI Shift: Why Specialized Models are the Next Wave for Tech Teams

idavidov13 — Thu, 13 Nov 2025 09:27:10 +0000

A Guide for Developers, QA, and Team Leaders on Moving Beyond General-Purpose AI

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:

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.
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.

Developing a Powerful Test Automation Strategy - Frameworks, CI/CD & E2E Tests

idavidov13 — Wed, 15 Oct 2025 06:11:28 +0000

We've built our feature on a solid foundation (Phase 1), with a clear blueprint (Phase 2), and with quality implemented in during construction (Phase 3). Now, it's time for the final, rigorous inspection before we open the doors to the public.

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.

Mastering In-Sprint Quality for Faster Releases - CI, Code Reviews & Collaboration

idavidov13 — Fri, 10 Oct 2025 12:04:49 +0000

We have our cultural foundation Essential Steps for Creating a Robust Software Quality Foundation - Culture, Roles & Mindset and our architectural blueprints Proactive Strategies for Pre-Development Success - Requirements, Stories & Planning. Now, it's time to pick up the tools and start building. Welcome to the construction site.

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.
- Schedule a short meeting: Book a 15-minute session once the developer has a working version of the feature.
- Dev demonstrates: The developer shares their screen and explains what they built and how it's implemented. This is a mini knowledge-transfer session.
- Test together: Both the dev and QA perform a few key tests together, discussing the results in real-time.
- 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.

Proactive Strategies for Pre-Development Success - Requirements, Stories & Planning

idavidov13 — Thu, 02 Oct 2025 05:17:55 +0000

In our previous article Essential Steps for Creating a Robust Software Quality Foundation - Culture, Roles & Mindset, we laid the cultural foundation for quality. We established that quality is a shared mindset, not just a department. But a strong foundation is useless without a solid plan. A nothing huge is built on hopes and good intentions. Instead it's built from a detailed architectural blueprint.

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.

Forem: idavidov13

REST API Testing: What Every QA Engineer Must Know

🧭 What Is a REST API

📬 HTTP Methods - The Five Actions

📨 Request Headers - The Metadata Layer

🔍 Query Parameters - Filtering, Sorting, Paging

📦 Request Payloads - What You Send Matters

🧪 Testing Payload Parameters Like a QA Engineer

🚦 Status Codes - The API's Way of Talking Back

🛡️ Schema Validation - The Safety Net You're Probably Missing

🗺️ Putting It All Together - The API Test Checklist

I Started a YouTube Channel - Here's Why

🎬 Why Video?

📺 What's on the Channel

🤝 Blog + Channel = The Full Picture

🚀 Come Along for the Ride

From Prompt to Passing Test: A Complete Agentic QA Session

🎬 The Scenario

🔄 What the Agent Does: Step by Step

👀 What You Review

🌱 Growing the Framework With AI

🎯 The Bigger Picture

🚀 Get Started

Explore First: Why the Agent Looks Before It Writes

🤔 What Is playwright-cli?

🗺️ The Explore-First Workflow

🧩 What the Agent Discovers Beyond Selectors

🔌 Exploration for APIs

⚠️ When Exploration Reveals Surprises

🧑‍💻 Your Role in the Explore-First Loop

Skills: Domain Expertise on Demand

🤔 What Is a Skill File?

🧠 Why Not Put Everything in CLAUDE.md?

📖 What's Inside a Skill File?

🔗 The common-tasks Skill

📝 Writing Your Own Skill Files

🔄 Skills as a Team Knowledge Base

CLAUDE.md: Teaching the AI Your Rules

🤔 What Is CLAUDE.md?

🏛️ The Constitution Pattern

✅ The MUST Rules

💡 The SHOULD Rules

🚫 The WON'T Rules

🗺️ The Workflow Section

📁 The Skills Index

✍️ Writing Your Own CLAUDE.md

What Is Agentic QA and Why It Changes Everything

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

🎯 Why Test Automation Is a Perfect Fit

🧠 The Mental Shift

🛠️ What Makes an Agent Reliable?

The Scaffold: Playwright Project Structure Built for AI

🤔 What Is a Scaffold?

🧱 What the Scaffold Gives You

🤖 But Here's the Real Point

🔌 Works With Your Tools

🐳 One Command to Start

The AI Shift: Why Specialized Models are the Next Wave for Tech Teams

🌊 The 5 Groups on the Adoption Curve

👑 The King is Dead: The Peak of Giant AI

🚀 Long Live the King: The Rise of Specialized AI

Why Specialized Models Win

🏄 How to Catch the Next Wave

💡 Your Next Move

Developing a Powerful Test Automation Strategy - Frameworks, CI/CD & E2E Tests

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

Building a Scalable & Maintainable Automation Framework

A Stable & Consistent Test Environment Strategy

Robust Test Data Management

Integrating Automation into the CI/CD Pipeline

Defining a Performance Testing Baseline

Implementing a Basic Security Testing Checklist

Cross-Browser & Cross-Device Testing Strategy

Conclusion: Building Unshakeable Confidence

Mastering In-Sprint Quality for Faster Releases - CI, Code Reviews & Collaboration

A Fast and Reliable Continuous Integration (CI) Pipeline

Enforced Code Quality Standards & Static Analysis

Mandatory, Effective Peer Reviews (Pull Requests)

In-Sprint Dev-QA Collaboration & Pairing

Early and Continuous Exploratory Testing

🔗 The `common-tasks` Skill