Resumen Agile Testing

resumen-agile-testing

Te comparto el resumen del libro Agile Testing de Lisa Crispin y Janet Gregory. El objetivo de este libro es dar una visión amplia y clara de qué significa ser un tester en un equipo agile. Esta visión se complementa con acciones y responsabilidades concretas a desempeñar. Este nuevo rol no se limita al testing sino que es también un agente de cambio. Por este motivo este libro lo he encontrado también muy recomendable para Scrum Masters que quieren guiar y ayudar en equipos con un enfoque más tradicional del testing, todavía largamente extendido hoy en día.

Es un libro práctico muy enfocado en el proceso. Sobre todo da muchas pautas de comportamiento y muchos ejemplos prácticos de situaciones concretas. Durante todo el libro se guía por los principios clave que debe practicar un agile tester, especialmente la colaboración y el feedback con desarrolladores y Product Owner. Lo más interesante para mí es la última parte, donde explica con detalle qué actividades suceden en todo el ciclo de vida de un equipo Scrum, incluyendo Release.

Sin embargo, pienso que en algunas partes del libro estas explicaciones son demasiado detalladas. Me ha parecido largo de leer (tiene 533 páginas), en ocasiones el contenido se repetía demasiado o eran cosas que ya sabía de otros libros Agile. Además encontré que en la pequeña parte más técnica, hablaba de tecnologías muy desfasadas como Easyb, Crosscheck o Canoo (el libro se publicó en 2009). Finalmente me sorprendió encontrar ciertas cosas propias de entornos tradicionales en un libro de referencia Agile (p.e. releases de 2-3 meses, iteraciones de release o traspaso de entregables entre desarrollo y operaciones).

En fin, te dejo con mi resumen de Agile Testing para que puedas evaluar por ti mismo si puede resultar una lectura interesante para ti.

Agile-Testing

I. Introducción

1. ¿Qué es Agile Testing?

En un equipo agile todo el mundo es responsable del testing y de entregar un producto de máxima calidad. Los desarrolladores escriben tests unitarios (bajo nivel) con TDD (Test Driven Development).

El tester agile está entre negocio entendiendo los requisitos y los desarrolladores para comprender la complejidad técnica de la solución. De forma colaborativa, definen los casos de test de negocio (alto nivel) y los casos extremos y los automatizan. Como uno más del equipo tienen un entendimiento profundo de las necesidades de negocio y participan en su definición. Complementan los requisitos con tests cases completos basados en ejemplos identificados con negocio y hacen test exploratorio manual para encontrar posibles bugs.

En contraposición, en proyectos tradicionales el equipo de QA recoge un desarrollo de requisitos cerrados y lo prueba antes de una entrega planificada para una fecha.

2. 10 principios para testers agile

El tester agile está continuamente buscando formas para entregar más valor y con más calidad. Utiliza preguntas y ejemplos para asegurar que lo que necesita el negocio es lo que construye el equipo. Los 10 principios:

  1. Dar feedback continuo. El tester participa en los requerimientos con ejemplos y casos de tests y después trabaja con los desarrolladores para convertirlos en tests automáticos y ejecutarlos frecuentemente.
  2. Entrega valor al cliente. El foco del equipo es identificar siempre lo que más valor aporta al usuario y entregar solo eso pero con calidad en cada iteración.
  3. Comunicación cara a cara. El tester debe estar en las conversaciones entre desarrolladores y negocio. Facilitan la discusión normalmente mediante ejemplos.
  4. Muestra valentía. Para hacer cambios y refactors, gracias a los tests automáticos. Para responder a preguntas difíciles sobre su rol. Para recuperarse después de fallar. Para pedir ayuda en las cosas que no llega.
  5. Simplifica. Busca la solución que dé valor y que sea simple. Ayuda al cliente a establecer el nivel de calidad adecuado. Simple significa probar con el tiempo y herramientas que tienes para asegurar calidad y que el cliente tenga lo que necesita. Quizás solo automatizar algunos smoke tests y hacer exploratorios para aprender sobre el sistema.
  6. Practica la mejora continua.
  7. Responder a cambios. Para los testers es especialmente difícil, tienen que estar en constante diálogo sobre los cambios al igual que los desarrolladores.
  8. Autoorganización, también a la hora de decidir la estrategia de testing y ejecutarla.
  9. Foco en las personas. El tester es un par más en el equipo.
  10. Disfruta.

II. Retos organizacionales

3. Cambios culturales

Cultura = normas, valores, asunciones. Un cambio a agile en una cultura jerárquica puede ser doloroso. Los testers = personas pueden resistirse a los cambios. Si hay un equipo QA con poder, sobre todo los managers se resistirán a perder ese poder.

Agile va en contra de la imagen del tester como policía de la calidad. Tiene que aprender a compartir esa responsabilidad de la calidad con el equipo. A esto se suma las capacidades técnicas que necesitan para automatizar.

Otro choque cultural es el trabajar extra para cumplir fechas. En agile se busca el ritmo sostenible para entregar con la máxima calidad.

El tamaño importa, cuanto más grande y jerárquica sea la compañía más difícil será el cambio.

agile testing

Barreras para el cambio por parte de los QA testers :

  • Pérdida de identidad al entrar en un equipo multidisciplinar
  • Falta de formación y coaching en su nuevo rol
  • No entender los conceptos agile, por ejemplo que el testing involucra a todo el equipo y no es solo hacer mini-waterfalls que duren una iteración
  • Experiencias pasadas y actitud pasiva

Estrategias para una transformación agile exitosa:

  • Habla sobre los miedos
  • Dar ownership al equipo, que identifiquen y solucionen sus propios problemas
  • Celebra los éxitos, ej: unos chocolates o un trivia

4. Logística en el equipo

Hay razones para tener un equipo de testers independiente de los desarrolladores, pero independientes != separados. El equipo de testers es más una comunidad.

Es necesario formación por ejemplo en pair testing, automatización y trabajar con requisitos cambiantes. El tester es uno más en el equipo, y sus tareas están en el tablero del equipo y se estiman y planifican. Una historia no está done si no está testeada.

Los testers deben estar en el mismo sitio que los desarrolladores, compartiendo espacio de trabajo para que la comunicación suceda. Si no es posible, hay que buscar maneras creativas de conseguirla como teleconferencia, mensajería instantánea o espacios comunes.

Los testers participan en las mismas reuniones que el resto aportando su conocimiento. Toma la iniciativa si esto no está sucediendo.

No hay un ratio desarrollador-tester correcto, depende de cosas como la complejidad del producto o la experiencia del equipo. En cualquier caso, los desarrolladores participan tanto en el testing manual como automático.

5. Transición desde un proceso tradicional

En agile buscamos las métricas que provocan el comportamiento que buscamos. Algunos ejemplos:

  • Tiempo de ciclo, desde que llega al equipo hasta que produce beneficios
  • Retorno de la inversión

Las métricas son útiles cuando están alineadas al objetivo que se quiere conseguir y no se usan de forma aislada.

Aunque el equipo use un tablero, es recomendable usar un sistema de tracking de bugs (i.e. Bugzilla) para adjuntar la información necesaria (i.e. capturas) y tenerla para referencia. Pero no se deben usar como herramienta de comunicación entre desarrolladores y testers o como backlogs secretos.

Considera tener un documento de estrategia de test genérico para todos los proyectos. Esto evitará que tengas que hacer planes detallados de test que nadie leerá.

La trazabilidad se consigue indicando en los commits de qué historia se trata o automatizando los test y enlazándolos al requisito.

III. Los cuadrantes del testing agile

6. El propósito del testing

4 cuadrantes para clasificar los tests, según si sirven al equipo o evalúan el producto, y si están del lado del producto o son técnicos.

Q1 sirven al equipo y técnicos, tests unitarios y TDD

Q2 sirven al equipo y del lado de producto, tests de negocio, generalmente con ejemplos

Q3 UAT, tests de usabilidad y tests exploratorios, evalúan el producto desde el lado del usuario con ejemplos de negocio, generalmente manuales

Q4 tests de rendimiento, escalabilidad, carga y seguridad, evalúan el producto y son técnicos

En cada historia/proyecto tienen que estar cubiertos los 4 cuadrantes para que se considere done. Usa los cuadrantes para garantizar la calidad del producto y no amontonar deuda técnica.

7. Tests técnicos que sirven al equipo

Los tests unitarios son clave para el desarrollo agile sostenible. Sirven para asegurar que el código hace lo que se espera y para guiar el diseño. El TDD (test driven development) asegura el diseño simple y el código testeable. Los equipos que no tienen estas prácticas suelen caer en el antipatrón mini-waterfalls. Los testers pueden ayudar con los casos a probar.

Para hacer TDD el código debe estar desacoplado. El resultado es un código simple y testeable sustituyendo bases de datos, interfaz gráfica y dependencias externas. Patrones como arquitectura en capas o ports and adapters facilitan la testability. Es muy importante que los tests unitarios ejecuten en <10 minutos. Si tarda más se deben reducir, sustituir dependencias o mejorar el hardware. Los tests funcionales se ejecutarán con menos frecuencia.

Para convencer al equipo de hacer TDD busca ayuda de un desarrollador respetado y dispuesto a probar.

Herramientas esenciales: control de versiones, IDE, automatización de builds y framework de tests unitarios.

8. Tests de negocio que sirven al equipo

Los tests de negocio (o tests de aceptación) expresan requisitos con ejemplos. Estos ejemplos los utilizan los desarrolladores para hacer los tests automáticos. Los tests de aceptación incluyen también criterios técnicos como rendimiento, seguridad… Se escriben antes de codificar ya que dirigen el desarrollo a un nivel más alto que los unitarios. Una parte de estos test formará la suite de tests de regresión.

Las historias son casi una frase al inicio. Con conversaciones con el equipo de producto y equipo de desarrollo los testers crean los ejemplos, criterios de aceptación y tests necesarios para cada historia. Para ello, los testers usualmente hacen preguntas, proponen ejemplos y hablan con clientes cara a cara. Utiliza prototipos de papel y tests de Mago de Oz (humano que hace de máquina) para hacer tests de usabilidad.

Cuando afrontas un desarrollo grande o complejo una buena estrategia es hacer primero el happy path end to end más fino que exista. A partir de ahí ya puedes ejecutar tests, obtener feedback y continuar el ciclo. La historia estará done cuando hayas ejecutado también los tests exploratorios, de rendimiento y de usabilidad.

Los tests ayudan a mitigar riesgos. Una vez cubierto el happy path busca con el equipo de producto y equipo de desarrollo los edge cases sin olvidar la foto global.

9. Herramientas para tests de negocio

Para capturar los requisitos algunas herramientas pueden ser mockups, checklists, mapas mentales, hojas de cálculo o diagramas de flujo. El nivel más alto es usar directamente Fitnesse para especificar requisitos. También útiles herramientas BDD como easyb.

Para testear servicios Web usar SOAPUI o Crosscheck.

Para testear GUI Watir (Ruby), Selenium o Canoo.

Los tests siempre deben estar en el control de versiones y en verde. Si fallan debe ser porque el requisito ha cambiado. En este caso la prioridad es cambiar el test a verde de nuevo, antes incluso que implementar el cambio.

10. Tests de negocio que evalúan el producto

Tras los tests automáticos, los tests exploratorios manuales ayudan a encontrar ejemplos erróneos, fallos de usabilidad o de flujo, asunciones incorrectas o facilitan encontrar nuevas necesidades, usando el pensamiento crítico y el aprendizaje.

Los tests exploratorios pueden ser estructurados (se buscan patrones, heurísticas) y timeboxed.

Para mostrar a stakeholders puedes usar las demos de final de iteración, testing con escenarios de la vida real o tests exploratorios (sin script).

Para los tests del usabilidad usa “personas” con personajes inventados por ti o famosos.

Es posible además diseñar tests automáticos para APIs y web services de una manera simple. No hay que olvidar también testear la documentación, especialmente los manuales de usuario e informes.

Se pueden usar los scripts de automatización para hacer setup del entorno o simuladores para hacer tests exploratorios manuales. Monitoriza los logs cuando hagas este tipo de testing.

dark agile testing

11. Tests técnicos que evalúan el producto

Algunos de estos tests (ej. seguridad) requieren skills especiales que no siempre están en el equipo. Otros es cuestión de cultura y mindset del equipo. Se pueden incluir al backlog como historias técnicas, y es mejor implementar estos tests de forma iterativa incremental.

Seguridad: existen herramientas para análisis estático y dinámico del código de la aplicación y escaneo de vulnerabilidades (ej. Nessus). Incluye un set de estas herramientas en tu CI/CD.

Mantenibilidad: aplica los mismos estándares de código y buenas prácticas técnicas a los tests automáticos.

Interoperabilidad: tests que aseguran que varios sistemas pueden comunicarse entre sí.

Compatibilidad: con versiones de navegador, dispositivos de accesibilidad…

Fiabilidad: si el sistema falla tras un uso intensivo del mismo.

Instalabilidad: menos importante con CI/CD.

Escalabilidad: preparar el sistema para un gran número de usuarios.

De rendimiento: evalúa los cuellos de botella del sistema. Herramientas: httperf, jMeter, jProfiler.

De carga: prueba que el sistema puede aguantar muchos usuarios al mismo tiempo. Herramientas: Pounder, OpenWebLoad, NetScout (red).

Utiliza entornos de tests similares a los de producción y extrapola los resultados. Cuida la gestión de memoria ya que suele ser un punto común de fallos durante picos de uso.

12. Resumen de los cuadrantes de tests

En el ejemplo de un equipo Scrum que se hace cargo de un sistema legacy, empiezan con prácticas técnicas de XP, pair programming, TDD y tests de aceptación creados por el product manager.

Se automatizaron algunos tests funcionales de la web con Watir, y los servicios Web con la librería de tests unitarios de Ruby. Se creó un simulador para probar un sistema empotrado de mediciones junto con un script que leía datos de test y resultados esperados de un Excel.

Los desarrolladores usan tests exploratorios y tests funcionales automáticos para detectar bugs mientras desarrollan. También crearon un cliente proxy para leer las colas de mensajes y enviar alertas en caso de fallo.

Los testers tienen tests automáticos end to end y simuladores, que encuentran bugs esporádicos de transmisión o integración.

Se creó un sistema para que el cliente, que no estaba co-localizado con el equipo, probara el sistema. Así se cambió la fase de UAT por una aceptación continua.

IV. Automatización

13. ¿Por qué queremos automatizar tests y qué nos frena?

Razones:

  • Los tests manuales consumen mucho tiempo, y llevan a deuda técnica, diseños complejos de testear y frustración.
  • Los procesos manuales son propensos a error, sobre todo con deadlines.
  • La automatización deja tiempo al equipo para hacer trabajo de calidad, como aprender y diseñar con calidad.
  • Los tests de regresión automáticos son una red de seguridad. Si no existen, esa red son los testers.
  • Los tests de regresión automáticos proveen feedback rápido y frecuente. Los bugs se detectan inmediatamente, cuando son muy baratos de solucionar.
  • Los tests guían el desarrollo
  • Los tests proveen documentación viva siempre actualizada.
  • La automatización tiene un gran ROI. Puedes centrarte en corregir las causas raíz con un buen diseño en lugar de simplemente corregir bugs.

¿Qué nos frena?

  • La actitud de algunos desarrolladores habituados a waterfall, separados de los testers y del testing
  • Inversión demasiado alta en tiempo y recursos
  • No tener claro el objetivo, y en momentos de pánico (deadlines) volver a los viejos hábitos (“ya automatizaremos después de la entrega…”)
  • Código legacy, no está diseñado para automatizar
  • Falta de experiencia y/o alta rotación en el equipo, la curva de aprendizaje es alta
  • Tests ligados a la implementación junto a muchos cambios en ésta
  • El foco está solo en automatizar, no en testear
  • El foco está solo en los problemas técnicos, no en solventar las necesidades reales

14. Una estrategia de testing agile

Usa los cuadrantes para identificar qué tests automáticos necesitarás en tu contexto. Para decidir cuánto de cada tipo es útil la pirámide del test.

Hay una base fundamental hecha de tests unitarios y de componentes en el mismo lenguaje que el sistema, usualmente con xUnit. En la capa central están los tests funcionales a nivel de API que prueban que hemos hecho el producto correcto. La capa superior ataca la GUI para implementar algunos tests funcionales de regresión (ya que son muy lentos y difíciles de mantener) y tests de interfaz (probar links, que los botones están activos…). Encima de todos estos tests automáticos están los manuales exploratorios y de UAT. Esta visión debe ser compartida e implementada por todo el equipo.

Integración continua es una práctica esencial para lograr tests automáticos de calidad. Los builds deben ejecutar los tests unitarios para dar feedback inmediato (<10 minutos). El resto de tests se pueden ejecutar cada noche por ejemplo.

La automatización no solo aplica al testing, cualquier tarea repetitiva es candidata a automatizarse (verificación, creación de datos, setup…).

Los tests que NO debes automatizar son los test de usabilidad, exploratorios, los que son de un solo uso y los que nunca fallarán.

Cuando afrontas una base de código legacy sin tests, comienza por los módulos más críticos y que reciben más cambios. Pieza por pieza ves añadiendo tests unitarios a la vez que refactorizas. Comienza siempre con los test unitarios pues tienen el mayor ROI. Los test de GUI son más propensos a cambiar y fallar y deben limitarse a los test de regresión. Posiciona tus test lo más abajo posible de tu pirámide.

Estos principios agile también aplican a los tests: elige la solución más simple que te funcione, experimenta y desarrolla en forma iterativa, involucra a todo el equipo, trabaja siempre con calidad, aprende mientras haces y sigue buenas prácticas técnicas (ej. Etiqueta tus tests con la misma versión que tu código en el control de versiones) .

Evita al máximo el acceso a la base de datos en los tests para más velocidad.

Elige las herramientas en función del conocimiento de tus desarrolladores, de tu stack tecnológico actual o de otras herramientas con las que integrar. Reserva tiempo para analizar y decidir.

Mantén las especificaciones (código) y los resultados de las ejecuciones de los tests accesibles para todo el mundo.

V. Una iteración en la vida de un tester

15. Actividades planificando una entrega (release)

En agile la planificación de la release es a alto nivel, ya que el análisis exhaustivo se hace siempre just-in-time. Los testers deben participar cuando el equipo estima las tareas o historias, ya que no se dan por hechas hasta que no están probadas y las pruebas requieren igual si no más esfuerzo e importancia que el desarrollo. Los testers también dan un punto de vista diferente del que emergen preguntas diferentes al PO. También piden ejemplos y casos de uso para entender cómo se usará y qué valor aportará. Puede ser útil escribir un test plan ligero con los riesgos alto nivel, asunciones, automatizaciones, infraestructura, datos de prueba…

Algunas métricas a medir sobre la release son: tendencia de # tests en verde, cobertura de código, # defectos.

16. Arrancar a toda velocidad

Sé proactivo, investiga y reduce riesgos de las historias un poco antes de que comience el Sprint, en los casos en que haga que todos vayan más rápido después y no se desperdicie ese tiempo por re-priorizaciones (ej. Sesión de refinamiento, escribir test cases).

Prepara preguntas, ejemplos concretos de lo que entra y lo que no en el scope. Utiliza mockups de las pantallas y ejemplos concretos.

También revisa defectos y plantea el valor de corregirlos.

17. Arranca la iteración

En la sesión de planificación usa ejemplos y escribe los casos de test junto a los desarrolladores. Ayuda a separar en rebanadas finas la funcionalidad esencial y deja aparte los “nice to have”.

Después cada historia se divide en tareas de desarrollo y testing.

Asegura que se estima teniendo en cuenta las tareas de testing.

Al arrancar la iteración el tester habla con stakeholders para especificar ejemplos y tests alto nivel para guiar el desarrollo (ej: sketches, diagramas, mockups). Después habla con los desarrolladores para repasar y mapear en las rebanadas finas de las historias.

mobile testing

18. Guiando la codificación

Mientras los desarrolladores codifican, los testers crean tests automáticos funcionales (que fallarán pues aún está en desarrollo) que entregan cuanto antes. Primero las historias con más riesgo y los happy path, y después se amplía con los casos extremos. Evita en antipatrón del desarrollador iniciando una nueva historia cuando todavía no se ha terminado el testing automatizado de la 1°. Asegúrate de comunicar en todo momento con el desarrollador, facilita esta comunicación si es necesario. Consulta con stakeholders y PO para las dudas y mantenles informados del progreso.

En el caso de encontrar un defecto comunicar directamente al desarrollador, preferiblemente cara a cara. Si es posible, corrige los defectos tan pronto los descubras. Otra opción más costosa es registrarlos y después priorizarlos (útil si no hay tiempo en la iteración o en sistemas legacy si el error vale la pena arreglarlo). Los defectos que rompen la build se deben arreglar inmediatamente en cualquier caso.

Considera incorporar métricas de seguimiento y calidad durante la iteración.

19. Finalizando la iteración

Los testers pueden escribir el feedback en la demo de iteración. También son uno más en las retrospectivas. Y no olvides celebrar los hitos aunque sean pequeños y dar reconocimientos a los compañeros.

20. Entrega con éxito

Antes de entregar al cliente todo debe estar listo. Pueden haber tareas adicionales en la iteración de entrega como documentar, pruebas en entornos integrados con sistemas externos, pruebas manuales adicionales o pruebas de carga y estrés. Prueba todos los scripts de base de datos en el entorno de staging.

Crea una checklist de tareas de release y conviértelas en tareas del tablero si es necesario

Involucra a negocio con UATs si están cerca o alpha/beta testing.

El tester también ayuda a definir criterios de aceptación para la release, ej. cero defectos críticos, informe con todos los tests ejecutados y en verde, se cumplen los criterios de aceptación de todas las historias…

Si tienes equipo de soporte, utilízalo como tu primer cliente y comunícate con ellos. No solo para la release, sino para identificar partes de la aplicación conflictivas o poco intuitivas.

21. Factores clave de éxito

  1. Todo el equipo es responsable de la calidad y el testing
  2. El tester no es un policía, guía y ayuda al equipo a conseguir resultados de manera cercana
  3. Automatiza los tests de regresión
  4. Da y recibe feedback, sobre los tests ejecutados, las métricas, los defectos encontrados, comportamientos observados…
  5. Usa prácticas técnicas clave como integración continua (al menos 1 vez al día), entornos de test, gestión de deuda técnica, desarrollo iterativo incremental, desarrollo y testing avanzan en paralelo en la iteración.
  6. Colabora con los stakeholders y clientes para clarificar los requisitos con ejemplos y escenarios de uso junto a desarrolladores
  7. Analiza la big picture con frecuencia

 

Hasta aquí el resumen del libro Agile Testing. Si te ha gustado y estás pensando en comprarlo, puedes hacerlo desde el siguiente enlace de afiliados. A ti no te cuesta nada y a mí me ayudarás a mantener este blog.

También te puede interesar...

Sprint Planning GTD para los objetivos del 2015 En la metodología ágil de desarrollo de software Scrum existe una ceremonia llamada Sprint Planning, en la que los miembros del equipo Scrum eligen me...
Tablero Kanban (Kanban Board) Kanban es una metodología que nos ayuda a mejorar los flujos de trabajo en cualquier proceso productivo, incluido el desarrollo de software. Se compon...
Los 7 desperdicios LEAN del software (y II) Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *