QA-Testing en SCRUM

Estimado tester del mundo,

Dando vueltas por “la red” veo repetidamente tus preguntas que reniegan de las metodologías Ágile, principalmente de  SCRUM:

“¿Cómo es posible que me digas que las iteraciones deben ser tan cortas? ¿si una iteración dura cuatro(4) semanas, tres (3), o dos (1), serán mitad de desarrollo y mitad de testing? ¿como se gestionan los defectos en tiempos tan acotados? ¿como es la comunicación en la gestión de defectos en proyectos Ágile? ¿si los desarrolladores deben continuar codificando los próximos incrementos, cuando corrigen los defectos? ¿cuando se los verifica?

NO ME QUEDAN CLARO LOS CICLOS!!!”

 

 

 

 

 

 

 

 

Como te habrás dado cuenta no obtuviste respuestas concretas ni en los mejores foros en tantos años de vida de Agile. Eso es así por que QA no tiene una definición concreta y formal en los entornos Ágile y te aseguro que en SCRUM no está estipulado como es el proceso de testing y calidad. Pero eso está bien por cuanto Scrum no es prescriptivo hasta el punto de definir “cómo hacer el trabajo” del equipo.

Leí varios libros sobre agilísmo y en todos ellos dicen “la calidad no se negocia”, pero en ninguno de ellos explican como evitan la merma de calidad con iteraciones tan cortas, o dicho de otra manera, como la obtienen y garantizan.

Alguna respuesta lógica podría ser:

  1. la intervención temprana del equipo de testing en el ámbito del proyecto.
    Esto quiere decir que hay que apartarse de la idea de esperar a que los requisitos estén maduros para tomar el documento de requerimientos y realizar el diseño de casos de pruebas por adelantado. En este tipo de metodologías, debemos tener en cuenta la mutación de requerimientos (la cual es mayormente deseada en los negocios actuales), como también la eliminación de algunos de ellos y la aparición de nuevos en tiempos muy cortos (inclusive dentro del Sprint en curso).
    Aquí debemos ingresar en el preciso momento en el que nace un requerimiento, es decir cuando la historia del usuario es expuesta al equipo. Nuestra fase de análisis comienza al mismo tiempo que para el equipo de desarrollo.
    Prontamente estaremos en la fase de diseño de las pruebas, donde también es extremadamente dificultoso ser veloces y preciso con iteraciones tan cortas. Es debido a ello que verás muy pocas propuestas serias para trabajar, aunque hoy en día se están abriendo paso…
  2. …herramientas colaborativas donde los encargados de indicar criterios de calidad, criterios de aceptación, modos de fallos, modos de prueba y demás, son todos los miembros del equipo e interesados.
    Esto es así dado a que la industria se dió cuenta que las mejores pruebas las hacen nuestros clientes y en todo el ciclo de vida de un requisito, los distintos tipos de analistas (negocios, requerimientos, sistemas, soporte, pruebas) representan algún aspecto de los clientes, aunque no todos.
    Estas herramientas ayudan a…
  3. … automatizar el proceso de desarrollo, donde la generación del requisito es el inicio natural, pero está acompañada su evolución por aspectos de la gestión de proyectos, tales como criticidad y priorización, estimaciones, asignaciones, control de cambios, control de estados, gestión de recursos, desvíos, replanificación y métricas. Todos elementos para sostener un curso razonable de la calidad del proceso y del proyecto.

En relación a tus preguntas te diría que:

  • Tres semana de desarrollo y uno de testing es posible, pero es mejor dejar de pensar en fases tan marcadas. Que opinas de colaborar todo el tiempo con lo que sabes, con lo que entiendes? Seguramente será más beneficioso para todos en términos de “descubrimiento de la feature” y/o “descubrimiento del product”, si te involucras y con tus opiniones generas mínimamente dudas.
    No considerarías a esto mismo TESTING?
  • ¿Tendrás tiempo de planificar algo que garantice cobertura sobre los requerimientos? dificilmente del modo tradicional. Lo que puedes hacer sabiendo que cuentas con los recursos necesarios y adecuados (interación plena, coordinación y colaboración, pero principalmente la involucración), es gestionar de un modo colaborativo, es decir con la opinión de todos a tus sugerencias y propuestas de planificación, así probablemente ya no existirán más los clásicos problemas de “responsabilidad de un rol”, porque el resultado será algo funcional a todos y generado por todos.
  • Mientras se hace testing los desarrolladores codifican y mientras reportas fallos, ellos corrigen, al rato lo verificas. Para eso está el trabajo en equipo, solo hay que consensuarlo y organizarlo.
    Aunque está mal visto en los paradígmas tradicionales, los desarrolladores serán eventualmente los mejores testers; puedo asegurar que visto que es positivo, imprime rítmo, genera velocidad y ayuda al crecimiento técnico del equipo en general, no solo a QAs.
    En el mismo iterín, los desarrolladores también adoptan perspectivas diferentes que le ayudan en sus próximos enfoques para el desarrollo de las soluciones.
    Tiene sus aspectos negativos que se pueden ir puliendo. Por ejemplo un desarrollador que eventualmente pasa a testing, al detectar un defecto lo analizará desde el aspecto que más conoce. Querrá acceder a la base de datos y debaguear el código, y si fuera posible corregir y recompilar inmediatamente.
    Bueno, eso también lo hemos hecho, pero en otras situaciones, por ejemplo cuando se hace la verificación de las correcciones de defectos.
  • Particularmente yo me salto “el aparato comunicacional” y  digo al desarrollador: “master, tengo un defecto persistente. Que te parece mirarlo juntos y resolverlo de buenas a primera?”
  • La herramienta de gestión de defectos es como cualquier otra o como una planilla Excel si lo quisieras llevar a extremos precarios (habrá quienes me discutan lo de precario por Excel) y en ocaciones suele ser una importante barrera comunicacional burocrática, puesto a que nuestros defectos deben “atravezar el espacio-tiempo” mientras esperan ser atendidos.
  • Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.
    También interactuo con los desarrolladores planteándoles un modo de uso, uno modo de fallo, un modo de prueba y ayudando a desarrollar una mejor solución.
  • Al respecto de cuando se solucionan los defectos, opino que no es buena cosa pasar a un próximo ciclo de desarrollo si no se cerró el anterior. De manera tal que decir que tenemos un incremento, va ligado de la frase “está hecho!!!”.
    Sin embargo en la vida real, notarás que es común iniciar la próxima iteración antes de corregir todos los defectos. Esto será válido si el incremento desarrollado fue aceptado por el cliente (Product Owner) aún a sabiendas de los defectos de la entrega.

Como elemento QA debes ser lo suficientemente analítico para iniciar el ciclo de vida de los proyectos, estudiando los requerimientos, detectando sus falencias, investigando modos de pruebas y modos de fallos. Mientras tanto deberás ir generando los criterios de aceptación funcional, generando un modelo de pruebas y si tuvieras el tiempo, los casos de pruebas.

También será menester gestionar los ambientes de pruebas netamente funcionales, aislados de accesos a bases de datos e IDEs de desarrollo, ya que lo que se pretende al menos en las pruebas de funcionalidad, es utilizar el sistema como lo haría nuestro cliente final, pero con mucho más rigor.

Entonces, como verás hay muchísima tela para cortar al respecto. Solo hemos “tocado por encima” algunos aspectos QA & Testing. Imagina si tenemos que hablar de pruebas unitarias, de componentes, de integración, métodos y técnicas…. en fin.

Lo cierto es que SCRUM es solo una metodología de gestión de proyectos, bien sinérgica, orientada a equipos maduros, autogestionados, con altísimos conocimientos técnicos, con gran dominio del negocio que genera los requerimientos y no pretende indicar como se hará el arte de desarrollar ni de probar, mucho menos se hará de conceptos para el mundo QA & Testing.

Para que esto no quede con un amargo sabor, te paso este enlace que podrá al menos darte una idea de como iniciar, pero te repito, aprende por tu cuenta pues no hay recetas.

Advertisements

7 thoughts on “QA-Testing en SCRUM

  1. ¿por qué separar al equipo de testing del equipo de desarrollo? Quizás debería “simplemente” que las personas de testing asuman las mismas responsabilidad principalq ue los desarrolladore (y viceversa) que es que el producto sea de la calidad suficiente y se termine.
    Yo no veo estos perfiles separados del equipo que hacer Scrum, pero ciertamente tu experiencia en estos temas es muy interesante.

    Salu2!

    • Hola Jose, gracias por haber comentado.
      Personalmente he pasado por varias empresas, por muchos equipos y debo admitir que en todos los casos la forma en que se encaran las cosas son siempre diferentes.
      Las personas que conforman los equipos normalmente tiene uno o mas roles y seguramente alguna función o grupo de funciones que son específicas para resolver problemas. Lo ideal es empoderarlos con ciertos principios y valores que son como reglas (sirven para regular pero no son leyes), los cuales están expresados de alguna manera en el post original (que es de 2010 cuando todavía muy pocos tenían experiencias Agiles).
      Si esos principios y valores se ponen en contexto y se los evalúa con una mirada “hacker” todo el tiempo, es probable que observemos que la conformación de esos equipos varia a lo largo de un año (por poner un marco de tiempo), pero lo hacen ya con cierta ‘gestión experta’ y no con una receta inmodificable.

      Saludos, Javo.

  2. Yo creo que los equipos deben estar bien separados, dado que la psicología propia del desarrollador es la de construir y crear, en cambio la del tester es destruir y romper, a un desarrollador le custa poder boicotear y destruir su propia creación, al contrario, inconscientemente tratara de probar que lo que ha hecho funciona lo mas correctamente posible.
    Esta bien que el desarrollador tenga su set de pruebas y que acompañe el desarrollo con los test diarios.
    Lo recomendable (incluido en metodologias agiles) es crear builds diarios y realizar test de prueba de humo “smoke-test” diariamente (en lo posible), esta tarea debe automatizarse. El smoke-test es una prueba no-exhaustiva para determinar si el build está en
    condiciones de ser sometido a testing.
    Build diario

    Esto deberia gestionarse:
    – Verificar builds rotos
    – Smoke-test diario
    – Establecer un equipo de build
    – Agregar código nuevo al build solo cuando tenga sentido hacerlo
    – No esperar demasiado para agregar código nuevo
    – Mantener el proceso aun bajo presión

    Las ventajas de esto no da:
    Disminuye la probabilidad de ocurrencia de riesgos de integración.
    – Reduce el riesgo de baja calidad o calidad impredecible del producto final.
    – Facilita el diagnóstico de defectos.
    – Mejora la moral del equipo y del cliente.
    – Mejora la visibilidad sobre el grado de progreso en el trabajo.
    – Puede usarse en forma efectiva en proyectos de cualquier tamaño y complejidad

    Algunas sugerencias que les puedo dar:

    – Contar con un buen proceso de control de versiones.
    – Evaluar la frecuencia más conveniente de liberación de builds.
    – Organizar el trabajo de forma que los desarrolladores puedan entregar
    código nuevo según la frecuencia estipulada de builds.
    – Un build roto debe ser la excepción, no la regla.
    – Considerar generar el build en horario nocturno, o bien evaluar el mejor
    momento para su pasaje (minimizar impacto sobre personas trabajando en
    el ambiente).
    – Automatizar en lo posible la generación del build y el smoke test.
    – Cuidar la moral del equipo respecto al proceso.

    Saludos!

    • Hola que tal. Gracias por tu comentario.

      Pasa que todavía estamos utilizando términos que nos son impuestos y no estamos pensando evolutivamente. Nos sucede todo el tiempo con todas las cosas.
      Por ejemplo, yo soy tester y Mauro mi compañero que se sienta detrás es programador, cuando vamos a “la demo” el ScrumMaster (que soy yo mismo…(en este caso actual) jaja) indica qué Historia de Usuario vamos a mostrar y dice: “Mauro desarrolló la feature y Javier la probó”…
      Que significa esto?
      . que solo un programador desarrolla las features?
      . que el proceso de testing no es parte del proceso del desarrollo?
      . que se asume que yo por ser tester no participo del proceso de desarrollo?

      Pero Mauro, quien es un tipo muy conciensudo de lo que implicó mi aporte para que tengamos la feature terminada para ser mostrada, hace notar toda la batería de pruebas que yo le facilité (en un Googledoc) para darle ideas de coberturas y riesgos, que lo ayudé a redireccionar su programación de código con consultas que le hicieron dar cuenta que el requerimiento no había sido bien entendido. Además entendió que el hecho de que yo sepa utilizar SoapUI o JMeter mejor que él (al menos eso), le facilitó conocer rápidamente los resultados que entregaban los Webservices y por otro lado que cálculos estaban arrojando errores por estar mal algunos criterios en las queries de bases de datos.
      El codificó, yo hice las pruebas durante y después, pero ambos desarrollamos la feature y muy probablemente sin el ejercicio constante del testing, no hubiéramos conseguido algo de alta calidad para el fin de Sprint.

      Después de todo esto si quieres podemos organizar “procesos finos” (exhaustivos?) sobre como generar test-suites, automatización e2e (esa utopía), etc. Eso si, no dejar de lado los consejos que nos das porque normalmente son la base de que todo se pueda hacer como yo lo explico en ésta respuesta y en el post original.

      Saludos, Javo.

  3. Todavía no le encuentro una vuelta al proceso de Scrum y Testing, por fin alguien habla de este problema. Creo que esto de ágil está obligando al Tester a tener reuniones, hablar con analistas, desarrolladores, product owners, menos a hacer lo más importante: TESTEAR.
    Yo creo que le uso de herramientas para reportar errores facilita el tiempo de trabajo de cada integrante del equipo. Si me salto este “aparato comunicacional ” (como dice el blogger) y le digo al desarrollador que encontré un error de la Historia 1 y lo veamos juntos, el me podría decir “reportámelo en el bugtracker porque ahora estoy concentrado con la Historia 3”
    Otro problema que veo es que si reporto un error y es crítico, y el desarrollador está con otra tarea, el mismo error queda en la herramienta como crítico y a veces el desarrollador no lo visualiza, acá debería intervenir un superior para decirle al desarrollador que cuando termine su tarea corrija el error crítico.
    Leyendo esto “Yo prefiero la interacción y la proactividad, inicialmente hablar con quien lidera el proyecto mostrando los defectos detectados, dándole información precisa y concisa, ayudándole a priorizar su resolución y a medir los impactos.” Y CUANDO TESTEÁS????????
    Si un tester se quiere meter a la BD y debaguear, entonces NO está testeando, está buscando en dónde está el error, esa no es la tarea del Tester. El Tester informa cómo ocurrió el error, no importa cómo se resuelve.
    Ese es mi pensamiento
    Saludos!!!

    • Ha pasado un largo tiempo desde que enviaste tu mensaje Fernando.
      Antes que nada, gracias por participar y dar tu opinión; estoy seguro de que con esta interacción quienes lean aprenderán mas, consolidarán mas sus ideas, modificarán sus ideas, difundirán la información de una manera diferente, etc.
      En cierto modo, el testing es lo mismo, se trata de una actividad de características activa (contexto vivo), netamente social, de cualidades cognitivas (ejecutado por seres pensantes e iteligentes) y bastante más lejos de lo puramente técnico como muchos lo suponen (ya vez el auge de automation, equivocado a mi enteder).
      Testing tiene muchas aristas y una de las más importantes es proveer información, irradiarla, promover ese nuevo conocimiento que estuvo oculto en las sombras hasta que con ésta hermosa actividad “descubrimos” aquello que faltaba. Agile bien entendido, bien apoyado en sus valores y principios, nos propicia el marco adecuado para que nuestro trabajo se haga de manera colaborativa y no de manera aislada, de manera cross-functional y no como especilista, siendo así que nuestro rol de testers es mucho más abarcativo y atractiva que como se acuño en cierto momento de la historia del desarrollo de software.
      Entonces no tenemos límite en nuestra función si nos lo proponemos. Quien dice que interesarse en la solución es un enfoque equivocado? Como conoces entonces lo suficiente para ser “el mejor” ?
      Siendo un tester, no crees que sos un desarrollador de software? si la respuesta es no, por qué?
      En Agiles somos todos desarrolladores, solo que al programador se le atachó el mote de “desarrollador”, pero es un codificador y sin nosotros los testers y sin los otros cross-functional-roles, es incapaz de desarrollar (al menos a ciertas escalas) y si lo hiciere solo por su cuenta, en algún punto habrá usado los sombreros de otros roles. No lo crees?
      Si de herramientas hablamos, bueno, son solo de soporte y lo interesante de ellas es que se adaptan a lo bien o mal que diseñemos nuestros procesos de trabajo que en definitiva componen el “aparato comunicacional”. Que pueden ser necesarias no lo niego, pero no es donde la comunicación vive si quieres realmente empoderar contextos colaborativos, Agiles.

      Cierta vez dije una broma en uno de los equipos con los que trabajé:
      “nuestra empresa genera software tan interesante que nuestros sistemas incluyen gratis un montón de cosas que aún desconocemos (a las que típicamente llamamos bugs o issues), pero que alguien tarde o temprano descubrirá.”
      La idea fue graciosa en el momento pero a las claras dejaba ver que no se estaba usando un marco de trabajo que nos ayude a anticipar “esa falta de conocimiento” y estoy hablando de testing pero como un mindset de equipo y de organización, donde TODOS en algún momento utilizábamos el sombrero del tester, en lugar de asumir que un especialista tester “nos de el OK” en alguna fase tardía.

      Ciertamente hay personalidades y preferencias y creo que esto de Agile excluye a cualquiera que declare:
      . yo no estoy interesado en participar en reuniones
      . yo no necesito participar de entrada en los proyectos
      . yo prefiero que me digan que hay que testear y me lo dejen hasta que tenga un resultado
      . yo les avisaré por las tools lo que encuentre y si no es un defecto lo descartamos y listo
      . no yo estoy interesado en interactuar con otros para “saber demás”
      . yo no me meto en las bases de datos, ni en los webservices, ni me interesa el código, ni los diagramas de arquitectura, etc, etc…
      . yo SI necesito un líder o supervisor que me diga: como priorizar, como reportar, como organizar, como ser inquisitivo, como explorar, como ser curioso, como interactuar, como ayudar a mi equipo más poderoso

      Saludos cordiales, Javo.

      • Estuve leyendo mi post y el tuyo, y la verdad, verlo a la lejanía veo que tenés razón, ajajaja. Debe ser que ese día tenía pésimo humor y me la agarré con el blog, ajajja. Pero ahora siento que es importante el trabajo en equipo y siempre tratar de llevar adelante lo mejor que se pueda para que el proyecto salga victorioso.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s