How to even out workload between developers and QA?

Question

I've noticed on my team the developers are very busy toward the beginning of the sprint with the QA people having little to do, while the opposite is true toward the end of the sprint.

This seems inefficient... is there any way to smooth it out?

Answer 1

It sounds like you are doing something very common in teams - a 2-week waterfall project. Things likely move from some requirements conversations before the sprint or in the early days of it to coding, then QA at the end. There are a few things you can do to change this up which will also have the impact of smoothing out workload:

1. Smaller pieces of work. Break things down into small features that can be designed, coded, and tested in 2 - 3 days. Lessons learned many decades ago from Lean: small batches lead to better flow.

2. Test-first development. Using techniques like TDD and BDD (as examples) can bring a lot of the testing early in the process instead of later. (this doesn't completely eliminate exploratory testing btw). This also really helps with...

3. Invest in test automation. Unit tests, integration tests, automated acceptance tests. This is all part of the build it process. Also, this requires both the coders and testers to work together. The testers are good at knowing what to test and the developers can help automate them and build the application to be more easily testable. This also gives you a large suite of regression tests that make it easier and safer to do #1.

Answer 2

Switch to Kanban so that you can balance the flow of work without the cold-start at the beginning of every sprint.

Once you start optimizing for delivery, look at how developers can help with the QA to finish the work instead of starting new items.

Over time, this might reveal team imbalance and drive some staffing decisions and/or tooling improvements.

Answer 3

One key is cross-training to reduce the skill gap between QA and SW engineers. That is, train developers to do some low-level testing, and testers some low-level development work. In fact, a big-data presentation I saw all the way back in 2014 at Agile World showed the best-performing teams did not have separate disciplines.

This echoes some of the other answers, but the process that has worked well for my teams includes these generic tasks for each development user story:

1. Write the test case, if one doesn't exist (QA, or dev in easier cases).
2. Develop (Dev) || Automate new test case, or conduct break/UX testing of existing code (QA).
3. Unit test (Dev).
4. "Second set of eyes" testing (QA, or different Dev from step 3's).
5. Acceptance test (Customer or Product Owner).

Good luck--Jim

Answer 4

^{I'm using a lot of Scrum terms here, but other agile methods are not that different.}

Let me make one thing clear first: test cases are not things developers or QA people make up as they go. Test cases are defined alongside the requirements. They need to be there when the implementation starts. Maybe not as automated tests, but at least as a description what should happen when on a piece of paper or in the ticket or as a reference to some electronic document.

Writing those testcases is a lot of work and can be done by QA people whenever they have nothing to do. However, that still leaves QA with one type of work at the start of the sprint and another type at the end of the sprint and the work at the start of a sprint is not even calculated into any kind of velocity because it's not measured as getting a ticket to "done".

The best way I have seen so far is to actually not have dedicated QA in the team. It doesn't make sense and wastes a lot of time. Maybe have a single one that can assist all others to become better at testing but can develop little features on their own if no assistance is neccessary.

Normal testing is done by the developers (preferably not the same developer that actually implemented the feature). They make sure a story works. They go by the test cases that are already listed with the story.

The team delivers potentially releasable software increments each sprint. The chance that you actually want to release that increment are slim. "Agile" lives from the ability to change things until the product owner is truly happy with them. Constantly realeasing a trickle of changes that might later be unchanged or changed in a different way is costly to everybody involved. You cannot run a marketing campaign every sprint. You cannot have ads for every little thing you finish. You cannot have 10 words translated (well, you can, but it might cost just as much as waiting until you have 100). And yes, you cannot have every feature thouroughly QA'd if it doesn't make it into a production release in the end. That's waste.

So your QA team needs to do their job not on every increment, but only on those increments that are to be released. The same as the marketing department, sales, whoever is involved in releasing a new version.

I know a team is supposed to be able to finish a product on their own, but that only goes for the actual implementation. There are no marketers, ad salesmen or translators on your team either. So don't make QA a part of the team. It's neither fun nor a good use of money to QA a feature over and over and over every time the product owner changes it.

Please note that I am talking about QA here. QA is making sure a product is working as it should be. I'm not talking about simple testing. Testing should be done by the developers, how else would they be able to say "I'm done".