Estas últimas semanas hablábamos de qué son las pruebas de regresión (Pruebas de regresión. O cómo evitar que los fallos que se habían arreglado en el software vuelvan a aparecer.) y del smoke test (Smoke test: Detecta lo más pronto posible si los elementos críticos de la aplicación no funcionan.).
Aunque hablar de testing da para largo, para cerrar un poco esta temática, el objetivo del post de esta semana es que tengas claro qué son y para qué sirven los tipos de pruebas más conocidos, de los que más se suele hablar. Y las diferencias que existen entre ellos.
Así podrás saber qué tipos de pruebas pueden serte más útiles en cada caso.
¡Vamos a allá!
—
Pruebas unitarias
Empezamos a más bajo nivel, el de programación. Aquí encontramos las pruebas unitarias.
Con ellas probamos las unidades del software, normalmente métodos.
Por ejemplo, escribimos estas pruebas para comprobar si un método de una clase funciona correctamente de forma aislada.
Las pruebas unitarias corresponden a la visión de los desarrolladores, que son los que deben elaborarlas. Esto es así porque cuando programas código, tú eres el que mejor conoce y entiende ese código, y sabes qué debería realizar exactamente cada método.
Las dependencias complejas o interacciones con el exterior se gestionan realizando stubs (que son objetos que tienen un comportamiento programado ante ciertas llamadas de un test concreto) o mocks (objetos ya programados con los datos que se espera recibir).
Por ejemplo, aunque estés probando un método que realice una serie de cosas y al final mande un correo electrónico a través de un servidor de correo, en una prueba unitaria no tienes que probar que el correo se ha mandado correctamente.
Buenas pruebas unitarias no irían contra una base de datos, por ejemplo, sino que simularían la conexión.
Aquí nos interesa como funciona la unidad, no la interacción entre componentes (cosa que sería una prueba de integración).
Las ventajas de las pruebas unitarias es que por un lado los tests tardan menos tiempo en ejecutarse, por lo que se tiende a lanzarlos más a menudo. Además, las pruebas unitarias te fuerzan a escribir clases menos acopladas (con menos dependencias las unas de las otras), lo que mejora el diseño del software.
Si una prueba unitaria falla, sabes que es por un problema en el código.
Para automatizar y realizar este tipo de pruebas se utilizan framework de tests, por ejemplo JUnit en el caso de Java.
No obstante, no pienses que JUnit sirve exclusivamente para realizar pruebas unitarias, porque con JUnit se pueden realizar también otros tipos de pruebas.
Pruebas de integración
En este caso probamos cómo es la interacción entre dos o mas unidades del software.
Este tipo de pruebas verifican que los componentes de la aplicación funcionan correctamente actuando en conjunto.
Siguiendo con el caso anterior, las pruebas de integración son las que comprobarían que se ha mandado un email, la conexión real con la base de datos etc.
Este tipo de pruebas son dependientes del entorno en el que se ejecutan. Si fallan, puede ser porque el código esté bien, pero haya un cambio en el entorno.
Por ejemplo, también podríamos usar JUnit para realizar pruebas de integración, si no hacemos mocks o stubs, y nos centramos en probar el comportamiento de los componentes en su conjunto.
Pruebas de sistema
Lo suyo sería realizar este tipo de pruebas después de las pruebas de integración.
Aquí se engloban tipos de pruebas cuyo objetivo es probar todo el sistema software completo e integrado, normalmente desde el punto de vista de requisitos de la aplicación.
Aquí aparecerían las pruebas funcionales, pruebas de carga, de estrés etc.
Pruebas funcionales
En este caso, el objetivo de las pruebas funcionales es comprobar que el software que se ha creado cumple con la función para la que se había pensado.
En este tipo de pruebas lo que miramos, lo que nos importan, son las entradas y salidas al software. Es decir, si ante una serie de entradas el software devuelve los resultados que nosotros esperábamos.
Aquí solo observamos que se cumpla la funcionalidad, no comprobamos que el software esté bien hecho, no miramos el diseño del software. Estudiamos el software desde la perspectiva del cliente, no del desarrollador.
Por eso este tipo de pruebas entran dentro de lo que se llaman pruebas de caja negra: aquí no nos centramos en cómo se generan las respuestas del sistema, solo analizamos los datos de entrada y los resultados obtenidos.
Una prueba funcional podría ser por ejemplo comprobar que en el formulario de mi página web si relleno un campo de teléfono con zzzz muestre un mensaje de campo no válido, y no me deje registrarme.
Estas pruebas pueden ser manuales, o automatizarse con herramientas. Una de las más conocidas para web es Selenium, en sus distintas variantes.
Como ya vimos, en función del objetivo al que se orienten, las pruebas funcionales también pueden actuar como pruebas de regresión, smoke test etc.
Pruebas de carga
Las pruebas de carga son un tipo de prueba de rendimiento del sistema. Con ellas observamos la respuesta de la aplicación ante un determinado número de peticiones.
Aquí entraría por ejemplo ver cómo se comporta el sistema ante X usuarios que entran concurrentemente a la aplicación y realizan ciertas transacciones.
Pruebas de estrés
Este es otro tipo de prueba de rendimiento del sistema. El objetivo de estas pruebas es someter al software a situaciones extremas, intentar que el sistema se caiga, para ver cómo se comporta, si es capaz de recuperarse o tratar correctamente un error grave.
Pruebas de aceptación
Por último, las pruebas de aceptación se realizan para comprobar si el software cumple con las expectativas del cliente, con lo que el cliente realmente pidió.
—
Como ves, distintos tipos de pruebas sirven para comprobar distintas cosas. En cada caso deberemos ver qué tipos de pruebas necesitamos, y utilizar distintos tipos de pruebas de forma complementaria.
Y bueno, sobra decir que si tienes cualquier duda o aclaración sobre estas pruebas u otros tipos de pruebas…este puede ser un buen sitio para comentarlas 🙂
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
¡Buenas!
Muy buen resumen de lo que son las pruebas en software, así por encima me parece una visión muy acertada.
Muy buen aporte. Gracias.
muy interesante todo lo que he leído y escuchado por youtube, a raíz de ahí me estoy interesando por tu página web.
Una pregunta, yo tengo un millón de dudas y quiero empezar a resolverlas y ponerme con este tema de calidad de forma seria y profesional.
la pregunta es si un cliente cuando realiza el protocolo de pruebas, debería pasar las pruebas unitarias, es decir, si el protocolo de pruebas para validar/aceptar una aplicación, solo incluye las pruebas de aceptación, pues mi cliente está interesado en conocer no solo que la funcionalidad está cubierta (lo que denominas pruebas funcionales o de caja negra) sino también saber cómo hacen las cosas, ¿es normal esta exigencia del cliente?.
muchas gracias
Hola es que tengo una duda serias tan amable de recomendarme algu programa para seguir el moedlo de pruebas en la creación de software ya que es de extrema importancia en mi empresa.
Lo que aquí se ha llamado «Pruebas de integración» lo he conocido siempre como pruebas de ensamblaje.
me pudiera decir de que manera realizo las pruebas de integración, tengo un módulo desarrollado que quiero integrar a otro sistema y necesito saber mediante que herramienta realizo las pruebas de integración.
Pruebas unitarias, de integración, sistemas y aceptación no son tipos de pruebas. Según la ISTQB estos son los llamados niveles de pruebas.
Tipos de pruebas serían funcionales, no funcionales, regresión, etc.
Dentro del nivel de integración, puedo hacer tanto pruebas funcionales (principalmente) como no funcionales (un poco); en el nivel de sistemas puedo hacer pruebas funcionales y no funcionales (principalmente).
Cierto Lucas. ISTQB define como tipos de pruebas las funcionales, no funcionales, estructurales y de regresión.
Y como niveles de pruebas las unitarias, integración, sistema y aceptación. Y depende del nivel puedo hacer funcionales y no funcionales.
Las de rendimiento, carga, usabilidad, mantenibilidad…van dentro de las no funcionales.
Pero también tenemos el concepto de smoke test, pruebas para las distintas características de calidad del software…
Con este post mi intención es que se entiendan los principales «nombres» de pruebas que se escuchan por ahí, qué hacemos en cada caso, y dar a entender que testing engloba muchas cosas. Muchas veces gente que empieza en testing, gente de dirección…escucha estos palabros y no saben lo que son 🙂
Muchas gracias por la puntualización! 🙂
que difrencia existe entre prueba de funcionalidad y prueba de aceptacion?
para mi suenen lo mismo
Las de aceptación pueden ser funcionales, seguridad, carga, etc., todo, todo lo que aquel quien acepta determine necesario para la aceptación.
Saludos
Como ya se dijo anteriormente, pruebas funcionales es un tipo de prueba (otros tipos son no-funcionales, estructurales, etc.)
En una prueba de aceptación podrías realiza distintos tipos de prueba (funcional/no-funcional) para aceptar el producto.
En las pruebas de aceptacion tu objetivo principal ya no es detectar defectos, sin comprobar la adecuacion del software para tu uso (pruebas en base a personas, escenarios, usabilidad, etc.), tambien si cumple regulaciones, compliance.
Para la ejecucion de pruebas o gestion de las mismas para un software en cobol con archivos indexados, existe algun software para la automatizacion de las mismas?
Hola, muchos saludos.
En este tema del testing, la calidad y aseguramiento soy nueva. Hasta el momento estoy haciendo una pequeña investigación de ciertos temas que me confunden, entre ellos los dichos niveles de pruebas y tipos de pruebas, que veo se mencionaron en comentarios anteriores.
He leído de los 4 niveles de
pruebas(unitaria,aceptación,sistema e integración), lo que no comprendo es que tipos de prueban entran dentro de cada nivel, se me hace un «colocho».
Hablan de funcionales y no funcionales, pero de estos 2 tipos ¿cuáles están en que nivel? y los demás tipos de prueba como los acomodo o dentro de que categoría entran?
Agradecería me puedan ayudar.
Hola Selenia, en cada nivel de pruebas podrias realizar distintos tipos de pruebas. Fijate en este ejemplo:
https://www.facebook.com/qatesterlatam/photos/a.1507566522685359/1648086378633372/
Buenas tardes, necesito saber si existe un documento que pueda seguir para realizar pruebas integrals de ajustes a un sistema, dentro de este cabe también laspruebas funcionales, para verificar que el cambio con el resto del sistema no se ve afectado. Pero necesito seguir un documento para implementar en mi area de trabajo que puedan seguir todos los desarrolladores y analistas.
Gracias
Buenas tardes… En la empresa donde trabajo estamos iniciando con SCRUM, no obstante tengo la duda de como meter las pruebas de aceptación dentro de la iteración. En la experiencia pasada, esas pruebas se demoran demasiado, porque dependen de la disponibilidad del usuario final. Y en ese caso, quien es el encargado de acompañar al usuario final en la realización de la prueba. Muchas gracias
En equipos agiles te recomiendo es que leas sobre el cuadrante de las pruebas agiles. http://labs.sogeti.com/guiding-development-agile-testing-quadrants/
Buenas tardes, tengo una duda en cuanto a test unitarios. Imaginemos que tenemos un código, escrito en C++ por ejemplo, con la siguiente estructura:
class A {
int metodoA1(int c) {
…
int d = metodoA2(c);
return d;
}
int metodoA2(int d) {
…
return d+5;
}
…
}
En este caso, si hiciéramos un assert sobre el metodoA1 ¿seguiría siendo un test unitario aun cuando éste dependa del metodoA2 para generar su «salida»? Lo que es lo mismo, si realizamos un assert sobre un método que depende de otro método de la misma clase, éste sigue siendo de tipo unitario al estar los dos métodos dentro de la misma clase. Si no es así ¿cuál sería la forma adecuada para hacerlo? Muchas gracias.
Artículo muy bueno para quien no conozca los tipos de pruebas existentes. Felicidades AnaM
muy bien explicado
Claro, conciso y puntual. Buen aporte.
Saludos
Me gustaria aportar algo más en este enlace: https://adictec.com/tipos-pruebas-de-software/
Muchas gracias por la aclaración entre los diferentes tipos de pruebas.
Hola Javier.
Te saludo desde la Ciudad de México. Me parece muy interesante tu publicación, ya que hace poco termine mi capacitación en una empresa precisamente de Tester, realizaba las pruebas funcionales de los proyectos internos aprendiendo a la indagación de cada apartado de los mismos. Y llegue a realizar las pruebas a 2 de algunos de los sistemas que manejaban allá, y aprendí muchísimo.
Pero con tu articulo, me doy cuenta que tengo que tener en cuenta los conceptos clave del testeo de aplicaciones.