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.
Frequently Asked Questions
Müssen Tester Einfluss nehmen können, oder reicht es, Fehler zu finden?
Influence is part of the job. Quality is too broad a topic for one role to own, so a finding only counts once someone else takes it seriously and acts on it. Testers also sit in contact with more stakeholders than almost any other role on a team: developers, product owners, ops or DevOps people, sometimes entire other teams. Each of them holds a piece of what quality means in practice.
Why does the same bug matter differently to developers, product owners, and marketing?
Because each group feels the cost in its own currency. A developer feels bad quality as time lost to bug fixing and context switching. A product owner feels it as a feature users cannot find or will not adopt. Marketing feels it as sign-ups staying below target because the flow is awkward. The same bugs sit behind all three complaints, so one uniform complaint reaches none of them.
How do you turn a quality observation into something a stakeholder acts on?
Replace the opinion with something measurable. “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 in this flow” is evidence. Kat Obring calls the sequence QED: find a concrete moment, ask a sharp question, collect evidence of the real impact, then frame the conversation for the person in front of you.
Why do multi-month improvement programs get so little support?
They ask people to believe blindly that things will improve later while daily work gets harder now. A change you can assess within a week or two is easier to get behind, because the effect is visible and the change can be dropped. Cheap experiments also keep you honest: once you have poured in time, money, and thought, you want the result to succeed, and that wish bends your reading of the evidence.
How can a team fix weak requirements without adding more reviews and workshops?
With a check of about fifteen seconds at standup: before a ticket moves from ready to in progress, the team confirms the requirements are actually in the ticket. If they are missing, two or three people meet right after standup and fix it. Held up for a week or two, this becomes habit and cuts the ping-pong between tester, developer, and product owner over what a button should do.
Why do all user stories land in testing right before the sprint ends?
That is the mini-waterfall, a common trap for teams new to agile or Scrum: developers develop, and two days before the deadline every story arrives in the test column at once. It disappears when testing stops being a phase after development. A concrete first step is pairing earlier: a tester sits with a developer at the start of a ticket to discuss how it will be tested, which also improves testability and the unit tests.
Can an introvert work well in a testing role?
Yes, but not by avoiding people. If you cannot work in a team, a testing role will not work out. What helps is finding your own setup: Kat Obring counts herself as an introvert and relied on asynchronous, written communication early in her career while working across California, Germany, the UK, and Indonesia, because writing gave her time. For neurodiverse colleagues, a meeting without camera is a fair adjustment.
Which improvements can a tester start without asking management?
Anything that runs longer than a week or two, costs money, or needs sign-off will usually require approval from above. Everything below that line you can start with an ally on the team who feels the same pain, a developer or a product owner. Pick a concrete target rather than “nothing is working”: for example a standup that runs thirty minutes because half the team arrives late.
