Agile, in a nutshell, provides an approach to delivering business value features in short development iterations, typically of two to four weeks. Two basic pillars that are hallmarks for any Scrum team are that they are cross-functional (they include every skill set necessary to get the job done) and they are self-organizing (the team is expected to figure out by itself how to get the job done best). The question I always ask is that whether we get the best out of Agile if we compromise on either of these basic pillars.
The industry is slowly moving from teams comprised of islands of specific skill sets to multi-skill-set teams, as we graduate from traditional Waterfall to neo concepts of Agile and Scrum. The challenge we see every day from a QA standpoint is how we justify the need for QA right from the inception of a project, and leave the traditional mind-set of just writing test cases, conforming to requirements, reporting bugs, and calling it quits. This break from tradition raises eyebrows among many clients, developers, and business stakeholders new to Agile. "How can testing professionals engage effectively during a sprint before anything is built?"
Let's try to answer how a traditional Waterfall QA team, which is used to getting involved at the very end of the project once all coding is complete, can start providing value right from the beginning. The journey of transition from specific skill set to multi-skill set is long, and we ought to find some ways to be relevant. QA expertise can't be lost, as it is a vital skill set for the industry as a whole.
Estimate user stories better
All along, the traditional QA mind has been trained to think beyond "happy paths." QA folks excel at identifying and capturing complex and negative test scenarios. This helps the Scrum team come up with a realistic estimate at the start of the user story itself, and thus better release planning and fewer surprises to the business stakeholders around what user stories were committed and which were delivered.
Take the lead in collaborating with the product owner
QA folks have the best-end-to-end view for an application and thus they are better equipped to think holistically and act as liaisons between the Scrum team and the product owner. QA team members can work closely with the product owner to write detailed acceptance criteria for the user stories. Based on what the team learns after the retrospective meetings, QA can help the product owner modify or enhance the existing user stories to better reflect the true requirements.
Be a proxy product owner
QA can act as a proxy product owner when the product owner is not available (thanks to the end-to-end view of the application and experience with writing acceptance criteria test cases). Thus QA can help the team move forward at all times.
Provide fast feedback
QA and developers work together in Scrum all the time, and this "lightweightedness" can help the developer to always consult with QA about the acceptance criteria of any functionality (user story) from the user's perspective, while working in the feature that results in saved testing and bug-fixing cycles.
Uphold the Definition of Done
QA can enforce the Definition of Done. A DoD is nothing but a list of team-defined completion criteria, which must be completed before the user story can be deemed complete. A basic DoD can comprise the following things:
Unit test complete
Functional/UI test complete
DB test complete
Approved by product owner
Though it is not the sole responsibility of QA to define the DoD, the fact that they are the last in the chain for completion of a user story means they can expand the role of gatekeeper and make sure the checklist is followed completely.
Test with strategy
Having a dedicated test lead is very difficult and luxurious in a Scrum team, so building a formal test plan can be an issue. Scrum believes in preparing only enough documentation to support the immediate needs of the team. As such, the QA team can always come up with high-level strategies and documentation to help the developer find friends from the Scrum team to help them test.
Take ownership of doing demos
At the end of each sprint, the team holds a sprint review meeting, where the team must demonstrate the user stories completed during the sprint to the product owner and other interested stakeholders. This sprint review meeting provides a healthy dose of accountability to the team and motivates them to complete as many user stories as possible.
With small sprint cycles of two to four weeks, everyone on the team must stay focused on his or her respective tasks in order to complete them on time. Developers stay busy developing their assigned user stories and fixing bugs while QA stays busy writing test cases and clarifying questions from product owners. Having short sprint cycles also means that developers have less time to explore the complete functionality of their user stories on their own. As a result, developers typically consult with QA to better understand the user stories, since they are the ones aware of the complete functionality and know each and every requirement and acceptance criteria. As a result, it can be a good practice for QA to perform the demo at the sprint review meeting and field functional questions coming from business. That can free up the developers to handle any technical questions that surface.
Move toward the business tester (amalgamation of tester and business analyst) role in the long run
On Scrum teams it is common to see the responsibilities of QA and those of the business analyst begin to converge. The business analyst role is typically responsible for creating and maintaining the sprint and product backlogs, analyzing the user stories from the business perspective, and prioritizing the backlogs with input from the product owner. The QA role, on the other hand, is typically responsible for defining/refining the acceptance criteria for each user story, testing the completed functionality during each sprint from the end user's perspective, and ensuring that all previously completed functionality has not regressed. As QA tests each user story and verifies that the defined acceptance criteria has been met from the end user's perspective, they are also analyzing the user stories in term of the business. So in many ways the QA role and the business analyst role share responsibilities, required skills, and overall objectives.
Normally, a Scrum team gets user stories and the predefined project scope from the product owner at the beginning of a project. However, in Scrum the team is encouraged to suggest new features or changes to existing features if it will improve the end user's experience. The team is also encouraged to recommend changes to the priority/sequencing of user stories in the backlog when they find technical dependencies that suggest a different implementation order would be more efficient. Whether it's defining requirements, analyzing user stories, defining/clarifying acceptance criteria, building acceptance test cases, or closely working with customers, the roles of tester and analyst are clearly converging. While this offers many advantages -- particularly for small teams -- it also has its disadvantages as well. The biggest concern is that neither the tester nor the business analyst role will get as much attention as it would with a team member fully dedicated to that responsibility.
Summary and conclusion
QA expertise is important and should be preserved. It can benefit the Scrum team and project as a whole in many ways until the transition to being fully cross-functional is complete. Rather than going "big bang" and trying to find multi-skill-set folks, the inside-out approach of nurturing the QA talent to pick up project activities and evolve to become developers with core QA strength or business testers or full-fledged product owners is effective.