Quality assurance (QA) and test automation processes have evolved significantly over the last few years as a result of high demand for quick, cost-effective and smooth application releases.

Most organizations now follow the agile methodology and execute projects in sprints. Their QA team is either a part of the same sprint working in coordination with a Dev team or kept as a completely separate team.

The decision of how to use a QA team is generally made by the project stakeholders. But this choice can have a direct and long-lasting impact on the overall success of the project. Stakeholders need to analyze the project scope and delivery timelines along with team capabilities and size before making such a critical decision.

Let’s look at some of the pros and cons of the above two approaches.

One Team Approach – QA and Dev Module Team

In this method, the QA team is part of the same sprint working with the Dev team. The following schematic details this structure.

As depicted above, QA is part of each module’s team. Some of the key attributes for this type of team composition are:

• QA is an integral part of the module development team.
• QA is involved in every stage of the Software Development Life Cycle (SDLC).
• Team assignments are tightly bound, engineers involved are rarely moved across module teams.
• Efforts of developers and QA are counted in the same sprint.

The typical schedule of a weekly sprint for this method is shown below:

Pros of QA members as part of the module team:

• Better integration of QA resources in sprint planning as QA is an inherent part of the team
• High visibility on what should be tested for a planned release
• Better planning and execution since QA is aware of day-to-day development updates
• QA efforts are well thought out during sprint planning and execution.

Cons of QA members as part of the module team:

• QA is not a separate team, so its efficiency can be negatively impacted by delays in development, changes to product features, etc.
• Since QAs are tightly bound with a module, the verification of that module can become monotonous. This might impact performance of long-term projects.
• It may present challenges when the Dev and QA teams are not in the same time zone as it demands close intra-team communication.
• Requires deep understanding of complex modules, which is often costly and time consuming.

Separate Approach – QA Team as a Separate Unit from the Dev Team

In this scenario, QA teams have their own separate sprints and are loosely coupled with module development teams. The following image depicts this method:

Some characteristics of this type of composition are:

• QA is an independent organization, completely separate from the development team.
• QA is involved with the development team at specific joints, such as planning, defining UAT, etc.
• QA is usually shared across multiple feature teams.
• Each development sprint is followed by a QA Sprint.

The typical schedule of a weekly sprint is shown in the below graphic:

 

Pros of separating QA and Dev teams:

• Less dependency on each development sprint as it runs on its own schedule.
• Team assignments are flexible, which allows test engineers to move across modules.
• It works better if Dev and QA are located at different geographical locations or operate in different time zones

Cons of separating the QA and Dev teams:

• As QA is a separate team managing its own sprints, it must be aware of the ongoing development and modules to be released for production to ensure accuracy and efficiency. It also must work collaboratively with the AppDev team to receive the latest release updates to understand the test scenarios and coverage.
• Each release takes additional time compared to the one team scenario.
• Dev and QA processes must be monitored to ensure good communication and collaboration.

Other QA considerations

The above approaches to QA sprint planning are powerful means of managing test automation. To decide which suits your project best, stakeholders must consider factors like:

• Overall project timelines
• The number and complexity of modules to be released
• The geographic location of QA and Dev teams
• The number of QA resources available, etc.

Irrespective of which approach they choose, project stakeholders also should determine how to:

• Ramp up maximum team members on multiple modules
• Gain flexibility in test assignment and planning
• Reduce test dependency on individuals
• Effectively manage overall project timelines and costs

The optimal use of both of these approaches will go a long way in ensuring overall project success through seamless delivery.

If you would like to review or revamp your QA and test automation processes or would like more information on Emtec’s QA and testing services, please contact us today.