How to backtest a portfolio without writing code

Backtesting a portfolio means applying its rules to historical prices and recording what would have happened. Twenty years ago that required a programming language and a data subscription. Ten years ago form-based tools made fixed allocations easy but left rule-based strategies to programmers. Today you can describe either kind in a sentence and get a tear sheet in under a minute. This guide walks through the process using ENSEMBLE, and most of it applies to any tool.

Step 1: Decide what question you are asking

A backtest answers one question well: given these rules and this history, what would the portfolio have done? It does not answer "is this a good portfolio," and it answers "will this work in the future" only indirectly and with heavy caveats.

So before touching any tool, write down the question. Some examples:

• Would adding gold to my stock and bond portfolio have reduced its worst drawdown?
• How much does rebalancing frequency matter for a fixed allocation?
• Does a trend filter on my equity sleeve cut drawdowns enough to justify the turnover?

Each of those is testable, and each implies a specific comparison: the portfolio with gold against the portfolio without it, monthly against annual rebalancing, filtered against unfiltered. A backtest with no comparison is just a number.

Step 2: Choose the universe

The universe is the set of assets the portfolio can hold. For most portfolio backtests it is a handful of broad exchange-traded funds, because ETFs have clean daily total-return histories and are what most people actually buy.

The common building blocks and their approximate start dates:

The platform will not hold something that did not exist yet, so a fund only enters the portfolio once it has prices. The backtest computes from the first day any member has data, and the tear sheet opens on the first day two members do, because a rule that chooses between funds tells you nothing while it can only hold one. A portfolio of SPY, DBC and BIL therefore reads from 2006 (SPY and DBC), with BIL joining in 2007; the Full history control shows the earlier SPY-only stretch. You can also set the start yourself in the description ("since 2010", "the past five years"), which stops the backtest computing anything earlier. Where the test begins is a real choice: one that begins in 2007 includes the 2008 crisis, while one that begins in 2010 includes a decade of nearly uninterrupted gains, and the two will tell very different stories about the same rules. The common mistakes guide has more on this.

Step 3: State the rule completely

This is the step most people rush, and it is where backtests go wrong. A complete description of a portfolio has three parts:

1. What it holds. The tickers.
2. How much of each. Fixed weights, or a rule that produces weights.
3. When it changes. The rebalancing schedule, or the condition that triggers a change.

"A balanced portfolio of stocks and bonds" has none of these. "60 percent SPY and 40 percent TLT, rebalanced quarterly" has all three. If you leave one out, the tool has to guess, and a guessed rebalancing schedule can change the trade count by a factor of twelve.

For rule-based strategies, the same discipline applies with more detail. "Hold SPY when it is above its 200-day moving average" is incomplete. "Hold SPY when it closes above its 200-day simple moving average, otherwise hold BIL, evaluated at each month end" is complete, because it says what average, what price, what happens otherwise, and when the check happens. The 200-day moving average page shows how much those details matter.

A useful test: could a careful person with a spreadsheet implement your description without asking you a question? If not, add the missing piece.

Step 4: Run the backtest

On ENSEMBLE, running the backtest means submitting the description. Create an account (every account starts with $100 in credit, no card required), open the dashboard, type or paste the sentence, and press run. The platform writes the Python that implements the rule, executes it in a sandbox against the historical data, and returns a tear sheet. The whole process takes 10 to 50 seconds.

The prompt below is a reasonable first portfolio to try: four uncorrelated asset classes, equal weights, quarterly rebalancing. It starts in 2006 and covers two bear markets.

When the build finishes you will land on a public tear sheet. Two things to check immediately:

• The universe. The tear sheet lists the tickers the generated code actually trades. Confirm they match what you asked for. If you asked for "gold" and the model picked IAU instead of GLD, that is fine but worth knowing.
• The start date. Confirm it is what you expected. The tear sheet names the fund whose launch set it; if it is later than you thought, one of your funds is younger than you assumed, or the description named a date.

Step 5: Read the tear sheet

A tear sheet has a lot of numbers. Read them in this order.

The equity curve against the benchmark. This shows the growth of one dollar in the portfolio and in a benchmark, usually SPY, on the same axis. Look at the shape before the end point. A portfolio that ends slightly below the benchmark but never fell as far is a different thing from one that ends in the same place by way of a much wilder ride.

Maximum drawdown. The largest peak-to-trough decline. This is the number that decides whether an investor would have stayed in the portfolio. For a diversified portfolio over a twenty-year window that includes 2008, anything under 20 percent is unusual; equities alone fell about 55 percent.

Compound annual growth rate. The single annual rate that turns the starting value into the ending value. Compare it to the benchmark over the same window, never to a number you remember from a different period.

Volatility and Sharpe ratio. Volatility is the annualized standard deviation of daily returns; Sharpe is return above the risk-free rate per unit of volatility. Together they say how efficiently the portfolio converted risk into return.

Trades and turnover. How often the portfolio changed. This is where costs live, and a strategy that trades daily needs a much larger edge than one that trades quarterly to come out ahead after costs and taxes.

Holdings over time. For a fixed allocation this is nearly a flat band. For a rule-based strategy it shows when the rule was in and out of each asset, which is usually the fastest way to understand what the rule actually did.

Every one of these is defined precisely in backtest metrics explained, including how each is computed and what a reasonable range looks like.

Step 6: Change one thing

The first backtest is rarely the interesting one. The interesting one is the comparison. Go back to the description, change exactly one thing, and run it again:

• Change the rebalancing from quarterly to annual. Watch the trade count fall and see how much else moves.
• Drop one asset. If removing gold barely changes the drawdown, gold was not doing much in this portfolio.
• Add a rule. Put a 200-day moving average filter on the equity sleeve and compare drawdowns and turnover.

Because every model on ENSEMBLE starts as a sentence, the two descriptions sit side by side and the difference between them is exactly what you changed. That is the discipline that separates research from curve fitting: one variable at a time, with the question written down in advance.

Step 7: Read the code

Every model's tear sheet links to the generated Python. You do not need to read it, but you can, and for a rule-based strategy it is worth skimming to confirm the rule was implemented as you meant. Look for the lookback length, the rebalancing condition, and what happens when the signal is off. If the code says 200 days and you meant 10 months, the difference is small; if it rebalances daily and you meant monthly, the difference is large.

This is also the moment to notice things the description left implicit. If you did not say what to hold when a signal is off and the code chose cash, that was a reasonable choice, but now it is your choice.

What to do with the result

A backtest is a description of one history. Used well, it tells you how a rule behaved across the environments in the sample, which environments it struggled in, and what it costs to run. Used badly, it becomes a search for the parameters that make the past look best, which the common mistakes guide covers in detail.

The right next step is usually another backtest with one thing changed, and after that a comparison against the simplest alternative, which for most portfolios is the 60/40 portfolio. If a strategy cannot beat a static blend of two index funds after costs on the metrics you care about, it does not need to be more complicated than that.

Backtests are hypothetical, past performance does not guarantee future results, and ENSEMBLE is research software rather than an investment adviser.