Compare bot versions.
Keep the test fair.

Disclosure: I develop MT5 and cTrader trading software at ExpertCodeFX.

A new version of a trading bot deserves a fresh evaluation. Even a small code change can alter which trades it accepts, how it handles orders or how much exposure it takes.

The useful question is specific: what changed, and what evidence would show whether that change did its job?

Write the purpose before running the test

Suppose a revision is intended to avoid a particular order rejection. Its first evaluation should examine that rejection and the surrounding order handling. A better profit total alone would not explain whether the problem was fixed.

For a change intended to reduce exposure, examine exposure and the trades affected. Fewer trades might be an expected consequence. It still needs to be reported so a reader can understand how the outcome was obtained.

Write down the intended improvement and what else you expect to stay consistent. This gives you something concrete to check when the results arrive.

Preserve the old version as a control

Keep the old executable, preset and report. Give the candidate its own name or version record. Avoid overwriting the only copy of the setup you are trying to compare against.

Record the test identity for both runs: platform, software build, preset, broker symbol and timeframe. Then record the dates, starting capital and other tester assumptions that affect the comparison.

The control should be rerun under the same intended conditions. An attractive report from a different period is useful history, but it does not isolate the effect of this revision.

Change one thing at a time where practical

If the code, preset, position size and test period all change together, a different result can have several explanations.

Start with matched inputs wherever the revision permits. If an input has changed meaning or is no longer available, describe that difference. Do not present an impossible match as an exact comparison.

After the basic comparison, additional experiments can examine a new feature or parameter. Keep those results separately named so a reader can follow which question each run answers.

Read the outcome alongside the behaviour

Build a small comparison table with net profit, maximum equity drawdown, trade count, costs and execution errors. Add recovery behaviour and any open exposure at the end of the test.

Then look at the trade history. Were trades removed by the new rule? Did position sizes change? Did the bot stop taking entries after a limit? Did an apparent improvement come from one unusually favourable period?

There may be a worthwhile tradeoff. A revision can reduce a particular risk while also reducing returns. Describe both observations rather than declaring a winner from one number.

Use evidence labels that match the work

“Compiled successfully” describes a build result. “Completed this historical comparison” describes a test. Neither statement establishes future profitability or proves that the system is ready for unattended real-money use.

If the candidate has passed only a local test, say so. If a comparison could not be completed, keep the result pending. Clear labels help someone else decide what evidence is still missing.

The goal is a review another person can follow: the same question, identifiable versions, controlled conditions and complete results.

For a companion checklist on reading the report, see ExpertCodeFX's EA and cBot backtest guide.

Trading involves risk. Historical comparisons do not guarantee future performance.

Continue your research

Keep a useful demo test journal · Read a backtest report · Compare MT5 EAs and cTrader cBots

Read the exact product documentation and current official Store listing before evaluating a package.