Lesson 1 of 87 min read
What makes AI and ML apps different to test
Normal software follows rules a developer wrote: same input, same output. An ML model learns patterns from data, so its answers are probabilities, it can be confidently wrong, and the same question to a chatbot may give different wording each time. This lesson explains what changes for a tester and what stays the same.
Key takeaways
- 1Traditional code: rules written by people. ML: rules learned from example data, so the data is part of the product and must be tested too.
- 2Outputs are often probabilistic: a spam filter says '93% spam', a recommendation list changes, an LLM rewords its answer.
- 3There is rarely one exact expected result, so tests check properties: correct category, within a range, contains key facts, no forbidden content.
- 4Models can degrade over time when real-world data changes (drift), even if nobody changes the code.
- 5Everything around the model still needs normal testing: UI, APIs, permissions, performance, error handling and logging.
Same feature, two kinds of tests
Feature: 'Detect fraudulent payments' Normal checks (exact): - API returns 200 and a score between 0 and 1 - Score above 0.8 blocks the payment and shows 'Under review' - Blocked payments appear in the admin queue ML checks (statistical / property-based): - On a labelled test set of 5,000 payments, recall for fraud >= 90% - False positives on normal payments <= 2% - Similar payments from different cities get similar scores - A tiny change (amount 1000 -> 1001) does not flip the decision
Go deeper
Expert notes beyond the basics
- 01
The oracle problem
In testing, the 'oracle' tells you the right answer. For ML there often isn't one exact answer, so testers use other oracles: labelled datasets, rules that must always hold (a price prediction can't be negative), comparisons with the previous version, and human review for a sample.
- 02
Metamorphic testing
When you can't know the exact output, check relationships between outputs. If you translate a review to uppercase, the sentiment should stay the same. If you add a rival product to a search, the original results shouldn't disappear. These 'metamorphic relations' make powerful automated tests.
- 03
The system around the model
In most AI products the model is a small part of the code. Data pipelines, feature code, APIs, caching, fallbacks when the model is down, and the UI all have ordinary bugs. Don't let 'it's AI' stop you from doing normal functional and API testing.
Common mistakes to avoid
- - Expecting exactly the same output every time.
- - Testing only the model and forgetting the app around it.
- - Trusting a single overall accuracy number.
- - Assuming a model that worked last month still works.
Try it yourself
Pick an AI feature you use (photo search, autocomplete, chatbot). List three normal tests and three ML-specific tests.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
How is testing an ML feature different from testing normal software?
Model answer
Normal software has deterministic rules, so I compare actual and expected results exactly. An ML model learns from data and returns probabilities, so I test on labelled datasets and measure metrics such as precision and recall against agreed thresholds, check properties like consistency and robustness, test the training and input data quality, check for bias across user groups, and monitor for drift after release. The surrounding application still gets normal functional, API, security and performance testing.
- Q2
What is metamorphic testing?
Model answer
Testing relationships between inputs and outputs when exact answers are unknown, such as checking that adding a typo does not change a classifier's label.
- Q3
What is the oracle problem in ML testing?
Model answer
The difficulty of knowing the correct expected output. It's handled with labelled data, invariant rules, comparisons with previous versions and human review.
Knowledge check
+5 points
Why can't most ML outputs be tested with one exact expected value?
