How we do Quality Assistance in practice, the Wolt way

In our previous blog post, we talked about the role of our Quality Assistance team at Wolt and what principles we follow to ensure we build high quality products. In this post, we wanted to show you some of the tools from our dynamic toolbox which have proven to be exceptionally effective within our organization. This isn't a rigid checklist for all teams and QA professionals to follow. Instead, it's a showcase of powerful tools that have enhanced our capabilities. Each tool is always evaluated because we believe in a tailored approach – recognizing that in the world of QA for highly autonomous teams, there's no one-size-fits-all solution.

Our ideology is to embrace a journey of continuous improvement and learning. When choosing your toolset, it’s important to discover what works best for your unique needs, and leave behind what doesn't resonate. 

It's all about experimentation and growth. 

💪 Here are our top tips and tools that we utilize for QA at Wolt:

1. Plan what you build and how to test it

Test planning is more than just writing test cases. We want to start with defining what we’re building and why, what the risks are, how to mitigate them, and then dive deeper into how we could test the new functionality. At Wolt, planning is a collaborative effort between the team and the Quality Assistance Engineer. We want to make sure that everyone’s on the same page and that we’re building the right things.

Define your goal

The key question in any team planning is to first define the objective of the feature or project. Once you have a clear vision of what you’re building, you can start thinking about how to test it. One term we like to use at Wolt when doing feature planning is the “Definition of Awesome”.

What makes this feature awesome? How does it have a positive impact on our customers? How does it improve the product? How can we ensure it’s high enough quality, or what we call Wolt-grade?

Once the Definition of Awesome is clear to everyone, we can measure the impact of the feature when it’s in the hands of our customers. It helps us identify gaps in implementation to iterate and improve the feature.

Analyze Risks

Thinking about potential risks when planning the feature is a great way to understand the product you’re building. How does the feature fit with the existing product, how is it going to be used, and what are the risks involved if something goes wrong?

Understanding risks can help us mitigate them already in implementation and to plan testing more efficiently so we can focus on the high-risk areas. Low-risk features can be tested with less effort, so you spend your time wisely and get the most out of your testing.

Perform the needed testing to sleep better at night

Testing is essential in discovering problems with the product and planning testing activities is vital in making sure we deliver with high quality.

Automated tests give us quick feedback and assurance that our system is functioning correctly. We focus on writing tests not just for the sake of it, but to ensure high confidence in our product. We use code coverage tools for unit- and integration tests to make informed decisions about where to focus our testing efforts.

With automation in general, we aim for a high number of automated unit tests, fewer integration tests, and as few as possible end-to-end tests (or just one, for the happy path scenario!). However, knowing the risks involved with the feature helps us to increase the number of end-to-end tests if needed. Or the other way around, if the feature is low-risk, we can focus on unit and integration tests and leave the end-to-end tests out.

The key to automated tests is to understand which level of testing brings us the most confidence with the least amount of effort.

However, we shouldn’t forget manual testing. One can claim all testing is manual testing, as automation doesn’t create or analyze itself (but AI might, soon?).

2. Ensure you work towards the same goal effectively ✅

When working with multiple product teams at once it’s important to remember that every team is different, and they have different needs. High ownership teams are great at figuring out what works for them and what doesn't. But we as QA professionals are here to help the teams figure out what works best for their specific needs.

Ways of working can include things like team working agreements, Definition of Done, or simple tooling improvements such as story description templates.

Working agreement is a living document that outlines the way a team is working together and can be a great source of information, especially in a scale-up where many new team members are joining the company. Everyone will be on the same page quickly, on how teams conduct their planning, which ceremonies they adhere to, and how those ceremonies are conducted. From the QA point-of-view, this agreement could contain a QA strategy or a testing strategy.

Definition of Done is important in the team to set expectations and to deliver with high quality, every time. To better understand our Definition of Done, you can ask the following questions: 

• What’s expected to call something done? Yes, it needs to be available for the customer to use, but what else on top of this? 

• Do we need to have a code review? 

• What type of test plan do we have?

• Do we need to have automated tests, and on which levels? 

• Do we need to have a product or design sign-off? 

• Do we need to have a rollout plan? 

• What’s the feedback we collect from production usage? 

• How do we follow-up on the added value of this feature?

• Is there testing to be done in a production environment?

Writing down the Definition of Done can help the team to understand what’s expected of them, which helps them deliver high quality features consistently.

It’s important to remember that no agreement is set in stone, and should be improved when needed.

By providing simple tooling improvements to the teams, we can improve the way they use tools such as Jira for project management, and make their lives easier. Story description templates are a great example of this. Working with the teams to understand what gaps there might be in the current stories, what slows the team down, what information is missing or hard to find, and trying to gather the relevant information in the story description. Templates keep things consistent and provide enough information for the team to start working on the feature. 

However, it’s important to remember that templates lose their value if they become a chore to fill in and don't provide any value to the team. When the task at hand is easy to understand just by the title, we tend to overlook the description. The key thing in these examples is to find a balance: when and how to add story description templates for the team to utilize it purposefully.

Coaching the teams on ways of working and finding ways to improve is at the heart of Quality Assistance.

3. Work together in pairs

Pair testing is the most effective tool we have in our toolbox, however scaling it to cover every engineer is a challenge. Coaching one-on-one has huge benefits to the overall quality of work.

Pair development, be it programming or testing, is a great way to share knowledge and learn from each other. We highly encourage teams for both, but we acknowledge that it’s a muscle that needs to be trained to become effective.

Pair testing is more often the session where QA professionals can coach developers one-on-one and help them build a Quality Mindset. Quality Mindset means being obsessed with your customer and remembering that you’re building a product, not just lines of code.

In pair testing sessions, the QA engineer can help the developer understand the product better, think about edge cases, and how the feature is going to be used by the customer. One obvious point is to understand how the developer has planned the testing for the feature, which levels of testing were used, and why. Are there any gaps in the testing that we can identify and improve? Performing exploratory testing together creates engagement with the product and brings the developer closer to the customer.

Pair development is a great tool to scale the Quality Assistance mindset. When developers learn more about testing, they can do pair testing themselves without a QA professional. This increases the ownership of the team and helps them to build high-quality products.

4. Make it a Testing Party 🥳

Testing Parties are for the development teams to gain confidence in the feature they’ve implemented, find ways to improve the solution, understand how customers interact with their product, and find potential bugs before the release. In Testing Parties, the team focuses on certain or a set of features and they test them together. The team might have a list of test cases that they want to go through, or they might just test the feature as they see fit, in a more exploratory manner.

We’ve found two ways to make these testing sessions more effective:

• Option 1: Split the group into smaller groups (2-4 people), depending on the size of the team. In these smaller groups, pick a driver for each group, who does the actual testing and shares their screen. Others observe.

• Option 2: Mob-testing where everyone is testing at the same time while we’re communicating in real-time what we’re doing and what we’re finding.

All findings are written down, and we want to capture every minor detail in these sessions so we can improve the product and eventually make it great.

Testing Parties are a great way to catch bugs, but shouldn't be relied on as the only or main source of testing. Relying on them too much can lead to inefficient testing during the planning and development phase. The team should treat every finding from the Testing Parties as a learning opportunity to understand how the other forms of testing have failed to discover the issue and take measures to mitigate such issues in the future. Bug post-mortems are a good practice in such cases to dig deeper at the root causes.

Testing Parties are a great way to raise the product ownership of the team. When the team is testing their features, they’re more likely to take pride in their work and keep the quality bar high. Quality Assistance engineers help in facilitating these sessions and make sure we’re cultivating the Quality Mindset.

And most importantly, testing parties are fun! Teams can have a good time together and learn from each other. Also having donuts during the session makes them even better 🍩

To wrap up…

Quality Assistance is a mindset and a way of working that we’re cultivating at Wolt. We want to empower the teams to own their quality and we want to help them in ways that benefit the team. We want to keep the quality bar high and empower the teams and organization to improve. We want to help the teams to keep learning, but we also want to keep learning ourselves.

Build high-quality products, not just lines of code.

Does the work we do sound interesting?

We’re hiring! Check out our open roles! 🚀