NashTech Blog

The Evolution of Testing in AI Projects: Beyond Finding Bugs

Table of Contents

When AI became part of modern product development, many discussions focused on how developers, business analysts, and product teams would adapt. Less attention was given to another important question:

How does AI change the role of a Tester?

From practical experience in AI projects following an AI Development Life Cycle (AI-DLC), one thing becomes clear: AI does not eliminate the need for testing. Instead, it changes how quality is defined, evaluated, and managed throughout the product lifecycle.

Testers Are Involved Much Earlier Than Many People Think

A common misconception is that Testers become involved only when an AI model is ready for evaluation.

In reality, successful AI projects often require Tester involvement from the earliest stages:

  • Reviewing requirements
  • Clarifying business objectives
  • Discussing solutions with Product Owners
  • Collaborating with Developers and AI Engineers
  • Identifying risks
  • Defining quality criteria

Unlike traditional projects where some ambiguities can be resolved during implementation, AI projects require a much higher level of clarity upfront.

Questions such as the following should be answered early:

  • What should AI be allowed to answer?
  • What should AI refuse to answer?
  • What is considered an acceptable response?
  • How will success be measured?
  • What level of accuracy is acceptable?

This alignment is critical because AI enables teams to build solutions very quickly.

However, if the team misunderstands the actual business problem, AI may simply help everyone move in the wrong direction faster.

A misunderstanding discovered late in the project may require updates to prompts, workflows, datasets, evaluation criteria, or even the entire solution design.

Software Testing Versus AI Testing

In traditional software projects, quality is often easier to verify.

Consider a Login feature.

Requirements

  • Users enter valid credentials.
  • The system redirects them to the Dashboard.
  • User information is displayed correctly.
  • The UI matches the approved design.

A Tester can verify:

  • Functional behavior
  • Error handling
  • Security validations
  • UI consistency

The evaluation is relatively straightforward:

Expected Result
=
Actual Result

If they do not match, a defect exists.

AI systems behave differently.

Imagine a customer asks:

I want to reschedule my delivery.

The AI may respond:

Please provide your order number so I can help you reschedule the delivery.

Or:

Could you share your order ID so I can assist with changing the delivery schedule?

Both responses may be acceptable.

As a result, Testers are no longer focused solely on determining whether an answer is correct or incorrect.

Instead, they must evaluate:

  • Is the response relevant?
  • Is it helpful?
  • Is it complete?
  • Is it consistent?
  • Is it trustworthy?
  • Does it align with business expectations?

This shift from verification to evaluation is one of the most significant differences between Software Testing and AI Testing.

Understanding the AI Workflow Is Essential

In traditional systems, understanding business logic is usually sufficient.

In AI systems, it is equally important to understand how information flows through the solution.

A typical workflow may look like this:

When an AI response is incorrect, the model itself may not be the root cause.

The issue could originate from:

  • Ambiguous requirements
  • Inadequate prompt design
  • Incomplete knowledge sources
  • Retrieval failures
  • Missing business rules
  • Poor post-processing
  • Incorrect model selection

This is why Testers often benefit from working closely with Developers and AI Engineers throughout development rather than waiting until the testing phase.

The deeper the understanding of the solution, the faster issues can be analyzed and resolved.

Hallucination Is Not the Only AI Defect

When AI testing is discussed, hallucination usually receives the most attention.

While it is an important risk, real-world AI products often encounter many other quality issues.

Hallucination

The AI generates information that does not exist.

For example, it invents a company policy, process, or business rule that is not supported by any available source.

Noise Output

The AI adds unnecessary content such as:

✅✨📌

or excessively friendly introductions when the product expects concise and professional communication.

The information may be correct, but the user experience does not meet expectations.

Unwanted Content

AI occasionally generates additional content such as:

[Generated by AI]

[Suggested Response]

[Note]

even though those labels were never defined in the product requirements.

Inconsistent Responses

The same question receives different answers at different times.

Each answer may sound reasonable individually, but inconsistency gradually reduces user trust.

For many AI products, consistency is just as important as correctness.

Quality Is Not Only About the Final Output

One key observation from AI projects is that quality depends on far more than the generated response.

Traditional software relies heavily on source code quality.

AI products rely heavily on:

  • Data quality
  • Prompt design
  • Retrieval strategy
  • Model selection
  • Solution architecture
  • Business constraints

Therefore, requirement discussions often include questions such as:

  • Do we really need AI for this problem?
  • Is a large model necessary?
  • What defines acceptable performance?
  • How should uncertainty be handled?
  • What happens when the AI cannot provide a reliable answer?

Teams may also encounter operational risks such as token limitations, conversation limits, model costs, or architectural decisions involving single-agent and multi-agent solutions.

These topics are not always the primary focus of testing, but they are important risks that should be identified and discussed early in the project lifecycle.

The Role of the Tester Is Evolving

Modern AI tools can generate:

  • Requirements
  • Documentation
  • Source code
  • Test cases
  • Automation scripts

This significantly increases development speed.

However, AI is not accountable for the quality of its output.

That responsibility still belongs to people.

As a result, the role of the Tester is gradually evolving from:

Bug Finder

to:

Quality Evaluator

Risk Analyst

Trust Guardian

The challenge is no longer just finding defects.

The challenge is determining whether AI-generated outcomes are reliable enough for real users and whether the overall solution is aligned with business expectations.

Conclusion

AI projects demonstrate that the fundamental strengths of a Tester remain highly valuable:

  • Requirement analysis
  • Business understanding
  • Risk assessment
  • Stakeholder communication

What changes is the definition of quality.

In traditional software development, quality is often measured by whether a system behaves according to its specifications.

In AI-powered systems, quality extends beyond correctness. It also includes relevance, consistency, reliability, trustworthiness, and the ability to behave appropriately when there may not be a single correct answer.

The role of the Tester is therefore evolving.

Rather than focusing solely on identifying defects, Testers are increasingly expected to evaluate AI-generated outcomes, challenge assumptions, assess risks, and help ensure that AI-driven solutions remain useful and trustworthy for end users.

AI may accelerate development, but trust remains a human responsibility.

Picture of Dung Dang Phuong

Dung Dang Phuong

Suggested Article

Scroll to Top