How Testers Build Trust Across Software Teams - Kat Obring

📘 Free e-book: The 7 success factors of software testing. 25 years of project experience in one 33-page workbook, now also in English 👉 Get it for free

"If we cannot work in a team, then we are not going to be successful in this role. It is fairly simple, right?" - Kat Obring

In this episode, I talk with Kat Obring about the tester as an influencer. We explore how to stop saying everything is broken and start speaking the language of stakeholders. Bring evidence, not opinions. Say "the Safari sign up button fails and 20 percent of users are blocked". We share a 15 second check before stand up, and pairing early so testing is part of development, not a mini waterfall at the end. Pick small battles and run one or two week experiments. If it works, keep it. If not, drop it. Influence without authority grows from trust and habits.

With over 20 years in the software industry, Kat Obring now focuses on what matters most: teaching teams and individuals how to measurably improve the quality of their work. Her practical frameworks combine insights from her diverse experience as a DevOps QA engineer, Head of Delivery, and, surprisingly, her early career as a chef. She's learned that evidence always beats guesswork, and a well-designed experiment will reveal more truth than months of planning ever could.

Highlights:

• 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.

More Links with Insights:

• Free Ebook about the QED Framework