Quality Assistance, Not Assurance
I manage a team of five Quality Engineerings, supporting the work of 100+ software developers. A traditional approach to quality and software testing such as Quality Assurance will not work for us.
Adapted from a post I wrote in 2022 for work.
I manage a team of five Quality Engineers, supporting the work of approximately 100 software developers. A traditional approach to quality and software testing such as Quality Assurance will not work for us, as it just doesn't scale. That's why we offer Quality Assistance instead.
What is Quality Assistance?
Quality Assistance is quality engineers (QEs) working collaboratively with developers to deliver the best experience and highest possible quality to our customers.
This differs from a traditional QA model (explained later in this post). We are not here to assure the quality of anyone’s code. We’re here to assist by partnering with developers, sharing our knowledge of quality and testing best practices, and building tools and other things that help in achieving high-quality releases.
This can look like many things, including (but not limited to):
Test automation
Provide tools for test automation (e.g., Playwright).
Write or update existing automated tests.
Help fix or identify flaky tests.
Code reviews for tests.
Code coverage audits.
Identifying missing tests or gaps in coverage.
Recommendations on how/where to add tests.
Pairing
Pair on writing tests or even for a whole PR to write tests in parallel with the code.
Calls for Testing (CfTs are internal requests for help with testing across the company.)
Participate in CfTs by doing manual testing.
Help write CfTs.
Amplify CfTs visibility and recruit participants.
Quality Guidance & Strategy
For anything from a big release to a single PR.
Can include risk analysis.
Quality Assessment / Walkthrough
For a team or a team’s quality & testing-related processes.
Bugs
Help reproduce bugs.
Help test bug fixes.
Incident Reports
Review and help generate action items.
What It’s Not
Quality Assurance, which typically places the responsibility of product quality on a single, often silo’ed, QA team.
QEs acting as gatekeepers to deploying code.
A replacement for developers/teams testing their own code, including writing unit or e2e tests.
Why Quality Assistance and not Quality Assurance?
In a traditional Quality Assurance model, a typical release cycle might look like this:
Focusing on bug detection rather than prevention, this model is very inefficient. Testing is often done at the end of the release cycle, and often the time allocated for testing (QA) is cut short to meet delivery dates. This means more bugs in production, which are costly whether they are fixed or not, as unresolved bugs may impact customers and revenue.
The chart below illustrates how the cost of bugs increases the later they are found in the development process.
Quality Assistance seeks to remedy this by encouraging quality and testing throughout all stages of software development, and by shifting the responsibility of quality from a silo’ed QA team to the entire organization.
Are you in the quality engineering or software development space? How does quality and testing work where you're at?
Let’s find some 🐛,
Brie