Guides

How to Manually Backtest a Trading Strategy

Manual backtesting is how most discretionary traders actually validate a setup — no code, no chart-replay software, just a disciplined process of logging what happened and being honest about the results. Here's how to do it properly.

Stratlog Guides · Backtesting

If you trade based on judgment — reading price action, session timing, confluence between a few conditions — an automated backtest usually can't replicate what you're actually looking for. Manual backtesting fills that gap: you go through historical charts, mark down every time your setup occurred, and record what happened next. It's slower than running a script, but it's the only reliable way to test a rule you can't fully express in code.

Done properly, it tells you something an automated backtest never can: whether you, with your specific judgment calls, actually have an edge. Done sloppily, it tells you whatever you wanted to hear. The difference between the two comes down to process — which is what this guide is actually about.

What manual backtesting actually is

At its core, manual backtesting is a repeated loop: define a condition, find every historical instance of it, record the outcome, and calculate how often it worked. Do that enough times across enough instances, and you get a real number — a win rate grounded in what actually happened, not what you remember happening.

That last part matters more than people expect. Human memory is a poor backtesting engine. Traders tend to vividly remember the setups that worked and quietly forget the ones that didn't — which is exactly why a written, systematic log beats "I've noticed this pattern works" every time.

The process, step by step

Define your setup precisely

Write down the exact conditions that make up your setup before you start looking at charts — not while you're looking at them. If your rule is "FVG during London session," decide right now what counts as a valid FVG and what counts as London session. Vague rules produce vague results, because you'll unconsciously bend the definition to fit whatever chart you're looking at.

Pick a representative sample

Choose a date range and instrument before you start, and stick to it. A common mistake is testing until you hit a good win rate, then stopping — which quietly turns a backtest into a search for a story that confirms what you already believed. Decide the sample size and time period in advance, and test the whole thing.

Log every occurrence — not just the wins

This is where most manual backtests quietly fall apart. It's easy to note the setups that led to a clean win and skip past the ones that didn't quite work, especially if they're less satisfying to look at. Log every single time your conditions were met, win or lose, in the order you find them.

Decide "win" before you see the outcome

Define what counts as a win — a fixed R multiple, a specific target, whatever fits your style — before you look at what actually happened on that chart. If you decide after the fact, you'll unconsciously calibrate the definition to make more setups count as wins.

Calculate the real win rate

Once you've logged every occurrence honestly, the math is simple: wins divided by total occurrences. The number itself is less important than what you do with it — a genuinely low win rate is just as useful a finding as a high one, because it tells you where not to put real money.

Common mistakes that quietly invalidate a backtest

✕Cherry-picking the sample. Scrolling until you find a chart that looks like a clean example, rather than testing every instance in a fixed window, produces a number that reflects your search process, not your edge.
✕Changing the rules mid-test. If your definition of the setup shifts halfway through because early results looked weak, the back half and front half of your data aren't actually testing the same thing anymore.
✕Too small a sample. A handful of instances can look like a strong pattern by pure chance. Treat anything under roughly 30–50 occurrences as a preliminary signal, not a conclusion.
✕Not tracking occurrences you skipped. If you only log the trades you'd have actually taken, you lose the ability to calculate a true win rate — you need the full occurrence count, not just the subset you liked.

Why this is worth doing manually, not just automating

Algorithmic backtesting is faster, but it can only test what can be precisely coded — and a lot of real discretionary trading involves judgment calls that don't reduce cleanly to code: "does this look like a clean order block," "is this actually London session momentum or just noise." If your edge lives in that kind of judgment, an automated backtest is testing a different, cruder strategy than the one you actually trade.

Manual backtesting is slower, but it tests the strategy you actually use — including the parts of it that live in your judgment, not just the parts that fit neatly into a script.

Keeping the process actually consistent

The biggest practical failure point in manual backtesting isn't the concept — it's consistency. Spreadsheets get abandoned, notes get lost across different charting sessions, and without a structured place to log every occurrence the same way every time, most people's "backtest" ends up being a loose collection of the setups that happened to feel notable. Whatever you use — a plain spreadsheet or a dedicated tool — the thing that actually matters is logging every occurrence, in the same format, every time.

That consistency problem is specifically what STRATLOG is built to solve: a structured way to log conditions row by row, combine them into named patterns, and see your real win rate calculated directly from what you've actually logged — not what you remember.