Your AI testing can pass every check against the spec while the behavior you know is real never gets checked at all. You know how a feature behaves because you have used it, watched it, and broken it for years, and then the documentation says something different. The test you write against that documentation passes, and if you raise the unchecked behavior anyway, the conversation turns into whether you are the one who is wrong. That is the situation this post is about, and I ran into it recently in a place that had nothing to do with software.
I asked an AI to research a topic for me. I already had my own understanding of it from my own experience, and I was not careful with my prompt. I never told it that my understanding was the starting point and that the sources were only there to show what had already been written. The research came back with the written answer and treated my version as the thing to be corrected, and it took several messages of pushing back before the real gap showed up. The answer was built on its training data and what is on the internet, my understanding was real, and nobody had ever written it anywhere the research could look.
Every Expected Result Has a Source
Every test case has an expected result, and every expected result comes from somewhere. Usually that somewhere is the acceptance criteria, the spec, the design file, or the documentation. In testing terms that source is your test oracle, the thing you compare the actual behavior against to decide pass or fail, from requirements testing through the last regression run.
Here is what that means in practice. A test that passes only proves the product agrees with its source. It says nothing about whether the source is right, whether it is complete, or whether it describes what real users actually do. When the source and the real world disagree, the test sides with the source every time, because the source is the only thing the test knows how to ask.
The Behavior Nobody Wrote Down Looks Like Your Mistake
The trouble starts when your experience disagrees with the source. The source is written, linkable, and attributed to someone. Your knowledge is none of those things, so the source wins the argument before anyone checks whether it fits the case in front of you.
In QA this shows up as a report closed with works as designed, or as a finding you never file because you cannot point to a line that backs you up. The behavior stays unchecked, the results stay green, and the release looks safe on paper. That is exactly what happened in my research session. The written answer won first, and the question of whether it covered my case never got asked.
The same pattern shows up in AI software testing, when you ask an AI to do test case design from the requirements and acceptance criteria. It can only return what that documentation supports, so a behavior that lives in a tester’s head and nowhere else is invisible to it. I covered a related version of this in happy path testing when your dev team uses AI, where the code reflects a model’s reading of the prompt and not everything the team actually discussed.
AI in Testing Has the Same Problem Even With Context
The first part of this is on me, because I was not careful with my prompt, and a sloppy prompt hands the default answer room to move in. The obvious fix is to hand the AI your context up front, and that only goes so far. Even with context in place, the answers kept sliding back toward what the training data and the internet already say.
I covered why context matters in context engineering for LLMs, where the argument is that a model fills the gaps in its context with averages from its training data. That still holds, and this is the harder case sitting on top of it. Supplying context narrows the gaps, but it does not guarantee the model stays inside them. I wrote up the research side of what happened in the AI limitations post on EngineeredAI, where an AI overwrote what I knew with what the internet already says.
This is what adds complexity to hybrid QA. In a hybrid workflow the AI does part of the work and a human reviews it, and reviewing used to mean checking whether the output was wrong. Now it also means checking whether the output quietly reverted to the generic written answer after you told it not to, and that failure looks like a confident, reasonable result. I walk through the review layer in the hybrid QA workflow for AI generated code, and this is one more thing that layer has to catch.
Two Pieces of Advice That Both Fail
The first piece of advice is that if it is not in the spec, it is not a bug, which makes specification testing the entire job. That treats the spec as complete, and no spec is complete. It also quietly teaches testers to stop noticing anything that cannot be traced to a document, which is the opposite of what the job is for.
The second piece of advice is to trust your gut and ignore the docs. That fails too, because experience can be wrong. My own understanding of that topic might have been right or wrong, and I will not pretend otherwise. What matters is that it was a real input, and it got overwritten by the nearest written answer instead of being tested against anything.
I came up in QA without formal training, testing on instinct before I had the vocabulary for what I was doing. For a long time the feel was the only thing telling me something was off before any document did. That is why I do not treat experience as noise, and it is also why I do not treat it as proof.
What I Do When Experience and the Source Disagree
The fix is to stop letting either side rule on the other. Neither the source nor your experience gets to win by default, because a default is exactly how the unwritten behavior got lost in the first place. Here is how that plays out in the order it should happen.
First, state what you know as its own claim, in your own words, with where it comes from. Not as a correction of the document, just as a claim that exists. With an AI, that means saying so in the prompt before the research starts, which is the step I skipped. Second, read the source to see what it actually says, and use it to learn what is already written down, not to rule on you. Third, when the two disagree, log the disagreement itself as the finding. The gap between what is documented and what is real is information the spec owner does not have yet.
Then give it an actual session. This is where an exploratory testing session structure earns its place, because exploratory testing goes looking for what nobody has verified, the paths nobody wrote a case for. Charter the disagreement in one sentence, timebox it, take notes as you go, and when something surfaces, funnel in and reproduce it. Whatever you confirm becomes a test case someone else can run without you standing there, and now the unwritten behavior is written down.
That last step is the part that makes it count. A tester who only trusts documents ends up certifying documents. A tester who only trusts experience ends up unable to prove anything to anyone. Run the disagreement as a test and you get a result that survives both.
If your tests pass against the spec but you still suspect the real behavior is different, you already have the one thing an exploratory session needs, which is a suspicion with no test case behind it yet. Start with the session structure in the exploratory testing post and charter the one thing you know that nobody wrote down. A one sentence charter is enough to begin, and everything else in the session builds from it.
