Los diez principios de un tester Agil (1ra parte)

REF 1 KNOL, a unit of knowledge. Coronel, Fabiana Patricia. 17 de Mayo de 2009. Disponible en Internet: KNOL REF 2 KNOL, a unit of knowledge. Coronel, Fabiana Patricia. 17 de Mayo de 2009. Disponible en Internet: KNOL ¿Qué es un tester "agile" (ágil)? Un tester "agile" es un profesional que se adapta a los cambios, colabora tanto con el equipo técnico como con la gente de negocio y comprende el concepto de usar las pruebas para documentar los requerimientos y conducir el desarrollo. Dentro de un equipo ágil, el tester es una pieza clave en la release (o puesta) del código a producción, más de lo que podría serlo en un ambiente tradicional. Un tester "agile" podría:        Correr scripts.        Ejecutar un testing manual para verificar que todos los elementos de la release están en su lugar, como por ejemplo un script para verificar la actualización de la base de datos. Probar desde el inicio del proyecto y probar continuamente durante todo el ciclo de vida del proyecto es la base sobre la cual se construyen las pruebas ágiles. Cada práctica, técnica o método se centra en este claro objetivo. Entonces, ¿qué es lo que ahora necesitamos saber y hacer para trabajar eficazmente dentro de un equipo que utiliza un método ágil? El concepto de "el equipo responsable de la calidad", es decir, "todo el concepto de equipo" y no sólo el equipo de pruebas, es un valor fundamental de los métodos ágiles. En Agile, los testers o el equipo de QA no son los únicos responsables de la calidad. Es un trabajo de todo el equipo. Brett Pettichord define el papel de las pruebas dentro de los proyectos ágiles como:        Las pruebas son los faros del proyecto - ¿Dónde estás ahora? ¿Hacia donde te diriges?        Las pruebas proporcionan información al equipo - Permiten al equipo tomar decisiones informadas.        Un "error" es algo que podría decidir un usuario - Los testers no tienen la decisión final.        El tester solo por sí mismo no garantiza la calidad - Lo hace el equipo (o no).        Las pruebas no son un juego de "gatcha" (1) - Encontrar la forma de fijar metas, en lugar de centrarse en los errores. Los 10 principios Basándonos en los valores del Manifiesto Ágil, podemos obtener los siguientes diez principios importantes para un tester ágil (agile):        Proveer feedback en forma contínua        Entregar valor al cliente        Posibilitar la comunicación cara a cara.        Coraje        Simplicidad        Mejora contínua.        Responde al cambio        Se auto organiza        Foco en la gente        Se divierte ¿Cuál es la explicación a cada uno de estos principios? En esta primera parte, he aquí la razón para los primeros cinco de la lista. Proveer feedback en forma continua Dado que las pruebas conducen los proyectos ágiles, no es una sorpresa que el feedback juegue un rol importante en un equipo ágil. Una de las contribuciones mas importantes del tester ágil es ayudar al dueño del producto o cliente a articular los requerimientos para cada historia en forma de ejemplos o pruebas. El tester trabaja entonces junto con sus compañeros de equipo para transformar esos requerimientos en pruebas ejecutables. Testers, programadores y otros miembros del equipo trabajan para ejecutar estas pruebas en forma temprana y con frecuencia, porque entonces de esa forma son guiados en forma continua por el feedback que ello genera. Cuando un equipo encuentra un obstáculo, el feedback es una forma de ayudar a removerlo. Entregar valor al cliente El desarrollo con metodologías ágiles justamente es entregar funcionalidades de valor para el cliente o el negocio en pequeñas entregas que él mismo ha priorizado. Esto significa, limitar el objetivo. Es fácil verse atrapado por el cliente que desea incluir nuevas funcionalidades durante una iteración. El tester ágil mantiene el foco en la gran figura. Podemos entregar la funcionalidad que hemos acordado para esta iteración y agregar nuevas funcionalidades más tarde. Si dejamos que nuevas funcionalidades se agreguen a la iteración en curso, nos arriesgamos a entregar nada en tiempo. Posibilitar la comunicación cara a cara Ningún equipo trabaja correctamente sin una buena comunicación. Hoy en día cuando muchos equipos están distribuidos en múltiples ubicaciones geográficas, la comunicación es vital y un gran desafío. El tester agile debe buscar una forma única para facilitar la comunicación. Es un aspecto crítico para hacer bien su trabajo.Cada vez que surge alguna duda sobre una funcionalidad, el tester introduce una conversación entre el desarrollador, el cliente y él mismo para hablar sobre ello. La comunicación cara a cara no tiene sustituto. El desarrollo ágil depende de la constante colaboración. La gente que realiza actividades de test busca continuamente al cliente y a los miembros técnicos del equipo para discutir y colaborar. Si el equipo se encuentra en diferentes ubicaciones geográficas y necesitan hablar, se deben buscar las formas de reemplazar la comunicación cara a cara por conversaciones en tiempo real. Coraje Cuando se trabaja en una organización donde los testers están en su propio silo, sin posibilidades de hablar con el cliente u otros miembros del equipo técnico, y surge la posibilidad de unirse a un entorno colaborativo ágil, es común sentirse incómodo yendo a pedir ejemplos al cliente, al pedir ayuda a un programador para automatizar una prueba o al presentar en la reunión diaria un impedimento en el desarrollo. Cuando se une por primera vez a un equipo ágil o cuando se pasa por primera vez a un desarrollo con esta metodología, es normal experimentar miedo y tener una lista de preguntas que necesitan ser respondidas. ¿Cómo se van a completar las tareas de testing en tan corto tiempo? ¿Cómo se complementarán testing con desarrollo? ¿Cómo se sabe cuando el testing es suficiente? El tester necesita coraje para encontrar las respuestas a estas preguntas pero hay otras razones también para tener coraje.        Se necesita coraje para permitirnos fallar, sabiendo que al menos fallamos y somos capaces de aprender de las fallas. Después que se ha perdido una iteración porque no se consiguió un entregable estable, se comienza a pensar en formas de asegurarse que no suceda nuevamente.        Se necesita coraje para permitirle a los demás cometer errores porque esa es la única forma de aprender la lección.        Se necesita coraje para pedir ayuda, especialmente cuando la persona que puede proveer la ayuda parece ocupada y estresada. Salir del viejo silo y unirse a un equipo donde la responsabilidad del éxito o la falla es compartida requiere de coraje. Simplicidad El tester ágil y el equipo en sí tienen como desafío no solamente producir la implementación del software lo mas simple posible sino también tomar el objetivo más simple para asegurar que el software cumple con los requerimientos del cliente. El equipo debe proveer información al cliente y ayudarlo a considerar todos los aspectos de la calidad, incluyendo requerimientos no funcionales tales como performance y seguridad. La última decisión es del cliente. El equipo puede ayudar al cliente a tomar buenas decisiones con solo establecer un simple objetivo paso a paso de su trabajo. El testing ágil significa hacer las pruebas más simples posibles para verificar que la funcionalidad existe y el estándar de calidad fijado por el cliente se cumple. Simple no significa fácil. Para el tester significa probar lo suficiente con las herramientas más livianas y las técnicas que sabe cumplimentarán el trabajo. Las herramientas pueden ser tan simples como una hoja de calculo o un checklist. Se necesita automatizar las pruebas de regresión pero debe hacerse al mas bajo nivel posible para facilitar el feedback rápido. La simplicidad ayuda a mantener el foco en el riesgo, el retorno de ganancia y la mejora en áreas de mayor debilidad. (1) En Estados Unidos y otros países este juego es conocido como paintball. Gotcha es un juego de palabras que contiene los términos "got ya" que es un modismo de "i got you" (te tengo)