Testing Machine Learning Systems: A Guide for Malaysian Teams
Testing machine learning means checking four things, not one: the code, the data, the model and the system around them once it runs in production. A model that scores well on a spreadsheet can still fail on live documents, drift within months or mishandle personal data. This guide sets out what to test, in what order, and what Malaysian organisations should add.
TL;DR
ML testing covers code, data, model and the deployed system. Conventional software tests only cover the first.
Hold back an independent test set at the start of a project and use it once, at the end, to judge the final model.
Test data for missing values, duplicates, outliers, skew and bias before any training run.
Malaysian teams handling personal data should apply PDPA accuracy duties and the proposed JPDP Framework expectations to testing itself.
Testing does not stop at go-live. Monitoring and retraining checks are part of the same discipline.
Table of Contents
Why machine learning needs more than ordinary software testing
In conventional software, engineers write the logic and testers check it against expected results. In machine learning, training data determine part of the program logic, so code coverage tells you little, and stochastic learning makes it hard to define a deterministic expected result.
Researchers Marijan and Gotlieb explain that ML systems are generated inductively, with logic inferred from training data. A fault can therefore come from faulty code or from errors in the data. They also point to non-determinism: outputs for the same test inputs can change over time, which complicates test case specification.
The international standard on the subject, ISO/IEC TR 29119-11:2020, gives guidelines for testing AI-based systems across the life cycle. It addresses the test oracle problem, where testers struggle to say what the right result is, and covers black-box approaches as well as white-box testing for neural networks.
The practical consequence is a wider scope. You test the pipeline that feeds the model, the model itself, and the behaviour of the whole system under conditions it has not seen.
The four layers of an ML test plan
Think of the plan as four layers, each with its own failure modes. Skipping one tends to show up later as an expensive production incident.
Code tests
Microsoft’s engineering playbook describes ML unit tests as code quality checks, not accuracy checks: does the model accept correct inputs, return outputs of the right shape, and update its weights when fitted? These are quick, repeatable and belong in every build.
Google’s guidance adds a useful caveat. Test-driven development is tricky in ML, because before training you cannot write a test that validates the loss. Write tests for the surrounding code first, and add model-level checks once a baseline exists.
Data tests
Most ML failures begin here. The European test methodology ETSI TR 103 910 says training data should be tested for correctness, consistency, missing data, duplicates, outliers, distribution and skewness, correlated features and unwanted bias.
In practice, that means automated validation at the point of ingestion. Open-source tools such as Great Expectations let teams define what data should look like in a standard way and connect to file systems, S3 and databases. Test cases should include empty inputs, wrongly formatted files, null values and outliers.
This matters most for document-heavy work. Scanned invoices, bank statements and insurance forms arrive in inconsistent formats, and the pipeline needs tests for exactly those inconsistencies. Teams that want to see how these controls fit together can read our guide to the data pipeline for ML.
The same logic applies in any field where data quality decides results. A trading-strategy article on out-of-sample testing shows why validation data must stay separate from the data used to build the strategy, a principle that carries straight over to model training.
Model tests
The same ETSI methodology says the model itself must undergo performance, robustness and bias testing. Performance means accuracy metrics against a defined baseline. Robustness means stable behaviour when inputs are noisy, incomplete or slightly altered. Bias testing checks whether results differ unfairly across groups.
The Deepchecks guide frames this as reliability, robustness and fairness, and notes that data from most sources can reflect human bias that a model then learns.
For a detailed treatment of validation methods, see our ML model validation guide.
System and integration tests
A model is rarely used alone. Google lists the tests a full ML system needs: input data validation, feature engineering validation, new model version quality, serving infrastructure and integration between pipeline components. The Azure MLOps series reaches a similar view, naming unit, data and model, and integration testing as the three essential tests for production robustness.
Component-level testing comes first. A US-based test and evaluation best-practice paper sets the primary component-level objective as testing individual ML components before system-level integration.
How to confirm a model generalises
A model that does well on its training data proves very little. The academic guide How to avoid machine learning pitfalls states that performance on the training set is almost meaningless, and that the common error is letting information about test data leak into configuration, training or model selection.
Its recommended practice is simple:
Partition off a subset of data at the very start of the project.
Do all development, tuning and model selection on the remainder.
Use the independent test set once, at the end, to measure the generality of a single chosen model.
The same guide notes that many ML models are stochastic or unstable, so a single evaluation can mislead. Run multiple evaluations and report the spread, not one lucky number.
For time-based data such as transactions or sensor readings, split by time rather than at random, so the test set mirrors the future the model will face. That is our practical reading of the principle, not a rule from the guide.
Checks for bias, safety and security
Reliability is not only about accuracy. Pre-deployment testing should ask whether the system behaves consistently with its intended purpose and whether it presents material errors or unexpected behaviour.
Security belongs in the test plan too. Malaysia’s National Cyber Security Agency lists data poisoning, prompt injection, adversarial attacks, model theft and AI supply chain compromise as evolving risks, and its AI Systems Cyber Security Framework takes a risk-based approach across the lifecycle. For conversational agents built on large language models, prompt injection tests deserve a place in every release checklist.
Data quality checks can also be borrowed from other regulated fields. The METRIC framework, written for medical AI, covers completeness, noisy labels, source credibility, traceability and data poisoning, all of which apply equally to finance and insurance data.
Testing under Malaysian data rules
Many enterprise ML projects in Malaysia use customer or employee records. That raises two points for testers.
First, the Personal Data Protection Act 2010 requires reasonable steps to keep personal data accurate, complete, not misleading and up to date. A 2026 compliance guide reads Section 11 as supporting data quality checks before training, including provenance verification, handling of missing records and documented data limitations.
Second, the Personal Data Protection Commissioner’s public consultation paper on AI and personal data proposes a framework with direct implications for testing. It is a consultation draft, so check the Commissioner’s site for the final position. As proposed:
Personal data used for development, training, testing or validation should be adequate, relevant and limited to what is necessary.
Controllers should consider anonymised or pseudonymised data where direct identification is unnecessary.
Deployment should follow completed testing and validation, with appropriate action on material issues found.
Pre-deployment testing should assess consistency with intended purpose, reliability of outputs and foreseeable operating conditions.
In practice, build test datasets from pseudonymised extracts, record who accessed them and keep the test evidence. That evidence doubles as an audit trail for compliance and internal risk teams. Where a project involves sensitive personal data, take advice from your data protection officer or legal counsel.
Testing continues after go-live
A passed test suite describes the model on the day it shipped. Live data changes, and so does model behaviour. Microsoft’s production checklist asks teams to confirm that ground truth can be obtained in production, alongside a defined baseline, benchmarks and analysis of training, test and validation distributions.
That turns testing into monitoring. Our guides cover data drift detection, a model monitoring strategy and a model retraining strategy that prevents silent failures. For teams moving from pilot to production, the exit criteria for an AI proof of concept are effectively the test gate.
A practical order of work
For an enterprise team starting from scratch, this sequence keeps effort proportional to risk:
Define success. Agree the baseline, the metrics and the business threshold before building anything.
Validate the data. Automate checks for nulls, duplicates, outliers, skew and bias at ingestion.
Lock the test set. Separate it at the start and protect it from tuning.
Unit-test the code. Shapes, inputs, weight updates and pipeline steps in every build.
Evaluate the model. Multiple runs, robustness and bias checks, compared with the baseline.
Test the system. Integration, serving, security and failure handling.
Monitor and retrain. Track drift and performance against ground truth after launch.
Tracking each run matters as much as running it. See our guide to experiment tracking for ML and the wider AI project lifecycle for Malaysian project managers.
Our perspective
Most testing failures we see are not failures of technique. They are failures of ownership. One team builds the model, another deploys it, a third watches it, and nobody holds the test evidence from start to finish. We engineer for production from day one, which means the test plan is written during strategy, not after the build. Data diligence comes first, because a model cannot be better than the records it learns from. Governance and auditability are designed in, so every test result can be traced. That is why we keep one senior team accountable for strategy, build and operation. The people who define the acceptance criteria are the people who monitor the system a year later, and the cost of drift or silent failure does not compound unseen. Thomas Samuel
How Sentient Concepts supports ML testing
Testing is easiest when it is designed into the project. We cover the full path: readiness and data diligence to check data before any model is trained, then deployment and MLOps to carry tests, monitoring and evaluation into production, with managed operations and ongoing optimisation afterwards.
If you are planning an AI system in finance, manufacturing, logistics or insurance and want testing built in from the start, talk to our team about your use case.
FAQ
What is the difference between testing machine learning and testing software?
Software tests check coded logic against known expected results. In ML, the logic is learned from data and outputs can vary, so you must also test the data, the model’s behaviour on unseen cases and its stability over time.
How much data should I hold back for testing?
The sources reviewed give no fixed percentage. The principle is to separate an independent test set at the start and use it once, at the end, on your final model. The right size depends on how much data you have and how rare the cases you care about are.
Do unit tests tell me if my model is accurate?
No. ML unit tests check code quality, such as input and output shapes and whether weights update during fitting. Accuracy needs separate evaluation against a baseline on held-out data.
Can I use real customer data to test a model in Malaysia?
The PDPA expects personal data to be accurate and handled for its purpose, and the proposed JPDP Framework says test data should be limited to what is necessary, with anonymised or pseudonymised data considered where possible. Confirm your approach with your data protection officer.
Sources
Recommended