QA Is the Backbone of Software Quality and the Difference-Maker for AI Systems

Every software system that reaches production depends on a layer that users rarely notice when everything works as expected: testing strategy, automation, defect management, regression coverage, release controls, and continuous validation. When that layer is strong, engineering teams can move faster with greater confidence. When it is weak, problems that should have been caught during development reach production, where they become customer-facing incidents, operational costs, security risks, and reputational damage.

That is why Quality Assurance (QA) should not be treated as a final project phase. It is part of the engineering foundation that supports the entire software lifecycle. The principle applies to conventional applications, but it becomes even more important as organizations introduce artificial intelligence into their products.

AI systems bring a fundamentally different quality challenge. A traditional application can often be tested against predictable rules: given an input, the system should return a defined output. AI systems may produce different results depending on the model version, prompt, context, data, retrieval results, or even changes in the surrounding system.

For organizations putting AI into production, simply asking “Does it work?” is no longer enough.

The more important questions are: Does it produce reliable results? Can we measure that reliability? Can we understand why it failed? And can we safely detect and correct quality degradation over time? That is where modern QA evolves into Quality Engineering.

QA is sometimes reduced to finding bugs before a product launch. In mature engineering organizations, however, its role is much broader. Quality engineering establishes the mechanisms that allow teams to understand whether software behaves as intended throughout its lifecycle.

That includes:

• Defining what “good” looks like before development begins.
• Designing tests around business-critical workflows.
• Automating repetitive and regression-heavy scenarios.
• Validating integrations and system behavior.
• Tracking defects and identifying recurring failure patterns.
• Measuring test coverage and release readiness.
• Establishing quality gates before production.
• Monitoring software behavior after deployment.

This makes QA an ongoing control system, not a checkpoint.

The distinction matters because software quality is not created by testing alone. It is created by integrating quality into engineering decisions from the beginning.

NIST's software verification guidance similarly emphasizes a combination of practices such as automated testing, black-box and structural testing, historical test cases, fuzzing, threat modeling, and other verification techniques rather than relying on a single testing method.

In other words, quality is strongest when it is built into the development process rather than inspected into the product at the end.

Traditional software testing often benefits from deterministic behavior. Consider a payment form. If a user enters a valid card number and submits the form, the application should follow a defined flow. The same input should produce the same expected result under the same conditions.

That makes it possible to write assertions such as:

Given this input, the expected output is this.

AI systems complicate that equation.

A large language model, recommendation engine, computer vision system, or autonomous agent may produce different results depending on:

• Model versions
• Prompt changes
• Context windows
• Retrieved information
• Training or inference data
• Temperature and other parameters
• Tool calls
• External APIs
• Agent decisions
• Changes in system instructions

This does not mean AI systems cannot be tested. It means they cannot be tested exclusively through the deterministic methods traditionally used for conventional software.

Research from Google has highlighted this challenge in production machine learning systems: model behavior can be difficult to specify in advance, which requires testing and monitoring approaches specifically adapted to ML systems.

The result is a shift from simply testing whether the software functions toward continuously evaluating whether it produces acceptable, reliable, and trustworthy outcomes.

For conventional software, a test may have a straightforward outcome:

• Pass: The login succeeds with valid credentials.
• Fail: The login succeeds with invalid credentials.

For AI, the evaluation might be closer to:

• Acceptable: The generated answer is accurate, relevant, grounded in the available information, and follows the required policy.
• Unacceptable: The answer contains fabricated information, exposes restricted data, ignores instructions, or falls below an established quality threshold.

This changes the role of QA. Instead of asking only whether an AI system is operational, teams need to establish quality baselines and continuously compare production behavior against them.

Google's ML Test Score research proposed a structured set of tests and monitoring practices specifically because production ML systems introduce risks that conventional software testing does not fully capture. NIST's AI evaluation work takes a similar principle further, emphasizing structured testing and evaluation across different AI capabilities and modalities.

The practical lesson is straightforward: AI quality needs to be measured, not assumed.

Building a reliable AI system requires more than running a test suite before deployment. The QA strategy needs to account for the behavior of the complete AI system and how that behavior changes over time.

Replayable Execution Traces

When an AI agent produces an unexpected result, knowing that it failed is only the beginning. Engineering teams need to understand why it failed.

• What prompt did it receive?
• What context was available?
• Which documents were retrieved?
• Which tools did it call?
• What intermediate decisions did the agent make?
• Which model version was running?

Without this information, reproducing an AI failure can become extremely difficult.

Replayable execution traces create a record of the system's behavior so engineers can reconstruct an interaction and investigate the failure later. This becomes particularly important for agentic systems, where a single user request may trigger multiple model calls, tool interactions, retrieval steps, and decisions.

Versioning Models, Prompts, and Agent Logic

Application code is normally version-controlled. AI systems require the same discipline to extend beyond source code.

A production AI system can change because of:

• A new model version
• A modified system prompt
• A different retrieval configuration
• A new knowledge base
• A changed agent workflow
• A new tool
• A different embedding model
• Updated safety policies

If these components are not tracked, an engineering team may know that something changed without knowing which change caused the quality regression. Versioning AI components alongside application code creates a much stronger foundation for testing, debugging, auditing, and rollback.

Evaluate Against a Quality Baseline

Uptime does not equal quality. An AI application can have 99.99% availability while producing increasingly poor answers. That is why AI QA needs metrics beyond infrastructure health.

Depending on the use case, teams may evaluate:

• Accuracy
• Relevance
• Groundedness
• Completeness
• Consistency
• Latency
• Hallucination rate
• Retrieval quality
• Safety violations
• Task completion
• Human evaluation scores
• Cost per interaction

The appropriate metrics depend on what the AI system is supposed to accomplish.

For example, a customer-support assistant might prioritize groundedness and successful resolution, while a clinical classification system may prioritize prediction accuracy, recall, precision, and safety.

Google's research on ML data validation also demonstrates why quality cannot stop at the model itself: errors in production data can undermine model performance even when the underlying algorithm is functioning correctly.

Build Safe Release and Rollback Gates

AI changes should not move directly from experimentation into production simply because the system passes a basic functional test. A stronger process introduces staged promotion:

Development → Evaluation → Staging → Controlled Release → Production

At each stage, the system can be evaluated against predefined quality criteria. If a new model or prompt performs worse than the baseline, the release should be blocked. If quality degrades after deployment, the team should have a documented rollback mechanism. This approach turns deployment into a controlled engineering decision rather than a binary switch.

NIST's AI Risk Management Framework also emphasizes processes for evaluating AI systems and making explicit go/no-go deployment decisions.

Govern AI Memory and Data

For AI systems that use retrieval, persistent memory, or external knowledge sources, QA must also account for what the system knows when it makes a decision.

A response can be technically valid but based on outdated, incorrect, or unauthorized information. Data quality therefore becomes part of system quality.

This includes validating:

• Data sources
• Document freshness
• Access permissions
• Retrieval behavior
• Data transformations
• Embeddings
• Context passed to models
• Persistent memory
• Data lineage

This is particularly important in regulated or sensitive environments, where teams may eventually need to demonstrate not only what an AI system produced but also what information influenced that result.

Enforce Guardrails at Runtime

Testing in a controlled environment is necessary, but it is not sufficient.

Production traffic introduces combinations of inputs, behaviors, integrations, and edge cases that may never appear in a pre-release test set. Runtime controls can therefore act as a second layer of defense.

Depending on the application, these may include:

• Input validation
• Output filtering
• Permission checks
• Content policies
• Tool restrictions
• Rate limits
• Human approval steps
• Sensitive-data detection
• Confidence thresholds
• Fallback mechanisms

This creates a layered approach where QA does not end when the system reaches production.

Automation is an important part of modern QA, but Quality Engineering is not synonymous with automated testing.

Automation answers:

Can we repeatedly verify this behavior?

Quality Engineering asks a broader question:

Have we designed the system and delivery process so that quality can be measured, maintained, and improved continuously?

That distinction becomes critical for AI.

A highly automated test suite can still miss:

• Model drift
• Data-quality problems
• Prompt regressions
• Retrieval failures
• Unexpected agent behavior
• Hallucinations
• Security vulnerabilities
• Changes in user behavior
• Performance degradation

The goal, therefore, is not to automate every possible test. The goal is to build a quality system in which automation, human evaluation, observability, governance, and engineering controls reinforce one another.

Automation is an important part of modern QA, but Quality Engineering is not synonymous with automated testing. A mature QA program needs measurable signals.

For traditional software, useful indicators may include:

• Test coverage
• Defect density
• Regression pass rate
• Escaped defects
• Automation coverage
• Mean time to detect
• Mean time to resolve
• Release failure rate

AI systems add another layer of quality indicators. Depending on the application, teams may track:

The important point is that there is no universal AI quality metric. A useful QA strategy starts with the system's business purpose and defines measurable quality criteria around it.

The value of sustained QA becomes clearer when looking at software systems that operate at scale.

Scaling QA Without Sacrificing Speed

When Applause needed additional QA expertise on a tight timeline, Waverley assembled a distributed QA team within one week. The team supported iOS and Android testing through a shared technology approach and worked across projects involving companies including Mastercard, Nike, Trulia, and Carbonite.

The engagement combined functional and compatibility testing, test infrastructure, automation, device testing, bug management, and documentation. The result was not simply more test cases—it was greater testing capacity that helped clients improve product quality and time-to-market.

This is an important distinction: QA capacity becomes a business capability when it is integrated into the engineering workflow.

Turning Low Test Coverage Into an Engineering Asset

Freeman EMEA provides another example of how quality engineering can evolve alongside a product.

When Waverley joined the project, test coverage was only around 2–3%. The team increased overall unit and integration coverage to approximately 40%, while aiming for 100% coverage of reusable components.

The QA effort extended beyond unit testing. The team introduced more structured test management, expanded manual testing, implemented automated functional and visual testing, and supported testing across APIs, integrations, payments, file processing, and the application's complex visual editor.

At the same time, the platform had to scale from supporting around 500 exhibits to approximately 3,000—six times the original volume.

The lesson is that coverage is not valuable because a percentage looks impressive. It is valuable when it gives engineering teams greater confidence as the system becomes more complex.

AI Quality Requires Model-Level and System-Level Thinking

In one healthcare machine-learning project, Waverley developed a natural language processing system designed to classify clinical text.

The system needed to process approximately 870,000 data entries. Rather than attempting to fit the entire workload into a single model, the engineering team developed 29 specialized prediction models and an additional classifier responsible for routing inputs to the appropriate model.

The resulting system achieved an average prediction accuracy of 95% and was subsequently tested against real patient data ahead of potential hospital deployment.

This illustrates why AI QA cannot focus solely on the final model.

Quality must be considered across the entire pipeline: data processing, routing, model selection, prediction, infrastructure, and eventual real-world validation.

QA as Long-Term Engineering Infrastructure

The Seagate engagement offers perhaps the clearest example of QA as sustained infrastructure rather than a one-time milestone.

Waverley initially built a QA team to help Seagate test a new network-attached storage product line under a tight delivery timeline. The team created test plans, test cases, compatibility matrices, and performed functional, regression, compatibility, usability, localization, and ad hoc testing.

The initial engagement was expected to last four months.

Instead, Seagate retained the team for future products, and the QA relationship has continued since 2005.

That longevity reinforces a broader point:

Software quality is not something an organization achieves once. It is something engineering teams continuously maintain as products, users, infrastructure, and requirements change.

Whether you are evaluating an internal QA organization or a software engineering partner, these questions can quickly reveal where your quality process stands.

1. Do you measure quality beyond uptime?

For AI, a system being available does not necessarily mean it is producing useful or trustworthy results.

2. Can you reconstruct an unexpected AI interaction?

If a model or agent produces a problematic result, can your team determine what inputs, context, model version, tools, and decisions led to it?

3. Are AI components versioned?

Are models, prompts, retrieval configurations, agent logic, and other critical components tracked with the same discipline as application code?

4. Do you have defined quality baselines?

Can you compare a new model, prompt, or system version against an established benchmark before promoting it?

5. Is there a controlled path to production?

Do releases pass through evaluation and staging gates, with a clear rollback strategy if quality deteriorates?

6. Are production signals feeding back into QA?

Does information from real users, incidents, monitoring, and production behavior become part of the next testing cycle?

7. Do you treat data as part of the quality equation?

Can you identify data-quality problems, drift, outdated knowledge, or retrieval issues that could affect AI behavior?

If several answers are “no,” the problem is not necessarily that your system is unsafe or unreliable today. It may simply mean that quality engineering has not yet evolved at the same pace as the system itself.

The strongest QA strategies start before the first test case is written.

• During Discovery

Define what quality means for the product.

For AI systems, establish acceptable behavior, risk boundaries, evaluation criteria, and the metrics that will determine whether the system is ready for production.

• During Development

Introduce automated unit, integration, API, security, and regression testing alongside development.

For AI components, begin building evaluation datasets and baseline measurements early rather than waiting until deployment.

• During CI/CD

Make quality checks part of the delivery pipeline.

A build should not move forward simply because the code compiles. It should meet the relevant functional, performance, security, and AI evaluation criteria.

• During Staging

Test realistic scenarios, edge cases, integrations, and production-like data conditions.

For AI agents, this is also where teams can evaluate multi-step workflows, tool use, failure recovery, and unexpected inputs.

• During Production

Monitor both technical health and output quality.

The system should provide enough observability to detect regressions and enough control to contain them.

• After Release

Feed production insights back into the testing strategy. Every significant incident, unexpected output, or newly discovered edge case can become a future test case.

This creates a continuous loop:

Build → Test → Evaluate → Deploy → Monitor → Learn → Improve

That is the foundation of modern Quality Engineering.

AI is not making QA less important. It is making high-quality QA more sophisticated.

As organizations deploy generative AI, machine learning, and autonomous agents into increasingly important workflows, the definition of software quality is expanding.

It is no longer enough to verify that an application does not crash.

Engineering teams need to understand whether the system behaves reliably, whether its outputs meet defined standards, whether changes can be traced, whether failures can be reproduced, and whether the system can be safely controlled in production.

This is why the strongest AI initiatives will not be built around models alone.

They will be built around models + data + software engineering + observability + evaluation + governance + quality engineering.

DORA's 2025 research reinforces the broader engineering lesson: AI tends to amplify the strengths and weaknesses already present in an organization's underlying software delivery system. The value therefore comes not simply from adopting AI tools, but from strengthening the systems around them.

For companies adopting AI, that means QA should move closer to the center of the engineering strategy, not further away from it.

The most impressive AI demo is not necessarily the most valuable AI system.

A production system has to perform consistently under real-world conditions, handle unexpected inputs, protect sensitive information, adapt to changing requirements, and give engineering teams enough visibility to understand when something goes wrong.

That is why QA is the support structure behind software quality, and one of the biggest difference-makers for AI.

Traditional testing remains essential, but AI requires organizations to extend QA into continuous evaluation, observability, versioning, governance, runtime controls, and production monitoring.

The objective is not to eliminate every possible failure.

It is to build systems where failures can be detected, understood, contained, and corrected before they become business-critical problems.

That is the real role of Quality Engineering: giving software teams the confidence to move faster without compromising the quality that makes their products worth trusting.

Ready to make quality an engineering advantage? Build a QA strategy that scales with your software and your AI.