Una estrategia de prueba es, según ISTQB, «una descripción de cómo llevar a cabo las pruebas para alcanzar los objetivos de prueba en unas circunstancias dadas». No es un calendario ni una lista de casos: es el conjunto de decisiones que explica por qué se prueba lo que se prueba y hasta dónde. Su columna vertebral es el enfoque basado en riesgo: como probar todo es imposible, se invierte más esfuerzo donde el impacto y la probabilidad de un fallo son mayores. Y su producto más valioso son los criterios de entrada y salida, que convierten la decisión de entregar en una comprobación en lugar de una opinión.
Ver índice de contenidos
- 01Política, estrategia y plan
- 02El enfoque basado en riesgo
- 03Qué niveles y tipos de prueba usar
- 04Qué automatizar, decidido arriba
- 05Criterios de entrada y salida
- 06Entornos y datos de prueba
- 07Métricas que sirven y métricas que dañan
- 08Cómo escribir la tuya en una página
- 09Quién decide y quién ejecuta
- 10Errores frecuentes
- 11Preguntas frecuentes
- 12Fuentes
Política, estrategia y plan
Estos tres términos se usan como sinónimos en la mayoría de las conversaciones, y esa confusión tiene un costo concreto: equipos que reescriben la estrategia entera en cada sprint, y equipos que tienen un plan de cuarenta páginas sin ninguna decisión de fondo detrás. Las definiciones del glosario de ISTQB los separan con precisión.
- Política de prueba: «documentación de alto nivel que describe los principios, el enfoque y los objetivos principales de la organización respecto de las pruebas». Es de la empresa, no del proyecto, y cambia cada uno o dos años.
- Estrategia de prueba: «una descripción de cómo llevar a cabo las pruebas para alcanzar los objetivos de prueba en unas circunstancias dadas». Es de un producto o una línea de producto. Es el nivel que decide.
- Plan de prueba: «documentación que describe los objetivos, los medios y el calendario para lograr la coordinación de las pruebas». Es del proyecto o la iteración, y es el que se actualiza seguido.
Hay un cuarto término que conviene tener a mano porque aparece en los tres documentos: el enfoque de prueba (test approach), definido simplemente como «la manera de implementar las tareas de prueba». Es la pieza que la estrategia elige y el plan aplica.
Sin política, una buena estrategia funciona igual. Sin estrategia, el plan es un calendario sin criterio: dice cuándo se prueba pero no por qué eso alcanza. Si tenés tiempo para escribir un solo documento, escribí la estrategia.
El enfoque basado en riesgo
Esta es la idea central de toda estrategia de prueba moderna, y la que propone la serie de estándares ISO/IEC/IEEE 29119. ISTQB define las pruebas basadas en riesgo como «un enfoque de prueba en el que la gestión, la selección, la priorización y el uso de las actividades y recursos de prueba se basan en los tipos y niveles de riesgo correspondientes».
Parte de una aceptación incómoda: probar exhaustivamente es imposible. Un formulario con diez campos de texto libre tiene más combinaciones que tiempo disponible en el proyecto. Entonces la pregunta deja de ser «¿cómo probamos todo?» y pasa a ser «¿dónde ponemos el esfuerzo que tenemos?».
Cómo se calcula en la práctica
El riesgo combina dos dimensiones, y la clave es que se estiman por separado porque las conoce gente distinta:
- Impacto: qué tan grave es si esto falla. Lo sabe el negocio: cuánta plata se pierde, cuánta gente se ve afectada, qué exposición legal o reputacional hay.
- Probabilidad: qué tan probable es que falle. Lo sabe el equipo técnico: complejidad del código, cuánto cambió últimamente, cuántos defectos históricos tuvo, si hay integraciones con terceros, si la persona que lo escribió sigue en el equipo.
Con esas dos estimaciones se ordena el producto por áreas. No hace falta una fórmula sofisticada: una escala de alto, medio y bajo en cada eje alcanza para ordenar y decidir.
| Nivel de riesgo | Qué esfuerzo justifica | Ejemplo típico |
|---|---|---|
| Alto | Varias técnicas de diseño, valores límite de tres valores, transiciones inválidas, exploración dedicada y regresión automatizada | Cobro, autenticación, cálculo de saldos |
| Medio | Particiones y límites de dos valores, camino principal y errores más probables | Alta y edición de datos, búsquedas, filtros |
| Bajo | Verificación superficial, lista de comprobación, o nada | Textos informativos, preferencias visuales |
Ese «o nada» de la última fila es la parte difícil y la más importante. Una estrategia que no dice explícitamente qué se decidió no probar no es una estrategia: es una lista de deseos. Y dejarlo escrito protege al equipo: cuando aparece un defecto en un área que se acordó no cubrir, la conversación es sobre la decisión y no sobre la culpa.
Qué niveles y tipos de prueba usar
La estrategia decide en qué nivel se verifica cada cosa. Es la decisión que más impacta en la velocidad del equipo, porque el mismo comportamiento se puede comprobar en varios niveles con costos muy distintos.
El principio operativo: verificá cada cosa en el nivel más bajo donde sea posible. Una regla de cálculo se comprueba en una prueba unitaria en milisegundos; la misma regla verificada moviendo un navegador tarda segundos, depende de datos y entornos, y falla por motivos que no tienen que ver con la regla. Si esa lógica de pirámide te suena nueva, está explicada en la guía de testing desde cero.
Además del nivel, la estrategia decide qué tipos de prueba entran en el alcance, y esta es la parte que se olvida más seguido. Las pruebas no funcionales —rendimiento, seguridad, accesibilidad, compatibilidad— no aparecen solas: si nadie las pone en la estrategia, no se hacen.
Recorré las características de calidad del producto —adecuación funcional, rendimiento, compatibilidad, usabilidad y accesibilidad, fiabilidad, seguridad, mantenibilidad— y preguntá para cada una: «¿quién verifica esto y cuándo?». Las que no tienen respuesta son el hueco real de tu estrategia.
Qué automatizar, decidido arriba
La decisión de automatizar suele tomarse por entusiasmo individual, y ahí es donde nacen las suites que nadie mantiene. Corresponde a la estrategia porque tiene consecuencias de largo plazo: la automatización es una inversión con costo de mantenimiento permanente.
Lo que la estrategia tiene que dejar por escrito son cuatro cosas concretas:
- Qué se automatiza y qué noLo repetitivo, estable, crítico y frecuente se automatiza. Lo que todavía cambia de forma, la usabilidad y la exploración quedan manuales.
- En qué nivel vive cada prueba automatizadaCuántas unitarias, cuántas de integración y cuántas de extremo a extremo. Sin esta decisión, todo termina en el nivel más caro.
- Qué herramienta y por quéUna sola, elegida con criterio. Mantener dos multiplica el costo de CI, informes y aprendizaje del equipo.
- Qué se hace con las pruebas intermitentesLa regla más importante y la que más se omite: qué pasa cuando una prueba falla sin que el producto haya cambiado. Sin política acá, el equipo aprende a ignorar los rojos.
Ese último punto merece énfasis. Una suite grande con fallos intermitentes que el equipo ignora es peor que no tener suite, porque consume tiempo de ejecución y de diagnóstico y no aporta confianza. La regla sana es explícita: una prueba intermitente se arregla o se desactiva con fecha de vencimiento, nunca se convive con ella.
Cuando llegue el momento de elegir la herramienta, la comparativa de Selenium, Cypress y Playwright plantea las tres preguntas que ordenan esa decisión.
Criterios de entrada y salida
Si la estrategia produjera un solo artefacto, debería ser este. Los criterios de entrada son «el conjunto de condiciones para comenzar oficialmente una tarea definida» y los de salida, «el conjunto de condiciones para completar oficialmente una tarea definida».
Traducido: qué tiene que estar listo para que empecemos a probar, y qué tiene que cumplirse para decir que terminamos. Escribirlos de antemano es lo que evita la discusión de «¿ya está listo?» al final del proyecto, cuando todos están cansados y hay una fecha encima.
| Criterios de entrada | Criterios de salida |
|---|---|
| La funcionalidad está desplegada en el entorno de pruebas | Se ejecutaron todos los casos de riesgo alto |
| Los criterios de aceptación están escritos y sin ambigüedades | No quedan defectos abiertos de severidad crítica o alta |
| Existen los datos de prueba necesarios | Los defectos abiertos restantes están documentados y aceptados por quien decide |
| Las pruebas unitarias del equipo de desarrollo pasan | La suite de regresión automatizada pasa completa |
| La versión a probar está identificada | Los resultados están registrados y comunicados |
Dos advertencias sobre cómo se escriben. La primera: tienen que ser verificables, no aspiracionales. «La calidad es aceptable» no es un criterio; «no quedan defectos abiertos de severidad alta» sí. La segunda: los criterios de salida casi nunca se cumplen al cien por ciento, y eso está bien. Su función no es bloquear la entrega sino hacer explícito qué se está aceptando cuando se decide salir de todos modos. Un criterio incumplido y aceptado a conciencia es una decisión de negocio; uno incumplido sin que nadie lo note es un accidente.
Entornos y datos de prueba
Es la sección menos glamorosa de cualquier estrategia y la que más horas hace perder cuando falta. Dos decisiones concretas:
Entornos. Cuántos hay, para qué sirve cada uno, qué tan parecidos son a producción y quién los administra. La pregunta que ordena todo: cuando una prueba falla, ¿podemos distinguir un defecto del producto de un problema del entorno? Si la respuesta es «no siempre», ahí está el trabajo pendiente.
Datos de prueba. De dónde salen, cómo se regeneran cuando se agotan y —crítico— qué pasa con los datos personales. Acá hay un punto que va más allá de la eficiencia: copiar la base de producción a un entorno de pruebas es una práctica extendida y un riesgo real de privacidad, porque los entornos de prueba suelen tener controles de acceso más laxos, credenciales compartidas y respaldos menos protegidos.
Si tu producto maneja datos de personas, la estrategia debería exigir anonimización o generación sintética antes de usarlos para probar. Además del cumplimiento normativo que aplique en tu jurisdicción, es sentido común de seguridad: reduce la superficie de exposición sin costo funcional. Si te interesa cómo se evalúan estos riesgos de forma metódica, el punto de partida es fundamentos de hacking ético.
Métricas que sirven y métricas que dañan
La regla para elegir métricas es una sola: sirve la que cambia una decisión. Todo lo demás es trabajo de informe que consume tiempo y no mejora nada.
| Métrica útil | Qué decisión habilita |
|---|---|
| Defectos encontrados después de entregar | Si sube, la estrategia no está cubriendo lo que importa |
| Tiempo desde el commit hasta tener resultado | Si crece, la suite empezó a estorbar y hay que rebalancear niveles |
| Proporción de pruebas intermitentes | Si pasa de un umbral, hay que parar y arreglarlas |
| Cobertura por área de riesgo alto | Un cero acá señala un hueco concreto que hay que llenar |
Y las que conviene evitar, todas por el mismo motivo: se pueden mejorar sin mejorar la calidad.
- Cantidad de casos escritos. Se sube partiendo casos en dos. Mide volumen de documentación, no cobertura de riesgo.
- Porcentaje de cobertura de código como objetivo. Se llega al 100 % sin una sola aserción útil.
- Defectos reportados por persona. Premia reportar en lugar de prevenir, y desincentiva ayudar a que el defecto no exista.
- Casos ejecutados por día. Premia ejecutar rápido lo trivial en lugar de invertir tiempo en lo riesgoso.
Cómo escribir la tuya en una página
No hace falta un documento extenso. Estas son las siete preguntas que una estrategia tiene que responder, y todas caben en una carilla si se responden sin rodeos:
- ¿Qué riesgos priorizamos?Las tres o cuatro áreas de riesgo alto del producto, nombradas. Y las que decidimos no cubrir.
- ¿En qué niveles probamos cada cosa?Qué se verifica en unitarias, qué en integración, qué en extremo a extremo.
- ¿Qué tipos de prueba entran?Además de lo funcional: rendimiento, seguridad, accesibilidad, compatibilidad. Y quién los hace.
- ¿Qué automatizamos y con qué?Los cuatro puntos de la sección de automatización, incluida la política sobre pruebas intermitentes.
- ¿Cuáles son los criterios de entrada y salida?Escritos de forma verificable, no aspiracional.
- ¿En qué entornos y con qué datos?Incluyendo la regla sobre datos personales.
- ¿Qué medimos y quién decide?Las tres o cuatro métricas que van a cambiar decisiones, y quién tiene la última palabra sobre entregar.
En el foro de Underc0de hay un punto de partida concreto para el nivel de abajo: ANTRAX compartió un modelo de plan de pruebas en agosto de 2023, con una aclaración que vale reproducir porque es exactamente el criterio correcto: «existen muchas formas de hacer un plan de pruebas, por lo tanto, esta no es la única forma de hacer uno». Y agrega que si algún ítem no aplica al proyecto, simplemente se saca. Esa actitud —una plantilla como punto de partida, no como formulario obligatorio— es la que hace que estos documentos se usen en lugar de archivarse.
Quién decide y quién ejecuta
Una estrategia sin dueño es una sugerencia. Y hay una distinción de roles que en el foro de Underc0de se discutió en el hilo «El abismo entre tester y QA» y que vale traer acá, porque explica por qué muchos equipos no tienen estrategia: nadie tiene asignado escribirla.
En términos prácticos, hay tres responsabilidades distintas y conviene que estén nombradas:
- Quién define la estrategia. Habitualmente quien lidera calidad, con participación del equipo técnico y del negocio. No puede ser una sola persona en un cuarto, porque el impacto lo estima el negocio y la probabilidad la estima quien programa.
- Quién la ejecuta. Todo el equipo, no solo quien tiene «QA» en el título. Las pruebas unitarias las escribe quien desarrolla; la revisión de requisitos la hace quien la lea primero.
- Quién decide entregar cuando no se cumplen los criterios de salida. Esta es la que más falta y la que evita más conflictos. Tiene que ser una persona con autoridad sobre el producto, no la persona que probó: el rol de QA informa el riesgo, no lo asume.
Quien prueba no decide si se entrega: hace visible el riesgo para que quien decide lo haga con información. Confundir esos dos roles genera dos patologías: el QA que bloquea entregas sin autoridad para hacerlo, y el QA al que se le reclama un defecto que se decidió no cubrir.
Errores frecuentes
- Confundir estrategia con plan. Y reescribir en cada sprint decisiones que deberían durar un año.
- No escribir qué se decidió no probar. Es la parte que protege al equipo cuando aparece un defecto en un área descartada a conciencia.
- Criterios de salida aspiracionales. «La calidad es aceptable» no se puede comprobar. Si no es verificable, no es criterio.
- Estimar el riesgo sin el negocio. El impacto no lo puede estimar sola el área técnica, y la probabilidad no la puede estimar solo el negocio.
- Olvidar las pruebas no funcionales. Rendimiento, seguridad y accesibilidad no aparecen por sí solas: si no están en la estrategia, no se hacen.
- No tener política sobre pruebas intermitentes. Es el camino más corto a que el equipo deje de mirar los resultados.
- Copiar datos de producción sin anonimizar. Riesgo de privacidad evitable y sin beneficio funcional.
- Medir lo que se puede contar en lugar de lo que importa. Cantidad de casos y porcentaje de cobertura se mejoran sin mejorar nada.
- Que quien prueba sea quien decide entregar. Le da una responsabilidad que no le corresponde y le quita el rol de informar con independencia.
Preguntas frecuentes
¿Cuál es la diferencia entre estrategia y plan de pruebas?
La estrategia describe cómo se van a hacer las pruebas para alcanzar los objetivos en unas circunstancias dadas; el plan describe objetivos, medios y calendario concretos para coordinar el trabajo. Dicho de otro modo: la estrategia responde qué probamos y hasta dónde, y cambia poco; el plan responde quién, cuándo y en qué entorno, y cambia por proyecto o por iteración. El error más común es escribir un plan sin estrategia detrás, con lo cual se termina con un calendario sin criterio que justifique las decisiones.
¿Qué son las pruebas basadas en riesgo?
Son, según ISTQB, un enfoque en el que la gestión, la selección, la priorización y el uso de las actividades y recursos de prueba se basan en los tipos y niveles de riesgo correspondientes. En la práctica: como probar todo es imposible, se prueba más donde el impacto de un fallo y la probabilidad de que ocurra son mayores. El riesgo se calcula combinando esas dos dimensiones, se ordenan las áreas del producto de mayor a menor, y el esfuerzo se reparte en ese orden. Es el enfoque que propone la propia serie de estándares ISO/IEC/IEEE 29119.
¿Qué son los criterios de entrada y de salida?
Los criterios de entrada son el conjunto de condiciones para comenzar oficialmente una tarea definida, y los de salida, las condiciones para completarla oficialmente. En pruebas se traducen en preguntas muy concretas: qué tiene que estar listo para que empecemos a probar, y qué tiene que cumplirse para decir que terminamos. Escribirlos antes de empezar es lo que convierte «¿ya está listo para salir?» en una comprobación en lugar de una discusión de opiniones al final del proyecto.
¿Cuánto tiene que medir una estrategia de prueba?
Una página bien escrita rinde más que cuarenta que nadie lee. Lo que la hace útil no es la extensión sino que el equipo la conozca y la use para decidir. Tiene que responder al menos cinco cosas: qué riesgos priorizamos, qué niveles y tipos de prueba usamos, qué automatizamos y qué no, qué criterios de entrada y salida aplicamos, y en qué entornos y con qué datos probamos. Si un documento responde eso en una carilla, está terminado.
¿Sirven las métricas de testing?
Sirven las que cambian una decisión; el resto es trabajo de informe. Las útiles suelen ser tres: defectos encontrados después de la entrega, que mide si la estrategia está funcionando; tiempo desde el commit hasta tener resultado de pruebas, que mide si la suite está estorbando; y proporción de pruebas intermitentes, que mide si el equipo todavía confía en la suite. Las contraproducentes son las que se convierten en objetivo, como cantidad de casos escritos, porcentaje de cobertura o cantidad de defectos reportados por persona: todas se pueden mejorar sin mejorar la calidad.
¿Hace falta una estrategia formal en un equipo chico?
Hacen falta las decisiones, no el documento formal. Un equipo de tres personas necesita igual haber acordado qué se prueba antes de entregar, qué riesgo justifica frenar una salida y quién decide eso. La diferencia es que puede caber en una página del repositorio en lugar de un documento con aprobaciones. Lo que no funciona es no haber decidido nada: ahí el criterio queda en la cabeza de una persona y cambia según el día y el cansancio.
Fuentes
Glosario normativo, estándares y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
- ISTQB. Glosario: test strategy, test plan y test policy. Las tres definiciones que separan los niveles de decisión.
- ISTQB. Glosario: risk-based testing. Definición del enfoque basado en riesgo.
- ISTQB. Glosario: entry criteria y exit criteria. Criterios de entrada y de salida.
- ISTQB. Glosario: test approach. Definición de enfoque de prueba.
- ISO/IEC/IEEE. ISO/IEC/IEEE 29119 Software Testing. Serie de ocho estándares; la Parte 1 cubre conceptos y definiciones, la Parte 2 procesos de prueba y la Parte 3 documentación, incluidos los documentos de política, estrategia y plan.
- Underc0de, foro. «Modelo de Plan de Pruebas - QARMY», por ANTRAX, 21 de agosto de 2023, sección QA. Plantilla de la comunidad y la advertencia de que no hay una única forma correcta de armarlo.
- Underc0de, foro. «El abismo entre tester y QA», sección QA. Discusión de la comunidad sobre el reparto de responsabilidades entre quien prueba y quien gestiona la calidad.