Better approach to sprint for QA and Dev team

Question

We are having a challenge with fitting QA work into the Scrum process and specifically due to a need to do a full regression and load testing before releasing into production which takes up to 3 days. We are on 2-weeks sprint cycle.

Because the obvious answer seems to overlap sprints for development and QA since the reality is that QA always lags behind development to some degree due to full regression and load testing, we are considering the following:

QA will work on shorter sprints (1-week) and 1 iteration behind the main development (2-weeks sprint).

In other words: first week:

• dev is developing new stuff during the first week
• QA goes through regression testing of previous sprint
• QA works with dev on each individual user story

second week:

• QA goes through full "new feature" testing
• Dev addressing bugs or working on completing minor stories.

Assuming we want to keep developers developing and tester testing, what would be a better practical solution?

Answer 1

Since you're doing Scrum, let's look at the guide:

Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,

Why does scrum take such a strong stance against the sort of thing you're trying to do?

• Your team is not regularly and reliably producing shippable software. At the end of a "dev sprint" it isn't tested properly, so it's still work-in-progress. More testing and potentially more dev effort is needed. It's not shippable.

  If you're lucky and the regression tests all pass first time without dev effort, that’s shippable. Otherwise, you have the choice whether to derail the new "dev sprint" or just record (potentially serious) bugs (/failure of stories to be delivered to acceptance criteria) for later. Neither of these is a good outcome and neither result in shippable software that sprint.

• You've damaged your ability to respond to change. Let's assume that this is one of the weeks we get lucky with the regression testing and everything passes. We hand the software to the customer and do our demos. We get lots of useful feedback. Unfortunately we already decided what the priorities of the next sprint should be last week.

• You've divided up the team A team committed to delivering a goal is a powerful thing. This sense of shared responsibility cannot really exist in this situation. QA and Dev are working towards different goals. When a Dev helps a QA complete their sprint goals, the dev imperils their own. People become less T-shaped as responsibilities are heavily siloed and there isn't a sense of everyone pitching in towards the same goal. Team dynamics are incredibly important and this will matter more than you probably think it does.

So what should you do?

Regression tests that take 3 days aren't something you should work around, they're something you should fix. Sorry, Scrum isn't an infinitely malleable process that can cover for teams that don't want to adapt, improvement and fix their underlying technical problems. Which is why, incidentally, much like Extreme Programming (XP), it isn't for everyone.

Unless you're selling tickets for the most boring spectator sport of all time, you're job isn't to "keep developers developing and tester testing", it's to deliver value. If you have to take on less work, finish a bit earlier to allow for 3 days of testing, do that. In exchange you get the opportunity to continuously release actual done working software, it's worth it.

You can always use the dev time towards the end of the sprint to improve the speed and automation of your tests. QA time towards the start of the sprints should also be used for this, as well as things like exploratory testing. Good CI and good automation will be big wins for your teams productivity.