Svet Penkov argues that unit tests, integration tests, and data checks are only parts of the development process, rather than tests of whether an ML model behaves correctly.
2
Models should have a defined operational domain, with concrete requirements for conditions such as image position, brightness, and contrast before teams search for cases where the model fails.
3
ML testing should borrow continuous integration and property-based testing from software engineering, then adapt them for large datasets, probabilistic results, and model-specific requirements.
Summary
Svet Penkov describes ML testing as a quality assurance problem that starts before deployment. His robotics work showed him that real-world systems cannot simply be run repeatedly until they improve, because failures are costly and data collection is limited. He argues that teams should define the closed world in which a model is expected to work, then express requirements for that world in concrete terms. Edge cases often arise from combinations of known variations, such as an object's color, position, and background. Penkov recommends borrowing continuous integration and property-based testing from software engineering, while adapting them to large datasets and probabilistic model behavior. He wants tools that let teams write non-functional requirements quickly and run them whenever data, code, or model architecture changes. He is candid that Efemarai's platform is an early step and that the wider ML community still needs to develop the testing culture, APIs, and research needed for broader use.
Robotics makes data efficiency and failure definitions unavoidable
Svet Penkov's robotics background shaped how he thinks about ML testing. A classifier can be trained on a very large image collection, but a robot cannot safely be made to repeat a physical action a billion times. A robot that moves that many times may break repeatedly. This makes data efficiency important, along with a clear decision about what performance the team is willing to sacrifice. It also forces the team to define what counts as a system failure. Penkov connects this experience to testing because a model that interacts with the real world cannot be improved by waiting for every problem to appear after deployment.
Common ML tests do not test the model's behavior directly
When people hear testing, Penkov says they often name unit tests, integration tests, data cleaning, or data testing. He considers these individual steps around an ML system rather than tests of the model itself. Much current work places software testing tools around machine learning, which can help, but it avoids the harder question of what the model should do across the situations it will meet. Demetrios Brinkmann asks whether this testing belongs to ML engineers, data scientists, or DevOps. Penkov postpones that question until the team has first agreed on what should be tested and how the model should behave.
Teams should stop treating frequent failure after deployment as inevitable
Penkov challenges the common idea that it is acceptable to ship a model that will fail often because machine learning is difficult and the data is high-dimensional. He accepts that deploying, observing failures, and iterating can be useful while testing an early hypothesis. Once the problem is worth solving, he says the team should work out how to improve reliability before exposing users or real-world systems to those failures. A loop built around deployment and observation is slow, costly, risky, and difficult for the team to trust. Monitoring still has a place, but it should not replace work done before release.
An operational domain turns the open-world problem into a testable space
Penkov says ML teams often give up because they cannot know everything a model may encounter. Other engineering fields face the same open-world problem, so they define the smaller operational domain in which a system is expected to work correctly. For an image model, requirements might state that the result should remain reliable when an object moves within the image or when brightness and contrast fall within specified ranges. These requirements should come from the problem and product perspective as well as from ML specialists. Writing them down gives the team a concrete closed world and a way to check whether the model meets it.
Many edge cases are combinations of known variations
Once a team defines its operational domain, each requirement becomes an axis of variation. Penkov explains that an object detector may fail when a particular object color, position, and background occur together. The edge case is then a location in a space the team has already described, rather than an entirely unexpected event. This makes it possible to search for combinations that produce poor behavior. Unknown unknowns remain outside the team's ability to define in advance, but known unknowns can be discussed and tested in a principled way. The aim is to find concrete model failures inside the domain before deployment.
Property-based testing offers a middle ground for ML
Penkov describes three levels from software testing. Unit tests check individual functions and rely on the test writer to define meaningful inputs and expected behavior. Formal verification and validation can provide stronger guarantees, but they are expensive and usually applied to small, sensitive components such as transaction engines or aircraft controllers. Property-based testing sits between these approaches. The team writes a function expressing the property it cares about, then lets the computer search for inputs that make the test fail. Penkov sees this pattern as a useful starting point for finding model failures across a large input space.
ML testing needs continuous integration with probabilistic checks
Software engineering offers continuous integration, which lets teams update products frequently while repeatedly running tests. Penkov says an ML testing stage should follow that pattern. It must also account for large datasets and the fact that ML tests are often probabilistic or empirical. A single failed run may not prove that a model is wrong, so tests may need to evaluate expectations over multiple outcomes. The community also needs to work out an API for expressing requirements such as robustness to brightness, weather, or spelling changes. Different ML areas may use plugins, while a smaller set of general assertions sits underneath them.
The desired tool reruns requirements whenever the model changes
Penkov imagines a workflow where a team spends a short time at the start of a project defining non-functional requirements and saving them in a file. The tests would run whenever the team adds data, changes the model architecture, or modifies code. Their output would describe the closed world where the model works and let the team decide whether that domain is sufficient. If it is sufficient, the model can ship. If it is not, the team can investigate how to extend the domain. He wants this process to be simple enough that testing does not bury an exploratory project in technical debt.
Data quality should be judged by model behavior inside the intended domain
Penkov takes a deliberately narrow view of data quality. Basic checks still matter, such as finding empty fields, missing values, or data outside an expected distribution. Beyond that, he says the useful measure is whether the data helps the model work inside its intended closed world. A small dataset could be enough if it covers everything the model needs to cover, although he acknowledges that the real world contains complexity that cannot always be compressed. His broader point is that teams should seek simpler and more efficient processes instead of treating larger datasets and more storage as automatic improvements.
"Property based testing essentially says your unit test function is the property you care about. Now let the computer figure out if there are any inputs that are going to make your function unit test fail."Svet Penkov16:06
Who should watch
You deploy models and rely on monitoring to discover failures after users encounter them.
Your team has data checks and unit tests but has not written down the conditions under which the model must behave correctly.
You are building ML testing tools and need ideas for combining property-based testing with large datasets and probabilistic results.
