AI did not break testing. We were already stuck. Watching QA argue about titles while AI becomes the new panic topic feels familiar.  We already know how to deal with uncertainty and risk. We just keep choosing not to apply it.

The “AI reviewing AI is marking its own homework” argument is based on an incorrect analogy. Most poor AI output starts with vague prompts. Reviewing with clear, narrow criteria can be useful, because AI is good at scanning volume when the rules are explicit. Do you let AI review AI?

The problem with many AI written tests is not that they are “wrong”. It’s that they are not all that useful. When teams are told to “just use AI”, they often skip the thinking step that normally shapes good test design. 

I rage quit a project after an AI “simple UI reskin” rewrote half my system. The issue wasn’t the model. It was vibe coding without constraints. Fast output, eroded structure, invisible scope creep. But I didn't ditch the AI. 

AI can generate test cases fast, which is why judgement matters more, not less.  If you can’t name the decision, the uncertainty, or the constraints, AI will give you volume instead of confidence.  How do you tell activity from evidence in your team?

Forensic analysis of objective video evidence. This is how you serve readers searching for clarity.

AI use often focuses on the tool. The bigger question is where human judgment adds the most value. Framing the problem, setting constraints, and deciding when an answer is good enough are still human responsibilities, especially when risk matters. Where do you see the highest leverage?

If a tool promises to remove human judgment, that should worry you. In software work, judgment is how teams manage risk and trade-offs. AI can support thinking, but once it starts deciding what is good enough, the reasoning becomes harder to see and harder to question.

Merry Christmas if that’s your jam, or happy holidays if you’re just enjoying the quiet and some marzipan. I’m signing off for cheese, films, and beating Godrick. Have a great break, however you spend it. See you next year. *Of course the image is AI created. Helga would never wear a Santa hat.

AI in testing isn’t just shiny tooling. It comes with real traps: de-skilling, burnout, liability gaps, and vendor lock-in. I made a short infographic with the six risks I see most often. AI can help, but only if you understand the trade offs before you adopt it.

Final day to join the course. Five short lessons that unlock one per day and help you explain why something matters. As AI speeds up testing, clarity is becoming the real differentiator.

If you have ever worried that you do not have time to improve communication, or that your team will not change, you are not alone. Five short lessons can help.

Many testers tell me the same thing. They raise good points, but nothing changes. The issue is not skill, it is communication. If you want simple patterns that help people listen, I built a five day course for that:

If you feel unheard at work, try this shift. Not “We found a bug.” Say “This could create extra rework for dev and test. Can we look at it together.” It moves you from reporting problems to protecting outcomes.

If your team is arguing about AI in testing, you might be solving the wrong problem. Instead of debating the future of the profession, focus on a single, current pain. No need for a new philosophy. Just a small, contained trial and a clear yes or no at the end.

Most teams ask the wrong question about AI in testing. The real question is whether it improves quality outcomes in a measurable way, and if it does not, it is just noise.

The most useful question about AI in testing is not ""Will it replace testers?"" but ""Is it improving our quality outcomes?"" You only get that answer if you treat AI as an experiment, not a belief system.  What is one metric you would track to decide whether an AI testing tool is worth keeping?

Stakeholders ignore testers not because the insights are wrong, but because the language often doesn’t match how decisions get made.  I’ve made a free cheat sheet, here's the link:

“Two hours to test a two‑day dev task” sounds like a moan … until you have data. Measure wait time before testing and bugs after code freeze. Then try a 2‑week rule: no story enters dev without test scenarios. What is stopping you from trying that?

I've been thinking about how AI fits into my actual work, not the hype, and NotebookLM after ignoring it for ages.  Curiosity sometimes turns into very convenient procrastination, and I learned something to boot. 

Blame cultures in software rarely come from bad people. They come from invisible systems. When quality issues hit production and all eyes turn to QA, it is usually a sign that the team has no shared view of how work flows or where risk accumulates. What new metric would you pick to expose this?

Had a team with flaky booking workflow tests. Classic noise. No one cared. So I stopped talking about test failures and talked about rollback risk during peak traffic. That got attention fast. Now we were solving the same problem. Developers tune into outcomes, not artefacts.

Some teams normalise chaos. I saw one where every sprint had vague stories, rework, Thursday panic. Nobody questioned it. Turns out the problem was upstream. Different assumptions. Missing detail. Rework baked in from the start. Quality signals hide in the friction everyone ignores.

Refinement moment last week. Dev says, “Something feels off.” Old me would chase AC. New me asks, “What breaks downstream?” It’s the small questions that change how people see your role.

The most valuable QA skill isn't technical - it's knowing how to ask the right questions at the right time. Quality is about perspective, not just process.

Video gamers have known for ages that spiders live in colonies in caves. Finally science has caught up! euroweeklynews.com/2025/11/08/w...

Most teams have dashboards full of quality metrics that no one outside QA actually cares about. That’s not because the metrics are wrong. It’s because they don’t speak the language of outcomes. I used NotebookLM to create a video from my framework, check it out here

Had a chat with some fellow testers about why so much advice online feels dated. The internet never forgets, and AI keeps recycling what it learned from the past.

I built Stakeholder Ready for that moment when you see something that matters and hesitate to speak. It is a short, practical course that helps testers find their voice and speak with confidence when it counts. Get notified when it launches (soon): courses.kato-coaching.com/stakeholder-ready

The hardest part of being a tester is not finding the problem. It is having the confidence to speak up in a way that gets heard. Confidence is not about being louder. It is about being clearer. That is what Stakeholder Ready is about: courses.kato-coaching.com/stakeholder-ready

Have you noticed how easily testers get boxed into “support” roles, even when they are driving real decisions? It often comes down to language. If you link your insight to a business outcome, people start listening differently. Sign up here courses.kato-coaching.com/stakeholder-ready

Have you ever shared a concern about quality, only to watch the conversation move on as if you never spoke? The problem is rarely skill. It is translation. Turning what you see into something others care about is the real challenge. I have been working on something to help with that. More soon.

After two days at home I'm now in Copenhagen for the #ISTQB GA, and to meet my workgroup for the Quality in DevOps syllabus, which is now officially on the ISTQB homepage and is currently in it's beta review phase.  Exciting times!

It's almost time for my presentation "Your metrics are lying", and I am excited to present this new thing here today: a lightweight framework that can shape how you use metrics to actually learn stuff.  #hustef #hustef2025

A lovely day in Budapest, and I have a few free hours to enjoy the beautiful weather. Tomorrow it’s #hustef time!

Everyone’s talking about how AI will change testing. But I think we’re asking the wrong question. I’ve just written about why the future belongs to testers who learn faster than they code.

I just taught my new workshop, We’re not Spotify: Imperfect Metrics. The big takeaway? AI can generate more data than ever, but it can’t tell you what matters. That’s where testers add real value. Not in counting bugs, but in translating data into decisions.

I’ve just come back from two testing conferences, and nearly every talk circled the same question: How do humans add value in an AI-driven workflow? AI gives you data. Humans give it direction. The future of testing isn’t automation, it’s discernment.

So much good stuff yesterday! And it turns out I'm not at #testBash2025 at all, I'm at #MoTaCon2025.  Congrats to everyone for being present at the birth of something great!  #motaverse @ministryoftesting.com

Tell me where I am without telling me where I am. #testbash2025

I'm looking forward to running my new workshop "We are not Spotify: How to do metrics in smaller teams" at #TestBash2025 on Thursday morning. If you've wondered what metrics you can collect to assist your team improve quality, do come along.

Today I'm playing with temporal to build an AI agent, and it's ... interesting. As usual, setting up the project takes about 10 times longer than it should (how does that never change??), partially my own fault because of an incomplete docker uninstall. Sigh. #temporal #aiAgent #hobbyCoder

Testers often ask me: “Why don’t people listen when I raise important points?” It’s usually not about your skills. It’s about how your message lands. Stakeholders hear risk, cost, and user impact, not technical detail. 📺 Video:

Not “too much detail.” Wrong frame. Say it differently, not less. Cheat sheet → how to keep substance but shift delivery.

When stakeholders brush past your point, it’s not always dismissal. They’re filtering for relevance. Show them the connection between your risk and what matters to them to cut through the noise. Here’s a cheat sheet to help you:

In most teams, quality work is quietly carried by someone. Because they care enough to ask better questions and spot risk before it shows up on a report. If that’s you, I hope you’re getting the support you need. If not, this might help:

If it keeps happening, it’s not just annoying. It’s your next problem statement. Reopened bugs, last-minute clarifications, weird handoffs Those aren’t one-offs. They’re patterns. And patterns are where your influence starts. https://resources.kato-coaching.com/influencer-cheat-sheet

You don’t need to be loud to lead. One well-timed question can shift a whole sprint. That’s how you move from helper to strategic partner. This cheat sheet helps:

People still say QA is the gatekeeper. But gatekeepers stop things. If you’re asking smart questions early surfacing risk before it becomes rework and helping your team steer you’re not gatekeeping you’re guiding

QA is the only profession I know where people regularly say “critical thinking is our most important skill” Like that’s the crown jewel of our identity. Curious where you stand on this. Do you think we overplay “critical thinking” as a skill in QA? Or am I just in a Friday mood?