Periscøpe
// Guide

Common backtesting mistakes

The mistakes that make a backtest look better than the strategy is, look-ahead bias, survivorship bias, overfitting, ignoring costs, and how to avoid each.

June 19, 2026

Most backtesting mistakes share a theme: they make a strategy look better than it really is. That’s what makes them dangerous: a bug that hurt your results, you’d catch; a bug that flatters them, you’ll happily ship. Here are the usual offenders.

Look-ahead bias

Using information the strategy wouldn’t have had at decision time, a value computed over the full series, a signal that peeks at the same bar’s close, data joined without respecting timing. It’s the most common way backtests lie, and it inflates results in ways that vanish the moment you trade live. Event-driven backtesting makes it structurally harder.

Survivorship bias

Testing only on instruments that still exist today. Companies that went bankrupt or were delisted drop out of the data, so a strategy looks safer than it was, and you never see the losers because they’re not in the dataset. Use data that includes delisted names where it matters.

Overfitting

Tuning parameters until the strategy fits the past beautifully. The result is a strategy optimized for history that hasn’t happened again rather than for any real pattern. The more parameters you tune and the more you tune them, the worse it gets. Hold out data, and be suspicious of strategies with many finely-tuned knobs.

Ignoring costs and slippage

Filling every order at the last printed price ignores the spread and slippage you’d really pay. Many “profitable” strategies are profitable only because they trade for free in the backtest. Model costs, and check whether the edge survives them.

Unrealistic fills and order types

Assuming you’d get filled at a price you wouldn’t, or that an order type behaves in the backtest as it would at a broker. Stops are a classic trap: a backtested stop may not reflect real fill behavior. Know what your engine actually models.

Calendar and session bugs

Trading when the market was closed, mishandling half-days, or ignoring futures expirations. These produce weird results that look like strategy quirks but are really data problems. Use real market calendars.

Too few trades

A spectacular return from a handful of trades is noise, not evidence. Make sure the result rests on enough trades to mean something before you believe it.

How to avoid all of this

Use an event-driven engine, model your costs, respect the calendar, hold out data you don’t tune on, and read the orders and fills, not just the equity curve. Periscøpe handles several of these for you: it’s event-driven, models spread and slippage, uses real market calendars, and records every order and fill so you can check that the result is real rather than an artifact of one of the traps above.

Related
// Access

Run one strategy through Periscøpe.

We onboard in focused cohorts. Tell us what you trade and how you work. Live access is rolled out to select users on request.

We only use your email to contact you about access.

Read the docs →