Help of the QA in the sprint first days of a sprint

Question

According to the Agile philosophy, it is important for the team to work together as one to achieve the goal fixed at the begenning of an iteration. With that in mind, I know that developpers and analysts can help the QA at the end of an iteration to make sure all the testing is completed in time.

How can the QA help the team at the begenning of a sprint if no Stories are completed and that test plans are ready.

(We are team of 5-6 people with 1 QA and we are on 3 Weeks sprints so the dead time can be long for the QA)

Answer 1

QA Should Never Become a Separate Process Track

Quality Assurance (QA) is an integral part of the agile delivery process. Passing tests are often a formal part of the Definition of Done, and Test-Driven Development (TDD) is a common practice that originated with Extreme Programming and has been widely adopted by other agile frameworks.

The QA specialists on a cross-functional team have several ways to contribute from day one of a Sprint:

1. They must help estimate stories, because the time and effort required for proper testing needs to be part of the story-point estimate.
2. They should work alongside the developers to ensure that unit and acceptance tests are baked into the team's process.
3. They may handle stories before the developers to ensure that new features are written to pass defined acceptance tests.
4. They may handle stories with the developers to ensure that all new work is fully testable at the unit- and integration-test levels.
5. They may pair-program with the developers so that the developers and testers cross-pollinate, share their particular expertise, and increase knowledge transfer within the cross-functional team.

While all of the examples above apply most strongly to software projects, the same general concept is largely transferable to manufacturing or business-process projects. Everyone on the team has something to contribute, and the best teams never "toss something over the wall" to other team members; the work should always remain collaborative.

Answer 2

In some teams, the testers take care of implementing automated acceptance tests while the programmers work on implementing the new features. In other cases, they start preparing test data or test scripts that will be used once the new stories are included in the build.

Sometimes, programmers may not know exactly what the impact of the new feature is going to be. Testers can help by doing exploratory testing, simulating the new functionality or similar scenarios to provide advance feedback to the programmers. Or they can talk to business users to get further clarification on their expectations, or getting ideas about how to test tricky corner cases.

But beyond all that, testers could also consider picking up development tasks, and grow their skills laterally in other areas of expertise. A good way to do that is, as mentioned in other answer, to pair with programmers.

Answer 3

I had this problem as well. One big thing we did is put in a hard WIP limit for the devs. This forced the to finish stories earlier in the sprint before they moved on to another one. This then means QA can start testing earlier in the sprint to avoid a giant bottleneck towards the end of the sprint.