How to backtest a trading strategy without writing code
A backtest replays your rules on past candles to show what they would have done. The method, step by step, in plain words: no code and no spreadsheet.
- Written by
- The EdgeLuma team
- Published
- Reading time
- 8 min
On this page
- What does it mean to backtest a strategy?
- Step 1: say the idea the way you would say it to a friend
- Step 2: make every rule testable
- Step 3: choose the market, the timeframe and the period
- Step 4: put the real costs in
- Step 5: run it, and read the right numbers
- Step 6: change one thing, then check where you never tuned
- What a backtest cannot tell you
- Frequently asked questions
- Sources
Backtesting is the replay of a trading strategy’s rules on historical market data, to see what those rules would have done: which trades they would have taken, what each one would have cost, and how the account would have moved. It does not predict the next candle. It answers a narrower question, and an honest one: did this idea ever work, with the costs a real trader pays?
For most traders the hard part is not the idea. It is the tooling: a backtest has usually meant writing code, or scrolling a chart candle by candle with a spreadsheet open beside it. This guide is the method itself, in the order you would follow it, in plain words. The steps hold whatever tool you use; where it helps, we say how EdgeLuma handles them.
What does it mean to backtest a strategy?
To backtest a strategy is to apply its rules, exactly as written, to every candle of a past period, and to record each trade they would have opened and closed. The output is a list of trades and the numbers that summarise them: how many there were, how much each one made or lost, how deep the worst losing stretch went.
Three things decide whether that output is worth reading:
- Rules precise enough to replay. Two people following them on the same chart would take the same trades.
- Data from the market you will trade. The same coin as a spot pair and as a perpetual is two markets, with two fee schedules.
- The costs that market charges. A fee on the way in and on the way out, and the slippage of every fill that takes liquidity.
Get any of the three wrong and the backtest still prints a result. It is just the result of something else.
Step 1: say the idea the way you would say it to a friend
Start with the sentence, not with the settings:
I buy BTC/USDT Perp on the 1h when price closes above the last swing high, with a stop under the swing low and a target at twice the risk.
That sentence is already most of a system. It names a market, a timeframe, an entry, a stop and a target. What it does not say yet matters just as much, and finding it is the next step.
Step 2: make every rule testable
Every testable idea answers the same handful of questions. Writing the answers down is most of the work, and each one is a decision about your strategy, not a technical detail.
| Part | The question it answers | In the example |
|---|---|---|
| Market and timeframe | Where, and on which candles? | BTC/USDT Perp, 1h |
| Entry | What has to happen, and how do you get in? | A close above the last swing high, then a market order |
| Stop | Where is the idea wrong? | Below the swing low that formed the setup |
| Exit | Where do you take the profit, or give up? | A target at twice the risk |
| Size | How much do you risk on one trade? | A fixed share of the account, such as 1% |
| Costs | What does the venue charge? | Its maker and taker fees, plus slippage |
Vague words are where a backtest goes wrong without telling you. “A strong breakout”, “a pullback”, “close to the level”: each one hides a number you have not chosen. A tool can choose it for you, silently, and the result will then be the result of its choice, not of your idea.
In EdgeLuma, the System Builder asks instead of guessing: when a description leaves something open, Luma asks which reading you mean rather than picking one for you, and shows the rules in plain words before anything is saved.
Step 3: choose the market, the timeframe and the period
The market is the one you will trade, named exactly. BTC/USDT Perp and BTC/USDT Spot share a price chart but not their fees, their order books or their funding.
The timeframe follows from the rules, not the other way round. A rule about the daily trend, tested on one-minute candles, is a different rule.
The period should be as long as the data allows, and it should contain more than one kind of market: rising, falling, and going nowhere. A strategy tested only during a rally has been tested in one kind of weather.
What matters most is not the number of years but the number of trades. With ten or twenty trades, a result is mostly luck, however good it looks. As a rule of thumb, an average measured over about a hundred trades starts to mean something.
Step 4: put the real costs in
Every trade pays a fee to get in and another to get out, and a fill that takes liquidity from the order book usually pays a little slippage on top. On a system that trades often for small gains, those costs can be the whole difference between an edge and a slow leak. We wrote a separate guide on what fees and slippage do to a backtest.
On an exchange preset, EdgeLuma charges the venue’s own published maker and taker fees for its entry tier, checked on the venue’s pages and dated, plus slippage on every fill that takes liquidity: half the venue’s price tick, and a book impact that grows with the size of the position. You can also enter your own fees, or run the same system with no costs at all to see exactly what the costs take.
Step 5: run it, and read the right numbers
The total is the number everybody reads first, and it is the one that says the least. Results are clearer in R. 1R is the money risked on one trade: the distance from the entry to the stop, times the size. A trade that makes twice its risk is +2R; a trade stopped at its initial stop is −1R. Counting in R makes runs comparable at any account size and on any market.
Read these, in this order:
- The number of trades. It is the size of the sample, and it limits what every other number can mean.
- The expectancy. The average result of one trade, in R, costs included. Positive means the rules made money on average; negative means they lost, however good some trades felt.
- The win rate, beside the payoff. A low win rate is not bad by itself when the winners are much bigger than the losers. Read the two together.
- The max drawdown. The deepest fall from a peak: the worst stretch you would have had to sit through.
- The longest losing streak. The run of losses in a row you must be ready to live with, in money and in nerves.
- The trades themselves. Open them. One lucky trade can make a whole curve, and only the list shows it.
Step 6: change one thing, then check where you never tuned
Every change you make after seeing a result is a decision taken with the answer in your hand. Make enough of them and the rules will fit the past perfectly, and the past is the one market you will never trade again.
Two habits keep the test honest:
- Change one rule at a time, and write down why before you run it.
- Keep the last part of the history aside. Tune on the first part. When you are done, run the final rules once on the part you never looked at. If the edge only exists where you tuned it, it was the period, not the edge.
There is a whole body of research on how easily a backtest can be overfit, and on how to tell an edge from a lucky curve.12 We summarised it in our guide to backtest overfitting.
What a backtest cannot tell you
A backtest replays the past. It cannot know the next candle, and nothing in a report is a forecast or financial advice. What it can do is stop you from risking real money on an idea that never worked, and show you, before you trade it, how an idea that did work behaved while it was losing.
Frequently asked questions
Can you backtest a trading strategy without coding?
Yes. A backtest needs three things: rules precise enough to be replayed, historical candles for the market you trade, and that market’s costs. A tool that turns a plain-words description into rules does the work code used to do. What no tool should do is decide on its own what your vague words meant; a good one asks.
How many trades does a backtest need?
There is no exact number, but the fewer the trades, the more of the result is luck. Over ten or twenty trades, even a strong average says little. Over about a hundred, spread across rising, falling and flat markets, it starts to mean something.
How much historical data should I use?
As much as the market has, as long as it covers more than one kind of market. Years of history that produce a handful of trades can say less than a few months that produce hundreds.
Sources
- The Probability of Backtest OverfittingDavid H. Bailey, Jonathan M. Borwein, Marcos López de Prado and Qiji Jim Zhu, Journal of Computational Finance
- BacktestingCampbell R. Harvey and Yan Liu, The Journal of Portfolio Management, 2015

