I’m joining a new team at work, and as I do so I’ve taken some time to reflect on how I want to contribute to the team. Obviously some of that will be specific to the context of the...
I’m joining a new team at work, and as I do so I’ve taken some time to reflect on how I want to contribute to the team. Obviously some of that will be specific to the context of the team I am on, but I’ve also decided to publish some of my personal quality principles. These are the principles that currently guide the approach I take to quality and testing.
Quality is a team sport. I don’t do all the testing. I might not even do most of the testing. My main goal is for the team to produce high quality software that makes customer’s lives better, and I believe that can only be accomplished if everyone on the team owns quality. This means that I will work with the team to make sure we are not cutting corners on the testing, and that we are all getting infected with the quality virus (don’t worry, it’s better for you than covid).Testing should be an accelerant not a bottleneck. This means that it should be rare or non-existent to be “waiting for testing to finish.” If testing is or becomes a bottleneck, I will work with the team to identify and mitigate the reasons it has become one. Time spent testing should be an investment in the future, not a form of evil that stops us from doing what we want.Using testing as a safety net is an anti-pattern. Testing is not something that primarily happens after the code is written. Testing happens during design, during development and while code is in production. In other words, at every point in the software development lifecycle. Limiting testing to a just one step in the SDLC is inefficient and counterproductive. If the team is primarily relying on after-the-fact testing to stop them from getting hit by surprise bugs, I will do my best to help the team recognize and remove the need for a testing safety net.People first. We write software so that we can make people’s lives better. If we are not doing that, we are making bad quality software. I want to know how our customer’s lives are being improved, which means knowing our customers needs and usage patterns. I love using telemetry and logging to understand the quality of our code, but we also need to remember that customers are fully rounded complex humans and not just data points. Alos, software is created by people, and so part of a people first approach to quality is to think about things that might impact the team. Software that makes the life of the team worse, is also bad quality software regardless of the impact it is having on customers. Testing scalability is important. Software development is all about scaling things. Testing needs to be done in a scalable way too. This means that I will work with the team invest in scalable test automation. Regression testing is too important to ignore, but particularly as a feature set grows, quickly becomes too slow to do manually.Those are some of the principles that drive my approach to testing. The way that plays out in my day-to-day activities is, of course, going to vary widely depending on the needs of the team, but these are the goals and principles that lie behind the kinds of things I try to work on and advocate for.
