.jpg "Integrate QA in The Agile Sprint Process | Freeport Metrics (1)")
How do you create a sprint plan so that all development and testing tasks are completed on time and on budget? What is the most effective way to engage QA before anything has been built? How many testers will you need per developer? What is the role of the QA Specialist on the Scrum team?
Our best practices for effectively planning and executing sprint projects are the result of more than a dozen years of mobile development and web application design and development for SCRUM projects (and waterfall projects with SCRUM elements), typically with 4 to 6 members on a sprint team. The role of QA is integral to the success of each project.
During sprint planning meetings we review details of the user stories and designs and prepare task breakdowns, estimates and assignments. The project manager, developers and QA are mandatory participants for this session. QA specialists bring a unique perspective to reviewing user stories and planning tasks. They consider happy and unhappy user paths and all edge use cases, and can identify gaps or inconsistencies missed by other team members.
Once development estimates are entered into Jira tickets, we run additional verification with QA to make sure all tasks in the sprint scope are feasible to complete.
Some tasks require additional preparation/data/access/tools to enable testing by QA. If such tasks are identified up front in the sprint plan, we ensure that all blockers are removed, or additional preparation/dev tasks are included in the sprint plan. Don’t ever get caught with one or more tasks marked as Ready for QA, without the option to test them.
During sprint planning, our whole team works together to make sure that the division of tasks works well for both developers and QA. Ideally there should be some tasks ready for QA on Day 2 of the sprint. This means breaking down large development tasks into smaller ones so that QA and development are working in parallel from the start. Remember that issues reported by QA require additional communication, time for investigation of the details, and fixing in the same sprint. By keeping tasks small and fairly simple you decrease the communication overhead and the risk of missing deadlines.
Make sure that tasks are well prioritized within the sprint, namely that the most complex and time-consuming are scheduled for the early stages of the sprint. Both tests and communication around the most complex tasks take longer, so if possible they should be on the top of the sprint priorities. Every sprint plan should also be in line with overall project priorities. In order to help mitigate some other, more significant risks, we would proceed with smaller tasks/bug fixes at the beginning of the sprint, and push other tasks lower in the queue.
Ideally test cases are prepared before the sprint starts. In reality, it is not always possible. Some test cases can be created or updated only after the sprint planning session and final clarification of any open issues. The beginning of the sprint is the best time to schedule this task. While the first development tasks are underway, QA can be writing/finalizing test cases.
There may be numerous issues reported by QA during the sprint. Not all of them have to be fixed within the same sprint schedule. We make a critical assessment of each issue, usually dividing them into one of two categories.
- Blockers. Directly related to the planned scope of the sprint, or different features that are important from a business perspective.
- Low priority. Usually smaller issues that can be moved to the backlog and fixed in the future sprints.
Last minute change orders are verified with developers and QA before committing to a different scope. It is not correct for project management to swap out tasks with similar development estimates. We take the time to consider whether more effort for testing is required by the new task than the one being swapped out, and that the analysis and re-planning take time as well.
Ideally full regression testing would be done before each release, especially with production releases. This would usually be applicable for small products, when full regression testing takes max 6-7 hours. With larger products, we select the parts that are most affected by the new work during the sprint to perform regression testing.
There’s an obvious benefit to automating something versus doing it manually. With agile projects, however, it may be difficult because the feature you are developing during the sprint may not be in its final state. Decisions about adding automated tests to the scope of the project should be based on a thorough analysis of project budget distribution.
When embarking on your next sprint, and every one after that, be sure to involve your QA team from the very beginning of project planning until final execution. Following these few simple best practices will help make you a better team.
