Backtesting is how traders test an AI trading bot on historical data before risking real money. Done well, it reveals weaknesses, realistic drawdowns, and whether a strategy even deserves live testing. Done badly, it produces a beautiful equity curve that collapses on the first live week. Most backtesting failures are not coding errors; they are quiet assumptions that flatter the past. Learning to spot them saves both capital and false confidence.

Overfitting happens when you adjust indicators, parameters, and filters until the strategy looks perfect on one historical period. With enough tweaks, almost any dataset can be made to show profits in hindsight. The problem is that the tuned rules often capture random quirks of that period, not a durable market edge. When conditions change, the overfitted strategy has nothing real to fall back on and performance drops sharply.

A simple defence is to split your data. Develop the strategy on one period, then test it untouched on a later, out-of-sample period. If performance falls apart out of sample, the strategy was likely overfitted. Limit the number of parameters, prefer simple rules you can explain, and be suspicious of any backtest that shows almost no losing months. Real strategies lose regularly; a curve without drawdowns is usually a warning, not a triumph.

Many backtests assume you always buy at the exact signal price with no fees, no spread, and no slippage. Real trading is messier. Exchanges charge fees on every trade, spreads widen during volatility, and fast markets fill orders worse than expected. A strategy that trades frequently can look profitable before costs and unprofitable after them, especially on small timeframes where each trade targets only a tiny move.

To avoid this mistake, include realistic fees, spreads, and a slippage estimate in every backtest, and test sensitivity: what happens if costs are twenty or fifty percent higher than assumed? Also check trading frequency and holding time. If the strategy depends on dozens of trades a day to scrape small gains, execution quality will dominate results. A robust strategy should still make sense after costs, not only before them.

Look-ahead bias creeps in when a backtest accidentally uses information that was not available at the time of the trade, such as revised economic data, a future closing price, or an indicator calculated with later bars. Even a small leak can inflate results dramatically. Survivorship bias is similar: testing only on assets that survived to today ignores delisted coins, failed stocks, or pairs that stopped trading, making the past look safer than it was.

Cherry-picking periods is the most human version of the same error. Reporting only a strong bull year, or starting the test just after a crash, flatters the strategy. A credible backtest covers multiple years, includes bear markets, sideways markets, and volatile shocks, and reports the full period without quietly dropping bad months. If a vendor shows only a short, perfect window, ask for the longer history and the losing periods too.

A stronger approach is walk-forward testing: optimise on one window, test on the next unseen window, then roll forward and repeat. This mimics real life, where you must trade the future without knowing it. Also stress-test the strategy: what happens during a flash crash, a news spike, or a long sideways grind? A strategy that only works in one regime is a conditional tool, not a general solution, and should be used only when that regime is present.

Even a clean backtest is not the final step. Paper-trade the bot in live conditions for several weeks, comparing its fills, fees, and timing to the backtest. Watch for missed signals, delayed orders, and API issues that never appeared historically. Only then consider a small live test with strict risk limits. Remember the core warning: backtests do not guarantee live results. They are a filter for bad ideas, not a promise of future profit.