0809-08-12346 Ervin A.
Santos Ramirez
Aseguramiento de la calidad de Software
La siguiente actividad es para que expliquen basado a lo visto en clase los tipos y modelos
de pruebas con ejemplos que ustedes puedan recomendar a una empresa.
Pruebas unitarias
Las pruebas unitarias son de muy bajo nivel y se realizan cerca de la fuente de la
aplicación. Consisten en probar métodos y funciones individuales de las clases,
componentes o módulos que usa tu software. En general, las pruebas unitarias son
bastante baratas de automatizar y se pueden ejecutar rápidamente mediante un servidor de
integración continua.
Pruebas de integración
Las pruebas de integración verifican que los distintos módulos o servicios utilizados por tu
aplicación funcionan bien en conjunto. Por ejemplo, se puede probar la interacción con la
base de datos o asegurarse de que los microservicios funcionan bien en conjunto y según lo
esperado. Estos tipos de pruebas son más costosos de ejecutar, ya que requieren que
varias partes de la aplicación estén en marcha.
Pruebas funcionales
Las pruebas funcionales se centran en los requisitos empresariales de una aplicación. Solo
verifican el resultado de una acción y no comprueban los estados intermedios del sistema al
realizar dicha acción.
A veces, se confunden las pruebas de integración con las funcionales, ya que ambas
requieren que varios componentes interactúen entre sí. La diferencia es que una prueba de
integración puede simplemente verificar que puedes hacer consultas en la base de datos,
mientras que una prueba funcional esperaría obtener un valor específico desde la base de
datos, según dictan los requisitos del producto.
Pruebas integrales
Las pruebas integrales replican el comportamiento de un usuario con el software en un
entorno de aplicación completo. Además, verifican que diversos flujos de usuario funcionen
según lo previsto, y pueden ser tan sencillos como cargar una página web o iniciar sesión, o
mucho más complejos, como la verificación de notificaciones de correo electrónico, pagos
en línea, etc.
Las pruebas integrales son muy útiles, pero son costosas de llevar a cabo y pueden resultar
difíciles de mantener cuando están automatizadas. Se recomienda tener algunas pruebas
integrales clave y depender más de pruebas de menor nivel (unitarias y de integración) para
poder detectar rápidamente nuevos cambios.
Pruebas de aceptación
Las pruebas de aceptación son pruebas formales que verifican si un sistema satisface los
requisitos empresariales. Requieren que se esté ejecutando toda la aplicación durante las
pruebas y se centran en replicar las conductas de los usuarios. Sin embargo, también
pueden ir más allá y medir el rendimiento del sistema y rechazar cambios si no se han
cumplido determinados objetivos.
Pruebas de rendimiento
Las pruebas de rendimiento evalúan el rendimiento de un sistema con una carga de trabajo
determinada. Ayudan a medir la fiabilidad, la velocidad, la escalabilidad y la capacidad de
respuesta de una aplicación. Por ejemplo, una prueba de rendimiento puede analizar los
tiempos de respuesta al ejecutar un gran número de solicitudes, o cómo se comporta el
sistema con una cantidad significativa de datos. Puede determinar si una aplicación cumple
con los requisitos de rendimiento, localizar cuellos de botella, medir la estabilidad durante
los picos de tráfico y mucho más.
Pruebas de humo
Las pruebas de humo son pruebas básicas que sirven para comprobar el funcionamiento
básico de la aplicación. Están concebidas para ejecutarse rápidamente, y su objetivo es
ofrecerte la seguridad de que las principales funciones de tu sistema funcionan según lo
previsto.
Las pruebas de humo pueden resultar útiles justo después de realizar una compilación
nueva para decidir si se pueden ejecutar o no pruebas más caras, o inmediatamente
después de una implementación para asegurarse de que la aplicación funciona
correctamente en el entorno que se acaba de implementar.
Pruebas exploratorias
Cuantas más funciones y mejoras se apliquen en tu código, más deberás someterlo a
pruebas para garantizar que todo el sistema funciona correctamente. Entonces, para cada
error que soluciones, lo mejor es comprobar que no se vuelvan a producir en nuevas
versiones. La automatización es clave para hacer esto posible, y escribir pruebas antes o
después pasará a formar parte de tu workflow de desarrollo.
Entonces, la pregunta es si aún merece la pena realizar pruebas manuales. Se podría decir
que sí, y que puede que lo mejor sea realizar pruebas exploratorias para descubrir errores
que no sean obvios.
Una sesión de pruebas exploratorias no debe durar más de dos horas y debe tener un
alcance claro para ayudar a los testers a centrarse en un área específica del software. Una
vez que todos los testers hayan recibido la información, deben utilizar diversas acciones
para comprobar cómo se comporta el sistema.
