Mitos del testing agile


MythBusters

En esta entrada vamos a ver algunas temáticas que se discuten comúnmente en proyectos ágiles o en grupos de trabajo que arrancan a trabajar en ágiles. Por eso vamos a desbancar algunos mitos.

Los Testers pueden no obtener documentación detallada de los requerimientos para realizar las pruebas

Este mito viene mas que nada por la creencia (o por comodidad? o para tapar otros problemas?) de pensar que en agile no se debe documentar, pero en realidad el framework de trabajo agile propone darle más prioridad a una aplicación funcionando que a una aplicación documentada. Por eso se propone que  los miembros del equipo colaboren y se comuniquen más a menudo, en lugar de documentar cada pequeño detalle. Dicho esto, es responsabilidad de todos los miembros del equipo asegurarse de que tienen todos los detalles sobre los requerimientos sobre los que están trabajando actualmente.

Los tester en agile necesitan asegurarse de que entienden los criterios de aceptación lo suficientemente bien como para continuar con la planificación y ejecución de sus pruebas. Ellos deben trabajar con el PO para perfeccionar los requerimientos y añadir criterios de aceptación adecuados para garantizar la integridad de los requerimientos.

En comparación con los proyectos tradicionales, en agile los testers no tienen tiempo suficiente para completar las pruebas en del sprint

Este mito es similar al anterior, proviene mas que nada de un mal uso de los frameworks agile donde se ubica al testing como un estado/fase en lugar de ser una tarea en el sprint.  En los equipos agile, las pruebas deben ser lo mas tempranas posibles, a menudo, y en paralelo con el desarrollo. Los testers deben colaborar con los programadores y verificar sus desarrollos. La colaboración puede incluir un grupo de programadores para identificar escenarios de pruebas de unidad, integración y escenarios funcionales. El tester debe empezar a escribir las pruebas tan pronto como la planificación de Sprint se termina, luego debe trabajar lo mas cerca del desarrollador y el PO para verificar que lo que se esta generando es de valor y tiene calidad. Si esperamos a que todo este desarrollado para luego testearlo, estaríamos llevando a cabo un mini proyecto cascada dentro de un ciclo de Sprint, lo que si provocaría una falta de tiempo y gran presión para los testers.

La calidad del producto es responsabilidad del tester.

Esto mas que un mito, suele ser el modelo mental del equipo que viene trabajando con proyectos cascada tradicionales, donde el desarrollador solo de ocupa de generar codigo y luego el equipo de pruebas se encarga de la calidad(amplio concepto si los hay) del mismo. El tester no es un policía de calidad en los equipos agile, la calidad es responsabilidad de todo el equipo, todos los miembros del equipo deben trabajar y probar juntos para asegurarse de que cada trabajo realizado es de gran calidad y es potencialmente entregable (“si el sprint termina hoy, se puede entregar esto?”). Un ejemplo de esto es lo descrito en esta entrada donde podemos ver como todo el equipo genera pruebas para mejorar la calidad del producto en distintos niveles del desarrollo.

Todo esto de  “el equipo es responsable” puede sonar un poco desgastado, pero creo que todavía funciona (mejor) que otros enfoques. Los testers se sientan junto con el equipo de desarrollo, asisten a las mismas reuniones  y conversaciones con el cliente acerca de la funcionalidad. Especialmente el último punto será de gran ayuda en la comprensión de la finalidad del software y por lo tanto lo que para hacer las pruebas necesarias.

La automatización es la única manera de incorporar el testing en equipos agile.

Este mito esta muy relacionado con el mito de que no hay tiempo para pruebas, ya que el pensamiento mas simple nos lleva a pensar que si no hay tiempo para las pruebas manuales, automaticemos las mismas y listo, todo es mágicamente mas rápido y sencillo. Las pruebas automatizadas llevan tiempo y tienen un mayor costo a corto plazo en comparación con las pruebas manuales. La automatización definitivamente debe ser una parte importante de los esfuerzos de las pruebas, pero no debe ser la única manera de probar el producto en equipos agile. También se deben considerar la realización de pruebas manuales sobre todo si se trata de una aplicación que arranca desde cero. El testing exploratorio (técnica de prueba manual) es también una de las mejores maneras de aprender y probar la aplicación. También es necesario evaluar el costo-beneficio en la automatización, normalmente las pruebas de regresión y pruebas sobre funcionalidad existente (que tienen mínima probabilidad de cambiar) son los más adecuados para la automatización.
Pruebas en paralelo con el desarrollo no es posible.
Este mito viene mas que nada de una mezcla entre por un lado, la creencia que existe en que DEVs y Testers son una clase de archienemigos donde uno lucha por crear y el otro lucha por destruir lo creado y por otro lado con que el testing como parte de una fase tiene que esperar a que todo este terminado para poder ver lo que se hizo, yendo nuevamente a los mini proyectos cascada. Esto tiene un gran impacto en la capacidad del equipo de testing para afrontar su trabajo, ya que tiene que esperar a que desarrollo termine las tareas del sprint para poder arrancar con los tests y el tiempo se ve limitado por la presión de presentar los resultados del sprint en la demo y cerrar el mismo (Como vimos en mitos anteriores). En el dashboard del proyecto, qa tiene que ser una tarea mas que pasa por los mismos estados que desarrollo, si tenemos que QA es un estado de la tarea de desarrollo, estamos llevando adelante mini proyectos cascada en el sprint. En agile es necesario cambiar nuestro paradigma mental y colaborar lo mas posible para prevenir y detectar bugs trabajando cerca del PO para entender el valor y para que estamos haciendo determinadas tareas (de esta forma prevenimos bugs) y detectar bugs trabajando junto al desarrollador, visitándolo en forma seguida y viendo en su maquina el trabajo realizado hasta el momento y dando feedback constructivo sobre el mismo.

Te gustó el post? Quieres contribuir? Contribute with the Blog

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s