Who this is for — Anyone with operational rules who wants to know whether they have a real edge before going live: discretionary, semi-systematic, or systematic.
A backtest applies defined rules to a consistent historical sample. It does not predict the future, but it measures how the method reacts to trends, sideways phases, and stress — separating an interesting idea from an operable one.
In plain terms — It is a dress rehearsal on past data: if the method does not hold up there, it will hold up even less in real time.
Bronze prerequisite — Before this lesson: trading-journal, trade-result, trading-mistake. See bronze-path.
What makes a backtest useful
A test is reliable when rules, sample, and costs are realistic:
- entry and exit rules written without ambiguity;
- instrument universe consistent with what you will actually trade;
- costs included (commissions, spread, slippage);
- stable risk per trade, readable in R;
- final report with equity, drawdown, and distribution of results.
If these points are missing, the result risks being only a retrospective narrative.
Example — Breakout strategy on an index: without costs it shows +22% per year; with realistic costs it drops to +9% and a worse drawdown. The method remains valid, but it needs different size and expectations.
How to use it without self-deception
- Define the rules before opening the data.
- Run the test over a long period and across different market phases.
- Freeze the method version and move to out-of-sample.
- Check robustness with forward-test or live simulation.
Card
- What it is: retrospective application of operational rules to historical data.
- When to use it: before going live and every time you change the method.
- Typical mistake: optimising parameters until the past looks perfect.
Silver path — Module: Validation. Part of silver-path.