blogs

MCA Awards 2026

2026-05-18T07:56:29Z

I am incredibly honored to have been selected by the Management Consultancies Association as a finalist for Chartered Management Consultant of the Year.

While recognition like this is appreciated, it really reflects the people and teams I’ve had the privilege to work alongside throughout my career in software testing. I’ve been fortunate to collaborate with talented, passionate professionals who care deeply about quality, delivery, innovation, and supporting one another through challenging projects.

Some of the work I’m proudest of has never been about technology, it has been about building teams, mentoring people, creating opportunities, and helping others grow into leadership roles of their own.

I’m grateful to everyone who has supported me at KPMG UK for my nomination and the great people in the Quality Engineering and Testing practice run by Daryl Elfield.

Fingers crossed for October!

The post MCA Awards 2026 first appeared on Quality Remarks.

How to perform different mouse click actions using Playwright Java

2026-05-18T07:18:34Z

Learn how to perform different click actions using Playwright Java with best practices, debugging tips, and advanced interactions.

Continue reading on Level Up Coding »

How to perform different mouse click actions using Playwright Java

2026-05-18T07:18:34Z

Learn how to perform different click actions using Playwright Java with best practices, debugging tips, and advanced interactions.

Continue reading on Level Up Coding »

You’re not bad at AI. You’re just bad at talking to it.

2026-05-17T19:43:02Z

Most people blame the tool when the real problem is the conversation.

Every week, someone tells me AI “doesn’t work” for them. They tried ChatGPT. They got a wall of generic text. They asked Claude something specific and it completely missed the point. So they shrugged and went back to doing things the slow way. What’s frustrating is that the capability was always there. The gap wasn’t the AI. It was the gap between what they meant and what they said.

This is the biggest challenge in AI adoption right now, and nobody talks about it plainly. We get articles about which model is best, which tool has the most features, which company raised the most money. But the bottleneck for most people and most teams isn’t access to AI. It’s knowing how to direct it.

The real problem: AI does exactly what you ask, not what you mean

Here’s the thing about working with AI that catches most people off guard. It’s not a colleague who fills in the gaps. It’s not a system that reads between the lines. When you write a vague instruction, you get a vague result. When you write a precise one, you get something genuinely useful.

Think of it like this: imagine hiring a contractor to renovate your kitchen. If you say “make it nicer”, you might come home to bright yellow walls and new cabinet handles. Technically, the instruction was followed. But that’s not what you needed. You needed to specify the budget, the style, which fixtures to keep, what “nicer” actually means in your house. AI works the same way. The quality of the output is almost entirely a function of the quality of the input.

What this means in practice is that the same AI model, given two different prompts for the same task, can produce wildly different results. One version is polished, structured, and saves you an hour. The other is a generic essay that you delete immediately. The model didn’t change. The prompt did.

Most people write prompts like search queries

The habit most people bring to AI is the habit of search. Short. Keyword-driven. No context. That made sense when the goal was to find a web page. It doesn’t work when the goal is to get a specific, usable output from a language model.

A search query says: “email subject lines marketing.” A prompt that works says: “Write five email subject lines for a B2B SaaS product targeting engineering managers. The campaign is about reducing manual QA work. Tone should be direct, no fluff, no exclamation marks. Each subject line under 50 characters.” The difference in output quality is enormous, and the difference in effort is maybe 45 seconds.

The practical shift is learning to think like a director, not a searcher. Before you type anything, ask yourself: what does the AI actually need to know to give me what I want? That usually includes the task, the audience, the format, the tone, and any constraints. Spell it out. You’ll be amazed how much the output improves.

Why effective prompts are hard to maintain

Here’s where the challenge becomes a real business problem and not just a personal productivity quirk. People figure out a prompt that works. Maybe it took them ten minutes of iteration. Maybe a colleague passed it to them. They use it once, it’s great, and then they paste it into a notes doc somewhere or just try to remember it next time.

And then next time, they start from scratch. Or they use a slightly different version and wonder why the output isn’t as good. Or the colleague who wrote the original prompt has left the team.

This is the ROI problem that most organisations haven’t addressed yet. Every time a good prompt gets lost or reinvented, you’re paying the cost of that ten-minute iteration again and again. Multiply that across a team of twenty engineers or a content team running fifty workflows, and you’re talking about hundreds of hours of lost productivity per year. Not counting the inconsistency in outputs when different people run slightly different versions of what should be the same instruction.

The craft of prompting is just the beginning. The operational question is how you capture, organise, version, and share what works.

What a proper prompt practice looks like

Treating prompts as assets rather than throwaway inputs is a mindset shift, but it’s one with a clear return. Teams that manage their prompts well are faster, more consistent, and better positioned to improve their AI workflows over time. The discipline looks a lot like how good engineering teams manage code: with version control, shared ownership, and some governance around what’s in production.

In practice, this means your best prompts live somewhere findable, not buried in a Slack thread or someone’s personal Notion. It means when you improve a prompt, you’re not just replacing the old one; you’re tracking that the new version exists and why it changed. It means new team members don’t need to rediscover what works. They inherit it.

This is exactly the gap that ai-monsoon is built to close. It gives teams a place to store, version, and manage their prompts the way they manage everything else that matters: with structure, access control, and a clear record of what’s being used and why. The prompts that power your AI workflows deserve the same care as the code that powers your product. Right now, most teams treat them as disposable. The ones who don’t will compound that advantage over time.

Talking to AI well is a learnable skill. The frustration most people feel isn’t a signal that AI isn’t useful for them; it’s a signal that the gap between intent and instruction hasn’t been closed yet. Start by writing prompts like a director, not a searcher. Then build the habit of keeping what works. The compounding effect of good prompt practice is bigger than most teams realise.

Sajitha Pathirana is the founder of ai-monsoon, a platform for managing AI prompts securely. Follow for more on prompt engineering, AI workflows, and building AI-native products.

Testing: The Art of Unlearning

2026-05-17T18:39:02Z

In two earlier posts I traced the path from Aristotelian to Galilean thinking as a way of understanding how testing developed as a discipline: how competing models of quality, and the slow maturation of experimental method, gave rise to something we might actually recognize as testing today. This post sits in that same current of thought, but takes a step back to ask a prior question: what is it that makes any of that development so difficult in the first place?

There’s a common assumption about how knowledge grows: we learn things, we add them to what we already know, and understanding accumulates. It’s a tidy picture. It also happens to be largely wrong, at least when it comes to the kind of understanding that actually changes how we see the world.

A more accurate picture is this: the hardest part of learning something genuinely new is not acquiring the new idea. It’s retiring the old one. And the old idea is hardest to retire precisely when it feels most obviously true; when it seems less like an assumption and more like the simple shape of reality itself.

This has direct consequences for testing. A tester who can’t retire their assumptions about how a system works will systematically miss the failures that violate those assumptions. And those are often the most consequential failures of all. The bottleneck, in other words, is rarely evidence. It’s unlearning.

The Dialogue That Wasn’t About What You Think

Galileo’s Dialogue Concerning the Two Chief World Systems, published in 1632, is often described as a defense of the Copernican heliocentric model. That description is technically accurate and almost entirely misleading.

The bulk of the Dialogue is not spent arguing that the Earth moves. It’s spent dismantling the felt certainty that the Earth’s movement is inconceivable. Galileo understood something crucial: you cannot argue someone into a new model while they are still standing inside the logic of the old one.

The geocentric model didn’t persist because people lacked access to better evidence. It persisted because the Earth’s stillness felt like bedrock; not a theory, but a precondition for thought itself. Galileo’s real target was that feeling. His method was to make the geocentric intuition feel, from the inside, like the assumption it actually was.

The Dialogue is structured as a three-way conversation between Salviati (the Copernican), Simplicio (the Aristotelian), and Sagredo (the open-minded layman). The choice of format was deliberate: Galileo wanted to show that the geocentric position couldn’t survive honest cross-examination, not merely that it contradicted new data. The Inquisition’s subsequent objection wasn’t primarily to the astronomy. It was to the implication that orthodoxy was debatable at all.

This is the key intuition for testing: evidence is necessary but not sufficient. What a tester brings to evidence, the assumptions through which they interpret it, determines what they can and cannot see. The question is never just “what does this system do?” It’s also “what am I already certain it does, and how would I know if that certainty were wrong?”

Seven Retirements

The physicist Carlo Rovelli, in his 2023 book White Holes, sketched a compressed history of how humanity arrived at Einstein’s theory of general relativity, which among other things, is the discovery that time itself is not fixed but bends under the influence of gravity. What strikes me about his account is that it reads, on closer inspection, less like a sequence of discoveries and more like a sequence of retirements. Each figure in the chain doesn’t simply add something new. They remove something that everyone had assumed was permanently load-bearing.

If you walk through each part of the chain in order, the pattern becomes hard to miss. So let’s do that now.

Anaximander (sixth century BCE) notices that if the Sun, Moon, and stars revolve around the Earth, there must be empty space below the Earth as well as above it. Which means the Earth hovers. Which means the Earth needs no foundation. At the time, this was not just counterintuitive; it was conceptually vertiginous. After all, everything rests on something. Right? I mean, that’s not a theory, is it? That’s just how things are. Well, Anaximander retired it anyway.

Anaximander is often underappreciated in the history of science, perhaps because his conclusion sounds so obvious to us now. But the obviousness is the point: we’ve already done the unlearning he did. From inside the pre-Anaximander intuition, the Earth hovering on nothing was not a bold hypothesis. It was a category error. It was like asking what’s north of the North Pole. The assumption that things require support was so fundamental it didn’t feel like an assumption at all.

Aristotle (fourth century BCE) observes that during lunar eclipses, the Earth’s shadow falling across the Moon is only slightly larger than the Moon itself. Which means the Moon is not a small bright disc in the sky. It’s a large body, a world, only somewhat smaller than the Earth. The Moon as a distant lamp was retired. The Moon as a place became thinkable.

Aristarchus (third century BCE) contributes what may be the most elegant argument in the ancient world. When the Moon is exactly half-lit, and thus a quarter Moon, the angle between the Sun and the Moon as seen from Earth is nearly a right angle. A triangle with two near-right angles has a very distant third vertex. So the Sun is vastly farther away than the Moon. Yet the Sun and Moon appear the same size in the sky. Therefore the Sun must be enormously larger than the Moon and, Aristarchus reasoned, much larger than the Earth itself. Now, if that’s true, it’s far more natural to suppose that the small Earth orbits the gigantic Sun than the reverse.

Aristarchus arrived at heliocentrism nearly eighteen centuries before Copernicus, using nothing but naked-eye observation and geometry. His argument required no instruments and no mathematics beyond what any educated Greek would have known. What it required was the willingness to follow the geometry wherever it led, even when it led somewhere that felt absurd. He was largely ignored. This is itself a data point about how unlearning works: having the correct argument is not the same as having the argument accepted. The intuition that the Earth is still and central was too strong to be dislodged by logic alone.

Copernicus, Kepler, and Galileo (sixteenth and seventeenth centuries) finally make the heliocentric model stick and not just as a geometric convenience but as a description of how things actually are. And the core retirement here is perhaps the most psychologically demanding of all: the intuition that motion is something we would necessarily feel. We don’t feel the Earth move. Therefore the Earth doesn’t move. Galileo’s inclined planes and falling bodies established the principle of inertia (that uniform motion produces no felt sensation) and in doing so, retired the intuition that stillness and motion are experientially distinguishable from the inside.

Newton (eighteenth century) builds modern physics on the work of his predecessors and makes a move that his contemporaries found almost as unsettling as heliocentrism: he proposes that objects can exert force on each other across empty space, with nothing in between. Gravity acts at a distance. The intuition that forces require contact, that cause and effect must touch, is retired. Something else is present in the world beyond material bodies. Newton called it force. He couldn’t explain how it worked. He simply demonstrated, with devastating mathematical precision, that it did.

Faraday and Maxwell (nineteenth century) discover that Newton was almost right. Forces are not quite instantaneous. There is a lag: small, because light is fast, but real. Something propagates through space, carrying the force from one body to another. Faraday called this something the physical field. It was considered a somewhat mystical idea by many of his contemporaries, some invisible medium filling all of space, transmitting influences. Maxwell wrote the equations for it. The retirement here is the assumption that cause and effect are functionally simultaneous. They are not. The gap is just usually too small to matter.

Faraday’s intuition about fields is worth pausing on because it echoes something from my earlier posts on these topics. Kepler, similarly, intuited that the Sun was the motive power of the universe but couldn’t explain the mechanism. Both men were working at the edge of what their conceptual frameworks could support, sensing that something was there without being able to say precisely what. In both cases, the intuition preceded the formalism by decades. This is a recurring pattern: the unlearning happens before the new learning can be properly articulated.

Einstein (twentieth century) finds, while searching for the equations governing the gravitational field, something he didn’t expect: that the geometry of space and time is not fixed. It’s shaped by the gravitational field itself. Time doesn’t pass at a uniform rate everywhere. Clocks run slower in stronger gravitational fields. Falling is not a force acting on a body; it’s a body following the straightest possible path through spacetime that has been curved by mass. The retirement here is double: the Euclidean geometry we learned in school, and the universal tick of time. Both turn out to be approximations, accurate enough for ordinary experience, quietly wrong at the edges.

What Testers Can Recognize Here

What the above sequence traces, viewed through the lens of testing, is a taxonomy of the kinds of assumptions that become invisible through familiarity. Each retirement maps onto a class of assumption that testers routinely carry into their work without examining it.

There’s the Anaximander problem: the assumption that the system rests on a foundation that may not actually exist. I’ve seen people assume, for instance, that the infrastructure beneath the application is stable, that dependencies behave consistently, that the environment in which we test resembles the environment in which users operate. These assumptions often go untested precisely because they feel like preconditions rather than hypotheses. This is something testers can correct for.

There’s the Aristarchus problem: the assumption that we have correctly estimated the scale and distance of things. I’ve seen people regularly misjudge how far a failure propagates, how large the affected surface area actually is, or how remote a particular edge case truly is from normal operation. Aristarchus followed the geometry and found that the Sun was far larger and farther than anyone had supposed. The same discipline, following the logic rather than the intuition, often reveals that a defect’s blast radius is not where we assumed it would be. This, too, is something testers can correct for.

There’s the Copernican problem: the assumption that we, as observers, are at the center of the interaction. Testers construct test cases from their own mental model of how a user approaches a system. That model is always, to some degree, geocentric: organized around the tester’s own position and perspective. The users who find the most interesting failures are often the ones who approach the system from angles the tester never inhabited.

There’s the Newtonian problem: the assumption that effects are local. A change here shouldn’t affect behavior there. After all, there’s nothing connecting them. Newton’s insight was that the absence of visible connection doesn’t mean the absence of actual connection. Testers encounter this constantly in complex systems, where a change in one component produces failures in a component that appears entirely unrelated. The field exists even when we can’t see it.

There’s the Einsteinian problem: the assumption that the frame of reference is stable. We test in a particular environment, at a particular load, with a particular dataset, and we treat the results as if they describe the system in general. Einstein showed that the geometry of spacetime is not fixed but contextual. A tester’s results are similarly contextual: not wrong, but local. The question is always how far the local result generalizes, and that question is harder to answer than it looks.

Unlearning as Method

It’s worth pausing on a contemporary example before returning to Galileo, because the unlearning problem is not just a historical curiosity. It’s happening right now in testing’s own present.

A recent series of posts on this blog explored what it means to test AI-driven systems, by which is meant systems that are non-deterministic, and where the same input does not reliably produce the same output. The challenge that series kept circling was not primarily technical. It was conceptual: testers reading those posts had to retire the assumption that a test result is a stable, binary thing. Pass and fail, in a non-deterministic system, are not fixed categories. They are probabilistic ones. And that retirement turns out to be genuinely difficult, not because testers lack the intelligence to grasp the idea, but because pass/fail is so foundational to how testing has always felt that questioning it seems less like updating a technique and more like pulling on a load-bearing wall.

That is precisely the Anaximander problem, wearing contemporary clothes. The assumption isn’t wrong because it was foolish. It was reasonable, well-supported by decades of practice, and invisible precisely because it worked so well for so long. Unlearning it required the same thing Anaximander required: following the logic of the new situation wherever it led, regardless of how vertiginous the destination felt.

Galileo’s inclined planes, which I looked at in some of the earlier posts in this History and Science series, are worth returning to here. What made Galileo’s experimental method distinctive was not just that he observed carefully. It was that he designed observations specifically to defeat his own expectations. He recognized that an experiment conducted inside an unexamined assumption will tend to confirm that assumption, not because the experimenter is dishonest but because the assumption shapes what counts as a result worth recording.

The mature version of this, for a tester, is not cynicism about one’s own work. It’s a structured practice of asking: what would have to be true for this test to be misleading? What assumption am I making about the system that, if false, would invalidate this result? What would the Aristarchus version of this test look like, the version that follows the geometry wherever it leads, regardless of where I expected it to go?

Our above sequence ends with Einstein retiring the fixed geometry of space and time. That is, in a sense, the ultimate unlearning: discovering that even the stage on which all events occur is itself a participant in those events, bending and warping in response to what happens on it. The frame of reference is never neutral.

Neither is the tester’s. The assumptions we bring to a system are not a transparent window onto its behavior. They are part of what we are testing. Or ought to be. The discipline of testing, understood in its fullest sense, is not just the discipline of observing carefully. It’s the discipline of becoming a rigorous skeptic of one’s own certainties.

That is a harder thing to learn than any technique. It’s also the thing that, historically, has made the difference between testers (and scientists!) who merely confirmed what they already believed, and those who found something genuinely new.

Where does quality fit in the Product Operating Model?

2026-05-17T17:19:05Z

More software organisations are adopting the Product Operating Model, inspired by companies such as Amazon, Apple, Netflix, Stripe and Spotify.

These organisations are reshaping themselves around product, design and engineering. Teams are being asked to move away from simply delivering features and towards d

iscovering, building and improving products that achieve customer and business outcomes. It shifts the focus from simply shipping things to learning what the right thing is and then building it right.

I think there is a lot to like about this shift, but one thing stands out to me.

In many conversations about the Product Operating Model, there is very little explicit mention of testing, testability or quality roles.

It can sometimes sound as if quality will simply be absorbed by product, design and engineering. But as many of us have seen before, when quality is everyone’s responsibility, it can easily become no one’s responsibility.

So where does quality fit into the Product Operating Model?

What is the Product Operating Model (POM)?

The Product Operating Model is a way of organising around empowered, cross-functional teams that continuously discover, build and improve products in pursuit of customer and business outcomes.

The POM, as it’s often referred to, doesn’t explicitly tell you what to do and how to do it. Instead, it encourages organisations to focus on the problems they want to solve, the outcomes they want to achieve, and the principles that help teams discover and deliver better solutions.

The POM has been popularised by Marty Cagan and the Silicon Valley Product Group (SVPG), which he founded in 2001 after working in product leadership roles at HP, Netscape and eBay.

Why organisations are adopting it

A lot of organisations building software products use engineering teams to build their products. But many of the teams are still following the older, waterfall hangover of projects. Typically, engineering teams are told what to build, and they figure out how to build it. Some people often refer to these teams as delivery or feature teams. These teams are often measured on their output e.g., how many things they shipped.

POM advocates for product teams rather than feature teams. These teams are not simply told what to build. They are given problems to solve, context for why those problems matter, and the autonomy to discover the best solution.

The POM is about empowering teams to own their solutions because they have the skills and abilities to identify what could work and experiment to find what does work. This allows teams to adapt more quickly, rather than waiting for the business to decide the best way forward.

One of the key ways POM tries to support this is through multi-disciplinary product trios, usually made up of product, design and engineering.

The idea is that these perspectives are interdependent. Product brings value and business context, design brings user experience and usability, and engineering brings feasibility and delivery. No one discipline can achieve the outcome alone, so collaboration becomes central to how the team works.

And I’m a big fan of collaboration in engineering teams, but it also raises an important question.

If POM talks explicitly about product, design and engineering, where does quality show up?

But where is quality?

What stands out to me is not that POM rejects quality. The issue is that quality is often implied rather than made explicit.

There is plenty of talk about empowered teams, product discovery, product delivery, outcomes and risk. But there is far less about testing as a learning activity, testability, observability, quality attributes, risk analysis, or the feedback loops teams need to understand whether their products are working safely and well.

This becomes a bigger issue when you remember that POM depends on learning.

Teams are expected to learn what customers need, what solutions might work, what is feasible, what creates value, and whether what they shipped is producing the desired outcome.

But that learning is only useful if the feedback is trustworthy, and this is where Quality Engineering (QE) comes in.

1. QE helps teams learn responsibly during discovery

Product discovery is about figuring out what is worth building before committing too much time and effort. From a QE perspective, this is all about uncertainty reduction.

Quality engineers can help teams ask better questions. Such as:

What are we assuming?
What do we need to learn?
What evidence would increase our confidence?
What could go wrong?
What risks are acceptable in an experiment?
What risks should never be pushed onto users?

This is where approaches like software feedback rings and quality mapping sessions can help. They give teams a way to visualise uncertainty, discuss risk, and decide what kind of feedback they need before they build too much.

When quality thinking is excluded from discovery, teams often discover risks later as incidents, rework, and “how did we miss that?” conversations.

2. QE helps teams build confidence during delivery

Once a team has evidence that something is worth building, the question changes.

It is no longer only “is this the right thing?” It becomes “can we build this in a way that is reliable, accessible, observable, secure, maintainable and safe to change?”

This is where QE can help teams design better delivery feedback loops.

That might include improving testability, shaping automated checks, supporting exploratory testing, making release risks visible, improving observability, using feature flags, and helping teams build confidence through small, frequent and reversible changes.

The aim is not to slow delivery down. It is to connect delivery speed with confidence.

When quality thinking is missing from delivery, teams can end up with shallower feedback loops. Small issues are missed, risks combine, and the first meaningful signal may come from production incidents.

3. QE helps teams make quality visible

If product teams are accountable for outcomes, they also need to understand what quality means for the product they are building.

Reliability, performance, accessibility, privacy, resilience, usability and trust are not side concerns. If these things are poor, then it does not really matter how good the product idea is. People may still struggle to use it, trust it, or keep coming back to it.

Quality Engineering can help teams make these quality attributes visible earlier, connect them to stakeholder value, and decide which ones matter most for the product, the users and the organisation.

4. QE helps teams learn from failure

POM relies on teams learning quickly. But teams only learn quickly when it is safe to surface bad news, discuss uncertainty and treat failure as information.

In complex software systems, failure is not always a sign that someone did something wrong. Sometimes that failure is preventable. Other times, it is informative because it tells us something about the complexity of the system.

Quality engineers can help teams develop a more nuanced view of failure, so they are not just trying to avoid it, hide it or blame someone for it.

The goal is to learn from failure in ways that improve the product, the process and the system around the team.

POM does not remove the need for quality thinking

A Product Operating Model does not remove the need for quality thinking. If anything, it increases it.

When teams are given more autonomy and accountability, they need stronger ways to understand risk, test assumptions, observe behaviour and learn from what happens.

Quality Engineering can help make that possible.

Not by acting as a gate at the end of delivery, but by helping teams build quality into discovery, delivery, operations and team decision-making.

If POM is about helping teams learn faster, QE helps make that learning safer, deeper and more trustworthy.

If this way of thinking about Quality Engineering is useful, you can subscribe to get future posts on testing, feedback loops, engineering culture and building quality into teams.

Subscribe now

Non Timebound nature of Software Quality

2026-05-17T10:19:00Z

Usually, usuallY it is easy to only talk about the times where software fails. And then try to learn from the event. And in a way, events are always messy. A hacker getting into and deleting your work for example is one event that is truly frightening. Should software testing be frightening at all you can hear yourself say. Surely software engineering is a sedate process of correcting wrongs one at a time. Considering the impact of one line of code here, removing another line or condition that no longer makes sense. The line that made sense at the time, but now it no longer does. So an engineer will try also to pre-empt a failure.

The requirements versus the Yaymo Spec

A software tester will take a higher view, at the behaviour level of the system, and use the oracle of past behaviours memorised, and find newer ones that now offend. We do this by exploring, not by using AI to generate lists of test cases. Especially necessary since if the product itself has an AI core, using any AI tooling would easily become a case of a scholar marking their own homework. The tester in me for example makes mental and paper notes. Suggesting the eradication of an old behaviour will require the tester support their request for a bug fix with some proof. Proof that the product will be better somehow afterwards. But UsuallY only slightly better, because the tester also knows that every fix also has the possibility to break things. Things that are not visible at the surface.

Waymo washed away

I'm pretty sure they tested everything they were required to at the time. Software does not exist in a vacuum. Time is an untestable dimension to quality. So is water. We only know what we know, at the instant in time, that has usually past. Water can be ice, and it can be steam or fog. Trying to teach an AI something it cannot grasp merely points to needing a human to make domain decisions that decide which domains are really useful.

So companies hire software testers, in the hope they will increase the body of knowledge just in time before the creek floods and their car drives into it and is written off. Waymo probably were unable to make an insurance claim. I'll bet the age old "act of god" clause absolved the insurer. They certainly have a negligence defence. So the tester adds yet another test, can we drive the car into a flooded road. We assume they already test for the Whil E coyote painted road diversion trick, that never nets the wily canyon criminal a meal of road-runner.

Limit capabilities at the right point in product life cycle

I can only imagine a manager somewhere 20 years from now will ask, why do we have to test for that? It never rains around here. And the manager would be right, at least for the time being. You should also never know all of the defects in a product. That is especially true when a product initially launches. In the early days, testers can easily introduce so much defensive coding, that it can either hobble the vision or exhaust the developers. Imagine if that developer was not a human, but was an AI, the product might then have no friction at all to making bug-fixes which suddenly mean that your boat-car design, may in fact end up only being able to drive on roads because you raised too many water based bugs. And then your amphibious car might later-on fail proper sea-trials. The mind boggles.

Any similarities are intended

What Tools to Learn for Testing?

2026-05-17T09:46:52Z

Over the years I've seen, heard, and been in many conversations about the tools testers must learn. So many specific tools mentioned in that time, but I prefer an answer like this:

Learn the tools that are important for your context.

Perhaps that sounds like a cop-out, because it means testers will have to think about what they're doing, why they're doing it, the results they want to get from it, ways that they might get those results, the relative trade-offs of alternative approaches, how deep to go, the amount of time it's worth investing, when to invest it, and so on.

Tough.

There are easier alternatives. For example, just learn whatever tools someone on LinkedIn said that someone else on Linked said that someone else on LinkedIn said that someone else on LinkedIn said that ...

But that's a merry-go-round anyone would soon want to get off.

If you were asking the question and urged me to be specific I'd point you to My Favourite Tool.

If you read it and then continued nagging me for something very specific I might say to learn just enough of the key tooling that other people on your team use: IDEs, source control, visualisation, monitoring, etc. Those things are all gateways to information below the surface of your application and give you interactional expertise, which in turn greases the wheels of respect and collaboration.

I could ask you to think about the information you'd like to be able to have to do your job better but currently don't have and to research tools that could get it. You could consider using a tool that can help you to build the tool you need, or team up with someone who already knows that kind of tooling.

Maybe I'd also suggest that you keep an eye on what's happening elsewhere in your company, the industry, and the world. You might be looking for a job at some point: what do you think you would need to be able to say or demonstrate to make yourself marketable? What role do tools play in that, and to what extent?

Finally I'm pretty sure I'd ask what you'd like to learn about, just for yourself, for your own interest and satisfaction. And I'd suggest you try to find a way to do that in your work, where it's justifiable enough for some task.

By this point, though, I'd hope you'd see that in these answers I'm merely helping you to do what I suggested at the start: look at your context(s) and find the important tools.
Image: Emine Karakurt on Unsplash

Why a test column on boards is a problem

2026-05-17T08:01:00Z

I often see on boards columns like “Open”, “Dev” or "In Progress" (but still just being for developers) and next to them “Test” or “QA.”. And ticket moving through it and handovers happening between columns. Developers stop working once they are done (with a first version) and testers just start once they got the ticket handed over. Sequentially working on it instead of doing it in parallel where doable.

In this article, I explain why I see this structure as a problem, how it can cause issues if enforced, and what possible alternatives exist.

This is an updated version of an already existing article. Also available in German.

You can use a test column on your ticket board when

… only one task can be carried out at a time at that ticket. Development XOR Testing.

The notion that testers can only begin after development has started is based on the misconception that testing is reduced to mere interaction with the product. Like an executable (of a very final version) to exist would a precondition for any testing work.
As if no preparatory work were possible, or as if interaction with the product could not take place in parallel with development (e.g., at various intermediate stages).

A command-and-control mentality may be another root cause. This is not conducive to constructive collaboration and rapid feedback.

Some models of actual workload

This are some simplified models of what I observe regular. Reality is way more complex.

When is a ticket changing from the Dev to the Test column by this distribution of the work???

=> Test after Dev is a problem

Testing benefits from preparation

Gathering information, planning (e.g. coverage and approaches), preparing test data and tools and many other are tasks in testing which can be done/started without an actual product - before or while the code is written.

What are good reasons to postpone this until the development of the first version is done? Aside from a lack of time.
It would be a waste of time and being a risk by extending the feedback time for the developers.

=> Test after Dev is a problem

Testing can be integrated into development

Here are two examples from my daily work where I’ve collaborated closely with developers, and we couldn’t even say for sure which column a ticket was currently in.

Pair / Ensemble testing with developers on their computers. They showed me the application, and I advised them on what to try. During these sessions, my colleagues made code changes and, when necessary, rebuilt the application so they could test it again immediately.
I can build and deploy the product locally myself. With this setup, developers send me code changes at short intervals (git push & pull), which I then test within minutes—often while we’re on the phone or chat.

=> Test after Dev is a problem

Testing can be done in parallel to development

It happens frequently that I interact with the product while in parallel developers still code by to basic scenarios:

They start fixing bugs while I continue testing.
I start testing not yet fully developed features where we agree on that I should just look at specific places. Early feedback. I test while the developers code.

=> Test after Dev is a problem

What about tickets?

All above is true no matter how your work is organized.

Bug tickets - Testing is here first (and also last)

Bug tickets in general about that someone found a problem, aka tested, and reported that. And often, especial when coming from the customer, they describe mostly symptom and don't give a good manual of how to reproduce and exact details.

A tester has to find out the scenario and causes, then developers (try to) fix it and finally it needs a test of the fix (and maybe some more loops).
Would this ticket start in a test column and the switch back to dev? …

Test needs to act first.

=> Test after Dev is a problem

Single ticket for multiple people

Somehow you just a have single ticket, but multiple people (can) work at in parallel. Maybe you use sub tasks, but you use them per sub topic and not per task / craft.
The people can be only developers, testers or a mixture of both. To which column would you put such ticket, especial at the mixed case?
And e.g. in Jira a ticket can only have a 1 assignee

=> Test after Dev is a problem

Summary

Testing and development are tasks that can generally be carried out in parallel. Just because no code has been written yet doesn't mean that testers have nothing to do.

Also they both are a feedback loop:

Testing informs (at least) development and (at least) development gives testing something to interact with.

This loop can be run several times in a few minutes.
Feedback is sooner better than later. If developers have already switched contexts, it takes them longer to get back on track.

Every ticket in a issue tracker is a (simplified) model of a more complex reality.
Especial only one assignee possible is often far from reality of team work.

Alternatives

Here are some ideas what to do instead.

Task oriented:
- Add a list of tasks in the ticket and add names to them. Here goes the same for state.
- Use sub tasks and assign them. They have already a state field. I suggest to have a simple workflow here.
People oriented:
- Note in the ticket all people who are working on it.
  - You can add a state by a word or icon to show who is still working and who is finished.
Some ideas what task you could add for testing:
- - Prepare X, Test Y, Review/Debrief Z
    - When testing covers multiple, separate topics and people you can add multiple test sub task.
  - When using Session-Based Test Management (Wiki, Article) you can create a sub task for every session
  - Need to prepare data ? Need to develop or enhance a tool? Need to learn the product? Need to … whatever? Add a task.

Others say the same - further articles

There are multiple people advocating the same goal.

Bart Vanherck: You don't need a test column
Ben Linders: Deliver Faster by Killing the Test Column
Daniel Knott: Delete The Test Column
Katja Obring: Kill That Test Column
Wayne Roseberry:
- A "testing" column represents testing as a monolithic black box. It says nothing of what the testing work is or offers any notion of how long it ought to take.
  I like the way session-based test management breaks testing into visible, easy to schedule activities. I prefer testing being a mix of either be an assumed part of doing the development work, or the testing sessions on the schedule as explicit activities with their own card moving across the status columns.
Ben Fellow
- The test column often doesn't make much sense when the dev column isn't even the "dev" column, but "in progress", like testing doesn't mean the task in still in progress. It makes even less sense when you consider development still goes on in the "test" column due to bug fixes or further changes. If anything, the test column should be at least "testing and potentially some more development still".Removing work items from the board altogether and reducing status columns to just "Todo > WIP > Done" with sub-tasks for all activities related to the work item is so much better, and allows multiple different activities assigned to different people in a team that can be completed at the same time.

What would you add? Contact me how you want to. I would like to read any opinion.

Published on LinkedIn

Machine Learning Pipelines: The Backbone of Reliable AI Systems

2026-05-17T00:00:00Z

Written by - Millan Kaul

Machine learning pipelines turn raw, messy data into deployable models through a repeatable set of automated steps. In practice, the pipeline is what makes ML usable in the real world, because it connects data ingestion, preprocessing, training, evaluation, deployment, and monitoring into one reliable flow.

Opinion: Without a pipeline, ML is mostly experimentation. With one, it becomes engineering.

Core Pipeline Stages

Why ML Pipelines Matter

A data pipeline moves information. An ML pipeline goes further and operationalizes model development.

That matters because ML systems break easily when preprocessing changes between training and inference, when experiments cannot be reproduced, or when models drift after deployment. A pipeline reduces those risks by making each step explicit, testable, and repeatable.

Automation removes manual glue code.
Consistency keeps training and inference aligned.
Scalability supports more models, more data, and more environments.
Reproducibility makes experiments easier to compare and debug.

Data Collection and Ingestion

This is where data enters the system from databases, APIs, files, logs, or streaming sources.

The goal is not just to collect data, but to bring it into a centralized, reliable format that downstream stages can use without manual cleanup.

Preprocessing and Cleaning

Raw data is rarely model-ready.

This stage handles missing values, duplicates, malformed records, outliers, and noisy entries. It also ensures the same cleaning logic can be reused later during inference.

Feature Engineering

Feature engineering turns raw fields into useful model inputs.

That can include normalization, scaling, categorical encoding, text vectorization, aggregation, or domain-specific transformations. Good features often matter as much as the choice of algorithm.

Model Training

This stage fits a model to the prepared data.

In many workflows, it also includes hyperparameter tuning, cross-validation, and experiment tracking so teams can compare versions and understand what changed.

Evaluation and Validation

A model is not ready just because it trains successfully.

It must be tested on separate data to measure accuracy, robustness, and generalization. This is where teams catch overfitting, bias, and weak performance before deployment.

Deployment

Once validated, the model is packaged and moved into production.

Deployment can mean a real-time API, a batch scoring job, or an embedded service inside a larger system. The key is that the model now produces predictions for users or applications.

Monitoring and Maintenance

Deployment is not the finish line.

Models degrade as data changes, behavior shifts, and real-world conditions evolve. Monitoring checks for data drift, performance degradation, and pipeline failures, then triggers retraining or alerts when needed.

Sample ML Flow

Raw data -> Cleaning -> Features -> Training -> Validation -> Deployment -> Monitoring

Code

Sample ml_pipeline_flow.yaml would look something like this

# File: ml_pipeline_flow.yaml

ml_pipeline:
  raw_data:
    source: warehouse
  cleaning:
    steps:
      - remove_nulls
      - deduplicate
  features:
    steps:
      - normalize
      - encode_categories
  training:
    model: xgboost
  validation:
    metrics:
      - accuracy
      - f1_score
  deployment:
    target: api
  monitoring:
    checks:
      - data_drift
      - performance_drop

A simple customer-churn pipeline might pull usage data, clean missing values, encode customer segments, train a classifier, validate it against holdout data, deploy it to score active users, and monitor whether predictions start drifting over time.

Common Tools

Different teams use different tooling depending on scale and complexity.

Scikit-learn for simple in-memory pipelines in Python.
Apache Airflow for orchestration and scheduling.
Google Vertex AI, Azure Machine Learning, and AWS Step Functions for managed cloud pipelines.

What Good Looks Like

A strong ML pipeline is modular, versioned, observable, and repeatable.

Modular means each step has a clear job.
Versioned means data, code, and models are tracked.
Observable means teams can see failures and performance changes.
Repeatable means the same inputs produce comparable outputs.

ML Pipeline Checklist

Ingest data from trusted sources.
Clean and validate inputs before training.
Reuse preprocessing for inference.
Track experiments and model versions.
Validate on separate test data.
Deploy with a clear rollout strategy.
Monitor drift and performance continuously.

Machine learning pipelines are the backbone of reliable AI systems. They take ML out of the notebook and turn it into something teams can run, trust, and improve over time.

A good model is important. A good pipeline is what makes that model dependable.

Book Review: Contract Testing in Action

2026-05-16T12:27:22Z

Review of "Contract Testing in Action: With Pact, PactFlow, and GitHub Actions" book written by Marie Cruz and Lewis Prescott

What to read from testing and engineering (2025 edition)

2026-05-16T12:27:22Z

Best IT books I`ve read in 2025

One simple step to use AI more effectively as a tester

2026-05-16T12:27:22Z

One forgotten aspect of using AI for testing and learning

Test Automation Framework or Test Automation Solution?

2026-05-16T12:27:22Z

What is the difference between framework and solution?

What to read in test automation?

2026-05-16T12:27:22Z

A curated list of good books for test automation engineers

Paper Review: Software Testing Research Challenges: An Industrial Perspective

2026-05-16T12:27:22Z

An overview of the current state of software testing and open research questions

Why do we fail at interviews?

2026-05-16T12:27:22Z

Why do we fail at interviews and what we can do about it

AI tools and how they kill learning

2026-05-16T12:27:22Z

Pros and cons of using AI tools (for beginners)

On choosing what to learn

2026-05-16T12:27:22Z

How I learn or treating learning as a project

What I read this summer - 2024

2026-05-16T12:27:22Z

Few books that I read during summer 2024

blogs

MCA Awards 2026

How to perform different mouse click actions using Playwright Java

How to perform different mouse click actions using Playwright Java

You’re not bad at AI. You’re just bad at talking to it.

The real problem: AI does exactly what you ask, not what you mean

Most people write prompts like search queries

Why effective prompts are hard to maintain

What a proper prompt practice looks like

Testing: The Art of Unlearning

The Dialogue That Wasn’t About What You Think

Seven Retirements

What Testers Can Recognize Here

Unlearning as Method

Where does quality fit in the Product Operating Model?

What is the Product Operating Model (POM)?

Why organisations are adopting it

But where is quality?

1. QE helps teams learn responsibly during discovery

2. QE helps teams build confidence during delivery

3. QE helps teams make quality visible

4. QE helps teams learn from failure

POM does not remove the need for quality thinking

Further reading

Non Timebound nature of Software Quality

Limit capabilities at the right point in product life cycle

What Tools to Learn for Testing?

Why a test column on boards is a problem

Table of Contents

You can use a test column on your ticket board when

Some models of actual workload

Testing benefits from preparation

Testing can be integrated into development

Testing can be done in parallel to development

What about tickets?

Bug tickets - Testing is here first (and also last)

Single ticket for multiple people

Summary

Alternatives

Others say the same - further articles

Machine Learning Pipelines: The Backbone of Reliable AI Systems

Why ML Pipelines Matter

Data Collection and Ingestion

Preprocessing and Cleaning

Feature Engineering

Model Training

Evaluation and Validation

Deployment

Monitoring and Maintenance

Sample ML Flow

Code

Common Tools

What Good Looks Like

ML Pipeline Checklist

Book Review: Contract Testing in Action

What to read from testing and engineering (2025 edition)

One simple step to use AI more effectively as a tester

Test Automation Framework or Test Automation Solution?

What to read in test automation?

Paper Review: Software Testing Research Challenges: An Industrial Perspective

Why do we fail at interviews?

AI tools and how they kill learning

On choosing what to learn

What I read this summer - 2024