A Tester Who Doesn't Ask Isn't Testing

The line reached me second-hand, the way those lines always do.

Testers just pester people.

What a Question Actually Is

A question to a developer or a consultant is a test executed before the code exists.

It runs against the requirement, costs a minute, and can only return one of two results: the answer matches your model of the system, or it does not. The second result is a defect found at the cheapest point it will ever be available.

That is not an argument about culture. It is the arithmetic of when a question gets asked versus when the same misunderstanding gets found in SIT.

None of which changes how it lands on a project. The pestering is never personal — it is not driven by anything personal on our side — and it is still received as interference rather than as value, because of a visibility problem that is structurally impossible to fix from the tester's side.

The cost of a question is immediate, specific, and lands on a named person who was doing something else. The value of a question is a defect that never happened, which has no ticket, no chart, and no name attached to it. One side of that ledger is felt. The other side does not exist as an object anyone can point at.

So the tester who asks the most questions looks like the most expensive person in the room, on a day when they were the cheapest.

The Silence That Looks Like Competence

The obvious counterpart to the pestering tester is the quiet one. Gets the ticket, tests it, closes it, asks nobody anything.

A QA audit I ran gave that silence a much less comfortable explanation. A significant part of the team did not understand the development process at all. They tested tasks because tasks had been assigned to them, without understanding what a defect they found would go on to affect.

You cannot ask a question without a model. A question is what happens when something you are told collides with something you already believe about the system. No model, no collision, nothing to ask — and from the outside that reads as a tester who is quietly getting on with it.

The onboarding described neither the SDLC nor where testing sits inside it. Nobody had ever told these testers what happens to a defect after they raise it, who receives it, what it blocks, or what it costs at each stage.

A tester who does not know why they are testing cannot report risk. They can report a step that failed. Those are not the same output, and only one of them is useful to someone deciding whether to release.

That is the honest version of the lesson, and it is not about attitude: a tester who does not understand the process around them can only click. They cannot think, because nothing has given them anything to think with.

The Same Shape, in a Tool

The team had been using Postman for a year.

Most of them knew how to click Send. Very few could say why we use environment variables.

That is the same failure wearing different clothes. The tool was rolled out with a step-by-step instruction and no explanation of the logic underneath it — do this, then this, then this. Follow it and you get a working request every time — until something differs from the instruction, and then there is nothing to fall back on.

Knowing a tool and understanding it are different states. One is a habit, the other is a competence. A habit executes the path it was shown. A competence can construct a path nobody showed you — which is the only thing that helps on the day the environment changes, the token expires, or somebody asks you to prove an integration behaves differently for two customer types.

And an instruction without its reasoning cannot be questioned. There is nothing in it to disagree with. That is precisely what makes it feel efficient to write, and what makes it produce testers who never ask anything.

Why the Questions Are Not Optional

Two rules open our testing guideline, and everything else in it is technique.

You can't test everything. Testing shows defects, but doesn't prove there are none.

Juniors usually arrive believing the opposite of both. They think the job is to demonstrate that the system works — to go through the feature, confirm it behaves, and report that it is fine. That is the inverse of testing. A tester looks for holes. Nobody is paid to approve functioning.

Follow the two rules and the questions become unavoidable, not admirable. If you cannot test everything, you have to choose. Choosing requires knowing what matters, what is likely to break, what the change touches, and what it would cost if it failed. Not one of those is written on the ticket. Every one of them lives in a person's head — a developer, a consultant, an analyst — and there is exactly one way to get it out.

A tester who does not ask is not being efficient. They are selecting what to test at random, and calling the result coverage.

What Fixes It Is Structural, Not Motivational

Telling people to ask more questions does nothing. The conditions that produce the silence are all built into how a team is set up.

• Put the SDLC in onboarding, with the consequences. Not the diagram. What happens to a defect after it is raised, who it reaches, what it blocks, what it costs later. Without that, a tester has no basis for a priority, a risk statement, or a question.
• Roll out tools with the reasoning, not the keystrokes. Whoever teaches the tool has to explain why the mechanism exists — what an environment variable is protecting you from — or you get a year of Send-clicking and no capability.
• Make questions leave a trace. A question asked in a corridor is a cost with no record. The same question written against the story becomes a visible artefact, and when the answer changes the acceptance criteria, everyone can see what the asking was worth.

That last one is the closest thing I have found to a fix for the visibility asymmetry. It does not stop the questions being annoying. It just means they are annoying and on the record.

When your team stopped asking questions, did anyone check whether it was because they finally understood the system — or because they never had a model of it to begin with?