Navigating Change in QA: Lessons from Robert Sabourin

QA is always evolving — whether it’s new tools or software testing strategies, shifting team structures, changing tech stacks, or evolving business goals. The only constant in this field? Change. 

I recently had the pleasure of hearing Robert Sabourin speak at QonfX about leading quality through change. What stuck with me most was how he framed quality — not as a fixed goal, but as something that evolves with context, purpose, and people.

Understanding the context of change is essential — especially within your own organization or role. He breaks it down into four pillars: 

  • Business: What business are we really in?

  • Technology: What tech are we using (or being pushed into)?

  • Organization: Who’s in charge? Are we centralized or distributed?

  • Culture: How does where we work (and who we work with) shape how we approach change?

To understand the context of your role in the change, you really need active context listening - a practice of listening, learning, and adapting in real-time to generate better test ideas and smarter decisions.

It's so easy for us to fall into the pattern of checking boxes just to "keep pace" in agile QA. But we need to take it a step further - we need to define the quality of change itself. Not just testing that it works, but understanding why it matters, and who it matters to.

📌 "On time, on trend, on budget means nothing if it's not also on purpose"

How do we define quality? That is largely dependent on your context, but Robert highlights some key areas that generally cover most companies' main concerns:

  • Data integrity

  • Truthfulness

  • Trust

In defining our quality, we must also review our risk factors. In the advent of AI, our usual 2D model leaves some gaping holes. Robert suggests a newer way of modelling risk; the likelihood, the impact, and the autonomy - that is, how far an AI is left to operate without human intervention.

QA isn’t just about verifying change — it’s about leading it. Understanding the risks within your context, and knowing what quality metrics are important to your stakeholders, will keep us ahead of the storm and in charge of our AI augmented workflows.

How are you navigating change in your QA team? I’d love to hear how others are approaching risk, AI, and defining quality in today’s fast-paced dev cycles.

Comments

Post a Comment

Popular posts from this blog

Understanding HTTP Response Status Codes

Image
As a quality assurance professional, understanding HTTP response codes is essential, especially when testing APIs or web applications . These codes provide vital information about the status of requests, helping you identify issues quickly. In this post, we’ll break down what each response code means, why it matters, and how you can use it for effective testing. HTTP response codes are divided into five categories: informational, success, redirection, client error, and server error. While there are many codes in each category, the most common ones you'll encounter are 200 , 404 , and 500 . 1xx – Informational Responses You’ll rarely encounter these during typical testing, unless you're working with proxy servers or handling long-running requests . These responses simply indicate that the server has received the request and is processing it. 100 : Continue — The server has received the request headers, and the client should proceed with sending the request body. 101 : Switchi...
Read more

API Testing Overview

Image
When you're new to API testing, it can seem like a very foreign concept. In reality, it is very similar to testing any application. We'll look at some general categories to cover, and what types of tests those might include. Functionality Functionality tests are of course a major part of any test plan. In API functionality testing we check for things like a correct Response, the correct Response Code, and Schema Validation. You'll want to validate these for each endpoint you're working with, as well as for each type of request available. Security For the most part, APIs are typically internal tools and you'll want to protect the data from being accessed by outsiders. While security testing APIs we check for authentication and authorization methods, unauthorized access, and injection attacks. Performance At the most basic level, performance testing an API involves checking that the response time in within limits. This can be further fleshed out while the API is under...
Read more

Testing vs. Checking

Image
In software quality assurance, the terms testing and checking are often used interchangeably, but they actually refer to two distinct activities. While both are essential in ensuring the quality of a product, they serve different purposes. Let’s break down the differences and explore some common methods used for each. What’s the Difference? Testing is an in-depth process used to explore and assess the behavior of a system under various conditions. It’s about learning and discovering how the product performs, often revealing unexpected issues or areas for improvement. Checking , on the other hand, is a more straightforward process. It focuses on confirming that the system meets predefined expectations or requirements. It’s about verifying whether specific functions or features are working as they should. Key Differences Purpose: Testing: Aims to identify problems by exploring the system in various scenarios. It’s used to find defects, unexpected behaviors, or gaps in functionali...
Read more