Los distintos tipos de pruebas de software

Compara distintos tipos de pruebas de software, como las pruebas de unidades, de integración, funcionales, de aceptación y mucho más.

Sten Pittet Sten Pittet

Hay muchos tipos distintos de pruebas que puedes usar para asegurarte de que los cambios en el código funcionan como se espera; sin embargo, no todas son iguales. Aquí veremos en qué se diferencian las principales prácticas de pruebas.

Comparación entre pruebas manuales y automatizadas

Cuando el nivel es alto, debemos distinguir entre las pruebas manuales y las automatizadas. Las pruebas manuales se realizan en persona, haciendo clic a través de la aplicación o interactuando con el software y las API con las herramientas adecuadas. Resultan muy costosas, ya que requieren que alguien configure un entorno y ejecute las pruebas, y pueden ser propensas a errores humanos, ya que el encargado puede cometer erratas u omitir pasos en el script de la prueba.

Por otro lado, las pruebas automatizadas se realizan a través de una máquina que ejecuta un script de prueba escrito con antelación. Estas pruebas pueden variar mucho en cuanto a complejidad, desde comprobar un único método en una clase hasta comprobar que al realizar una secuencia de acciones complejas en la IU se generan los mismos resultados. Las pruebas automatizadas son mucho más potentes y fiables que las manuales, pero su calidad depende de lo bien que se hayan escrito los scripts de las pruebas. Si estás empezando con las pruebas, puedes leer nuestro tutorial sobre integración continua para obtener ayuda con tu primera serie de pruebas. ¿Necesitas más herramientas para hacer pruebas? Echa un vistazo a estos tutoriales sobre pruebas de DevOps.

Las pruebas automatizadas son un componente clave de la integración continua y la entrega continua, y constituyen una forma excelente de escalar tu proceso de control de calidad a medida que añades nuevas funciones a tu aplicación. Sin embargo, sigue siendo útil realizar pruebas manuales mediante las llamadas pruebas exploratorias, como veremos en esta guía.

Los diferente tipos de pruebas

Pruebas unitarias

Las pruebas unitarias son de muy bajo nivel, como la fuente de tu aplicación. Están compuestas de pruebas de 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 dicten 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 ejecutadas para verificar si un sistema satisface los requisitos empresariales. Requieren que toda la aplicación esté en marcha y que se centre 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 comprueban el comportamiento del sistema cuando está sometido a una carga importante. Estas pruebas no son funcionales y pueden tener la forma variada de entender la fiabilidad, la estabilidad y la disponibilidad de la plataforma; por ejemplo, puede estar observando tiempos de respuesta al ejecutar un gran número de solicitudes, o cómo se comporta el sistema con una cantidad significativa de datos.

Por su naturaleza, las pruebas de rendimiento pueden ser bastante costosas de implementar y ejecutar, pero pueden ayudarte a entender si los nuevos cambios van a degradar tu sistema.

Pruebas de humo

Las pruebas de humo son pruebas básicas que sirven para comprobar la funcionalidad básica de la aplicación. Están concebidas para ejecutarse rápido, 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

Una persona puede ejecutar todas las pruebas mencionadas arriba, pero sería una tarea muy costosa y contraproducente. Como humanos, contamos con una capacidad limitada para realizar una gran cantidad de acciones de forma repetible y fiable. Sin embargo, una máquina puede hacerlo rápidamente y comprobará que la combinación de usuario y contraseña para iniciar sesión funciona hasta 100 veces sin quejarse.

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.

Los envíos al repositorio se verifican gracias a Bitbucket Pipelines

Si estás empezando con las pruebas, puedes leer nuestro tutorial sobre integración continua para obtener ayuda con tu primera serie de pruebas.

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.

De este modo, la pregunta es si aún merece la pena realizar pruebas manuales. Se podría decir que sí, y que deben centrarse en lo que se conoce como pruebas exploratorias, cuyo objetivo reside en detectar errores que no son 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, les corresponde a ellos probar varias acciones para comprobar cómo se comporta el sistema. Este tipo de pruebas suelen salir caras, pero resultan bastante útiles para descubrir incidencias en la interfaz de usuario o verificar flujos de trabajo complejos de los usuarios. Merece la pena ponerlas en práctica, sobre todo cada vez que se añade una nueva capacidad significativa a la aplicación para ayudar a entender cómo se comporta en casos extremos.

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 (puedo iniciar sesión, puedo guardar un objeto...), resulta igualmente importante probar que el sistema no se modifica 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 modificar la aplicación y ayudar a conocer su límite.

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.

A continuación
Exploratory testing