2

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?

2
  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

enter image description here

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
| improve this answer | |
  • "The first approach ensures that integration tests are in place and components are well tested before being integrated. On the other hand the second approach lives on the system test level." I don't really see that. There're plenty of teams with dedicated testers, yet with zero unit tests. The presence of a QA within a team has close to zero impact on whether or not components are well tested. It's more a question of resources the company has and/or is available to spend on low level testing in the near future. – pavelsaman Aug 13 at 11:47
  • @pavelsaman given they do thier work 😁 – PDHide Aug 13 at 11:48
  • It's hardly ever a decision of one person. It's more complex than saying "if they do their job". – pavelsaman Aug 13 at 12:24
  • @pavelsaman a single persons effort will always have effect you will see it only when you remove that person from that team. Having zero unit test and having more integration test level doesn't equate to zero impact . Its just slows down the development , detection and debugging efforts. But its better to know things are breaking before its far late. – PDHide Aug 13 at 12:27
  • 1
    Thanks for the answer, very useful for thinking about this. But to make things clear, this is not my decision, it's management's decision. I'm just trying to see what are possible downsides and upsides to both approaches. – Mate Mrše Aug 13 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.