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.

4 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.

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