In-Sprint QA

61 team-in-sprint-qa

In-Sprint QA integrates quality at the Team level, making it a first class citizen in the Agile process. When properly integrated, Agile teams can commit to tasks being built and tested against the user story within the same iteration, when the cost to address defects is significantly less.

Explore More.

Inputs:

The input for In-Sprint QA is design assets, semi-working code, and ideally almost ready to ship code. These inputs should come from all members on the team level.

Outputs:

The output of In-Sprint QA is documented and duplicate bugs that can be given back to team members and evaluated as meeting the Acceptance Criteria for the story.

Building high-quality software isn’t the role of a single person or team, it requires the efforts and commitment of the entire team.

In-Sprint QA is normally conducted by a QA Engineer, but the overall responsibility may be shared in certain cases with other members of the Agile team.

There are a few primary actions that the person assuming the role of In-Sprint QA will engage in during the course of a sprint:

  • Creating test cases from Acceptance Criteria (AC) - By reviewing stories and artifacts from previous sprints, a person performing QA for the sprint should be able to create test cases that will be used during the sprint. Depending on the type of solution and testing environments, ideally this individual can write end-to-end tests from these Acceptance Criteria.
  • Reviewing design and development artifacts - All design and development artifacts should be reviewed through the lens of quality with the experience in mind. Designs should be reviewed for unhappy paths and other potential ‘gotchas’. Development artifacts should be reviewed for potential limits.
  • Reviewing “ready for test” working software - As work progresses, it will eventually reach a point where development is nearing a completion. It is at this point that the QA Engineer for this story can begin their test cases, assuring software meets all the AC. By linking manual and automated tests to specific AC, the QA engineer is able to begin testing against a story that is partially complete.
  • Writing defects - It is not the responsibility of the QA Engineer to build perfect software. However, it is their responsibility to surface all instances of less than perfect software and let the product owners decide what is worth fixing. To make those decisions, product leadership will need to have all defects replicable, with enough detail for quick decisions about priority.

All of these activities should be done in the most transparent method possible. Team members should communicate to one another the status of what they are working on during the sprint. This communication should begin in the daily stand up, and it should continue in conversations throughout the day. Defects should not be delivered all at once on the final day of the sprint.

Fully tested and validated Acceptance Criteria should be a part of the ‘definition of done’ for an Agile Feature team.

Common Pitfalls

All organizations have to address the advantages and costs of building the highest quality software. There are some frequently observed issues that cause derivation from the ideal implementation:

  • Lack of communication of goals - The choice to let a defect into production software needs to be communicated across the entire team. It is unrealistic to think that software will ever exist without defects. There will always be a problem on an obscure device or browser. It’s important that before these defects are allowed into the system, guidelines are established to limit the amount of churn in the future supporting non-supported situations.
  • Using too much detail - “Simplicity—the art of maximizing the amount of work not done—is essential”1 When writing defects, a delicate balance must be struck between over communicating and not giving enough detail. The goal of a defect is that someone with working knowledge of the system can read it, duplicate it, and decide how to act on it with as little effort as possible.
  • Lack of transparency early in sprint - Early in a sprint communication, it is essential for the team to keep moving and reduce likelihood of future problems. This communication can be broken into a few main sections.
    • The QA Engineer needs to share test cases with the design and development team. The test cases don’t need to be approved, but they should be available for everyone to review and reference when working.
    • The design and development resources need to show the QA Engineer artifacts and working code as soon as it exists. If done properly, the QA Engineer will spend the first few days of an iteration writing Acceptance Criteria for future user stories, and after the first few days they will transition to testing Acceptance Criteria for stories in the current iteration as soon as they are completed.
  • Only using specialized QA resources for QA - Mature teams tend to try to staff a dedicated group of QA Engineers. This is encouraged, but it is also important to consider every member of the company a potential QA resource. There is no reason why QA can’t train designers, developers, and product people to help in the testing process. This falls into the team ethos for Agile development. The team commits to the objectives and stories, and all team members help ensure it happens, even if one discipline is delayed or needs extra capacity.
  • Not having a consistent QA resource - On the flip side, it is also destructive to have no consistent QA Engineers. QA Engineers contribute to velocity just as developers and designers do. With that being said, we recommend having a dedicated QA Engineer for each team and not changing that team member unless you have no other choice.

References