A backtest is one stage in evaluating a strategy. Specify rules, audit history, separate training from evaluation, then investigate execution through demo and any carefully limited live study. Passing these stages does not guarantee account survival or a repeatable return.

Why a single backtest is not a process

Program correctness, data quality, historical performance and operation on an account answer different questions. Code can faithfully execute an unprofitable idea; a profitable report can also come from incorrect code. Keep a versioned evidence card with the question, expected state, observed result and unresolved limit. Include successful entry, loss, no signal, confirmed rejection and restart cases. Mark “not checked” when evidence is missing. A hypothetical 30% return selected from 300 combinations is a reason to investigate selection, not proof of an edge. See how to backtest a strategy.

98% overall does not pass a failure category

Record the case type beside each result. One overall percentage can hide untested or incorrect handling of an important state.

Scroll sideways to see the full diagram

98% overall does not pass a failure categoryA fictional list of 100 functional cases contains 98 normal-operation cases and 2 confirmed order rejections. All 98 normal cases meet their predefined criterion. Both rejection cases fail the requirement to record rejection without falsely marking execution. Overall pass rate is 98%, but the required rejection category passes 0 of 2. Equal-length frames each represent 100% of their own category, not equal case counts; filled portions show pass shares. These are fictional functional tests, not a reliability probability or strategy return.CHECK THE FAILURE CATEGORY FIRSTFictional functional tests • pass sharesNormal operation98 /98 pass100%Confirmed rejection0 /2 pass0%Each frame = 100% of its own category.Overall:98 /100 = 98%Failure criterion:0 /2 = 0%This category still fails.

Assumptions: The complete fictional list of 100 functional cases has predefined criteria. Pass means the expected state is recorded; there are no real prices, accounts or trades. Categories must pass separately. This is a program check, not a statistical reliability estimate.

The two required categories were defined before testing. All 98 normal cases recorded the expected states. In the two confirmed-rejection tests, the program should record rejection without marking execution. Both fail that criterion.

The overall 98 /100 = 98% describes this list only. Rejection gives 0 /2 = 0%. Because both categories are required, the check remains open: repair rejection handling and rerun the relevant cases, checking that normal operation still works.

Each diagram frame represents 100% of its own category; its area does not compare 98 cases with 2. This sample gives no market failure probability, broker-quality measure or future profitability. A missing network response is not classified as rejection here: the two tests receive an already confirmed rejection state.

A high overall score does not close a failed required category.

Rules on paper, no interpretation

Write entry, exit, stop, target and sizing rules precisely enough to reproduce. A hypothetical candidate uses EMA(50), EMA(200), RSI(14), a twenty-period average, a 1.5 ATR(14) stop, a 2.5 ATR target and one-percent planned risk. It still needs exact bar timing, a definition of “touch”, executable prices and handling of simultaneous exit conditions before testing.

Match the data window to the research question

Choose history for the strategy and available instrument data, rather than a fixed number of years. Record provider, product, time zone, quote sides, gaps, code version, inputs and execution assumptions. Archive the dataset or its identifier and retain operations and logs. Distinguish MT5 real ticks from generated replacements. A change in history, terminal build or account settings can change a report without a strategy change. Trade count alone does not establish independent evidence.

Splitting the data and protecting the out-of-sample block

Predeclare the chronological development and evaluation split. A hypothetical 70/30 design is one choice; a weaker OOS result can reflect sampling, costs or conditions as well as selection. Keep the test unavailable to rule selection. For example, if version 1.0 is tested on 2024–2025 and its Monday losses motivate excluding Mondays in version 1.1, the repeated 2024–2025 result is development evidence for that new version. Preserve both reports and the reason for the change; renaming the period does not make it independent again.

Walk-forward as another check

A hypothetical walk-forward study trains on 2018–2021 and tests on 2022, then trains on 2019–2022 and tests on 2023. Repeat the chosen rolling procedure without using future information. Five to seven cycles are a design choice. Define the metric called WFE and its denominator before interpreting it; values of 0.5–0.75 or below 0.3 are not universal verdicts. See walk-forward analysis and the traders' workshop.

Real-time operation and any optional live study

A demo study or observation without orders can check signal timing, permissions, responses and restarts in real time. Record the idea identifier, requested volume, fills and any active orders. MT5’s tester option called Forward instead evaluates the later part of a historical date range; it is not the same as observing future quotes on demo. Elapsed months do not test a rare failure that never occurred, and demo fills need not reproduce a live account.

Consider a hypothetical buy target of 0.20 lot. Before disconnection, 0.08 is filled and the remaining order is subsequently confirmed cancelled. With no other positions or orders for this idea, repeating 0.20 gives 0.28 filled, exceeding the target by 0.08, or 40%. Filling only the difference, 0.20 − 0.08 = 0.12, gives 0.20 in total. If cancellation is unknown, the old remainder could still fill: first reconcile the state rather than blindly resubmit. This checks one specified failure path, not total system reliability.

If a live study is justified, specify the actual contract size and exposure; “micro-lot” does not mean one-tenth of any target size. A three-to-six-month observation period is illustrative. Compare costs and execution with the model, and record differences before considering any increase. Similar results across stages do not eliminate market risk.

Illustrative example — full pipeline for a breakout strategy

All figures in this illustrative breakout study are assigned, not observed results. A EUR/USD M30 candidate uses a previous twenty-bar high for entry and a previous ten-bar low for exit; it still needs precise order timing and fill rules. Development is 2014–2020 and evaluation is 2021–2023. Suppose optimisation selects twenty-three/eleven bars and a 1.4 ATR stop; the assigned IS win rate, profit factor and annualised return are 58%, 1.72 and 22%, versus 54%, 1.51 and 18% OOS. These aggregate values do not reconstruct a trade sequence or drawdown. A later demo scenario assigns an extra half-pip of execution cost, and an optional live scenario assigns 51% wins. None of these summaries validates the next stage or determines a position size; compare recorded signals, payouts, costs and uncertainty.

What to do tomorrow

  1. Write the strategy rules into a plain text file precisely enough that another human reading it would place identical trades — no interpretation, no "I feel the trend", with exact parameter values, a stop-loss formula, and position size as a percentage of account equity.
  2. Audit historical data for the traded instrument, including timestamps, missing periods, tick provenance and contract changes. Choose a sample suited to the hypothesis and document the market conditions it does and does not cover.
  3. Predeclare the chronological split, evaluation metric and walk-forward design. A seventy/thirty split and five to seven cycles are illustrative choices. Investigate unstable parameters without treating a fifty-percent change or WFE below 0.5 as an automatic universal verdict.
  4. Use demo to test the operating workflow with frozen rules. If a live study follows, cap its planned exposure and compare execution and costs with the model. Three-to-six-month periods and a Monte Carlo simulation do not guarantee readiness to scale.
  5. Compare costs, drawdowns and uncertainty alongside returns. Twelve percent at each stage is not automatically safer than thirty percent IS and eight OOS. Use the discrepancies to investigate the proposed trading edge.