Dev and Tester separated team AND single sprint

Question

First a bit of background :

Previously in V cycle process, we have a dev team and a product definition/tester team (we'll call them testers). We moved to agile few months ago with still this separation : people with dev knowledge and people for product definition/testing.

The dev team has for some time already continuous integration with automated non-regression testing. The tester team only has functional testing capacity, no dev possibility.

Also, the devs and the testers are in different location (video conference is used).

If helping for the solutions, we are using Jira for Scrum.

Current situation :

The devs and testers are in the same scrum team. Everyone is dedicated to the team for the duration of a sprint. User stories have acceptance criteria correctly set... So far so good.

However, the testing of the user stories is handled by the testers and not something like a test that check the acceptance criteria and allow or not the user story to be integrated (we add tests to check but they are not used for validation of the user story). And obviously, the testers cannot code as they don't have the knowledge to do so.

This leads us to an issue that when doing the sizing, we cannot make a sizing that make sense for both the devs and testers inside the same sprint. If we add up the sizing, when planning the sprint there is a high chance that one side with have 75% of the workload and the other almost nothing to do. And if we size for only one of the side, we ensure that one side will have the right amount for the sprint but the other side might not. We could size for both but then selection might not match priority is we want to have an adapted workload.

So far we sized the dev work and end up with a huge backlog of untested user stories (which can bite us if test are failing)

From what I read here and there, the solution is to have separated sprints and dev making validation based on the acceptance criteria (automated testing) and then the testers might do additional tests in their own sprint. However, the management wants that we keep everything in one sprint, one board...

So being unable to find a solution that would enable good sizing with both team working in the same sprint, I'm hoping some of you might have encountered the same issue and found a solution or have ideas about a possible improvement.

TLDR :

How to plan and manage sprints with user stories requiring a specific group to dev and a specific group to test for the user story acceptance without empty time for one group ?

Answer 1

Lets break your problem down to the simplest case.

You have one story, one dev, one tester and one sprint to deliver the tested story.

If The story is fully specced the dev should be able to complete the work in half a sprint. The tester has no work to do as the dev will test thier code against the spec before delivery.

If the story is vaguely specced, the tester has to write test cases which essentialy will add tasks to the story. This will take them half a sprint.

But since these added tasks are unknown at the start of the sprint the dev is unable to commit to completing the dev work for the story and therefore has nothing to do that sprint.

Therefore: It is impossible for testers and devs to work on the same story in the same sprint if they are committed to finishing the story. QED.

If you must do it then you will have to break a rule. Have the testers work on v2 of the story, have the devs commit to techincal tasks rather than entire stories or have the tester work on the stories in advance of the devs.

Answer 2

What comes in and out of every sprint should be pacted and both parts agreed on all the issues/task/items (customer and dev team). So the boundaries and scope of the development is set and it's also the scope of the tests.

With tasks pacted dev team can start to design and then to implement. Meanwhile testers (who certificate the release of the sprint) should be planning and designing all the user cases involved in the sprint. Use case of success, alternative user case of success and the most important, use case of errors. ALL of them!!!. Then apply these scenarios during the testing phase. Finally start the process of tracking issues for further sprints.

Takes long to make a plan of unit tests, integration tests, functional tests, regression test, etc. For successful scenarios but it even takes longer to find out every possible scenario of error.

Testers should be like end users. To be up date about requirements and the business. In this face QA will find lot of unexpected scenarios that nobody saw during functional analysis and those that happens cause unplanned changes (and we all know they happens every day). Some changes have a deep impact and devs or analyst could miss some.

However devs should make tester team work easier. Devs should to do all the unit test related to their implementations. Also Integration test if needed.

It's a cooperative work. Both teams should work together. Looking at the same goals.