Focus on team or focus on app?

Question

Given the following scenario:

• a company is working on a complex product - multiple teams working on multiple connected apps/microservices, sometimes more than one team works on a single application
• each team has a dedicated QA engineer
• product is growing more and more complex and more apps are added
• more developers are hired in order to keep up with customer requests but only occasionally new QAs get hired
• dev/QA ratio gets skewed so QAs start supporting multiple teams at the same time

Provided that the number of QAs won't catch up with the number of devs, which of the two options (I'm sure there are other ways of doing this, but I'm interested in these two) of reorganization is preferable in order to keep the quality at the respectable level:

1. Keep the QAs connected with the team (even when the same QA is a part of multiple teams)
2. Link the QA to a particular app (so they support an app, regardless of the development team that is currently working on it)

The first approach seems to conserve more of a team spirit, IMO, but the second could be better for the overall quality, but at the price of the tester losing the sense of belonging to a team.

Do you have any thoughts on that or experience with it? What are the pros and cons of each approach?

Answer 1

1. Keep the QAs connected with the team (even when the same QA is a part of multiple teams)
2. Link the QA to a particular app (so they support an app, regardless of the development team that is currently working on it)

This approaches shows that you have missed the concept of test level . The first approach ensures that integration tests are in place and components are well tested before being integrated.

But can fail to test the system as whole , and can sometime fail to validate important business logic. This will make the product components working but the product as whole fails

On the other hand the second approach lives on the system test level.

Here if you implement the second pattern , your test strategy looks like cone which is an anti pattern

SO i think you need to have hybrid strategy where , the unit test , and integration tests are handled by developers . And the system tests are covered by test engineers through BDD and TDD.

This ensures that features are tested individually and business flows are covered completely.

Dev , PO, QA and BA should start writing requirements and specifications using Gherkins and automate it at system test level or UAT.

In other levels developers can take up the ownership in a rotating manner . A developer should work in test development for 2 sprint and then back to development ( As in Microsoft)

But still quality of test levels may differ as testing is more about mindset skills than programming skills.

Summary:

1. Unit test , component test and integration test cannot be ignored just because you have system test in place. This because it will break the fast feedback in a agile setup
2. It slows down development, detection , bug fixing and debugging s
3. Over dependence on System tests can mask component bugs , that may result in security breaches in future.
4. Ensure proper responsibility transfer from dedicated QA to Dev for lower levels for Approach 2
5. Depending on only Approach 1 will miss to test the product as whole and will miss important business logic