What is the best way to contribute as a QA in 2022?
Previous experiences
I started working with Quality Assurance (QA) in 2010 in a company using our old friend “waterfall” process. We developed big chunks of software, testing the whole thing before deliveries and delaying those deliveries because of bugs. I was in a separate QA team, where testing was the last step in the development lifecycle.
In my next job, I was in a company that was transitioning to Agile, they had one tester in each team but still had a separate QA team to test everything before deliveries (don’t ask me why).
Then I worked for smaller startups and had more freedom to choose how to work. Since then, I have been working within agile teams and actively participating in sprints and deliveries.
Which are the options in 2021?
After eleven years working as a QA, studying, researching, and talking to colleagues, I got some insights that I would like to share here.
To start, I want to share what I believe to be the concept of “Quality” in software development. It has two main points:
- Deliver the right thing — meet the customer’s needs (Product)
- Deliver it right — enable the customer to go through the whole user journey and side-features without problems (Engineering)
So there are two main sides to this “Quality” conception, the “Product” and the “Engineering.”
Considering an agile software development lifecycle (SDLC) with the following steps:
We can then split them into our Quality definition sides:
- Product: Requirements, Planning, Design
- Engineering: Build (development), Testing, Deployment/Maintenance
And I believe that as QA’s, we can contribute to all of them. How?
First, we have the so-called “shift-left” testing approach, which consists of “testing” your deliverables as early as possible in the SDLC, i.e., preventing bugs over finding them.
WARNING: “Shift left” is (or should be) more about everyone acting as QA’s during the development cycle than the QA itself having to approve every step. If you don’t educate your team, you will continue to be the “gatekeeper” of quality, but at different levels — and we do not want that.
So yes, you can review user stories, tasks, and design files, but you can’t be the one and only approver of everything. Your reviews and actions should give more and more insights to the responsible people in each step, and it is part of an improvement process.
So after some research and talks, considering all the information above, I see then three ways to contribute as a QA:
- Inside a Platform team (https://teamtopologies.com/key-concepts);
- Inside development teams;
Platform teams
A platform team is not the “usual” development team. It is a group of people that delivers internally to the other teams, ensuring better and faster deliveries.
The platform team deliverables can be boilerplates, internal tools, infrastructure, modules or frameworks, consumed by development teams.
As a QA in a platform team, it is possible to help also in code reviews, pairing, and non-functional tests like security, performance, availability, etc.
In this approach, one QA can support multiple teams, and the goal is to eliminate the “gatekeeping” that usually happens.
Development teams
Each team has a QA Engineer. As any other engineer, they have tasks during sprints and participate in feature development, can be part of all team meetings, and contribute to each step of the SDLC.
It’s essential not to have the “test” step as an exclusive QA step or a blocker here. Testing is an activity that has to be done by every team member.
Usually, QA’s have a lot of business knowledge which can be helpful in team discussions, helping finding “bugs” even during the requirements phase.
So which one is better?
During the years working as a QA, I have helped development teams in different ways, but there’s one that I like better. Delivering test automation, assisting teams to continuously deliver is excellent, but I’m one of those who still value a lot the so-called “QA mindset.”
Working inside a platform team seems to be the best way to contribute to the Engineering side. It may give you more freedom to research and implement new things and contribute to a broader level. You’re contributing to the whole company and not just a single team. I don’t work like this right now, but I would miss participating in team decisions related to product and feature development.
For me, working inside development teams is the best option. It allows you to also contribute to the Product side. You can do the same as you would in a platform team if you organize well and will still participate in the whole process with the other engineers. I have helped my teams so many times by discussing features, screens, tech stacks, and business rules that I just can’t get rid of it.
And for you? How do you work? How would you like to work?
Which one is your favourite approach? Let’s discuss!
Thanks a lot to Samanta Cicilia(GitHub) and Paulo Gonçalves(GitHub) for the insights on working as a QA in a Platform Team, also to Leonardo Galani and Wellington Avelino for reviewing ❤️.
