I Got Tired of Sending Backtests as a Pile of Screenshots — So I Built a Better Format
There is one small part of working with trading robots that becomes surprisingly annoying over time.
Running a backtest is easy.
Getting the chart, statistics, inputs, trade list, and tester report is also easy.
The real inconvenience starts when you need to show the result to someone else.
Suddenly, a simple backtest turns into a folder like this:
Settings.png
Inputs_1.png
Inputs_2.png
Backtest.png
Graph.png
Report_final_final_2.png
If the input list is long, you also have to scroll, make several screenshots, remember where the previous one ended, crop unnecessary interface elements, rename the files, and then explain which image belongs to which test.
A week later, even the author may already have trouble understanding the archive.
And if there are dozens of tests, this is no longer reporting.
It is archaeology.
A Screenshot Without Context Is Not Much of a Report
The problem is not that screenshots are bad.
The problem is that screenshots usually lose their context.
I can open an old image several months later and immediately start asking questions:
Which EA was this?
Which broker was used?
What account type?
What leverage?
When was the test created?
Which report version is this?
Was this a single experiment or part of a larger series?
Which parameters were actually used?
What exactly was I trying to verify?
Even a beautiful equity curve does not answer those questions.
At some point, I started thinking about a backtest not as a collection of pictures, but as a small technical document.
That Is How My Backtest Review Format Started
I began automating the whole process.
The idea is simple.
A utility switches the required MetaTrader 5 tabs, finds previously selected interface areas, captures them, and assembles everything into a single PDF document.
Instead of doing this manually:
click → screenshot → crop → save → rename → switch tab → repeat
the same process can be reproduced automatically.
But I quickly discovered that simply putting several screenshots into a PDF was not enough.
I wanted to be able to open the document six months later and understand immediately what I was looking at.
So the format gradually became more structured.
The First Page Should Explain the Test Before Showing the Results
The cover now clearly identifies the test.
It includes:
Backtest + EA name
and, when applicable, a clearly visible customer name.
Below that I show the broker, account type, leverage, test date, and document version.
There is also a dedicated area for important parameters and a short description of the test.
For example, instead of opening a random report and wondering what it belongs to, the first page may immediately tell me:
Backtest EA
Customer: Customer name
Broker: VTMarkets-Live-6
Account Type: RAW/ECN
Leverage: 1:500
Test Period: 2020–2026
That changes the document from “a folder of screenshots” into a record of a specific test scenario.
Visual Consistency Matters More Than I Expected
Another surprisingly important problem was screenshot geometry.
If one screenshot fills almost the entire page, the next one is much narrower, the third one is shifted, and the fourth one has completely different proportions, the whole document starts to look accidental.
So I introduced one simple rule:
all main screenshots use the same visual width.
It does not matter whether the page contains Settings, Inputs, Backtest, or Graph.
The document follows the same grid.
That gives the report visual rhythm and makes different sections easier to compare.
Small things like alignment, margins, spacing, and frame geometry make a large difference.
A technical report should look intentional.
Long Input Lists Are a Separate Problem
The Inputs tab created another challenge.
A large EA can have far more parameters than fit into one visible MT5 window.
The obvious solution is to make several screenshots.
But that creates a new problem: duplicated rows, missing rows, and ugly visual breaks.
So I experimented with an automated scroll-capture process.
The utility:
-
scrolls the area in small steps;
-
waits for the interface to repaint;
-
captures consecutive frames;
-
calculates the actual vertical displacement between them;
-
reconstructs the visible sequence into one continuous image.
I deliberately prefer keeping the result as one uninterrupted vertical ribbon instead of arbitrarily cutting the image into unrelated pieces.
For reviewing a long Inputs table, continuity is more important to me than forcing every page into a conventional paper ratio.
Cropping the UI Is Also Part of the Report
Sometimes the correct UI Automation element is larger than the useful content.
For example, a Pane may also include a menu, a vertical title, or another interface strip that has nothing to do with the test.
For that reason, each saved capture can have its own pixel correction:
Left / Right / Top / Bottom
This allows the report to keep the correct automated capture target while still removing irrelevant interface elements.
Again, this sounds like a minor detail.
But once screenshots are collected automatically, these small corrections matter a lot.
Broker Information Deserves to Be Obvious
I also decided that the broker should not be hidden somewhere inside the description.
It should be immediately visible.
The same applies to account type and leverage.
Why?
Because backtest results should not be discussed without the conditions under which they were produced.
Two reports may look nearly identical while being based on different trading environments.
If the document is meant to support serious technical discussion, these conditions should not require detective work.
I Also Added a Watermark for a Specific Reason
Every page of my current format contains a very subtle diagonal watermark:
Backtest Review
This is partly a design element, but more importantly it serves as a visual reminder that the document contains a historical backtest review.
It is not a live-account statement.
It is not evidence of real trading performance.
And it should not be interpreted as such.
I think this distinction should be visible immediately, not hidden in tiny text at the end of the document.
Important Disclaimer: A Backtest Is Not a Promise of Profit
This point is essential.
A backtest is a simulation of how a trading strategy behaved on historical data. It is not a result of real trading and it is not a promise of future profitability.
A historical test can be useful for studying an algorithm, checking its logic, reviewing risk behaviour, testing parameter sensitivity, and comparing different configurations.
But historical results do not turn future market behaviour into a known quantity.
Live trading may differ because of many factors, including execution, spread, slippage, liquidity, broker conditions, historical-data quality, market regime changes, and modelling assumptions.
For that reason, I see Backtest Review as a technical analysis and documentation format, not as proof of future profit.
That distinction is important both technically and ethically.
Why Spend Time on Reporting Instead of the EA Itself?
Because good engineering is not only about writing code.
Code should be reproducible.
Experiments should be reproducible too.
If I run one test today, another tomorrow, and a third one a month later, I want to be able to place those three reports next to each other and compare them without asking:
“Was this screenshot made on another broker?”
“Which Inputs belong to this graph?”
“Was this already the new version?”
“Did I change leverage here?”
A consistent report format becomes part of the development process.
It does not make the trading strategy better by itself.
But it can make the process of reviewing, preserving, comparing, and discussing the experiment much better.
A Backtest Report Is Really an Interface Between People
This was probably the most interesting conclusion for me.
The Strategy Tester is an interface between MetaTrader and the developer.
But once the result has to be discussed with another developer, trader, customer, or tester, another interface is needed.
That interface is the report itself.
A good report should answer the obvious questions before the reader has to ask them.
What was tested?
Under what conditions?
Which parameters were used?
What was the purpose?
What did the tester show?
What conclusions can reasonably be drawn?
And, just as importantly:
what conclusions cannot be drawn?
What Format Do You Prefer?
I will publish several examples of my current Backtest Review format on my MQL5 wall.
I am interested not only in showing my layout, but also in understanding what other developers and traders actually find useful.
Some people may want the full Inputs list.
Some may care mostly about the equity graph.
Some may want maximum Strategy Tester statistics.
Some may prefer a compact two-page report.
Others may want a full technical review with test conditions, screenshots, notes, and a conclusion.
So I would be interested to hear your opinion:
What do you consider essential in a good backtest report?
And which format is more convenient for you:
a compact summary or a detailed Backtest Review?
I think there is room to make backtest reporting much clearer than a folder full of screenshots.
