Aseguramiento Ágil de Calidad

Soy reconocido en la industria primordialmente por mi actividad en el ámbito de Lean, Kanban y Agile. Algo menos sabido es que también soy miembro del Comité de Dirección del Agile Testing Alliance y que en 3 de las 5 empresas en Silicon Valley que fui miembro del equipo fundador yo cree las organizaciones de aseguramiento de calidad. Así que a compartiré a continuación algunos aspectos relevantes de pruebas estilo ágil.

La mayoría de las actividades de pruebas de software desafortunadamente se enfocan en hacer pruebas funcionales manuales lo cual es deficiente pues el alcance y valor agregado de ese tipo de prueba es muy limitado, resultando en productos y servicios de baja calidad.

Un punto de partida para mejorar la calidad de las actividades de prueba es considerar el Cuadrante de Pruebas Ágil, el cual nos muestra el tipo de pruebas a efectuar dependiendo de los factores considerados además de recomendar qué hacer de manera manual y qué hacer de manera automatizada. Ver Figura 1.

El primer cuadrante tiene que ver con probar aspectos que ayudan al equipo de desarrollo desde la perspectiva tecnológica. Utilizando herramientas se verifica la calidad mediante pruebas unitarias y de componentes. Esto es para asegurar que la funcionalidad del código y las interfaces de los módulos es adecuada.

El segundo cuadrante se enfoca también en probar aspectos que soporten el desarrollo, pero desde la perspectiva de negocio. En ese cuadrante se llevan a cabo pruebas funcionales para validar lo que se está construyendo respecto a las expectativas del usuario. Esto involucra pruebas tanto automatizadas como manuales.

El tercer cuadrante es para pruebas que evalúan el producto o servicio desde el punto de vista del negocio. Este es el único cuadrante en el que es aceptable sólo hacer pruebas manuales y es para aspectos de exploración, uso, aceptación y Alfa/Beta (éste último es para determinar cuál de más de una opción de funcionalidad es mejor y es determinada por los usuarios mismos).

El último cuadrante se enfoca en pruebas para evaluar el producto desde la perspectiva de tecnología. Las pruebas en este cuadrante se llevan a cabo de manera enteramente automatizada. Ejemplos de pruebas son seguridad y carga.

Tomando un paso hacia adelante, el aseguramiento de la calidad de software no debe ser una actividad reactiva. Es decir que en lugar de enfocarnos en probar código para encontrar defectos o para verificar que defectos no existan, mejor llevemos a cabo actividades para evitar que los defectos existan.

TDD

Para ello hacemos uso de Desarrollo Basado en Pruebas unitarias (TDD del inglés Test-Driven Development). En breve, se trata de generar y codificar las pruebas de lo que se va a implementar primero; ejecutar el código de prueba para asegurar que falle porque el código a probar no se ha implementado; e implementar el código que pase esas pruebas. Si esto se hace bien y completo entonces ese último código es la característica indicada en la especificación con la ventaja de que jamás tuvo errores. Adicionalmente las pruebas automatizadas son la documentación (más completa y actual). Conforme ésta práctica se lleva a cabo es indispensable factorizar el código que se está generando.

TDD es fantástico pero hay aún más. Desarrollo Basado en Pruebas de Aceptación (ATDD del inglés Acceptance Test-Driven Development) en el cual las pruebas son de aceptación en lugar de unitarias. Las pruebas de aceptación son creadas por el equipo técnico y sus líderes técnicos. La ventaja radica en que el énfasis está en el comportamiento esperado del código en lugar de tan solo en la validez del código.

BDD

Otro paso adelante es el Desarrollo Basado en Comportamiento (BDD del inglés Behavior-Driven Development) en el cual el énfasis es en verificar que el código hace lo que el negocio necesita en lugar de verificar si la implementación funciona. En éste tipo de pruebas se generan escenarios en adición a historias de usuario.

Como pueden ver las actividades de Aseguramiento de Calidad y de Pruebas son distintas y requieren de mayor nivel de excelencia técnica de lo que en muchas industrias se considera. Es posible que algunos lectores piensen que las actividades que menciono incrementarán costos y retrasarán el tiempo de entrega. No es así. En realidad los costos y tiempos mejorarán porque más tiempo es dedicado típicamente en proyectos a la detección y resolución de defectos de lo que toma evitarlos como les he mostrado aquí. Aún muchos de los defectos que no son detectados de la manera tradicional son encontrados tarde, cuando el servicio ya está en producción o fue entregado al cliente, haciéndolo mucho más costoso.

Les invito a que eleven el nivel de madurez de sus organizaciones y actividades de calidad.