How Expeto Tests⚓︎
This page describes the levels at which the Expeto Platform is tested, how often each level runs, what gates a release, what evidence is kept, and how the acceptance test catalog is maintained. It is the reference an MNO's test or assurance team uses to understand what Expeto has already verified before a release arrives.
Test levels⚓︎
| Level | Scope | Executed by | When |
|---|---|---|---|
| Component tests | Individual services and network functions inside xCore, xRouter and xControl, with real databases where a component needs one | Automated, in each repository's pipeline | Every merge request |
| Platform end-to-end suites | Complete platform installs from published Helm charts on Kubernetes, driven by 3GPP peer simulators: provisioning, session flows, soaks, capacity ramps, fault injection, monitoring, browser checks of xControl | Automated, six suites per pipeline | Every merge request; weekly deep soak |
| xControl browser suite | The management portal's create, edit, search, filter and report flows in a real Chromium browser against a real backend | Automated, on demand | Before an xControl release |
| Release certification | Declarative core configurations applied to a real cluster and driven with subscriber lifecycle scenarios; a single go or no-go verdict per configuration | Automated harness, run by Engineering | Before a release is published |
| Acceptance tests | End-to-end behaviour of a complete deployment with real devices and radios, per the acceptance test catalog | QA, manual and scripted | Every release candidate |
The first four levels are described in Continuous verification, including the cadence of each suite and the checks that run on demand rather than on every change. The acceptance tests are the subject of the rest of this section.
Environments⚓︎
Acceptance testing is performed in Expeto's lab against a complete platform: Expeto Edge (xCore) on Kubernetes, Expeto Gateway (xRouter), and Expeto Management (xControl and xView), with private radios and commercial UEs. A test that depends on topology (a Kubernetes node failure, a geo-redundant failover, a public-radio path through xRouter) states that topology in its Applies to facets and preconditions and is executed on that topology.
MNOs execute the installation and upgrade verification set in their own environment after installing an xCore and before promoting an upgrade to production. Expeto does not host pre-production or production infrastructure; every procedure in the catalog is written to run in the MNO's environment with the MNO's own devices.
Release gating⚓︎
A platform release is published to MNOs only when:
- every component test and every platform end-to-end suite is green on the release commit;
- the release certification harness passes for the reference configurations;
- every test in the acceptance test catalog that applies to the changed components has been executed on the release candidate, with a passing result or an agreed, documented deviation;
- any test added or modified for the release has been reviewed and accepted in the test repository;
- the release notes cite the test identifiers affected by the release.
Results are recorded per release in an acceptance test report that lists each test identifier, its result, the tester, the date and the evidence reference. MNOs receive the report for each release they deploy on request.
Evidence⚓︎
Each acceptance test names the evidence collected when it is executed. Typical evidence is a 3GPP signalling capture (pcap) showing the expected procedure, the Mobile Asset's session event log in xControl, a device-side connectivity or throughput result, and, for resilience tests, the Kubernetes or service status before and after the fault. Test environment and tooling defines where each capture is taken and how evidence files are named. Evidence is retained with the acceptance test report for the release.
Test status⚓︎
| Status | Meaning |
|---|---|
| Accepted | The procedure is complete, has been reviewed by QA and by the engineering owner of the component it exercises, and is released in the catalog. |
| Retired | No longer executed. Keeps its identifier for the record; not shown in the catalog. |
Every procedure in the catalog is accepted; a procedure that is still being written stays on a branch and is not published. The result of executing a procedure on a given platform release is not a property of the procedure: it is recorded, per release, in the acceptance test report described under Release gating.
How the catalog is maintained⚓︎
The catalog is a set of structured source files, one per domain, in the same repository as this documentation. Each test is a record with a permanent identifier, its applicability facets, preconditions, single-action steps with expected results, the 3GPP clauses it exercises, the evidence it produces and the automated checks that mirror it. Any Expeto engineer can propose a new test or a change through a merge request; every change is reviewed by QA and, for platform behaviour, by the engineering owner of the affected component, and is published only once accepted.
The pages in this section are generated from those sources. The generator validates every identifier, cross-reference and vocabulary, and the documentation pipeline fails if a published page differs from its source, so what an MNO reads is what Expeto executes.
New tests most often come from three places: a feature or behaviour change in a release, a defect found in the field that had no covering test, and a scenario raised by an MNO during onboarding. MNOs are welcome to propose scenarios through their Expeto account team; an accepted scenario becomes a test with a public identifier.
Scope and limitations⚓︎
The catalog covers the Expeto Platform. It does not cover the mobile operator's radio access network, transport, or core network beyond the interfaces xRouter and xCore present to them; those remain the mobile operator's responsibility and are covered by the operator's own test programs. Device interoperability is tested with a representative set of commercial UEs; an MNO with specific device requirements includes them when it runs the installation and upgrade verification set.
The following are not provided by the Expeto Platform. No acceptance test covers them, and the standards conformance statements mark the related items Not applicable:
- voice services (VoLTE, VoNR, IMS);
- emergency services;
- network slice-specific authentication and authorization (NSSAA);
- SMS on the private radio path (SMS is tested on the public radio path, where the Expeto SMSC in xRouter serves it);
- mobility between the 4G and 5G cores of a site over the N26 interface (a combined core interworks without N26);
- non-3GPP access to the 4G and 5G cores;
- power-saving modes (eDRX, PSM);
- dynamic policy control through a PCF (N7, N15), policy being applied from the subscription profile instead;
- a Network Slice Selection Function, the AMF granting the subscribed S-NSSAIs instead;
- the visited-network side of a roaming split (V-SMF, I-SMF, V-PCF, N32), roaming subscribers being served from the home side over S6a, S8 and Gp.
The following are implemented by the network function software but are not configured in an Expeto deployment by default, so no acceptance test covers them. Their statements are published under Additional network function capabilities; enabling one is configuration work agreed with Expeto Product Support:
- circuit-switched fallback and the SGs interface;
- cell broadcast (SBc);
- location services (SLs, SLg, 5G LCS);
- lawful interception;
- subscriber and equipment trace;
- EPS AAA interfaces for non-3GPP access (SWx, STa, SWm, SWa, S6b).