← All writing

The quality engineer did not disappear when the AI started typing

AI can draft code and tests quickly. Someone still has to decide what correct means, where the risk sits, and whether the evidence is good enough to ship.

I started in quality engineering by writing test plans and running manual cases. Later came automation, deployments, teams, budgets, and release decisions. The tools changed. The awkward question at the center of the work did not: how do we know this does what people actually need it to do?

Now an AI agent can write a respectable test in the time it takes me to find the ticket. I like that. I will happily let it set up fixtures, suggest edge cases, and do the repetitive typing. I have spent enough of my life moving data through a form to welcome a little help.

But the ability to produce a test does not settle what the test should prove.

A generated check can be perfectly faithful to the code and still miss the mistake in the idea. If the implementation assumes the wrong rule, a test that copies that assumption gives us two agreeing pieces of software and one unhappy user. Green is useful evidence. It is not an independent opinion.

I learned that well before AI was writing code. At Array Health, my QA and DevOps organization worked on a health insurance exchange with identity, broker and customer journeys, and payment flows. A change could behave correctly in isolation and still cause trouble where systems or people met. At PACCAR Parts, the team’s software supported inventory, warehouse, logistics, and ordering work. Those are not places where I want to discover that everyone tested the happy path and nobody asked how the change fits the actual day.

I am not claiming an agent cannot ask those questions. A good one can, especially when it has the context. I am saying that somebody has to know which questions matter, check whether they were answered, and own the decision made from the answers. That is quality work.

Sometimes it starts before anyone writes a test. What does “done” mean for this change? Which rule wins when the requirements disagree? What happens when a service is slow, a customer retries, or a person moves between systems? Which failure is inconvenient, and which one means we should stop the release? If the team cannot answer, adding another hundred generated test cases is a very efficient way to decorate the uncertainty.

Then there is triage. I have run defect triage as a QA leader and, later, for the department I managed at PACCAR. A defect list is not a stack of identical obligations. Severity, timing, recurrence, customer impact, and what we actually know all matter. So does the possibility that the report describes a misunderstood requirement rather than broken code. The useful conversation is rarely “How many tickets are open?” It is “What is this telling us about the product and the release?”

AI can help prepare that conversation. It can group reports, look for repeated symptoms, trace a change, or point to a missing test. I want those capabilities. I also want to know where its summary came from, because a confident summary of incomplete evidence is a particularly tidy way to make the wrong call.

As a leader, I have had to build teams and practices that make these questions possible to ask. That includes giving engineers and testers room to challenge a plan, agreeing on entry and exit criteria for testing, and making release risk visible early enough that the choice is real. Quality cannot be assigned to one person standing at the end of a pipeline with a red pen. It is a way the team learns whether the thing it is building survives contact with its purpose.

The agent changes the amount of work we can try. It can also increase the amount of work we must judge. If it produces code, tests, and documentation in a burst, I need to understand which of those are independent checks and which are three versions of the same assumption. Faster output is lovely. Faster confidence requires more care.

So yes, I still call myself a quality engineer, even when an agent does much of the typing. I inspect the evidence. I ask what it leaves out. I decide which risks deserve another experiment and which ones deserve a clear warning. When I lead a team, I make sure those questions can be raised without someone having to win an argument against a dashboard full of green checks.

Let the machine type. I would rather spend my attention on what the green check is claiming.

~ Trish

Join the conversation

Your email address will not be published. Required fields are marked *