Aplicando Criterios Ágiles a la Calidad

Hoy es la presentación del nuevo sistema de software. El cliente usuario y el cuerpo directivo estarán presentes. Llegó la hora, el cuerpo directivo se muestra interesado, el presentador realiza la demostración de acuerdo al “happy path” (escenario de uso ideal sin condiciones de excepción), pero no contemplaron que el ambiente en el cual se iba a presentar no era el mismo donde se desarrolló y no se había probado ahí. De pronto, a media presentación … ¡aparece una pantalla de error y el sistema se cierra repentinamente! Se escuchan murmullos  y se hace sentir la molestia de los presentes, mientras el presentador trata de minimizar la falla y terminar la presentación de manera “normal”.

El escenario descrito anteriormente es demasiado común. La deficiencia de pruebas de software conlleva a: retrasos en la entrega del producto; fallas del software en la operación; desacreditación de posicionamiento del producto y la compañía responsable; costos no contemplados por las fallas del producto, provocando que el presupuesto del proyecto rebase lo contemplado; o en el peor de los escenarios puede ser que las fallas en el sistema provoquen la pérdida de vidas humanas.

No podemos seguir creyendo que es imposible comprobar la calidad del producto antes de que se está ejecutando o validando con el usuario. Es muy importante incluir como una actividad las pruebas de software durante el desarrollo del producto, y no como un proceso de pruebas opcional o de trámite para después de ser liberado.

Por donde empezar

Ya nos queda más que claro que las pruebas de software son una necesidad que beneficia tanto a la imagen como a la economía y viabilidad de nuestra empresa, pero ahora, ¿Cómo podemos realizar esta planeación de manera eficiente o con procesos que podamos llamar  ágiles? ¿Cómo poder tener un equipo multidisciplinario ágil? Es decir, es necesario que desde el punto de vista de la calidad y pruebas se  tenga una mentalidad ágil.

Para ser ágil es necesario que todo el equipo sea consciente de la importancia que tienen las pruebas para alcanzar una calidad alta. Las actividades de prueba no deben ser una etapa al final del proyecto, sino que deben ser parte de todo el ciclo de desarrollo.

Existen distintos métodos y niveles de prueba de software que deben de ser contemplados en el plan de pruebas de cualquier proyecto de desarrollo de software. Entre los métodos de prueba más comunes están las pruebas estáticas, dinámicas, de caja negra, de caja blanca; cada uno con distintas técnicas y enfoques. Las actividades y diferentes técnicas que se utilizarán deben de planearse de manera eficiente dependiendo del contexto de cada proyecto.

Es necesario contar con un plan de pruebas que incluya la definición, preparación y ejecución de pruebas a lo largo de todo el ciclo de vida del proyecto. Debemos incorporar al personal responsable de las pruebas en las reuniones como el “sprint planning” (planificación de las tareas a realizar en la iteración) para que entienda qué se va a construir y bajo qué condiciones va a ser aceptado. Todo requerimiento debe estar asociado a un conjunto de pruebas de aceptación, de manera que en todo momento se sepa claramente si dicho requerimiento ha sido correctamente resuelto o no.

En las etapas tempranas podemos empezar con pruebas de exploración con las primeras funcionalidades que se vayan completando, como prototipos, que nos sirve para asegurar la retroalimentación de la iteración.

La persona responsable de la calidad de un producto de software debe mantenerse centrada en la visión global del proyecto, definiendo y ajustando la estrategia de prueba de manera que esté alineada a dicha visión. También debe contar con el valor y las bases para decirle al equipo de desarrollo cuando algo no es correcto.

Conclusión

Para hacer testing ágil es necesario que todo el equipo de trabajo esté consciente de la importancia que tienen las pruebas para alcanzar alta calidad en un producto de software. Si todo el equipo está preocupado por el desarrollo y generar versiones por cada modificación o parche al sistema, el testing no encaja en ese equipo. Establecer un esfuerzo de pruebas ágiles requiere compromiso y colaboración.

Referencias
[1] L. Crispin & J. Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley Professional, 2009.
[2] X. Albaladejo, “Planificación ágil vs planificación tradicional” http://swgu.ru/sg38r1