Diferencia entre la prueba unitaria, la prueba de sistema, la prueba de integración y la prueba de regresión

Prueba unitaria

Las pruebas unitarias se llevan a cabo en las unidades individuales de un programa y se ha modificado o introducido por primera vez. Cada prueba que tenga como objetivo validar un solo módulo debe presentarse con la documentación técnica conexa adjunta, que contendrá, entre otra información, los resultados que se espera que proporcione el módulo probado. Las pruebas unitarias se centran en la funcionalidad y fiabilidad del software y se realizan en una fase de prueba previa a la integración del sistema. Si se descubriera un defecto durante una prueba unitaria, se evaluaría su naturaleza e impacto en el sistema general; el objetivo es resolverlo antes de que se apruebe el módulo probado.

Prueba del sistema

La prueba del sistema se realiza en todos los componentes y módulos nuevos o modificados que caracterizan a un producto. El objetivo es comprender cómo interactúan los diferentes bloques unitarios entre sí y si proporcionan los resultados requeridos en general; se hace hincapié en validar y verificar los requisitos del sistema y en cómo los módulos individuales funcionan juntos cuando están conectados. Por lo general, las pruebas en el sistema son más de una: el primero merece una mención especial (normalmente llamado “prueba de humo”), que tiene como objetivo estudiar en términos generales cómo se comporta el programa y si las funciones principales se llevan a cabo correctamente, sin detenerse en los detalles. Las pruebas en todo el sistema llevan mucho tiempo, ya que es necesario realizar un gran número para analizar todos los escenarios posibles que puedan ocurrir; el Plan de pruebas en esta coyuntura juega un papel muy delicado, ya que contiene la descripción de los casos de prueba, la secuencia en la que deben realizarse y la documentación necesaria para enumerar los resultados. Cuando se descubre y corrige un error, se debe volver a realizar la prueba para garantizar que las correcciones realizadas no hayan tenido ninguna influencia negativa en componentes que anteriormente no tenían errores (la prueba de regresión ya mencionada anteriormente).

Prueba de integración

Después de haber realizado las diversas pruebas del sistema, es necesario asegurarse de que el programa desarrollado proporciona los resultados deseados incluso si se ejecuta en entornos distintos del nativo: por lo tanto, es necesario realizar pruebas de integración, en las que el producto se prueba junto con otras interfaces y aplicaciones. A diferencia de las pruebas del sistema, en las pruebas de integración no es necesario volver a probar si se descubre un defecto después de que se ha corregido. Las pruebas de integración se dividen en diferentes grupos y se pueden realizar o no en función de la aplicación a probar:

• Prueba de compatibilidad: garantiza que la aplicación funciona con diferentes configuraciones basadas en las disponibles para el usuario
• Pruebas de rendimiento: evalúan la capacidad de la aplicación para funcionar correctamente cuando, por ejemplo, varios usuarios la utilizan simultáneamente o el número de entradas aumenta
• Pruebas de esfuerzo: prueban el funcionamiento correcto de la aplicación cuando está estresada con cargas de trabajo inusuales
• Pruebas de carga: son complementarios a las pruebas de esfuerzo y evalúan el funcionamiento de la aplicación bajo cargas de trabajo normales

Prueba de regresión

La prueba de regresión, ya mencionada en los párrafos anteriores, se realiza cada vez que se modifica el procedimiento de una pieza del programa tras la identificación de un defecto; cuando se corrige un error, surge la posibilidad de que se introduzca uno nuevo de forma involuntaria: por lo tanto, se introduce incertidumbre sobre la capacidad de la aplicación para repetir correctamente todas las funciones realizadas anteriormente. La prueba de regresión se suele llevar a cabo en paralelo con otras pruebas y puede verse como un control de calidad para garantizar que el código que acaba de modificarse continúe realizando correctamente las funciones que no se han modificado y que cumpla con los mismos requisitos verificados anteriormente . En conclusión, puede afirmarse que la prueba de regresión garantiza que el resto de la aplicación no sujeta a modificación no se vea afectado por errores derivados de la corrección de otros.