Many development teams are switching to Agile methodology when they develop products. As the agile methodology is gaining traction in businesses, the QA team is often asked to be part of the development team within the sprints. At times, this structure works well, but there are other cases where separate QA teams seem to be working better.
It is a very common question when it comes to the arranging QA team – Should they work with the development team or as a separate team?
The answer to this question will depend upon various factors that need to be evaluated before making a final decision.
- The number of Quality Assurance resources available
- Timing of the project as a whole
- Entire modules count and complexity of each module
- Developer and Quality Assurance teams geographical location
Let’s look at some of the reasons why it should be one or the other and try to understand strategy.
Most QA personnel work in two types of settings:
One Team Approach – QA and Dev Module Team
During the One team approach, the efforts of the QA and Dev are calculated and executed in a single sprint. Both the teams are operating their task in a single time-boxed period, to complete a set amount of work.
The QA team is involved in each phase of the Software Development Life Cycle (SDCL) that makes the project monotonous and may negatively impact the project.
The one-team approach is more focused on tightly binding the Dev team and QA team. During this method, the developer and QA team are codependent. This proves that this method is not time efficient as it does not use the full potential of the Dev and QA team.
These approaches help develop the software and identify bugs, errors, and other defects in the same sprints and the release of an error-free sprint, as it moves from one sprint to the next.
This approach is only effective when it is crucial to assure the quality of the first sprint before moving to the next.
Separate Approach – QA Team as a Separate Unit from the Dev Team
In the Separate Approach, QA and development teams are non-coupled, the development teams work on features and deliver them in a sprint while the QA team tests them, developing team moves towards the next sprint. This method is called the Separate Approach Method.
In this method, the QA teams are distinct, independent teams that work on their own and it allows the developers to work without any interruptions until the feature is complete. This method requires good communication and collaboration between the Dev. and the QA team.
The main benefit of this approach is that it removes the pressure on the development team to wait until the Quality Assurance performs testing is complete. Here, the QA teams continue their work, as the development teams move further.
Check the image below.
Sometimes, as the QA and the Dev. the team performs their independent sprints, it becomes a challenge for the QA team to know what will be developed. In other words, there is no visibility of upcoming or planned functionality. The Dev. team would need to always communicate plans to the QA team to help prioritize QA resources and reduce re-work. Conversely, the QA team should always be kept aware of new functionality releases to assist with the test planning and examining enhancements for the defects found. If the whole process is not planned and executed properly, it could result in a delayed response from a release, as the information flows up and down.
What we recommend:
No matter which approach is favored, the goal remains the same: to ship the best product possible with erasing the number of bugs. The goal must be to not lose sight of other goals, including reducing overall project time and expenses, which will dictate how test automation development is scheduled.
For insurance business:
Some insurance IT providers still prefer one team approach for the completion of the projects. The insurance industry, however, faces continuous challenges from dynamic demands and digital competitors. The insurance IT service providers started moving towards the Separate Approach as it provides more scope for executing the project quickly and create a balance of the work between the Dev and QA team.
Post a comment