Los distintos tipos de pruebas de software

1. 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.

2. 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.

3. 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 dicten los requisitos del producto.

4. Pruebas de extremo a extremo

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.

5. 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.

6. 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.

7. 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.

Cómo automatizar las pruebas

Para automatizar las pruebas, primero hay que grabarlas en un programa mediante un marco de pruebas que se adapte a la aplicación. PHPUnit, Mocha y RSpec son ejemplos de marcos de pruebas que se pueden usar para PHP, JavaScript y Ruby, respectivamente. Existen numerosas opciones para cada idioma, de modo que puedes indagar un poco y pedir a una comunidad de desarrolladores que averigüe cuál sería el mejor marco para ti.

Cuando las pruebas se pueden ejecutar mediante un script desde tu terminal, puedes hacer que se ejecuten de forma automática a través de un servidor de integración continua, como Bamboo, o usar un servicio en la nube como Bitbucket Pipelines. Estas herramientas supervisan tus repositorios y ejecutan tu conjunto de pruebas cuando se hayan aplicado nuevos cambios en el repositorio principal.

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.

Nota sobre las pruebas

No podemos terminar esta guía sin hablar del objetivo de las pruebas. Aunque es importante probar que los usuarios pueden utilizar la aplicación (iniciar sesión, guardar un objeto...), resulta igualmente importante probar que la aplicación no se colapsa cuando se introducen datos incorrectos o se realizan acciones inesperadas. Hay que anticiparse a lo que ocurrirá cuando un usuario cometa un error tipográfico, intente guardar un formulario incompleto o utilice la API equivocada. Hay que comprobar si alguien puede poner en riesgo los datos con facilidad o acceder a un recurso que no debe. En una buena serie de pruebas, se debe intentar colapsar la aplicación y ayudar a conocer sus límites.

Por último, las pruebas también son código. Así que no te olvides de ellas durante la revisión de este, ya que puede que sean el último paso para llegar a la producción.

Open DevOps de Atlassian es una plataforma de cadena de herramientas abierta con la que podrás compilar una canalización de desarrollo basada en CD con tus herramientas favoritas. Descubre cómo Atlassian y las herramientas de terceros pueden integrar pruebas en tu flujo de trabajo con nuestros tutoriales sobre pruebas de DevOps.