Hablar de Pruebas de Software o QA como lo conocemos, me recuerda la etapa donde fuí desarrollador Java para un proyecto importante en el estado. Trabajé muy duro codificando y luego probé a mi manera que lo que había codificado realmente funcione. Para mí todo estaba muy bien, funcionaba de las mil maravillas.
Después de que termine el desarrollo de la funcionalidad requerida por el negocio, el siguiente paso era enviar el código realizado para que el equipo de aseguramiento de calidad (QA) valide que todo este OK. Sin embargo, no todo fue color de rosa.
El equipo de QA me devolvió el código con un millón de observaciones tanto de forma como de funcionalidad y entre otras cosas más. Entonces allí me volví a preguntar, ¿Cómo es posible que el código que había sido probado y funcionaba en desarrollo, tenga un gran cantidad de observaciones detectadas de las cuáles ni siquiera me di cuenta de que existían? La respuesta era sencilla. Yo no conocía los tipos de pruebas que se pueden aplicar a un código para asegurar su calidad.
En este post, vamos revisar 2 términos básicos para las pruebas y los tipos de pruebas más usados en el mercado del desarrollo de software:
Términos en QA
- Código: Es la fuente de un programa o aplicativo que permite construir funcionalidades definidas por un usuario o cliente.
- Funcionalidad: Es aquello definido por el usuario o cliente y se transforma en código que es escrito por los desarrolladores del equipo.
Tipos de Pruebas para Software – QA
Después de lo que me ocurrió. Empecé a investigar y empaparme de todos los tipos de pruebas existentes. Conocí qué pruebas son las utilizadas, cuáles ayudan más a detectar tempranamente un problema, cuáles permiten saturar tu aplicativo, etc.
Aquí les presente una lista de 7 tipos de pruebas para software basado en mi investigación y mi experiencia personal.
1. Pruebas unitarias
O también conocidas como pruebas de código las cuales permiten validar que el código escrito cumpla con los casos programados. Por ejemplo si has codificado un caso de uso para guardar una persona, entonces mediante una prueba unitaria validar que se pueda guardar persona con data válida y usar data inválida para saber cómo nuestro código se comporta en esta situación.
Responsable: Desarrollador o programador que hizo el código.
2. Pruebas de cobertura de código
Las pruebas de cobertura de código tiene como objetivo principal validar todos los posibles escenarios que se pueden dar al analizar el código escrito y que estos sean cubiertos por las pruebas unitarias escritas por un desarrollador. Por ejemplo si un desarrollador realiza el código de un registrar persona entonces lo que hará esta prueba es validar que las pruebas unitarias escritas cubran todos los escenarios que tiene el código.
Responsable: Desarrollador o programador que hizo el código.
3. Pruebas funcionales
Estas pruebas tienen como objetivo validar la funcionalidad de un aplicativo es decir si está funcionalidad cumple con lo definido por el Product Owner/dueño de producto en la historia o analista de negocio en sus casos de uso según la metodología utilizada. Por ejemplo un Product Owner define una historia con ciertos criterios de aceptación, entonces las pruebas funcionales validarán que el código escrito realmente cumpla con los criterios de aceptación.
Responsable: Equipo de QA.
4. Pruebas de Integración
Las pruebas de integración permiten validar la comunicación de la aplicación con componentes y servicios externos y a la vez ver cómo se comportan estos con data válida e inválida. Por ejemplo una aplicación de préstamos debe consumir un servicio externo para reportar todos los movimientos que se están haciendo en un préstamo, entonces las pruebas de integración en este caso se encargarán de validar la comunicación entre la aplicación de crédito y servicio externo y además si el servicio cumple con todos los escenarios definidos por la aplicación.
Responsable: Equipo de QA y equipo de desarrollo.
5. Pruebas con el usuario
Estas pruebas las realiza el usuario final que va utilizar el aplicativo y consiste en validar que el aplicativo realmente funcione así como el lo pensó. Usualmente en estas pruebas, el usuario no está conforme con el aplicativo por lo que te pedirá que realices algunos ajustes a su forma o también que adiciones mayores funcionalidades no definidas por el Product owner o analista de negocio. Recuerden que el usuario es el que va utilizar la aplicación y su feedback es muy valioso.
Responsable: Los usuarios con soporte del equipo QA y desarrollo.
6. Pruebas de estrés
Este tipo de pruebas consiste en saturar la aplicación para saber dos cosas, la primera para saber cuánto es lo máximo que puede soportar una aplicación a nivel de usuarios y que recursos consumiría en ese momento (saber el límite) y la segunda es para saber qué cuellos de botella hay en nuestra aplicación con la finalidad de reducir o eliminar estos. Por ejemplo, una aplicación de un banco debe ser estresada mediante una prueba de estrés para saber el límite y conocer hasta cuándo usuarios puede soportar y si es necesario poner más recursos para la aplicación.
Responsable: Equipo QA y equipo de desarrollo.
7. Pruebas de humo
Las pruebas de humo o también pruebas de marcha blanca tienen como función validar que los componentes, servicios, aplicaciones funcionen desplegadas en producción funcionen correctamente. Esta prueba se realiza con data ficticia para lo cual es necesario que los equipos que administren componentes, servicios o aplicaciones externas con las cuales se va comunicar nuestra aplicación, nos provea la data para poder probar y no ocasione problemas en producción. Por ejemplo una aplicación ha sido desplegada a producción hoy día entonces se necesita realizar las pruebas de humo para validar que la aplicación funcione correctamente en producción probando flujos básicos con data ficticia.
Responsable: Equipo QA con el soporte de todo el equipo de trabajo
Existen más tipos de pruebas como pruebas de caja de blanca, pruebas de caja negra, pruebas automatizadas y algunas más, que lo estaremos tratando a más detalle en el Taller de Gestión de Proyectos Ágiles.
Conclusión
Recuerdan la película de Rápidos y furiosos donde Vin Diesel dice la frase: “Dime cómo conduces y te diré quién eres”. Basado en esta frase, podría decir: “Dime cómo realizas tus pruebas y te diré quién eres”.
Las pruebas son muy importantes para asegurar que lo que hemos realizado funcione de acuerdo a lo estipulado por el negocio. Hoy en día, las empresas de desarrollo de software buscan personas que apliquen pruebas a todo el código que realizan y mucho mejor si estas pruebas son automatizadas (sin intervención humana).
Si eres desarrollador debes realizar siempre las pruebas unitarias de tu código para asegurar que realmente estás cumpliendo con lo definido. Si perteneces al equipo de calidad, debes realizar pruebas funcionales, pruebas de integración, pruebas de humo, pruebas de estrés según sea el caso.
Saludos
Aldo Malaver
