Testers as Influencers

Tester influence is the ability to make quality observations heard, taken seriously, and acted upon across different stakeholder groups. It requires framing the same problem differently for each audience: developers care about context-switching and bug fixes, product owners care about feature adoption, and marketing cares about conversion. Small, low-cost experiments with visible results within a week or two build trust faster than long transformation programs.

Key Takeaways

• Framing a bug report around business impact lands harder than stating that quality is bad: telling a product owner that a broken button affects a specific browser used by a fifth of all users is evidence, not opinion.
• Small, low-cost changes that show results within one or two weeks are easier to get buy-in for than multi-month transformation programs, because people can see the effect and abandon the change if it does not work.
• Testers need a different message for each stakeholder, because the same bug causes different pain for developers, product owners, and marketing teams, and one uniform complaint reaches none of them.
• A 15-second check at stand-up, confirming that requirements are present in a ticket before it moves to in progress, can cut the back-and-forth between testers, developers, and product owners that drags out a sprint.
• Mini-waterfall inside a sprint, where all stories land in the test column two days before the sprint ends, disappears when testing is treated as part of development work rather than a separate phase after it.

Influence is part of the testing job, not a soft skill on top

Testers cannot do their job well without influencing people. Quality is too broad a topic to be owned by one role, so the work depends on getting others to take what you say seriously and act on it.

This holds for most roles in modern software development, but it weighs heavily on testers. You sit in contact with more stakeholders than almost any other role on the team. Developers, product owners, ops or DevOps people, sometimes whole other teams. Each of them holds a piece of what “quality” means in practice.

Kat Obring frames this as the tester acting like an influencer. The point is not self-promotion. It is making yourself heard so that an observation about quality turns into a decision and then into action.

Why “everything is broken” never lands

Saying “the quality of this release is horrible” gives people nothing to do with the information. The statement may even be accurate. It still fails, because it does not connect to anyone’s actual work.

Different stakeholders care about different versions of the same problem. Bad quality hurts the business, but it hurts each person differently. A developer feels it as time lost to bug fixing and context switching. A product owner feels it as a feature that users cannot find or will not adopt. A marketing team feels it as sign-ups that stay below target because the sign-up flow is awkward.

The same bugs can sit behind all three complaints. What changes is the impact on the person in front of you. So the first move is not to talk. It is to understand who you are talking to and what matters to them right now.

Evidence beats opinion when you want action

Replace your opinion with something measurable, and the conversation changes. “The sign-up flow is broken” is an opinion. “This button does not work on Safari, and a large share of our users are on Safari, so we lose them every time they go through this flow” is evidence.

Evidence removes the argument about whether you are right. It moves the discussion straight to what to do next. Kat builds this into a method she calls QED: Question, Evidence, Developed. You find a concrete moment where something is not working, you ask a sharp question about it, you collect evidence on its actual impact, and only then do you frame the conversation with the relevant stakeholder.

The framing and the evidence work together. Pick the angle of the problem that matters to that specific person, then back it with a fact they cannot wave away.

Speak more than one language inside the team

One shared language is not enough, because each role values different things. You need a slightly different version of your message for developers, for product owners, for ops.

That does not mean vague language. A team should agree on what its words mean, even if the definitions do not match any external standard. Kat does not mind whether a team’s idea of a “test level” lines up with the big test frameworks. She cares that everyone on the team means the same thing when they say “integration test.”

Precision inside the team and tailored framing toward stakeholders are two separate disciplines. Both matter.

Small changes beat big transformation programs

A change you can assess within a week or two beats a six, twelve, or eighteen month transformation. The long programs are usually well meant and well thought out. They are also hard to get behind, because they ask people to believe blindly that things will improve later while life gets harder now.

People get on board with something easy to do. They struggle with effort whose payoff sits far in the future. So the lever is not the scale of the plan, it is how quickly someone can see whether the change worked.

Cheap experiments carry a second advantage. When you have invested little, you stay honest about the result. Pour in too much time, money, or thought, and you get married to the outcome. You want it to succeed, and that wish quietly bends your reading of the evidence.

“Good experiments are the experiments where you know what you want to change. So you need to know what success looks like. But they’re also easy and cheap enough that if you can’t reach success with that, you can like, eh, fine, let’s try something else.” — Kat Obring

A 15-second check before standup

Weak requirements are a constant problem, and the usual responses overshoot. One team bolts a heavy review process onto everything: more reviews, more meetings, more workshops. Another team writes ever more detailed requirement text, which does not help either.

The small move is different. Before a ticket goes from “ready” to “in progress,” the team takes about fifteen seconds at standup to check that the requirements are actually in the ticket. If they are missing, two or three people meet right after standup and fix it.

Do this consistently for a week or two, and it starts to form a habit. The payoff shows up at the other end: fewer bugs, less ping-pong between tester, developer, and product owner about what a button is supposed to do.

If the check does not move your problem, you drop it and try something else, maybe a requirements template. Then you come back in two weeks and look again. Each cycle teaches the whole team something about its own requirements, which a template alone never does.

Stop treating testing as a phase after development

The mini-waterfall is a common trap, especially for teams new to agile or Scrum. The sprint starts, developers develop, and two days before the sprint ends, every story lands in the test column at once. The testers are then expected to test everything before the deadline.

The fix is to stop separating testing from development. Testing is part of the development work, not a phase that follows it. There is no test phase anymore, so the testing has to be planned and started from the beginning of a ticket.

A concrete first step: pair earlier. A tester sits with a developer at the start of a ticket and they discuss how the thing will be tested. The developer then builds it with testability in mind, which also helps with the unit tests. This is a small change, not a reorganization. Just start pairing sooner.

The introvert excuse does not hold

The idea that everyone in software development is an introvert who would rather not talk to anyone needs to go. If you cannot work in a team, you will not succeed in a testing role. That part is simple.

What you can do is learn what works for you and for your team. Kat counts herself as an introvert and found her own footing through asynchronous, written communication early in her career, working across California, Germany, the UK, and Indonesia. Written exchange gave her time, which mattered all the more because English is not her first language.

For people on the neurodiverse spectrum, an always-on camera can be genuinely hard. A meeting without camera is a fair adjustment. Talk to your team and your team lead, find the setup that works, and make as many small adjustments as you can. The one thing you cannot adjust away is the need to talk to other people at all.

How to pick what to actually work on

You have more influence than you think, so pick battles you can win and start with small ones. “Nothing is working” may be true, but it is not a useful statement. Find something concrete instead.

Anything that takes longer than a week or two, costs money, or needs sign-off probably requires approval from someone above you. So begin with what you can do alongside an ally on the team, a developer or a product owner who feels the same pain. A standup that runs thirty minutes because half the team arrives late is the kind of concrete target you can take to your team lead.

For prioritizing, Kat reaches for a fast impact-and-importance assessment, the Eisenhower matrix, done in minutes with a whiteboard and sticky notes. She also likes the Liberating Structures family of methods. The tool matters less than the discipline behind it: a concrete example, a question, evidence of the real impact, and then a quick call on what to try.

The aim is a quick result you can act on, not a perfect one. Speed of learning beats polish, because a cheap experiment that fails costs you almost nothing and points you to the next one.