Tech
Mikko Vaha
Sep 21, 2022
From Quality Assurance to Quality Assistance at Wolt
Like in most companies, QA at Wolt plays a key role in ensuring the software we build provides our customers exactly what they need. But due to our hyper-growth, ways of working and autonomous teams, we do things a bit differently compared to many ‘traditional’ QA teams. In this blog series, we want to let you know how quality software is created at Wolt and how QA activities are incorporated into it.
This first post is a short general overview — a teaser if you will. The overall blog series on Quality Assistance at Wolt is aimed to illustrate why and how we shape our approach towards the daily needs of our teams. We’ll touch on things like Quality Assistance in practice, building a quality mindset, quality measurements and coaching, to name a few (subject to change 😉). We also want to provide insight on how Quality Assistance enables teams to test efficiently and enhances their sense of quality ownership within a scale-up.
So, let’s dive into the world of QA at Wolt.
Ensuring quality in an autonomous, scale-up environment
Product development at Wolt is built around autonomous teams that are driven by a high sense of ownership. For the first three years, Wolt didn’t have a separate QA role in the organization. The need for QA expertise was identified as we were challenged with varying levels of quality in customer releases, and over the past few years our QA team has grown fast to respond to the needs of our growing organization.
Before getting into details with QA, we’ll need to understand how Wolt is structured and the type of culture we have. Our development model is based on autonomy, ownership and accountability. We’ve removed the authority that originates from titles, spreading ownership to teams at every chance. Team members are trusted to make the right decisions as the experts in their area, and team leads are rather coaches that direct and help remove blockers rather than telling the team what to do. And while team members are empowered to own their work, the ownership also comes with accountability to own your products, product quality and projects end-to-end.
The development organization itself is organized in groups and teams, which all are centered around a customer need with a clear ownership and set of responsibilities. Each team can decide their ways of working and tooling they want to use themselves. This leads us to the situation of over 50 unique teams (and growing fast), with varying needs, tools and practices along with a platform that’s rapidly growing in complexity.
The model of autonomy and empowerment is great, but from the QA viewpoint, our ways of working raise some challenges. Since there’s no one-size-fits-all solution to anything, all teams must be supported according to their individual needs. QA is organized as a horizontal team, loosely coupled with development teams, which gives the team more flexibility to help out where needed. Then again, as a horizontal team, QA doesn’t have the authority to dictate (nor does any other one person due to team ownership) the approaches for teams. Instead, we adapt to and support their individual needs based on our QA insight, while sharing tried and tested working practices. We trust in our people and that’s why we’re there to support and help when needed.
This setup has led us to discover the approach we’re taking with the development teams by assisting them to build high quality software with our deep and wide QA expertise.
We embed QA mindset into product development teams
Since the beginning of 2020, our product development team at Wolt has more than doubled in size and we are running at 400+ people at the moment. The product development function is split into groups that own a core area of Wolt and form a team of teams focusing on key customer groups. The groups are split into small, autonomous product teams, usually consisting of a product lead, designer, engineers and an analyst. The set up looks like this:
As all groups have their own ownership areas, the QA team has distributed our focus to all groups based on the group specific need, one to four persons in a group at a time in practice.
As our growth has been extremely rapid, we’ve had to scale our QA capabilities along with the organization while aiming to highlight the sense of ownership for development teams. The approach of supporting teams in need has enabled us to raise the ratio from QA:DEV to QA:Team level, meaning that one QA person normally supports one to five teams at a time, depending on the current need and ongoing projects.
As the specific need of a team varies due to area of responsibility, the QA team has been built with this in mind. In the team we have people who are specialized into mobile, web or backend development, with expertise in a specific area to be able to support different development teams efficiently. This also enables us within the QA team to learn from each other.
Quality is defined and ensured together
What is quality is a tricky question with no definite answer within an organization. As our platform serves different types of customers — external, internal, business, consumer — the definition of quality varies. This is why the people owning a part of our software should have an extensive understanding of what quality means for their team and thus be able to make sure it is implemented in the software as well.
The Wolt QA team approaches creating quality software following our high sense of ownership ideology in our product organization. Assistance, enabling, supporting and coaching are the tools of the trade from our QA team point of view.
An ideal situation would look like this:
For the highest efficiency and teams truly owning the quality of their software, developers should be enabled to release high quality features. In practice, this means that QA does not “own quality” or enable the possibility of QA being a separate part of the development flow.
What? But, how does that work? Devs aren’t able to test their own stuff? What does QA do if they’re not testing once developers have done their magic?
Well, we think this approach will work and we already see it working. QA at Wolt is there to support and empower developers to build software with a quality mindset and execute testing with efficiency.
Building a Quality Assistive approach mindset
Defining the exact role of QA at Wolt is still an evolving process. These are some of the ways we practice the assistive approach:
We gather information and understanding around whether we really need as many ways of working as we have teams. What can we unify and how can we “act locally, but think globally”?
Building quality software doesn’t originate from just code (and manual testing), but from people, culture, skills and mindset.
We need to help the teams to be able to release high quality software — doing whatever is needed, which at times might end us up detecting issues, rather than preventing them.
We keep in mind the long-term goal of enabling developers to match the “ideal situation” (picture above) and release without additional QA as a separate process.
We push the organization to constantly improve following lean principles of removing bottlenecks.
We build frameworks, reporting tools and such to make the development process more efficient.
We aim to get the highest quality possible, with the lowest effort possible — enabling us to scale efficiently.
We’ll dive deeper into what these ideologies mean in practice in the upcoming posts of the blog series.
Figuring it out and sharing the same long-term goals
While taking our first steps and figuring out the ways we can scale our small QA team for the biggest impact on the organization, we’ve found that there are several organizations in the world who think the same way about Quality Assistance.
We’ve found inspiration in Laura de Paiz’s assistive approach called the modern Tester on their blog Hello, Modern Testing World:
We also believe this approach is the way software development is done in the future and how QA-minded people are involved in the team effort.
Atlassian has also provided some insight on what they think Quality Assistance is (How to Move from Quality Assurance to Quality Assistance) and how they have matured their ways of working towards it: Quality at Speed, How JIRA Does QA (Webinar).
It’s been interesting to learn how similar challenges we’ve had and what type of approaches have worked in different organizations.
We hope you enjoyed this first part of our QA at Wolt series. The next blog post will dive deeper into the day-to-day activities we’ve adopted to grow QA insight in the organization. Stay tuned, we want to make this worth your while!
– A Little Better Every Day – Mikko
