El vocabulario mínimo para que un equipo pueda discutir su estrategia de pruebas sin que cada persona entienda algo distinto.
No es una página de opinión. Es el diccionario, con una advertencia por delante: la industria no se pone de acuerdo en estos nombres, hasta el punto de que Google decidió clasificar sus pruebas por tamaño en vez de por nombre para no entrar en la discusión. Lo que sigue es lo más canonizado que hay, y aun así cada equipo tiene que acordar una vez qué significa cada palabra en su casa.
Se confunden constantemente y no son lo mismo.
<aside> 1️⃣
Un documento. Describe alcance, enfoque, recursos y calendario del esfuerzo de prueba. Es organizativo, no ejecutable.
</aside>
<aside> 2️⃣
Un conjunto de casos agrupados para ejecutarse juntos.
</aside>
<aside> 3️⃣
Un escenario específico, con entradas, pasos y resultado esperado.
</aside>
Una observación práctica que a muchos equipos les ahorra un artefacto entero:
(CI/CD) la suite ya no es un documento, es una etiqueta en el código.@smoke sobre el test, y el pipeline corre lo que tenga esa etiqueta.Si un equipo mantiene planes de prueba como documentos aparte del repositorio, ahí hay dos fuentes de verdad que se van a desincronizar.
Este es el eje que casi todos usan y el que más discusiones genera.
| Nivel | Qué abarca |
|---|---|
| Test Unitario | Una unidad de código aislada de sus dependencias |
| Test de Integración | Varios componentes trabajando juntos |
| Test de Sistema o end-to-end | El sistema completo, atravesado por su interfaz real |
| Test de Aceptación | Definido por propósito, no por alcance: verifica que el sistema cumple lo acordado |
Justamente para evitar la ambigüedad de los nombres anteriores, Google clasifica por lo que el test puede hacer, no por lo que abarca conceptualmente: