This article is the second in a series of AI related articles we’ll be publishing as we go through our journey of implementing AI in Testmo, sharing our learnings as we go. If you want to keep up with our journey, be sure to subscribe to our newsletter. Additionally, you can respond to our survey here: AI Test Case Generation in Testmo

So you’ve read about the ten essential practices for testing AI systems. You’ve nodded along to TRiSM frameworks, red teaming methodologies, and continuous monitoring approaches. Maybe you’ve even bookmarked some of those tools – SHAP, LIME, WhyLabs, the whole arsenal.

But now you’re staring at your feature testing queue, watching AI features creep into the product like Borg nanoprobes, and thinking: “Where do I actually start?”

In this article, you’ll learn a few best practices when building AI testing in your QA process and four steps you can take to start testing new AI features embedded in your application or product:

Getting Started with AI Testing

Let’s be honest about something: a lot advice about how to test AI falls into two camps. Either it’s so high-level it’s useless (“you should care about fairness!”) or so technical it assumes you have a PhD in machine learning (“implement cosine similarity metrics for your semantic evaluation pipeline“!)

Neither helps when you’re a working QA professional trying to figure out how to test the new AI chatbot feature that goes live next sprint.

The ten practices we outlined in our previous article represent our best assessment of current, genuine state-of-the-art AI testing approaches. They align with regulatory expectations, reflect what companies like OpenAI and Anthropic actually do, and go well beyond traditional software testing paradigms. But “state-of-the-art” doesn’t mean “ready for product delivery teams without significant adaptation.”

Here’s an uncomfortable truth: implementing TRiSM frameworks or comprehensive red teaming requires expertise, tooling, and organisational commitment that most delivery teams don’t have yet. That doesn’t make these practices wrong. It just means they’re likely aspirational for those of us working in the trenches on day-to-day product delivery.

The gap between “what we should do” and “what we can do with current resources” is where many teams get stuck. They read about advanced AI testing methodologies and either give up (too complex) or jump in without a proper foundation (chaos ensues).

Here’s a better approach: start where you are, with what you have, and build toward those advanced practices incrementally.

Challenges to Implementing AI Testing Practices

Before we talk about practical implementation, let’s acknowledge why AI testing melts the traditional QA brain. Understanding AI weirdness isn’t academic – it’s essential for knowing what battles to fight and which ones to postpone.

1. Determinism is dead.

Traditional testing assumes same input equals same output. AI systems mock that assumption. Temperature settings, context windows, model versioning, and data drift can all influence responses in ways that would never occur in traditional software. Run the same prompt through an LLM twice and you might get subtly different answers – not because of a bug, but because that’s how these systems are designed to work. Try writing a test assertion for probabilistic outputs that are correct when they vary and broken when they don’t.

2. Failure modes are invisible.

When a REST API fails, you get a 500 error. When an AI fails, it keeps smiling while confidently telling you that Paris is the capital of Italy. Unless you’ve built specific detection mechanisms, these failures won’t show up in your logs, monitoring dashboards, or error tracking systems.

3. The system evolves without code changes.

Your beautiful test suite might pass today, degrade silently next month, and collapse entirely in six months – not because anyone deployed broken code, but because the world changed around your model. User behaviour shifted, data distributions drifted, or edge cases you never tested started appearing in production.

4. Data is the product.

In traditional systems, you validate data as it flows through. The purpose of the system is either to display or manipulate that data in predictable way, which can be validated given a set of known inputs. In AI systems, the training data is the system. If your data skews Western, corporate, or male-coded, that bias becomes baked into every prediction. No amount of functional testing will catch that.

This isn’t just a learning curve. It’s a paradigm shift that mandates rethinking some core assumptions about what testing means.

Best Practices for AI Testing

The path from “we should implement comprehensive TRiSM” to “here’s what we’re actually going to test this sprint” requires translation. You need to take those advanced practices and find their practical entry points – the places where you can start building capability without needing a machine learning PhD or a six-figure tool budget.

1. Start with Risk, Not Tools

TRiSM (Trust, Risk, and Security Management) sounds intimidating until you realise it’s just systematic risk-based testing applied to AI. You don’t need specialised frameworks to begin. You need to ask better questions:

• What happens if this AI feature gives confidently wrong answers?
• Who gets hurt if the system exhibits bias we didn’t catch?
• What’s our liability if the model leaks training data?
• How will we know if the system starts behaving differently?

These aren’t philosophical questions. They’re AI product design constraints that should shape your testing strategy. Start by cataloging the specific risks your AI features introduce, then work backwards to testing approaches that can surface those risks early.

2. Treat Security as a Spectrum, Not a Binary

Red teaming sounds like something that requires elite hacker skills and specialised tools. In reality, it starts with curiosity and systematic exploration. Begin with basic adversarial thinking:

• Can users trick your AI into revealing information it shouldn’t?
• What happens when you feed it unexpected input formats?
• Does the system maintain appropriate boundaries when users try to manipulate its responses?
• How does it handle attempts to extract training data or internal prompts?

You don’t need specialised security analysis or testing tools. Start with session based exploration, document what you find, and build systematic test cases around the vulnerabilities that matter most to your specific context.

3. Make Privacy Testing Concrete

Data privacy in AI isn’t just about GDPR checkboxes and legal Ts & Cs. It’s about understanding how your specific system might ingest or leak information in non-obvious ways. Instead of trying to implement comprehensive privacy testing frameworks, start with targeted exploration:

• Can the system be tricked into inferring protected characteristics about users?
• Do anonymised inputs stay anonymous when processed by your model?
• What happens when you ask the AI about specific individuals or organisations?
• Are there patterns in outputs that could reveal information about training data?

Build these questions into your exploratory testing cycles. Privacy testing doesn’t require specialized tools – it requires systematic thinking about the potential for information leakage.

4. Explainability Starts with Asking “Why”

You don’t need SHAP or LIME implementations to begin working on explainability. Start by validating that your AI systems can provide reasoning for their decisions when asked. Test the quality and consistency of those explanations:

• Does the system provide reasoning when users ask for it?
• Are explanations consistent across similar inputs?
• Can support teams use these explanations to help confused customers?
• Do the explanations actually help users understand what happened?

This human-centered approach to explainability testing is often more valuable than sophisticated interpretability metrics, especially in customer-facing applications.

How to Start Testing AI

Here’s a four-step model for how you can begin applying AI testing practices from the ground up.

1. Map Your AI Attack Surface

Before you can test AI features effectively, you need to understand what you’re dealing with. This isn’t about model architecture – it’s about system behaviour and integration points.

• Inventory your AI touchpoints. Where does AI appear in your product? Customer-facing chatbots, recommendation engines, automated content generation, fraud detection, search functionality – catalog everything that uses machine learning, language models & agents.
• Identify the human interfaces. How do users interact with AI-powered features? What expectations are being set? How are AI-generated results presented? These interaction patterns determine your testing priorities.
• Map the data flows. Where does data enter your AI systems? How is it processed, transformed, or enriched before reaching the model? Understanding these pipelines helps you identify potential failure points and bias injection opportunities.
• Document the fallback mechanisms. What happens when AI systems fail or become unavailable? Are there graceful degradation paths? Can humans override AI decisions when necessary?

This mapping exercise may take a few days, but it provides the foundation for the rest of your testing strategy.

Don’t lose sleep over trying to get a complete understanding though. Remember: “All models are wrong, some are useful.” You just need something useful enough to start driving the right questions from.

2. Build Baseline Test Cases around AI

Start with simple, systematic test cases that establish baseline behaviour for your AI features. Think of this as your “smoke test” equivalent for AI systems.

• Prompt regression testing. If your system uses language models, treat prompts like code. Save current versions, create test cases that validate expected output characteristics (tone, format, key information), and run these tests when prompts change.
• Input boundary testing. Test your AI features with edge cases: empty inputs, extremely long inputs, special characters, different languages, unexpected formats. Document how the system responds to these boundary conditions.
• Consistency validation. Run the same inputs multiple times and measure consistency. While AI systems aren’t deterministic, they should be predictably inconsistent. Establish baselines for acceptable variance.
• Confidence calibration. If your system provides confidence scores, validate that they correlate with actual accuracy. High-confidence wrong answers are worse than low-confidence wrong answers.

These basic test cases won’t catch sophisticated failures (they’re the AI equivalent of smoke tests), but they establish a foundation and help you understand normal system behaviour before you start looking for abnormal patterns.

3. Implement Basic Drift Detection

Once again, you don’t need specialist tools to start monitoring for model drift. Begin with simple metrics you can track over time:

• Response characteristics. Track average response length, response time, confidence scores, and any other quantifiable metrics your system provides. Significant changes in these patterns may indicate drift.
• User interaction patterns. Monitor how real users respond to AI-generated content. Are they accepting suggestions less frequently? Reporting issues more often? These behavioural signals often precede measurable model degradation.
• Error escalation rates. Track how often AI decisions get overridden, corrected, or escalated to human review. Increases in these rates may indicate declining model performance.
• Content categorisation. If your AI generates text, periodically sample outputs and categorise them by tone, topic, or other relevant dimensions. Shifts in these distributions can signal drift.

Start with manual sampling and tracking. Once you understand what signals matter for your specific system, you can invest in automated monitoring tools.

4. Build Cross-Functional Testing Relationships

AI testing can’t happen in isolation. As a testing leader you should make efforts to establish relationships and processes that will make more advanced testing practices possible:

• Partner with data teams. Understand how your models were trained, what data sources were used, and what known limitations exist. This context is essential for designing effective test cases.
• Connect with security teams. Share your findings about AI-specific vulnerabilities and learn about broader security testing approaches. Red teaming becomes more effective when QA and security collaborate.
• Engage with product teams. Help define what “success” means for AI features beyond basic accuracy. Establish shared understanding of acceptable risk levels and failure modes.
• Build feedback loops with support teams. They’re often the first to hear about AI failures that testing missed. Create systematic ways to capture and analyse these insights.

These relationships are what transform basic AI testing into the comprehensive TRiSM approaches that represent true state-of-the-art practice.

Scaling Up: The Path to Advanced Practices

Once you’ve established these foundational practices, you can begin implementing more sophisticated approaches systematically:

• From basic prompt testing to comprehensive red teaming. Start with manual adversarial exploration, document successful attack vectors, then gradually implement automated fuzzing and dedicated red team exercises.
• From simple drift detection to continuous monitoring. Begin with manual sampling and basic metrics, then invest in automated monitoring as you understand which signals matter most.
• From basic explainability validation to comprehensive interpretability testing. Start with human-readable explanations, then gradually incorporate interpretability tools if your needs become more sophisticated.
• From ad-hoc governance to systematic compliance frameworks. Begin with basic documentation and review processes, then implement formal AI governance tools as regulatory requirements and organisational needs become clearer.

The key is building capability incrementally rather than trying to implement comprehensive frameworks all at once.

Why This Approach Works: The Tester’s Advantage

Ready for some good news? Experienced testers already have the core skills needed for AI quality assurance. You don’t need to become a machine learning expert. You need to apply your existing testing mindset to a new class of problems.

• You understand risk thinking. You’ve spent years identifying what could go wrong and designing tests to surface those failures early. AI systems just have different failure modes.
• You know how to work with ambiguous requirements. Product managers have always been vague about edge cases and error handling. AI features are just vague in new and creative ways.
• You’re comfortable with exploratory testing. Much of AI testing involves systematic exploration of system behaviour under various conditions. That’s core tester territory.
• You advocate for users. You’ve seen how technical failures become user experience disasters. That perspective is crucial when AI systems fail convincingly rather than obviously.
• You understand system complexity. You know that bugs often live at integration points, in edge cases, and in the spaces between components. AI systems just have more complex integration surfaces.

The state-of-the-art practices we outlined in our previous article aren’t foreign concepts requiring complete retraining. They’re an evolution of testing approaches you already know, adapted for AI systems that learn and change over time.

Winning at AI Testing

Let’s be realistic about what you can achieve in the short term. You’re probably not going to implement comprehensive TRiSM frameworks in a month, or during the course of a single release. You’re not going to become a red teaming expert overnight. You’re not going to solve AI bias with exploratory testing.

What you can do immediately is to start building the testing capability that will matter as AI becomes more central to your product. You can establish the foundational practices that make advanced AI testing techniques possible. You can become the person on your team who understands AI testing well enough to ask the right questions and design meaningful test strategies.

Most importantly, you can start protecting your users from the kinds of AI failures that aren’t obvious until they’re already causing problems. That’s not state-of-the-art; it’s just good testing. But in the brave new AI world, good testing might be the most advanced practice of all.

Winning at AI testing isn’t about implementing every advanced technique. It’s about systematically reducing the risk that your AI features will surprise users, violate their trust, or cause unintended harm. Start there. Everything else builds on that foundation.

The future of quality assurance is being written right now, in products shipping AI features without adequate testing, in teams learning these practices through trial and error, in testers who are figuring out how to adapt their skills to this new reality.

You don’t need permission to start. You just need to begin.