Leigh Rathbone has over 24 years of experience in the tech industry and has held tech leadership positions across several organizations. He started his software testing career in 1998, working at different companies for four years until he joined Sony Ericsson. Leigh spent seven years at Sony Ericsson, where he notably worked on the world’s first touchscreen phone and first smartwatch!
He joined Sony PlayStation as Head of European Test Operations, managing about 300 testers after leaving Sony Ericsson. Some time later, Leigh took up a new role in clinical software testing at System C Health Care. He also spent five years in leadership roles at Very Group before joining Gear4Music as the Head of Quality Engineering, a position he currently holds.
Gear4Music is the biggest online retail store for musical instruments in Europe, where you can order a range of musical instruments and equipment manufactured by many of the industry’s best-known brands at very competitive prices. As the Head of Quality Engineering at Gear4Music, Leigh is responsible for improving quality within the 12 development teams working on their online music gear store.
In this article, we share details of our conversation with Leigh Rathbone on how to do software testing and quality assurance right. But you can also watch the full video on our discussion with Leigh via the link below:
If you joined the tech industry back when Waterfall was the go-to software development method, there’s a good chance you’re used to relying on the quality assurance team to be responsible for the quality of the product.
But even if you’re used to more contemporary methods like Agile, you might still be buying into the idea that the quality assurance team should test and fix errors and bugs after the software has been developed. Many tech leaders assume that quality is a team-based thing—and that’s where they’re gravely mistaken.
The problem with the team-based approach toward quality testing is that the software team and other stakeholders interested in the product may not be too keen on ensuring the quality of their processes, which will affect the overall quality of the product. Moreover, errors and bugs discovered during software testing could be avoided if everyone felt responsible for the software quality.
Leigh argues that quality assurance should not be the sole responsibility of the quality assurance team. In his words, “The development team, Product Owners, customers, users—anybody involved in building software and anybody who receives software should share responsibility for the quality of the product.”
Leigh also recommends moving from quality assurance to quality engineering. While quality assurance merely assures the quality of the software, quality engineering is multilayered and integrates the product development processes in a broader context that involves everyone on the product development team.
Adopting the quality engineering mindset can help your team see quality as a shared responsibility, rather than a team-based responsibility exclusive to the quality assurance team.
It’s easier to make changes in a one-person team than a multiple-people team, but it takes a village to build great software. Hence, as a tech leader, you may struggle to reshape the quality assurance approach adopted by everyone involved in the software development process and get them to share responsibility for the product quality. If you’re wondering how to go about this, the following tips from Leigh may help:
Many tech leaders wrongly assume that the quality assurance team is the gatekeeper with overriding authority to approve or disapprove a product and test for quality. However, modern quality testers work with a symbolic toolbox and test frameworks, making them engineers.
Therefore, changing their roles from quality assurers or testers to quality engineers changes the mindset of the people performing that role. It also makes the software development team realize that quality is an engineering process and, therefore, part of their responsibility.
Leigh suggests reviewing processes with engineering leads and understanding their approach toward testing and development. This can help the quality engineering team understand what needs to be tested and make quality a whole process instead of leaving everything till the end. It can also help the team understand how their processes affect the overall product quality.
The product support team are usually engineers who monitor and fix defects from products already deployed. Working with the team or picking someone from the team to join the quality engineering team can help your team identify defects before the products are deployed and improve the quality of your products.
Customers expect quality products and don’t really want to be involved with the backend. Nevertheless, getting customers involved in the quality journey can ensure that your products meet their expectations and increase the product’s usability. According to Leigh, “Quality is not just a tech thing. Customers can help with usability, so they need to be involved, too.”
A common approach adopted for software testing is assigning only a tester to work with the software development team. However, it may be difficult for one person to test for everything, since testers often have limited knowledge of software development and other processes. This can affect the outcome of the quality assurance process as a whole.
Leigh recommends training testers to have a broader understanding of the software development process and different testing parameters while also training them toward becoming specialists in one or more testing parameters. This way, they would be able to engage other team members in the testing process.
Everyone has a part to play in delivering quality products with minimal flaws. The way Leigh puts it, “Quality is everyone’s responsibility, as everyone cares about onboarding and offboarding.”
The software team has to write good code, and the users and customers have to define the product requirements clearly to avoid errors. Hence, everyone needs to own the software and be accountable for its quality. By doing so, you can get maximum participation from all stakeholders and define quality processes for each team.
Changing the mindset around quality may involve asking people to do things they have never done before. This can be difficult, since adjusting to a new approach requires time. Moreover, when faced with deadlines, they may revert to their old ways, leaving loose ends that can affect your quality processes and, by extension, the quality of software built by your organization.
Hence, as a technical leader, you’ll be responsible for ensuring that your team does not deviate from the new approach and go back to doing things the way they used to. Here are some strategies you can use to build quality into your team:
While a fully aligned team that prioritizes quality in all processes may seem like a long shot from your team’s present disposition toward quality assurance, it’s best to start building the quality culture right away.
Leigh suggests starting small while thinking big. For instance, you can get the quality engineers to start asking developers for the quality of their code, implementing unit checks, conducting peer reviews, etc.
Getting the right people from the business side and empowering them to put quality first can go a long way. They can influence other members of the organization and spread the culture.
However, selling the quality culture to business leaders may be hard. Leigh recommends backing it with financial benefits. Such benefits may include an increase in the users’ trust and reduced time spent on software development due to errors, positively affecting the organization’s bottom line.
According to Leigh, “Quality engineers can be quality coaches within other teams, raising awareness and promoting the quality mindset.” Hence, an excellent way to encourage the quality culture in your organization is by pairing teams with quality engineers.
This will help your quality engineering team understand what different teams do and develop testing parameters and questions around the team’s processes. Consequently, the developers get to build with quality in mind from the beginning and improve their skills.
Encourage the quality testers on your team to learn. If they’re curious about certain types of testing, give them time off to go and learn and explore, then come back and share the knowledge gained with the quality engineering community.
However, you should set realistic expectations for these quality champions. They don’t need to become experts in some particular kinds of tests; they just need to know enough to spot quality defects.
According to Leigh, “Quality testers need to ask questions and drive conversations around quality to promote the quality culture.” Such conversations should be aimed at developing a shared understanding of how the ticket, app, and program will get built, tested, and delivered to clients with minimal defects. This will help everyone prioritize delivering a quality product.
Quality engineers need a separate toolbox of questions to drive conversations with different product stakeholders. Coming up with these questions may be pretty challenging.
However, Leigh recommends drawing inspiration from the Agile Testing Quadrants. You can simply ask questions around each quadrant. Leigh shared some great questions from each Agile Testing Quadrant that we noted down below.
First quadrant: Unit tests
Possible questions: Can you show me what unit checks you plan to do?
Second quadrant: Functionality tests
Possible questions: Does the product work? What are you doing to ensure that it works?
Third quadrant: Exploratory and usability testing
Possible questions: How can we gain insights into the customer’s user journey? How does this affect the users?
Fourth quadrant: Performance and security testing
Possible questions: How do we know this will perform against our load peak? How do we know the storage is secure?
Instilling the quality culture in your organization may not be free from certain challenges, for instance, who is left in charge of unit testing, since everyone cares about the product quality. However, it’s essential to consider the skills required to conduct unit tests when determining how such tests should be conducted.
According to Leigh, “The right person with the right skills should do the testing.” However, quality engineers should always collaborate with unit testers. Also, quality engineers should keep records of the unit tests conducted to avoid duplicate tests.
Building great software requires different processes and collaboration with different teams, and it may be challenging to manage the quality of each team’s process.
Logically, you may want to delegate the process of scrutinizing for quality to a quality assurance team, but this approach cannot guarantee the quality of the end products, since there are several processes in between that can only be fully understood and identified for testing in collaboration with the product stakeholders.
Hence, it’s best to adopt the quality engineering approach and get everyone involved in the quality testing process to build a product that will suit your customers’ needs.
While there may be different ideas and opinions on the right approach and when to test for quality, it’s essential to identify and do what’s right for your company instead of getting carried away by trends. Leigh also advocates putting the customer at the heart of the quality process, since they are the ultimate deciders of quality as the ones actually using the product.
Thank you for reading this article. With the tips and strategies shared here, you should be well on your way toward building quality products that will meet your customers’ expectations.
Before you go, feel free to check out the following guides and resources about software testing on our blog to help you build software that users can rely on:
Lastly, if you’re building a product and need testers, we offer comprehensive software testing and quality assurance services. We’ve implemented robust QA processes across the entire development cycle because we believe quality assurance is everyone’s responsibility, like Leigh Rathbone says. Go ahead and reach out to us for support with your next project!