How to backtest an options strategy

1. Write the strategy as rules, not as a feeling

Before any software is involved, the idea has to be reducible to rules a computer can follow with no judgement: what is traded, when it is entered, how the strikes are chosen, and every way it can exit.

A rule you cannot state precisely is a rule you cannot test. "Sell a straddle when volatility looks high" is not a rule. "Sell the at-the-money straddle at 9:20 on the current weekly expiry, with a stop on each leg and a hard square-off at 15:15" is.

• Instrument and expiry: which index, and which expiry (current week, next week, monthly).
• Entry: a time, or a condition on an indicator, or both.
• Strike selection: at-the-money, an offset, a premium target, a delta target, or a distance from spot.
• Exits: stop-loss and target per leg or for the whole structure, a daily loss limit, and a time-based square-off as the backstop.

2. Build it without code, then check the legs

In the Strategy Builder the legs, conditions and exits are assembled point-and-click, so the definition is explicit and reviewable. The most useful habit at this stage is to read the leg list back and confirm it describes the trade you meant, including the quantity of each leg.

3. Run it over a window long enough to contain different markets

One quiet month tells you almost nothing. Choose a window that includes trending days, range days, high-volatility days and expiry days. Note the dates you used: a result only ever describes the window it was run on.

Fills matter as much as signals. A backtest that prices options at a convenient mid-price, with a round notional lot size and a made-up expiry calendar, is testing a different strategy from the one you would trade. Real lot sizes, the real expiry calendar including holiday-shifted weeks, and per-leg entry and exit are the minimum for a result to mean anything.

4. Read the result in three layers

Then look at costs. Government charges (securities transaction tax, exchange and clearing fees, GST, stamp duty) are real, and options strategies with many small trades are sensitive to them. A good report shows the gross result, the charges, and the result after charges as three separate lines, so you can see how much of the headline number the costs consume. Brokerage and slippage are assumptions you set yourself; test a few levels instead of assuming zero.

• Is the result plausible? Check the trade count and the ledger first. A run that finds no trades is a configuration problem, not a result.
• How did it get there? Look at the drawdown and the worst days before the total. Maximum drawdown, the Ulcer index and the recovery factor describe how bad the path was.
• Is it consistent? Sharpe, Sortino, profit factor, win rate and expectancy summarise the distribution. No single one of them is the answer; read them together.

5. Do not tune on the data you will judge on

The moment you adjust a parameter and re-run on the same window, the window has become part of the strategy. Keep a stretch of history the tuning never sees and judge the final choice there. Rolling the fit and the test forward through time (walk-forward testing) is the stricter version; see the guide on walk-forward testing.

6. Paper trade before any real order

History cannot tell you about your own execution, your broker's behaviour on a volatile open, or latency. Running the same strategy definition on paper against the live feed exposes those differences with no money at risk. Move to live only when the paper behaviour matches the backtest closely enough that you can explain every difference.

Common questions

Try it on the desk

Build the strategy without code, run it over history, and read the result before any money is involved.

Start with a backtest