There’s a moment in every project where things start slipping.

Tests are being executed… but no one is fully sure:

• what was tested

• what’s still pending

• what failed yesterday vs today

• or whether we’re actually ready to release

I’ve seen this many times.

Not because teams lack skill.
But because they lack structure.

That’s where Azure Test Plans comes in.

What Azure Test Plans really is (beyond the definition)

Azure Test Plans is not just a place to “store test cases.”

It’s a centralized system to control quality across:

• test cases

• test execution

• traceability

• reporting

• releases

Think of it as the control tower for QA.

Everything flows through it:

• requirements → test cases

• test cases → executions

• executions → defects

• defects → release decisions

The core components (simple and practical)

1. Test Plans

A Test Plan = a release or sprint scope

Example:

• Sprint 12 Regression

• Release 1.5 Validation

👉 This is where you define what you’re validating

2. Test Suites

Organized containers inside a Test Plan.

Types:

• Static suites (manual grouping)

• Requirement-based suites (linked to backlog items)

• Query-based suites (dynamic via filters)

👉 This is where structure starts to matter

3. Test Cases

Each test case includes:

• Steps

• Expected results

• Preconditions

• Attachments

• Parameters (for data-driven testing)

👉 This is your single source of truth

4. Test Runs & Execution

This is where real QA happens.

You:

• execute tests

• mark Pass / Fail / Blocked

• log bugs directly

👉 Everything is tracked automatically

5. Traceability (This is HUGE)

This is where Azure Test Plans shines.

You can link:

• User Story → Test Case → Test Result → Bug

So when someone asks:

“What was tested for this feature?”

You don’t guess.
You show it.

Subscribe now

How a real QA workflow looks like

Here’s a simple, senior-level flow you can explain in interviews:

1. Requirements are created in Azure Boards

2. Test cases are linked to requirements

3. Test Plan is created for the release

4. Test Suites organize coverage

5. QA executes tests during the sprint

6. Bugs are logged directly from failed steps

7. Reports show progress, pass rate, and gaps

8. Release decision is based on real data

👉 This is test governance in practice

Why companies like Azure Test Plans

From a Test Manager perspective:

✅ Full traceability (audit-ready)

Everything is linked and versioned.

✅ Built-in reporting

• Pass rate

• Fail trends

• Execution progress

✅ Integration with DevOps

No tool switching:

• Boards (requirements)

• Repos (code)

• Pipelines (CI/CD)

• Test Plans (QA)

✅ Supports manual + automation

You can:

• track manual tests

• integrate automated results

Where people struggle (real talk)

Azure Test Plans is powerful… but not always simple.

Common issues:

• Overcomplicated suite structure

• Poorly written test cases

• No clear ownership

• Treating it as “just documentation”

And the biggest mistake:

Using the tool without defining a process

How I approach it (practical mindset)

When I use Azure Test Plans, I focus on:

1. Keep structure simple

• Don’t over-engineer suites

• Align with features or flows

2. Write test cases for clarity, not volume

• Clear steps

• Clear expected results

• Easy to execute

3. Enforce traceability

Every test must answer:
👉 “What requirement does this validate?”

4. Make results meaningful

Execution is not just clicking “Pass”

It’s:

• validating behavior

• identifying risks

• supporting release decisions

The real value (what most people miss)

Azure Test Plans is not about test cases.

It’s about confidence.

Confidence that:

• what needed to be tested → was tested

• what failed → is visible

• what is risky → is known

And when you reach release day…

You’re not guessing.

You’re making a data-driven decision.

Final thought

Tools don’t improve quality.

Clarity does. Structure does. Discipline does.

Azure Test Plans simply provide the environment to apply them at scale.

If used right, it doesn’t just organize testing.

It elevates how your team thinks about quality.

Share

When I first started learning Playwright, I spent far too much time trying to find the “perfect” locator. I would inspect elements, experiment with CSS selectors, and constantly fix tests that broke after small UI changes. Then I discovered Playwright Codegen. Suddenly, finding stable locators became almost effortless. In this article, I’ll show you how to use Codegen and the Playwright Inspector to generate reliable locators in seconds.

👉 Playwright Codegen

Codegen can automatically generate recommended locators while you interact with your application.

In this article, you’ll learn how to use Playwright Codegen + Inspector to discover the best locator in seconds.

What is Playwright Codegen?

Codegen is a Playwright tool that:

• Opens a browser

• Records your interactions

• Generates Playwright test code automatically

• Suggests the best locator strategy

Instead of manually searching the DOM, Playwright analyzes the page and recommends locators like:

• getByRole()

• getByLabel()

• getByText()

• getByPlaceholder()

These are user-facing locators, which are more stable than raw CSS selectors.

Step 1 — Run Playwright Codegen

Run this command in your terminal:

npx playwright codegen http://localhost:4200

Playwright will:

1. Open a browser

2. Launch the Playwright Inspector

3. Start generating code as you interact with the page

You’ll see something like this:

await page.getByRole('textbox', { name: 'Email' }).click();
await page.getByRole('textbox', { name: 'Email' }).fill('denis@email.com');
await page.getByRole('button', { name: 'Login' }).click();

Notice something important here:

Playwright prefers:

getByRole
getByLabel
getByText

These locators are based on how users see the interface, not on fragile DOM structures.

Step 2 — Click Elements to Generate Code

Once Codegen is running:

1. Click inside the browser window

2. Interact with your application normally

3. Playwright will generate test code automatically

Example interaction:

• Click email field

• Type email

• Click login button

await page.getByRole('textbox', { name: 'Email' }).fill('denis@email.com');
await page.getByRole('button', { name: 'Login' }).click();

This code can be copied directly into your test files.

Step 3 — Understand the Locator Strategy

Playwright follows a locator hierarchy when generating selectors.

Best → Worst

getByRole()
getByLabel()
getByPlaceholder()
getByText()
getByTestId()
CSS locator()
XPath

This is why Codegen rarely generates something like:

page.locator("div:nth-child(3) > button")

Those selectors are fragile and break easily.

Step 4 — Refine Locators with the Inspector

While Codegen is running, you also have access to the Playwright Inspector.

The Inspector allows you to:

• Pick elements visually

• Highlight matched elements

• See how many elements match a locator

• Debug tests interactively

For example, if a locator matches multiple elements, the Inspector will show something like:

3 elements matched

This immediately tells you the locator is too broad.

Example: Improving a Locator

Bad locator:

await page.locator("input").first().fill("test@email.com");

Why this is problematic:

• It depends on DOM order

• If another input appears, the test breaks

Better locator:

await page.getByLabel("Email").fill("test@email.com");

Now the test is clearer and more stable.

Debugging Tip: Use the Playwright Inspector

You can also pause your tests and inspect locators interactively.

Add this line to your test:

await page.pause();

Then run:

npx playwright test --headed

The Playwright Inspector opens, letting you:

• select elements

• test locators

• refine selectors quickly

Why Codegen is So Powerful

Codegen is extremely useful because it:

✔ saves time
✔ suggests stable locators
✔ teaches best practices automatically
✔ helps beginners learn Playwright faster

Many automation engineers use Codegen as a starting point for writing tests.

Final Thoughts

Writing stable locators is one of the most important skills in automation testing.

Instead of manually guessing selectors, use Playwright Codegen to generate reliable locators in seconds.

The workflow becomes simple:

Run Codegen
↓
Interact with your app
↓
Copy generated locators
↓
Refine if necessary

With this approach, you’ll spend less time debugging locators and more time building meaningful tests.

Writing good automation tests isn’t just about tools—it’s about choosing the right techniques. Locator strategy is one of the biggest reasons tests become fragile over time. By using Playwright Codegen and the Inspector, you can immediately discover stable locators and build more reliable tests from the start.

If you’re learning Playwright or working in QA automation, I’ll continue sharing practical tips like this—things that save time and improve test stability.

Subscribe if you’d like more guides on Playwright, automation testing, and modern QA workflows.

Happy testing 🚀

Share

When learning Playwright, one of the first things you realize is that finding elements correctly is everything.

If your locator is weak or ambiguous, your tests will fail.
If your locator is precise and well-designed, your automation becomes stable, readable, and maintainable.

In this article, I want to walk through the basic locator syntax rules in Playwright — the foundation every QA engineer should understand before writing complex automation.

Let’s look at a simple test example.

test('locator syntax rules', async({page}) =>{

    // by Tag name
    page.locator('input')

    // by ID (# indicates the locator is an ID)
    page.locator('#inputEmail1')

    // by class value ( "." indicates class )
    page.locator('.shape-rectangle')

    // by attribute ([] indicates attribute)
    page.locator('[placeholder="Email"]')

    // by entire class value (full class selector)
    page.locator('[class="input-full-width size-medium status-basic shape-rectangle nb-transition"]')

    // combining selectors (tag + attribute)
    page.locator('input[placeholder="Email"]')

})

Now let’s break down what each of these selectors means.

1. Locating Elements by Tag Name

The simplest selector is the HTML tag itself.

page.locator('input')

This finds all <input> elements on the page.

However, this approach is usually too broad. Most pages have many input fields, so relying only on the tag name can make your locator unstable.

It’s useful for quick exploration, but rarely ideal for production tests.

2. Locating by ID

IDs are often the most reliable selectors.

page.locator('#inputEmail1')

The # symbol tells Playwright that you're targeting an element ID.

Example HTML:

<input id="inputEmail1">

If the ID is unique (as it should be), this locator becomes very precise.

3. Locating by Class

You can target elements using their CSS class.

page.locator('.shape-rectangle')

The . symbol represents a class selector.

Example HTML:

<input class="shape-rectangle">

This works well, but remember: many elements can share the same class, so sometimes this selector is not unique enough.

4. Locating by Attribute

Another powerful technique is using HTML attributes.

page.locator('[placeholder="Email"]')

Example HTML:

<input placeholder="Email">

The square brackets [ ] indicate that we are selecting by attribute value.

This method is extremely useful because attributes like:

• placeholder

• type

• data-testid

• aria-label

are often very stable.

Share Denis De O

5. Using the Full Class Attribute

Sometimes you may see selectors like this:

page.locator('[class="input-full-width size-medium status-basic shape-rectangle nb-transition"]')

This targets the entire class attribute value.

While it works, it’s usually not recommended, because UI frameworks frequently change class combinations. Even a small change can break your locator.

A better approach is selecting only a relevant class.

6. Combining Selectors (The Powerful Technique)

One of the best practices in Playwright is combining selectors.

Example:

page.locator('input[placeholder="Email"]')

This means:

• find an input tag

• that also has placeholder=”Email”

Combining selectors helps create unique and stable locators.

This is extremely powerful because it reduces the chance of selecting the wrong element.

7. What About XPath Locators?

If you come from Selenium or older automation projects, you might be used to XPath, like:

page.locator('//input[@placeholder="Email"]')

XPath can work — but Playwright’s documentation recommends avoiding XPath when you can, because it often leads to:

• Brittle tests (UI structure changes → XPath breaks)

• Hard-to-read selectors (especially long XPaths)

• More maintenance over time

A better approach than XPath

Instead of relying on the DOM tree structure, prefer CSS selectors and meaningful attributes, or even better, user-facing locators like role-based selectors:

// CSS: simple and stable
page.locator('input[placeholder="Email"]')

// Better (when possible): role-based, closer to how a user interacts
page.getByRole('textbox', { name: 'Email' })

When XPath is “acceptable.”

Sometimes XPath is the only option — especially in legacy apps with no stable attributes. If you must use it, keep it:

• short

• specific

• and avoid absolute paths like /html/body/div/...

But in modern Playwright-style automation, XPath should be the last resort, not the default.

A Practical Tip for QA Engineers

In real projects, I try to follow a simple rule:

Start with the most meaningful selector possible.

Good options include:

• getByRole() (best for accessibility)

• data-testid

• unique IDs

• attribute combinations

Weak selectors like tag name alone should usually be avoided.

8. Locating Elements by Exact Text

Sometimes the easiest way to locate an element is simply by the visible text the user sees on the page.

Example:

page.locator(':text-is("Using the Grid")')

This finds an element whose visible text is exactly "Using the Grid".

Example HTML:

<button>"Using the Grid"</button>

This approach is powerful because it matches what the user actually sees, rather than relying on technical attributes that may change.

In modern Playwright testing, text-based selectors are often preferred because they reflect real user interactions.

9. Locating Elements by Partial Text

You can also locate elements using partial text matches.

Example:

page.locator(':text("Using")')

This would match elements such as:

Using the Grid
Using tag
Using settings

Partial text matching is helpful when:

• The full text may change slightly

• The UI contains dynamic content

• You only need part of the label

However, be careful: partial matches can sometimes return multiple elements, so make sure the locator is still unique.

Why Locator Quality Matters

Good locators lead to:

✔ More stable tests
✔ Easier debugging
✔ Cleaner automation code
✔ Less maintenance when the UI changes

Poor locators lead to the opposite: flaky tests that waste hours of investigation.

Final Thought

Learning automation is not only about writing scripts.

It’s about learning how the browser sees the page.

Once you understand locator strategies, your Playwright tests become simpler, stronger, and much easier to maintain.

And in QA automation, that makes all the difference.

If you’re learning Playwright like I am, remember:

Small details like locator strategy often separate fragile test scripts from professional-level automation.

Share

When you start writing Playwright tests, one of the first things you learn is:

await page.getByText(’Login’).click();

It feels simple.

It works.

And in the beginning… it’s enough.

But then something happens.

The moment things start breaking

You run your tests again.

And suddenly, you see this:

strict mode violation: getByText(’Login’) resolved to 2 elements

Or worse…

Your test clicks the wrong thing.

Or fails randomly.

Or passes locally but fails in CI.

Nothing changed.

But everything broke.

The real problem isn’t Playwright

It’s how we are selecting elements.

getByText() feels natural because it mimics how we read pages:

“Find something that says Login and click it.”

But the browser doesn’t think like a human.

It sees structure, roles, and accessibility, not just visible text.

And that’s where getByRole() changes everything.

What getByRole() really does

Instead of searching for any element with text, getByRole() searches for elements based on what they are meant to do.

Example:

await page.getByRole(’button’, { name: ‘Login’ }).click();

You’re no longer saying:

“Find text ‘Login’ somewhere.”

You’re saying:

“Find the button that the user sees as ‘Login’.”

That’s a completely different level of precision.

Why this matters more than you think

Modern web apps are full of repeated text:

• “Save”

• “Submit”

• “Edit”

• “Charts”

And getByText() doesn’t know which one you mean.

It might match:

• hidden elements

• labels

• tooltips

• partial matches (like “Echarts” vs “Charts”)

That’s how flaky tests are born.

A real example

You write:

await page.getByText(’Charts’).click();

But your app also has:

• “Charts”

• “Echarts”

Now Playwright finds two elements.

And you get:

strict mode violation

The fix

await page.getByRole(’link’, { name: ‘Charts’, exact: true }).click();

Now you’re saying:

• it must be a link

• it must be named exactly “Charts”

No ambiguity.

No guessing.

No flakiness.

The hidden superpower: accessibility

getByRole() doesn’t just make tests better.

It aligns your tests with how real users interact with your app, including:

• screen readers

• keyboard navigation

• accessibility tools

So when you use:

getByRole(’button’, { name: ‘Submit’ })

You’re testing the user experience, not just the DOM.

And that’s a big shift.

Cleaner tests, clearer intent

Compare these two:

await page.locator(’.btn.primary’).nth(2).click();

vs

await page.getByRole(’button’, { name: ‘Submit’ }).click();

The first one says:

“Click the third button with this CSS class.”

The second one says:

“Click the Submit button.”

One is implementation.

The other is intent.

And tests should always reflect intent.

The senior QA mindset

At some point, you stop asking:

“How do I click this element?”

And start asking:

“How would a user find this?”

That’s when your tests become:

• more stable

• easier to read

• easier to maintain

• easier to trust

When should you use getByText()?

It’s not useless.

You can still use it for:

• simple static content

• unique text (like headings)

• quick experiments

But for interactive elements, prefer:

• getByRole()

• getByTestId()

A simple rule to remember

If the element is clickable, typeable, or interactive…

👉 Use getByRole()

If the element is just content…

👉 getByText() is fine

One small change, big impact

You don’t need a new framework.

You don’t need more tools.

Just change this:

getByText()

To this:

getByRole()

And over time, your tests will feel different.

More stable.

More intentional.

More professional.

A small exercise

Open one of your existing tests.

Find a line like this:

await page.getByText(’Login’).click();

Replace it with:

await page.getByRole(’button’, { name: ‘Login’ }).click();

Run your tests again.

Notice how it feels.

Final thought

Good automation isn’t about making tests pass.

It’s about building tests you can trust.

And trust comes from clarity.

Not just for the machine…

…but for the human reading the code.

Subscribe now

Share

When someone becomes a TestRail admin, the expectation is usually simple:

“Set it up.”
“Create the projects.”
“Configure the fields.”
“Give people access.”

Once that’s done, everyone assumes the job is finished.

That assumption is where most TestRail setups start to quietly fail.

Because being a TestRail admin isn’t really about configuration.
It’s about ownership.

Setup Is a Moment. Ownership Is Ongoing.

Configuration happens at a specific point in time.
Ownership happens every week.

If your role as a TestRail admin stops after setup, a few things slowly begin to happen:

• Test cases start to look different from each other

• Naming becomes inconsistent

• Reports feel less and less useful

• Automation results don’t quite match reality

None of this breaks overnight. That’s what makes it dangerous.

What You’re Actually Responsible For

Most TestRail admins don’t realize how much influence they have.

Whether you intend it or not, you’re shaping:

• How testers think about coverage

• What “good enough” looks like

• What people trust when a release is coming

• How confident (or confused) new team members feel

These aren’t technical decisions.
They’re system decisions.

And if no one actively makes them, the system still evolves — just in random ways.

Subscribe now

Why Configuration-Only Setups Don’t Last

I’ve seen this pattern many times.

A TestRail instance starts clean.
Everyone agrees on structure.
The first few months look great.

Then:

• Teams grow

• Deadlines tighten

• Shortcuts creep in

Without someone paying attention, the system absorbs all of that pressure.
TestRail doesn’t complain. It just records it.

A year later, people say:

“TestRail used to be useful.”

What usually changed wasn’t the tool.
It was the lack of ongoing ownership.

Ownership Doesn’t Mean Being the Police

This is an important point.

Owning TestRail doesn’t mean blocking people or enforcing rules for the sake of control.
It means keeping the system understandable and trustworthy.

Good TestRail admins:

• Set clear expectations early

• Adjust structure when reality changes

• Keep standards simple and visible

• Step in before small inconsistencies become big problems

The goal isn’t perfection.
The goal is clarity.

The Cost of Not Owning the System

When no one truly owns TestRail, the cost shows up slowly:

• Time wasted arguing about coverage

• Reports that management stops looking at

• Automation metrics that confuse more than they help

• New testers who don’t know what matters

At that point, teams often blame the tool.

But TestRail is just reflecting what’s happening underneath.

A Better Way to Think About the Role

If you’re a TestRail admin, a useful way to think about your role is this:

You’re not maintaining a tool.
You’re maintaining shared understanding.

That means regularly asking:

• Does this still reflect how we test today?

• Are we capturing a signal or just accumulating data?

• Would someone new understand this setup without explanation?

If the answer drifts over time, configuration alone won’t fix it.

Subscribe now

Share

Leave a comment

Most teams adopt TestRail hoping it will solve their QA problems.

It doesn’t.

What TestRail actually does is something far more uncomfortable:
It exposes how your QA system really works — or doesn’t.

Used well, TestRail becomes a powerful coordination and decision-making tool.
Used poorly, it turns into an expensive archive of outdated test cases that no one trusts.

The difference has very little to do with the tool itself.

What TestRail Is Actually Good At

At its best, TestRail helps teams answer a few critical questions:

• What do we actually test — and why?

• What changed, and what needs coverage now?

• What risks are we accepting in this release?

• Where does automation help, and where does it not?

In other words, TestRail is not about storing test cases.
It’s about making testing visible, structured, and intentional.

When TestRail works, it’s usually because:

• Someone owns the system

• There are clear standards

• Decisions are explicit, not accidental

Subscribe now

Where Most Teams Go Wrong

Most TestRail implementations fail for predictable reasons:

• No one owns the structure long-term

• Test cases grow without pruning

• Permissions are too loose or too strict

• Reports exist, but no one uses them to decide anything

• Automation is bolted on without a clear purpose

Over time, TestRail becomes a reflection of organizational entropy.
The tool didn’t cause the problem — it simply made it visible.

This is why teams often say things like:

“TestRail doesn’t really help us anymore.”

What they usually mean is:

“We stopped making decisions about how QA should work.”

TestRail as a QA System, Not a Tool

The biggest shift teams need to make is mental, not technical.

TestRail is not:

• A checklist generator

• A compliance box

• A mirror of your automation framework

TestRail is:

• A coordination layer

• A shared language between QA, engineering, and management

• A place where test intent and risk become explicit

When treated as a system, TestRail helps teams:

• Scale without losing control

• Onboard new testers faster

• Understand coverage without false confidence

When treated as a tool, it quietly decays.

Why TestRail Helps — When Used Correctly

TestRail helps not because it has features, but because it forces structure.

It forces teams to decide:

• What a “good” test case looks like

• How much detail is enough

• What matters to report — and what doesn’t

• How manual and automated testing relate

These decisions are uncomfortable.
Avoiding them is easy.
TestRail simply refuses to hide the consequences.

What This Publication Will Focus On

I won’t explain how to click buttons or recreate documentation.

Instead, I’ll write about:

• Owning TestRail as a QA system

• Governance, structure, and long-term maintainability

• How TestRail and automation should (and should not) interact

• The patterns that make TestRail useful — and the ones that destroy it

I’m documenting these lessons as part of a practical TestRail Admin Playbook, built from real production environments, not idealized setups.

If you’ve ever felt that TestRail should be helping more than it does, this is where we’ll unpack why — and what to do about it.

In the next post, I’ll explain why being a TestRail admin is not a configuration job, and why that misunderstanding causes most setups to fail.

Leave a comment

Subscribe now

Share