In a traditional software organization, responsibility for quality assurance activities falls to a dedicated QA team. The QA team is intentionally separated from design, development, and operations, often reporting up through an entirely different branch of the organization. QA engineers focus entirely on building, running, and reporting on tests. They interact at arms length with marketing and development through the mechanisms of the specification, build, and defect-tracking system.
QA traditionally plays an adversarial role within the software delivery lifecycle. It is up to them to “certify” a release’s quality. They often have, or are perceived to have, the authority to stop a release from being delivered to customers.
Pervasive QA dissolves the boundaries that separate QA from marketing, design, development, and operations. It disperses responsibility for many QA activities across other teams. Marketers design A/B tests and interpret the results. Designers conduct user testing sessions. Developers write unit tests. Operations runs game day exercises, reads monitoring dashboards, and deploys chaos monkeys.
Automation further erodes dedicated QA. Software QA teams spend a surprising amount of their time on tedious, repetitive activities. They manage test suites in spreadsheets and execute them by hand from the command line. They manually correlate test results and hand-generate reports after each test run.
Automating the ...