Plan de pruebas (o guion de pruebas de aceptación): el documento que describe los escenarios a ejecutar y los resultados esperados, para verificar que un sistema cumple sus requisitos (OpenClassrooms). Automatizar un plan de pruebas es convertir esos escenarios en pruebas que se repiten de forma idéntica en cada entrega, sin escribir código: es exactamente el principio de las pruebas de regresión.
Un plan de pruebas bien escrito no caduca: lo que se detiene es su ejecución. Al lanzar el proyecto, el equipo recorre los 80 casos de prueba en tres días. Seis meses después, las entregas salen cada dos semanas y la ventana de aceptación dura dos horas. Se prueba lo recién entregado, se deja de repetir lo que ya funcionaba, y la regresión se cuela por el hueco. Este artículo separa lo que puede automatizarse sin código de lo que debe seguir siendo humano, y detalla el método para pasar de un documento a una campaña de regresión que se repite en cada entrega.
Lo esencial en una página (definición, automatización sin código, cuadrícula para elegir herramienta): Pruebas de regresión automatizadas, sin código.
¿Tu plan de pruebas se reduce a la mitad de los casos por falta de tiempo? Delta-QA graba tus recorridos mientras navegas y repite el plan completo en cada entrega, sin código. Probar Delta-QA gratis →
Por qué un plan de pruebas manual no sigue el ritmo de las entregas
Un plan manual tiene un coste de ejecución constante: recorrerlo lleva el mismo tiempo en la entrega número cincuenta que en la primera. Su utilidad, en cambio, crece con la frecuencia de entrega, ya que cada despliegue puede romper un recorrido que funcionaba. Cuando el hueco entre esas dos curvas se hace demasiado grande, los equipos recortan la cobertura: ejecutan los casos del alcance entregado y abandonan el resto.
El riesgo se desplaza entonces justo donde nadie mira. Un túnel de pago rehecho se prueba en detalle; la página de cuenta, afectada por la misma refactorización de componente, no la repite nadie. El departamento de sistemas de Inria, que industrializó las pruebas de regresión de su sistema de información, llega a la misma conclusión: repetir las pruebas tras cada cambio es repetitivo, caro en tiempo y fuente de errores; su automatización eliminó esos fallos (JRES 2019).
La buena pregunta no es « ¿habría que redactar mejor el plan? », sino « ¿cuántas veces al año merece cada caso repetirse? ». Todo caso cuya respuesta es « en cada entrega » es candidato directo a la automatización.
Qué se puede automatizar en un plan de pruebas, y qué queda humano
Todo lo que se repetiría de forma idéntica puede automatizarse sin código; lo que exige juicio queda con la persona que hace la aceptación. La frontera pasa entre verificar y valorar.
| Comprobación típica de un plan | Ejemplo concreto | ¿Automatizable sin código? |
|---|---|---|
| Recorridos críticos | Compra completa, registro, búsqueda y reserva | Sí: recorrido grabado, repetido y comparado |
| Renderizado de páginas clave | Inicio, ficha de producto, en cada ancho de pantalla | Sí: captura comparada con la referencia |
| Estados de una misma página | Formulario vacío, con error, validado; menú abierto | Sí: cada estado grabado como escenario |
| Coherencia entre navegadores | El pago funciona en Chrome, ¿y en Safari? | Sí: mismo escenario, navegadores distintos |
| Pertinencia de un contenido | ¿Es claro el nuevo mensaje de error? | No: juicio humano |
| Decisión final | ¿Es aceptable la entrega, con pleno conocimiento? | No: eso es la aceptación, y sigue siendo humana |
En la práctica, la mayoría de los planes que vemos contienen entre el 60 y el 80 % de casos repetibles. Es la parte que más tiempo consume en la aceptación manual, porque es repetitiva. También es donde la fatiga produce los « OK » falsos: marcar la línea sin repetir realmente la manipulación. Para redactar o afianzar el documento en sí, la guía de referencia sigue siendo útil: Pruebas de aceptación de software: la guía completa.
De plan de pruebas a campaña de regresión: el método en 5 pasos
La migración se hace sobre el plan existente, sin reescribirlo: cada caso pasa a ser un escenario automatizado, o un caso que sigue manual porque exige juicio.
- Clasificar el plan. Marca cada caso como « repetir en cada entrega » o « juicio puntual ». El primer lote se automatiza; el segundo se queda en el documento manual, que se vuelve más corto y por fin se ejecuta entero.
- Grabar los recorridos navegando. Con una herramienta sin código, el escenario « buscar un producto, añadirlo al carrito, pagar con 3-D Secure » se graba tal como lo recorres. Ni una línea de código, ni un framework que instalar.
- Capturar los estados que importan. Un formulario vacío, con error y validado son tres escenarios distintos. Añade los anchos de pantalla críticos (móvil, tableta, escritorio) y los navegadores de tu audiencia.
- Repetir en cada candidata a entrega. La campaña completa se ejecuta en preproducción antes de cada despliegue. También corre periódicamente en producción, para los cambios que no pasan por tus despliegues: CMS, widgets de terceros, actualizaciones de dependencias en el navegador.
- Calificar cada diferencia. El informe muestra qué cambió entre la referencia y la entrega. El equipo decide: regresión que corregir, o evolución querida que se convierte en la nueva referencia.
En Delta-QA, la comparación la realiza una IA determinista, no un LLM: un algoritmo propietario, sin modelo entrenado, que da el mismo veredicto en cada ejecución y solo señala lo que un ojo humano notaría. Por qué importa este criterio en una aceptación: una herramienta que varía de una ejecución a otra reintroduce exactamente el azar que la automatización debía eliminar. Sobre el papel de QA en esta migración: Automatizar las pruebas sin desarrolladores.
¿Repetir 80 casos de prueba antes de cada despliegue? Graba tus recorridos una vez en Delta-QA; la campaña se repite sola y el informe lado a lado muestra cada diferencia. Probar Delta-QA gratis →
Cuánto tiempo toma la automatización, y cuándo se amortiza
Cuenta media jornada para los recorridos críticos, uno o dos días para un plan completo: es el tiempo de grabar los escenarios navegando y calificar las primeras diferencias. El cálculo de rentabilidad después es aritmética simple. Un plan de 40 casos a 10 minutos cada uno cuesta unas 7 horas por ejecución completa; con una entrega cada dos semanas, la automatización se amortiza antes de acabar el primer mes, y cada ejecución siguiente es tiempo ganado.
Dos matices honestos completan este cálculo. Primero, el mantenimiento existe: cada evolución de interfaz querida exige validar la nueva referencia, unos minutos por página. Es el precio normal de una campaña alineada con el producto. Segundo, no todo es automatizable el primer día, y no pasa nada: una campaña que cubra los recorridos críticos en el primer mes ya protege lo esencial de los ingresos.
FAQ
¿Se puede automatizar un plan de pruebas sin saber programar?
Sí. Las herramientas de grabación y repetición capturan los escenarios mientras navegas por la aplicación, y luego los comparan automáticamente con una referencia validada. El plan existente sirve de plano: cada caso « repetir en cada entrega » pasa a ser un escenario grabado.
¿Qué diferencia hay entre aceptación y prueba de regresión?
La aceptación valida una entrega concreta, en su globalidad y con juicio humano. La prueba de regresión verifica, en cada entrega, que los recorridos ya validados siguen funcionando. Ambas coexisten: la aceptación decide, la regresión protege lo adquirido.
¿Qué hacer con los casos de prueba que cambian en cada entrega?
Suelen pertenecer a la confirmación de la nueva funcionalidad y siguen siendo manuales. Cuando la interfaz evoluciona de forma duradera, la referencia del escenario afectado se actualiza validando el nuevo render una vez; las ejecuciones siguientes parten de esa nueva base.
¿Un plan de pruebas automatizado sustituye al tester?
No. La automatización ejecuta las comprobaciones repetitivas y señala las diferencias; calificar esas diferencias, la pertinencia de los contenidos y la decisión final de salida siguen siendo humanas. El tester gana el tiempo de las ejecuciones mecánicas para dedicarlo a exploración y juicio.
¿Por dónde empezar cuando el plan ya existe?
Por los recorridos que tocan los ingresos o un compromiso regulatorio: compra, pago, registro, contacto. Grabados primero, cubren la mayoría del riesgo con una minoría de los casos. El resto del plan sigue en las semanas siguientes, sin fecha límite.
Tu plan de pruebas merece algo mejor que una ejecución de cada dos. Crea una cuenta gratuita, graba tus recorridos críticos y deja que Delta-QA repita la campaña completa en cada entrega. Probar Delta-QA gratis →