One Team – One Mission

“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?


 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.

1 thought on “One Team – One Mission

  1. And the point “a developer can no longer work without testing knowledge and a QA’er needs programming knowledge” is the big gap in my eyes. Developers think that QA is only >writing a unit test or have some specified level of code coverage<. In the past, QA was trained to also emphasize on edge cases and how to do that. This knowledge is not in the heads of the developers out there and requires training – as you said. On the other hand I see a problem with edge cases when it comes to MVP. In the past QA blocked something if requirements where not met. Today the MVP approach let software get shipped / released even if not all edge cases are covered and therefore situations emerge where exactly this edge case bumps back in the form of a filed changed request / defect from a customer.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.