A product may look like a single system from the outside. In reality, engineering teams often have to validate many possible combinations behind it: different hardware revisions, software versions, communication profiles, regional configurations, optional features…
Taken individually, these variants may seem manageable. But when they interact, the number of possible validation scenarios can grow very quickly. That is where traditional test approaches start to struggle.
The problem is not the number of variants. It is their combinations.
Imagine a connected product available with 3 hardware versions, 4 software releases, 3 communication profiles, 4 optional feature combinations, 2 regional configurations. That already creates 288 possible configurations before considering states, user actions or error conditions.
Of course, not every combination will be valid or relevant. Some variants share the same behaviour. Others differ only in specific areas.
The challenge is therefore to determine:
- which configurations actually need to be validated,
- which behaviours are shared,
- which differences matter,
- and where a change creates new validation requirements.
Why test suites become difficult to scale
A common response is to keep extending the existing test suite.
A new configuration appears? Add more tests. A software update changes behaviour? Duplicate and adapt existing scripts. A new hardware variant introduces an exception? Create another branch of the test campaign.
This works for a while. But over successive releases, three problems emerge.
1. Redundancy increases
Similar scenarios are often implemented several times for different configurations. This increases both execution volume and maintenance effort.
2. Coverage becomes harder to assess
A large number of tests can create a strong impression of coverage. But the real question is not how many tests exist. It is whether the relevant combinations of configurations and behaviours have actually been exercised.
3. Changes have wider impact
A modification to one behaviour, transition or feature dependency may affect several product variants at once. Identifying every impacted test can quickly become a major task. The result is simple: product complexity starts growing faster than the validation architecture.
Combinatorial explosion does not mean testing everything
The answer is not necessarily exhaustive testing. In complex systems, that is often impractical. The objective is to identify the combinations that are meaningful from a behavioural and requirements perspective.
Some options may be mutually exclusive. Some features may only exist on specific hardware versions. Several configurations may share the same behaviour.
These relationships allow teams to reduce the validation space without reducing coverage arbitrarily.
This is where Model-Based Testing can help.
From test cases to a model of behaviour and variability
With Model-Based Testing, the starting point is not an ever-growing collection of individual scripts. Instead, teams describe the expected behaviour of the system in a model.
That model can include:
- states,
- transitions,
- conditions,
- expected responses,
- configuration-dependent behaviour,
- and constraints between variants.
Test scenarios can then be generated according to defined coverage objectives.
The key advantage is that variability becomes part of the validation logic, rather than something managed indirectly through duplicated test scripts.
One model, several product variants
Imagine that one feature behaves identically across five configurations, except for one extra transition available on two of them. In a scripted approach, teams may end up maintaining several very similar tests.
In a model-driven approach, the common behaviour can be represented once, while the configuration-specific difference is explicitly described. If the shared behaviour changes, the model is updated. If a new variant introduces another path, that difference is added. Relevant scenarios can then be regenerated accordingly.
The objective is not simply to automate more tests. It is to generate the right tests for the right configurations from a consistent representation of expected behaviour.
Better control over coverage
For products with many variants, teams need to answer questions such as:
- Has every supported configuration exercised this transition?
- Which requirements apply to all variants?
- Which behaviours are configuration-specific?
- What needs to be retested after a change?
A model makes these relationships easier to represent and reason about.
Instead of relying only on test counts, teams can define coverage objectives around behaviours, states, transitions and configuration conditions.
Product variability should not automatically mean validation complexity
Multiple configurations are often unavoidable. Hardware evolves. Software changes. Products target different markets and feature sets.
The validation strategy therefore needs to accommodate variability instead of continually reacting to it. Model-Based Testing does not remove product complexity. But it can provide a more structured way to represent it, apply constraints, generate relevant scenarios and maintain consistency as the product evolves.
The key question becomes: “How do we model what is common, identify what is different and validate the combinations that actually matter?”
That shift in perspective can help keep validation scalable as product variability increases.
Is product variability making your validation process harder to scale?
Mellonne can help you explore how a model-based approach can bring more structure, consistency and control to complex validation environments.
Stay informed
Receive occasional product updates, certification insights and security news from Mellonne.