La diferencia real entre backtesting manual y automático
Imagina una regla sencilla:
Entrar largo cuando el precio cierre por encima del máximo de las últimas 20 velas. La entrada se realiza en la apertura de la vela siguiente.
Un trader y un programa pueden aplicar esa condición de forma bastante parecida.
Ahora cambia la regla:
Entrar cuando el precio haga una ruptura convincente, muestre fuerza y el contexto acompañe.
Aquí aparece el problema.
¿Qué significa convincente? ¿Cuánta fuerza? ¿Qué variables definen el contexto?
Un humano puede interpretar esas palabras mirando un gráfico. Un programa no. Necesita que conviertas cada una en una condición observable.
Por eso el punto de partida no debería ser “¿qué software voy a usar?”, sino “¿mis reglas están suficientemente definidas?”.
Si todavía tienes dudas ahí, conviene volver a cómo definir las reglas de un sistema antes de preocuparte por automatizarlo.
| Criterio | Backtesting manual | Backtesting automático |
|---|---|---|
| Quién aplica las reglas | El trader | El software |
| Velocidad | Menor | Mucho mayor |
| Cantidad de casos que puedes revisar | Limitada por tiempo | Muy escalable |
| Repetibilidad | Depende del protocolo | Alta con el mismo código, datos y parámetros |
| Reglas discrecionales | Puede manejarlas | Deben formalizarse |
| Programación | No es imprescindible | La lógica debe codificarse de alguna forma |
| Principal riesgo oculto | Hindsight y selección subjetiva | Errores de código, supuestos de ejecución y sobreajuste |
| Principal utilidad | Entender y depurar el sistema | Medir reglas mecánicas de forma sistemática |
Hay una diferencia que para mí merece subrayarse: automatizado no significa automáticamente correcto, y manual no significa automáticamente subjetivo.
Puedes hacer un backtest manual extremadamente disciplinado. Y puedes programar un backtest automático lleno de errores.
Qué aporta de verdad un backtest manual
El gran valor del backtesting manual no está en hacer clic en cientos de velas. Está en obligarte a enfrentarte a cada decisión que tu sistema todavía no ha resuelto.
Supongamos que tu regla dice:
Compro el pullback después de una ruptura.
Parece clara hasta que empiezas a probarla.
¿Tiene que regresar exactamente al nivel roto? ¿Puede quedarse a cinco puntos? ¿Cuántas velas pueden pasar? ¿Qué ocurre si primero rompe un poco por debajo? ¿Cualquier pullback sirve?
Esas dudas aparecen muy rápido cuando haces el ejercicio a mano.
Por eso un primer recorrido manual puede ser tremendamente útil incluso si tu intención final es automatizar la estrategia. No estás intentando todavía demostrar que el sistema tiene ventaja. Estás intentando descubrir si existe realmente un sistema definido que se pueda probar.
Un backtesting manual serio necesita protocolo
Aquí tendría bastante cuidado.
Mover el gráfico hacia atrás, encontrar una entrada bonita y pensar “aquí habría comprado” no es un backtest serio.
La prueba debería impedir, en la medida de lo posible, que la información futura contamine tus decisiones. Lo razonable es avanzar cronológicamente, registrar los casos, aplicar siempre las mismas reglas y anotar cualquier escenario en el que no sepas con claridad qué deberías haber hecho.
Además, si modificas una regla de forma material a mitad de la prueba, tienes otro problema: ya no estás evaluando exactamente el mismo sistema.
Una función de replay puede ayudarte mucho porque evita que veas directamente todo lo que ocurrió después. En TradingView, por ejemplo, Bar Replay permite retroceder hasta un momento histórico y avanzar progresivamente por las velas.
Y aquí aparece uno de los principales peligros del backtesting manual.
Si primero observas que el precio subió con fuerza y después decides que aquella vela “claramente era una entrada”, estás utilizando una información que en tiempo real todavía no existía.
Ese problema tiene suficiente importancia como para tratarlo de forma independiente en la lección sobre look-ahead bias.
También hay que poner otra limitación sobre la mesa: un backtest manual no reproduce la presión psicológica de operar dinero real.
Puede servir para estudiar reglas, practicar su interpretación y encontrar inconsistencias. Pero sigue siendo una simulación sobre información histórica.
Qué aporta el backtesting automático
El backtesting automático cambia la naturaleza del problema.
En lugar de tomar tú cada decisión, defines una serie de condiciones y dejas que el motor de backtesting las aplique a todos los casos que encuentre.
Eso aporta tres ventajas enormes:
- velocidad;
- consistencia;
- repetibilidad.
Si la regla dice que la entrada ocurre siempre cuando A, B y C son verdaderos, el programa no se aburre en la operación 327 ni decide saltarse la 614 porque “esta no le gusta tanto”.
Ejecuta lo que has programado.
Plataformas como MetaTrader 5 disponen de motores específicos para probar Expert Advisors sobre datos históricos. TradingView también permite programar estrategias con Pine Script y generar simulaciones de operaciones históricas.
Eso hace posible estudiar un sistema mecánico sobre muchos más datos, mercados o configuraciones de los que sería razonable revisar manualmente.
Pero hay una frase que conviene recordar:
El programa ejecuta exactamente lo que programaste, no necesariamente lo que querías programar.
Un error lógico puede repetirse miles de veces con una precisión impecable.
Backtesting automático no significa “más realista”
Este es uno de los puntos que más fácilmente se pasan por alto.
Supongamos una operación larga con estos niveles:
- entrada: 100;
- stop loss: 97;
- take profit: 104.
Ahora aparece una vela cuyo máximo fue 105 y cuyo mínimo fue 95.
Con esa información sabemos que durante esa vela el mercado tocó tanto el objetivo como el stop.
Pero hay algo que el OHLC de esa vela no nos dice: cuál ocurrió primero.
¿Subió de 100 a 104 y después cayó a 95?
¿O bajó primero a 97 y después rebotó hasta 105?
El resultado de la operación cambia por completo.
Un humano que observe únicamente la vela terminada también puede caer en el error de escoger retrospectivamente la secuencia que más le conviene. Un motor automático, en cambio, tiene que utilizar algún modelo de ejecución, información de una temporalidad inferior o datos de ticks.
Y esto abre un problema más amplio.
Puedes tener un código que reproduzca perfectamente las reglas que escribiste y, aun así, obtener resultados poco realistas porque la simulación no representa correctamente:
- spreads;
- comisiones;
- slippage;
- ejecución intrabar;
- gaps;
- liquidez;
- horarios;
- calidad de los datos.
No vamos a desarrollar todo eso aquí porque el siguiente paso del curso está dedicado precisamente a cómo preparar buenos datos históricos para backtesting.
La idea que necesitas conservar ahora es más sencilla:
automatizar una prueba no elimina los problemas de los datos ni de la ejecución simulada.
¿Qué método encaja mejor con tu sistema?
Para responder bien, primero separaría el tipo de estrategia.
Si tu sistema es mecánico, con condiciones que dos personas distintas aplicarían prácticamente de la misma manera, el backtesting automático tiene mucho sentido como herramienta principal de medición.
Puedes seguir utilizando una revisión manual para comprobar operaciones individuales y confirmar que el algoritmo está haciendo exactamente lo que esperabas.
Si tu enfoque es discrecional, la situación cambia.
Una parte de la información está en tu interpretación del contexto. No puedes automatizar una decisión que todavía depende de expresiones como:
- “se ve fuerte”;
- “el rechazo es bueno”;
- “la estructura está limpia”;
- “el contexto acompaña”.
Primero tendrías que explicar qué significa cada cosa de forma suficientemente concreta.
Esto conecta directamente con la diferencia entre trading discrecional y sistemático.
Y luego están los sistemas híbridos, que son especialmente interesantes.
Puedes tener, por ejemplo, filtros totalmente objetivos de horario y volatilidad, pero mantener una entrada que requiera interpretación visual.
En ese caso no tienes por qué obligar a todo el sistema a ser manual o automático. Puedes automatizar aquello que realmente es mecánico y revisar de forma manual la parte que depende de juicio.
No se trata de defender una metodología. Se trata de probar la estrategia que realmente pretendes operar.
Manual primero y automático después: cuándo tiene sentido
Hay un flujo que me parece especialmente útil cuando estás construyendo un sistema desde cero.
Primero defines la hipótesis y las reglas antes de conocer los resultados.
Después haces una prueba manual diagnóstica para encontrar contradicciones, casos límite y decisiones ambiguas.
Si la lógica puede codificarse, entonces la automatizas.
Y aquí aparece una comprobación muy potente: comparar operaciones concretas del backtest manual con las que genera el algoritmo.
Supongamos que tú registraste una entrada en una determinada vela, pero el programa no la tomó.
Hay que averiguar por qué.
Quizá la regla era más subjetiva de lo que creías.
Quizá programaste mal una condición.
Quizá estabas utilizando información que todavía no estaba disponible en el momento de la entrada.
O quizá el algoritmo ha descubierto que tu interpretación real de la regla no coincide con lo que habías escrito.
Esa discrepancia no es una molestia.
Es información sobre tu sistema.
De hecho, muchas veces puede enseñarte más que mirar únicamente la curva de capital.
Si quieres llevar esta lógica un paso atrás y revisar cómo debería construirse la estructura completa antes de testearla, puedes volver a cómo crear un sistema de trading paso a paso.
Más operaciones no arreglan un mal backtest
Una de las grandes ventajas del método automático es que permite procesar muchas más operaciones.
Pero aquí hay una trampa conceptual.
Una muestra grande de una simulación defectuosa sigue siendo una simulación defectuosa.
Diez mil operaciones no arreglan un error de look-ahead.
Tampoco arreglan una comisión olvidada, una lógica mal programada o unos fills imposibles.
Y, en sentido contrario, un puñado de operaciones manuales no basta para sacar conclusiones sólidas simplemente porque las hayas estudiado con muchísimo detalle.
La pregunta de cuántos trades necesitas merece tratarse aparte, por eso tiene su propia lección sobre cuántas operaciones necesita un backtest.
Lo importante aquí es no confundir velocidad para producir datos con calidad de la evidencia.
El riesgo específico del backtesting automático: probar demasiadas cosas
Automatizar hace muy barato probar cambios.
Media móvil de 20, 21, 22, 23…
Stop de 1.2 ATR, 1.3 ATR, 1.4 ATR…
Horario A, B, C…
Filtro uno, filtro dos, filtro tres…
En poco tiempo puedes generar cientos o miles de combinaciones.
Eso parece una ventaja. Y lo es.
Pero también facilita encontrar una configuración espectacular simplemente porque has buscado durante suficiente tiempo dentro del pasado.
No voy a desarrollar aquí todo ese problema porque tiene una lección propia sobre overfitting en trading.
Quédate con esta idea:
la capacidad de probar más configuraciones también aumenta tu capacidad de engañarte con una configuración que encajó demasiado bien en una muestra histórica concreta.
Un backtest extraordinariamente bonito merece preguntas extraordinariamente buenas.
Separar descubrimiento y validación mejora ambos métodos
Hay una distinción que ayuda mucho a ordenar el trabajo.
Cuando exploras una estrategia, puedes descubrir problemas, reformular reglas y aprender del histórico.
Pero en algún momento tienes que dejar de mover la portería.
Si cada pérdida te lleva a añadir un filtro nuevo y cada operación ganadora confirma retrospectivamente que “la idea era buena”, nunca estás sometiendo la estrategia a una prueba limpia.
Por eso más adelante vamos a separar los datos utilizados para desarrollar una idea de aquellos que se reservan para comprobar cómo se comporta fuera de ese proceso.
Esa es la lógica de In-Sample vs Out-of-Sample.
No necesitamos entrar todavía en la metodología completa. Lo que sí necesitas entender en esta lección es que manual y automático pueden utilizarse tanto para investigar como para validar; lo peligroso es no saber en cuál de las dos fases estás.
¿Qué herramientas puedes utilizar para cada tipo de backtest?
Para backtesting manual, una función de replay suele ser mucho más útil que simplemente desplazar el gráfico hacia la izquierda.
Te permite colocarte en un momento del histórico y revelar la información progresivamente, que es precisamente lo que necesitas si quieres reducir el sesgo retrospectivo.
Para sistemas automáticos, plataformas como TradingView y MetaTrader 5 permiten trabajar con estrategias programadas y analizar sus operaciones históricas.
Aquí la herramienta debería elegirse después de entender qué quieres probar, no al revés.
Si buscas un broker que te permita trabajar posteriormente con distintas plataformas de trading, Pepperstone es una opción que puede encajar bien para este tipo de perfil. La disponibilidad de plataformas, instrumentos y condiciones depende de la entidad y de la jurisdicción correspondiente, así que conviene revisar siempre la información vigente antes de abrir una cuenta.
Puedes consultar Pepperstone y la promoción disponible mediante nuestro enlace.
La promoción y sus condiciones pueden cambiar, así que no asumiría un importe concreto sin comprobarlo en el momento de abrir la cuenta.
Un backtest automático puede verse mejor y ser peor
Supongamos dos pruebas.
El backtest A es manual. Tiene menos operaciones, algunos casos marcados como ambiguos y una curva irregular.
El backtest B es automático. Tiene miles de operaciones, una curva suave y estadísticas mucho más atractivas.
¿Cuál merece más confianza?
Con esa información, no lo sabemos.
Quizá A está hecho con un protocolo razonablemente honesto y B contiene un error que utiliza información futura.
Quizá B es perfectamente correcto y A seleccionó únicamente los setups más evidentes.
Quizá los dos tienen problemas.
Esta es la razón por la que yo no evaluaría nunca la calidad de un backtest por lo profesional que se ve su reporte.
Antes de confiar en una curva deberías entender:
- qué reglas generaron las operaciones;
- qué datos se utilizaron;
- qué costes se incluyeron;
- qué supuestos de ejecución existen;
- qué muestra se analizó;
- qué sesgos pueden estar presentes.
Más adelante aprenderás a estudiar esos resultados con mucho más detalle en la lección sobre cómo interpretar las métricas de un backtest.
Entonces, ¿backtesting manual o automático?
La pregunta que usaría para decidir es bastante sencilla:
¿Otra persona podría aplicar mis reglas sin necesitar que yo le explique qué “me parece” cada vez que aparece un setup?
Si la respuesta es sí, ya tienes una base razonable para automatizar.
Si la respuesta es no, el problema no es todavía el software.
Tu sistema contiene una capa de interpretación que necesitas estudiar manualmente, formalizar mejor o aceptar conscientemente como discrecional.
El método manual te ayuda especialmente a entender esa capa.
El automático te permite ejecutar reglas definidas con consistencia y escalarlas sobre mucho más histórico.
Y cuando puedes utilizar ambos, aparece una combinación muy potente:
el manual puede ayudarte a descubrir qué estás intentando medir; el automático puede ayudarte a comprobar si realmente lo mediste como creías.
Ninguno convierte una mala hipótesis en una buena estrategia.
Ninguno elimina sesgos por sí solo.
Y un resultado histórico favorable, venga de una hoja de cálculo o de miles de líneas de código, sigue sin garantizar lo que ocurrirá en el futuro.
El siguiente paso: los datos importan más de lo que parece
Ya sabemos cómo cambia el proceso dependiendo de si eres tú o un programa quien aplica las reglas.
Ahora toca responder otra pregunta:
¿sobre qué información estás haciendo la prueba?
Un motor fantástico con datos malos puede darte una respuesta muy precisa a la pregunta equivocada.
Por eso la siguiente lección del curso es cómo preparar buenos datos históricos para backtesting.
Y si quieres empezar a conocer un entorno donde posteriormente puedas practicar la ejecución de tu sistema, también puedes revisar Pepperstone y consultar la promoción disponible actualmente.
Una cuenta demo puede servir para practicar la ejecución sin arriesgar capital real, pero no sustituye un backtest bien construido ni demuestra que una estrategia vaya a ser rentable en real.
Preguntas frecuentes sobre backtesting manual y automático
¿El backtesting automático es más fiable que el manual?
No necesariamente.
Es más repetible porque el mismo código aplica las mismas reglas, pero la calidad del resultado depende de que esas reglas, el código, los datos, los costes y los supuestos de ejecución sean correctos.
Un proceso automatizado puede repetir un error miles de veces sin cometer ninguna inconsistencia.
¿Tiene sentido hacer backtesting manual de una estrategia mecánica?
Sí.
Puede ser una excelente forma de auditar visualmente la lógica antes o después de programarla.
Si tu backtest manual y el automático producen operaciones diferentes, investigar esas discrepancias puede revelar errores de programación, reglas ambiguas o diferencias en los supuestos de ejecución.
¿Se puede automatizar una estrategia discrecional?
Solo en la medida en que consigas traducir su discrecionalidad a condiciones observables.
Si automatizas una versión simplificada que elimina precisamente el criterio que utilizas para operar, estarás haciendo backtesting de otra estrategia, aunque superficialmente se parezca a la original.
¿Necesito saber programar para hacer backtesting automático?
No necesariamente tienes que escribir todo el código tú mismo, porque existen herramientas que facilitan la construcción de estrategias.
Pero alguien —tú, una herramienta o un desarrollador— tendrá que transformar tus reglas en instrucciones que el software pueda interpretar.
Y ninguna interfaz elimina el trabajo intelectual principal: definir exactamente qué debe ocurrir para entrar, salir y gestionar cada operación.
¿Puedo utilizar solo backtesting automático?
Puedes hacerlo si tu estrategia es suficientemente objetiva, pero yo seguiría revisando manualmente una muestra de operaciones.
No para sustituir la estadística, sino para comprobar que el algoritmo está interpretando y ejecutando las reglas tal como esperabas.
¿Cuál debería aprender primero?
Si estás construyendo tu primer sistema, entender primero el proceso manual suele ayudarte a ver qué significa realmente testear una regla.
Después, si el sistema es suficientemente mecánico, automatizar puede darte mucha más capacidad para estudiar datos.
El objetivo no es graduarte del método manual y “pasar” al automático.
Es saber qué problema resuelve cada uno.
