Backtesting a Trading Strategy: The Full Method, Start to Finish

Quick Answer

Backtesting a trading strategy means running an exactly-specified rule set over historical data and recording what it would have done, with every cost it would have paid. Done properly it is a falsification exercise — you are trying to kill the idea, not confirm it. The method has seven steps: write the rules until they are unambiguous; get data at the granularity your rules actually need; build the full cost stack including slippage per leg; split your sample before you look at any result; run it and read the distribution rather than the total; test whether the result survives small changes to the rules; and then paper trade it live. Most retail backtests fail at steps three and four — costs are modelled thin, and the sample is chosen after the fact. A backtest can tell you that an idea is bad. It can never tell you that an idea is good. That asymmetry is the whole discipline.

If what you actually need is which software to use, that is a different question and we answer it separately in our guide to options backtesting software in India, which reviews eleven platforms against a twelve-point checklist. This page is the method, and it applies on any of them.

Paper trade before any of this touches live capital. This page describes a research method. It recommends no strategy, no strike and no structure, it reports no expected return, and it is analysis rather than advice.

What a backtest is, and the trap built into the word

A backtest is a simulation. You specify a rule, apply it to past data, and count what happens. There is nothing clever about the idea; the difficulty is entirely in the execution, and it is entirely about honesty.

The trap is that a backtest is extremely easy to make look good. You have the full history in front of you, and you are choosing rules. Every choice you make — which years, which index, which stop level, which entry time, which filter — is a choice made with knowledge of the answer. Make enough of those choices and you will produce a beautiful equity curve from pure noise, and you will not feel like you cheated at any point. You will feel like you were being thorough.

So the useful framing is not "does this strategy work?" It is:

• Can I kill this idea? A backtest that survives genuine attempts to break it is informative. One that was built to pass is not a test, it is a demonstration.
• What is the cheapest way to find out this does not work? Run the version most likely to fail first. Test the full cost model before the clean one. Test the ugly period before the favourable one.
• What would have to be true for this result to be an artefact? Write that down before you run anything, so you can check it afterwards.

For option selling specifically there is an extra reason to be suspicious of good-looking results: the strategy family produces high win rates by construction. Selling out-of-the-money premium wins most days because that is the design, not because an edge was found. A backtest showing 85% winning days has told you almost nothing until you look at what the 15% cost.

Step 1 — Write the rules until there is nothing left to decide

This is the step people treat as a formality and it is where most backtests are actually lost. If any part of the rule requires judgement at the moment of execution, you have not specified a strategy — you have specified a feeling, and the backtest will quietly resolve the ambiguity in whichever direction flatters it.

A rule set is complete when a competent stranger could execute it from the page without asking you a question. For an option-selling strategy that means all of the following are written down:

• Entry trigger. Exact time, or an exact condition with exact parameters. "After the opening settles" is not a rule. A specific clock time is. Our own house convention never uses a 9:15 entry — the first minute of an Indian index session carries auction-driven prints that no backtest models faithfully — so entries start at 9:16 or later.
• Instrument and expiry selection. Which index, which expiry (current week, next week, monthly), and what happens on a week where that expiry does not exist or falls on a holiday.
• Strike selection rule. Not a strike. A rule that resolves to a strike — by distance from spot, by delta band, by premium range. Then the tie-breaker when two strikes qualify equally, which happens more often than you would expect.
• Position size rule. In lots, and as a function of capital, not a fixed number — otherwise the result is not scalable and you will not notice until you scale it.
• Stop-loss, per leg or on the position. With the exact trigger basis: premium multiple, points, underlying level, or percentage of capital. And whether it is checked on close of a candle or intrabar, which changes results materially.
• Target or re-entry logic, if any. Including the maximum number of re-entries per session and whether a stopped leg is re-sold.
• Hard square-off time. Every intraday strategy needs one, and the time is part of the strategy, not an operational detail.
• What happens on edge days. Expiry days, holiday-shortened sessions, special sessions, days where the first candle gaps past your entry condition.

Write these as a numbered list in a file before touching data. You will amend it, and that is fine — but amendments made after seeing results need to be logged as amendments, because the count of how many times you changed the rules is itself a result. We come back to that in step 6.

Step 2 — Get the right data, at the right granularity

Options data is not like equity data, and "historical options data" covers several quite different things. What your rules need determines what you must have, and getting this wrong invalidates everything downstream.

What the data has to contain

For an Indian index option-selling backtest, the minimum per contract per timestamp is: the underlying's price, the option's own traded price, the strike, the expiry date, and the option type. Beyond that minimum, three fields change what questions you can ask:

• Bid and ask, not just last traded price. Without the spread you cannot model execution honestly — you are implicitly assuming you traded at the mid or at the last print, both of which are optimistic for a seller entering and for anyone exiting in a hurry.
• Volume and open interest. These tell you whether the strike your rule selected was actually tradeable at that moment. A backtest that happily trades an illiquid far strike is producing fiction.
• Implied volatility, or enough to derive it. Only needed if your rules reference volatility or delta. If your strike-selection rule is delta-based, you need this and you need it to have been computed consistently.

Choosing granularity by the question

Granularity	Answers	Breaks down on
End of day	Multi-day positional strategies, long-horizon studies of premium behaviour, rough regime work	Anything intraday. Cannot model a stop at all — an EOD backtest of a stopped strategy is not a weak approximation, it is a different strategy
One minute	Most intraday option-selling rules: timed entries, timed exits, stops checked at candle close, square-off times	Intrabar stops. A one-minute candle can travel far enough that "stop hit at the candle's low" and "stop hit on close" are different trades. Also understates expiry-afternoon moves
One second / tick	Intrabar stop logic, slippage studies, re-entry sequencing, the final hour of an expiry session	Nothing methodologically — but it is expensive, slow, and overkill for rules that only act at fixed times

The rule of thumb: your data must be finer than your fastest rule. If a stop can trigger at any moment, minute data is an approximation and you should know which direction it is biased in — generally it flatters, because it smooths over the worst prints inside each bar. If your rules only fire at fixed clock times, minute data is genuinely sufficient and tick data buys you nothing.

Captured versus reconstructed

The question that matters more than granularity: was the option price captured from real trades, or reconstructed from a model? Some data sources fill gaps in illiquid contracts by pricing them theoretically from the underlying and a volatility assumption. That is defensible for some research and fatal for backtesting a selling strategy, because the whole risk you are measuring lives in exactly the moments when real prices diverge violently from theoretical ones.

Reconstructed data is recognisable by its behaviour rather than its label: it is too smooth. Real far-out-of-the-money prices near expiry are jumpy, gappy and widely spread. If your dataset shows a clean curve where the market showed chaos, you are backtesting the model that generated the data, not the market. There is a concrete twenty-minute procedure for checking this on any platform in the data accuracy test on our backtesting software guide — run it before you trust a dataset, and we would rather point you there than rewrite it here.

The broader question of what historical options data for Indian index options consists of, where the official sources are and what each one does and does not give you, is covered in NSE and NIFTY historical options data: what exists and what to check.

Step 3 — Build the cost stack honestly, then make it worse

This is where most retail backtests die, and it is the single highest-leverage step on the page. An option-selling result at zero costs is not a weak result — it is a different sign. We have measured strategies that are comfortably profitable gross and clearly negative net, and the gap was not close.

There are four layers, and they are usually modelled in descending order of accuracy, which is exactly backwards from their size.

Layer 1 — Brokerage

The easy one. A per-order or percentage figure from your broker's rate card. Apply it per leg and per order, including the exit, and including stopped-and-re-entered legs. The common error is counting a four-leg round trip as one or two orders instead of eight.

Layer 2 — Statutory charges and taxes

Securities transaction tax, exchange transaction charges, SEBI turnover fees, stamp duty, GST on the brokerage-and-charges base. All of these are set by the exchanges, SEBI and the government, all of them are revised, and we deliberately publish no rates for them — a stale rate in a backtest is worse than no rate, because it produces a precise wrong answer. Take the current figures from the exchange and the notification in force on the day you build the model, and record the date you took them.

Two structural points that survive any rate change:

• STT on an exercised in-the-money option is computed on a settlement-derived base, not on the premium, which makes it enormously larger. Any strategy whose rules let short legs run into settlement needs that modelled or it is understating costs on precisely its worst days. The mechanism is in how options trading income is taxed in India.
• Rate changes break comparability across time. The STT increase that took effect on 1 April 2026 changed the arithmetic for sellers, which means a backtest spanning that date is running two different cost regimes and reporting one average. Either model the change on the correct date, or state the limitation.

Layer 3 — Slippage, per leg

The biggest and the most frequently fudged. Slippage is the difference between the price your backtest assumed and the price you would actually have got, and for options it is routinely larger than every other cost combined.

How to model it properly:

• Per leg, not per strategy. A single slippage figure applied to the whole position hides the fact that your far-out-of-the-money leg has a far wider spread than your at-the-money leg. The legs are not equally liquid and should not share one number.
• Asymmetric by direction. You cross the spread entering and crossing it again exiting. A seller's entry and a buyer's exit are not symmetric costs on a thin book.
• Worse on stops. A stop-loss exit is, by definition, an exit into a fast-moving market, which is when the book is thinnest. Modelling stop exits at the same slippage as planned exits is the most common single source of overstated backtest results in option selling.
• Worse near expiry and further from the money. Both widen the spread. If your strategy lives in far strikes on expiry day, your slippage assumption is doing more work than your entry logic.

The practical discipline: find the slippage level at which the strategy stops working, and then ask whether that level is plausible. That number is far more informative than the result at your preferred assumption, because it converts a judgement call into a measurable margin of safety. A strategy that breaks at half a tick of slippage is not a strategy.

Layer 4 — Things that are costs but do not look like them

• Margin opportunity cost. The exchange blocks margin for as long as the position is open, and that capital is doing nothing else. A return figure that ignores blocked margin is a return on the wrong denominator.
• Margin expansion. Requirements rise when volatility rises, which is the same day your position is losing. If your backtest does not track margin, it cannot tell you about the day you would have been squared off for a shortfall. See how option selling works, step by step for the mechanics of that.
• Non-fills. A limit order that your backtest filled might not have filled. Market orders always "fill" in a backtest and fill worse in reality.

Our own convention, for what it is worth: we run every finalist strategy under a realistic slippage model and the full Indian charge stack before any number is reported internally, not after. Results computed at zero cost exist only as a sanity check on the engine, never as a result.

Step 4 — Split the sample before you look at anything

This step is free, it takes thirty seconds, and skipping it invalidates more backtests than every data problem combined.

Decide, before running anything, which part of your history you will develop on and which part you will not touch. Then do all your thinking, tuning, parameter-choosing and rule-amending on the first part only. The second part gets used once, at the end, to check whether what you found survives on data that had no influence on your choices.

How to split:

• By time, not randomly. Randomly shuffling days leaks information — adjacent days share regime, and a random split lets the development set tell you about the test set. Use contiguous blocks.
• Across regimes, not just chronologically. A simple early/late split can hand you a development period that was entirely low-volatility and a test period that was entirely high-volatility, which tests regime sensitivity rather than the rule. For index option selling the volatility regime is the dominant variable, so make sure both halves contain quiet periods, violent periods and trending periods.
• With enough days on each side to mean anything. Expiry-day strategies in particular have few observations per year — one or two per week per index — so a year is a few dozen trades, which is not many. Be honest about the sample size before drawing a conclusion from it.

A caution specific to option selling, which we have come to through our own work: the conventional train-and-out-of-sample split is weaker here than it is in other domains, because the thing that drives results is the volatility regime, and regimes are long. A clean split can produce two halves that differ mainly in their regime, so "it failed out of sample" and "the regime changed" become indistinguishable. Where we can, we prefer two additional checks alongside the split: whether the result holds up in the most recent portion of the sample without fading, and what the result looks like at a pessimistic percentile of the distribution rather than at the mean. Both are harder to fool than a single out-of-sample pass.

And the honest version of the rule: you get one look at the held-out data. If you look, fail, adjust the rules and look again, it is no longer held out — it has become part of your development set, and you now have no clean test at all. Going back for a second look is extremely tempting and it is the point at which a research process becomes a search for a result.

Step 5 — Run it, then read the distribution rather than the total

You now have output. The instinct is to look at the total P&L and the win rate. Both are nearly useless on their own, and both are what gets quoted.

What to read instead, in this order:

1. The shape of the losing days. Sort every day by result and look at the worst ten. For a premium-selling strategy, that handful of days usually contains the entire answer. If the worst day is many multiples of the average winning day, you have a strategy whose whole outcome depends on how many of those days land in your sample — which is luck, not edge.
2. Average win against average loss, alongside win rate. An 85% win rate with an average loss eight times the average win is a coin flip wearing a suit. Neither number means anything without the other.
3. Drawdown, and its duration. The depth tells you whether you would have been wiped out. The duration tells you whether you would have stopped trading it — a 15% drawdown lasting four months ends more strategies than a 30% drawdown lasting a week, because the trader quits.
4. The path, not the endpoint. Two strategies with the same annual return and completely different equity curves are not comparable. Look at the curve.
5. Results by regime. Split the output by volatility band and by trending versus range-bound periods. A result that is entirely produced by one regime is a bet on that regime continuing, which is a legitimate position but needs to be stated as one.
6. Trade count per bucket. Before believing any of the above, check how many trades are in each slice. Conclusions drawn from eleven trades in the high-volatility bucket are not conclusions.

Two specific red flags that mean stop and investigate rather than proceed:

• No losing month. For a short-gamma strategy over a multi-year sample, this is evidence of a modelling error, not of quality. Something in the cost model or the fill logic is too kind.
• A result that improves as you add legs or complexity. Each addition is another parameter fitted to the same history. Improvement with complexity on the development set is the expected behaviour of overfitting.

We should also say what our own data says about the gap between a backtest's result and what is actually bankable. Across 163 logged expiry sessions on our own book, the median session gave back 42.8% of its intraday profit peak by the close, and roughly 30% of sessions turned a position that had been profitable at its peak into a loss by the end of the day. A backtest that reports only end-of-day results is silent about that entire dynamic, and a strategy whose rules are built around capturing peaks will behave very differently live than its summary row suggests.

Step 6 — Try to break it

A result that exists at exactly one set of parameters is not a finding. The checks below are the ones that actually change our minds, and they are deliberately adversarial.

• Perturb every parameter. Move the entry time by five minutes. Move the stop by 10%. Shift the strike-selection rule by one strike. A robust strategy degrades gradually in every direction. A fitted one falls off a cliff, and the cliff edge is where your backtested parameters are sitting.
• Count the configurations you tested. If you ran 200 variants and reported the best, the best one's apparent edge is largely a selection artefact — out of 200 random variants, some will look excellent. The honest summary is not "this config returned X", it is "the best of 200 configs returned X", which is a far weaker claim. Record the count.
• Run the whole thing on the other index. A NIFTY strategy that collapses entirely on SENSEX is telling you something about the fit, not about the index.
• Re-run with the cost model doubled. Not because costs will double, but to see how much of the result is margin and how much is noise.
• Shuffle the day order and re-derive the drawdown. The specific sequence of your sample's days is one draw. Reordering them gives you a sense of how much worse the drawdown could plausibly have been.
• Check for look-ahead in the rules. Any rule that references a candle's close while claiming to act inside that candle, uses the day's high or low, or picks a strike using information from later in the session, is using the future. This bug is easy to write and produces spectacular results, which is why it often goes unexamined.

Our own experience of doing this properly is the strongest argument for it. When we built an engine to test a widely recommended idea — take a technical indicator signal on the index and sell options against it rather than buying them — and ran it across 438 trading days, the short strangle version lost on the order of ₹499 per lot per day at zero slippage. The defined-risk version of the same idea lost more, not less. Across eighteen structure-and-parameter combinations, none passed our acceptance gate. That is what a real research outcome usually looks like, and the value of the method is that it produced that answer in software rather than in the market. We publish the fuller account in is algorithmic trading profitable — our own data.

Step 7 — Paper trade it before it sees capital

A completed backtest has told you about the rules. It has told you nothing about execution — whether the order sequence is placeable in the time available, whether your strike-selection rule resolves ambiguously in live data, whether the fills resemble your slippage model, whether the whole thing works on a day the broker's platform is slow.

Paper trade long enough to include a bad week. Not a bad day — a week where the strategy is in drawdown and you have to keep following it. Then compare the paper fills against the backtest's assumed fills, leg by leg. A systematic gap in one direction is your slippage model being wrong, and now you can correct it with measurement instead of judgement. We cover doing this so the results actually mean something in paper trading an option-selling algo.

The India-specific constraints a correct method has to encode

These are not optional refinements. Each one silently invalidates results if the method ignores it, and each is a method requirement rather than a platform feature — though whether your platform handles them is a fair question to ask of it, which is what the twelve-point checklist on our backtesting software guide is for.

• Lot size is not constant through history. Lot sizes are revised, so a rupee P&L computed with today's lot size across an older period is simply the wrong number. Either hold quantity in lots and convert per contract period, or restrict the sample to one lot-size regime and say so.
• Expiry weekday is per-index and it has moved. A backtest that assumes a fixed expiry weekday across a multi-year window will place trades on wrong days, and an expiry-day strategy tested on non-expiry days is measuring something else entirely. Verify the trade dates in your output against the actual expiry calendar for that index in that period — this is a two-minute check on an exported trade log and it catches a surprising number of broken runs.
• Settlement is a closing-window calculation, not the last traded price. Any rule that holds to expiry must settle against the correct basis or its expiry-day results are wrong by whatever the gap was. The mechanism is in the closing auction session and expiry settlement.
• Holidays and special sessions. Trading holidays, muhurat sessions and shortened days all need handling explicitly, because the default behaviour of most engines on an unexpected session is not what you want.
• The statutory cost base changes. Covered in step 3, repeated here because it is a sample-period issue as much as a cost issue.
• Regime breaks. The volatility character of Indian index options changed materially across 2024 and 2025. A long window spanning that break reports an average of two different markets, and the average describes neither.

What a backtest can never tell you

Worth stating plainly, because the method's value depends on knowing its boundary.

• Whether the future resembles the sample. Every backtest result is conditional on the market continuing to behave as it did. Nothing in the method addresses that, and no amount of data length fixes it.
• Whether you will actually follow the rules. The backtest assumes perfect discipline through the worst drawdown in the sample. That assumption fails in practice more often than any technical assumption on this page.
• What the tail looks like beyond your sample. Your worst day is the worst day that happened to occur in your window. A worse one exists. For a short-gamma position, that is not a philosophical point — it is the position's defining risk. See what the Greeks actually measure for why the loss is convex rather than linear.
• Whether the result is real or selection. If you tested many variants, the method can bound this but cannot resolve it. Only forward results can.
• Anything about capacity. A backtest fills whatever size you specify. The market may not.

Which is why the honest claim at the end of a good backtest is narrow: these specific rules, over these specific days, with these specific cost assumptions, produced this distribution of outcomes. Every word of that sentence is load-bearing, and anything broader than it is not supported by the exercise.

A compact checklist for the whole method

1. Rules written to the point where a stranger could execute them, with edge cases covered and no 9:15 entries.
2. Data finer than your fastest rule, captured rather than reconstructed, with bid/ask if you model execution.
3. Full cost stack: brokerage per leg per order, current statutory charges with the date recorded, slippage per leg with stop exits penalised, margin accounted for.
4. Sample split by contiguous time, both halves containing multiple regimes, held-out portion untouched.
5. Results read as a distribution — worst ten days, average win versus average loss, drawdown depth and duration, results by regime, trade count per bucket.
6. Robustness: every parameter perturbed, configuration count recorded, other index tested, cost model doubled, look-ahead audited.
7. Lot size, expiry calendar, settlement basis and holiday handling verified against the exported trade log.
8. Paper traded through at least one bad week, with paper fills compared against modelled fills leg by leg.
9. The final claim written in the narrow form, with the sample, the costs and the configuration count stated.

Frequently Asked Questions

The Bottom Line

Backtesting a trading strategy is a falsification exercise, not a confirmation exercise, and the method is built around that. Specify the rules until no judgement remains at execution time. Use data finer than your fastest rule, captured from real trades rather than reconstructed, with bid and ask if you intend to model fills. Build the full cost stack — brokerage per leg, current statutory charges taken from the source on the day, and slippage modelled per leg with stop exits penalised harder than planned exits — then find the slippage level at which the strategy stops working and ask whether that level is plausible. Split the sample by contiguous time before you look at anything, make sure both halves span several volatility regimes, and take exactly one look at the held-out portion. Read the output as a distribution: the worst ten days, average win against average loss, drawdown depth and duration, results by regime, and the trade count behind every slice. Then try to break it — perturb every parameter, record how many configurations you tested, run it on the other index, double the costs, audit for look-ahead. Encode the Indian constraints that quietly invalidate results: lot sizes change, expiry weekday is per-index and has moved, settlement is a closing-window calculation, and the statutory cost base was revised. Finally, paper trade through a bad week and compare real fills against modelled ones. What you get at the end is a narrow, honest claim about specific rules over specific days at specific costs — which is the most a backtest can give you, and far more than most of them do.

This article is for educational and informational purposes only and does not constitute investment advice. EliteAlgo is proprietary trading research and analytical software; it is not a SEBI-registered investment adviser and does not provide investment advice, strike or strategy recommendations, or trading tips. No strategy, strike, expiry, structure, platform or data vendor mentioned or implied above is recommended. Backtested results are hypothetical, carry inherent limitations including the benefit of hindsight, and do not represent actual trading. Logged and backtested results described above are what our own data did over specific samples; they do not guarantee future outcomes and imply no expected return. Brokerage, statutory charges, securities transaction tax, lot sizes, margin requirements, expiry calendars and settlement procedures are set by the exchanges, SEBI, the government and your broker and are revised from time to time — take all current figures from the source before relying on them. Selling options involves substantial risk of loss and is not suitable for all investors. Paper trade before deploying live capital and consult a SEBI-registered investment advisor before trading derivatives.