10.1 Testing for Data Representativeness

What representativeness testing asks

An ML model can post a flattering accuracy on a held-out split and still collapse in the first week of live traffic. The usual reason is not a clever algorithm bug. It is that the files used to train, validate, and test the model do not look like the data the system will actually consume. Data representativeness testing measures how closely those lab datasets match real-world operational data. The ISTQB Certified Tester AI Testing (CT-AI) v2.0 syllabus treats this as its own testing activity, not as a side effect of shuffling rows.

Representativeness failures show up in several recognizable shapes. A skewed dataset over-weights some feature values: a vision model trained mostly on daylight loading-dock photos will not represent night-shift scans. Missing data can hide an entire operating mode. If humidity is blank whenever the warehouse fogger runs, summer condensation never enters training. Disproportionate feature distributions mean the histogram of a numeric column in the lab does not match the field histogram even when the column names agree. Inadequate coverage of operational scenarios is the cousin of missingness: cells are filled, but critical situations (holiday surges, a new SKU, emergency braking, a regional dialect) never appear. Imbalanced class representation is the label-side version of the same problem. Fraud that is 0.4% of production might be 15% of a convenience sample, or a safety-critical failure class might be almost absent from the training file.

A random 80/10/10 split does not fix any of this. If the source extract is "last Tuesday in one depot," every split is still last Tuesday in one depot. Testers therefore build an independent picture of the target population and compare lab files against that picture.

Step 1: Define the target population

Start outside the spreadsheet. Document intended use cases and operational context: who invokes the model, through which channel, at what cadence, with which sensors or forms, and under which safety or service constraints. Then describe end users and environments. A speech model used on call-center headsets is a different population from the same architecture on a windy loading dock. A triage model in a tertiary hospital is not the same population as a rural clinic with a different case mix.

Expected operational distributions and critical edge cases are not inferred from the training file alone. Three sources named for this work are:

• Domain experts, who know seasonality, regional patterns, and which rare events actually matter.
• Existing or similar systems, such as logs from a rules engine you are replacing, a prior model version, or a sibling product in another region.
• Trusted benchmarks, including National Institute of Standards and Technology (NIST) datasets and industry databases, used only when they genuinely describe your population rather than a convenient academic substitute.

From that reference picture, apply stratified sampling so the baseline covers relevant subgroups. Stratification means you do not sample uniformly from a pile that is 90% Hospital A if Hospital B will generate half of live traffic. Important strata (site, device firmware, vehicle type, language, age band) appear at rates that reflect operational importance, not only historical convenience. Rare but high-impact edges (pediatric doses, left-hand-drive markets, black-ice nights) get an explicit stratum rather than a hope that they appear in a uniform draw.

Suppose three depots will all use a delay classifier. Historical exports are 70% Depot North, 25% Depot Central, and 5% Depot South because South came online last month. Operations will route traffic 40/40/20 within a quarter. A representative baseline is sampled to the future mix (and to time-of-day and vehicle-type strata), not to last month's dump. The output of Step 1 is a reference operational dataset or a documented sampling frame if raw records cannot leave the plant. Every later comparison is a comparison against that baseline, not against "the file we already like."

Step 2: Analyze data characteristics

Run exploratory data analysis (EDA) on both sides: the training, validation, and test datasets under evaluation, and the reference operational dataset. Side-by-side EDA is the method, not a gallery of charts for a slide deck.

Use histograms, density plots, and bar charts to compare shapes. Use scatter plots and other pairwise views to see whether feature relationships, especially correlations, are preserved. If lab data shows a strong negative correlation between on-hand inventory and supplier lead time, but operations show almost none after a new contract, the model will learn a relationship that is not present in the field.

Hunt for anomalies, gaps, and unusual concentrations. A gap is a hole in coverage: no examples with humidity above 80% even though the warehouse hits 95% in July. A concentration is a spike: nearly every image taken under the same fluorescent bank. An anomaly might be a cloned batch from an augmentation script that duplicated one customer segment. EDA often catches these failures before a formal hypothesis test. It also tells you which features and strata deserve statistical comparison next.

Step 3: Apply statistical assessment

Formal tests compare distributions rather than leaving the decision to a glance.

Chi-squared tests suit categorical variables: product category, operating system, diagnosis code, class label, depot ID. You compare observed counts in the lab set with expected counts from the reference mix. A large statistic suggests the category mix does not match. Interpret p-values with sample-size caution: huge files make tiny, operationally irrelevant differences look "significant," while small strata can hide a real miss.

Kolmogorov-Smirnov (KS) tests suit continuous variables: amount, latency, age, pixel intensity, parcel weight. KS compares empirical cumulative distribution functions. A large KS distance means the shapes differ, not merely that two means differ. A training file whose claim amounts stop at $8,000 while live claims reach $40,000 can share a similar mean in the body of the data and still fail KS in the tail.

For classification problems, add class imbalance checks. Imbalance is not automatically a defect; fraud is rare. The defect is a mismatch with operations, or too little minority-class coverage to support a decision you still claim to offer. Verify coverage of typical scenarios and edge and boundary cases. A mean that matches while the 99th percentile is missing is still a representativeness failure for a risk model that must handle tail events.

Report per feature and per stratum, not as a single boolean. A national file can match overall and still fail in the region that will generate 40% of traffic.

Before training, and again after release

Perform representativeness testing before model training. Fitting a model on an unrepresentative file wastes compute and bakes in a distorted decision surface. Later accuracy on a similarly distorted test split will not reveal the problem; both files can agree with each other and still disagree with the world.

After deployment, continuously monitor operational inputs for data drift: live traffic moving away from the mix you trained on. Drift testing is specified separately in the model-testing chapter (see 6.1.7). Representativeness work is what creates the baseline those monitors compare against. If the live histogram of claim_amount walks away from the training histogram, you raise a data-quality or retraining signal. You do not wait for a customer complaint to become the first test case.

A practical tester rhythm is: freeze a reference snapshot, compare candidate training/validation/test extracts to it, block training if material mismatches remain, then keep the same snapshot (or a controlled refresh) as the drift baseline. When the business itself changes (new market, new camera, new claim type), update the definition of the target population and repeat Step 1 rather than silently treating yesterday's file as truth.