Traducción de artículo de a revista Better Software - Octubre 2008

Título: The One-Hour Regression Test - Find and Fix the Big Bugs Fast
Autor: Steven Woody
Acceso a revista: http://tinyurl.com/3pv4sbw
Las pruebas de regresión son esenciales y desafiantes para los equipos de testing. Por definición, una
prueba de regresión es el proceso de verificar que ninguna de las funcionalidades existentes de un
software se haya roto accidentalmente por corrección de incidentes o cambios recientes. El principal
desafío para las pruebas de regresión es realizar la mayor cantidad de pruebas en el menor tiempo
posible y detectar los errores graves.

Un ciclo clásico de regresión:

1. El equipo de desarrollo libera una versión final del software con las nuevas funcionalidades
implementadas y resueltos los incidentes más severos.
2. Se ejecutan pruebas para las nuevas funcionalidades y pruebas de regresión para las
funcionalidades existentes
3. Se ejecutan pruebas de performance, integración, interoperabilidad y estrés
4. Si se detecta un incidente grave o son necesarios cambios en alguna funcionalidad, se repiten
los pasos del 1 al 3.
5. Cuando todas las funcionalidades necesarias son operables y no presentan incidentes graves, el
software es liberado por testing, y está listo para ser usado por el usuario.

Problemas inherentes a las pruebas de regresión

A pesar de que es sencillo seguir esta secuencia, hay varios problemas con el enfoque clásico de las
pruebas de regresión.

Enjabonar, enjuagar y repetir

El objetivo de las pruebas de regresión es detectar problemas en las prestaciones o funcionalidades de
software que funcionaban anteriormente. A pesar que quienes gestionan el proyecto pueden decidir
retrasar la corrección de los incidentes, y en algunos casos, no solucionarlos, algunos de los incidentes
que se detecten en las pruebas de regresión deben ser corregidos antes de la liberación final. Luego el
ciclo de corrección- regresión se repite, probablemente más veces que las que el cronograma permite.

Todo cambio en el código puede “romper” algo o todo

Quienes gestionan los proyectos, usualmente creen que todo defecto introducido por un cambio en el
código puede ser aislado y es suficiente ejecutar pruebas de regresión “abreviadas”, enfocadas en el
área del cambio. Con el tiempo se aprende que cualquier cambio en el código, sin importar cuán aislado
este, puede tener efectos indirectos, involuntarios y catastróficos en aéreas aparentemente no
relacionadas con el área donde se hicieron modificaciones en el código.

Las mejores pruebas se dejan para el final

La mayoría de los planes de prueba son dispuestos en un orden lógico que empieza con pruebas simples,
como hacerle “ping al server”, proceder a través de múltiples funcionalidades del producto y terminan
con pruebas de performance complejas, como “medir el tiempo de convergencia del enrutamiento con
un millón de rutas en la tabla”. A pesar de ser lógico desde la perspectiva del tester, va contra el
principal objetivo de la pruebas de regresión, encontrar primero los incidentes más serios. Las pruebas
más complejas, demandantes y críticas para el éxito del producto deben ser ejecutadas primero.

Obtener resultados significativos es lento

Ambos enfoque para las pruebas de regresión, automatizados y manuales, tienden a tomar un día o más
antes de que sepamos si la última versión del software es aceptable o si tiene problemas serios. Las
pruebas más complejas de performance, interoperabilidad y estrés pueden tardar semanas en
realizarse. Pero quienes gestionan el proyecto pueden necesitar saber en horas si la última versión es
suficientemente buena para una demo al usuario de las nuevas funcionalidades, o si corrige un
incidente crítico detectado por el usuario sin introducir nuevos problemas.

Las pruebas de regresión son repetitivas aburridas y tediosas

Las pruebas de regresión tienden a ser última actividad favorita de los testers de software por su
naturaleza repetitiva. Luego de unas pocas iteraciones, las mismas pruebas manuales adormecen la
mente, especialmente si pocos incidentes son detectados. Los scripts automatizados son usualmente
desarrollados para acelerar las pruebas se regresión y reducir la carga a los testers humanos. Pero,
multiplica una simple prueba de regresión automatizada por los miles de funcionalidades que existen en
la mayoría de los productos. El resultado son decenas de miles de líneas de scripts de pruebas de
regresión para mantener - otra tarea aburrida.

Las pruebas de regresión consumen gran cantidad de recursos

La mayoría de los equipos de testing, dedican la mayoría de sus recursos a las pruebas de regresión, a
escribir y mantener miles de pruebas automatizadas o a ejecutar pruebas manualmente. A medida que
se detectan incidentes, el equipo de testing queda atrapado en una repetición sin fin de ciclos de
prueba, sin poder escapar para utilizar su tiempo adecuadamente en generar nuevos casos de prueba o
mejorar los existentes.

Intentos para lidiar con estos problemas

La mayoría de los equipos de testing han intentado lidiar con los problemas clásicos de las pruebas de
regresión utilizando alguno de los siguientes enfoques:

La prueba de regresión completa

Algunos equipos de prueba buscan evitar los problemas de la regresión comenzando en una versión del
software y continuando días y semanas en la misma versión hasta que se finalicen las pruebas, aunque
nuevas versiones del software estén disponibles durante el ciclo de regresión. Estas versiones quedan
sin probarse hasta que el actual ciclo de regresión finalice, y el próximo ciclo comienza con la última
versión del producto.

Las prueba de regresión continua

Otros equipos de testing buscan evitar los problemas aceptando nuevas versiones diariamente o
semanalmente durante el ciclo de regresión. Cuando una nueva versión está disponible, es instalada en
el ambiente de testing continuando el ciclo de regresión sin reiniciarse. Al final, las pruebas de
regresión se propagaron por múltiples versiones del software. Ninguna versión se prueba
completamente, pero las pruebas de regresión son ejecutadas solo una vez.

Las pruebas de regresión de humo

Otros equipos de testing ejecutan pruebas superficiales, usualmente automatizadas “pruebas de humo”
que pueden completarse en algunas horas en cada versión del software. Una regresión “full” es
ejecutada solo en la versión “final”.
Las pruebas de regresión se reinician
Otros equipos de testing reinician las pruebas de regresión con cada nueva versión disponible,
particularmente si y se cree que es la versión final (o cercana) que será probada. Por supuesto, que todo
incidente severo que se detecte requerirá reiniciar (nuevamente) las pruebas de regresión. Rara vez el
cronograma se reinicia para tener tiempo para las pruebas de regresión. A veces, los primeros casos de
prueba serán ejecutados sobre todas las versiones y las últimas pruebas serán solo ejecutadas una vez.

Sin embargo, los problemas continúan

Cada uno de los distintos enfoques a las pruebas de regresión resulta en un testing poco significativo
sobre la última versión. Lo que conduce a fallar en el propósito de las pruebas de regresión, el cual es
dar en el menor tiempo posible confianza en que todas las funcionalidades críticas continúan
funcionando.
Un enfoque para mitigar el riesgo de ejecutar pocas pruebas de regresión es realizar una prueba más
exhaustiva sobre la versión final. El problema con esto es que es imposible saber antes de que la prueba
de regresión comience que en la última versión no se van a detectar incidentes severos que requieran
otra versión final a ser construida y probada, y así sucesivamente.

Estrategia de pruebas: Una hora de pruebas de regresión

Estos problemas pueden ser minimizados por la adopción de la estrategia: Una hora de pruebas de
regresión. Esta estrategia:
• Intenta encontrar los incidentes más severos lo más pronto posible, al costo de encontrar los
menos severos más tarde en el ciclo de regresión
• Se adapta a los variados estilos de pruebas de regresión nombrados anteriormente
• No requiere personal adicional, equipamiento o fines de semana de trabajo

Pregúntate, ¿Y si solo tuviera una hora?

Y si un cliente te pidiera que le demuestres en una hora que la nueva versión del software está lista para
usar? ¿cuáles pruebas ejecutarías? Ahora piensa, ¿son estas las mismas pruebas que estás ahora
ejecutando en tu primera hora del ciclo de regresión?

La importancia de la primer hora

“Espera un minuto”, dices. “tengo seis semanas para ejecutar el plan de pruebas de regresión, ¿es
realmente la primer hora tan importante?” Es una palabra, sí. Encontrar los incidentes severos tan
pronto como sea posible en el ciclo de regresión le brinda al equipo de desarrolladores poder pensar
una corrección completa, no solo una rápida.
La retroalimentación inmediata de la calidad del software mantiene al equipo de proyecto con el
objetivo a la vista, el cual es producir rápido software de alta calidad. Además, la retroalimentación
inmediata previene que se desvíen recursos de desarrollo a otros proyectos.

La retroalimentación inmediata le da a quienes gestionan el proyecto el máximo tiempo posible para

reaccionar a los problemas. A veces es necesario bajar las expectativas del cliente. Conociendo esto tan
pronto como sea posible hace un trabajo difícil más sencillo.
La retroalimentación inmediata le da al equipo de testing más conciencia de las áreas problemáticas en
la versión actual del software. Guía a los testers a evitar pruebas más profundas de una funcionalidad
hasta que sea corregida. Declarar a la última versión “muerta a la llegada” puede sacar presión al equipo
de testing. En vez estar varios días ejecutando pruebas de bajo valor, pruebas que tendrán que ser
ejecutadas nuevamente, pueden utilizar la mayoría del tiempo ejecutando, automatizando y mejorando
pruebas de regresión de alto valor.

Cómo elegir las pruebas correctas para la primera hora

La filosofía de una hora de pruebas de regresión es muy diferente de la filosofía clásica de pruebas de
regresión- En vez de metódicamente validar que cada una de las funcionalidades cumple la
especificación de requerimientos del producto, el enfoque de la primera hora de pruebas intenta
encontrar los problemas severos de la versión lo más rápido posible. Las pruebas de regresión a elegir
en la primer hora varía dependiendo del tipo de producto, madurez, estabilidad del software y
disponibilidad de recursos. Las siguientes preguntas ayudarán a seleccionar las pruebas adecuadas para
la primera hora de pruebas del producto.

Pruebas enfocadas al cliente

Primero, considera el uso típico del producto de comienzo a fin y asegúrate que ese uso está probado.
Piensa en global, pruebas macroscópicas del producto. ¿Cuáles pruebas serán las más significativas para
tus clientes? ¿Cómo el producto se ajusta a las situaciones y expectativas del cliente? ¿Cuál es el nombre
del producto? Las primeras pruebas deberían asegurar que el producto está a la altura de su nombre.
¿Cuáles funcionalidades tendrán mayor impacto en el cliente si no funcionan? ¿si los datos almacenados
se pierden? ¿si la seguridad es comprometida? ¿si el servicio no está disponible? Estas funcionalidades
críticas deben ser probadas en la primera hora.

Pruebas complejas y difíciles

¿Cual escenario de uso podrá decirte que la mayoría y más importantes funcionalidades están
funcionando? Asegúrate que el escenario sea realista con configuraciones basadas en el cliente. Si no
hay un único escenario, prueba los tres escenarios más usados por el cliente. Considera cuales test de
alto nivel pueden detectar problemas que contengan varias pruebas unitarias o funcionales.
¿Cuales funcionalidades pueden ser probadas juntas? En vez de pruebas de regresión de funcionalidades
aisladas, usa una mezcla de funcionalidades compatibles. Finalmente, ¿cuáles funcionalidades son las
más complejas ¿cuáles usos son los más dinámicos o los más desafiantes? ¿cuáles pruebas son las más
difíciles de ejecutar o tienen el menor margen de repuesto?

Pruebas globales
Ahora da un paso atrás y mira la imagen global. Asegúrate que pruebes la performance del sistema
general en usos de grandes escalas. ¿Cuáles son las métricas de performance más importantes? ¿Cuáles
pruebas de performance pueden ser usadas como “benchmarks” de otras funcionalidades? ¿Cuales
pruebas mostrarán rápidamente incidentes de memoria, CPU, o uso de recursos?

Pruebas que esperamos que fallen

¿Cuáles funcionalidades han sido históricamente un problema para el producto? ¿Donde han sido
detectados y corregidos los incidentes de mayor prioridad?
Hay áreas que tienen que ser probadas en ciclos tempranos de regresión. ¿Cuáles pruebas de regresión
son más probables que fallen basados en los cambios que se han hecho? Usa tu experiencia en testing e
intuición para seleccionar los casos de prueba de regresión que tienen más probabilidad de fallar.
¿Cuáles son las funcionalidades más nuevas en el ciclo de pruebas de regresión? Estas usualmente
tienen problemas que han dejado escapar instancias anteriores de testing El objetivo global es probar la
versión del software tan profundo y rápido como sea posible. Estas pruebas pueden llevar más de una
hora, pero intenta priorizar y seleccionar las pruebas que proveerán información esencial sobre la
calidad de la versión del software.

Resumiendo
Antes de empezar cualquier prueba de regresión es crítico probar la corrección de incidentes, nuevas
funcionalidades u otras modificaciones sustanciales de funcionalidades existentes en esta última
versión.
Estos cambios son la razón por la que se construyó la versión, si no están bien, ya sabes que habrá otra
versión.
Inserta las pruebas de regresión de una hora antes de las pruebas de regresión pero después de probar
las nuevas funcionalidades.
Prueba las razones por las que se creó la versión:
• Prueba la corrección de incidentes y prueba los probables incidentes que se pudieron introducir
con la corrección
• Prueba toda nueva funcionalidad usando el plan de pruebas para nuevas funcionalidades de una
hora
Realiza una hora de pruebas de regresión
• Selecciona pruebas de performance, carga y capacidad
• Selecciona pruebas de interoperabilidad y compatibilidad
• Selecciona pruebas de “backup and restore” de la base de datos
• Selecciona pruebas de redundancia, seguridad e integridad de datos
• Selecciona pruebas funcionales
Continúa con el testing de regresión
• Ejecuta pruebas de humo o de sensatez (“sanity tests”)
• Ejecuta pruebas de carga, capacidad, interoperabilidad y performance
• Ejecuta pruebas de estrés, inyección de fallas, redundancia y de longevidad
• Ejecutar pruebas detalladas de casa funcionalidad por pruebas clásicas de regresión

Continuamente optimiza tu primera hora de pruebas de regresión a medida que van apareciendo
incidentes, son agregadas nuevas funcionalidades y se mejoran las herramientas de testing.

Evalúa tu estrategia actual de pruebas de regresión

Ahora que tienes seleccionada una lista de pruebas candidatas para la primer hora de pruebas de
regresión, compárala con las pruebas que actualmente ejecutas en la primer hora de testing de
regresión. ¿Tu plan de pruebas de regresión actual es una secuencia centrada en las pruebas o en el
cliente? Tus primeras pruebas deben enfocarse en escenarios del usuario de complejidad y gran escala.
¿Tu actual plan de pruebas de regresión se actualiza integrando las pruebas de nuevas funcionalidades?
¿las pruebas de las nuevas funcionalidades están al final del plan de pruebas, esperando a que todas las
anteriores sean ejecutadas?
Luego de enfocarse en la primera hora de pruebas, pregúntate que quieres lograr en la primera hora de
pruebas, las primeras ocho horas y la primera semana.
Asegúrate que priorizas y reorganizas tus casos de prueba, o sea que si te preguntan si pueden liberar
una versión unos días antes de que todos las pruebas de regresión se ejecuten, todos las pruebas críticas
ya fueron ejecutadas.

Pruebas de humo (“smoke tests”) y de “sensatez” (“sanity tests”)

La hora de pruebas de regresión tiene similitudes con otros dos tipos de prueba de regresión, pruebas
de humo y de “sensatez”, pero son diferentes.
Las pruebas de humo usualmente refieren a pruebas superficiales, como:
• ¿El software se instala y corre?
• ¿Todas las ventanas y menues están accesibles?
• ¿Se puede acceder a todos los objetos?
El enfoque de una hora de pruebas de regresión está más enfocado y no reemplaza a las pruebas de
humo. Si es posible, las pruebas de humo pueden ser ejecutadas en paralelo con la hora de pruebas de
regresión. Si no es posible, inmediatamente después de la hora de pruebas de regresión.
Las pruebas de “Sensatez” usualmente se refieren a un conjunto pequeño de pruebas que verifican las
funcionalidades básicas del software, como ser:
• Cálculos simples provén resultados correctos
• Funcionan correctamente las funciones básicas
• Las funcionalidades, individualmente, funcionan correctamente

Típicamente no hay pruebas de capacidad, escala o performance involucrados en las pruebas de

“sensatez”. Estas pruebas proveen el punto de partida para pruebas de regresión más profundas de
cada funcionalidad. Pueden ser ejecutadas luego que las pruebas de una hora de pruebas de regresión
son finalizadas.

Nuevas funcionalidades
Si nuevas funcionalidades son introducidas durante el ciclo de pruebas de regresión, denle fuerte en la
primera hora, sacudiendo cualquier problema mayor en el diseño. Luego que sobreviven las nuevas
funcionalidades a las pruebas, metódicamente prueba los detalles de las nuevas funcionalidades usando
pruebas completas para la nueva funcionalidad.

Resumen
En el enfoque de una hora de testing de regresión, luego que se libera una nueva versión, se ejecutan
pocas pruebas complejas e importantes, en la primera hora, con el objetivo de encontrar los grandes
incidentes de forma temprana. Los variados enfoques de testing de software pueden obtener todos los
beneficios de la estrategia de una hora de testing de regresión, sea un equipo de testing que usa una
estrategia tradicional, ágil o exploratoria. Requiere ligeros cambios en la forma de pensar para la
primera hora de pruebas, pero puede ahorrar días o semanas de pruebas de regresión repetitivas e
incrementa la calidad global del producto.