Glosario · Fundamentos de testing
Sanity testing (prueba de cordura)
En inglés: Sanity testing
También llamado: sanity test, prueba de cordura, pruebas de cordura, prueba de sanidad
Definición
Comprobación acotada y enfocada tras un cambio pequeño o una corrección, para confirmar que el área afectada funciona como se espera antes de seguir con pruebas más amplias.
El sanity testing (prueba de cordura) es una comprobación rápida y dirigida de que un cambio concreto funciona y de que el área que lo rodea sigue comportándose de forma razonable. Se realiza tras una corrección de bug o un cambio menor sobre un build que ya es razonablemente estable. Si la prueba de cordura falla, el build vuelve a desarrollo sin gastar tiempo en una regresión completa.
Ejemplo
Un informe de bug dice que el correo de “Olvidé mi contraseña” no se envía cuando la dirección contiene un signo más (ana+test@example.com). El desarrollador publica una corrección. Una prueba de cordura consistiría en:
- Solicitar un restablecimiento para
ana+test@example.comy confirmar que llega el correo. - Solicitar un restablecimiento para una dirección normal y confirmar que sigue funcionando.
- Seguir el enlace de restablecimiento y confirmar que se acepta la nueva contraseña.
Eso es todo. Aquí nadie revisa el carrito de compra ni el módulo de informes. Si estos pasos pasan, el build continúa hacia las pruebas de regresión.
Sanity frente a smoke testing
| Sanity testing | Smoke testing | |
|---|---|---|
| Alcance | Estrecho y algo profundo: una funcionalidad o corrección | Amplio y superficial: toda la aplicación |
| Desencadenante | Una corrección concreta o un cambio pequeño | Cada build nuevo |
| Estado del build | Ya bastante estable | Desconocido, posiblemente roto |
| Forma | A menudo sin guion, la hace un tester | Normalmente una suite automatizada con guion |
Algunos equipos describen el sanity testing como un subconjunto de las pruebas de regresión centrado en el área modificada. Es una forma razonable de verlo.
Una nota sobre la terminología
Las definiciones varían entre empresas y manuales, y algunos equipos usan “smoke” y “sanity” indistintamente. En una entrevista, explica la distinción anterior y añade que lo que importa en la práctica es que el equipo acuerde qué cubre cada comprobación y cuándo se ejecuta. Ser preciso y reconocer la ambigüedad causa mejor impresión que aferrarse a un único manual.