Single project, Multiple Teams – Difficult to manage/track Testing activities? - A guide to write a single Master QA document

Problem Statement:

Multiple teams working on a single project was a big challenge initially in terms of Measuring the QA Progress and defect tracking, Managing efficient communication and collaboration between the teams. Making them understand the responsibilities and current updates of the tasks. Teams found it very difficult to follow the on-going agenda across the teams. It was hard to generate one single consolidated report on the overall QA progress since each team was following their own way of execution process. One of the difficult parts we came across was the Test coverage for functional and regression. If you face the same situation then you are in the right place and this document will help you to overcome this.

Overview:

I am repeatedly asked “How can we define the process and co-ordinate QA activities of multiple teams working on a single project……finding hard. Is there any document that can be referred….”. “There are different problems that can arise

1. Should each team follow their own team’s specific process?
2. How should the communication/interaction between the team happen?
3. Should each team need to run BAT after every deployment?
4. Who has to coordinate between the teams?
5. How can the cross-feature testing be done?
6. How can regression be done when each team is working on their specific feature?
7. How can we track the consolidated progress of Test execution?
8. How to avoid duplicate efforts?
9. How can each team get the updates/changes related to the project?
10. Who will be responsible if any issue occurs in future?
11. Who will support UAT in providing Test data and other details during execution?

Are you in a company that is aiming to implement or already working on a Single project with multiple teams and worried about how to manage and coordinate team activities from a QA standpoint. Then you are in the right place that will guide you through on how to manage and track QA activities effectively and collaboratively.

Single project multiple teams:

A project can have multiple scrum teams working from the same backlog, in parallel. The teams will have to collaborate on creating a potentially releasable increment.

Why need a single master QA document:

A common place where anyone from any team can access and know what is the process and can track overall execution % of all teams.

Overall QA Execution Summary:

Each team working on a single project will have their own dashboard to display their initiative/feature execution progress along with the defect dashboard. However, it is hard to know overall execution progress combined of all teams working on a single project. So, it is important to have a common place like here to update consolidated QA execution progress.

Consolidated QA execution Weekly Summary Report:

One common QA Process for multiple teams involving in a single project:

As there are multiple teams working on a single project, define a single common QA process and make sure it is communicated to each team and followed strictly. I have given some examples below that you can include as part of your QA process

1. Define BAT & Feature Execution process

It is hard having each team to run Basic acceptance testing and track the result after every deployment. So, you need to have one common BAT executed, covering scenarios of all teams. So, define the BAT process as below

1. Define BAT scenarios: Prepare a list of basic acceptance test scenarios that need to be run after every deployment to execute making sure the build is stable enough to continue testing. These scenarios to be received from each team covering their basic features and to be finalized and added as part of BAT. So, we can make sure that all teams are good to test their features without any blockers.
2. BAT Execution Process: After every deployment in development or QA environment, the BAT Team (Assign few responsible resources as part of BAT team in order to execute BAT after every deployment) is responsible to execute the BAT and post the results in the relevant chats. If the BAT scenario fails
3. Decision to add scenario into general BAT: Upon new features are getting added to the project, the respective team is responsible to request to add the basic scenario to be added as part of BAT. So, the closed group (who are all assigned to be responsible for the BAT or the BAT team will gather in order to discuss and finalize if the scenario can be added to be part of BAT and update the team back who raised the request.
4. Feature Execution Process: Once the BAT is passed, all the teams are responsible to run their feature-specific smoke test to make sure the features are not broken.
5. QAT Support: Define who will support for UAT execution by preparing Test data and providing necessary details to the BA during UAT. The respective team who is handling the feature is responsible to coordinate and assist during execution of their feature by UAT

2. Brainstorming/Test coverage discussion

1. Define the process here as below.
   1. Have a common shared location/page where all team can write the scenarios specific to their features
   2. Once the team is assigned and aware of the Initiative/ Epic/story then the QA lead is responsible to make sure to add the details in QA Master page (have the QA Master scenario page created where all teams can add their scenarios specific feature assigned) and his/her respective team specific confluence page
   3. The QA lead is responsible to coordinate and schedule a meet to brainstorm on the related feature assigned between teams to have the test coverage
   4. Every scenario that is added to the page should have the column included and marked if the scenario can be automated or not.
   5. QA Lead is to make sure the team’s specific scenario page is UpToDate

3. Automation Vs Manual execution

It is mandatory to track how many scenarios are automated and how many are manually to be run. The respective QA lead from each team is responsible for this effort to provide the percentage of automated and manual candidates.

4. Defect Management

As there are many teams involved in the project there will be a confusion as to how to raise a defect and under which Epic or story. And there may be a chance that the defect is left unnoticed. Define the QA defect management process. So, all the teams can follow the same process. I have provided a few examples below that will help you.

1. Any new issues found should be reported under the Epic/Story related to the respective feature (Ex: anything related to booking should be raised under the booking related Epic and assign it to the specific team). Anything related to regression should be logged under the common regression Epic/Story.)
2. When reporting a defect, the QA must provide all the necessary details
3. QA is responsible to track the reported defects until closure of the defect

5. General Info

Provide any general information/updates to the team by mentioning in the General information section. So, everyone in the team is communicated and aware of any latest updates. I have given a few examples below.

1. Any changes in the environment
2. If the environment is under maintenance
3. Outstanding Defect Dashboard Link
4. Test data / Test cards details
5. Team names and respective QA Leads names
6. Any other important notes that the team need to know

Conclusion:

Managing a single Master QA document helps you to simplify your process and managing activities. Hope this document will help you to move forward and to run a successful project every time.