Direct answer: definition and purpose
Backtesting practice is the process of checking how a defined set of trading rules would have behaved in past market data. It is used to learn whether those rules are consistent with certain behaviors and whether the approach is plausible enough to investigate further. In forex contexts, backtesting is typically done on historical price series to estimate outcomes under assumptions about execution.
Backtesting practice is not the same as predicting the future. Historical relationships can break, and real trading involves factors (such as spread changes, order execution differences, and slippage) that may not be fully captured by simple historical simulations.
Mechanics: how backtesting works
A backtest needs a clear, repeatable model. The core elements are:
- Trading rules: entry/exit conditions, position sizing, and risk controls written so they can be applied the same way every time.
- Data and time window: which historical period is used, and at what timeframe (for example, minute bars vs. hourly bars).
- Execution assumptions: how trades are filled in the simulation (prices, costs, and whether orders can be filled at the next bar or at a specified price).
- Evaluation metrics: what you measure, such as total return, drawdowns, win rate, or variability.
A simplified example model is: “When a rule triggers on bar t, open at the assumed execution price, close when the exit rule triggers, then repeat across the dataset.” Any calculation depends on assumptions, so those assumptions should be stated explicitly before interpreting the results.
Adjacent concepts and how backtesting practice differs
Backtesting is often mentioned alongside other evaluation approaches, but they are not identical:
- Forward testing (paper or live simulation) checks the rules on data that comes after the backtest period, reducing reliance on the exact historical window.
- Walk-forward analysis repeatedly retrains or re-evaluates using shifting windows, aiming to mimic how the rules would behave as new data arrives.
- Chart review or “manual back-looking” may look similar, but it is usually less structured: rules can be vague, selection bias can occur, and execution assumptions may be unclear.
Backtesting practice is best understood as a structured, checkable method for applying explicit rules to historical data—not as evidence that a specific future outcome is likely.
Evidence and example: a concrete, checkable setup
To keep a backtest checkable, define your assumptions upfront.
For instance, assume a rules-based entry and a rules-based exit, then run the simulation across a chosen historical window using one consistent execution assumption (such as using a specific bar’s price as the fill). Record the results and the rule behavior over time.
A useful practice is to compare two backtests that differ only in one deliberate aspect (for example, the time period) to see whether the apparent behavior depends strongly on that choice. If results change dramatically when you adjust reasonable settings, that is a warning sign.
Limitations and risks: what can fail
Backtesting often fails for predictable reasons:
- Non-stationarity: market conditions change, so patterns that worked in one era may not persist.
- Execution mismatch: historical prices may not reflect realistic fills, especially if order execution differs from the simulation model.
- Transaction costs and liquidity: costs and the ability to enter/exit can materially affect outcomes; ignoring them can overstate performance.
- Overfitting: tuning rules too closely to historical noise can make results look strong in-sample but perform poorly on new data.
- Data quality issues: missing, adjusted, or inconsistent historical series can distort results.
These limitations mean that a good-looking backtest is not sufficient on its own. It shows that the rules might have had certain behavior in that specific historical context under those specific assumptions.
Verification and next question: how to independently assess
Independent verification should focus on whether the conclusions survive changing the data and the assumptions. Common checks include:
- Out-of-sample testing: evaluate the rules on a separate period not used to develop or tune them.
- Sensitivity analysis: vary key assumptions (like costs or execution timing) within a reasonable range and observe whether conclusions change.
- Rule transparency: ensure the rules are fully specified so the backtest can be reproduced.
- Repeated evaluation: run the process across multiple historical windows to reduce the chance that results are driven by one lucky period.