“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”

Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Testers”" como parte de la serie "Roles ágiles".

Testers Ágiles

Durante años, el enfoque de la prueba se ha basado en la definición de Philip Crosby de la calidad: la conformidad con los requisitos. Si la calidad es la conformidad con los requisitos, entonces los mejor es que dichos requisitos estén escritos. Esto ha llevado a muchos Testers a una búsqueda exagerada de un documento de requerimiento perfecto con el que puedan confirmar el cumplimiento del sistema. Sin embargo, si bien la conformidad con los requisitos es buena, la conformidad con las necesidades de los usuarios es aún mejor. En el uso de Scrum reconocemos que es imposible predecir a la perfección todas las necesidades de los usuarios.

Así como los programadores ya no puede decir: "Dame las especificaciones perfectas, y luego desaparece mientras que hago que el sistema haga exactamente lo que has pidido", los Testers no pueden decir, "Dame el documento de requisitos perfecto y me aseguraré de que el sistema haga todo lo que en él dice". Cada una de estas actitudes (muy frecuentes en los proyectos administrados de forma tradicional) conduce a una abdicación de la responsabilidad. Cuando expresiones como éstas se expresan, el programador o tester que las dice está renunciando a la rendición de cuentas para el éxito final del proyecto. "Sólo dime qué hacer y lo haré", cada uno está diciendo. En su lugar, cada uno tiene que pensar en el producto final y hacer preguntas acerca de cada función y cómo se añade a (o resta) el producto en general.

Dado que los equipos de Scrum cambian de de enfoque durante la recolección de requisitos, de escribir acerca de los requisitos para hablar de ellos, las conversaciones con el Product Owner se transforman en la principal fuente del tester para averiguar cómo una nueva funcionalidad debería comportarse. Un tester es probable que hable con el Product Owner acerca de cómo debería funcionar una característica, la rapidez con que debe realizar, qué criterios de aceptación debe pasar, etc. Los testers no se limitan a la adquisición de esta información únicamente de los Product Owners. Cuando sea necesario, los testers también deben hablar con los usuarios, clientes y otros stakeholders.

Al igual que para los programadores, trabajar en ese entorno interactivo puede ser incómodo para los testers que hacen la transición a Scrum. Muchos de los testers, como sus colegas, entraron en el desarrollo de software con la expectativa de que podría sentarse día a día en un cubículo con poca interacción humana. Ya no. Los testers de un equipo Scrum tendrá que acostumbrarse a conversaciones más frecuentes y significativas con sus compañeros de trabajo y, en muchos casos, las personas fuera del equipo.

Junto con renunciar al mito de que una especificación perfecta puede ser escrita de antemano, uno de los cambios más importantes que enfrentan los testers es aprender a trabajar de forma iterativa. Conceptualmente, esto no debería ser una cosa difícil de hacer. Si pensamos en cada sprint, como su propio proyecto, entonces la prueba para cada proyecto / Sprint se hace dentro de ese sprint. No es tan sencillo como determinar que la última semana de cada sprint se reservará para las pruebas. Esto no funciona y en su lugar crea cascadas en miniatura dentro de cada sprint. Durante los primeros sprints, los testers se enfrentarán a un reto inmenso. Durante ese tiempo, los programadores también están aprendiendo cómo trabajar de forma iterativa y probablemente no serán buenos en eso tampoco. El equipo probablemente se comprometa a entregar más de lo que puede hacerse en un sprint, y los programadores probablemente no tendrán ninguna de las características planeadas totalmente codificada sino hasta muy cerca del final del sprint. Así que se intentará entregar el código a los testers a los dieciocho días del sprint de veinte días. Después de que los individuos en estos roles aprender a trabajar de una manera ágil, estas entregas de última hora van a desaparecer.

Un mayor énfasis en la automatización de pruebas se convierte en un sello característico de los equipos Scrum. Incluso los equipos que han luchado durante años para lograr avances en la automatización de las pruebas encontrarán que los sprints cortos de Scrum transforman la automatización de pruebas en una necesidad. Con el tiempo esto reduce la dependencia de los testers manuales, los que leen un guión, pulse un botón, y toman nota de los resultados. A estos testers a menudo se les pide el aprendizaje de una o más herramientas de automatización de prueba para ser utilizada por el equipo. Si bien algunas herramientas de automatización de pruebas se basan en lo que bien podría ser llamado la programación para crear las pruebas, no todas lo hacen. He conocido a pocos testers manuales que han sido incapaces de hacer la transición para contribuir significativamente a los esfuerzos de sus equipos con la automatización de las pruebas. Por otra parte, he conocido a muchos que tienen miedo a este cambio. Tiempo, la práctica, la capacitación y la programación de a pares (incluso con un programador) debería ser suficiente para superar los temores.

Lisa Crispin, coautor con Janet Gregorio del libro Agile Testing, recuerda que cuando cambió a trabajar en un equipo ágil, lo primero que notó fue que tenía que ser proactiva.

No se siente y espere a que las cosas vengan a Ud. Sea proactivo! Nosotros los testers no podemos esperar para probar las tareas que vengan a nosotros. Hay que levantarse e involucrarse y averiguar qué hacer. Colaborar con los programadores es algo nuevo para muchos de los testers. Colaborar con los clientes también es nuevo para muchos de los testers. Es salir de la zona de confort para muchas personas. Los programadores son gente ocupada y con un poco de miedo, a veces. Cuando yo era la única tester de un equipo de ocho programadores, aunque la mayoría de ellos eran personas con las que había trabajado durante años en otra compañía, me requirió mucho coraje el hecho de pedir ayuda.

Si yo trabajo muy de cerca con el resto del equipo, voy a desarrollar "ojos de  programador", haciendo que vea todo desde su perspectiva, no desde la perspectiva de un tester. Es difícil ver cómo el hecho de trabajar más estrechamente con los programadores hará que los testers pierdan tanto la perspectiva que ya no puedan probar software. Los profesionales de bases de datos han trabajado estrechamente con los programadores durante años sin llegar a contaminarse tanto. Durante décadas, los testers se han abocado a hacer ambas pruebas: de caja blanca (en el que pueden ver el interior del sistema) y pruebas de caja negra (donde no pueden). Si el hecho de trabajar con un programador puede conducir al desarrollo de " ojos de programador", parecería lógico pensar que un tester que ha hecho pruebas de caja blanca, de modo similar, perdería la perspectiva y no sería capaz de hacer pruebas de caja negra. Afortunadamente, este no es el caso.

Aunque muchos de los cambios introducidos por Scrum puede ser incómodos al principio, la mayoría de los testers podrán disfrutar de sus nuevas formas de trabajar una vez se acostumbra a ellas. Jyri Partanen es un QA Manager en Sulake, los desarrolladores de Habbo, un mundo virtual con un promedio de más de ocho millones de visitantes únicos al mes. Partanen describe la transición necesaria de los testers.

El testing es una profesión donde los viejos hábitos tienden a durar. En el caso de la transición a la agilidad, adherirse a las viejas maneras de hacer las cosas puede conducir a una implementación mediocre del espíritu de agile. Normalmente la angustia de los ingenieros de pruebas se han relacionado con la seguridad laboral y los cambios que la transición ágil puede generar en su día a día. Esta es, sin embargo, una preocupación innecesaria. Basado en mi propia experiencia y la experiencia de otras personas que realmente han completado la transición a la agilidad con el personal de QA, lo que puedo decir con confianza es que el cambio ha sido sin duda una decisión inteligente. Los ingenieros de pruebas en los equipos ágiles tienen más influencia en el proceso de desarrollo y, lo que es aún más importante, en el producto final.


Dime lo que piensas. Por favor, deja un comentario más adelante (y luego dale click a ese botón de 'Me gusta'!)

Seguir leyendo


Comentarios

comments powered by Disqus