Backtesting vs Live Trading: Why Real Results Differ

Almost every trader who has built a strategy has had this moment: the backtest looks great, and after a few weeks of live trading the picture is completely different. That does not necessarily mean the strategy is bad. It means a backtest is a model of reality, and every model has assumptions. This article walks through the main sources of the gap and how to shrink it.

What a backtest actually measures

A backtest runs a strategy's rules over historical price data and calculates what would have happened had you traded them. In TradingView, for example, the Strategy Tester does this for strategies written in Pine Script. The result is an estimate, not a recording of the past.

The problem is that a backtest only "knows" what is in its data. If the data is five-minute bars, it does not know what happened inside the bar. If you did not set commissions, it assumes trading is free. If you did not set slippage, it assumes every order fills exactly at the price you wanted. Each of those assumptions biases the result upward.

Fills and slippage

For most traders this is the single biggest source of the gap.

• Market orders fill at the next available price, not the price on the chart at the moment of the decision. In volatile moments, such as an employment report release, the difference can be several ticks.
• Limit orders guarantee price but not a fill. Many backtests assume that if price touched the level, the order filled. In reality you may have been at the back of the queue and never filled - often on the very best trades.
• Stop orders become market orders when triggered, so they can fill far from the level.

A hypothetical example: a strategy takes 400 trades a year on MNQ. If each trade suffers on average one tick of slippage on entry and one on exit, that adds up to 800 ticks a year that never appeared in the backtest. For a strategy with a small edge, that can be the whole difference. More in slippage and execution costs.

Commissions, exchange fees and data costs

Every futures trade carries costs: broker commission, exchange and regulatory fees, and sometimes platform fees. Relatively high-frequency strategies are especially sensitive. A simple rule of thumb: set conservative costs in the backtest, slightly higher than what you expect to pay.

Latency

Time passes between the moment a condition is met and the moment an order reaches the exchange: the bar has to close, the alert is sent, the webhook is received and processed, and the order goes to the broker. Usually this is a matter of a few seconds or less, but in a fast market even that matters. A strategy built around entering exactly at bar close will always get a slightly different price in practice.

Data quality and biases

• Look-ahead bias: the code uses information that was not available at the moment of the decision. A classic example: deciding based on a bar's close but entering at that same bar's open. Careless use of higher-timeframe data can cause it too.
• Repainting: indicators that change their historical values after the fact. On the chart the signal looks perfect; in real time it appeared and disappeared.
• Survivorship bias: mainly relevant to stocks - testing only on assets that survived to today. In futures, the parallel issue is continuous charts (such as NQ1!) that stitch together different contracts and can create artificial jumps on roll days.
• Missing or wrong data: missing bars, wrong session hours or an incorrect time zone.

Market regime changes

Even a technically perfect backtest describes the past. Markets go through periods of high and low volatility, trend and chop. A strategy tested mostly on one year with a particular character may behave very differently in the next period. The longer and more varied the test period, the more reliable the picture - but it is never guaranteed. A closely related problem is overfitting, which we cover in overfitting in trading strategies.

Forward testing and simulation

The best way to bridge the gap is an intermediate stage: running the strategy in real time on a simulation account, using the same execution path you will use live. This is called forward testing or paper trading.

What to check during this stage:

1. Do alerts arrive on time and in the right format?
2. What is the average distance between signal price and fill price?
3. Is the number of trades similar to what the backtest expected?
4. Are there duplicated or missing trades, or "orphaned" positions?
5. Is behavior around the open, the close and data releases reasonable?

Log every trade in a journal and compare it with the backtest over the same period. The gap you measure is valuable: you can feed it back into the backtest as a realistic slippage assumption.

Reasonable expectations

• Assume live results will be weaker than the backtest, and plan accordingly.
• If a strategy is profitable only without commissions and slippage, it has no real edge.
• A short simulation period proves nothing either way; mostly it tests the plumbing.
• Position size at the start of live trading should be small, growing only once execution behaves as expected.

Key takeaways

• A backtest is a model with assumptions, and nearly all of them bias results upward.
• Slippage, limit-order fills and commissions are the largest sources of the gap.
• Look-ahead bias and repainting can produce results that were never achievable in real time.
• Forward testing in simulation, with the same execution path, is a mandatory step.
• Measure the actual gap and feed it back into your testing.

If you run TradingView alerts, WeCore lets you connect them to your own account and run them first in simulation mode, so you can check fills, timing and risk rules before moving to a live account. For the basic concepts, see what is algorithmic trading.