Close

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.

Foto de Sten Pittet
Sten Pittet

Escritor colaborador


Hay muchos tipos de técnicas de pruebas de software que puedes utilizar para asegurarte de que los cambios en el código funcionen según lo esperado. Sin embargo, no todas las pruebas son iguales. En este artículo veremos en qué se diferencian algunas prácticas de pruebas.

Comparación entre pruebas manuales y automatizadas


Es importante 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 tester puede añadir 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 la prueba escrito con antelación. Estas pruebas pueden variar en cuanto a complejidad, desde comprobar un único método de una clase hasta comprobar que se consiguen los mismos resultados al realizar una secuencia de acciones complejas en la interfaz. 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 en esto de las pruebas, puedes leer nuestro tutorial sobre integración continua para obtener ayuda con tu primera serie de pruebas. Si 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.

Ver la solución

Desarrolla y pon en marcha software con Open DevOps

Material relacionado

Pruebas automatizadas para DevOps

Los diferente tipos de pruebas


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

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.

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.

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.

Sten Pittet
Sten Pittet

Llevo 10 años en el negocio del software desempeñando diversas funciones, desde el desarrollo hasta la gestión de productos. Tras pasar los últimos 5 años en Atlassian trabajando en herramientas para desarrolladores, ahora escribo sobre compilación de software. Fuera del trabajo, me dedico a perfeccionar mis habilidades como padre con el maravilloso hijo que tengo.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

La comunidad de DevOps

Ilustración de Devops

Leer el blog

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up

A continuación
Exploratory testing