Qué es el Forward Testing en trading y qué puede validar de tu sistema

Un forward testing consiste en tomar una estrategia con reglas ya definidas y observar cómo se comporta con datos que llegan después de haberla diseñado, sin volver a ajustar las reglas cada vez que el mercado hace algo incómodo.

Esa última parte es la importante.

En un backtest ya conoces, de una forma u otra, el pasado que estás estudiando. En un forward test, la siguiente vela todavía no existe. No sabes cuál será la próxima operación, si vas a entrar en drawdown o si el mercado cambiará de comportamiento.

Por eso, para mí el forward testing no es otro backtest con un nombre distinto. Es el momento en el que dejas de preguntarte “¿qué habría hecho mi sistema?” y empiezas a comprobar “¿puedo ejecutar realmente este sistema, tal como está definido, cuando no conozco lo que viene después?”.

Si vienes siguiendo el curso en orden, esta prueba tiene sentido justo ahora. Primero construimos y testeamos el sistema; después estudiamos sus métricas y lo sometimos a distintas pruebas de estabilidad. La lección anterior fue precisamente sobre cómo comprobar la robustez de un sistema de trading. Ahora toca llevar esa versión del sistema hacia delante en el tiempo.

Qué es el Forward Testing
Qué es el Forward Testing

Qué es exactamente el forward testing

En esta lección voy a utilizar forward testing para referirme a la evaluación prospectiva de un sistema: congelas una versión de sus reglas y empiezas a aplicarla sobre datos que no conocías cuando desarrollaste la estrategia.

Lo habitual para un trader discrecional o sistemático es hacerlo mediante una cuenta demo o paper trading, siguiendo el mercado conforme ocurre.

La distinción es sencilla:

El forward test es la prueba. La cuenta demo es uno de los entornos donde puedes realizarla.

Puedes tener una cuenta demo y no estar haciendo un forward test serio. Por ejemplo, si hoy operas una regla, mañana la cambias, pasado mañana ignoras una señal y al final solo recuerdas las operaciones que salieron bien, estás practicando en demo, pero no estás validando una versión concreta del sistema.

También conviene aclarar una cuestión terminológica. Algunas plataformas utilizan forward testing de una forma algo distinta. MetaTrader 5, por ejemplo, llama así a la comprobación de resultados de una optimización sobre un segmento posterior de datos históricos que no se utilizó para optimizar los parámetros.

La idea de fondo es parecida —evaluar fuera del conjunto utilizado para ajustar el sistema—, pero no quiero mezclar conceptos. Si necesitas profundizar en esa separación, ya tienes las lecciones de In-Sample vs Out-of-Sample y Walk-Forward Analysis.

Aquí nos interesa principalmente la prueba hacia delante, con las reglas congeladas y el mercado llegando sin que conozcas el resultado.

Dónde encaja el forward testing después del backtesting

Yo lo ordenaría así:

Hipótesis → reglas → backtest → pruebas de robustez → versión congelada → forward test → revisión

Cada etapa intenta responder una pregunta distinta.

El backtesting te permite estudiar muchas operaciones y distintos periodos históricos en relativamente poco tiempo. Es muy potente para investigar si existe evidencia de que las reglas merecen seguir siendo estudiadas.

Pero precisamente porque estás trabajando con el pasado aparecen riesgos como el overfitting: probar suficientes parámetros, filtros o variantes hasta encontrar algo que describe extraordinariamente bien lo que ya ocurrió.

El forward test cambia una variable fundamental: el futuro deja de estar disponible.

BacktestingForward testing
DatosHistóricosNuevos conforme avanza el tiempo
VelocidadPuede comprimir años en poco tiempoAvanza al ritmo del mercado
Ventaja principalTamaño de muestra y variedad históricaPrueba prospectiva y ejecución
HindsightHay que controlarloMucho menor si las reglas están congeladas
EjecuciónNormalmente simuladaPuede observarse en demo en tiempo real
PsicologíaLimitadaMás realista, aunque demo no equivale a dinero real
Principal limitaciónSesgos y sobreajusteTiempo, muestra y diferencias respecto a ejecución real

No elegiría entre uno y otro. Responden preguntas distintas y se complementan.

Un forward test tampoco rescata una estrategia que nunca tuvo evidencia histórica razonable. Esperar seis meses para descubrir algo que un backtest podía descartar en una tarde no tiene demasiado sentido.

Qué puede comprobar un buen forward test

La primera tentación es mirar si la cuenta demo terminó ganando o perdiendo dinero.

Yo miraría bastante más.

Si las reglas son realmente ejecutables

Una regla puede parecer clarísima después de ver un gráfico histórico y resultar sorprendentemente ambigua en tiempo real.

Imagina esta condición:

Entrar cuando exista una ruptura fuerte de resistencia.

¿Qué significa fuerte? ¿Tiene que cerrar la vela? ¿Cuántos puntos debe superar el nivel? ¿Se permite entrar si el movimiento ya recorrió determinado rango? ¿Qué ocurre si rompe y regresa inmediatamente?

Si dos semanas de forward testing producen una discusión contigo mismo cada vez que aparece una señal, has descubierto algo valioso.

Quizá el problema no era el mercado. La regla todavía no estaba suficientemente definida.

Si las señales aparecen con la frecuencia que esperabas

Supongamos que el backtest mostraba unas 20 operaciones mensuales y en el forward test apenas encuentras tres.

Eso no demuestra automáticamente que la estrategia haya dejado de funcionar. Puede haber cambiado el régimen de mercado.

Pero también puede revelar otra cosa: que durante el backtest estabas clasificando retrospectivamente como válidas situaciones que en directo no reconoces con la misma claridad.

Esa diferencia merece investigación.

Si puedes ejecutar el proceso sin utilizar información futura

Esto es especialmente útil en estrategias discrecionales.

Cuando estás viendo el histórico terminado, es fácil que una entrada parezca evidente porque, aunque no quieras, ya ves la estructura que apareció después.

En forward testing desaparece esa comodidad.

Tienes que decidir con la información disponible en ese instante.

Dónde se separan la teoría y la ejecución

También puedes observar cuestiones operativas:

  • una señal que aparece cuando no estás frente a la plataforma;
  • órdenes que introduces tarde;
  • stops o tamaños mal calculados;
  • diferencias entre el precio teórico de entrada y el que realmente registras en la demo;
  • una frecuencia de decisión que resulta inviable para tu rutina;
  • reglas tan complejas que generan errores repetidos.

Aquí el P&L casi pasa a segundo plano.

Un sistema teóricamente bueno que no puedes ejecutar de forma consistente no es, para ti, el mismo sistema que aparece en el backtest.

Una cuenta demo sirve mucho, pero no demuestra cómo operarás con dinero real

Este matiz merece quedar muy claro.

Una demo puede ser excelente para comprobar el proceso, familiarizarte con la plataforma, seguir las señales y detectar errores operativos. Pero demo y real no son equivalentes.

La propia regulación estadounidense sobre resultados hipotéticos lleva décadas advirtiendo de esta diferencia: la CFTC señala que una simulación no representa operaciones reales y puede reflejar de manera imperfecta factores de mercado como la liquidez.

Además, hay otra diferencia que ningún software puede eliminar por completo: tu comportamiento.

Perder 3R virtuales y perder 3R con dinero que realmente es tuyo pueden producir decisiones muy distintas.

Por eso una demo puede ayudarte a evaluar:

  • cumplimiento de reglas;
  • frecuencia de señales;
  • manejo de la plataforma;
  • errores de ejecución;
  • operatividad del sistema;
  • consistencia del proceso.

Pero no demuestra por sí sola:

  • que obtendrás los mismos fills con dinero real;
  • que spread y slippage serán idénticos;
  • que la liquidez se comportará igual con cualquier tamaño;
  • que reaccionarás emocionalmente de la misma manera;
  • que la rentabilidad observada continuará;
  • que el sistema posee una ventaja permanente.

Esto no le resta valor a la demo. Solo evita pedirle una respuesta que no puede darte.

Para hacer esta fase sin poner capital en riesgo, Pepperstone ofrece cuentas demo con fondos virtuales y acceso a plataformas como Pepperstone, MT4, MT5, cTrader y TradingView. La propia compañía aclara que sus cuentas demo sirven para probar la ejecución, pero pueden no reflejar las condiciones del trading real.

Puedes abrir una cuenta demo de Pepperstone desde nuestro enlace y utilizarla para practicar tu forward testing. Antes de pasar a una cuenta real, revisa siempre las condiciones, productos y riesgos aplicables a tu caso.

Cómo hacer un forward testing que realmente te enseñe algo

El error más frecuente es empezar a operar en demo y decidir después qué queríamos medir.

Yo lo haría al revés.

1. Congela la versión del sistema

Antes de comenzar, deja definido qué versión estás probando.

Por ejemplo:

  • mercado;
  • temporalidad;
  • horario;
  • setup;
  • entrada;
  • stop;
  • salida;
  • filtros;
  • tamaño o modelo de riesgo;
  • parámetros;
  • costes que vas a considerar.

No tiene que ser un documento de 40 páginas.

Tiene que ser lo bastante preciso para evitar que una operación se considere válida o inválida dependiendo de cómo terminó.

2. Define antes qué quieres comprobar

“Ver si funciona” es demasiado vago.

Puedes querer comprobar, por ejemplo:

  • si detectas todas las señales;
  • si puedes ejecutar las entradas a tiempo;
  • si la frecuencia observada se parece a la histórica;
  • si los costes realesistas cambian demasiado el resultado;
  • si sigues las reglas de forma consistente;
  • si las métricas se mantienen dentro de un rango razonablemente compatible con el histórico.

Esto convierte el forward testing en un experimento.

3. No cambies las reglas a mitad de la prueba

Esta es una de las reglas que más protegería.

Imagina que llevas 18 operaciones y aparecen cinco pérdidas seguidas. Decides añadir un filtro para evitar “mercados malos”.

Las siguientes 20 operaciones mejoran.

¿Funcionó el forward test?

Ya no lo sabes.

Las primeras 18 pertenecían al sistema A y las siguientes al sistema B.

Puedes descubrir durante el test que una regla necesita cambios. Perfecto. Pero si el cambio es material, crea una nueva versión y separa sus resultados.

Lo que no haría es retocar constantemente el sistema y mantener todas las operaciones dentro de la misma estadística.

4. Registra también los errores, no solo las ganancias y pérdidas

No voy a desarrollar aquí todo el sistema de registro porque esa es precisamente la siguiente lección del curso.

Pero para que el forward test tenga sentido, como mínimo necesitas poder distinguir:

resultado del sistema de resultado de tu ejecución.

Supongamos que una operación debía entrar a 100 y tú entraste tarde a 101.20 porque estabas distraído.

Ese dato importa.

Si después el trade pierde, no puedes atribuir automáticamente toda la diferencia al sistema.

Y si ganas pese a haber incumplido la regla, tampoco deberías convertir el error en una nueva regla porque “esta vez funcionó”.

5. Compara las mismas métricas que utilizaste en el histórico

Si durante el backtesting mediste unas cosas y durante el forward test otras, la comparación empieza mal.

No necesitas diez dashboards. Pero sí conviene utilizar definiciones consistentes.

Por eso aquí damos por aprendido lo que vimos en cómo interpretar las métricas de un backtest.

El objetivo tampoco es que los números coincidan exactamente.

Un forward test no tiene que reproducir un win rate de 47.3% porque el backtest obtuvo 47.3%.

Lo que buscas es saber si el nuevo comportamiento resulta plausiblemente compatible con lo que esperabas o si aparece una desviación que merece una explicación.

Un ejemplo: perder durante el forward test no significa automáticamente que el sistema haya fallado

Supongamos un ejemplo completamente hipotético.

Tienes un sistema con 300 operaciones históricas:

  • win rate: 42%;
  • ganancia media: +2.1R;
  • pérdida media: -1R.

Su esperanza histórica simplificada sería:

Expectancy = (0.42 × 2.1R) − (0.58 × 1R) = +0.302R por operación

Eso describe esa muestra histórica. No promete +0.302R en la siguiente operación.

Ahora haces 30 operaciones en forward testing y solo ganas 10.

Tu win rate forward sería aproximadamente 33%.

¿Hay que abandonar el sistema?

No puedes saberlo mirando únicamente esa cifra.

Treinta operaciones pueden contener bastante ruido. Primero habría que preguntarse:

  • ¿una tasa de acierto así entra dentro de la variabilidad que ya observamos históricamente?;
  • ¿cambió el payoff?;
  • ¿hubo errores de ejecución?;
  • ¿cambiaron los costes?;
  • ¿se concentraron las operaciones en un régimen de mercado concreto?;
  • ¿las reglas se aplicaron exactamente igual?

Para esto resulta útil recordar la lección sobre cuántas operaciones necesita un backtest: una muestra pequeña permite aprender algunas cosas, pero no justificar cualquier conclusión estadística.

Y también puede ocurrir lo contrario.

Imagínate que ganas 8 de las primeras 10 operaciones.

Eso tampoco demuestra que ya tengas un sistema excelente.

Quizá simplemente has empezado el forward test en un régimen extraordinariamente favorable.

Una buena racha no valida un sistema y una mala racha tampoco lo invalida por sí sola.

Cuánto tiempo debe durar un forward testing

No me gusta dar una cifra universal como “30 días”, “50 operaciones” o “tres meses”.

Depende demasiado del sistema.

Yo pensaría en dos relojes.

El reloj de las operaciones

Necesitas suficientes observaciones para que la información tenga alguna utilidad.

Un sistema que hace 15 operaciones diarias puede acumular cientos de trades rápidamente.

Un swing trader que obtiene cuatro setups al mes puede tardar bastante más.

El reloj del mercado

Pero acumular muchas operaciones tampoco resuelve todo.

Imagina un scalper que completa 300 operaciones en tres semanas. Puede tener una muestra grande y, aun así, haber probado prácticamente un solo régimen de volatilidad.

El tiempo importa porque permite que el sistema se encuentre con condiciones diferentes.

Por eso un buen protocolo puede definir antes de empezar tanto un mínimo de observaciones como un periodo mínimo de seguimiento.

No elijas el punto final después de mirar el resultado.

Si vas +12R, será tentador declarar que ya tienes evidencia suficiente.

Si vas -8R, será igualmente tentador seguir hasta recuperar.

Eso introduce otro sesgo.

Cómo interpretar las diferencias entre backtest y forward test

Aquí es donde el forward testing empieza a ser realmente útil.

No busques únicamente “pasó” o “no pasó”. Pregunta por qué aparece la diferencia.

El forward test se parece razonablemente al histórico

Es una buena señal en el sentido limitado de que estás obteniendo nueva evidencia compatible con la anterior.

No significa que el sistema vaya a seguir funcionando.

Significa exactamente eso: hasta ahora no has encontrado una contradicción evidente entre el comportamiento histórico y el prospectivo.

El forward test es peor, pero estás ejecutando correctamente

Aquí tendría cuidado antes de tocar parámetros.

Puede ser:

  • varianza normal;
  • una muestra todavía pequeña;
  • un régimen distinto;
  • degradación del edge;
  • un backtest demasiado optimista;
  • sobreajuste.

La respuesta no debería ser automáticamente optimizar otra vez hasta conseguir una curva bonita.

Si terminas necesitando modificar el sistema, esa decisión pertenece a una fase posterior del curso: cómo mejorar un sistema sin sobreoptimizarlo.

El forward test revela muchos errores de ejecución

Entonces tienes otro problema.

Quizá la estrategia es demasiado rápida para ti.

Quizá las reglas tienen demasiada discrecionalidad.

Quizá estás interpretando el setup de formas distintas.

Quizá el proceso exige mirar cuatro mercados simultáneamente y en la práctica no puedes hacerlo.

Eso es información extraordinariamente útil aunque el P&L de la demo sea positivo.

El forward test sale mucho mejor que el backtest

Tampoco celebraría demasiado pronto.

Puede haber ocurrido exactamente lo contrario: empezaste durante un régimen ideal para esa estrategia.

El forward testing sirve para sumar evidencia, no para producir una ceremonia de graduación después de unas cuantas ganancias.

Errores que pueden arruinar un forward test

Hay varios que vigilaría especialmente:

  • Modificar las reglas después de cada racha. Terminas persiguiendo el ruido.
  • Ignorar señales que no te gustan. Si eran válidas según el sistema, deben formar parte de la prueba.
  • Registrar únicamente las operaciones ejecutadas correctamente. Los errores de ejecución son parte de lo que intentas descubrir.
  • Parar cuando el resultado te parece suficientemente bueno. El criterio de finalización debería existir antes.
  • Usar costes irreales. Una ventaja pequeña puede desaparecer con spread, comisión o slippage.
  • Comparar definiciones distintas. Si una “operación ganadora” se medía de una manera en el backtest y de otra en forward, la comparación no vale demasiado.
  • Probar diez variantes simultáneamente y conservar la mejor. Has vuelto a introducir selección retrospectiva por otra puerta.
  • Confundir demo rentable con sistema validado. La demo no elimina el riesgo de modelo ni demuestra cómo ejecutarás con capital real.

En general, el forward testing funciona mejor cuando es aburrido.

Mismas reglas. Mismo proceso. Todas las operaciones. Pocas decisiones improvisadas.

Eso es precisamente lo que queremos.

Entonces, ¿cuándo ha “pasado” un sistema el forward test?

No existe una frontera universal.

Yo no utilizaría algo como:

“Si después de 50 operaciones eres rentable, el sistema está validado.”

Es demasiado simple.

Un criterio serio depende de qué intentabas comprobar.

Puedes preguntarte:

  • ¿se pudo ejecutar el sistema sin reinterpretar constantemente sus reglas?;
  • ¿la frecuencia de señales tiene sentido frente a lo esperado?;
  • ¿los errores operativos son controlables?;
  • ¿costes y ejecución destruyen la ventaja teórica?;
  • ¿las métricas prospectivas resultan compatibles con un rango razonable de resultados históricos?;
  • ¿aparece algún comportamiento que contradiga la hipótesis original?

Y, sobre todo:

¿estás tomando la decisión con criterios que definiste antes de conocer el resultado?

Esa pregunta protege mucho más que cualquier número mágico.

El forward testing no te da certeza; te quita algunas excusas

Esta es la idea con la que me quedaría.

Un backtest puede decirte que una estrategia merece seguir siendo investigada.

Las pruebas de robustez pueden mostrarte si el resultado depende demasiado de parámetros, periodos o supuestos concretos.

El forward testing añade otra capa: comprueba qué ocurre cuando congelas el sistema, dejas que llegue información nueva y tienes que ejecutarlo sin saber cómo terminará el gráfico.

No convierte una estrategia en infalible.

Pero puede descubrir ambigüedades, costes, problemas operativos, sobreajuste y diferencias entre lo que creías que hacías y lo que realmente haces.

Y eso ya es muchísimo.

Si quieres poner en práctica esta fase sin arriesgar dinero real, puedes utilizar una cuenta demo para ejecutar una versión congelada de tu sistema y registrar las diferencias respecto al backtest. Aquí puedes consultar Pepperstone y la promoción que esté disponible al abrir tu cuenta mediante nuestro enlace.

El siguiente paso del curso es precisamente aprender a convertir todas esas operaciones en información útil. Para eso seguimos con qué es un Trading Journal y para qué sirve.

Esta lección ha sido elaborada por Javier Borja