Module 6 · Lesson 3 of 17 · Risk, process, and mindset · About 6 minutes

Trading Plans, Journaling and Honest Backtesting

On this page
  1. What you will learn
  2. Why write anything down?
  3. What goes into a trading plan?
  4. What does a journal record?
  5. What is backtesting?
  6. How do backtests mislead?
  7. Out-of-sample diagram
  8. What does honest testing look like?
  9. What this does not tell you about a backtest
  10. Method in Practice
  11. Check yourself
  12. Reflect on your own process
  13. Sources

Before you read: Risk Management Arithmetic: Position Size, Risk-Reward, Drawdown

What you will learn

Why write anything down?

If you cannot describe your process in writing, how would you know whether you followed it?

Memory is a poor record. People tend to remember wins better than losses, recall their reasoning as clearer than it was, and adjust the story after the outcome is known. Writing things down before and after each decision is one simple defense against that. A plan states the process in advance; a journal records what actually happened; testing asks whether the idea holds up when examined honestly.

What goes into a trading plan?

What would someone need to know to follow your process exactly, without asking you?

A trading plan is a written description of how someone intends to trade. Its contents differ from person to person, but plans commonly cover:

  • Markets and hours: which products and which sessions.
  • Preparation: what is reviewed before a session, such as structure, levels and the economic calendar.
  • Conditions: the circumstances under which the trader considers acting, described precisely enough that someone else could check them.
  • Risk framing: how position size and the planned loss per trade are worked out (risk management arithmetic).
  • Order handling: which order types are used and how exits are managed.
  • Limits on activity: for example, conditions under which the trader stops for the day.
  • Review: when and how results and the plan itself are reviewed.

The value is not in any particular content. It is in making the process explicit enough to compare with what actually happened.

What does a journal record?

Six months from now, what would you want to know about today’s decisions?

A trading journal is a log of each decision, written at the time. Entries often include:

  • date, market, timeframe and session,
  • what was observed, in descriptive terms, before acting,
  • the planned entry, exit conditions and size,
  • what actually happened, including fills, slippage and costs,
  • whether the plan was followed, and if not, why,
  • a screenshot of the chart before and after, and
  • a line on mood or circumstances, such as fatigue or distraction (trading psychology).

Over time, a journal can make patterns visible: conditions where the plan is often broken, costs that were larger than assumed, or descriptions that turned out vague. The session replay lesson shows a descriptive way to review a session.

What is backtesting?

If an idea would have worked in the past, what has actually been shown?

Backtesting means applying a precisely defined set of rules to historical data to see what would have happened. Done carefully, it can show whether an idea is even coherent, how often its conditions occur and how sensitive it is to costs. It cannot show what will happen in the future. Every test result is hypothetical: no money was at risk, and the past may not resemble what comes next.

How do backtests mislead?

If you try enough ideas on the same data, will one of them look good by chance?

Five problems can open a gap between test results and real experience.

Overfitting. Adding rules and tuning settings until the results look good on past data. Each tweak fits the noise of that particular history a little more closely. The more parameters a rule set has, the easier this is to do without noticing.

Multiple testing. Testing many ideas, or many versions of one idea, and keeping the best. With enough attempts, some will look impressive purely by chance. Reporting only the winner hides how many losers were discarded. An honest account records how many variations were tried.

No out-of-sample check. Data used to develop an idea cannot also be used to judge it. Out-of-sample data is held back, untouched, until the rules are final. A common structure is to develop on one period and then test once on a later period. If the idea is adjusted after seeing the out-of-sample result, that data is no longer out of sample.

Ignored costs and fills. Commissions, fees, spread and slippage (trading sessions and costs) are certain and repeat with every trade. Tests that assume fills at exact prices, or ignore partial fills and gaps, overstate results, especially for ideas that trade often.

Survivorship bias. Testing only on instruments that still exist today, such as the current members of an index, leaves out the companies that were delisted or removed, often after falling sharply. The data has quietly been filtered toward winners.

Other common problems include look-ahead bias (using information in the test that would not have been available at the time, such as a day’s close to make a decision earlier that day) and data errors in the historical record.

Out-of-sample diagram

Development data vs. out-of-sample data. Timeline splitting older development data from newer out-of-sample data, with rules frozen at the split. Illustrative diagram constructed for teaching. Not real market data.

Illustrative diagram constructed for teaching. Not real market data.

The diagram shows a constructed timeline split into a development period and a later, untouched out-of-sample period, with a note that adjusting rules after seeing out-of-sample results turns it into development data. It is constructed for teaching and is not real market data.

What does honest testing look like?

What would you write down before you ran a test, so you could not change it afterwards?

Habits that make testing more honest:

  • Write the rules and the test design before looking at results.
  • Record every variation tried, not just the best.
  • Hold back out-of-sample data and use it once.
  • Include realistic costs and slippage from the start.
  • Treat any result as hypothetical, and expect real results to differ.

What this does not tell you about a backtest

  • What any plan should contain for a particular person.
  • That a well-tested idea will work in the future.
  • How to build or code a backtest on any platform.

Method in Practice: an honest backtest

Fictional example. John, Harbor Index futures, the prices, times, costs and results are all invented for teaching. This shows how a written plan can be built and tested. It is not a recommendation, and nothing here says how often this idea works.

Try it on a real chart. Test this idea yourself on past sessions with bar replay. Keep your own count, including the days with no trade.

The idea. The lesson lists habits that make a backtest honest: write the rules first, include costs, record every variation and keep data back. John runs his plan from Volume Profile Explained: POC, Value Area, HVN, LVN over 50 past sessions, and shows how the same trades look with and without costs, and per trade versus per session. These are the same 50 sessions as in the capstone lesson.

John's test design (written before testing)

Rules
The Volume Profile Explained: POC, Value Area, HVN, LVN lesson's plan, version 1 (no rule about how far below value the open is)
Sessions
1–50 that opened below the prior value area. 51–90 held back, unopened
Costs
$5 per contract, 1 tick of slippage on market and stop orders, from the start
Counted
every session, including no-trade days

Three outcomes (invented numbers: this shows how to count, not how the method performs)

  • Without costs: +$660 over 24 trades. Looks promising

  • With costs: +$40 over 24 trades, about +$1.67 per trade

  • Per session: 26 of 50 sessions had no trade. +$40 ÷ 50 = +$0.80 per session

Show the full workings
ItemAmountWorking
Commissions$24024 trades × 2 contracts × $5
Entry slippage$24024 market entries × 2 contracts × 1 tick ($5)
Exit slippage$14014 trades left by market or stop orders × 2 contracts × $5. Limit exits have none
Total costs$620
Result before costs+$660
Result after costs+$40+$660 − $620
Per trade+$1.67+$40 ÷ 24
Per session+$0.80+$40 ÷ 50

Journal: "Costs took $620 of $660. The idea isn't dead and it isn't proven. Next: small live size, and the 40 sessions I haven't opened."

Test it yourself

  • Add costs before the first run, not after you like the result.
  • Report results per session as well as per trade, so the no-trade days count.
  • Keep a list of every variation you try. Each one is another test.

Where it breaks

  • 24 trades is far too few to say anything about the future.
  • Even honest replays assume fills a live order might not get.
  • A small positive number can disappear with slightly higher costs.

Calculators: expectancy

Reflection question: Did your last backtest include costs from the first run, and does it count the days with no trade?

Check yourself

Reflect on these; there is no score.

  1. Name four items you would expect to find in a written trading plan. Hint: markets, preparation, risk framing, review.
  2. Why does testing many variations of one idea make the best result less trustworthy? Hint: chance.
  3. Your rules were tuned, tested out of sample, then tuned again. What is the out-of-sample period now? Hint: it has been used for development.
  4. Give an example of survivorship bias in a stock test. Hint: today’s index members.

Reflect on your own process

For your own notes; there is no score and no right answer.

  1. Before your last test, did you write down the rules and how many variations you planned to try?
  2. How does your journal record whether each decision followed your written plan, and why it did or did not?
  3. Which data in your own testing is held back as out-of-sample, and how would you know if it had been used?
  4. Did your last backtest include costs from the first run, and does it count the days with no trade?

Sources

Last reviewed . Spotted a mistake? Report an error.