Freeze the rules. Write them down in a form somebody else could follow. Then run them on prices that have not printed yet, and do not change anything until the test ends. That discipline is the whole method, and it is the part almost nobody manages, because a forward test is boring for weeks and then produces a losing run that makes the parameters look obviously wrong.
What the live feed catches that history cannot
A clean backtest already told you the logic makes money under a set of assumptions. Forward testing exists to find out which of those assumptions were wrong. Five things routinely differ.
- Fill quality. Backtests fill at the modelled price. Live orders fill where the book was when the order arrived, which on a fast news candle can be a long way off.
- Spread behaviour. Historical spread is only present if the test used real tick data. Live, the spread widens around rollover, thin sessions and scheduled releases, and it widens most on exactly the setups a breakout system wants.
- Latency and infrastructure. Your machine sleeps, the wifi drops, the platform updates itself at the worst possible moment. Anything running unattended belongs on a VPS before the test, not after.
- Rule ambiguity. Written rules always contain a gap the coder or the trader silently filled during the backtest. Forward testing surfaces it the first time a candle closes exactly on the level.
- Your own behaviour. The strategy that survives is the one you can still follow in week seven of a flat stretch.
Points one through three are why the results of an MT5 Strategy Tester run should be treated as a filter rather than a forecast. The tester models neither requotes nor variable latency, and it never models the person watching.
Demo, then small live
Run the first phase on a demo account hosted on the same server as the live one, so the symbol specification, the trading hours and the candle boundaries match. That phase answers a narrow question: does the system generate the trades it is supposed to generate, at the times it is supposed to generate them. It answers nothing about execution, because demo servers typically fill instantly at the quoted price with no requotes and no partial fills.
The second phase is a small live allocation, sized so that a bad run is an annoyance rather than an event. Now you can measure the thing demo hides: the difference between your intended entry price and the actual fill, trade by trade. Record it in pips and in money. If the average slippage plus commission eats a meaningful share of the average win, the strategy has an edge on paper and no edge in the market, and no amount of further optimisation changes that. The behavioural gap between the two phases is real too, and worth reading about separately in our piece on how demo and live accounts differ.
A forward test that ends profitably proves the strategy survived one particular stretch of market. It is not a prediction, it does not guarantee anything, and every stage of this process risks real money once you leave demo.
How long, and how many trades
Time is the wrong unit. Trades are the right one, and market conditions are the constraint on top. A system that takes four trades a month needs the better part of a year to build a sample anyone should act on. A session-open system taking three a day gets there in a couple of months. If the strategy only works in trending conditions, a test that happens to run through a trending quarter tells you the strategy works in trending conditions, which you already knew.
Set the end date before you start, and set it by trade count with a maximum calendar limit. Ending a test early because it is going well is the most common way people talk themselves into deploying a fitted system. Ending it early because it is going badly is a different mistake with the same cause: no criteria were written down.
Log the things you will want in three months
Platform statements give you entry, exit and profit. They do not give you why. For every trade record the setup tag, the intended entry and stop, the actual fill, the spread at entry, whether the signal was clean or marginal, and whether you followed the rules or improvised. Screenshots at entry and exit take ten seconds and settle arguments later.
The payoff comes when you segment. Nine times out of ten a mediocre forward test contains one tag that is clearly negative and one that is clearly positive, and the fix is to cut a setup rather than retune a parameter. That analysis is impossible without tagging, which is the practical argument for keeping a structured trading journal from the first trade of the test rather than starting one after the results confuse you.
Kill criteria, written in advance
Before the first order, define what would make you stop. Something like: stop if the drawdown from the test's own peak exceeds a stated percentage, stop if the average slippage exceeds a stated number of pips, stop if fewer than a stated number of signals appear in the first month, stop if the trade list diverges from the backtest behaviour in a way you cannot explain. These are engineering thresholds, not predictions.
The last one matters more than it sounds. If the forward test produces trades the backtest would not have taken, something in the implementation differs from the tested version, and that is a bug hunt rather than a performance question. Compare the two trade lists directly. Mismatched server times, a different symbol suffix and an indicator that repaints on the live feed but not on stored bars all show up this way.
When a test passes, scale in steps, not in one move, and keep logging. The same discipline applies to any external system you are considering paying for, which is why the questions in evaluating a signal service are largely the questions you should be asking your own strategy.
"Every strategy I have ever killed was killed by the forward test, and every one of them looked fine in the backtest. That is the entire reason the stage exists."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Freeze the rules before the test starts and change nothing until the predefined end point.
- Demo validates the trade list, small live validates the fills. Only the second measures slippage honestly.
- Measure the test in trades and market conditions, not in weeks, and set the end date up front.
- A live trade list that diverges from the backtest is a bug to find, not a result to interpret.
Frequently Asked Questions
How long should a forward test run?
Long enough to collect a trade sample that means something and to cross at least one change in market conditions. For a system that takes a few trades a week that usually means several months rather than several weeks. A short test on a strategy with rare signals tells you almost nothing, and the honest answer is often that the system cannot be validated by a single trader in a reasonable time frame.
Is a demo account good enough for forward testing?
A demo on the same server as the live account is fine for validating logic, signal timing and the trade list. It is weak on execution because demo fills are usually idealised, with no requotes, no partial fills on size and little slippage. The common approach is a demo phase to confirm the strategy behaves as designed, then a small live allocation to measure real fill quality before any scaling decision.
What is the difference between forward testing and walk forward optimisation?
Walk forward optimisation is still a backtest: the software repeatedly optimises on one slice of history and measures the next slice, all on stored data. Forward testing runs the finished, frozen strategy on prices that did not exist when the rules were written. Walk forward analysis reduces the odds of curve fitting. Only forward testing exposes the strategy to real execution and to the trader's own behaviour.