How to backtest a trading strategy without code

What does a no-code backtest actually do?

A backtest applies a defined strategy to historical market data. At each bar, the test evaluates the information that would have been available at that moment, decides whether the rules permit an entry or exit, and records the resulting simulated trade.

A no-code backtesting platform changes how those rules are expressed. Instead of writing loops, indicator calculations, order objects, and reporting code, you connect visual blocks. The standard of evidence should remain the same: every condition must be explicit, each assumption must be visible, and the result must be inspectable beyond one headline return.

Step 1: write a falsifiable trading hypothesis

Start with one sentence that can be wrong. “Buy when the market looks strong” is not testable. A useful hypothesis names the market state, entry, exit, and the reason the behavior might persist.

Example structure: when a slow trend filter is positive and a faster signal confirms momentum, enter on the next eligible bar; exit when momentum reverses or the risk rule is reached.

This is deliberately a structure, not a recommended strategy. The parameters and market must come from your own research. Writing the hypothesis first makes it harder to keep changing rules until a historical chart produces an attractive number.

Step 2: translate the idea into visual blocks

A readable graph usually separates five responsibilities:

1. Data inputs: symbol, timeframe, and historical OHLCV bars.
2. Indicators: calculations derived from information available at each bar.
3. Filters: conditions that define when the strategy is allowed to act.
4. Entry and exit rules: exact boolean decisions, including evaluation timing.
5. Risk and sizing: how simulated exposure and exits are constrained.

Connect the blocks so data flows in one direction and each decision can be read without guessing. Name important nodes by intent, such as “slow trend positive,” rather than by a generic label such as “comparison 3.” A visual builder is most valuable when another person can audit the graph.

For more on graph structure, read thevisual crypto strategy builder guide.

Step 3: choose the market, timeframe, and test window

The data window determines what conditions the strategy experiences. A short interval from one market regime can make a fragile rule look stable. Prefer a window that includes materially different conditions: sustained trends, ranges, fast reversals, calm periods, and stress where reliable data is available.

• Confirm that timestamps and time zones are consistent.
• Check for missing, duplicated, or obviously corrupt bars.
• Avoid selecting the window because you already know it contains a favorable move.
• Keep a later period untouched for out-of-sample validation.
• Use only assets and venues whose historical data matches the intended research question.

More data is not automatically better. Data from a market structure that no longer resembles the intended test can add false confidence. Record why the selected period is representative.

Step 4: state execution and cost assumptions

A strategy does not trade at an abstract chart price. Define when a signal is observed, which later price can be used for the simulated fill, and which costs are included. Never let a rule read a bar’s close and pretend it filled earlier on the same bar.

At minimum, document fees, spread assumptions, slippage assumptions, order type, position sizing, and treatment of partial fills. If the backtester does not model one of these, mark the omission beside the result.

Koval’s current backtest model includes explicit fees but does not model slippage, spread, or partial fills. That makes the result an optimistic bound, not an execution forecast. Theaccuracy guide explains how those gaps affect interpretation.

Step 5: run a baseline before optimising

Run the simplest version that represents the original hypothesis. Save its configuration and treat it as the baseline. If the idea fails plainly, investigate why before adding exceptions. Additional blocks should correspond to a defensible market hypothesis, not merely repair an unattractive period.

Keep a small experiment ledger: hypothesis, change, expected effect, actual effect, and decision. This prevents circular tuning and makes later comparisons meaningful.

Step 6: inspect the trade ledger, not just the summary

Aggregate return can hide a strategy that depended on one unusual trade, suffered intolerable drawdowns, or stopped working during most regimes. Review the individual simulated fills and ask:

• Did each entry occur only after all required information existed?
• Do exits match the graph, including conflicts between multiple exit rules?
• Is performance dominated by a few trades or one asset?
• How long are losing sequences and underwater periods?
• Does turnover make the result unusually sensitive to omitted execution costs?
• Are any trades impossible because of missing liquidity or bar-level ambiguity?

Koval is designed to expose every bar, fill, and fee behind a run. Use that detail to debug logic and challenge the benchmark rather than treating the report as a score.

Step 7: challenge robustness

A strategy deserves more attention only after it survives tests designed to make it fail.

1. Out-of-sample period: freeze the rules and evaluate data that was not used to design them.
2. Neighboring parameters: small input changes should not collapse the entire result.
3. Different regimes: identify where the logic works, fails, or stays inactive.
4. Harsher costs: recalculate expectations with less favorable execution assumptions.
5. Operational delay: consider what happens if decisions or fills occur later than the idealised model.

Robustness does not prove future profitability. It reduces the chance that the visible result is only an artefact of one parameter, one period, or a hidden assumption.

Step 8: move forward one evidence level at a time

A historical backtest cannot test live scheduling, incoming data behavior, persistent state, or exchange API semantics. The next step is paper trading, followed by supported exchange sandbox execution when the strategy needs that integration check.

Learn exactly what changes between these stages inbacktesting vs paper trading vs sandbox trading. Koval intentionally stops at these testing environments and does not place real-money orders.

No-code backtesting checklist

• The hypothesis was written before optimisation.
• Every rule has one unambiguous visual representation.
• The graph uses no information from the future.
• Data scope and quality checks are recorded.
• Fees and every omitted execution cost are visible.
• The trade ledger matches the intended logic.
• An out-of-sample period remains untouched until rules are frozen.
• Parameter and regime sensitivity have been reviewed.
• The result is described as hypothetical, not predicted performance.
• A paper or sandbox validation plan exists before any stronger conclusion.