Trading Platform Release Testing

By Semenov Viktor, CTO, Alfa Algorithms Cyprus Ltd
Published 4 October 2026

For a broker, a trading platform is a system that records obligations, calculates exposure and controls access to client operations. A release therefore needs more evidence than a working interface or a successful order response. It needs checks that the resulting trades, account values and risk calculations agree.

As CTO, I view regression testing before every release as a necessary engineering discipline. This overview explains the purpose of the ScaleTrade test suite, the relationships it checks and how to read a public result without confusing a passing run with complete coverage.

Why trading software needs financial outcome checks

An execution error does not always look like a rejected order. A platform might record a position as closed and realise its profit, yet still include that position in margin or floating profit calculations. Each response can look plausible in isolation while the combined account state is wrong.

The consequences extend beyond a display discrepancy. Margin influences whether the next order can open. Equity influences risk monitoring and stop-out decisions. Trade history supports client statements and operational investigations. Inconsistent values can therefore affect decisions made by clients, managers and automated systems.

Our aim is to verify those relationships. With no open exposure, the account should not retain margin from a closed position. With a partially closed position, the remaining volume and realised result must agree with the original trade. Financial checks must also account for credit, commissions, storage and the rules of the instrument being tested.

Independent expectations make tests meaningful

Comparing two responses produced by the same faulty calculation can give false confidence. A useful test starts with controlled inputs and an expectation calculated independently of the result under examination.

The test stand uses deterministic instruments and known quotes so that expected profit, balance, equity and margin can be modelled. Reconciliation then compares those expectations with reported account values and the relevant portfolio evidence. A successful HTTP response is one observation; it is not the financial oracle.

This approach also makes failures more useful. A report can show the expected value, the actual value, the difference and the operations that preceded it. Repeated sampling helps distinguish a short-lived update delay from an inconsistency that persists through the verification window.

Coverage follows relationships across the platform

Trading functionality spans trades, groups, accounts, symbols, quotes and charts. Testing each area separately is useful, but many important failures occur where they interact.

Trade lifecycle checks exercise opening, modification, pending orders, protection levels and closing. Account finance checks examine how those actions affect balance and exposure. Group and account restrictions test which operations are permitted. Symbol settings and quotes provide the inputs for prices, spreads, margin and currency conversion. Market-data checks examine historical data and chart aggregation rather than assuming that a visible chart proves the underlying data is correct.

The established regression suite includes commissions, swaps, hedge margin, stop-out, multicurrency portfolios, bulk operations, trading rules, HTTP and WebSocket behaviour, and isolation between clients. Restart, backup and recovery checks extend validation beyond uninterrupted execution.

This is a description of tested areas, not a claim that every command, configuration, chart interaction or external integration is covered. Coverage needs to be expanded as the platform and its operational use develop.

Concurrency and repeated operations need explicit models

Real platforms process more than one action at a time. A quote can reach take-profit while a protection modification is in progress. A client can retry a request after losing its connection. A manager can act on a group of orders while individual positions change.

Testing only a sequential happy path misses these interactions. Race scenarios deliberately overlap actions and verify the settled result, including trade history and account finance. The essential question is whether the outcome remains valid, not whether a particular scheduling order always wins.

Specialised Sync commands, group close and cancel, trade deletion, cancellation and restoration, history imports and exports need additional attention. These operations can change or reproduce existing state rather than simply create a new order. Each needs a financial model suited to its semantics, checks of the affected trade set and verification of repeated application.

Repeated application does not mean every command must return the same response. Depending on its contract, a second request might be rejected, return an existing result or perform another valid operation. The test must verify the specified behaviour and ensure there is no unintended duplicate financial effect. Likewise, an export should be checked against the source records, while an import needs checks of accepted records, rejected input and the resulting financial state.

Recovery is part of correctness

A passing operation before a restart is not sufficient evidence that its result survives one. Recovery checks examine whether account values, positions and history remain consistent after the tested interruption and restoration procedures.

Backup tests matter for the same reason. The existence of a backup alone does not establish that it can restore a coherent trading state. Validation must examine the restored result within the scenario's scope.

These checks do not prove every possible infrastructure failure is covered. They provide repeatable evidence for specific restart, backup and recovery paths, which must be complemented by deployment-specific operational checks.

Why regression testing belongs before every release

Trading features share calculation and state-management logic. A change to one operation can affect commissions, margin, permissions or reporting elsewhere. Targeted tests of the changed feature therefore need the support of a broader regression run.

The release discipline I advocate is straightforward: test the exact candidate build, verify new behaviour with targeted scenarios, run the established regressions, investigate failures and rerun after corrections. When a defect exposes a missing case, add a reproducer so later releases exercise that case too.

The report should identify the build and test scope. A result from an earlier build—or an earlier, smaller suite—cannot substitute for validation of the current candidate. Testing is one input to release readiness alongside review, operational checks and the risks of the particular change. It is not a guarantee that production will never encounter a defect.

Public evidence and its limits

Our public test stand makes test results available for inspection. Here is a verified successful run:

Report field	Recorded result
Scenario	Basic trading and finance regression
Run date	3 October 2026, UTC
Tested build	1.25.250
Assertions passed	105,860
Assertions failed	0
Run status	Passed

Read the successful report for the detailed results. The assertion count represents individual checks across scenarios; it is neither a count of unique trading workflows nor a coverage percentage.

There is an important boundary to that result. The expanded run on 4 October 2026 included the new trade-mutation block and failed, reporting failures in 10 of that block's 13 sections. That result requires investigation; the report alone does not establish whether each failure originates in the platform, the test model or the test setup. The 3 October pass must not be presented as approval of that later expansion.

This distinction is the purpose of publishing evidence: readers can see which build was tested, what passed and where further work remains. Confidence comes from reproducible checks and honest coverage boundaries, not from treating a large test count as a promise of perfection.

For the shorter CTO overview, read Why We Test Trading Platform Releases.