Estos cuatro términos se mezclan con frecuencia, lo que genera expectativas distintas sobre el alcance y discusiones sobre las palabras. En la práctica, acordar un significado compartido dentro del equipo importa más que debatir la definición correcta del manual.
Pruebas smoke
Las pruebas smoke determinan rápidamente si el sistema funciona de forma general y es apto para seguir probándolo o utilizarlo. Suelen incluir los recorridos correctos más críticos: arranque, inicio de sesión, navegación básica, creación de una entidad principal y disponibilidad de la API principal.
Pruebas sanity
Las pruebas sanity son una comprobación reducida y dirigida a un cambio o una zona problemática concreta. Por ejemplo, después de un pequeño cambio en el cálculo de descuentos, el equipo verifica los escenarios relacionados y las zonas cercanas, en lugar de todo el producto.
Pruebas de regresión
Las pruebas de regresión vuelven a comprobar funcionalidades existentes para confirmar que los cambios nuevos no han roto el comportamiento anterior. Suelen tener mayor amplitud que smoke o sanity y se orientan por los riesgos conocidos del producto.
Pruebas de confirmación
Volver a probar un defecto, también llamado prueba de confirmación, comprueba una corrección concreta: ¿se ha resuelto el problema en el escenario donde se detectó? No sustituye a las pruebas de regresión, porque no determina qué otros elementos pueden haberse visto afectados.
Diferencias prácticas
- →Smoke: ¿esta compilación es apta para continuar las pruebas?
- →Sanity: ¿la zona concreta sigue comportándose como se espera después de un cambio local?
- →Confirmación: ¿se corrigió este defecto concreto?
- →Regresión: ¿los cambios afectaron a otras funcionalidades?
Recomendación práctica
- →Documenta un vocabulario compartido para que todo el equipo entienda el alcance de la misma forma.
- →Organiza las pruebas de regresión alrededor del riesgo, no de una selección arbitraria de casos antiguos.
- →No consideres que volver a probar el defecto basta como evidencia para publicar cuando el cambio afecta a zonas dependientes.
Elegir según la finalidad: una entrega con una corrección de descuentos
Requisito ficticio DISC-1: aplicar un descuento del 10% cuando el subtotal de productos sea de al menos 10000 céntimos. Un defecto notificado utilizaba > en lugar de >=, por lo que una cesta de 10000 céntimos no recibía descuento. Todos los importes siguientes producen resultados en céntimos enteros; otros importes necesitan una regla de redondeo explícita. La entrega modifica este comparador en una función compartida de cálculo del total.
Comprobación Objetivo Desencadenante Alcance Ejemplo
Smoke ¿La versión permite continuar las pruebas? Nuevo despliegue Conjunto pequeño de funciones críticas La aplicación abre, funciona el acceso, carga el catálogo y abre la compra
Sanity (convención de este equipo) ¿El área modificada se comporta razonablemente? Corrección pequeña y específica Entorno cercano al cambio Subtotales 9900 / 10000 / 10100 producen 9900 / 9000 / 9090
Retest / confirmación ¿Se corrigió el defecto informado? Corrección de una incidencia conocida Reproducción original y resultado esperado La misma cesta de 10000 céntimos devuelve ahora 9000
Regresión ¿El cambio dañó comportamientos existentes? Cambio con impacto potencial Funciones relacionadas y dependientes seleccionadas por riesgo Pedidos guardados, facturas y cálculos de reembolso siguen coincidiendo con sus expectativas aprobadasUna entrega, cuatro preguntas diferentes
Primero ejecuta el smoke del entorno. Si no se abre el proceso de compra, registra un bloqueo; un despliegue fallido no demuestra que la corrección del comparador sea incorrecta. Después repite exactamente la configuración, la cuenta, la moneda y la entrada del defecto en la nueva compilación: 10000 debe producir 9000. Eso es confirmación. A continuación, comprueba los valores cercanos 9900 y 10100 con el conjunto focalizado; el equipo puede llamar sanity a estas pruebas.
Para la regresión, examina quién llama al cálculo compartido antes de seleccionar las pruebas. Incluye los totales de pedidos guardados, los de facturas y cualquier proceso de reembolso que realmente invoque la función. Contrasta cada uno con un resultado esperado acordado y registrado para sus propias reglas; no supongas que un reembolso es automáticamente del 90% ni que todos los consumidores comparten DISC-1. Añade como control una cesta sin descuento que antes fuera válida. La amplitud depende de las dependencias y del riesgo de negocio, no de una regla fija sobre el número de pruebas.
Una pequeña demostración ejecutable
Guarda el código como release_check_selection.py y ejecuta python3 release_check_selection.py. Salida esperada: Known defect reproduced; confirmation and three focused checks passed. Este script demuestra únicamente la aritmética y la lógica de selección: no ejecuta un smoke de la aplicación ni el conjunto de regresión de funcionalidades dependientes.
def old_total(cents):
return cents * 9 // 10 if cents > 10000 else cents
def fixed_total(cents):
return cents * 9 // 10 if cents >= 10000 else cents
# Values below produce whole-cent results; no rounding rule is inferred.
assert old_total(10000) == 10000
assert fixed_total(10000) == 9000
for cents, expected in [(9900, 9900), (10000, 9000), (10100, 9090)]:
assert fixed_total(cents) == expected
print("Known defect reproduced; confirmation and three focused checks passed")Registrar los límites de las evidencias
Un caso puede pertenecer a más de un conjunto: la comprobación de 10000 céntimos es evidencia de confirmación del defecto y también una prueba útil para futuras regresiones. No cuentes la ejecución duplicada como cobertura adicional del comportamiento. Registra la compilación, la finalidad, el resultado obtenido y el riesgo no cubierto para que se entienda qué significa «superado».
Sanity tiene significados distintos entre equipos y a veces se utiliza como sinónimo de smoke. Define su alcance localmente en lugar de tratar esta tabla como una clasificación obligatoria. Confirmación y regresión responden a preguntas distintas; corregir la reproducción original no demuestra que el comportamiento cercano siga igual.
Ejercicio: se supera la prueba de confirmación exacta de 10000 céntimos, pero las facturas siguen mostrando 10000 después de que el proceso de compra guarde 9000. ¿Puede declararse correcta la entrega? No. El defecto original puede estar corregido y, al mismo tiempo, fallar una prueba de regresión de una funcionalidad dependiente. Registra ambos resultados e investiga la incoherencia en lugar de convertir una confirmación correcta en un veredicto sobre la entrega.
Seguir aprendiendo
Crear una estrategia de regresión basada en riesgos
Recopilar evidencias de la entrega