Backtest vs Live Trading: What really changes when an EA goes live?

Backtest vs Live Trading: What really changes when an EA goes live?

11 September 2026, 15:11
Maksym Viunik
0
37

Why a profitable backtest is only the beginning of the testing process

You have a profitable backtest. 📈

✅ The drawdown looks reasonable.
✅ The equity curve looks good.
✅ The number of trades is large enough.
✅ The strategy appears to work across several years of historical data.

So, is the Expert Advisor ready for live trading? 🤔

‼️Not necessarily.‼️

In fact, I think this is one of the most important questions in automated trading.

A good backtest is necessary. But after many years of developing and running automated Forex systems, I have become increasingly convinced that a backtest should be viewed as the beginning of the validation process, not the end of it.

In my previous articles, I discussed why an automated trading system should be viewed as more than just an Expert Advisor, how we approach currency-pair selection, and why the broker and execution environment can have a significant impact on live performance.

Now I want to take the next step.

What actually happens between a promising backtest and a real trading account?

A backtest answers only one part of the question

The MetaTrader Strategy Tester is an extremely useful development tool.

It allows us to run an Expert Advisor against historical market data, analyze its behavior and test different parameters. It also provides forward-testing and optimization functionality specifically designed to reduce the risk of simply fitting the strategy to historical data.

But there is an important distinction.

A backtest essentially asks: "Could this strategy have worked under these historical conditions?"

Live trading asks a different question: "Does this strategy still behave as expected when we don't know what happens next?"

Those are not the same question.

And this difference becomes particularly important when dealing with short-term automated strategies.

A historical test can tell us a lot about the logic of a strategy.

It cannot tell us everything about its future execution.


Stage 1 — Backtesting

This is where most automated strategies begin.

We take a set of trading rules and test how they would have behaved over historical data. At this stage, I am not particularly interested in finding the highest possible return.

That may sound strange.

If you are developing a trading robot, why wouldn't you want to find the most profitable settings?

Because the highest historical return is often not the most useful result.

A backtest should help answer questions such as:

  • Does the basic trading idea have statistical potential?
  • How frequently does the strategy trade?
  • How does it behave during different market periods?
  • What is the historical drawdown?
  • Are there long periods without meaningful performance?
  • Does the strategy depend on one particular period?
  • Does it remain reasonably stable when conditions change?

This is much more useful than simply looking for the largest percentage return. The Strategy Tester is very good at answering these questions. But there is also a danger. You can ask it to search through a huge number of parameter combinations. And eventually, something will probably look very good. That does not automatically mean you have discovered a robust strategy. You may simply have discovered a very good explanation of the past.


Stage 2 — Robustness testing

This is where things start getting more interesting.

Once we have a potentially viable strategy, we need to find out how dependent the result is on the exact assumptions we used.

For example:

🔸 What happens if a parameter is changed slightly?

🔸 What happens if the spread is somewhat higher?

🔸 What happens if execution is slower?

🔸 What happens if the strategy starts trading in a slightly different period?

🔸 What happens if we remove part of the historical data?

🔸 What happens if the market behaves differently from the period used for optimization?

A robust strategy should not completely collapse because one parameter changes by a small amount.

That doesn't mean every parameter should produce identical results.

It means we want to understand the stability of the strategy, rather than simply finding one perfect combination.

This is one of the reasons why I am generally more interested in a reasonable area of stable results than in a single "best" result.

A smooth landscape is usually more interesting than one very high peak.


Stage 3 — Forward testing

This is probably one of the most important steps.

A forward test gives the strategy data that was not used to optimize it. The basic idea is simple. We use one period for development and optimization. Then we take the resulting strategy and test it on another period.

The second period is effectively asking: "Does the strategy still make sense when we stop giving it the answers?"

MetaTrader has a built-in forward-testing function for exactly this reason. The platform separates the historical period into optimization and forward sections, allowing the selected parameters to be checked on a later period that was not used for the original optimization.

This is important because a strategy can look excellent when it has effectively been "taught" the historical data. But the market does not provide the next dataset in advance.

That is the real challenge.


A useful way to think about it

I sometimes think about the testing process like this:

🔹 Backtest: Could the idea have worked?

🔹 Robustness testing: Does it survive reasonable changes?

🔹 Forward testing: Does it continue to work on data it has not seen?

🔹 Live testing: Does it behave correctly in the real market?

🔹 Long-term monitoring: Does the underlying logic remain relevant as market conditions change?

Each stage answers a different question.

And skipping one of them can create a false sense of confidence.


Stage 4 — The execution environment

This is where my previous article becomes directly relevant.

A strategy can pass historical testing and forward testing and still behave differently when it goes live.

Why? Because now we introduce the actual trading environment.

The EA has to deal with:

  • real spreads;
  • real commissions;
  • real liquidity;
  • real slippage;
  • real execution;
  • a particular broker;
  • a particular account type;
  • a particular server;
  • a particular VPS;
  • and actual market conditions.

This is why I increasingly think of the following combination as one system:

EA + currency pair + trading hours + broker + execution conditions

rather than treating each component separately.

I discussed this in more detail in my previous article, [Why a Good Forex EA Can Become a Bad EA at the Wrong Broker].

For short-term strategies, the difference can be particularly important. The Strategy Tester can simulate many aspects of the trading environment, including execution delays, but the real market will always introduce variables that cannot be known with certainty in advance. That is why live observation remains essential.


Stage 5 — The first live trades are still a test

I don't consider the transition from demo to live to be a magical moment when testing suddenly ends.

Quite the opposite.

The first live trades are another stage of testing.

At this point, I want to compare what we expected with what actually happens.

For example:

  • Are trades appearing with approximately the expected frequency?
  • Are spreads during the trading window consistent with expectations?
  • Is slippage reasonable?
  • Are entries and exits behaving as expected?
  • Are there unexpected execution problems?
  • Is the strategy opening trades under the same types of market conditions?
  • Does the real drawdown behave within a reasonable range?

This is where the difference between software testing and trading-system testing becomes very clear. An EA can be technically correct and still produce unexpected live results. The code may be doing exactly what it was programmed to do. The problem may simply be that the real environment is different from the assumptions used during development.


This is where long-term data becomes valuable

One of the biggest lessons we have learned over the years is that a single good month doesn't prove much.

The same is true for a single bad month.

Automated strategies go through different market environments.

There can be periods with:

  • many trading opportunities;
  • very few opportunities;
  • strong performance;
  • flat performance;
  • and drawdown.

The important question is not whether every month is profitable.

The more interesting question is whether the strategy continues to behave within the range that we consider acceptable over a sufficiently long period.

This is also why I prefer looking at long-term live history rather than focusing on one impressive backtest. A backtest can be optimized. A long live history is much harder to manufacture.


A practical example from our own development

The process described above is not theoretical for us.

It is essentially how we developed the technology behind our own SCR_NightScalper Expert Advisor. The goal was never simply to create an EA that produced an attractive historical equity curve.

The more difficult task was to find a combination of:

strategy + instruments + trading conditions + execution environment + risk management

that could continue to be monitored and evaluated over a long period of time.

The resulting technology became the foundation for our SCR_EURAUD system and later for the more diversified SCR_EURAUD_advanced approach.

But even after reaching that stage, the development process did not stop. We continue to test different instruments, execution environments and possible improvements. Some ideas look promising in historical data and do not survive further testing. Others survive forward testing but prove less interesting in live conditions. And occasionally, an idea works well enough to become part of the system.

That is normal.

I think this is actually one of the least discussed parts of algorithmic trading.

A large part of developing an automated strategy is learning what not to use.


Why we don't optimize everything for maximum return

There is another important lesson here.

Imagine two backtests.

Strategy A

  • Very high historical return
  • Relatively aggressive parameters
  • Performance concentrated in a few periods
  • Significant sensitivity to execution conditions

Strategy B

  • Lower historical return
  • More stable behavior
  • Less sensitivity to small parameter changes
  • More consistent performance across different periods

Which one is better?

There is no universal answer. But if the objective is to build a system that can operate for years, I would be very careful about automatically choosing Strategy A.

The highest backtest result is not necessarily the most robust result.

This is one reason why our development process has gradually shifted away from asking: "How much can we make in the backtest?"

towards: "How much of the strategy's behavior can we reasonably expect to survive outside the backtest?"

That is a much harder question. But I think it is also a much more useful one.


What happens when the strategy doesn't behave as expected?

This is another important part of the process.

Suppose a strategy performs well in the backtest but behaves differently in live trading.

The answer should not automatically be: "The strategy is broken."

There are many possible explanations.

Perhaps:

  • spreads are higher than expected;
  • execution is worse;
  • the trading session has changed;
  • the currency pair is behaving differently;
  • the market regime has changed;
  • the historical assumptions were too optimistic;
  • or the strategy was simply over-optimized.

This is why diagnosis is so important.

We need to understand why the behavior changed before deciding what to change. Otherwise, it is very easy to start modifying a strategy simply because of a short period of disappointing results.

And that can create another problem: You may end up optimizing the strategy for the latest problem rather than improving the underlying system.


Testing does not really end

This is probably the biggest difference between developing a trading robot and developing ordinary software.

With ordinary software, once the code works correctly, you can often consider the development phase finished.

With an automated trading system, the environment itself keeps changing.

☝️ Markets change.

☝️ Liquidity changes.

☝️ Trading costs change.

☝️ Broker conditions change.

☝️ Volatility changes.

☝️ Correlations change.

Even a strategy that has worked for years still needs to be monitored. That does not mean constantly changing it.

In fact, constantly changing a strategy can be dangerous. It means continuing to verify whether the assumptions behind the strategy are still valid.


From backtest to live system

After years of working with automated Forex strategies, I would describe the process roughly like this:

1. Idea

Does the trading concept make sense?

2. Backtest

Does it have statistical potential?

3. Robustness

Does it survive reasonable changes?

4. Forward test

Does it work outside the optimization period?

5. Execution testing

Does it behave correctly under realistic trading conditions?

6. Live observation

Does real execution match our expectations?

7. Long-term monitoring

Does the system remain useful as market conditions change?

This is a much longer process than simply running an EA in the Strategy Tester.

But that is precisely the point.

The objective is not to create the most impressive backtest.

The objective is to build something that has a reasonable chance of surviving the transition from historical data to the real market.


Why public live history matters

This is also the reason I believe that transparency is useful when discussing automated trading systems.

Nobody should have to rely entirely on a developer saying: "This EA works."

If a live trading history is available, people can examine it themselves.

For our own systems, the live history of SCR_EURAUD and SCR_EURAUD_advanced is publicly available through the MQL5 Signals platform.

MQL5 provides detailed signal information including growth, equity and balance charts, statistical information and trading history.

I think this is much more useful than simply showing a screenshot of a backtest.

A screenshot can show a result. A long trading history shows a process.

And for automated trading, the process is often more important.


Final thoughts

A profitable backtest is exciting.

But it is not the finish line.

It is the point where the more difficult questions begin.

▪️ Can the strategy survive different parameters?

▪️ Can it survive different market periods?

▪️ Can it work outside the optimization sample?

▪️ Can it handle realistic execution?

▪️ Can the broker provide the environment it needs?

▪️ Does it behave similarly when it starts trading live?

And perhaps most importantly: Does the underlying logic continue to make sense after months and years of observation?

This is how my view of automated trading has changed over time.

Earlier, I was much more focused on finding profitable trading logic.

Today, I am much more interested in understanding why the strategy works, when it works, what can break it, and how much of its historical behavior can reasonably be expected to survive in the future.

That is a much less exciting process than finding a perfect backtest.

But it is probably much closer to what real algorithmic trading is actually about.

A backtest can tell you that an EA could have worked.

Only time, testing and real market observation can start telling you whether it actually works.

And that is where the real development begins.