KabuForge
Menu
GitHub日本語

What Is Backtesting? What Historical Tests Can and Cannot Tell You

Backtesting applies trading rules to historical data. Learn how to read orders, simulated fills and skipped orders, and understand the assumptions behind the results using a public KabuForge example.

What backtesting means

Backtesting means applying predefined trading rules to historical market data to examine their simulated results. It lets you study an equity curve and transaction records for rules such as ‘buy when this condition holds, and sell when that condition holds.’

Its value extends beyond a profit figure. When did losses grow? Was trading too frequent? Could the intended orders fill under the chosen assumptions? You can investigate these questions before putting real money at risk. See quantitative research and backtesting basics for the broader context.

The same rules can produce different results under different assumptions

Results depend on more than the trading rules. They also depend on the data, securities, test period, execution prices and treatment of costs.

For example, assuming that an order based on the closing price also fills at that same close can create an unrealistic sequence of decisions and execution. Specify what information was available when the decision was made, and which later price is used for execution. See data availability and look-ahead bias.

Deducting fees changes the result too. Frequent trading makes accumulated costs especially important. Transaction costs and turnover are basic assumptions to check when interpreting performance.

An order is different from a simulated fill

KabuForge’s public research course includes an example that selects securities using past price changes. A numerical representation of a security characteristic is called a factor. In the course’s price-momentum reference run, 1,464 observed sessions produced 161 filled orders and 22 skipped orders.

These counts belong to the specific input data and settings used in that example. A different period or configuration need not produce the same counts.

RecordMeaning
OrderAn instruction to buy or sell generated by the rules.
Filled orderAn order treated as executed under the test’s price and execution assumptions.
Skipped orderAn order that was not executed because a condition such as available cash was not satisfied.

The example fixes the quantity using the previous observed session’s close, then checks execution at the next observed session’s open. If an opening price increase makes the purchase unaffordable, the entire order is skipped rather than resized.

A skipped order is part of the result. An equity curve alone cannot explain why a planned trade did not occur.

161 filled orders does not mean 161 completed round-trip trades. Buy and sell orders are recorded separately. Counting a purchase and its subsequent sale as one completed trade is a different measure.

Read losses and transaction records alongside returns

Even if the ending account value is higher, a large decline along the way may make the same approach difficult to maintain. Drawdown, the decline from a previous peak in account value, helps reveal losses that a final return figure can hide.

A useful reading order is to check the input data and settings first, then orders and fills, and then the equity curve and loss measures. When something looks unexpected, inspect the records for the relevant date rather than guessing from the chart. The report-reading tutorial explains the screens.

What a backtest cannot establish

Good historical results do not prove that future results will be similar. Repeatedly changing settings after viewing the results can lead to rules that fit only the historical sample. This is a problem of overfitting and testing on periods not used during development.

The public example also has limitations. It does not model dividends, slippage, market impact or 100-share trading-lot constraints. It does not comprehensively guarantee when every input was historically available. Use it to learn how to read the interface and records.

Successful software execution and investment validity require separate checks. A completed run does not establish that trades in a real market would execute at the same prices or quantities.

Start your first test in KabuForge

Choose one public teaching example, save the input data and settings, and then run it. Keeping those inputs lets you check what was tested and compare results after changing a condition.

To explore the interface, start with the offline demo. To try a rule based on past price changes, follow the momentum and indicators tutorial. If you already have J-Quants data, use the J-Quants quickstart.

As a first goal, try to explain which data was used, which orders were generated and which prices were used for their fills, alongside whether the final result was positive.

Source: KabuForge’s GUI research courses. The counts above refer to the public price-momentum reference run.

This article is educational material about research procedures. It does not recommend particular securities or trades, or guarantee future returns. See the disclaimer.

Continue this topic

Explore the backtesting learning path

Applies to: main source candidate (unpublished) · Public source docs/en_US/GUI_RESEARCH_COURSES.md

Reviewed · KabuForge