El Tester Agil y el Síndrome de la Película Empezada

cinema

Imaginemos una persona que quiere ir al cine a ver una película. Saca su entrada anticipada, pero por determinadas circunstancias, llega tarde a ver la película y se pierde la primera parte. Entonces, verá por ejemplo que los actores buscan a alguien, pero no sabrá a quién ni por qué. O verá a un actor deseando venganza, sin saber bien qué le hicieron ni por qué está tan enojado. A esto llamo el “Síndrome de la película empezada”.

De la misma manera, a pesar del auge de las Metodologías Agiles, ATDD, TDD, etc., en muchos proyectos todavía se involucra tarde a los Testers. Suele pasar que se incorpora al Tester cuando las user stories ya están escritas, estimadas y con los criterios de aceptación ya delineados. De esta manera, el Tester se pierde parte de la película, y el proyecto a su vez pierde la visión que puede aportar el Tester.

Desde el punto de vista de la gestión del proyecto, se entiende que se haga esto por una cuestión de presupuesto, principalmente porque se presume que durante los primeros sprints el Tester no tendría demasiado para hacer y por lo tanto, sería un desperdicio de recursos.

Sin embargo, esta es una creencia equivocada. Veamos algunos ejemplos de tareas que el Tester podría tomar a su cargo en las etapas tempranas del proyecto:

  • Estimar las tareas de Testing: sabemos que, cuando les hablamos de tareas de testing, como diseñar casos de prueba, generar datos o planificar las pruebas, muchos PMs dicen “sí, sí, bueno…” con gesto de incredulidad, pensando que esas tareas van a ser agujeros negros adonde irán horas que no producirán ningún resultado tangible. Sin embargo, estas tareas son necesarias y aportarán su valor al proyecto, y por lo tanto, deben ser estimadas. Por otra parte, cada una de las user stories requerirá de tiempo de testing. Muchas veces, sin embargo, se realiza la estimación sin tener esto en cuenta, olvidando que una user story no está terminada hasta que fue completamente testeada. Ese tiempo debe ser considerado e incluido en la estimación.
  • Escribir los criterios de aceptación: el Tester es la persona ideal dentro del equipo para realizar esta tarea, por ser quien va a tener la visión funcional del desarrollo y además porque los criterios de aceptación van a constituir la base de su trabajo de testing. Suele pasar, sin embargo, que los criterios de aceptación los escribe el Scrum Master, convirtiéndose en una suerte de repositorio del conocimiento funcional, lo cual le quita tiempo y reduce la eficiencia de todo el equipo. Además, convierte al Scrum Master en un proxy entre el equipo y el Product Owner. Sucede que los proxies son muy buenos cuando son necesarios. Cuando no lo son, se convierten en un problema. Otro enfoque es que haya un Business Analyst que escriba los criterios de aceptación. El problema con esto es que esta persona suele participar al inicio del proyecto, y luego al no tener demasiado que hacer, se lo asigna a otro proyecto. Como consecuencia de esto, las preguntas que surjan en las etapas posteriores sobre los criterios de aceptación (“¿qué quiso poner acá?”, “¿este criterio todavía es válido?”, etc.), quedarán sin respuesta.
  • Automatizar: es muy difícil que un proyecto bajo metodologías ágiles resulte exitoso si no se utiliza la automatización de pruebas, como mínimo en un nivel básico de regresión. Esto no se puede lograr si no se comienza desde el inicio mismo del proyecto. Sin embargo, suele suceder que en el sprint 10, alguien de pronto le dice al Tester: “recordá que es un requerimiento de este proyecto tener pruebas automatizadas, por lo menos la regresión”. Frases como esta le ponen los pelos de punta al más calmado. A esta altura del proyecto, el Tester normalmente se está rompiendo la cabeza pensando cómo encontrar el tiempo para hacer una “mini-regresión”, y le hablan de automatizar…

Estos son sólo algunos ejemplos de tareas que generan valor y que el Tester puede tomar a su cargo en las primeras iteraciones, cuando las tareas de testing en sí no deberían demandarle demasiado tiempo.

Son también buenos motivos para que el Tester esté involucrado desde el comienzo y, entre otras ventajas, pueda evitar el “Síndrome de la película empezada”. El autor se permitió la licencia de inventar este “síndrome”, basándose en su teoría de que alguien que se incorpora a un proyecto cuando este ya ha comenzado, al igual que el espectador que llega tarde a una película, por más que se quede hasta el final y no se pierda de nada más, sentirá siempre la incertidumbre de pensar que quizás le falta saber algo. Acaso en las primeras escenas había un detalle que en realidad modificaba todo el sentido de la historia… Este síndrome sólo se logra evitar si se puede mirar la película completa (o participar en el proyecto desde el comienzo).

¿Qué puede hacer el Tester? Es simple: pedir, demandar, exigir que lo incluyan en el proyecto desde el principio. Hablar con el líder de Testing, con el responsable del proyecto, con quien sea necesario para lograr este objetivo. Una buena idea es mostrar la lista de más arriba, para dejar en claro que hay actividades que puede hacer para aportar valor en esas primeras iteraciones y así hacer buen uso de su tiempo.

De otra manera, será siempre víctima de la duda que le va a generar esa parte de la película que se perdió… ¿y si era todo un sueño y yo nunca lo supe?…

Nuevas fechas para Formación de Testers en Buenos Aires

EXO TRAINING CENTER®, líder en Capacitación y Entrenamiento de Profesionales y Empresas de TI que buscan estar a la vanguardia del conocimiento y las Mejores Prácticas, ha anunciado recientemente un acuerdo con QAbility, para el dictado de cursos de Testing/QA de Software.

La propuesta resulta interesante tanto para aquellos que buscan insertarse en el mercado laboral de IT, como así también para quienes necesitan fortalecer sus habilidades y así potenciar sus posibilidades de crecimiento dentro del mercado.

Para lo que resta de este año, se han anunciado 3 fechas, en octubre, noviembre y diciembre.

cursos exo

Más información en el sitio Web de Exo Training Center

Automatización de pruebas: el éxito está en cambiar

Muy bien. Después de mucho esfuerzo en tiempo y dinero, tenemos la regresión automatizada funcionando. Podemos ejecutarla las veces que queramos, con resultados confiables, velocidad aceptable y sin inconvenientes. Hasta la hemos incorporado a la integración continua y todo funciona. Ahora, podemos relajarnos. ¿O no?…

Si es viernes a la tarde y usted siente que necesita relajarse, no siga leyendo.

Un buen día, aparece un error en producción. Después de las corridas para solucionarlo y probar que todo siga funcionando, es aconsejable realizar un análisis para tratar de descubrir qué falló. La idea no es encontrar culpables, sino detectar qué salió mal, para corregirlo y que no se repita. En ese análisis, es posible que descubramos que la falla estuvo en la regresión automatizada, que no fue capaz de detectar el error. ¿Pero… cómo?

Ocurre que una vez que hemos logrado armar una regresión automatizada que funciona, que está completa y es confiable, necesitamos dar un paso más, que podemos considerar como parte del mantenimiento de esa regresión. El paso extra consiste en realizar cambios, para que siga siendo eficiente. Cambiar para evitar lo que se conoce como “paradoja del pesticida”.

La paradoja del pesticida se basa en un fenómeno observado en la actividad agropecuaria. Explica que, tras un tiempo de aplicar en un campo el mismo pesticida, en dosis similares y en la misma forma, éste pierde su efectividad, ya que habrá matado a todos los bichos a los que puede matar. Sin embargo, esto no quita que haya otra especie de bichos a los que este pesticida no puede eliminar. Esto, llevado al campo del Testing de Software, significa que, si repetimos una y otra vez las mismas pruebas bajo las mismas condiciones, estaremos seguros de que estamos libres de cierto tipo de defectos, pero habrá otro tipo de defectos que no vamos a detectar, que son “inmunes” o se han adaptado a nuestras pruebas. La paradoja del pesticida forma parte de uno de los principios de las pruebas de software definidos por la ISTQB.

En realidad, este fenómeno se aplica a todas las pruebas de regresión, pero especialmente a las automatizadas. Ocurre que, cuando la regresión se ejecuta manualmente, con el solo hecho de cambiar a la persona que ejecuta las pruebas, logramos un enfoque distinto y por consiguiente, podemos tener resultados diferentes. Las pruebas automatizadas, en cambio, son más sensibles a la paradoja del pesticida, por ser ejecutadas siempre por un robot.

Para evitar este fenómeno indeseable, como hemos dicho, deberemos realizar cambios. Vamos a necesitar del Tester, que va a ser quien va a definir estrategias para realizar modificaciones en las pruebas, sin que ellas pierdan su eficacia. Existen numerosas estrategias que se pueden aplicar para evitar la paradoja del pesticida. Algunos ejemplos:

  • Cambiar el set de datos de prueba: como hemos mencionado varias veces, los datos de prueba son muy importantes. No se trata de probar con cualquier dato, sino que deben ser diseñados cuidadosamente, ya que el set de datos incorrecto puede arruinar los mejores casos de prueba. Cuando se ha utilizado el mismo set de datos por un tiempo prolongado, es hora de cambiarlo por otro. Este cambio puede determinar que aparezcan errores que antes pasaban inadvertidos, que suceden ante determinados datos, y con otros no. Esto debe hacerse cuidando de no desvirtuar el espíritu de los casos de prueba.
  • Modificar la secuencia o el orden de las pruebas: normalmente, la regresión automatizada tiene su secuencia de ejecución. Muchas veces, esta secuencia puede alterarse, para buscar que las pruebas tengan un nuevo enfoque. Suele pasar que con sólo cambiar el orden en que se ejecutan los tests, aparecen errores que antes no se detectaban.
  • Ejecutar las pruebas sobre otro ambiente: de la misma manera, si ejecutamos el mismo set de pruebas sobre un ambiente distinto de hardware y/o software, podemos obtener resultados diferentes. Por ejemplo, si veníamos ejecutando nuestra regresión sobre el ambiente de Test, podemos ver qué sucede si la ejecutamos en Staging o incluso en Producción. Es posible que el mero cambio de ambiente nos descubra problemas que no se habían visto antes.

Estos son solamente algunos ejemplos de modificaciones que podemos aplicar para evitar la paradoja del pesticida. Estos cambios deben realizarse siempre con profundo conocimiento del concepto y el sentido de las pruebas, para evitar que terminen siendo inválidas. Asimismo, se recomienda que formen parte del mantenimiento normal de la regresión automatizada. De esta manera, vamos a asegurarnos que nuestra automatización continuará siendo exitosa a lo largo del tiempo.

Para finalizar, podemos concluir que el rol del Tester sigue siendo necesario, que estamos lejos de que la automatización reemplace al Tester. Más bien, necesitamos de él como nunca, para aportar su creatividad y el toque humano, que le permitirá al robot seguir siendo eficiente.