Acabas de recibir una nueva compilación y el equipo pregunta si está lista para probarse. ¿Ejecutas toda la suite de regresión o haces antes una comprobación rápida? Aquí aparece la duda de smoke testing vs sanity testing.

Los dos términos se confunden a menudo, incluso en entrevistas, así que esta guía de smoke testing vs sanity testing lo mantiene sencillo. Ambos actúan como filtros rápidos, pero responden a preguntas distintas en momentos distintos.

¿Qué es el smoke testing?

El smoke testing es un conjunto corto de pruebas que confirma que las funciones más críticas de una compilación funcionan. El nombre viene del hardware: enciendes el dispositivo y miras si sale humo. Si la aplicación no arranca o los usuarios no pueden iniciar sesión, no tiene sentido ejecutar cientos de pruebas detalladas. También se llama pruebas de verificación de compilación. El glosario de ISTQB recoge las definiciones estándar.

Un ejemplo real de smoke test

En una tienda online, una suite de smoke podría abrir la página de inicio, iniciar sesión, buscar un producto, añadirlo al carrito y llegar a la página de pago. No prueba todos los métodos de pago ni las reglas de cupones; solo demuestra que el camino principal está vivo.

• La aplicación arranca y la página de inicio carga
• El inicio y el cierre de sesión funcionan
• La búsqueda o navegación principal funciona
• Se completa una transacción clave
• No aparecen errores críticos en los registros

¿Qué es el sanity testing?

El sanity testing es una comprobación enfocada tras un cambio menor, como la corrección de un error. Confirma que el cambio funciona como se esperaba y que la funcionalidad muy relacionada sigue comportándose con sentido. Normalmente se ejecuta sobre una compilación que ya pasó el smoke testing.

Un ejemplo real de sanity test

Los desarrolladores corrigen un error por el que el campo del código de descuento rechazaba códigos válidos. Una prueba de sanity aplica varios códigos válidos e inválidos, confirma que los totales se actualizan bien y comprueba que los totales del carrito y del pago siguen coincidiendo. No volverías a probar el inicio de sesión ni la búsqueda.

Smoke testing vs sanity testing: tabla comparativa

Esta tabla de smoke testing vs sanity testing es la forma más rápida de recordar qué prueba ejecutar y cuándo.

Dónde encajan en el proceso de pruebas

Un flujo habitual es: nueva compilación, smoke test, pruebas funcionales, sanity test en las correcciones y pruebas de regresión antes del lanzamiento. En cualquier flujo de smoke testing vs sanity testing, el smoke protege tu tiempo y la regresión protege tu producto. Para ver el panorama completo, consulta nuestra guía de buenas prácticas de pruebas end-to-end.

Las pruebas de regresión vuelven a ejecutar un amplio conjunto de pruebas existentes para asegurar que nada más se ha roto. Piensa en el smoke como la revisión de la puerta, el sanity como la revisión puntual y la regresión como la inspección completa.

Cómo automatizar los smoke tests

La mayoría de los frameworks permiten etiquetar pruebas. Con Playwright puedes marcar las pruebas críticas con una etiqueta y ejecutar solo esas; consulta la documentación sobre anotaciones y etiquetas de pruebas.

import { test, expect } from '@playwright/test';

test('la página de inicio carga @smoke', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveTitle(/Shop/);
});

test('el usuario puede iniciar sesión @smoke', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('user@example.com');
  await page.getByLabel('Password').fill('Secret123');
  await page.getByRole('button', { name: 'Log in' }).click();
  await expect(page).toHaveURL(/dashboard/);
});

npx playwright test --grep @smoke

Ejecuta la suite de smoke como primer trabajo tras el despliegue en un entorno de pruebas y detén el pipeline si falla. Nuestra guía de GitHub Actions CI/CD te enseña cómo, y la lista de las mejores herramientas de automatización de pruebas de 2026 te ayuda a elegir un framework.

Checklist de smoke y sanity testing

• Mantén la suite de smoke por debajo de 10 minutos, idealmente de 5.
• Cubre solo los caminos críticos para el negocio.
• Haz el resultado binario: pasa significa continuar, falla significa rechazar la compilación.
• Escribe un objetivo de una línea para cada prueba de sanity antes de empezar.
• Registra qué cambió para poder elegir escenarios relacionados.
• Revisa ambas suites cada sprint y elimina las comprobaciones que ya no importen.

Errores comunes que debes evitar

• Dejar crecer la suite de smoke hasta que se convierte en una suite de regresión lenta.
• Saltarse las comprobaciones de sanity porque la corrección “parece pequeña”.
• Usar pruebas inestables en la puerta de control, lo que enseña al equipo a ignorar los fallos.
• Confundir smoke testing vs sanity testing en los informes, lo que causa confusión en las reuniones diarias y en las entrevistas.

Reflexiones finales

El smoke testing pregunta “¿merece la pena probar esta compilación?” y el sanity testing pregunta “¿tiene sentido este cambio?”. Entender smoke testing vs sanity testing mantiene enfocado el tiempo de regresión y hace los lanzamientos más seguros. Etiqueta entre cinco y diez pruebas críticas como smoke, ejecútalas en cada compilación y aplica una breve checklist de sanity cada vez que llegue una corrección.

Preguntas frecuentes

Sigue aprendiendo