Qué es realmente un backtest
Supongamos que tienes esta idea:
Comprar cuando el mercado muestra fortaleza y vender cuando pierde impulso.
Eso puede tener sentido como intuición, pero todavía no es suficiente para hacer un backtest.
¿Qué significa exactamente “fortaleza”? ¿Qué condición activa la compra? ¿En qué momento entras? ¿Dónde sales si la operación va en contra? ¿Cuándo tomas beneficios? ¿Qué mercado estás analizando? ¿En qué temporalidad?
Para probar una estrategia necesitas convertir esas ideas en decisiones suficientemente claras como para poder reconstruirlas sobre el pasado.
Por eso el backtesting empieza antes de abrir el histórico.
Primero defines qué vas a probar. Después compruebas qué ocurrió.
Si haces lo contrario —miras primero qué hizo el mercado y después adaptas tus reglas hasta que capturen esos movimientos— puedes construir una estrategia extraordinaria para un pasado que ya conoces.
Y eso sirve de bastante poco.
Esta es precisamente la razón por la que antes trabajamos cómo definir las reglas de un sistema de trading.
Yo separaría un backtest en cinco piezas:
| Parte | Qué estás haciendo | Pregunta importante |
|---|---|---|
| Reglas | Defines qué habría hecho el sistema | ¿Las decisiones están suficientemente definidas? |
| Datos | Reconstruyes el mercado histórico | ¿Los datos representan lo que necesito probar? |
| Ejecución | Simulas entradas y salidas | ¿Estoy suponiendo ejecuciones razonables? |
| Costes | Incorporas la fricción de operar | ¿El resultado sigue teniendo sentido después de costes? |
| Resultados | Registras qué ocurrió | ¿Qué puedo concluir realmente de esta muestra? |
Un backtest serio, por tanto, no intenta responder únicamente:
“¿Esta estrategia habría ganado dinero?”
La pregunta útil es bastante mejor:
“¿Cómo se comportaron estas reglas bajo estas condiciones históricas y estos supuestos?”
Un ejemplo sencillo de backtesting
Imagina un sistema hipotético sobre EUR/USD en gráfico de una hora.
Las reglas están definidas antes de comenzar:
- existe una condición concreta de entrada;
- existe una regla de salida si la operación va a favor;
- existe otra salida si va en contra;
- el tamaño de posición sigue siempre el mismo criterio;
- solo se opera durante determinadas condiciones.
Ahora tomas varios años de histórico y aplicas exactamente esas reglas operación por operación.
Supongamos que la simulación termina con un resultado bruto de +14,000 unidades monetarias.
¿Eso significa que el sistema “gana 14,000”?
No.
Todavía faltaría comprobar qué costes habría tenido realmente ejecutar esas operaciones.
Imagina que, al introducir spread, comisiones y una estimación razonable del slippage cuando corresponda, el resultado termina en +8,000.
Las reglas no cambiaron.
Cambió la calidad de la simulación.
Y ni siquiera esos +8,000 significarían que el sistema vaya a producir esa cantidad en el futuro.
Solo describen lo que habría sucedido en esa muestra histórica bajo los supuestos utilizados.
Esta forma de pensar es importante: un backtest intenta aproximar un proceso que podría haberse ejecutado; no fabricar una curva bonita.
Para qué sirve el backtesting
Para mí, una de las funciones más valiosas del backtesting es algo que suele vender bastante menos: descartar ideas.
Imagina que tienes una hipótesis que sobre el gráfico parece espectacular. La conviertes en reglas, analizas una muestra suficientemente amplia y descubres que el comportamiento real no se parece en nada a lo que esperabas.
Eso es información útil.
Has descubierto un problema antes de utilizar dinero real.
Pero el backtesting sirve para bastante más.
Te obliga a convertir ideas en reglas
“Comprar cuando parece que el precio va a subir” no es una regla testeable.
Cuando intentas hacer un backtest empiezan a aparecer las preguntas incómodas:
¿Qué significa exactamente “parece”?
¿Qué tienes que observar?
¿Cuándo se activa la entrada?
¿Qué invalida la operación?
¿Cuándo sales?
El propio proceso de intentar probar una idea expone muchas ambigüedades del sistema.
Te permite observar muchas operaciones
Una operación individual dice muy poco.
Puedes hacer una mala operación y ganar. También puedes ejecutar perfectamente tu sistema y perder.
Cuando empiezas a reunir muchas observaciones puedes estudiar cómo se comporta el proceso de una forma que un par de trades aislados nunca permitirían.
Puedes observar, entre otras cosas:
- frecuencia de operaciones;
- distribución de ganancias y pérdidas;
- rachas;
- periodos buenos y malos;
- sensibilidad a los costes;
- comportamiento bajo distintas condiciones de mercado.
No necesitas estudiar todavía todas esas métricas. Las trabajaremos más adelante en el curso.
Por ahora basta con entender que el backtesting te permite pasar de una historia sobre una estrategia a una muestra de decisiones repetidas.
Te ayuda a comprobar si una idea merece seguir siendo investigada
Un resultado histórico razonable no termina la investigación.
La empieza.
Si una estrategia produce un comportamiento interesante bajo unos supuestos sensatos, puedes seguir estudiándola. Si la idea se deshace en cuanto introduces costes realistas o amplías la muestra, también has aprendido algo importante.
No se trata de conseguir que todas las estrategias “aprueben”.
Se trata de obtener información que te permita tomar mejores decisiones.
Lo que un backtest no puede demostrar
Aquí tendría mucho cuidado.
Un backtest positivo no demuestra que una estrategia vaya a ser rentable en el futuro.
El mercado no tiene obligación de reproducir las mismas condiciones que aparecieron durante el periodo analizado.
Puede cambiar:
- la volatilidad;
- la liquidez;
- el comportamiento de los participantes;
- la estructura de costes;
- la frecuencia de determinadas situaciones;
- la relación entre las variables que utiliza el sistema.
Además, el resultado puede estar condicionado por la propia forma en la que construiste la prueba.
Eso significa que un backtest debería darte evidencia, no certeza.
La diferencia importa mucho.
Si una estrategia fracasa claramente en una prueba bien diseñada, tienes una buena razón para cuestionarla.
Si obtiene un resultado excelente, lo que tienes es una razón para continuar investigando.
No una garantía.
Los costes pueden convertir un buen backtest en uno malo
Este es uno de los errores que más distorsiona el resultado.
El mercado histórico puede decirte dónde estuvo el precio. Eso no significa que hubieras podido operar gratis en cada uno de esos niveles.
Según el instrumento y la forma de ejecución pueden aparecer:
- spread;
- comisiones;
- slippage;
- financiación;
- diferencias entre el precio teórico y el precio realmente ejecutable.
El impacto depende mucho del tipo de sistema.
Imagina dos estrategias.
La primera realiza 20 operaciones al año y cada operación busca movimientos relativamente grandes.
La segunda realiza 2,000 operaciones y obtiene una ventaja muy pequeña en cada una.
El mismo coste por operación puede ser casi irrelevante para la primera y destruir completamente la segunda.
Por eso nunca asumiría que los costes son un detalle que puedes añadir al final.
Forman parte del modelo que estás probando.
Si estás construyendo un sistema para llevarlo después a un entorno de ejecución concreto, conviene que los supuestos del backtest tengan alguna relación con las condiciones que realmente encontrarás.
Si quieres revisar una plataforma orientada a traders, puedes consultar Pepperstone y la promoción disponible mediante nuestro enlace. Antes de utilizar cualquier cifra en tu backtest, revisa siempre las condiciones actuales del instrumento y de la cuenta que estés considerando.
El problema de los datos históricos
Hay otro detalle que puede cambiar por completo un resultado.
Imagina una vela con estos precios:
- apertura: 100;
- máximo: 110;
- mínimo: 90;
- cierre: 105.
Tú estabas comprado desde 100.
Tienes un stop en 95 y un objetivo en 108.
Durante esa vela sabemos que el precio alcanzó tanto 95 como 108.
Entonces, ¿tu operación ganó o perdió?
Con esos cuatro datos solamente, puede que no lo sepamos.
Sabemos que el máximo fue 110 y el mínimo 90. Pero esos valores no nos dicen necesariamente cuál ocurrió primero.
Si el mercado tocó primero 95, habrías salido por el stop.
Si llegó primero a 108, tu objetivo podría haberse ejecutado antes.
El orden cambia completamente el resultado.
Este ejemplo es muy sencillo, pero muestra algo importante: la calidad del dato no es una cuestión académica; puede modificar las operaciones que aparecen en tu backtest.
Profundizaremos en ello en cómo preparar buenos datos históricos para backtesting.
Por ahora quédate con una regla:
necesitas datos adecuados para la pregunta que estás intentando responder.
No siempre más datos significa mejor backtest.
Una muestra pequeña puede engañarte
Supongamos que pruebas un sistema y obtienes estos resultados:
- 8 operaciones;
- 7 ganadoras;
- 1 perdedora.
Puede resultar tentador concluir que tienes una estrategia extraordinaria.
Pero con ocho observaciones sabemos muy poco.
Quizá tuviste una racha especialmente favorable. Quizá el periodo analizado beneficiaba muchísimo a ese sistema. Quizá las próximas ocho operaciones sean totalmente diferentes.
Ahora imagina que analizas cientos de operaciones distribuidas entre distintos periodos y condiciones de mercado.
Tampoco tienes una garantía.
Pero tienes bastante más información.
La dificultad es que no existe un número mágico de operaciones que convierta automáticamente un backtest en válido. La muestra necesaria depende del sistema, de la variabilidad de sus resultados, de su frecuencia y de lo que quieras estimar.
Por eso esta pregunta merece su propia lección: cuántas operaciones necesita un backtest.
Aquí solo necesitamos entender el principio:
cuanto menor sea la muestra, más cuidado debes tener al sacar conclusiones grandes de ella.
Un backtest puede estar equivocado aunque los cálculos estén bien
Esto me parece especialmente importante.
Puedes tener una hoja de cálculo perfectamente construida, ninguna fórmula incorrecta y una gráfica preciosa.
Y aun así tener un backtest prácticamente inútil.
¿Por qué?
Porque los errores más peligrosos muchas veces no están en la suma final. Están en cómo obtuviste los datos y cómo diseñaste la prueba.
Hay tres problemas que debes empezar a reconocer desde ahora.
Utilizar información del futuro
Si una decisión histórica utiliza información que todavía no estaba disponible cuando supuestamente se tomó, el resultado queda contaminado.
Es lo que estudiaremos como look-ahead bias.
Ejemplo muy sencillo: decidir una entrada a las 10:00 utilizando un dato que solo se conoció a las 10:05.
La computadora puede hacerlo si programas mal el test.
Tú en tiempo real no habrías podido.
Seleccionar solo los activos que sobrevivieron
Imagina que quieres estudiar una estrategia de acciones utilizando únicamente las empresas que hoy siguen formando parte de un índice.
El problema es que podrías estar dejando fuera compañías que desaparecieron, quebraron, fueron excluidas o dejaron de cumplir los criterios.
Entonces estás reconstruyendo el pasado utilizando información sobre quién consiguió llegar hasta el presente.
Eso puede introducir survivorship bias o sesgo de supervivencia.
No necesitamos desarrollarlo más aquí. Lo importante es entender que qué activos incluyes también forma parte del backtest.
Ajustar hasta que el pasado quede perfecto
Pruebas una media de 20 periodos.
No te gusta el resultado.
Pruebas 21, 22, 23, 24, 25…
Después cambias el stop.
Después el horario.
Después añades otro filtro.
Después eliminas los meses que perjudican al sistema.
Y finalmente aparece una combinación espectacular.
El problema es que puede que ya no estés descubriendo una relación útil. Puede que simplemente hayas encontrado la configuración que mejor se adaptó al ruido particular de esos datos.
Eso es overfitting o sobreajuste en trading.
Y es uno de los motivos por los que un backtest extraordinario puede comportarse fatal cuando deja de enfrentarse al pasado que utilizaste para construirlo.
Mirar el pasado sabiendo el final es una ventaja enorme
Hay una forma muy tentadora de “hacer backtesting”.
Abres un gráfico histórico.
Ves una tendencia enorme.
Buscas el punto donde habría sido perfecto entrar.
Y piensas:
“Esta señal estaba clarísima”.
Pero tú ya sabes lo que pasó después.
Sabes que ese soporte aguantó.
Sabes que aquella ruptura continuó.
Sabes dónde terminó la tendencia.
Sabes qué retroceso era solamente un retroceso y cuál terminó convirtiéndose en un cambio mucho mayor.
En tiempo real no tienes nada de eso.
Por eso un backtest bien planteado intenta impedir que utilices información futura para reinterpretar las decisiones pasadas.
La pregunta no es:
“¿Dónde habría sido bonito entrar viendo ahora todo el gráfico?”
Es:
“Con la información disponible hasta este momento, ¿qué habría hecho mi sistema?”
Ese pequeño cambio convierte el ejercicio en algo mucho más útil.
Un backtest debe poner a prueba la estrategia, no confirmar lo que quieres creer
Aquí aparece otro problema.
Supongamos que estás convencido de que tu sistema funciona.
Comienzas el backtest y las primeras operaciones son malas.
Puedes reaccionar de dos maneras.
La primera es registrar exactamente lo que ocurre y utilizar esa información para evaluar tu idea.
La segunda es empezar a encontrar excepciones:
“Esta no cuenta porque había una noticia”.
“Esta tampoco porque el gráfico se veía raro”.
“Esta señal técnicamente aparece, pero yo en tiempo real no habría entrado”.
“Esta pérdida habría podido evitarla”.
Y, curiosamente, las operaciones ganadoras sí cuentan todas.
Eso deja de ser una prueba.
Estás enseñando al pasado cuál era el resultado que querías encontrar.
Un sistema puede tener filtros discrecionales, pero esos filtros también tienen que formar parte del método que estás evaluando. No pueden aparecer únicamente después de saber qué operación perdió.
Para mí, esta es una buena prueba mental:
si necesitas explicar cada pérdida a posteriori para que el sistema siga pareciendo bueno, probablemente el backtest no está poniendo a prueba tu idea con suficiente dureza.
¿Hay que separar los datos utilizados para crear y comprobar la estrategia?
Normalmente, sí conviene distinguir entre los datos que utilizas para desarrollar una idea y los datos con los que intentas comprobar si esa idea se sostiene sin seguir adaptándola.
Pero aquí no quiero adelantar una lección completa.
Más adelante veremos con calma la diferencia entre In-Sample y Out-of-Sample.
Por ahora piensa en algo muy sencillo.
Si estudias un examen con las respuestas delante y vas cambiando tus respuestas hasta acertarlas todas, obtener 10/10 en ese mismo examen no demuestra demasiado.
Lo interesante empieza cuando enfrentas tus reglas a preguntas que no utilizaste para construirlas.
En trading ocurre algo parecido.
Backtesting manual y automático
Un backtest puede hacerse manualmente o mediante software.
En el manual, tú avanzas por los datos históricos y registras qué habría hecho tu sistema.
En el automático, las reglas están programadas y un motor ejecuta la simulación sobre el histórico.
El principio es el mismo:
aplicar reglas al pasado sin modificar esas reglas en función de lo que ocurre después.
Lo que cambia es cómo se ejecuta la prueba, qué errores pueden aparecer y qué tipo de estrategia puedes evaluar con mayor facilidad.
No voy a desarrollar aquí cuál conviene más porque esa es exactamente la siguiente lección del curso: backtesting manual vs automático.
Si quieres preparar también un entorno de plataforma para practicar sin convertir todavía la prueba en operativa con dinero real, puedes revisar Pepperstone y consultar la promoción disponible al abrir tu cuenta mediante nuestro enlace.
La plataforma es la herramienta. La calidad del backtest sigue dependiendo de las reglas, los datos y los supuestos que tú introduzcas.
Qué necesita un backtest para empezar a ser útil
No existe un sello automático de “backtest válido”.
Yo empezaría comprobando esto:
- Las reglas estaban suficientemente definidas antes de analizar el resultado.
- Los datos utilizados son adecuados para el sistema que estás probando.
- La simulación de entradas y salidas no presupone ejecuciones imposibles.
- Los costes relevantes están incluidos de forma razonable.
- La muestra aporta suficiente información para lo que pretendes concluir.
- El sistema no utiliza datos que todavía no existían en el momento de tomar la decisión.
- No has ajustado una y otra vez las reglas hasta conseguir el pasado que querías ver.
- Entiendes que una buena prueba histórica sigue sin garantizar resultados futuros.
Fíjate en lo que no aparece en esta lista:
“Que la curva suba muchísimo”.
Un resultado rentable puede formar parte de la evidencia, claro.
Pero antes de entusiasmarme con él, yo querría saber cómo se obtuvo.
¿Qué significa que un backtest salga mal?
No necesariamente significa que hayas perdido el tiempo.
De hecho, puede ocurrir justo lo contrario.
Si tienes una hipótesis y un backtest razonablemente construido muestra que no se comporta como esperabas, has obtenido información antes de asumir riesgo real.
Puede que:
- la idea original fuera incorrecta;
- las reglas no representen bien la hipótesis;
- los costes destruyan una ventaja demasiado pequeña;
- el sistema dependa mucho de determinadas condiciones;
- la muestra todavía sea insuficiente;
- la estrategia sea demasiado sensible a pequeños cambios.
El objetivo del backtesting no debería ser conseguir que el sistema pase el examen.
El objetivo debería ser descubrir qué ocurre cuando lo sometes a una prueba que podría demostrar que estabas equivocado.
Ese enfoque me parece mucho más útil.
¿Y qué significa que el backtest salga muy bien?
Tampoco significa que hayas terminado.
Supongamos que produces una curva histórica muy estable, con buenos resultados y pocas rachas negativas.
Perfecto.
Ahora empiezan las preguntas interesantes:
¿La muestra era suficientemente representativa?
¿Los costes eran realistas?
¿Cambiaste las reglas mientras veías los resultados?
¿Probaste muchas versiones antes de elegir esta?
¿La estrategia depende demasiado de un periodo concreto?
¿Hay información futura filtrándose dentro del test?
¿Los resultados se mantienen cuando dejas de ajustar el sistema?
Ese cambio de mentalidad es importantísimo.
Un backtest atractivo no es la conclusión de una investigación. Es un resultado que ahora tienes que intentar romper.
Si sobrevive a pruebas cada vez más exigentes, entonces la evidencia empieza a ser más interesante.
Ese proceso de validación y robustez lo iremos construyendo durante el resto del curso. No necesitas aprenderlo todo en esta primera lección.
La idea con la que quiero que te quedes
Backtesting no significa mirar gráficos antiguos y localizar operaciones que habrían funcionado.
Significa definir unas reglas, aplicarlas a datos históricos y estudiar cómo se habrían comportado bajo unos supuestos concretos de ejecución y costes.
Sirve para aprender sobre un sistema, detectar problemas, descartar hipótesis y decidir qué ideas merecen seguir siendo investigadas.
Pero no elimina la incertidumbre.
Un gran resultado histórico no convierte el futuro en conocido.
Y un mal resultado no siempre significa que el proceso haya sido inútil. A veces descubrir pronto que una idea no se sostiene es uno de los mejores resultados que puedes obtener de un backtest.
Ahora que ya sabes qué estás intentando conseguir, toca decidir cómo vas a hacer la prueba.
Ese es el siguiente paso del curso: backtesting manual vs automático.
Preguntas frecuentes sobre backtesting
¿El backtesting garantiza que una estrategia sea rentable?
No. Un backtest muestra cómo se habría comportado una estrategia sobre unos datos históricos y bajo determinados supuestos. Puede aportar evidencia, pero el comportamiento pasado no garantiza que las mismas condiciones ni los mismos resultados se repitan.
¿Cuántas operaciones debe tener un backtest?
No existe una cifra universal que sirva para cualquier sistema. La frecuencia de operaciones, la variabilidad de resultados y las condiciones incluidas en la muestra cambian cuánto puedes aprender de ella. Lo desarrollamos específicamente en cuántas operaciones necesita un backtest.
¿Se puede hacer backtesting sin saber programar?
Sí. El backtesting también puede hacerse manualmente sobre datos históricos. Programar permite automatizar pruebas cuando las reglas pueden expresarse de forma suficientemente objetiva, pero no es un requisito para entender ni empezar a hacer backtesting.
En la siguiente lección comparamos ambas formas de trabajar.
¿Un backtest negativo significa que debo abandonar la estrategia?
No necesariamente. Primero tienes que comprobar que las reglas, los datos, la ejecución y los costes estén representados correctamente.
Si el test está bien construido y la estrategia sigue mostrando un comportamiento incompatible con tu hipótesis, entonces tienes evidencia para replantearla. Lo que no conviene es modificarla retrospectivamente una y otra vez solo para conseguir que el histórico termine siendo positivo.
¿Un backtest positivo demuestra que tengo una buena estrategia?
Tampoco.
Primero necesitas saber cómo se obtuvo ese resultado. Una estrategia puede parecer excelente por una muestra favorable, costes irreales, información futura, selección de datos o sobreajuste.
El resultado importa. La metodología que produjo ese resultado importa todavía más.
