Backtesting vs diario de trading: por qué se necesitan ambos

En resumen. El backtesting simula una estrategia contra datos históricos de precios antes de arriesgar capital real; un diario de trading registra lo que realmente ocurrió una vez que se colocaron órdenes reales. Responden a preguntas distintas y ninguno sustituye al otro: un backtest puede mostrar si un conjunto de reglas tuvo mérito históricamente, pero solo un diario muestra si un trader puede realmente ejecutarlo, con slippage real, comisiones reales y psicología real de por medio.

Los traders tienden a apoyarse en uno y omitir el otro. Alguien ejecuta un backtest de una estrategia, ve una curva de capital limpia y empieza a operarla en real asumiendo que el backtest ya demostró el caso. Otro registra diligentemente cada operación en vivo, pero nunca comprobó, con datos históricos, si la idea subyacente tiene algún mérito estadístico. Ambos hábitos crean un punto ciego que la otra práctica habría detectado.

Lo que el backtesting realmente prueba

Un backtest aplica un conjunto fijo de reglas de entrada y salida a datos históricos de precios y mide lo que habría ocurrido: beneficio o pérdida neta, win rate, drawdown y otras estadísticas de rendimiento, calculadas sin arriesgar un solo centavo (Corporate Finance Institute, "Backtesting"). Eso lo hace barato de ejecutar y rápido de iterar: una idea de reglas puede probarse contra años de historial de precios, ajustarse y volver a probarse, todo antes de que salga una sola orden en real. Plataformas minoristas como el Strategy Tester de MetaTrader existen precisamente para esto: simulan la ejecución de una estrategia automatizada contra datos históricos de precios almacenados para poder revisar la lógica antes de que toque una cuenta real o demo (MetaQuotes, documentación de MQL5, "Testing Trading Strategies").

El valor de un backtest es estrecho y específico: responde si un conjunto definido de reglas habría producido un resultado positivo durante un tramo elegido de la historia. No responde si ese mismo trader, en condiciones reales de mercado, puede realmente seguir las reglas.

Lo que un backtest no puede ver

Un backtest corre sobre datos históricos limpios y una ejecución simulada en cada señal. No tiene acceso a lo que ocurre entre la regla y la orden real: el medio segundo de duda antes de hacer clic en comprar, el stop que se mueve porque la operación "se siente" mal, la posición que se cierra antes de tiempo por nervios, o la que se mantiene demasiado tiempo esperando un rebote. Nada de eso aparece en una simulación, porque una simulación no tiene nervios.

También suele subestimar los costes reales de operar. Las ejecuciones históricas en un backtest suelen asumirse exactamente al precio de la señal, mientras que una orden en real se ejecuta al precio que ofrece el mercado un instante después, más el spread y la comisión. El slippage en un instrumento líquido puede ser una fracción de un por ciento; en un mercado más delgado puede superar ampliamente el uno por ciento, e incluso una suposición pequeña de slippage puede convertir una ventaja probada en backtest en una pérdida en real cuando se aplica de forma consistente a cada operación.

Importante. Un backtest que nunca tuvo en cuenta un slippage, comisiones y ejecuciones realistas no está midiendo la estrategia que un trader realmente vivirá en real. Una curva de backtest limpia debe tratarse como una hipótesis de partida, no como una garantía.

Lo que un diario de trading captura en su lugar

Un diario de trading registra la operación que realmente se colocó: el precio real de entrada y salida, el tamaño real, el resultado real después de comisiones y, si el diario lo captura, el estado de ánimo antes y después de la operación. Este es el único registro que muestra la brecha entre la regla escrita y la regla ejecutada.

Esa brecha suele ser donde está la verdadera historia. Un setup puede tener un backtest limpio con un win rate del 55% y aun así perder dinero en real, no porque el setup estuviera mal, sino porque la ejecución en real cede consistentemente unos pocos puntos básicos por operación al slippage, la duda o una salida tomada demasiado pronto. Registrar cada operación con una etiqueta de setup es lo que hace posible esta comparación; sin ello, una racha de pérdidas en real y una idea rota se ven idénticas desde dentro.

El punto ciego que tiene cada método por separado

Un flujo de trabajo práctico: primero backtest, luego registrar la brecha de ejecución

Las dos prácticas funcionan mejor como una secuencia, no como una elección. Primero, hacer backtest de una idea sobre un tramo de historia lo bastante amplio y en más de una condición de mercado, para filtrar reglas que nunca tuvieron mérito antes de comprometer ningún capital. Si el backtest se sostiene, operar la idea en real con tamaño reducido y registrar cada operación bajo una etiqueta dedicada, incluyendo precio de entrada y salida, tamaño y resultado después de costes.

Tras un número significativo de operaciones en real bajo esa etiqueta, comparar el win rate registrado en el diario y el resultado promedio con las cifras del backtest para ese mismo conjunto de reglas. Una coincidencia cercana, dentro de lo que los costes y la varianza normal explicarían, es señal de que la estrategia sobrevive al contacto con la ejecución real. Una brecha amplia y consistente apunta a un problema real: costes subestimados en el backtest, o reglas que no se siguen tal como están escritas una vez que entran en juego el dinero real y las emociones reales. Revisar el desglose por estrategia de esa etiqueta con regularidad, en lugar de solo cuando el setup se siente como si hubiera dejado de funcionar, es lo que mantiene honesta esta comparación.

Leer una racha de pérdidas en real frente a una línea base de backtest

Una racha de pérdidas en un setup en real y registrado es fácil de malinterpretar sin un backtest con el que compararla. Si la prueba histórica ya mostraba tramos de cinco o seis pérdidas consecutivas como parte normal del patrón de rendimiento de esa estrategia, una racha en real de longitud similar no es información nueva; es la estrategia comportándose como se esperaba. Sin esa línea base, la misma racha puede parecer prueba de que la idea dejó de funcionar, y los traders abandonan setups que nunca estuvieron rotos, o duplican en otros que sí lo están, silenciosamente.

Este es un tipo de error distinto al de juzgar una ventaja con una muestra en real demasiado pequeña, que es un problema de tamaño de muestra. Aquí el problema es no tener ningún punto de referencia de cómo se ve lo "normal" para esta estrategia en concreto, porque se saltó el paso del backtest. La expectancy, calculada de la misma forma tanto en el backtest como en el diario en real, es el número que hace esta comparación concreta en lugar de una sensación.

Qué registrar para que la comparación funcione realmente

La comparación entre backtest y resultados en real solo funciona si el diario captura suficiente detalle para cotejarlo con la salida del propio backtest. Un registro que solo anota ganancia o pérdida no se puede comparar con un backtest que reporta win rate, resultado promedio y drawdown; ambos conjuntos de datos necesitan hablar el mismo idioma.

Como mínimo, cada operación en real bajo esa etiqueta necesita el nombre del setup, precio de entrada y salida, tamaño de posición, resultado después de comisiones y la fecha, para poder calcular las mismas estadísticas (win rate, resultado promedio, drawdown máximo para esa etiqueta) en ambos lados y ponerlas una junto a la otra. Ejemplos de diarios de trading construidos con este nivel de detalle convierten la comparación en una consulta de cinco minutos en lugar de una reconstrucción manual a partir de los estados de cuenta del bróker después del hecho.

Errores comunes

• Operar en real una idea probada en backtest sin comparar nunca los resultados reales con el backtest. Esa comparación es todo el propósito; omitirla convierte el backtest en un ejercicio único en lugar de una verificación continua.
• Asumir que las ejecuciones y los costes del backtest coinciden con las condiciones reales. Suposiciones poco realistas de slippage y comisión convierten habitualmente una ventaja de backtest en una pérdida en real.
• Registrar operaciones en real de una idea que nunca se probó con datos históricos. No hay forma de distinguir una racha de pérdidas normal de una idea rota sin una línea base.
• Abandonar una estrategia tras una racha de pérdidas que coincide con su propio patrón de drawdown de backtest. Comparar con el backtest antes de concluir que la ventaja desapareció.
• Tratar una sola ejecución de backtest como prueba permanente. Las condiciones del mercado cambian; un conjunto de reglas que se probó bien hace un año necesita una revisión periódica con datos frescos, igual que una ventaja en real.

Este artículo tiene fines educativos y no constituye asesoramiento financiero o de inversión. Operar con apalancamiento conlleva un alto riesgo de pérdida. El rendimiento pasado, ya sea de un backtest o de un historial en real, no garantiza resultados futuros.

Compare las expectativas del backtest con los resultados reales registrados en el diario de forma automática con el diario de trading de BitStat, en lugar de llevar dos hojas de cálculo separadas y adivinar la brecha entre ellas.