Hoy es el día de la presentación de un nuevo sistema de software, el cliente, el usuario y el cuerpo directivo se encuentran presentes para la validación del sistema. Desde varias horas antes se están realizando pruebas y parches en busca del “HappyPath”. Se ha dado la orden de detener las actualizaciones y modificaciones al sistema para dicha presentación y evitar problemas de último minuto. Llego la hora, el cuerpo directivo se muestra interesado y atento al nuevo sistema, el presentador realiza la demostración que el desarrollador le aconsejo, pero no contemplaron que el ambiente en el cual se iba a presentar no era el mismo donde se desarrolló y tampoco se había ensayado con anterioridad. De pronto a mitad de la presentación y cuando las funcionalidades del sistema son anunciadas… Aparece una pantalla de error y el sistema se cierra repentinamente. Se escuchan murmullos y se perciben signos de enfado entre los asistentes, mientras el presentador está tratando de salir de la situación y el equipo operativo lucha por levantar el sistema y terminar la presentación de manera “normal”.

¿Te suena familiar? ¿Te ha sucedido que el día de la entrega no funciona nada? ¿El equipo técnico siempre tiene que estar monitoreando el sistema por si se presenta una incidencia en la presentación?

Este tipo de situación y su falta de planeación en las etapas debidas, conlleva a retrasos en la entrega del producto y/o fallas del software en la operación, desacreditación de posicionamiento del producto y de los equipos de desarrollo o compañía responsable, costos no contemplados por las fallas del producto, lo que se reduce a pérdidas a veces demasiado costosas,  que en algunos casos llevan a que una empresa quiebre, o en el peor de los escenarios puede ser que cobre vidas humanas por las fallas en el sistema, y todo porque las pruebas exhaustivas en el software no se realizaron de la manera debida, porque se piensa que no son necesarias antes de liberar el producto o que son pérdida de tiempo y recursos.

No se puede seguir creyendo que sea imposible comprobar la calidad del producto hasta que se está ejecutando o validando con el usuario. Tampoco es posible promover las “Mejores Prácticas” como un ideal para una situación pero completamente inútiles para otras. 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 esto, las actividades y diferentes técnicas que se utilizarán deben de planearse de manera eficiente dependiendo del contexto de cada proyecto.

Existen diferentes técnicas para realizar un plan de pruebas formales y completas que tienen que ser incluidas en uno de pruebas eficiente y en cualquier proyecto de desarrollo, para asegurar que se cumpla con el objetivo de liberar un producto con el mínimo de errores posibles. Las más comunes son usar pruebas estáticas, dinámicas, de caja negra o caja blanca, sin embargo no son las únicas.

Ley de Brooks: "Agregar gente a un proyecto atrasado, lo atrasa aún más".

En la actualidad la mayoría de las fábricas de software posicionadas en el mercado saben bien que tener un plan de pruebas para el desarrollo de un sistema de software ya no es una opción, es una necesidad imperativa, ya que indudablemente asegura un mínimo de calidad del producto, lo que llevará a que el cliente confie en el desarrollo.

Pero al referirnos a la calidad de un sistema de software, no quiere decir que lo mediremos en base a la robustez, usabilidad, el número de interfaces existentes o por la compatibilidad y estandarización con otras plataformas tampoco nos podemos atrever a decir que entre más monstruoso sea el sistema tiene más calidad, ya que estos puntos no garantizan la calidad de un desarrollo de software. Para que un producto asegure que cuenta con la calidad necesaria, podemos afirmar que es el buen funcionamiento de cualquier sistema que cubre la necesidad puntual del cliente.

 Ya nos queda más que claro que las pruebas de software a un producto son una necesidad que beneficia tanto a la integridad como a la imagen de la organización, 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 testing.

Para ser ágil es necesario que todo el equipo sea consciente de la importancia que tienen las pruebas para alcanzar una calidad alta y no esperar el trabajo, si no incorporarse en todo el ciclo de desarrollo. No es limitarse solamente a resolver problemas de testeo, sino que ayude a la mejora continua del desarrollo.

El plan de pruebas de software tiene que incluir la definición, preparación y ejecución de pruebas desde el principio, más allá de prácticas recomendables como pruebas unitarias o de integración durante el desarrollo, es decir, incorporar al personal que va a definir las pruebas a las reuniones como el “sprint planning” [1], donde interviene el levantamiento de requisitos con el objetivo de tener todos los detalles de lo que se necesita construir y hacer durante la iteración, así como también se requiere saber bajo qué condiciones lo que se va a desarrollar va a ser aceptado.

Esto, por supuesto, debe pertenecer a “Definition of Done”, de manera que cualquier requerimiento no se asuma y que cuando no pase las pruebas de aceptación no se dé por válido. Por esto es necesario que todo requerimiento lleve al menos un conjunto de pruebas de aceptación definidas desde el principio y a medida que el proyecto vaya avanzando se ira complementando y mejorando como se realiza en “Scrum” [2] con el “Sprint Backlog" [3] a nivel de desarrollo.

También, podemos empezar con pruebas de exploración, con las primeras funcionalidades que se vayan completando a nivel de desarrollo, como prototipos, que nos sirve para asegurar el “feedback” [4] de manera que el tester se centre en expresar en forma los requisitos del cliente. Trabajando de la mano con él y cualquier cambio al sistema se lo haga llegar de forma clara al equipo de desarrollo.

Centrase en la visión global del proyecto, analizando si los casos son demasiado complejos para hacer que funcionen en el camino normal, así como tener el valor y las bases para decirle al equipo de desarrollo cuando algo no es correcto.

Añadir valor a los equipos y organizaciones, de modo que sepamos cuál es el procedimiento que realizarán los usuarios. Estos pueden ser ejemplos básicos, o más completos estilo “end to end”.

En conclusión para hacer “agil testing” es necesario que todo el equipo de trabajo sea consciente de la importancia que tienen las pruebas para alcanzar alta calidad en un producto de software, pero 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 y para hacer un equipo ágil de pruebas se requiere compromiso y colaboración, donde el tester de este equipo sea el traductor entre negocio y tecnología.

 Más información:

Agile Testing quadrants por Brian Marick

Agile Testing de Lisa Crispin y Janet Gregory

Otras fuentes:

Planificación ágil contra planificación tradicional http://www.proyectosagiles.org/planificacion-agil-vs-planificacion-tradicional

http://www.exampler.com/old-blog/2003/08/21/

 (Artículo publicado originalmente en la columna “Código Innovare” de la revistas Software Gurú en su edición Noviembre 2012-Enero 2013)

Por Ing. Jordana Villegas Sosa
Responsable de especialidad de pruebas y transferencia de conocimientos en la Gerencia de Desarrollo de Nuevos Productos y Servicios de INFOTEC

¡ÉCHALE UN OJO A LAS IMÁGENES!

AQUÍ PODRÁS ENCONTRAR TODOS NUESTROS WALLPAPERS, INFOGRAFÍAS, ESQUEMAS Y MÁS.