Quality Assurance often finds itself relegated to a series of tactical checkboxes-run these tests, verify those features, report these bugs.
In the short term, so what? But if you care enough to incorporate QA, you want to build long-term. This narrow view leads to a brittle and unsustainable QA process. As systems grow more complex and development cycles shorten, this tactical approach crumbles under its own weight, unable to scale or adapt to new challenges.
Building maintainable and scalable QA requires a strategic mindset. It's about creating an environment where quality is woven into the fabric of your organization, where it's not just a phase but a continuous, evolving process. It's about fostering a culture where everyone-not just QA engineers-is responsible for quality.
Seeding a QA culture
We've talked before about how we need to kill QA. But what we're talking about is killing QA as a tactical process. It must die as a bolted-on, last-box-checked component of the software development lifecycle.
Quality needs to subsume the entire organization.
Now, this is obviously a stupid thing to say. It's not like developers are striving for non-quality. But the reality is that quality often gets sacrificed on the altar of deadlines, feature pressure, and the relentless pace of modern software development. It's not that developers don't care about quality; it's that the system often doesn't prioritize it effectively.
So when we say quality needs to subsume the entire organization, what we're really advocating for is a fundamental shift in how we perceive and prioritize quality:
- Quality as an Engineering Responsibility. Break down the notion that quality is the sole responsibility of a QA team. Instead, cultivate a mindset where quality is everyone's job.
- Quality as a First-Class Citizen. Elevate quality considerations to the same level as feature development and business objectives. Quality metrics should be as visible and important in executive dashboards as revenue or user growth.
- Quality as Technical Excellence. Position quality as a key component of technical excellence. Just as we celebrate great code or architectures, we should celebrate robust test suites and effective quality processes.
- Quality as Cultural Value. Embed quality into the core values of the organization. This means rewarding quality-focused behaviors, standardizing culture around testing, celebrating quality wins, and making quality a key part of evaluating performance across the board.
By reframing quality in these ways, we move beyond the simplistic view of QA as a series of tests or a phase in development. Instead, we create an environment where quality permeates every decision, every line of code, every product discussion.
The challenge, of course, is in the implementation.
Communication is the foundation of effective QA
How does siloed quality manifest?
QA engineers often need developers to add specific CSS selectors into the app for end-to-end testing. In theory, this should be a straightforward request. However, in practice, it often plays out like this:
- QA engineers communicate the need for these selectors to the developers.
- Developers, focused on feature development and deadlines, may overlook or deprioritize these requests.
- Frustrated by the lack of action, QA engineers eventually add the selectors themselves in a separate commit.
This seemingly small interaction exemplifies the larger problem of siloed quality practices. The first is misaligned priorities. Developers and QA engineers are working towards different immediate goals, even though their ultimate objective-a high-quality product-is the same. They are in this position because of inefficient communication. The initial request from QA to developers isn't effectively conveyed or doesn't convey the importance of the task.
As we said about seeding quality in the organization, this really stems from alack of shared responsibility. Here, the developers don't see adding these selectors as part of their role in ensuring quality. Thus, we get the bane of dev teams everywhere: increased technical debt. When QA engineers add selectors themselves, it can lead to inconsistencies in the codebase and potential maintenance issues down the line.
Best practices for better QA communication
More pragmatically, we need to set out specific strategic best practices that allow us to execute at a higher level than the tactical best practices we hear about in testing.
Integrate workflows
The definition of "done" should be expanded to include quality-related tasks. This could include:
- Adding selectors, like above
- Performing code reviews with a specific focus on testability and potential edge cases
- Updating relevant documentation, including API docs and user guides
- Conducting accessibility checks to ensure features meet WCAG guidelines
This can also include introducing quality gates at various CI/CD pipeline stages. These gates should check for functional and non-functional requirements before allowing code to progress. This will also mean including QA engineers in planning sessions to ensure quality considerations are baked into task estimations and acceptance criteria and implementing quality-related OKRs for all team members, not just QA engineers.
Incorporate AI
AI is the future of QA. QA engineers will then become responsible for the strategic drive for quality.
AI testing tools can:
- Generate test cases: AI can analyze application code and user flows to create comprehensive test suites automatically. This saves time and often uncovers edge cases that human testers might overlook.
- Auto-heal tests: AI can automatically update test scripts when UI elements change, reducing maintenance overhead. This adaptability ensures that tests remain robust even as the application evolves.
- Reduce time spent writing and maintaining test code: AI-powered tools can suggest optimizations for existing test code and even generate new tests based on application changes. This allows QA engineers to focus on more complex, strategic testing tasks.
Automating QA allows you to "shift testing up," where QA engineers can focus on higher-level quality strategies and exploratory testing. This shift enables teams to improve overall product quality while increasing the testing process's speed and efficiency.
Surface quality metrics
Quality metrics-escaped bugs, defects, time to test-are how QA engineers rate themselves. But in siloed organizations, these metrics are kept to the QA teams.
The practice should be to hold everyone accountable to these metrics. This means making quality metrics visible and important across all teams, from development to product management to executive leadership. Quality becomes a shared responsibility by integrating these metrics into company-wide dashboards and regular review processes.
This visibility can drive behavior change, encouraging developers to think more critically about quality during development and helping product managers prioritize quality-related work. Moreover, it can facilitate more informed decision-making at all levels of the organization, balancing feature development with quality improvements.
Conduct blameless post-mortems
Things will go wrong. A bug will escape into the wild. Tests will fail.
But when fingers get pointed, everyone retreats and stops sharing. Regular blameless post-mortems allow teams to openly discuss what happened, why it happened, and how to prevent similar issues in the future. This approach fosters a culture of learning and continuous improvement.
By focusing on the process rather than individuals, teams can identify systemic weaknesses and implement more robust solutions. Blameless post-mortems also encourage transparency and trust within the team, as members feel safe sharing their perspectives without fear of repercussion. This open dialogue often leads to innovative ideas for improving quality processes and can ultimately result in more robust, more resilient systems.
QA at scale requires everyone
How do we make this shift without disrupting productivity? How do we measure success in this new paradigm? How do we balance the need for speed with the demand for quality?
Forward-thinking organizations must grapple with these questions as they build and scale truly maintainable QA processes.
The truth is, there's no one-size-fits-all solution to building and scaling maintainable QA. Each organization, each product, each team has its unique needs and constraints. However, this doesn't mean we're left without direction. Instead of focusing solely on specific practices or tools, we need to elevate our perspective and consider QA an integral part of the development ecosystem.
By shifting our focus from short-term tactics to long-term strategy, we can create a QA process that keeps pace with rapid development and drives innovation and quality. We're building AI testing to allow engineers and teams to do exactly that. If you want to see how AI testing can increase product quality while allowing you to move to a more strategic QA mindset, come talk to us.
