5 Major Problems with Large QA Testing Teams and How to Handle Them

More often than not, when you are a large testing team, you have an equally large product to test and equally complex challenges to deal with.

What then becomes difficult is maintaining the quality standards, knowledge sharing and decentralizing the expertise.

Let me explain this problem in-depth and possible solutions too. 

However, I want you to understand that even though most of my thoughts here come from my leadership experience– believe me, implementation of the methods that I am going to explain will help both senior and junior team members and teams of any size over one.

Recommended read => How to build a successful QA team?

5 Major Problems with Large QC Teams Along with Remedies

Problem #1 with larger Test teams: Maintaining Good Quality consistently over time

Problem: How many of us have experienced that maintaining good quality in a product becomes rather challenging when the team size increased in comparison to when the team was lean?

Remedy: The reason for this is, we all have different skill sets, strong hold in different areas, different naturally gifted talents, different styles or approaches to test and of course different past experiences.

These differences are impactful because it is not very easy to teach people “How to test” or convince them to test in a particular way. It is not easy, because Testing depends a lot on your freedom to think and do what you think.

Blocking someone’s thought process in a particular way and redirecting it to something else won’t always work and shouldn’t be done unless it is really needed. For that, there has to be dedicated efforts from the Mentor/Lead who should share a good rapport with the individual testers.

Coming back to the real problem- when given a particular functionality to test not all members of your team can spot all the defects. Number of defects caught, quality of defects caught and time in which they are caught will differ too.

Some or all of the below outcomes are possible in such cases:

• Getting issues in Released modules
• Inability to think of all negative scenarios while building Test cases or Test Scenarios
• Trying too hard to catch extreme cases while leaving the happy path ones
• Having less confident members for their own work in team
• Repeated Test Cycles to gain the lost confidence

Problem #2 with larger team: Centralized knowledge and expertise

Problem: Another problem to which managers/leads will relate better is that the knowledge or expertise on a particular module or testing type gets centralized to a few members in the team.

E.g.: John, Johny, Janardan together form a Team. John is excellent in Security Testing, Johny has deep knowledge in Workflow module, Janardan is irreplaceable within team when it comes to Performance Testing and Payment module.

Having module/type experts in team helps Managers in short term as they can be simply assigned new work where they are pro and then the managers can relax as they know they are going to get quality and best possible results.

In the long term however, this develops difficult to manage dependency. Unavailability of the key resource might create a problem and bring the release to a still stop. Unavailability can be due to many reasons like unplanned leaves, illness, internal shifting, resignations, etc.

We talked about expertise, what about knowledge sharing?

If we take our last example forward, then wouldn’t it help Johny if he gets to know on which part of the product Janardan is working? Wouldn’t John’s knowledge of workflow module help Janardan somewhere? Wouldn’t it help them all to understand new developments in the product and guess their impact on their past and present deliverables? Wouldn’t the entire product’s knowledge help each of them while working on future tasks?

I heard your ‘BIG YES’.

Remedy: Now that we have talked about the problems, let me talk about how my team operates and overcomes all these problems and many others.

We run on two rules which I’m sure you all have heard before.

• People over Processes.
• Collaboration over Documentation.

Here is how the work flows in our case, step by step:

1) Requirement gathering: Story/Feature XYZ is ready for discussion from the Business Analyst’s side.

2) User story discussion: This new requirement, if complex, gets discussed first at lead level, where Business Analyst, Dev Lead and Test Lead make the user story ready for grooming (Requirement discussion with team). The thought process behind this is to solve possible doubts/gaps in the story beforehand and detail them out so that the team’s time is saved.

3) Grooming session: This is a session which we call as Grooming/Hole punching session where Business Analyst drives the team through entire Requirement functionally. Around 90% of clarity to a tester who will be working on this (let’s refer him as Story Owner from now on) comes here.

When I say clarity, almost all test scenarios/cases are already formed here in his/her mind. I am leaving 5-10% for scenarios which are still unknown.

4) Brainstorming session*: Post grooming, dev and testing teams meet to discuss the requirement more technically than functionally where things like impact on existing features, the need to patch existing data, hidden scenarios and efforts are discussed.

The main factor here is that the maximum members from testing team try to attend this session in order to contribute to Story owner’s scenario list. This also helps their own knowledge too, of course. So we get multiple testing minds thinking here than just one.

Like in our example, Even if John owns this particular story, he will have Johny and Janardan too along with him to think and help him.

Story owner then appends all the scenarios discussed to the existing list from grooming session. Ideally, almost everything gets covered in this session except those few bugs which are absolutely random and can be uncovered only via good exploratory testing.

5) Test case conversion: Story owner then starts converting the requirement and scenarios he collected from the earlier chain into Test cases. At the same time the developer starts writing the code for new features after designing. Once test case writing is done, Story owner shares them with his/her Development counterpart for their review and reference.

6) Testing with Test Cases and going Exploratory: Once the story is marked as ‘Done’ from development team, story owner completes testing based on test cases written but in an exploratory way where he/she also tests many other things. Once desired quality level is achieved (decided on test coverage, open bug count and Story owner’s confidence), the story is marked as QC Done.

7) Overlapping Session*: Once story is QC Done, Story owner then conducts a small overview session (before release is shipped) for the new feature where he explains the functionality and testing done. We call this as “Overlapping session”. Attendance here is mandatory for all testers unlike Brainstorming session.

So at least at a high level, everyone knows what is being shipped, they can also think if there is still any impact of this story on their story’s testing and vice versa. They can even ask the Story owner some questions.

8) Overlapping Testing Round*: Important but kind of optional (because it depends on bandwidth available with team) step we follow is “Overlapping Testing Round” done by someone other than story owner in a time not more than an hour usually.

The overlapping tester thinks only about the extreme negative cases assuming the obvious has been already tested. This is like a second opinion before the release is shipped out.

May be you already have set processes in your team which cover most or all of the above. In our case, every step matters but the real differentiator compared to the rest of the world, would be the three steps marked with *, which make a positive difference.

I’m listing them again, because they generate a lot of ROI than I can explain here.

• Brainstorming Session
• Overlapping Session
• Overlapping Testing Round

As a Manager it makes my work a lot easier for keeping the Quality at its possible best and making knowledge flow smoothly through all team members.

But wait, more than me these methods help my team. These are not my words, my team of 25+ say this every time I ask them about few things which we are doing good in their opinion, things which are helping them and which we should continue doing.

Problem #3 with larger team: Making work FUN and interesting

Problem: Did you think I simply make my team work with no fun factor or personal enhancements at all? That would be crime for any good leader. If you throw only work towards your people then eventually they will get exhausted, bored and even frustrated.

Remedy: We have very friendly environment not only within our team but in the entire organization. If I talk about my team, we are more like friends and less like a reportee-manager.

Here is what we do extra which is worth mentioning-

Every Wednesday we all (all testers from all my products) meet for a couple of hours. We call it Q&A Session.

This is what we do there:

• Anyone can ask a question about anything and not just testing and others can answer.
• Anyone can share an idea, process improvement, their own achievements with all. Just anything can be shared.
• Everyone in round robin fashion comes up with something new within Testing world which he/she thinks others might not be knowing. That way we enhance our Knowledge base.
• Does this still looks like work only? Well, we click Pics, we play many new games. And more than anything else, we play MAFIA :). We share it all over our Trello Board (Another topic to speak on someday) or Slack channel.

Problem #4 with larger team: Work Distribution/Assignment

Problem: Another problem with larger teams is distributing work amongst the team. If you simply assign tasks as per your choice then there is the possibility of ending up in the following scenarios:

• A person getting similar complexity tasks again and again leading to limited personal growth.
• A person getting similar modules to test again and again leading to frustration over time.
• You naturally assigning particular module to module expert to get the best work and fuel the centralized expertise problem which we talked before even more.
• Your team gets a robotic feeling of simply obeying orders and they feel their opinion/choice is not valued.

Remedy: The remedy which I use here is, I make them BID. Yes, we sit for Release planning with Release Dashboard consisting of all user stories on Projector and I make them ask for the work of their choice.

By doing this, all the above problems get solved automatically as team drives the show and not the leader. Very rarely I override the bids keeping Product quality and release timelines in focus. Of course, only after explaining them ‘Why’.

Problem#5 with larger team: Appreciation and Motivation

Problem: You can categorize each of your team members into the buckets- Rockstar, Performer or under Performer.

Real problem occurs when you have many Rockstars and Performers but no under performers. Because, it suddenly makes your Performers look like under performers when compared against Rockstars.

Remedy: Well, the Remedy starts with accepting the fact that you can’t have all rockstars in your team. Everyone has different natural talents, different speed of learning and different style of working. As a leader you got to appreciate it.

You can help the performer be Rockstar but not alone. You will have to find the leaders (not necessarily designated but the natural ones) in your team first and involve them in this responsibility.

As a Manager/Leader you can’t give enough/same time to everyone in your team. You have to delegate responsibilities to the right Rockstar leader after making them believe in your vision.

I have done that and I can proudly say every leader in my team is getting more than 4.5 out of 5 in their Reportee feedback year on year.

You can connect with the maximum number of people that you can, but you have to constantly talk with the leaders, guide them, appreciate their efforts and share the vision. They will do rest of the work then which you can simply monitor.

Of course, writing appreciation emails, giving motivational talks, applauding your team publicly is something you’ll have to continue doing always.

Conclusion

Let me conclude with a saying “None of us is as smart as All of us”. So leverage your strength that is being a TEAM and fly higher.

Also read => How to Lead a Happier and Successful Test Team

About the author: This article is written by STH team member Mahesh C. He is currently working as Senior Quality Assurance Manager having experience of leading testing front for multiple complex products and components.

I hope what I shared helps you and your team in some way. I am positive that it will bring positive change.

I’ll love to hear back. do post your comment/feedback here.