blogs

Modern professional software development is more akin to sport than anything else

2026-05-23T14:36:13Z

For too long we’ve accepted one failed metaphor or another to help define developing software professionally. All models are fallible but the one I believe breaks least often is: software development is a contact team sport. One shared clear goal, smaller milestones to progress to that goal, filled with opportunities for success and failure to learn from and adapt and when on the pitch, it doesn’t matter what your ‘position’ is, you have one responsibility: make your team win.

John Cutler recently asked “What is a team?” in his post TBM 423: Why Defining Teams Is So Hard. What I took from his piece aligns a lot with my experience: organisations are messy.

We have one very strong source of inspiration for what real teams are, from sport. There are a number of different ‘teams’ in sport. There are examples of individual sports where the ‘team’ exists but is less apparent in direct competition, such as tennis or golf. Formula 1 is an individual sport but which cannot reach the extreme heights of innovation and excellence unless there’s an acceptance that success is impossible without the team around them. Then there’s the sports where the team is in competition together, in real time e.g. football and rugby.

It is my belief that ‘teams’ which have a shared goal, made up of more than 2 people, operate closer to football and rugby, than F1, golf or tennis. If a team doesn’t see themselves in this way now, making this subtle change in perspective will be transformative.

As a Manchester City fan, the announcement that Pep Guardiola is leaving is a hard one to process but it does instigate a moment to reflect. Pep’s Barcelona team is generally accepted to be the best football team created in the modern era. His strong beliefs, derived from his inspiration Johan Cruyff’s Total Football, applied to a squad of exceptional players, with one standout legend in Lionel Messi. This team dominated football matches from start to finish. I still don’t believe I’ve seen a better single performance from a football team than their 3-0 victory over Manchester United in the Champions League final.

It wasn’t until he became Manchester City manager that I started to delve deeper into his methods. Over the 10 years of his tenure as manager, I’ve watched countless press conferences, documentaries and interviews, attended more games home and away than my bank balance would like to admit and watched even more on TV. One thing about Guardiola stood out more for me than his tactics or beliefs.

The Pep Guardiola Effect

It’s easy to see why Pep’s teams do so well. Without going into too much detail, Pep’s teams have a number of very specific quality attributes: the team moves up and down the pitch with the ball; when the ball is lost the team have to get it back immediately; the individual skill level of every player is incredible to enable them to maintain the ball under intense pressure; there’s always a free player to pass to. It’s simple when written down, but only Pep has really been able to implement it consistently, season after season, at 3 major clubs. I asked myself why and I think I found it: responsibility.

The Pep Guardiola effect is evident most in the interviews and press conferences he does when City have lost or even more so, when they’ve won but not played well. He doesn’t hold his players accountable, he takes responsibility and makes the players responsible.

Accountability is often displayed in questions focussed on the past: why did this happen, why didn’t you do this?

Responsibility is best displayed in questions focussed on the future: what can I do differently, how can we be better?

Pep helps them be responsible for themselves, to be their best but more importantly, be responsible to their team, the fans and the club. Fear can drive you in short bursts, but responsibility is the internal fire that powers us. Pep is able to build incredible levels of responsibility into the players in his teams. That responsibility blurs the once static understanding of positions: goalkeepers just stop the ball, defenders stop attacks, midfielders collect the ball, wingers get the ball to the strikers, strikers score. This is now and forever more no longer true. In a Pep team, the goalkeeper has to play football as well as midfielder, strikers have to be able to retrieve the ball in an attacking position as well as any defender in their own penalty area. This responsibility, a responsibility to work for the team with a single shared goal, to win every game. This is what creates the virtuous feedback loop for excellence. That feedback loop or continuous learning is a relentless pursuit of the perfection of implementation of the beliefs. Some of the most successful players at Manchester City joined the club and were pretty terrible in their first season. But they stayed. They believed in themselves. They improved. Until Erling Haaland it’s arguable that Pep’s City had never signed a complete superstar. Every other player who turned out to be world class, became world class at City. But how can Pep build that level of responsibility into people?

The Pep Guardiola Approach

Pep thinks in systems. The pitch is a constraint and there are many others. He doesn’t accept all of those constraints as immovable, but he accepts them in the moment. That acceptance gives Pep a canvas to push those constraints to their absolute limits. There is one constraint he embraces more than any other: that his team is made of human beings. Humans have feelings, they have lives, they have limitations. We are all flawed. Pep is flawed. Pep knows this and he does one thing I don’t think I’ve seen anyone else do close to as well as him, other than Jurgen Klopp: he cares about those players as humans. Not as an extended family, there are clear boundaries of responsibility in place. But he cares about all of them as individuals. He signs players who he believes have a desire to reach the very top of their potential. He gets them there not through fear but by giving a damn about the success of each of them. This can’t be faked. Humans have excellent instincts to detect fakeness. Maybe not initially, but when it really matters. It is impossible for Pep to turn huge potential into world class, season after season, unless he is authentic. And you can see it in his behaviour.

We’ve all been told how psychological safety is important for excellence. Excellence is an emergent property of the ability to adapt following failure. Pep is able to build such a high level of trust in him from his team, that despite intense pressure, individuals feel the responsibility to take the circumstances, not the moments, the circumstances and lift themselves and each other to improve, over and over and over again.

People have written about this. Countless white papers of research, conference talks and many a book. One in particular Radical Candour.

“Care personally for your colleagues while also challenging them directly.’”
Matt Rutherford

The feeling of being cared for can only come from someone else’s action. Saying you care for someone only survives if you behave like it. Not perfectly, that’s not possible, but proportionally more often than not. It’s in the moments of highest stress when that care has to come to the fore. No one messes up on purpose. Football is a complex game, with a huge surface area for mistakes. Software development is no different. But excellence can only come from learning from those mistakes and to learn from those mistakes, the people who could scorn you, who could hold you accountable, have opportunities to demonstrate their level of care by accepting their responsibility in the failure or offering words of encouragement and reassurance.

And this is why that sustained level of care is necessary. Pep has said himself on a number of occasions that he overstepped challenging directly, during or after a game. You can watch some of the changing room exchanges online. As an outsider they’re uncomfortable to watch. But in that group, the players know it’s not personal, it’s just frustration. And because that frustration doesn’t boil over into accountability, even in this most intense of environments, players can feel safe that tomorrow, when the frustration is gone, responsibility kicks in again.

Almost everyone I’ve heard talk about this book falls into the ‘fake care’ problem. They fail to understand that the success of challenging directly is directly proportional to the amount of care the person receiving the feedback feels they have from the person providing it. These people will only be involved in creating and achieving genuine excellence, through luck.

Excellence in the world of AI

As building software becomes even more commoditised, everyone gets the lift up. Pep changed football, now every club, from junior to senior, try to emulate what Pep achieved, not because they solved that problem themselves, but because they’re standing on the shoulders of a giant. If everyone tries to play the same way you have two options for success: do it better than everyone else or be better than everyone else.

The organisations and teams of any reasonable scale will succeed in the era of AI by playing Pep’s football. Blur roles, build individual excellence, one shared problem to solve but solve it together. But that’s not enough, you need to be better. Being better is a tomorrow problem. Tomorrow can only be better if people take responsibility for it.

This isn’t about reading a book and looking for a recipe or process to follow. You’ve already failed if you do. Now as humans more than ever we have to stand out. That means looking inside ourselves and finding the humanity. That’s going to be the differentiator. You don’t have to completely overhaul an org overnight, you don’t need to do an all-hands. You start tomorrow by changing you. Take the next situation you’re perceived to be a leader for and demonstrate care, demonstrate responsibility. If it’s an incident review, look forward and find a path together. If it’s slipping schedule, look forward and find a path together. If it’s a feature that’s not living up to expectations, look forward and find a path together. Not in a slide deck or slack message but around a desk or in an online call, with the problem in front of you. Start together, end together. Drag each other over the finish line.

Data Driven API Testing in Playwright TypeScript: Part 1

2026-05-23T11:51:55Z

Learn how to implement data-driven API testing in Playwright with TypeScript using static test data and reusable tests.

Continue reading on Level Up Coding »

Data Driven API Testing in Playwright TypeScript: Part 1

2026-05-23T11:51:55Z

Learn how to implement data-driven API testing in Playwright with TypeScript using static test data and reusable tests.

Continue reading on Level Up Coding »

The Agile Circus

2026-05-22T19:50:40Z

A humorous story exposing fake Agile culture, endless meetings, toxic leadership, and workplace chaos in a modern corporate team.

Continue reading on ILLUMINATION »

The Agile Circus

2026-05-22T19:50:40Z

A humorous story exposing fake Agile culture, endless meetings, toxic leadership, and workplace chaos in a modern corporate team.

Continue reading on ILLUMINATION »

Selenium vs Playwright 2026: The Benchmark Data Every Migration Team Needs

2026-05-22T04:38:34Z

Playwright now leads Selenium by 23x in npm downloads. See real benchmark data, migration traps, and an 8-week roadmap for teams considering the switch in 2026.

The post Selenium vs Playwright 2026: The Benchmark Data Every Migration Team Needs appeared first on Software Testing & Automation.

n8n for QA Automation: Build No-Code CI Pipelines That Run Playwright Tests

2026-05-22T04:34:15Z

Learn how QA teams can build no-code CI pipelines with n8n and Playwright. Step-by-step tutorial covering triggers, JUnit parsing, Slack alerts, and Jira bug creation without writing YAML.

The post n8n for QA Automation: Build No-Code CI Pipelines That Run Playwright Tests appeared first on Software Testing & Automation.

DOM State Clarity With cy.depends Command

2026-05-22T04:00:00Z

Imagine a simple web application scenario: you click on a button. App tries to load some data. The data might load, or the backend might return an error. You write a Cypress test:

1
2
3

cy.visit('cypress/fetch-fails-sometimes.html')
cy.contains('button', 'Fetch data').click()
cy.contains('#data', 'Fetched data: "List of items"')

The test is green, but there are a couple of downsides.

test is slow Loading the data might take a while. In our case it takes almost 8 seconds, so your test must wait.

mismatch in speeds Network call might fail and the test times out waiting for the #data element. The network error itself is fast: it returns 500 status code after only half a second. But since the successful data load is slow, we have to keep waiting and waiting for #data element.

it(
  'handles occasional backend error',
  // longer command timeout to allow for slow data load
  { defaultCommandTimeout: 15_000 },
  () => {
    cy.visit('cypress/fetch-fails-sometimes.html')
    cy.contains('button', 'Fetch data').click()
    cy.contains('#data', 'Fetched data: "List of items"')
  }
)

errors are not observed The test does not report the "error" element shown. Instead the test times out looking for the "#data" element. It would be nice to write a test like this:

click on the button
wait for the "#data" element to appear and check its text
while waiting, if the "#error" element appears, fail the test with a clear message

Of course, we could rewrite the test to observe the network call - but not every action has a clear observable "single point". Instead many tests have to consider several possible outcomes at once.

DOM states

In our application, the app is simple. From the starting state (before we click the button), the app goes into "loading data" state, followed by the "successful data load" OR "failed data load" states. We can ignore the "loading data" state, since our app does not really show anything observable on the page (and we ignore the network call for now). At the end of the loading state, the app might show an element with ID "data" or an element with ID "error". Nothing else (unless things go really wrong)

In this blog post, I will show my new query command cy.depends from the cypress-if plugin that lets you consider multiple possible DOM states at once. This command can wait for all given selectors and then perform actions depending on the first matched selector.

Let's write a test and wait simultaneously for success and error states. For now, let's just print a message for each outcome.

cy.contains('button', 'Fetch data').click()
// simply report success or failure
cy.depends({
  '#data': 'Data loaded',
  '#error': 'Failed to load data',
})

When the network load succeeds, we see 2 items logged into the Command Log: the query command waits for all selectors using all matching CSS selector. Once some elements are found, cy.depends matches the elements again to the find the first individual selector and performs the actions specified in the arguments object. For example, if the value is a string, it simply logs it.

Let's say the network fails. Notice the cy.depends matched the #error element and the test finished immediately after the network load. No need to wait for #data element for 15 seconds when the app is clearly in the "error loading" state.

Handle each state

We can print log messages for each state. Or we can fail the test for some states. When the test finds the "#error" element, we want to fail the test immediately, which we can by giving an Error instance.

cy.contains('button', 'Fetch data').click()
// report success, fail on error
cy.depends({
  '#data': 'Data loaded',
  '#error': new Error('Failed to load data'),
})

Again, the test is fast and clear. If we see an element matching #error CSS selector, we want to throw the Error object. We can go beyond simply throwing an error. We could perform custom assertions on the found elements. The cy.depends command yields the matched selector and found elements to the callback function

cy.contains('button', 'Fetch data').click()
// do something depending on the matched selector
cy.depends({
  '#data': 'data loaded',
  '#error': 'load error',
}).then(({ selector, elements }) => {
  if (selector === '#data') {
    expect(elements, 'data element')
      .to.have.length(1)
      .and.to.have.text('Fetched data: "List of items"')
  } else if (selector === '#error') {
    expect(elements, 'error element')
      .to.have.length(1)
      .and.to.have.text('Fetch failed: Network response was not ok')
  }
})

By the way, if none of the cy.depends selectors match, the query command times out and the test fails.

Conditional actions

Querying multiple states helps solve conditional testing problems without nesting multiple IF/ELSE paths. Think of cy.depends as a switch statement; yes, it could be equivalent to multiple if/else statements, but having one switch usually beats multiple branches.

For example, let's say we have a page with a dialog that might be open, and we always want it closed. If we don't have a good programmatic way of controlling the dialog (I know, I know, but we are in the real world), then:

it(
  'closes dialog if open',
  () => {
    cy.visit('cypress/close-dialog.html')
    cy.depends({
      'dialog[open]': ($dialog) => {
        cy.wrap($dialog).find('button#close').click()
      },
      'dialog:hidden': 'dialog is already closed',
    })

    // check if the dialog is open
    cy.depends({
      'dialog[open]': new Error('dialog should be closed'),
      'dialog:not([open])': 'closed dialog',
    })
  },
)

Of course, you can have more than two states, just list the CSS selectors ordered from the most discriminating to the least discriminating to properly determine the correct state.

// conditional state depending on the number of items in the list: 3, 2, or 1
cy.depends({
  '#fruits li:eq(2)': 'Found 3 items',
  '#fruits li:eq(1)': 'Found 2 items',
  '#fruits li:eq(0)': 'Found 1 item',
})

Embrace and extinguish the ambiguity by handling every possible page state in your end-to-end tests.

🎁 Find the cy.depends query command in my cypress-if plugin.

Docker Compose for Test Automation: One File to Run Playwright, Selenium Grid, and API Tests in 2026

2026-05-22T03:40:59Z

Run Playwright, Selenium Grid, and API tests from one docker-compose.yml. Production-ready Docker Compose test automation setup for 2026 with health checks and CI/CD.

The post Docker Compose for Test Automation: One File to Run Playwright, Selenium Grid, and API Tests in 2026 appeared first on Software Testing & Automation.

From Manual Tester to AI Engineer: The 90-Day Roadmap for Indian QA Professionals in 2026

2026-05-22T03:40:07Z

The exact 90-day roadmap for Indian QA professionals to transition from manual testing to AI engineering. Includes real salary data from PayScale, the tools to learn, and a portfolio project that gets you hired.

The post From Manual Tester to AI Engineer: The 90-Day Roadmap for Indian QA Professionals in 2026 appeared first on Software Testing & Automation.

The QA Career Pivot Guide 2026: From Testing Features to Owning Quality Intelligence

2026-05-21T22:00:00Z

QA is evolving from testing features to owning quality intelligence. The career pivot guide for 2026: new skills, new role titles, and how to make the transition.

The post The QA Career Pivot Guide 2026: From Testing Features to Owning Quality Intelligence appeared first on Software Testing & Automation.

Measuring for AI success and quality improvement

2026-05-21T15:10:40Z

I’ve worked primarily in a tester and quality engineering role for a few decades now. “Metrics” have always been the magic beans of improving quality. People ask me “What metrics should we use?”, as if they will reach their quality goals by measuring the right things. They want something easy, like code coverage and bug counts.

Small experiments

In my experience, it works best the other way. My teams worked to achieve one improvement goal at a time. Having agreed on the next goal, we tried experiments to move towards it step-by-step. Then we’d figure out some way to measure whether each experiment was working. For example, one team I was on wanted to shorten our cycle time, from when we started working on a user story to when we got it into production.

We decided to try example mapping to get better shared understanding of each story in the planning stage. This practice should help us cut down on re-work when acceptance testing found issues. What metrics would track the success of our experiment? Besides cycle time, we could measure the percentage of stories rejected in acceptance testing. When it was reduced by half in two iterations, we kept up the example mapping.

Measuring progress in your AI journey

Today, we have AI tools to help us achieve our quality goals. The principles of building quality in throughout the whole development life cycle remain the same. AI assistance gives us new software tools that help us work smarter. Research shows that AI amplifies the strengths of high-performing organizations, and the problems of dysfunctional ones.

In my view, approaching AI adoption step-by-step, iterating through small improvement experiments, is a good way to enjoy the benefits and avoid the pitfalls. Measuring appropriately to track each experiment is key.

Enter the DORA AI Capabilities Model. I encourage you to go download the DORA AI Capabilities Model Report. Open it in your PDF viewer of choice. Now, do a “find” on the word “measure”. Found on 23 pages! Wow! Go back to the start of the document. Check out the seven key capabilities on page 4.

The Seven Key Capabilities

Now read page 5, where you will learn that the report gives you details on how to get started on each of the seven capabilities. Keep reading. As you explore the detailed section for each capability, and why that capability matters for AI, you’ll learn how to improve that capability day-by-day. And, hooray, the report explains specific ways to measure your progress. You’ll also find the common obstacles to successfully adopting capability.

There’s a lot to digest here. You’ve got so much information here for your team to discuss. But where do you start? We’re only human, we can’t grow seven capabilities at once.

No worries, the report provides detailed sections on techniques to help your team prioritize which capability to work on first. This takes an investment of time, for sure. Then your team will be ready to start iterating on those small experiments to improve the highest-priority capability. The best part is you will now know some good ways to measure your progress towards improving that capability.

Making the investment

I know this sounds overwhelming. Most people do look pretty overwhelmed by the challenges that AI brings along with its benefits. We humans tend to not make decisions based on scientific research. Yet the potential rewards of successful AI adoption, and the potential disasters of unsuccessful AI adoption, should motivate this investment. So now, go download DORA’s ROI of AI-Assisted Software Development report. It shows the initial investment needed to reap the eventual exponential growth that AI assistance enables.

Be patient, take baby steps, do one or two small experiments at a time. Make them short enough so that you know in a week or two if the experiment is working – based on those appropriate metrics you chose. At some point, your team will get past “J-curve of AI value realization” and start saving time. Rather, making time for humans to do what humans do best, while the robots do our grunt work. As the ROI of AI-Assisted Software Development report concludes,

Invest in engineering excellence today to ensure AI acts as an amplifier of value rather than a catalyst for downstream chaos.

You’ve got the recipe books here, thanks to DORA. Invest the time now, and enjoy tracking your quality – and your enjoyment – improving faster and faster over time.

The post Measuring for AI success and quality improvement appeared first on Holistic Testing with Lisa Crispin.

CI wasn’t built for coding agents. Here’s what comes next.

2026-05-21T14:30:00Z

CI pipelines are too slow for AI coding agents. Learn how "plans" bring fast integration testing directly into the developer inner loop.

Practicing Playwright: Visual Testing With Playwright

2026-05-21T12:46:54Z

If you want to do some basic visual checking to see if there has been any deviation from your baseline of images, you can use Playwright. It's built in! Playwright can take a snapshot of a web element, a visible viewport, or a full page, and save it in your Git repository as a baseline, failing the test if the image, page, or viewport does not match up.

Caution: From what I have been reading, this can quickly cause your code repository to balloon in size, since Chrome, Firefox, and WebKit would each store its own golden screenshot in your repo. Also, images on Mac, Windows, and Linux all appear different pixel-by-pixel. If using a CI platform, it might be best to run visual tests only on a standard Playwright Docker image, to generate and compare snapshots. According to TestQuality, "Once a suite passes 50–100 visual tests, teams need a layer that tracks run history, surfaces flaky-test patterns across cycles, and routes confirmed defects into the team's tracker — none of which lives inside the test runner itself"... I wonder if you can store images in an Amazon S3 bucket and hook that up as a virtual drive? ... no matter. That will be a blog post for another time...

Right now, we will be walking through Butch Mayhew's code he wrote for his LinkedIn Learning course, Learning Playwright, found on his companion GitHub site.

While the test is in a certain state you can a screenshot of the page or certain elements of the page and save them as a snapshot. The snapshots an be used as a baseline images to compare your current site against. This baseline can be periodically updated as the site evolves.

How does this happen? With Playwright's .toHaveScreenshot( ) to take a screenshot and the mask method that you want to leave out of the comparisons between the expected and actual screenshots.

toHaveScreenshot(name): Playwright.dev / Page Assertions

Our Test Site: PracticeSoftwareTesting.com

Butch has a series of tests for the test site Practice Software Testing ( practicesoftwaretesting.com ).

If you go to the site, you can see that there is an ever moving logo, "Toolshop Demo" which has the title "Practice Software Testing - Toolshop" . Let's write a test capturing an image of the page, leaving out the moving logo.

Butch also suggested waiting for everything to be fully loaded with "networkidle". But, according to the Playwright.dev waitForLoadState documentation, it says "Don't use this method for testing, rely on web assertions to assess readiness instead". Hrm. Let's go with that he has for now.

Writing the Visual Test

home.spec.ts

  test("visual test", async ({ page }) => {
    await page.waitForLoadState("networkidle");
    await expect(page).toHaveScreenshot("home-page-no-auth.png", {
      mask: [page.getByTitle("Practice Software Testing - Toolshop")],
    });
  });

tests / homepage / homepage.spec.ts

The first time you run this test, it fails, since there are not yet any snapshots saved. There is no golden file. The second time you run it, it will pass. If you wanted to bypass this step, and just update the snapshots for this page, you can run. This regenerates any snapshots for the assertions:

npx playwright test tests/home.spec.ts --update-snapshots

Did a snapshot not match up with the one saved?

You can investigate it in the built-in Playwright reports, showing differences outlined in red, the actual snapshot, the expected snapshots, and see them side-by-side. It also have a feature where you can move slider back and forth horizontally across the image investigating actual and expected snapshots.

Notice that the mask shows that image in an array. Need to mask a bunch of items on the page? You can add them all to the array.

You can also grab screenshots not just of whatever is in the viewport, or the full page beyond the fold, but also compare individual images, or elements such as popup windows.

Visual Comparisons

From Playwright.dev Docs / Test Snapshots: "Playwright Test includes the ability to produce and visually compare screenshots using await expect(page).toHaveScreenshot(). On first execution, Playwright test will generate reference screenshots. Subsequent runs will compare against the reference".

The ToHaveScreenshot Method

This is all part of Playwright.dev's PageAssertions class, where we are expecting the page for the actual viewable screenshot of the app to match the saved expected viewable screenshot. ( See all Options ). Options you can use:

fullPage: You can decide to capture the entire scrollable page, setting it as "true".
mask: You can tell Playwright to ignore certain areas, such as headers or footers if you are just interested in the main area of the site, finding the locators of those areas and mask them. Normally, it will be a pink box in the report to show what is masks, but you can change the maskColor in CSS color format.
threshold: How strict should colors match? Should it be strict (0) or lax (1) or somewhere in between? The default is 0.2.
omitBackground: When you want to hide the default white background and capture it as transparent.
maxDiffPixels & maxDiffPixelRatio: Shows the acceptable amount of pixels that could be different and a ratio of different pixels between 0 and 1. We can configure both using TestConfig.expect. These are turned off by default.

Matching Pixels With Pixelmatch

Playwright uses the pixelmatch JavaScript library ( https://github.com/mapbox/pixelmatch ) which is used to compare actual and expected images.

Configure Visual Checking In Playwright Config

Want to fine tune the above variables? You can update the global configuration in your playwright.config.ts file:

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

export default defineConfig({
  expect: {
    toHaveScreenshot: {
      // Allow up to 2% of total pixels to change 
      // (handles layout shifts/dynamic content)
      maxDiffPixelRatio: 0.02, 
      
      // Increase pixel color tolerance 
      // (0.2 blends strict pixel match with visual difference)
      threshold: 0.2,          
      
      // Automatically mask dynamic elements like blinking text cursors
      caret: 'hide',           
      
      // Ensure CSS animations are frozen on the first frame
      animations: 'disabled',  
    },
  },
});

How to Compare Product Cards?

Let's say on the PracticeSoftwareTesting.com site, you wanted to create a visual comparison of the first product card. The code could look something like this:



  test('product card matches snapshot', async ({ page }) => {
    await page.goto('https://practicesoftwaretesting.com');

    // Locate a specific element -- here, the first product card
    const productCard = page.locator('[data-test="product"]').first();

    // Wait for the image inside the card to fully load before snapping
    await productCard.locator('img').waitFor({ state: 'visible' });

    // Compare element screenshot against stored baseline
    await expect(productCard).toHaveScreenshot('product-card.png');
  });

});

How To Mask Changing Elements Such As Prices?

Prices for a Shopping Cart will never remain stagnant. They are always changing.

Let's say you just want to do visual checking on the basic layout. Every time the prices change, you don't want the visual test to fail. What you can do is just mask out all the prices, which are with the ids "product-price".

// tests/full-page-screenshot.spec.ts
import { test, expect } from '@playwright/test';

test('homepage layout matches snapshot, prices masked', async ({ page }) => {
  await page.goto('https://practicesoftwaretesting.com');

  await expect(page).toHaveScreenshot('homepage.png', {
    // Mask elements whose content changes between runs
    mask: [
      page.locator('[data-test="product-price"]'),
    ],
    // Pixel-level tolerance -- useful when anti-aliasing differs
    maxDiffPixelRatio: 0.02,
  });
});

... And if you wanted even more fine tuning, you could choose to Integrate Applitools with Playwright.

Running Visual Testing in CI Platforms

Let's say you are running visual testing in a CI environment: Make sure you generate the snapshots against what is in CI, and not your local environment or there will be pixel differences.

If you are using Playwright's pre-built Docker Image (see docs ) make sure to update the images in the container you are using.

According top TestQuality.com: Playwright Visual Regression Testing: A Production Guide to Baselines, Flake, and CI, "Native Playwright visual regression is free to start and expensive to scale. The cost shows up in CI, not on day one".

The problem is that "Windows, macOS, and Linux render fonts, anti-aliasing, and pixel spacing differently. A baseline captured on a developer's Mac will fail when compared against a screenshot taken on the Linux CI runner, even when the application code has not changed".

The solution? "[A] Dockerfile based on the official Playwright image, plus docker-compose mounting screenshot volumes so developers run the same Linux rendering engine locally that the CI runner uses. A single command brings up the same environment everywhere, which eliminates 'works on my machine' visual discrepancies entirely".

How to manage them? "Playwright visual regression CI integration requires treating visual checks as a separate, isolated pipeline stage. Tag visual tests with @visual, exclude them from standard runs using --grep-invert, and execute them in a dedicated Docker step. This keeps functional feedback fast and quarantines visual flake to a controlled environment".

Any other problems? "Storage is the harder problem. Native baselines live in the Git repository, with one image per browser engine — a ten-test suite covering Chromium, Firefox, and WebKit produces thirty committed images. The repo grows fast, but the bigger pain is approval. GitHub, GitLab, and most version control UIs cannot diff images inline. When a baseline updates, the reviewer sees a binary file change with no visible context. Resolving the conflict requires pulling the branch locally, opening the images side by side, copying the new baseline into the feature branch, and pushing manually. House calls this 'GitHub diff blindness,' and it is the single biggest reason teams move off native after a few months".

Happy Testing!

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles

An Approach of Structure‐Enhanced Code‐Centric Graph Learning for Just‐in‐Time Software Vulnerability Detection

2026-05-21T08:05:06Z

Our proposed SCGL model is a dual-view graph learning framework that combines relation-aware local and global structural modelling of code transformation graphs to improve just-in-time (JIT) vulnerability detection. Benchmark experiments demonstrate our SCGL model's effectiveness over state-of-the-art baselines in addressing the JIT software vulnerability detection problem.

ABSTRACT

In recent years, just-in-time vulnerability detection (JIT-VD) has become an essential strategy for improving software security, as JIT-VD can enable the immediate identification of vulnerable or flawed code-commits at the moment they are introduced. Unlike traditional vulnerability detection approaches, which scan entire repositories as well as often producing delayed or excessive reports, JIT-VD delivers timely alerts that allow developers to address security issues while the rationale behind their changes is still clear. This approach reduces remediation costs, prevents the propagation of vulnerabilities into production and aligns well with agile development practices. However, JIT-VD remains challenging because it must capture complex dependencies between recent modifications and the existing codebase to correctly differentiate between safe and risky code-commits. Recent studies have employed code transformation graphs (CTGs) to model the semantic relationships between consecutive commits, using graph neural networks (GNNs) to learn vulnerability patterns. Although CTG-based techniques have achieved promising results, most existing models primarily preserve local structural information, thus neglecting the global structural context that reflects how changes affect the broader system. This oversight limits their ability to identify vulnerabilities caused by indirect or cross-module interactions. To overcome these limitations, we propose SCGL, a structure-enhanced code-centric graph learning framework that integrates relation-aware local modelling via RGCN with global structural representation learning using GIN. This dual-view design allows our proposed SCGL model to capture both fine-grained local relations as well as high-level global dependencies within CTGs. By better leveraging these enriched representations, our SCGL model can significantly improve JIT-VD predictions. Comprehensive experiments on benchmark datasets confirm that our SCGL model consistently surpasses state-of-the-art methods, thus demonstrating the value of incorporating global context alongside local features in vulnerability detection.

Issue Information

2026-05-21T08:05:06Z

No abstract is available for this article.

The Coffee Stir Stick

2026-05-21T05:42:49Z

A funny office story about a new employee, coffee stir sticks, workplace culture, awkward moments, and unforgettable laughter.

Continue reading on ILLUMINATION »

The Coffee Stir Stick

2026-05-21T05:42:49Z

A funny office story about a new employee, coffee stir sticks, workplace culture, awkward moments, and unforgettable laughter.

Continue reading on ILLUMINATION »

LangChain for Testers: How QA Teams Can Build RAG-Based Test Documentation Agents in 2026

2026-05-21T04:53:46Z

Learn how QA teams can build RAG-based test documentation agents with LangChain in 2026. Step-by-step guide with code, vector DB choices, and retrieval strategies.

The post LangChain for Testers: How QA Teams Can Build RAG-Based Test Documentation Agents in 2026 appeared first on Software Testing & Automation.

Visual Regression Testing with Playwright: A Production-Ready Setup Guide for 2026

2026-05-21T04:37:42Z

Learn how to set up a production-ready visual regression pipeline with Playwright in 2026. Docker, sharding, masks, and CI/CD integration included.

The post Visual Regression Testing with Playwright: A Production-Ready Setup Guide for 2026 appeared first on Software Testing & Automation.