blogs

The Retrospective Nobody Believed In

2026-07-07T16:00:00Z

Team Falcon holds a retrospective every two weeks. Every time, they run out of time. It is too short to get through everything that matters. The check-in gets skipped, the follow-up from last time gets forgotten. Every two weeks, the team shows up, goes through the motions, and moves on, as if attending the meeting is the same as improving.

It is not.

An empty ceremony is worse than none

The brain is a reward machine. Behavior that pays off gets repeated. Behavior that pays nothing back dies out slowly.

Social media knows this well: every like, every reply is a small reward that pulls you back to the screen. A retrospective that consistently produces nothing works the same loop in reverse. You write down what went wrong. Nothing changes. Next sprint, you hit the same wall.

The brain draws its quiet conclusion: this meeting is useless.

People stop thinking about improvement. They fill in the sticky notes because it is expected, not because they believe anything will come of it. At that point you do not have a poorly run retrospective. You have a team that has lost trust in the process entirely.

That is much harder to fix than a time problem.

Four observations, one root cause

It is Owen who says it out loud first. One morning, without making it a confrontation, Owen brings four observations to the daily standup.

Time runs out. Every standup, someone starts a technical discussion and nobody stops it. Fifteen minutes becomes thirty. Fix this by appointing a timekeeper, agreeing on a hard stop, and moving anything technical to a separate slot outside the standup.

Sprint stories get skipped. The TODO column has stories waiting. Nobody picks them up. Instead, team members pull in new stories from the backlog, ones meant for a future sprint. The reason is simple: the sprint stories are configuration work, the backlog stories are coding work. The choice feels obvious. The sprint commitment quietly breaks down. The fix is not a WIP limit. It is a team agreement with one rule: no new stories enter the sprint while there are still stories waiting in TODO. Stick to the plan. If the configuration stories keep getting skipped, that is a separate conversation worth having about how those stories are written and who owns them.

Complex stories are black boxes. Nobody knows what is really inside them until someone picks one up and starts digging. Understanding grows as the work progresses, but the story description never changes. Fix this by making one person responsible for keeping the story content current. If the description is wrong, update it before moving on.

Remote meetings have bodies but not minds. Cameras are on. Attention is somewhere else. Open questions to the group hang in the air because nobody expects to be called on directly. Fix this by asking specific people specific questions, rotating the role of notetaker each meeting, and keeping calls short enough that drifting has a cost.

Four observations, together they point at a single root cause: the team runs without clear agreements, and nobody is keeping them. Not because people do not care. Because the agreements were never properly made or were made once and then quietly abandoned. The retrospective is exactly where these things should surface and get resolved.

Cameras do not create presence

One of the most repeated pieces of advice for remote teams: turn cameras on, and people will be more engaged. At Team Falcon, the cameras are already on.

Priya answers emails from the start of the meeting. Marcus keeps writing while the discussion happens around him. The camera captures their faces. Their attention is elsewhere.

The problem is not visibility. It is engagement.

People drift in meetings because the meeting gives them no reason to stay present. Open questions to the group get ignored. Passive listening becomes the norm. Nobody expects a direct question, so nobody prepares for one.

Structure is what actually helps. Go around the room instead of waiting for volunteers. Ask specific people specific questions. Keep the standup under fifteen minutes with a hard stop. And when someone consistently checks out in a way that slows the whole group down, have that conversation directly, outside the standup.

What Owen changed

Owen does not bring a list of complaints to that retrospective. Owen brings observations, patterns, and questions. That is the difference between venting and contributing.

Naming those four things does not fix the process overnight. It gives the team the words for what was already true. The next step is an emergency retrospective outside the sprint, focused entirely on how the team wants to work. Not sprint content, not new stories. Just one question: how do we want to work, and what do we need to make that happen?

Three concrete agreements come out of it. Not ten, only three:

The daily has a timekeeper and ends at fifteen minutes. No exceptions.
No story moves to “in progress” without acceptance criteria. Every team member holds that line.
Every retrospective starts by asking: what was our action item last time, and what actually happened?

That sounds simple. It is. It also requires someone willing to say what everyone already knows.

Team Falcon’s retrospective was not working. Not because of the tool, the format, or the remote setup. Because nobody had said so out loud.

Until Owen did.

Recent eye-catching testing articles

2026-07-07T13:11:09Z

Pxpipe: The Token-Saving Hack That Turns LLM Context Into Images

2026-07-07T12:17:04Z

A practical deep dive into how Pxpipe reduces Claude Code input tokens by rendering bulky context as PNGs, why the trick works, and where…

Continue reading on Towards AI »

Your Regulatory Time Bomb: When Compliance Theatre Meets Reality

2026-07-07T10:12:57Z

On the opening weekend of this year’s Giro d’Italia Women, Lorena Wiebes won the first stage in a bunch sprint, pulled on the race leader’s jersey, and was disqualified a few hours later. The reason had nothing to do with how she rode. Her bike weighed 6.78 kilograms against a mandatory minimum of 6.8. Her team pointed out that the same bike had been weighed several times already this season, always comfortably above the limit, and that a second weighing on the same day produced a reading fifty grams different from the first. Nothing about the bicycle changed between those two readings. What changed was which number the process happened to catch.

That small, brutal episode is a useful way into a much larger problem sitting inside enterprise technology right now: the difference between passing a compliance check and actually managing risk, and how rarely leadership discovers which one they have until a regulator, an auditor, or an attacker finds out first.

A Pass/Fail Reading Is Not a Risk Assessment

The UCI’s minimum weight rule was introduced in 2000 to stop bikes becoming dangerously light as carbon fibre took over the peloton. Since then, the UCI has built a genuinely thorough safety regime around equipment: frames must be submitted for approval against ISO 4210 structural standards, wheels must pass impact testing, and a clarification guide running to more than eighty pages governs everything from tube dimensions to handlebar geometry. None of that machinery was in question when Wiebes was disqualified. A single scale reading was.

That is the pattern worth noticing. A rule can be strictly enforced, produce a clean binary outcome, and still measure almost nothing about the risk it was originally written to prevent. Twenty grams is roughly the weight of four sugar cubes. It says nothing about whether a frame holds under load on a mountain descent. It says only what the scale read that afternoon.

Compliance theatre works the same way inside a business. A checklist gets completed. A control is marked “implemented.” A privacy policy gets published. The dashboard reads green. Whether any of it says something true about the underlying risk is a separate question, and it is the one that rarely gets asked until something goes wrong.

The Reverse Failure Is Just as Expensive

Sometimes the theatre runs the other way: every box ticked, and the real vulnerability sitting untested underneath. When Meta’s “View As” feature exposed data belonging to 29 million Facebook accounts in 2018, the eventual regulatory finding was not simply that a bug existed. Investigators concluded the breach could have been prevented with more thorough testing of the feature before release. The controls, the sign-offs and the policies had all been present. The specific interaction that let attackers generate access tokens through the feature had not been examined closely enough to catch it.

The financial consequences of that gap between documented compliance and demonstrated risk management keep compounding. DLA Piper’s most recent GDPR enforcement survey put fines issued across a single twelve-month period at €1.2 billion, spanning financial services, healthcare, retail, energy and the public sector. Several 2024 enforcement decisions explicitly cited the absence of demonstrable technical controls, encryption and audit logging as evidence of negligence rather than misfortune.

What Genuine Evidence Actually Looks Like

Professional cycling already runs a working example of the alternative, and it is not the bike-weighing scale. It is the Athlete Biological Passport. Rather than a single test looking for one substance at one moment, the passport tracks a rider’s blood markers over years, building a personal baseline and flagging only genuine deviation from it. The rider becomes their own point of reference. A result only carries weight when it breaks a longitudinal pattern, not when it crosses a fixed external line taken once.

That is the distinction leadership should be drawing between documentation and evidence. Documentation says a control exists. Evidence shows the control holding under the conditions that matter, tracked over time, against the organisation’s own risk baseline rather than a generic template lifted from last year’s audit pack. One is a policy binder. The other is a testing strategy doing its job.

The Forensic Arithmetic

Consider what a mid-sized financial services firm might carry into a serious enforcement action. At the fine levels cited above, a single case can run into eight figures before legal costs, remediation and customer notification are added. Layer on CISQ’s long-standing estimate that the cost of poor quality typically runs 15–20% of revenue in organisations that discover risk only after it materialises, and the arithmetic turns uncomfortable quickly: a business with genuinely tested controls is not spending less on compliance. It is spending the same money on something that actually works.

THE LEADERSHIP QUESTION

“When regulators or auditors ask ‘how do you know?’—can your testing provide evidence, or just documentation?”

The Path Forward

None of this requires an army of new auditors or another layer of governance theatre. It requires testing designed to answer the question a regulator will actually ask, rather than the one a checklist assumes. Previously in this blog, we talked about customer trust as the asset your testing strategy protects; regulatory resilience is the other half of that same asset. Trust built on a compliance function that has never actually been tested is trust you have not yet earned.

The good news, and it is genuinely good news, is that this is within reach. Testing teams that already think in terms of risk are best placed to build it: establish what “normal” looks like for your own systems, track deviation over time rather than relying on point-in-time snapshots, and make sure every control produces evidence a regulator could follow, not just a policy they could read. Organisations that do this do not merely survive an audit. They walk into one already knowing what it will find, because they found it first.

That is worth doing. It is worth doing because the alternative is discovering, the way Lorena Wiebes did, that the gap between a career-defining win and a very public disqualification can come down to twenty grams, a scale nobody recalibrated, and a system nobody thought to test until the moment it mattered most.

Sources:

DLA Piper. (2025). GDPR Fines and Data Breach Survey.
ComplyDog. (2025). Biggest GDPR Fines of 2025.
Cyclingnews, road.cc, Velora Cycling and VeloNews/Outside. (2026). Reporting on Lorena Wiebes’ disqualification from the Giro d’Italia Women, stage 1.
Escape Collective; Sports.legal; World Anti-Doping Agency (WADA). Explainers on the Athlete Biological Passport.
Consortium for Information & Software Quality (CISQ). Cost of Poor Software Quality research. https://www.it-cisq.org/

Test The Feature: Now With Examples!

2026-07-07T07:00:00Z

In my last post, I talked about how it’s more important to test the feature than the single API. Let’s explore this.

In my Bigger Better Bookstore^TM I have a POST API for adding a review:

/books/{book['id']}/reviews

We can write a test like this:

def test_add_review():
    book = requests.post(f"{BASE_URL}/books", json={"title": "Clean Code", "author": "Robert Martin"}).json()

    review_data = {
        "rating": 5,
        "comment": "Excellent book on software craftsmanship!",
        "user_id": "user-1",
    }
    response = requests.post(f"{BASE_URL}/books/{book['id']}/reviews", json=review_data, headers=AUTH_HEADER)
    assert response.status_code == 201

While it looks nice, we know that just checking the status code can be, let’s say very optimistic. Meaning, Even if the status code returns a 201, that doesn’t gives confidence that everything’s ok. So, first we add some checks:

def test_response_values_match_input(book):
    book_id = book["id"]
    resp = requests.post(
        f"{BASE_URL}/books/{book_id}/reviews",
        json={"rating": 3, "comment": "Decent read"},
        headers=AUTH_HEADER,
    )
    body = resp.json()
    assert body["rating"] == 3
    assert body["comment"] == "Decent read"

Here’s a better check. What we sent as an input gets mirrored back to us in the response. But who says the APIs code just does the mirroring and nothing else?

Here’s where “test the feature, not the API” comes in. We’re not really interested in the POST end point. We’re really interested in the book review. So, right now we’re interested in adding it, but the next thing would be to see if we can retrieve it:

def test_created_review_appears_in_book_list(book):
    review = add_review(book["id"], comment="Great chapter")
    reviews = requests.get(f"{BASE_URL}/books/{book['id']}/reviews").json()
    ids = [r["id"] for r in reviews]
    assert review["id"] in ids


def test_created_review_appears_in_all_reviews(book):
    review = add_review(book["id"], comment="Loved it")
    all_reviews = requests.get(f"{BASE_URL}/reviews").json()
    ids = [r["id"] for r in all_reviews]
    assert review["id"] in ids

Not just GET it. See, in the application, we need to see the review at least in two places (which are retrieved by different APIs). The first is in the “show me the all the reviews for this book”, and the other is “show me the reviews of all the books”.

Did I extend the scope? Of course, because the feature extends over APIs. Like a DELETE:

def test_delete_review_removed_from_book_list(book):
    review = add_review(book["id"], comment="To be deleted")
    requests.delete(f"{BASE_URL}/books/{book['id']}/reviews/{review['id']}", headers=USER1)
    reviews = requests.get(f"{BASE_URL}/books/{book['id']}/reviews").json()
    assert review["id"] not in [r["id"] for r in reviews]


def test_delete_review_removed_from_all_reviews(book):
    review = add_review(book["id"], comment="Also gone")
    requests.delete(f"{BASE_URL}/books/{book['id']}/reviews/{review['id']}", headers=USER1)
    all_reviews = requests.get(f"{BASE_URL}/reviews").json()
    assert review["id"] not in [r["id"] for r in all_reviews]

Again, the DELETE by itself is not interesting. The impact is about what happens after the deletion. In our example, it’s that the review doesn’t appear in the two lists.

But, the feature is getting bigger.


def test_no_duplicate_review_ids(book):
    with concurrent.futures.ThreadPoolExecutor(max_workers=THREAD_COUNT) as executor:
        futures = [executor.submit(submit_review, book["id"], i) for i in range(THREAD_COUNT)]
        responses = [f.result() for f in concurrent.futures.as_completed(futures)]

    ids = [r.json()["id"] for r in responses]
    assert len(ids) == len(set(ids))

This test checks what happens when many users call the API at the same time. This check is very simple, that the IDs sent are the same ones received. It can be tightened more, like if they entered on the right order.

The feature does feel a lot bigger than we thought. And part of it is because we’re focusing on number of APIs and status codes. The truth is, features are logical combinations of API calls.

Can there be more?

You betcha. Lot’s more. A small review feature can be tested in many different ways. And we should test it, because that’s the way users are going to call the APIs.

Here are a couple of things to check more

Our review service depends on a moderation service. What happens when the moderation service on goes down?
We checked concurrency for 300 people. Now make it 300,000. Is the server still breathing?
And the one we always forget – can I delete your review? Can you edit mine?

Can there be more? Suggestions in comments, please.

On July 15th I’m running a free webinar – Assertions You Can Trust. I walk through the questions, principles and yes, prompts to create a suite of tests for your features – that you can trust.

Save your seat

The API Testing Masterclass: The Tactician — test design, assertions, debugging, and AI-powered testing. Coming soon.
Join the waitlist

The Strategist Masterclass — Improve API quality strategy at the organizational level.
Join the waitlist

The post Test The Feature: Now With Examples! first appeared on TestinGil.

AI Testing Evidence: Stop Trusting Green Checks

2026-07-07T04:34:34Z

AI testing evidence is the difference between a useful browser agent and a green checkmark that quietly missed the risk.

The post AI Testing Evidence: Stop Trusting Green Checks appeared first on Software Testing & Automation.

The Most Valuable SDET Skill Is No Longer Test Automation

2026-07-07T03:51:00Z

For years, the career path for an SDET was relatively clear.

Continue reading on Medium »

Playwright Upgrade Checklist: Stop Blind Updates

2026-07-07T03:43:09Z

A practical Playwright upgrade checklist for QA teams that want safer releases: read the note, pin the version, run one critical journey, inspect trace evidence, compare screenshots, and ship or rollback.

The post Playwright Upgrade Checklist: Stop Blind Updates appeared first on Software Testing & Automation.

Browser Agent Test Evidence: QA Approval Guide

2026-07-07T03:38:40Z

Browser agent test evidence is the difference between a useful AI browser run and a risky green check. This guide gives QA teams a practical approval model.

The post Browser Agent Test Evidence: QA Approval Guide appeared first on Software Testing & Automation.

Network Throttling and Offline Testing in Playwright

2026-07-07T03:00:00Z

Learn Playwright network throttling and offline testing in TypeScript: offline mode, CDP Slow 3G throttling, per-request delays, and HAR replay.

The post Network Throttling and Offline Testing in Playwright appeared first on Software Testing & Automation.

Looking Behind Playwright’s Magic

2026-07-07T00:00:00Z

A Playwright click looks simple:

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

Chromium, however, cannot click “the button named Submit”. It can only receive input at an x,y position on the page. Before Playwright can send that action, it resolves the locator, determines whether the element can be interacted with, scrolls it into view, calculates its coordinates, and checks that another element will not receive the click instead.

Even so, sending the action is only half the battle. The click may start a navigation, submit a form, open a new page, or trigger network requests. Playwright then needs to coordinate with what the browser does next.

In a previous post, I used several approaches to observe Chrome DevTools Protocol (CDP) network events from Selenium. This time, I followed Playwright’s source to see how it turns those low-level browser signals into the higher-level behaviour behind a click.

There are two paths to examine:

how Playwright prepares and completes the action
how it observes and waits for the consequences.

This article follows the Chromium implementation, where Playwright talks to the browser using CDP. Firefox and WebKit provide the same high-level Playwright abstractions through different underlying code.

All Playwright source links are pinned to commit ad18048 from 1 July 2026.

It starts with a locator

The trail begins in:

packages/playwright-core/src/client/locator.ts

Locator.click() does not perform the click itself. It passes the locator’s selector to the frame and enables strict matching:

async click(options: channels.ElementHandleClickOptions & TimeoutOptions = {}): Promise<void> {
  return await this._frame.click(this._selector, { strict: true, ...options });
}

That is the implementation in locator.ts, lines 113–115.

Those few lines reveal two useful design choices.

First, the locator holds a selector rather than an element fetched earlier. Playwright can resolve it against the current document when the action is attempted. That matters on pages where a rendering framework may remove one node and insert another that represents the same thing. Resolving at action time avoids treating an old element reference as though it were still current.

Second, strict: true means the action expects exactly one match. If the locator resolves to several buttons, Playwright reports an ambiguity instead of silently choosing the first.

I prefer that failure mode. A selector matching several Submit buttons is usually a problem in the test or the interface, not something I want the framework to conceal.

The call then crosses Playwright’s client/server boundary and eventually reaches the server-side element action code in:

packages/playwright-core/src/server/dom.ts

This is where most of the pre-click “magic” becomes explicit logic.

A click may need retrying

The internal click path passes the work into Playwright’s element interaction code. The eventual mouse action is wrapped by _retryAction, which contains a retry loop shared by element operations.

One of the first things it defines is a delay schedule:

// We progressively wait longer between retries, up to 500ms.
const waitTime = [0, 20, 100, 100, 500];

The schedule appears in dom.ts, lines 318–319.

The loop attempts the action until it succeeds, encounters a non-retryable failure, or reaches the surrounding timeout. It handles results such as an element not being visible or lying outside the viewport. The branches are shown in dom.ts, lines 297–314.

This gives us a more useful description of auto-waiting than saying Playwright somehow knows when a page is “ready”. It does not need a universal definition of readiness. Instead, it asks a narrower and more understandable question: can this requested action proceed now?

That distinction matters because many modern pages never become completely inactive. A page may keep a WebSocket open, poll for notifications, or continue loading secondary content after the main interface is usable. Waiting for the entire page to become abstractly “ready” would be both vague and, in some applications, impossible.

For a click, the practical question is whether this particular target can receive this particular action.

What Playwright checks before sending input

For a normal click, Playwright checks several element states, including:

visible
enabled
stable

The Playwright-side logic calls injected.checkElementStates against the target. That path can be followed in dom.ts, lines 432–440.

Each state addresses a different failure mode.

A node being present in the DOM does not mean it has useful geometry. A disabled control may be visible but should not receive a normal user action. A button may be visible and enabled while still moving across the page because of an animation.

The stability check therefore observes the element across animation frames rather than adding the same fixed delay to every action.

This does not make races impossible. The application can always change after a check. Playwright is just reducing a common timing window, not making the browser immune to change.

Once those checks pass, Playwright scrolls the target into view. During retries, it can use different alignments rather than relying on one scroll position. The source comments explain why: a normal scroll may leave the element beneath an overlay, while another alignment may expose a usable point.

Playwright then calculates a x,y coordinate from the element’s geometry.

At this stage it has translated something semantic:

the button named Submit

into something the browser’s input system can use:

a point at x and y

It still has to establish that the point belongs to the intended element at the moment of interaction.

What `force` skips

Following this path also makes force: true less mysterious:

await locator.click({ force: true });

The forced path skips Playwright’s normal actionability logic : the visible, enabled, and stable checks above, along with the hit-target check described next. It proceeds towards dispatching the input without requiring the usual evidence that a user could perform the action.

I would read it as:

Attempt the action without Playwright first establishing user actionability.

It does not make the click more realistic. In fact, it arguably removes checks intended to establish realism.

There are legitimate uses for this, but it can also hide the interesting problem. Perhaps a loading overlay never disappeared, the locator matched a hidden duplicate, or the control remained disabled.

The network side remains separate. If forced input triggers a navigation or network requests, Playwright can still observe those browser events. The question is whether the test still demonstrates an interaction available to a user.

Visibility is not targetabity

A visible element is not necessarily the element that would receive an action.

A loading overlay might be nearly transparent, leaving the button visible to a person while still intercepting the click. An element can therefore pass a visibility check without being the browser’s target.

Playwright uses injected code to check which element would receive the pointer event and to install a hit-target interceptor:

const handle = await progress.race(
  this._evaluateHandleInUtility(
    ([injected, node, { actionType, hitPoint, trial }]) =>
      injected.setupHitTargetInterceptor(node, actionType, hitPoint, trial),
    { actionType, hitPoint, trial: !!options.trial } as const
  )
);

This comes from dom.ts, line 470.

If another element owns the ‘point’, Playwright returns a hit-target description to the outer retry loop. That is the source of errors reporting that a particular overlay or container intercepts pointer events.

The result feeds back into the retry logic, which can decide whether to attempt the click again.

Frames make the calculation more involved because the point must be checked through the frame hierarchy. Playwright performs a separate frame hit-target step before installing the interceptor, but I will leave most of that path unexplored here.

Chromium receives a mouse event

Once the element checks, scrolling, and targetabity succeed, Playwright calls its mouse abstraction with the calculated point.

For Chromium, the final implementation is in:

packages/playwright-core/src/server/chromium/crInput.ts

RawMouseImpl sends the CDP command Input.dispatchMouseEvent.

A mouse move is dispatched like this:

await progress.race(this._client.send('Input.dispatchMouseEvent', {
  type: 'mouseMoved',
  button,
  buttons: toButtonsMask(buttons),
  x,
  y,
  modifiers: toModifiersMask(modifiers),
  force: buttons.size > 0 ? 0.5 : 0,
}));

The implementation, including mousePressed and mouseReleased, is in crInput.ts, lines 104–164.

This is not the same as evaluating the following inside the page:

element.click();

The DOM method invokes the element’s programmatic click behaviour. The CDP route sends browser input at a position.

That difference explains much of Playwright’s action code. Chromium’s input domain does not understand a ‘role selector’ or an ‘accessible name’. Playwright must resolve the semantic target, inspect its current state, and produce valid coordinates before Chromium can act on it.

Now for the other side of the story…

The network path starts in `crNetworkManager`

The Chromium-specific network implementation is in:

packages/playwright-core/src/server/chromium/crNetworkManager.ts

When Playwright attaches a CDP session, it registers listeners for events from the browser’s Network and Fetch domains.

The source includes:

eventsHelper.addEventListener(session, 'Fetch.requestPaused', ...);
eventsHelper.addEventListener(session, 'Fetch.authRequired', ...);
eventsHelper.addEventListener(session, 'Network.requestWillBeSent', ...);
eventsHelper.addEventListener(session, 'Network.requestWillBeSentExtraInfo', ...);
eventsHelper.addEventListener(session, 'Network.requestServedFromCache', ...);
eventsHelper.addEventListener(session, 'Network.responseReceived', ...);
eventsHelper.addEventListener(session, 'Network.responseReceivedExtraInfo', ...);
eventsHelper.addEventListener(session, 'Network.loadingFinished', ...);
eventsHelper.addEventListener(session, 'Network.loadingFailed', ...);

Those registrations appear in crNetworkManager.ts, lines 67–75. The same setup also registers WebSocket lifecycle and frame listeners in lines 79–85.

These are close to the events I accessed through Selenium’s Chrome performance log in the previous article.

The difference is not that Playwright sees an entirely different network or anything like that. It consumes the browser events, handles their ordering and edge cases, and converts them into its own internal model.

CDP does not deliver one tidy request object

It would be convenient if Chromium emitted one event containing a complete request, followed by another containing a complete response. It does not.

Request and response information can arrive through several protocol events. When interception is enabled, Playwright may need to correlate Fetch.requestPaused with Network.requestWillBeSent. Redirects alter request relationships. Service workers can cause expected events to be absent. Additional request and response headers arrive through separate events.

One awkward case appears in _onRequestPaused:

if (!event.networkId) {
  // Fetch without networkId means that request was not recognized by inspector, and
  // it will never receive Network.requestWillBeSent. Continue the request to not affect it.
  sessionInfo.session._sendMayFail('Fetch.continueRequest', { requestId: event.requestId });
  return;
}

See crNetworkManager.ts, lines 245–249.

Playwright cannot wait to correlate that paused request with Network.requestWillBeSent, because the source says the event will never arrive. It continues the request instead.

There is another special case for service workers. In _onResponseReceived, Playwright notes that frame-level requests handled by a service worker may never produce a requestPaused event. It may therefore construct the request when the response arrives. See crNetworkManager.ts, lines 451–453.

Header information has its own ordering problem. The source comment for ResponseExtraInfoTracker says the ordinary request and response events, and their corresponding ExtraInfo events, are dispatched through different unassociated channels and may arrive in any order. The tracker associates them so that the extra headers are reliably available by requestfinished. See crNetworkManager.ts, lines 769–782.

As you can probably gather, there are loads of edge cases like this. Handling them is not glamorous work, but it is a large part of why the public API feels simple compared with working directly against the protocol.

Turning protocol events into Playwright events

Once Chromium’s network events have been associated with a Playwright request, they pass into the page’s FrameManager.

The request path marks the request as in flight, associates document requests with pending navigation, and emits the public request event:

requestStarted(request: network.Request, route?: network.RouteDelegate) {
  const frame = request.frame();
  this._inflightRequestStarted(request);
  if (frame && request._documentId)
    frame._setPendingDocument({ documentId: request._documentId, request });
  // ...
  this._page.addNetworkRequest(request);
  this._page.emitOnContext(BrowserContext.Events.Request, request);
  // ...
}

That code is in frames.ts, lines 329–343.

Responses and completion events are emitted nearby:

requestReceivedResponse(response: network.Response) {
  if (response.request()._isFavicon)
    return;
  this._page.emitOnContext(BrowserContext.Events.Response, response);
}

reportRequestFinished(request: network.Request, response: network.Response | null) {
  this._inflightRequestFinished(request);
  if (request._isFavicon)
    return;
  this._page.emitOnContext(BrowserContext.Events.RequestFinished, { request, response });
}

The implementations, including request failure handling, are in frames.ts, lines 345–356.

This is how low-level CDP events become the public interface used by tests:

page.on('request', request => {
  console.log(request.method(), request.url());
});

page.on('response', response => {
  console.log(response.status(), response.url());
});

page.on('requestfinished', request => {
  console.log('finished', request.url());
});

page.on('requestfailed', request => {
  console.log('failed', request.url());
});

How Playwright implements `networkidle`

The in-flight request tracking lives in frames.ts.

When a request starts, Playwright adds it to the owning frame’s _inflightRequests set. If it is the first active request, Playwright stops that frame’s network-idle timer.

When a request finishes or fails, Playwright removes it. If the set becomes empty, Playwright starts the timer again:

private _inflightRequestFinished(request: network.Request) {
  const frame = request.frame();
  if (this._isExcludedFromNetworkIdle(request) || !frame)
    return;
  if (!frame._inflightRequests.has(request))
    return;
  frame._inflightRequests.delete(request);
  if (frame._inflightRequests.size === 0)
    frame._startNetworkIdleTimer();
}

private _inflightRequestStarted(request: network.Request) {
  const frame = request.frame();
  if (this._isExcludedFromNetworkIdle(request) || !frame)
    return;
  frame._inflightRequests.add(request);
  if (frame._inflightRequests.size === 1)
    frame._stopNetworkIdleTimer();
}

The source is in frames.ts, lines 385–403.

The implementation deliberately excludes favicons and EventSource connections:

private _isExcludedFromNetworkIdle(request: network.Request): boolean {
  if (request._isFavicon)
    return true;
  if (request.resourceType() === 'eventsource')
    return true;
  return false;
}

See frames.ts, lines 405–411.

A favicon is browser housekeeping rather than meaningful application activity. An EventSource connection is long-lived by design, so counting it would prevent pages using server-sent events from ever reaching network idle.

The idle state is also calculated through the frame tree (the main page and its nested iframes). Lifecycle state is recorded on frames, and clearing lifecycle state resets the timer around the remaining current-navigation request. The relevant lifecycle and reset handling can be followed in frames.ts, lines 573–584.

This is honestly a more precise than saying Playwright waits until there are no requests. A closer description may be that Playwright tracks in-flight requests per frame, starts an idle timer when a frame’s set becomes empty, and combines the resulting state through the frame hierarchy.

It also shows why networkidle is not a universal indication that an application is ready.

A quiet network tells us nothing about a CSS animation, a client-side timer, data already queued for rendering, or an application bug that prevented the expected request from starting.

There is another race to solve.

Suppose Playwright dispatched a click and only then began listening for navigation. A sufficiently fast navigation could start before the listener was installed.

The pointer action avoids that race by running the input inside waitForSignalsCreatedBy:

async waitForSignalsCreatedBy<T>(
  progress: Progress,
  waitAfter: boolean,
  action: (progress: Progress) => Promise<T>
): Promise<T> {
  if (!waitAfter)
    return action(progress);
  const barrier = new SignalBarrier(progress);
  this._signalBarriers.add(barrier);
  try {
    const result = await action(progress);
    await progress.race(this._page.delegate.inputActionEpilogue());
    await barrier.waitFor(progress);
    // Resolve in the next task, after all waitForNavigations.
    await new Promise<void>(makeWaitForNextTask());
    return result;
  } finally {
    this._signalBarriers.delete(barrier);
  }
}

That method is in frames.ts, lines 192–207.

SignalBarrier acts as a gate. It keeps the action open until navigation initiated by the click has been acknowledged.

When a frame may request navigation, active ‘barriers’ are retained. When the possible request has been resolved, they are released. If a frame actually requests navigation, Playwright adds that frame navigation to the barrier. See frames.ts, lines 169–189.

The barrier is not a general wait for every network request caused by the click. It coordinates browser signals created by the action, especially navigation. General network observation continues through the network manager and the public request events.

A click may trigger an API request without navigating. Playwright cannot safely infer which arbitrary response represents the business operation a test cares about. The test must express that relationship explicitly:

const responsePromise = page.waitForResponse(
  response =>
    response.url().endsWith('/orders') &&
    response.request().method() === 'POST'
);

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

const response = await responsePromise;

The response wait is created before the click for the same reason as the internal barrier: a fast event must not be missed.

This is why Playwright’s documentation tells us to set up waitForResponse before the action that triggers it. The test applies the same broad principle Playwright uses internally with waitForSignalsCreatedBy: install the listener first, then perform the action.

Connecting this back to Selenium

Following the source changes how I would describe my previous experiment, but it does not make the experiment wrong.

The Chrome performance log approach observed real CDP network events. Playwright’s Chromium network manager listens to the same family of events.

What Playwright adds is a huge coordination layer. It installs protocol listeners, correlates Fetch- and Network-domain events, handles redirects and service workers, constructs request and response objects, exposes them as public events, tracks requests per frame, calculates network idle, and associates page-loading requests with navigation.

My Selenium examples addressed a narrower problem: determine whether network activity appeared to be in progress.

That may be enough for a particular test suite. Playwright needs a heavier implementation because a reusable framework must handle a broader range of browser behaviour, test styles, and edge cases than an application-specific helper.

A network counter also does not address the first half of the problem.

Before a request or navigation can exist, Playwright still has to make the click happen. That requires locator resolution, element-state checks, scrolling, geometry, hit testing, and browser input.

Network awareness cannot tell us that a transparent overlay is blocking a click. Pre-click actionability checks cannot tell us that the expected API response returned the correct data.

They solve different parts of synchronisation.

Wrapping up

We began with one line:

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

Following it through the source reveals two connected systems.

The first prepares and dispatches the input:

resolve the locator
check visible, enabled and stable
scroll the element
calculate a point
check the hit target
dispatch browser input

The second observes what the browser does next:

receive raw request and response events from the browser
normalise them into Playwright's own objects
track which requests are still in progress
emit public events that tests can observe
associate page-loading requests with navigation
wait for navigation triggered by the action
calculate network-idle state across the page and its iframes

These are the browser and network signals I was trying to expose through Selenium in the previous article. Playwright uses the same underlying family of events, but it does considerably more than count requests.

CDP is noisy and sometimes incomplete. Related information arrives through separate events and in inconvenient orders. Requests may redirect, pass through service workers, come from cache, or fail before every expected event appears. Playwright contains the code required to turn that stream into a more stable model.

The implementation also shows why networkidle is only one possible signal. It represents a quiet period in which no tracked requests are active. It does not establish that the application is correct, useful, or ready for the next business-level assertion.

I still do not think the conclusion is simply to choose Playwright over Selenium.

Selenium users can observe CDP events, execute browser-side JavaScript, and build application-specific waits. Playwright has chosen to make more of that coordination part of the framework itself. How much you want buried under an interface is up to you.

The useful lesson is to be precise about what we are waiting for.

Before a click, that may be a stable, enabled, and unobstructed target. After it, that may be a navigation lifecycle event or one specific API response. Sometimes network idle is useful. Sometimes it is the wrong question entirely.

I may still try reproducing Playwright’s “is something blocking the click?” check in Selenium.

I will not be reproducing crNetworkManager. Life is too short!

Did I get something wrong? Have you followed a similar trail through Playwright or Selenium? Please get in touch at joseph@josephward.tech.

We Have a Name for It. We Just Don’t Treat It Like It Matters.

2026-07-06T22:27:02Z

Why your .claude folder is quietly telling you how you actually think

Continue reading on Medium »

Smart Automation Testing Strategies: Why Your Passing Tests Miss Production Bugs

2026-07-06T22:00:00Z

All tests passing. Then production broke. Why happy-path automation creates false confidence. The 4 pillars of smart automation that actually catch real bugs.

The post Smart Automation Testing Strategies: Why Your Passing Tests Miss Production Bugs appeared first on Software Testing & Automation.

My laptop died last week, and here is what it took with it

2026-07-06T21:18:28Z

A few days ago, I accidentally spilled water on my laptop.

It restarted a few times and turned off entirely.

I did everything the internet told me to. Dried it out and didn't touch the power button.

Every repair shop was already closed. So I waited overnight, not knowing if anything on that laptop was still alive.

The next morning, the guy at the shop checked it and said: "The chances of recovery are small. Do you want us to try?"

Until that moment, I had hope. It was just water, not coffee, not something sticky.

But now, all I could focus on was what hadn't been backed up:

My photos
The fixes for the next release of my book
The code for one of my personal projects

Gone. Maybe forever.

Now let me ask you something.

If your laptop died right now, without any warning, what would you lose?

Do you actually back up the things you can't replace?

If you just pictured something you wouldn't want to lose, you’re exactly where I was a week ago. Here’s the simple system I wish I’d had back then:

Start with what you can't replace.
Automate a backup process. A backup you have to remember is a backup you'll forget.
Follow the 3-2-1 rule: 3 copies of your data (the original included) on 2 different types of storage with 1 copy somewhere remote.

If I'd followed step 2, the changes that I made last week for my book would be safe right now.

So here's what I'd suggest.

Tonight, before you close your laptop, pick the one folder you wouldn't want to lose, and copy it somewhere else: cloud, USB drive, anywhere.

That's it. Five minutes. You can build the full 3-2-1 setup this weekend. But tonight, get your irreplaceable stuff to two places instead of one.

Take care of your data (and your drinks near your laptop),

Alex

P.S. I'm writing this from a new laptop.

The repair shop called me back a few days later. They gave me the old one and said there was nothing they could do.

I'm telling you this because "I'll back it up later" was working fine for me too, right until the moment it wasn't.

What the Keeper (or Leader) Knows

2026-07-06T15:29:02Z

I’m not much of a sports-watching person, with one big exception. I watch a lot of non-American football (aka Soccer) - and right now, the whole world is watching the World Cup matches.

I grew up playing a lot of soccer. I stopped playing when I got my first grownup job, but found my way onto pretty good adult teams for a while later in life. I was a midfielder. I liked to run a lot, and I could find space between and around people, and I could make good passes. I understood the game pretty well from that perspective. I knew positioning, my role, and where the players were around me. Then one season I volunteered to play keeper, and I got a new perspective.

Once I got over the pressure of being the last defender with fast and strong people running at me full speed, I began to notice the view. Standing in goal, I could see the entire field in front of me. I could see the shape of both teams, where the gaps were forming, who was out of position, and where the pressure was building before anyone else felt it. I could see things that the players in the middle of the action usually couldn’t see from where they were standing. It’s a role made for people who like observing and thinking.

The other thing I noticed was that seeing wasn’t enough. I had to talk.

The Keeper Never Stops Talking

Watch a goalkeeper closely the next time you see a match, and look beyond the saves. They’re constantly communicating with their teammates. They organize the defense, they warn defenders about a runner sneaking in from behind, or they tell the team to push up or drop back. A good keeper is a constant stream of information, and most people watching probably don’t even notice it.

I found that observation, combined with better communication meant fewer shots. And, even though I may not have been so great at stopping shots, I found that I could prevent a lot of shots from ever happening just by telling people what I was seeing.

The team didn’t need me to make big plays. They needed me to give them information they couldn’t get from where they were playing.

Enough About Sports

When you move into a leadership role, something similar happens to your view.

You’re not the middle of the action the way you used to be. You’re not writing the code, running the project, or doing the work directly. And for a lot of leaders, that loss of direct contribution feels uncomfortable at first. It can feel like you’re less useful than you used to be.

But your view has changed in the same way mine did when I moved to keeper. You can see the shape of the whole system now. You’re in meetings that your team isn’t in. You have context they don’t have. You can see the pressure building from a direction they probably haven’t noticed yet. You can see the gap forming before anyone else feels it.

The question is whether you’re paying attention and communicating.

A lot of senior leaders hoard information without realizing they’re doing it. They may feel like sharing everything is inefficient, or they assume their team already knows, or they’re just so focused on their own decisions that they forget their team is playing the game without the view from the back of the field.

What your team experiences is the equivalent of a goalkeeper who sees an attacker making a run and says nothing. The defender gets beaten because the information that would have helped them was right there and never got shared.

I once worked with a leader who came back from a quarterly business review with a head full of context about where the company was heading. They had more context on the competition, some ideas on leadership changes, some early signals about where investment was going next year. Nothing was urgent, so they didn’t mention any of it to their team.

A few weeks later, one of their senior engineers proposed a significant technical investment that made complete sense given everything the team could see. The leader shot it down quickly. From the team’s perspective, it came out of nowhere. The proposal was solid, and the reasoning was sound. Why would you say no to this? Morale suffered, and people were frustrated.

The leader had context that made the answer obvious. The team had none of it. What felt like a clear decision from their view looked like an arbitrary one from the middle.

What Talking Actually Looks Like

I’m not suggesting over-communicating or holding endless update meetings. It’s about developing the habit of asking yourself what you can see that your team can’t, and then finding the right way to share it.

Sometimes that’s context about a decision that came from above. Sometimes it’s information you’re picking up from another part of the organization that might affect your team’s priorities. Sometimes it’s just telling someone that their work is being noticed by people they’ll never meet, because you were in the meeting when it came up and they weren’t.

None of that is complicated, but all of it requires you to be deliberate about it, because the natural pull is to stay focused on your own decisions and assume the rest will take care of itself. The habit isn't complicated, but it's easy to forget, at work as well as with the people you care about.

The best leaders I’ve worked with had this habit deeply ingrained. They shared information generously. They told you what they were seeing, what they were hearing, and what was coming. They treated their team’s situational awareness as part of their own job, not as a nice-to-have.

I’ve found that a lot of information feels secret, but isn’t secret at all. It’s just not shared.

One of my biggest leadership principles is Transparency. It makes a big difference when your team feels like they know what’s going on.

Watch It

The World Cup will be over in a few weeks. But the next time you watch a match, spend a few minutes watching the keeper instead of the ball. Watch how much they talk. Watch how much of the game they’re running from the back of the field.

At every level, in every organization, the person with the best view has a responsibility to share it.

If you’re not sure your team is getting the view from where you’re standing, that’s worth thinking about. And if you’d like to think through it together, I’d love to talk.

How we switched 150 stores from Redis to Valkey, and nobody cared!

2026-07-06T14:23:30Z

Ever since we started our move from the on-premises data center to the cloud, delivery teams haven’t had to worry about their infrastructure. We’ve built a platform that lets delivery teams focus on solving business problems. At Wehkamp, teams don’t have to worry about Kubernetes, network infrastructure, or writing Terraform code to provision data stores. They don’t even need to know about AWS! Team infrastructure is easily provisioned through our Slack bot. Basically, the teams have been running serverless since 2013!

Having such a platform comes with a peculiar downside: when teams don’t have to care about infrastructure, they usually… don’t!

So what if we want to migrate our AWS ElastiCache Redis stores to Valkey? In this article we’ll explain how we switched 150+ AWS ElastiCache stores from Redis to Valkey.

A big shout-out to Klaas Talsma and Chris Vahl for working together on this story. We started this migration at the beginning of 2026, so this article was long overdue.

Why?

Back in 2024, Redis switched to another license, and that got developers around the world thinking about a fork. Valkey was born in no time! AWS was heavily involved from the start. Honestly, the results were very impressive. And they didn’t stop there, as Valkey 8.1 was released with even more power.

When we read that it was 20% cheaper to run Valkey than Redis, the decision became a no-brainer. So we threw together some slides, gave a Tech Talk, and started adding Valkey to our platform.

This was only the beginning, as these slides are from early 2025.

To sum up: it is faster && cheaper => let’s migrate.

Step 1: Stop the bleeding

Whenever we introduce new technology, we work according to a two-step principle:

Stop the bleeding: make sure newly provisioned infrastructure uses the new technology by default.
Migration: present a migration path and let teams move at their own pace.

Our delivery teams don’t have to write Terraform code (they can); we provide a Slack bot to guide developers to provisioning a data source. Here we swapped out the provisioning of Redis resources for that of Valkey. In the beginning we even kept the Redis icon, but over time that got swapped as well, as the name caused confusion.

The Provisioner provides an easy dialog for Valkey provisioning. In an earlier version you could select Redis or Valkey engines.

Our Provisioner provisions Valkey according to Tech Hub standards, including TLS, authentication, and multi-AZ. It generates Terraform code, commits to the IAC Git repository, creates a PR, and watches it roll out to production, all while keeping the user informed on Slack.

Step 2: Migration

Again, we made some slides:

We made TLS mandatory for our new Valkey setups, which requires application changes.

The usual suspects moved right away, but the bulk of the teams did not migrate 😱. So we talked to the teams to find out if there were any blockers.

Some older services did not use AUTH or a TLS connection, and the teams did not want to refactor those applications to include both features.
Some teams still had their service on a single fascia environment, so they needed to move to a multi-fascia environment before they could benefit from the new setup.
Some teams had very busy backlogs, so they couldn’t prioritize it.

Step 3? Now what?

What could we, as a platform team, do? If we wanted to reap the performance and financial benefits, we needed to make an in-place upgrade possible. Fortunately for us, Valkey is meant as a drop-in replacement.

However, we hit a technical hurdle: our latest infrastructure standards mandate encryption and TLS, but applying those specific enhancements to existing environments would have made an in-place engine upgrade impossible. Fortunately there was a pragmatic solution: we rewrote an older version of the Terraform module, so old environments could also benefit from the new engine.

By testing this extensively on clusters with at least two nodes, we confirmed we could swap the engine under the hood with no downtime, because with a multi-node cluster, there’s always a node left to serve traffic during the switch.

The result was a process so streamlined that teams could migrate to Valkey by updating just a few lines of code:

Only 4 lines need to be changed.

A New Year’s Resolution

The next step was to talk to Koen Roumen, Head of Technology. We explained that there was no reason not to move, and we came up with a plan: either the teams move before a certain date, or we would make the move for them. Maybe it was the optimism that comes with starting a new year, or maybe the stars aligned, but we all agreed on a pretty tight timeline.

We wanted to move within the month.

Again, some teams woke up and moved, but most teams were like: if you’re sure there is no impact, go for it! And so we did. We ran the migration in batches. On the morning of the 27th, we migrated a batch of 47 stores for 6 delivery teams across 3 AWS development environments to Valkey. It went incredibly smoothly. Yes, it took AWS a while to provision the stores (no idea why), but by 9 o’clock we were done. Our delivery teams did not report any problems.

Production was scheduled for a week later. As dev went so smoothly, we dropped our requirement to send a backend engineer to the call, and we decided to start at 09:00 instead of 08:00. Again: one smooth transition.

Step 4: Right sizing

Now that the migration to Valkey was behind us, we shifted our focus from “making it work” to “making it right”. Because our in-place migration kept the exact same instance types that were previously running Redis, much of our fleet was likely over-provisioned. On a number of stores we observed lower resource utilization after the switch.

Valkey runs leaner. Where we saw genuinely lower load after the swap, the engine itself is the likely driver.
Some stores were simply oversized under Redis. Safety margins had been chosen years ago and never revisited. That capacity was “ghost capacity” regardless of engine, the migration was just the moment we finally went looking for it.

To do this well, we started a deep-dive analysis, leveraging LLMs and the AWS CLI to parse two weeks of CloudWatch metrics since the migration. Guided by our FinOps tooling, this data-driven approach identified consistently over-provisioned stores, which we then scaled down, keeping headroom for peaks. It’s a pragmatic approach to cloud spending: optimize the baseline first, so we only pay for the performance we actually use.

So what did we learn?

155 stores migrated, no production downtime, and zero complaints. We switched the engine, we’re seeing the savings, and, just as we intended, nobody even noticed. Great.

Our main lessons:

Valkey really is a great replacement for Redis.
Our delivery teams are very busy, and that’s great! But that shouldn’t stop us, as a platform team, from moving forward. This is where the real benefit of Infrastructure as Code and AWS shows: we can move the whole fleet without asking every team to stop what they’re doing.
There is even more power ahead in Valkey 9.1!

I work as a Pathfinder at the Wehkamp Retail Group, one of the biggest e-commerce companies of the Netherlands. This article is part of our Tech Blog, check it out & subscribe. Looking for a great job? Check our job offers or drop me a line on LinkedIn.

Originally published at keestalkstech.com on June 22, 2026.

How we switched 150 stores from Redis to Valkey, and nobody cared! was originally published in wehkamp-techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The code review bug hunt is dead. Here’s what developers get wrong.

2026-07-06T12:00:00Z

Engineers and experts say code review rarely catches bugs — its real job is flagging code that's painful to maintain later.

Testing Beyond Checks

2026-07-06T11:38:01Z

My ConfQ 2026 Talk

Last week, I had the privilege of speaking at ConfQ 2026 on a topic that has shaped much of my thinking over the past few years:

Testing Beyond Checks: Why Passing Checks Is Not the Same as Understanding Risk.

The session wasn’t an argument against automation.

It wasn’t an argument against CI/CD pipelines.

And it certainly wasn’t an argument against checking.

Checking is essential.

Automation is essential.

Fast feedback is essential.

The question I wanted to explore was different:

What happens when checking quietly becomes our definition of testing?

That question has influenced many of the articles I’ve written here on LifeOfQA. At ConfQ, I had the opportunity to bring those ideas together into one story.

🎥 Watch the presentation below:

The central idea

If I had to summarize the entire presentation in one sentence, it would be this:

Evidence of activity is not evidence of understanding.

Modern engineering teams generate an incredible amount of evidence.

Coverage reports.

Passing automated checks.

Green pipelines.

Defect dashboards.

Release approvals.

These are all useful signals.

But none of them, on their own, tell us whether we truly understand the risks within our system.

Passing checks tells us that certain expectations were verified.

Testing asks a different question:

Were our expectations sufficient in the first place?

That distinction may seem small, but it changes how we think about quality.

What teams really want

No engineering team wakes up hoping to execute more test cases.

Nobody celebrates increasing code coverage by another one percent.

Those things are tools, not goals.

What teams really want is confidence.

Confidence to release.

Confidence to make changes.

Confidence to move faster.

Confidence to make better decisions.

The problem is that confidence can come from two very different places.

One is built on genuine understanding.

The other is built on signals that simply make us feel safe.

Those are not the same.

When confidence becomes dangerous

During the talk, I discussed two well-known incidents: Knight Capital and CrowdStrike.

Different companies.

Different technologies.

Different industries.

Different years.

Yet they revealed a remarkably similar pattern.

The checks worked.

The assumptions failed.

That gap between what we verified and what we truly understood is where many of our biggest software risks hide.

These examples aren’t meant to criticize those organizations.

They’re reminders that even highly capable teams can miss important risks when confidence becomes disconnected from understanding.

Why smart teams still fall into this trap

I don’t believe these failures happen because engineers stop caring.

More often, they’re influenced by normal human psychology.

In the talk, I discussed three ideas that explain why intelligent teams can gradually become overconfident:

Automation Bias – trusting automated results more than our own judgment.
Goodhart’s Law – when a measure becomes a target, it stops being a good measure.
McNamara Fallacy – focusing only on what is easy to measure while ignoring what matters most.

Automation is valuable.

Metrics are valuable.

Dashboards are valuable.

But none of them should replace critical thinking.

So what does testing actually do?

For me, testing isn’t primarily about execution.

Testing is investigation.

Testing is learning.

Testing is reducing uncertainty.

Checking confirms what we already expect.

Testing explores whether those expectations are complete.

Whenever I begin exploring a new product or feature, I keep returning to three simple questions:

What assumptions are we making?
What could seriously hurt our users?
What behavior would genuinely surprise us?

These aren’t test cases.

They’re thinking tools.

Good testing often begins with a better question, not a bigger checklist.

Checking and testing need each other

One misunderstanding I wanted to avoid during the session was the idea that this is somehow an argument against checking.

It isn’t.

Modern software development depends on checking.

Without automated checks, continuous delivery at today’s scale wouldn’t be possible.

But checking and testing perform different jobs.

Checking provides repeatable evidence.

Testing creates understanding.

Quality needs both.

Testing is a social activity

One of the ideas closest to my heart is that testing is not just a technical activity.

It’s a social one.

Quality doesn’t come from a QA team alone.

It emerges from the decisions developers, testers, product managers, architects, designers, and leaders make together.

Testing contributes information.

It creates understanding.

It helps teams make better decisions.

That’s why I believe risk doesn’t live inside test cases.

Risk lives in conversations.

One question I encourage teams to replace in release meetings is this:

“Did all the tests pass?”

It’s a useful question.

But it’s incomplete.

Instead, ask:

“What risks remain?”

That single question changes the conversation from reporting activity to discussing uncertainty.

Final thoughts

If there’s one idea I’d like readers to remember, it’s this:

Confidence is not earned by passing checks. Confidence is earned by understanding risk.

The software industry doesn’t need fewer checks.

We need thoughtful checking.

Thoughtful automation.

Thoughtful engineering.

But above all, we need curious people who continue asking questions that dashboards cannot answer.

Because checks provide evidence.