Escribe “cuáles son las etapas de las pruebas de software” en un buscador y obtendrás dos respuestas distintas. Un sitio enumera cuatro niveles, desde unitarias hasta aceptación. Otro ofrece un proceso de cinco a siete pasos, que va desde la planificación hasta el cierre. Ambas son correctas, pero difieren porque responden preguntas diferentes.
Sin embargo, si le preguntas a un tester de tu propio equipo, obtendrás una tercera respuesta que no tiene relación alguna con las anteriores, pero que también es correcta. Esa tercera respuesta nunca aparece en los resultados de búsqueda, por eso sorprende a la gente. No tiene nada que ver con el producto en su conjunto, y todo que ver con un solo bug. Cada uno de ellos pasa por una breve serie de estados. Alguien confirma que es real, un desarrollador lo corrige, y un tester verifica el resultado. Esa serie es a lo que la gente se refiere cuando dice que un bug pasó a la siguiente etapa.
Esta guía separa los tres, para que puedas distinguirlos y determinar cuál necesitas. La mayoría de las empresas tienen personal para uno o dos, por eso el tercero suele quedar de lado. Un equipo de QA dedicado cubre los tres.
¿Cuáles Son las Etapas de las Pruebas de Software? Tres Cosas Que la Gente Quiere Decir
La confusión es genuina, porque una sola frase abarca tres ideas separadas, y una fuente que explica una de ellas rara vez menciona las demás.
Niveles de prueba
Cuánto del producto se está probando a la vez
4 niveles
Primero los desarrolladores, luego los testers
El ciclo de vida de las pruebas
Cómo se planifica y ejecuta un esfuerzo de prueba
5 a 7 fases, según la fuente
El líder de QA o el gerente de pruebas
El ciclo de vida del bug
Qué le sucede a un solo bug después de que alguien lo encuentra
7 estados principales, más los que agregue tu sistema de seguimiento
A quien esté asignado el bug
Mira la columna central, donde los niveles tratan sobre alcance, el ciclo de vida trata sobre proceso, y el ciclo de vida del bug rastrea un solo defecto desde el reporte hasta el cierre. En cualquier tarde dada, tu equipo puede estar en el nivel de sistema, a mitad del ciclo de vida, y manteniendo cuarenta defectos en cuatro estados diferentes. Ninguno de esos hechos contradice a los demás.
La cantidad de etapas depende de a quién le preguntes, y cualquiera que prometa una única respuesta correcta está simplificando. La variación no es aleatoria:
- Los niveles están fijados en cuatro. Nadie argumenta en serio por un número distinto.
- El ciclo de vida no está fijado. Algunos autores separan la planificación del análisis y otros los combinan, de ahí que salgan cinco, seis y siete.
- Los estados de los bugs siguen una convención, no un estándar. Siete de ellos son casi universales, y tu sistema de seguimiento decide si hay más.
Los Cuatro Niveles de Prueba y Qué Detecta Cada Uno
Los niveles responden a la pregunta de alcance: cuánto del producto pruebas a la vez. Van desde la pieza más pequeña hasta el producto terminado con una persona real usándolo.
- Pruebas unitarias: Una función, método o clase, verificada por sí sola con todo lo que la rodea simulado. Los desarrolladores las escriben junto con el código, y se ejecutan en segundos.
- Pruebas de integración: Dos o más piezas verificadas juntas, lo que te dice si están de acuerdo sobre los datos que pasan entre ellas. Aquí es donde un inicio de sesión que funciona y una página de perfil que funciona resultan estar en desacuerdo sobre cómo se ve un ID de usuario.
- Pruebas de sistema: El producto completo ya ensamblado, verificado de principio a fin frente a lo que debía hacer. Lo ejecutan testers independientes, porque para esta etapa quieres a alguien que no lo haya construido.
- Pruebas de aceptación: Las personas que pidieron el producto decide si lo obtuvieron. Esta es la última barrera antes del lanzamiento, y responde una pregunta que ningún nivel anterior formula. Las pruebas alfa y beta se ubican aquí, junto con la aprobación formal.
Unitario
Una función o clase de forma aislada
Desarrolladores
Si las piezas funcionan juntas
Integración
Las interfaces entre piezas
Desarrolladores y testers
Si el producto terminado cumple su función
Sistema
El producto completo ya ensamblado
Testers independientes
Si los usuarios querían que se construyera así
Aceptación
Escenarios de negocio reales, por las personas que lo solicitaron
Usuarios finales, clientes, partes interesadas
Cualquier cosa que aún sea económica de corregir
Lee esa última columna de arriba hacia abajo y tendrás el argumento para ejecutar los cuatro. Cada nivel es ciego a algo que el siguiente detecta, y el costo de una corrección aumenta en cada paso. Un error de nomenclatura detectado por una prueba unitaria le cuesta a un desarrollador dos minutos. El mismo error encontrado durante la aceptación cuesta un lanzamiento.
Nada de eso cambia en móvil. Los cuatro niveles también aplican ahí, y saber en qué etapa de prueba de la app estás te dice quién debería ejecutar las verificaciones y qué tan costoso se vuelve un fallo pasado por alto.
Ejemplo: Restablecimiento de Contraseña a Través de los Cuatro Niveles de Prueba
Tomemos como ejemplo un restablecimiento de contraseña, ya que casi todo producto tiene uno y todo el mundo lo ha usado en la vida real.
Las pruebas unitarias observan las piezas pequeñas por separado. ¿El generador de tokens produce algo que nadie puede adivinar? ¿El cálculo de expiración devuelve la marca de tiempo correcta? Un desarrollador las escribe mientras construye la función, y terminan en milisegundos.
Las pruebas de integración preguntan si esas piezas concuerdan entre sí. La solicitud tiene que llegar al servicio de correo, el token tiene que sobrevivir el viaje de ida y vuelta, y la base de datos tiene que registrar que hay un restablecimiento pendiente. La mayoría de los bugs de restablecimiento de contraseña viven en esos puntos de traspaso, porque cada pieza funciona perfectamente bien por su cuenta.
Las pruebas de sistema recorren todo el trayecto como lo haría una persona. Solicitar un restablecimiento, abrir el correo, hacer clic en el enlace, elegir una nueva contraseña, iniciar sesión. Un tester también recorre los caminos para los que nadie diseñó: hacer clic en el enlace dos veces, dejar que caduque, solicitar tres restablecimientos seguidos.
Las pruebas de aceptación preguntan algo completamente distinto. ¿Esto coincide con lo que acordó el negocio? Si tu equipo de seguridad dijo que los enlaces de restablecimiento caducan después de una hora y la versión se lanza con 24, los tres niveles anteriores pasan y la función sigue estando mal.
La aceptación es el único nivel que lo detecta, por eso los cuatro se ganan su lugar. Tres pueden salir en verde mientras el producto sigue fallando en la única prueba que refleja lo que alguien realmente pidió.
Por Qué la Regresión, el Rendimiento y la Seguridad Son Tipos, No Etapas
Aquí está la distinción que evita la mayor parte de la confusión una vez que la entiendes. Una etapa es algo por lo que avanzas en orden, mientras que un tipo es un trabajo que puedes hacer en más de una de ellas. Los siguientes son tipos de prueba:
- Las pruebas de regresión no están vinculadas a ningún nivel en absoluto, ya que su trabajo es confirmar que lo que funcionaba la semana pasada sigue funcionando hoy. Ejecútalas sobre todo lo que un cambio pueda alcanzar, no solo la parte que cambió.
- Las pruebas de rendimiento pueden apuntar a un solo servicio por su cuenta o al sistema completo bajo carga real. Colócalas donde una respuesta lenta realmente te cueste algo.
- Las pruebas de seguridad pueden examinar los permisos de un solo endpoint o el producto terminado de la forma en que lo haría un atacante. Trátalas como continuas, porque un solo cambio de acceso puede abrir una brecha que ninguna prueba funcional detecte.
Así que cuando alguien pregunta a qué etapa pertenecen las pruebas de rendimiento, la respuesta honesta es que la pregunta no funciona del todo. Pertenecen a cualquier nivel que te preocupe. Por eso un plan de pruebas útil nombra tanto el nivel como el tipo.
Ciclo de Vida de las Pruebas de Software: Resumen Breve
La otra respuesta común a cuáles son las etapas de las pruebas de software es un proceso, no un conjunto de niveles. Ese proceso es el ciclo de vida de las pruebas de software, normalmente abreviado como STLC. Describe cómo se organiza un esfuerzo de prueba en lugar de qué se prueba: revisar los requisitos, planificar, construir casos de prueba, preparar un entorno, ejecutar las pruebas, y luego cerrar con un informe.
Esa secuencia merece más espacio del que este artículo puede darle, y tenemos un recorrido dedicado a ella. Nuestra guía del ciclo de vida de las pruebas de software cubre cada fase junto con sus criterios de entrada y salida.
Aquí corresponde una aclaración, porque genera discusiones reales. Esa primera fase depende de tener requisitos con los que un tester pueda trabajar, lo cual es un problema separado con su propia respuesta en nuestra guía sobre requisitos de pruebas de software. El ciclo de vida te dice cuándo se revisan los requisitos. No te dice cómo se ve uno bueno.
El Ciclo de Vida del Bug: De Nuevo a Cerrado en Siete Estados
Las pruebas encuentran bugs, sea cual sea el nivel o tipo en el que ocurra, y cada uno de ellos sigue después su propia secuencia. Esta es la tercera cosa que se llama etapas, y es la que probablemente tus desarrolladores tienen en mente.
- Nuevo del reportante: el bug queda registrado, y nadie ha confirmado todavía que sea real.
- Asignado a un responsable: la triaje lo ha aceptado y se lo ha entregado a una persona designada.
- En progreso con un desarrollador: alguien está trabajando en la corrección.
- Corregido según el desarrollador: una afirmación, no una conclusión.
- Reprueba por un tester: alguien verifica esa afirmación contra los pasos de reproducción originales.
- Verificado por la reprueba: el problema realmente desapareció.
- Cerrado y registrado: el trabajo está terminado.
Otros dos estados existen fuera de esos siete. Reabierto significa que una corrección verificada volvió a fallar, lo que suele señalar una prueba de regresión faltante en lugar de un desarrollador descuidado. Diferido significa que el equipo aceptó que el bug es real y decidió no corregirlo por ahora, lo cual es una decisión legítima siempre que alguien haya anotado por qué.
El lugar donde se encontró un bug no hace diferencia en los estados por los que pasa. Uno detectado por una prueba unitaria y otro detectado en aceptación siguen los mismos siete. Lo que cambia es cuánto cuesta cada paso para el momento en que llegas a él.
Cómo QAwerk Ejecuta Estas Etapas en la Práctica
No tratamos las pruebas como una única fase cerca del final. Nuestros ingenieros se incorporan en cualquier punto que haya alcanzado el proyecto y trabajan dentro del sprint, de modo que los cuatro niveles se ejecutan de forma continua en lugar de acumularse antes de un lanzamiento. Para el detalle semana a semana, consulta nuestra guía sobre pruebas ágiles.
En la práctica, eso significa que tomamos un producto donde sea que se encuentre. Algunos equipos nos incorporan antes de que exista una sola línea de código, mientras los requisitos todavía se están discutiendo. Otros nos entregan una versión terminada y una fecha de lanzamiento. Ambos funcionan, aunque el primero cuesta menos, por la misma razón que una prueba unitaria es más económica que un fallo de aceptación.
La calidad depende de quién la haga. Contamos con más de 30 ingenieros de QA senior con un promedio de 9 años de experiencia cada uno, y hemos identificado más de 50,000 bugs críticos en más de 300 proyectos desde 2015. Esa experiencia importa más justo en los puntos donde los niveles se vuelven ciegos: saber qué integración probablemente no concuerde, y qué escenario de aceptación a nadie se le ocurrió anotar.
Para descubrir en qué punto se encuentra realmente tu producto frente a los cuatro niveles, habla con nuestro equipo de QA. Mapearemos tu cobertura actual antes de que te comprometas a nada.
Preguntas Frecuentes
¿Cuáles son las etapas de las pruebas de software?
Tres cosas distintas, y cuál quiere decir alguien suele depender de su trabajo. Los desarrolladores se refieren a los cuatro niveles de prueba: unitaria, integración, sistema y aceptación. Los líderes de QA se refieren al ciclo de vida de las pruebas, el proceso por el que pasa un esfuerzo de prueba desde la planificación hasta la aprobación final. Cualquiera que reporte un defecto se refiere al ciclo de vida del bug, que rastrea un solo problema en lugar del trabajo en sí.
¿Cuántas etapas de pruebas de software existen?
Cuatro, cinco a siete, o siete, según el sentido al que te refieras. Hay cuatro niveles de prueba y esa cifra es estable entre fuentes. El ciclo de vida se representa con entre cinco y siete pasos. Un bug pasa por siete estados comunes más lo que tu sistema de seguimiento defina. Ninguna cifra única responde la pregunta.
¿Cuál es la diferencia entre los niveles de prueba y el STLC?
Alcance frente a proceso, y esa división se refleja en quién es responsable de cada uno. Los niveles describen cuánto del producto cubre una verificación dada, así que pertenecen a quien escribe esa verificación. El STLC describe cómo se planifica, dota de personal y aprueba todo el esfuerzo, así que pertenece al líder de QA. Ninguno de los dos limita al otro.
¿Qué es el ciclo de vida del bug?
El conjunto de estados por los que pasa un defecto entre el momento en que se reporta y el momento en que se cierra, yendo desde nuevo, pasando por asignado, en progreso, corregido, reprueba y verificado. Observar dónde se acumulan los bugs te indica dónde está atascado tu proceso. Una cola acumulada en reprueba señala la capacidad de QA, mientras que una cola acumulada en asignado señala el triaje.
¿En qué etapa deberían empezar las pruebas?
Las pruebas deberían empezar antes de que exista cualquier código, en el punto en que alguien revisa los requisitos y pregunta qué pasa cuando las cosas salen mal. Las pruebas unitarias entonces comienzan durante el desarrollo, en lugar de después de él. Esperar a una versión terminada significa que los bugs más económicos de corregir ya tienen más código construido encima.
