cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

400380101. Estrategias de comprobación ágil

Escrito por Redacción en Tema de portada
no hay comentarios Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

En los últimos meses, cada vez más personas me han venido preguntando sobre cómo nos va con la comprobación de proyectos ágiles. Los desarrolladores de proyectos ágiles están sin duda “infectados por la comprobación” y en la edición de este mes exploro varias estrategias de comprobación en proyectos de desarrollo de software ágiles. Un breve aviso: Aunque evidentemente no seguimos la añeja metodología de comprobación en serie de nuestros padres, sospecho que aún podemos aprender unos cuantos trucos de nuestro querido papá.

Empecemos estableciendo las bases filosóficas:
• En primer lugar, queremos realizar la comprobación lo antes que buenamente sea posible, porque el impacto potencial de un defecto se eleva de forma exponencial con el tiempo (no siempre es así, pero es algo a tener en mente). De hecho, muchos desarrolladores de ágiles prefieren el enfoque de “primero comprueba”.

• En segundo lugar, queremos comprobar con la mayor frecuencia posible, y lo que es más importante, de la forma más efectiva posible para aumentar la casualidad de encontrar defectos. Si bien ello incrementa los costes a corto plazo, los estudios demuestran que una mayor inversión en la comprobación reduce el coste total de propiedad de un sistema debido a su calidad mejorada.

• En tercer lugar, queremos realizar las comprobaciones justas y precisas para la situación en la que nos hallamos: El software para la banca comercial necesita de una mayor inversión en las comprobaciones que el software para la administración de socios del grupo local de Scouts.

• En cuarto lugar, la comprobación en pareja, como la programación y el modelado en pareja, entre otros, es una excelente idea. Mi filosofía general es que el desarrollo de software se parece mucho a la natación: es muy peligroso hacerlo sólo.

Comprobaciones a lo largo de todo el ciclo de vida

La Figura 1 presenta una vista del nivel superior del ciclo ágil cuyo fin es la comprobación (para los detalles, véase “Initiating an Agile Project” en la versión americana de www.ddj.com/dept/architect/188700850). Los proyectos ágiles pasan por una fase -con frecuencia breve- de Inicio (Iteración 0) en la que establecemos las bases del proyecto; una fase de Construcción en la que desarrollamos el sistema de una forma evolutiva (iterativa e incremental); una fase de Final de Juego en la que modulamos nuestro sistema para la producción; y una fase de Producción en la que operamos el sistema y los usuarios del soporte. No hay que temer al coco de las series: La fase de Inicio no es una fase de requisitos; como tampoco es Final de Juego una fase de comprobaciones.

Figura 1: Actividades de comprobación durante el ciclo ágil.

Las actividades de comprobación van variando a lo largo del ciclo. Durante la Iteración 0, realizamos tareas iniciales de funcionamiento. Ello incluye la identificación de las personas que estarán en el equipo “investigador” externo de comprobaciones, la identificación e instalación potencial de las herramientas de comprobación y el inicio de la programación de recursos escasos, como por ejemplo un laboratorio de comprobación de valor práctico si fuera necesario. Si tenemos una fecha tope para el proyecto, es probable que queramos identificar la fecha en la que el proyecto ha de entrar en Fin de Juego. Veremos que el mayor número de comprobaciones realizadas durante las iteraciones de construcciones nos permitirá realizar menos comprobaciones durante la fase de Fin de Juego.

Una importante cantidad de comprobación se produce durante las iteraciones de construcción – recordemos “agilistas”, comprobar con frecuencia, comprobar pronto y, normalmente, comprobar primero. Esto es comprobación confirmatoria frente a la intención actual de la parte interesada y está basada, de forma característica, en un hito en el nivel de las unidades. Esto es un espléndido comienzo, pero no representa la comprobación completa (que es por lo que también necesitamos la comprobación investigadora que se basa en el riesgo a más de un nivel de integración.) Independientemente del estilo, nuestro auténtico objetivo debería ser comprobar, y no la planificación de comprobaciones y, desde luego, no escribir una documentación completa sobre cómo tenemos la intención de –esperamos- comprobar en algún momento. Los “agilistas” siguen planificando, y nosotros seguimos escribiendo documentación, pero hemos de concentrarnos en actividades de alto valor como lo es la realización de comprobaciones.

Durante la fase de Fin de Juego puede que se nos pida realizar trabajos de comprobación final para el lanzamiento, incluido una comprobación completa del sistema y de su aceptación. Esto ocurrirá si hay requisitos legales para ello (frecuente en situaciones críticas para la vida como por ejemplo el desarrollo de software médico), o si nuestra organización ha establecido acuerdos de servicio con clientes que lo necesitan. Afortunadamente, si hemos realizado comprobaciones efectivas durante las iteraciones de construcción, los trabajos de comprobación finales resultarán sencillos y rápidos. Si contamos con realizar cualquier forma de “comprobación seria” durante la fase de Fin de Juego, es probable que tengamos problemas porque el equipo no tendrá tiempo suficiente para solucionar los defectos que, sin duda, encontraremos.

Comprobaciones durante una Iteración de construcción

La mayoría de las comprobaciones se producen durante las iteraciones de construcción en los proyectos ágiles. Los trabajos de comprobación, al igual que el sistema en el que estamos trabajando, van evolucionando con la construcción. La figura 2 refleja dos iteraciones de construcción, que indican que el equipo lleva a cabo comprobaciones confirmatorias y, paralelamente, se realizan comprobaciones investigadoras, idealmente por parte de un equipo de comprobación independiente (He adoptado los términos de comprobación “confirmatoria” e “investigadora” que utiliza Michael Bolton, un referente del pensamiento de la “comunidad de las comprobaciones”) Aunque no siempre es posible contar con un equipo de comprobación independiente, especialmente en los proyectos pequeños, es, sin embargo, algo muy deseable. La comprobación confirmatoria se concentra en verificar que el sistema cumple con la intención de las partes interesadas tal y como hasta la fecha se le ha descrito al equipo, mientras que la comprobación investigadora pugna por descubrir problemas que el equipo de desarrolladores no tuvo en mente.

Figura 2: Comprobación incremental a lo largo del ciclo de desarrollo ágil.

Hay dos aspectos a considerar en la comprobación confirmatoria: Comprobación de aceptación ágil y comprobación de desarrolladores, las dos automáticas para permitir una comprobación de regresión continua durante todo el ciclo. La comprobación confirmatoria es el equivalente ágil a la comprobación de la especificación y, de hecho, consideramos que las pruebas de aceptación son la parte primaria en la especificación de los requisitos, al igual que las comprobaciones de desarrolladores son la parte primaria de la especificación del diseño. Ambos conceptos son aplicaciones de la práctica ágil de la información de una sola fuente, siempre que sea posible.

La comprobación de aceptación ágil es una mezcla de comprobación funcional tradicional y comprobación de aceptación tradicional porque el equipo de desarrollo y las partes interesadas en el mismo colaboran en ello. La comprobación de desarrolladores es una mezcla de comprobación tradicional de unidades y comprobación tradicional de integración de clase/componente/servicio. La comprobación de desarrolladores pugna por verificar tanto el código de aplicación como el esquema de la base de datos (para más información, (véase mi artículo “Ensuring Database Quality”; en la versión americana de www.ddj.com/architect). Nuestro objetivo es buscar los errores de codificación, realizar al menos una comprobación de lo que cubre, si no de toda la ruta, y garantizar que el sistema cumple con las intenciones actuales de las partes interesadas. La comprobación de desarrolladores se hace con frecuencia en forma de “comprobar primero”, en donde se escribe una única prueba y luego se escribe el código de producción suficiente para cumplir con la prueba (para más detalles, véase www.agiledata.org/essays/ tdd.html). Resulta curioso que este método de comprobar primero se considere, en primer lugar, una actividad de diseño detallada y, en segundo, una actividad de comprobación.

La automatización es un aspecto importante de las pruebas de construcción por la creciente necesidad de comprobar la regresión en los proyectos evolutivos. Con frecuencia se usa la plataforma de comprobación Fitnesse (www.fitnesse.org), disputable herramienta de documentación de requisitos, para automatizar pruebas ágiles de aceptación. También es posible generar casos de pruebas de aceptación a partir de casos de uso, y definiciones de escenarios o a partir de diagramas de procesos tales como los diagramas de actividad UML o diagramas de fabricación, y ya empiezan a emerger herramientas justamente para ello. La plataforma XUnit —JUnit (www.junit.org) para Java y VBUnit (www.vbunit.org) para Visual Basic—se utiliza para automatizar pruebas de desarrolladores. Herramientas comerciales de comprobación, como por ejemplo TestDirector (www.mercury.com/us/products/quality-center/testdirector) de HP Mercury, o TestManager (www-128.ibm.com/developerworks/rational/ products/testmanager) de IBM Rational, son también buenas opciones a considerar, ya que con frecuencia demuestran ser más sofisticadas que sus alternativas Open Source. Herramientas estáticas de análisis de códigos, tipo FindBugs (findbugs.sourceforge.net), se incluyen a menudo en ejecuciones automáticas de comprobación para ayudar a identificar potenciales problemas de calidad en el código fuente.

Comprobación investigadora

Mientras escribía el presente artículo, tuve suerte de asistir a la presentación que hizo el Dr. Cem Kaner ante la Asociación de Toronto para la Calidad de Software y Sistemas (TASSQ, por sus siglas en inglés). Kaner, co-autor de Lessons Learned in Software Testing (Wiley, 2001), describió sus pensamientos y experiencias en el campo de la comprobación del software, y como resultado, me ayudó a conceptualizar algunas de mis propias ideas. Concretamente, me hallaba intentando describir de forma adecuada las actividades en los trabajos de comprobación investigadora durante las iteraciones de construcción, y la presentación que hizo Kaner me ayudó a aglutinar mis experiencias.

¿Un equipo de comprobación a parte? ¡Sin sentido!, dirá el lector. En realidad, se puede ganar valor de forma significativa sometiendo el sistema a un equipo de comprobación independiente, en intervalos durante todo el ciclo, para que puedan verificar la calidad del trabajo que estamos realizando. Los equipos ágiles producen software que funciona al final de cada iteración de construcción; por lo tanto ahí tenemos algo nuevo que comprobar en este punto. Una práctica corriente es dar una nueva versión del sistema como mínimo una vez a la semana, independientemente de la longitud de la iteración, que es una estrategia especialmente buena cuanto más nos aproximamos a Fin de Juego.

El objetivo del equipo de comprobación investigadora debería ser el preguntarse, ¿Qué podría fallar? Y explorar posibilidades potenciales que ni el equipo de desarrollo ni las partes comerciales interesadas hubieran considerado. Tratan de dar respuesta a la pregunta “¿es un buen sistema?” y no “¿cumple el sistema con las especificaciones escritas?” Los trabajos de comprobación confirmatoria verifican si el sistema cumple con las intenciones, de manera que la mera repetición de dicho trabajo no va a añadir mucho valor. Kaner promueve la idea de que los buenos comprobadores buscan defectos que los programadores han pasado por alto, explorando los puntos ciegos exclusivos de los desarrolladores individuales.

Los comprobadores investigadores describen los problemas potenciales en forma de historias de defectos – equivalente ágil al informe de defectos. Una historia de defectos es tratada como una forma de requisitos – se hace una estimación de la misma y se prioriza, y se pone en la pila de los requisitos. La necesidad de arreglar un defecto es un tipo de requisito, por lo que es perfectamente lógico abordarlo como cualquier otro requisito. Tal y como cabía esperar, durante el Fin de Juego, el único tipo de requisito en el que trabajamos es en historias de defecto.

La comprobación investigadora que realicemos abordará temas comunes como comprobación de carga/tensión, comprobación de integración y comprobación de seguridad. La comprobación de escenarios, tanto frente al sistema mismo como frente a la documentación de apoyo, es también corriente. Podemos realizar además alguna forma de comprobación del valor práctico – la interfaz de usuario es el sistema para la mayoría de usuarios finales, en consecuencia, el valor práctico es fundamental para el éxito. La IU incluye tanto pantallas con las que la gente interactúa como la documentación que leen, lo que implica que hay que comprobar ambas.

Los buenos trabajos de comprobación investigadora revelan cualquier problema que los desarrolladores pasaron por alto mucho antes de que resulten excesivamente caros de abordar. También ofrece comentarios constructivos a Dirección de que el equipo proporciona, con éxito y de forma regular, software de gran calidad que funciona. Kaner indicó que no hay una única forma de realizar la comprobación investigadora, ni hay una única lista correcta de técnicas a emplear. El trabajo que realizamos ha de reflejar los objetivos de equipo de proyectos al que estamos dando soporte. Por ejemplo, ¿es el objetivo establecer si el sistema está listo para su envío? ¿O es garantizar que el sistema interactúa con otros sistemas existentes? ¿O es ayudar a los desarrolladores a identificar problemas en sus propios trabajos de comprobación indicando las causas o defectos que ellos no han tenido en cuenta? ¿O es minimizar la posibilidad de una demanda ante los tribunales contra nuestra organización o sus directivos? El contexto en el que estamos realizando la comprobación determinará el qué y cómo comprobamos – no sólo variará el contexto de cada proyecto, el contexto cambia también durante la vida del proyecto.

El tipo de comprobación confirmatoria realizado por los equipos ágiles es sólo una parte de todo el espectro de la comprobación – es el equivalente ágil de la tradicional prueba de humo. Esto representa un gran comienzo, y el disponer de una comprobación automatizada de regresiones ofrece la red de seguridad que necesitan las técnicas de desarrollo evolutivas. La comprobación investigadora nos permite explorar las cuestiones críticas generales, además de cuestiones de detalle en las que nadie había pensado hasta ahora.

La calidad es la principal tarea

El método de comprobación que he descrito aquí es distinto al método tradicional, que tiene mucha documentación y en el que lanzamos por la ventana el sistema y sus especificaciones a los comprobadores, y esperamos que todo salga lo mejor posible. Mi experiencia es que la calidad de nuestro sistema guarda una estrecha relación con la calidad de nuestros trabajos de comprobación.

Gracias a Michael Bolton, Cem Kaner, Renu L. Rajani, y Steve Robinson por sus profundos e iluminadores comentarios.
Recursos de comprobación ágil
Los siguientes recursos están llenos de ideas provocadoras sobre cómo mejorar los trabajos de comprobación:
• Agile Testing Mailing List (tech.groups.yahoo.com/group/ agile-testing).

• Context-Driven Software Testing Mailing List (tech.groups.yahoo .com/group/software-testing).

• “High-Volume Test Automation,” C. Kaner, W.P. Bond, y P. McGee (www.kaner.com/pdfs/HVAT_STAR.pdf).

• El blog de James Bach (www.satisfice.com/blog).

• “Lessons Learned in Software Testing,” C. Kaner, J. Bach, y B. Pettichord (www.testinglessons.com).

• Artículos sobre comprobación de Michael Bolton (www.developsense.com/articles).

• “Roadmap for Agile Testing” y “The Testing Team’s Motto,” Brian Marick (www.testing.com/writings).

• “What Is Exploratory Testing?” James Bach (www.satisfice.com/articles/what_is_et.shtml).

Etiquetas

Noticias relacionadas

Comentarios

No hay comentarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.