¿Por qué ChatGPT olvida tus casos de prueba y cómo solucionarlo (2026)?

En primer lugar, nunca tuvo tu suite

Una suite de pruebas es un artefacto grande, estructurado y en constante evolución: cientos de casos, una gramática de nomenclatura, fixtures, convenciones de etiquetado y un mapa implícito de lo que está cubierto y lo que deliberadamente no lo está. Nada de eso llega al modelo a menos que lo introduzcas en la conversación. Lo que obtienes en su lugar es una suite genérica de mejores prácticas: razonable de forma aislada, pero incorrecta para tu repositorio.

Los archivos subidos dejan de existir cuando termina el chat

Subir la suite funciona para ese chat en particular. El contenido está disponible mientras la conversación esté activa, y luego desaparece; un nuevo chat comienza sin tener idea de que el archivo existió, que es la misma barrera descrita en por qué ChatGPT olvida tus archivos subidos. Para una suite que cambia semanalmente, volver a subirla es una tarea tediosa que además se desactualiza silenciosamente: rara vez vuelves a subir la versión más reciente.

La memoria integrada almacena preferencias, no cobertura

La memoria de ChatGPT está diseñada para recordar cosas como tu rol, tu tono o tus instrucciones permanentes. Es realmente útil, pero no es un índice de 400 casos de prueba con sus etiquetas, propietarios y justificaciones. Pedirle que guarde tu mapa de cobertura es pedirle a una función que haga un trabajo para el que no fue diseñada, y el fallo es silencioso: el modelo responde con total confianza basándose en una impresión desactualizada.

El contexto de QA más valioso es el histórico

Las pruebas que más importan son las que se escriben después de que algo se rompe. Su valor radica en su procedencia: esta aserción existe porque un reembolso parcial se acreditó dos veces en producción; esa prueba de reintento existe porque la pasarela de pago se agotó silenciosamente a los 30 segundos. Ese historial reside en informes de incidentes, hilos de tickets y en la memoria de quien estaba de guardia, no en el chat que abriste esta mañana. Los fallos relacionados se manifiestan como ChatGPT olvidando el contexto del proyecto y como la pérdida de los requisitos que las pruebas debían verificar, algo que cubre ChatGPT olvidando los requisitos del producto.

Una plantilla de prompt gigante

La solución temporal estándar: un bloque reutilizable con el stack, las convenciones, los roles de usuario y las reglas de negocio, pegado al principio de cada sesión. Funciona, pero tiene un coste. Pagas por esos tokens en cada solicitud, la plantilla se desactualiza respecto a la base de código y nadie la actualiza después del sprint en el que cambiaron las reglas de nomenclatura.

Volver a subir la suite en cada sesión

Más preciso que la plantilla, pero más tedioso y limitado por lo que cabe y lo que el modelo puede leer de manera útil. Además, genera el incentivo incorrecto: al ser molesto, la gente sube solo un subconjunto, y el modelo razona sobre una cobertura que no puede ver.

GPTs personalizados o un proyecto dedicado

Una mejora real: instrucciones y archivos de referencia en un solo lugar, compartidos con el equipo. Sin embargo, sigue siendo un silo que mantienes a mano: los archivos no se actualizan solos cuando cambia la cobertura, y nada de lo que hay allí está disponible para el agente de código que escribe la implementación o el asistente que resume el lanzamiento. Dos fuentes de verdad para la misma suite es cómo empiezan las contradicciones.

Pegar la especificación completa

Las ventanas de contexto largas hacen que esto sea tentador. Pero una especificación describe la intención, no la cobertura, y no dice nada sobre qué casos ya existen. Terminas con duplicados que pasan la revisión porque nadie puede retener 400 nombres de pruebas en su cabeza tampoco.

El patrón que pone fin a la repetición consiste en mantener tu contexto de QA en una capa de memoria que resida fuera de cualquier chat individual y permitir que el modelo lea de ella. MemoryLake está diseñado para eso: tus convenciones, tu mapa de cobertura y tu historial de incidentes se almacenan una sola vez y pueden ser recuperados por cualquier asistente o agente que esté realizando el trabajo.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que definen cómo realiza las pruebas tu equipo: las convenciones de nomenclatura y etiquetado, el mapa de cobertura, los planes de prueba, los criterios de aceptación, los análisis post-mortem de los errores que generaron pruebas de regresión y la lista de pruebas inestables (flaky tests) con sus motivos.

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y a tus otros agentes acceso a esa memoria a través de MCP o de la API. Para ChatGPT, recupera la memoria relevante a través de la API e introdúcela en la conversación o en tus herramientas de QA, de modo que el modelo comience desde tu suite real en lugar de una genérica. El objetivo es que todos lean de la misma fuente: el agente que escribe el código y el asistente que escribe las pruebas dejan de contradecirse sobre lo que existe.

Haz las cuentas de tu propia repetición. Si un ingeniero de QA vuelve a poner en contexto al modelo durante cinco minutos al inicio de diez sesiones a la semana, eso equivale a casi una hora semanal por persona dedicada a repetir cosas que no han cambiado. Si el bloque de contexto permanente es de 2,500 tokens y se envía 30 veces al día en todo el equipo, eso representa 75,000 tokens al día (alrededor de 2.2 millones al mes) pagando por repetirte.

Los costes que no aparecen en la factura son aún mayores: casos duplicados que inflan el tiempo de ejecución de la suite, vacíos de cobertura que nadie nota porque el modelo no sabe qué falta y pruebas de regresión que se vuelven a discutir silenciosamente porque su motivo nunca se documentó. La memoria no convierte al modelo en un mejor diseñador de pruebas. Lo convierte en un diseñador de pruebas que conoce tu suite.

Almacena la estructura de la suite, no cada aserción

No necesitas 400 cuerpos de prueba en memoria. Necesitas el mapa: los módulos y su nivel de cobertura, la gramática de nomenclatura y etiquetado, lo que intencionadamente no se ha probado, qué suites son de confianza y cuáles son inestables. Eso ocupa una página o dos, y es precisamente lo que le falta al modelo.

Registra por qué existe cada prueba de regresión

Una línea por cada prueba que provenga de un incidente: el síntoma, la causa raíz y la fecha. Este es el elemento de mayor valor que puedes almacenar, porque es el conocimiento que se pierde cuando una persona se va de la empresa, y es lo que evita que una prueba "redundante" sea eliminada seis meses después.

Actualiza la memoria en el mismo pull request que la cobertura

La memoria se corrompe cuando actualizarla es un ritual aparte. Vincúlala al cambio: cuando cambie una convención o se retire una suite, el mismo pull request debe actualizar el dato almacenado. Es preferible reemplazar una declaración obsoleta que añadir una nueva; un contexto de QA desactualizado es peor que no tener ninguno, porque tanto el modelo como los humanos confían en él. Este hábito se generaliza; es la misma disciplina que hay detrás de no volver a explicar el contexto a tu IA.

ChatGPT olvida tus casos de prueba porque nunca los tuvo. No tiene una visión de tu suite, los archivos subidos desaparecen con el chat y la memoria integrada almacena preferencias en lugar de un mapa de cobertura. Los mejores prompts no cambian eso; solo hacen que la puesta en contexto sea más larga.

Coloca la estructura de la suite, tus convenciones y tu historial de incidentes en una capa de memoria que tus herramientas puedan leer, y el resultado del modelo pasará de ser plausible a ser utilizable: casos con tu estilo de nomenclatura, dirigidos a lo que realmente no está cubierto y respetando los errores por los que tu equipo ya pagó una vez. Vale la pena escribir eso correctamente, exactamente una vez.