Agile software development teams thrive on collaboration and communication. Successful teams often highlight their cross-functionality, integrating concerns from engineering, product and design- but they can also benefit from integrating a less talked-about concern: QA.

Quality assurance (QA) can mean various things to various people, at different stages in the development life cycle. From general code quality to varying degrees of unit, integration, end-to-end and regression testing- to the teams or systems tasked with ensuring these tests pass, and reporting the appropriate stakeholders when they do or don’t.

Sometimes QA processes are wholly automated and baked into a continuous delivery pipeline. Sometimes QA people work in close collaboration with engineering and product. And sometimes a QA team is far removed (geographically or organizationally) from the agile team; they may never interact with developers unless they find a bug, and may never have any context of the product other than a step-by-step testing script.

Recently my company integrated our QA team members into our agile teams, and I would like to share some of the lessons learned. First the scene, from my point of view as a software developer:

Before

• QA is an external team, located in a different state from most of the developers and product team members.

• QA has separate Selenium scripts, as well as manual testing instructions.

• Web developers have no transparency into the QA team and their workflow, other than the names of people who check a box in Jira or Trello to “fail” a task for not meeting some acceptance criteria, or for introducing a new bug.

• Regressions (new bugs) are often discovered many weeks after development, during quarterly (as stipulated by client regulations) release regression testing periods. This removes the developers from much of the context for what they built, making bugs harder to find and fix.

• Testing periods before quarterly releases are very stressful for QA and developer team members.

Steps we took

• QA attends daily standups, biweekly demos, retros and other ad-hoc agile training alongside developers and product.

• Developers and QA team members pair on building out and maintaining end-to-end tests in Protractor.

• We have lots of cross-team chat communication throughout the week, sometimes debugging in pairs over video or screenshare.

Improvements from integrating QA team members into our agile teams

• Ownership of the development process: Everyone is a “developer” as QA becomes more invested in building the product and developers steward their work further toward delivery.

• Empathy for QA team: Engineers witness and participate in parts of QA process.

• Reduced stress: Communication breakdowns and us-vs.-them mentalities are avoided, creating a more relaxed atmosphere, both socially and in working relationships.

• Everyone learns: Knowledge is shared about testing, automation, debugging and Definition of Done
• QA team members build skill sets by learning about the development process and codebase, gaining context of the larger ecosystem of the apps.
• Developers build skills in automated testing and debugging, using tools and dashboards that were previously “only QA.”
• Product learns to write better acceptance criteria, with the end-to-end tests and QA process further baked into the definition of done.

• More scalable through automation: As our platform took on more and more clients, QA needed to hire more and more people, which did not scale. Automating these processes and investing some development time into the issue leads to an immediate and future payoff.

• Quality improves: Fewer new bugs surface in quarterly regression testing periods.

• Development time saved: The feedback loop for work to pass QA closes dramatically, allowing downstream delivery to happen quicker.

• Accountability, teamwork and camaraderie create self-reinforcing feedback loops.

Adopting an agile framework that integrated team members from engineering, product, design and beyond had already helped our team build working, sustainable software faster, in a far less stressful environment. And these gains were easily extended when integrating QA team members.

Fine print: Yes, it’s complicated

Many organizations put significantly fewer resources into QA and would see this transformation as prohibitively or superfluously costly. My company had client stipulations requiring a certain QA threshold per release, and our team members could not work outside the US because of regulations.

Although there was a time cost in integrating QA team members into the ceremonies of our sprints, and we spent development resources when taking on end-to-end testing and pairing with QA team members, many hours and bugs were also saved by the automation and process improvements. And as with any process transformation, improvements can be made incrementally. As a start, you could easily integrate one or two QA team members, and they could report back to the rest of their teams, already increasing communication and collaboration.