In the last weeks I was talking about how QA should work:
Should they work in an agile team or in a QA squad?
Should they work with manual or automated tests?
Should they do both?
So I decided to publish this post and share my impressions about this.
What are archetypes?
In the dictionary, archetypes means:
1.a very typical example of a certain person or thing. — “the book is a perfect archetype of the genre”
2.an original that has been imitated. — “the archetype of faith is Abraham”
So, here I’ll talk about some models based on my experience and each model can fit better in some organizations or product teams. I don’t have the magic solution here, you’ll need to read about these archetypes, look at your context, and find what can fit better for you.
I’ll talk about 4 archetypes:
1- The specialist
2- The generalist
3- The Platform
4- The Consultant
The Specialist
I called the specialist the QA who works in one specific function like manual our automated or performance. Some companies hire for a really specific context like performance or security. On the other hand, some QA people prefer to choose one than another. I interviewed some professionals that told me they would like just to automate test and the test scenarios should be written by other QA.
I never worked in this model but I believe that in some organizations this is hard to scale, and we can make other questions like if I’ll hire a QA just to automate, why I can’t hire a developer?
In performance case, we can think in e-commerce companies where they have squads focused on this subject with different profiles like QA, DevOps, and developers.
The Generalist
This is a common archetype where the QA role is in the development team, one problem that we have sometimes in this model is that we have waterfall cycles in the sprint because the developers develop and then send the tasks to QAs to test. In general, we don’t have 1 QA to 1 Developer so the QA can be a bottleneck in the process.
This can happen in teams where we don’t have confidence in the test strategy at all, then we have one person (the QA) checking the features before the production deployment.
These archetypes can face some variations, for example, the QA can pair with developers to create unit tests, or with DevOps to create and evolve the pipelines and automated checks like coverage, mutation testing, and security, it’s why this QA is labeled generalist.
I already worked with this profile and we need to be careful to don’t make the QA the only person responsible for the quality, instead of this the team is responsible for quality together.
Platforms:
I’m currently experimenting this archetype. To understand better about platform teams you can read the book Team Topologies.
Before talking about the QA in this context, I'd like to give you a brief introduction to team topologies. When we are talking about team topologies we are thinking in team cognitive effort. For example, imagine your team is working in a registered service, the effort and focus should be in the first place the business, in the second place the technology used and in the last external questions like environment configuration, release process, and CI/CD*.
The QA in this context won't be a person in the team testing or automating, but someone who will help to create tools and mechanisms that will empower the teams to deliver high-quality products.
We can think in API tests as an example, the product team shouldn't invest cognitive effort in define what will be the test architecture, how to run the tests in parallel, how to generate code coverage and how to run in a CI tool. This structure should be provided by another team (platform team) so the product team will just fit it in their project.
The same should be applied to other test types like performance, where the product team can have a tool that abstracts how to create virtual users, how to reuse the TCP connection, how many containers to use in AWS to be able to run 500 TPS, all these stuff should be encapsulated in a solution provided by the platform team.
Something like QaaS, QA as a Service… maybe…
The idea here isn't to have a team with 30 QAs, but a team with different profiles that will be able to create this platform to the product teams. QA should be a profile who instead of test features, would worry about how he can optimize the other teams' work.
Consultant:
This is a common archetype, where the QA shares the knowledge and best practices instead of work in the tasks.
This kind of service can be external or internal, some companies have a QA that helps the teams to understand better about test and quality.
And… now?
Now that you know the archetypes it's time to think about where you and your team are and if this model fits with your organization and business.
And, if you will start to hire QAs, you can think about what archetype is better for your reality.
Remember that these archetypes are not excluding, you can have a Platform QA that will work as an internal Consultant and besides creating the tools, he will spread the knowledge in the teams.
So, what you think about this? Can you identify what is your archetype today? Leave your opinion in the comments :)
*TPS — Transactions per Second
*CI — Continuous Integration
*CD — Continuous Delivery
Top comments (0)