Software Quality Assurance Is More Than Testing: Agile Development in the Age of AI

Introduction

For many years, Software Quality Assurance (SQA) has often been associated with testing. When developers finish implementing a feature, testers verify whether it works as expected, identify defects, and report issues before the software reaches production.

Although testing is an essential part of software quality, it is only one piece of the puzzle.

Quality Assurance is about preventing defects, improving processes, managing risks, and building confidence in the software development lifecycle. Testing helps us discover problems, while a broader quality strategy helps us prevent them from happening in the first place.

This distinction becomes even more important in modern Agile environments and the age of AI-assisted software development, where teams are expected to deliver faster without compromising quality.

So, what does it really mean to own quality today?

1. Quality Assurance vs. Quality Control vs. Testing

These terms are often used interchangeably, but they represent different aspects of quality.

• Quality Assurance (QA): Focuses on the processes, practices, and standards that help teams build quality into software.

• Quality Control (QC): Focuses on evaluating the product to determine whether it meets the required quality standards.

• Testing: A key quality control activity used to evaluate software, identify defects, and provide information about product risks.

For example, when a team discovers repeated defects in an API integration, simply adding more test cases may not solve the underlying problem.

A broader QA approach would investigate why those defects occur. Are API contracts unclear? Are requirements incomplete? Is code review ineffective? Are developers missing important test scenarios? Is the test environment unreliable?

Addressing these underlying causes can prevent similar defects from appearing in future releases.

Testing tells us where problems exist. Quality assurance helps us understand why they occur and how to reduce the likelihood of recurrence.

2. Quality in Agile Development: Everyone Owns It

Agile development encourages frequent delivery, continuous feedback, and collaboration between developers, testers, product owners, and other stakeholders.

In this environment, QA cannot be treated as a separate phase that begins only after development is complete.

Quality must be considered throughout the sprint.

Shift quality left

Quality activities should begin before code is written.

During backlog refinement and sprint planning, the team should clarify requirements, identify acceptance criteria, discuss edge cases, and assess risks.

For example, consider a feature that allows a customer to update a payment method.

Instead of waiting until implementation is complete, the team can discuss questions such as:

• What happens if the payment provider is unavailable?

• How should invalid payment details be handled?

• What happens if the request is submitted twice?

• How are failed transactions logged and recovered?

• Are sensitive payment details protected?

These discussions help uncover missing requirements before they become expensive defects.

Build quality into the development workflow

Quality should be part of the team's everyday engineering practices.

Examples include:

• Developers writing unit tests alongside implementation.

• Testers collaborating with developers on functional and integration scenarios.

• Automated API and UI tests running in CI/CD pipelines.

• Code reviews checking maintainability, security, and testability.

• Static analysis and dependency scanning identifying potential problems early.

• Acceptance criteria and the Definition of Done including appropriate quality requirements.

Automation is valuable here, but automation alone does not guarantee quality. A team can have thousands of automated tests and still release a product with serious usability, security, performance, or business logic problems.

The goal is not simply to automate more tests. It is to establish an effective quality strategy.

Quality is a shared responsibility

In an Agile team, developers are responsible for the quality of the code they write. Product owners help ensure that the team understands business needs and acceptance criteria. Testers contribute risk analysis, test design, exploratory testing, and quality insights.

DevOps and platform engineers contribute through reliable deployment processes, observability, and production monitoring.

The QA professional's role is not to take quality responsibility away from everyone else. It is to help the team make better quality decisions.

3. The Role of a QA Engineer Is Evolving

As development practices evolve, the role of a QA engineer must evolve too.

Traditional testing skills remain important, but modern quality engineering requires a broader perspective.

A QA professional may need to:

• Understand business workflows and customer expectations.

• Identify risks before implementation begins.

• Design effective test strategies across UI, API, integration, and performance layers.

• Build and maintain reliable automation frameworks.

• Collaborate with developers on testability and code quality.

• Evaluate security, accessibility, resilience, and usability.

• Analyse production incidents and recurring defect patterns.

• Use metrics to support decisions rather than simply report test execution counts.

This does not mean every QA engineer must become an expert in every technical area. It means understanding how different engineering practices contribute to the overall quality of a product.

The focus shifts from asking, "How many test cases have we executed?" to asking, "How confident are we that this product is fit for its intended use?"

4. What Changes in the Age of AI?

AI-assisted development introduces another important dimension to software quality.

Developers can now use AI tools to generate code, create unit tests, explain unfamiliar codebases, suggest fixes, and accelerate repetitive engineering tasks.

QA engineers can also use AI to generate test ideas, analyse requirements, create automation code, identify edge cases, and summarise test results.

These capabilities can improve productivity, but they introduce a critical question:

If AI helps us produce software faster, how do we ensure that the software is actually correct, secure, and reliable?

AI-generated code can contain incorrect assumptions, missing edge cases, insecure patterns, inefficient implementations, or tests that merely confirm the behaviour of the generated code rather than validate the actual business requirement.

AI-generated tests can also miss important scenarios or make incorrect assumptions about expected results.

Therefore, AI should be treated as an assistant, not as an authority on quality.

AI changes the speed of development, not the responsibility for quality

Consider an AI tool that generates an API endpoint and its corresponding automated tests.

The tests may pass successfully. However, the endpoint might still expose sensitive information, mishandle concurrent requests, calculate a premium incorrectly, or fail when a downstream service becomes unavailable.

A green test report does not automatically mean that the implementation is correct.

The team must still validate business rules, challenge assumptions, assess risks, review the generated code, and independently verify important outcomes.

The more code we generate with AI, the more important it becomes to maintain strong engineering controls.

QA engineers need to validate the tests themselves

When AI generates test cases or automation scripts, we should ask:

• Do these tests reflect the actual business requirements?

• Are the expected results independently verified?

• Are important negative and boundary scenarios covered?

• Can the tests detect a defect, or are they merely confirming the current implementation?

• Are selectors, assertions, and test data reliable?

• Could the generated tests expose sensitive information or introduce security risks?

AI-generated automation should undergo the same review, execution, maintenance, and quality checks as manually written automation.

The objective is not to reject AI-generated code. It is to use it responsibly.

5. AI-Assisted Quality Engineering: A Practical Approach

AI can contribute to several stages of the quality lifecycle.

Activity	How AI can help	What the team must verify
Requirements analysis	Identify ambiguities and suggest questions	Business accuracy and completeness
Test design	Generate scenarios and edge cases	Risk coverage and expected outcomes
Test automation	Draft Cypress, Playwright, or API tests	Correctness, maintainability, and reliability
Code review	Highlight potential defects and risky patterns	Findings against actual code and context
Security testing	Suggest vulnerability scenarios	Independent security validation
Failure analysis	Summarise logs and suggest possible causes	Root cause using evidence
Regression testing	Suggest tests based on changed functionality	Impact analysis and critical coverage

The best results come from combining AI's speed with human judgement, engineering discipline, and reliable verification.

For example, AI might generate a Cypress test for a payment workflow. A QA engineer should review the scenario, validate the expected business outcome, ensure the test handles asynchronous behaviour correctly, and confirm that it would fail if a real defect were introduced.

AI can accelerate the work, but the team remains accountable for the outcome.

6. Measure Quality, Not Just Testing Activity

A team can execute thousands of tests every sprint and still struggle with production incidents.

Test counts and automation percentages provide useful operational information, but they do not independently measure product quality.

A more useful quality strategy considers several dimensions:

• Escaped defects: Problems discovered by customers or in production.

• Defect recurrence: Whether previously identified root causes continue to produce failures.

• Change failure rate: How frequently changes lead to incidents, rollbacks, or production remediation.

• Recovery time: How quickly the team restores service after a failure.

• Risk coverage: Whether critical business workflows and failure scenarios are adequately tested.

• Automation reliability: Whether automated tests provide trustworthy results without excessive flaky failures.

• Customer impact: Whether users experience incorrect results, service interruptions, or usability problems.

These measures should be interpreted in context. For example, an increase in reported defects may indicate worsening quality, but it may also reflect improved detection.

The purpose of metrics is to identify improvement opportunities and support better decisions, not to assign blame or encourage teams to optimise numbers at the expense of quality.

In AI-assisted development, it is also worth monitoring whether faster code production leads to increased rework, more escaped defects, or additional security findings.

7. What Should QA Leaders Focus on Next?

QA leadership should move beyond test execution management and help establish a culture of quality engineering.

Some practical priorities include:

1. Establish quality ownership. Make responsibilities clear across product, development, QA, security, and operations.

2. Introduce risk-based testing. Prioritise scenarios according to business impact, likelihood of failure, and technical complexity.

3. Strengthen engineering practices. Promote code reviews, unit testing, contract testing, CI/CD quality gates, and production observability.

4. Use automation strategically. Automate repeatable, valuable checks while preserving exploratory testing and human investigation.

5. Adopt AI with guardrails. Review AI-generated code and tests, protect confidential data, and validate important outputs independently.

6. Learn from production. Use incidents, customer feedback, monitoring, and defect trends to improve both the product and the development process.

7. Continuously improve. Review recurring problems and refine the team's working practices rather than relying on more testing as the default solution.

For a small QA team, these principles are especially important. The objective is not to perform every check manually or automate everything. It is to use the team's time where it reduces the greatest risk.

Conclusion: Quality Is an Engineering Culture

Software quality assurance has never been limited to finding defects. Its broader purpose is to help teams build software that meets business needs and performs reliably in real-world conditions.

Agile development reinforces this principle by bringing quality activities into every stage of delivery. AI makes it even more relevant by increasing the speed at which code and tests can be produced.

The future of QA is not about choosing between manual testing, automation, and AI. It is about combining sound testing practices, effective engineering processes, risk-based thinking, and responsible AI adoption.

The most valuable QA professional is not necessarily the person who executes the most tests or writes the most automation scripts. It is the person who helps the team identify risks early, prevent recurring defects, make informed decisions, and deliver software that customers can trust.

In the Agile and AI era, testing is one of the ways we evaluate quality. Quality assurance is the discipline that helps us build it into the product from the start.