“Gotta Keep ’em Separated”…. really?

So here you are, setting up your new project. And what do you need? A couple of Devs and then some people doing QA? Right?

Wrong.

 In past many software projects have separated development and QA or “testing” duties into different teams. This trend has been changing over the last few years to have only one team with devs and a couple of QA’ers.
It’s a step forward but we’re still not where we want to be:

 A single, unified team able to take on the different duties as needed.

And here’s why it matters:

1. Goal Orientation

Separating Dev and QA even if it is just by assigning these duties to specific people immediately creates differing goals for these groups. Devs will want to release software, to complete their stories and move on with the next task. Who blocks their progress? The QA’ers or “testers”. The QA’ers on the other hand have the goal of providing test coverage and preventing defective deliveries from being released. So they have to “clean up the devs’ mess” all the time.

Who of these people actually has the unified goal of both RELEASING and having GOOD QUALITY? Usually no-one.

If there is no-one specifically assigned to Dev or QA duty it no longer becomes a matter of coding something or getting it tested – it’s now a team goal to deliver results.
The difference might be subtle but it’s actually quite the game changer.

2. Flexible Assignments

Depending on how a project might progress the Devs might actually deliver new functionality faster than QA can cope with testing coverage. While unit tests should be present given a TDD environment (more on that later) the system and end-to-end tests also need to be done and they can be a huge time-sink. In other cases QA might be comfortable keeping up with the Devs but (or because) they are falling behind in their project plan.

Neither situation is ideal. And instead of having to bring in new staff it’s a lot easier to shift people into different areas as needed.

And this is A LOT easier if no-one clings to a specific position in the first place. That way workload is automatically balanced as needed by the team and project as the overall success (see #1) is a shared goal.

3. Skill Mixture Needed

When looking at test-driven-development it becomes clear that a developer can no longer concentrate on just creating code. A considerable degree of testing knowledge is also needed to provide the necessary (and effective!) test coverage.

When looking at the QA side the times of grinding through a sheet of manual tests is coming to an end. Initiatives such as CI and DevOps mandate fully automated testing from day one. However this testing automation does not magically appear, it requires a lot of coding on the QA-side of things. This requires a considerable degree of programming knowledge.

All things considered a developer can no longer work without testing knowledge and a QA’er needs programming knowledge. Mixing skills and knowledge in a team is therefore absolutely necessary.

The Bottom Line

Modern projects require a team that is aligned with a shared goal – to deliver a high-quality product on-time. Constantly changing needs and requirements make it necessary to be able to shift workloads quickly and flexible without being tied to specific people or teams. And with the TDD/CI requirements of modern DevOps-driven projects the skill separation between Dev and QA has become non-existent.

It’s okay to bring in people with different skills together – but in the end it requires a combined team effort to be successful, not the combination of a few loose parts.