Agile testing y gestión de defectos

Desde hace un buen tiempo me encuentro en contra de la registración de defectos masiva, principalmente para entornos de desarrollo de software Agile, donde en resumidas cuentas un defecto pierde su razón de ser ni bien es corregido y verificado en el mismo Sprint de desarrollo.

Muchos me han preguntado, pero como hacen los desarrolladores en Agile para saber de que estamos hablando cuando alguien del team encuentra una anomalía, y mi respuesta siempre fue que el trabajo cara a cara evita cualquier tipo de aparato comunicacional y facilita no solo la corrección sino la mejora.

Por otro lado es cierto que existen muchos modelos de trabajo, como los tercerizados o los remotos, que impiden que los equipos se encuentren co-localizados y entonces ya existe la necesidad de algún sistema de gestión de defectos, sobre todo si hay personas que se dedican exclusivamente al testing de los items de trabajo.
Para estos esquemas también hay soluciones verdaderamente livianas, pero sin llegar a mencionar a ninguna, les diría que lo que prima es la real posibilidade contactarnos entre desarrolladores y testers para hablar de los defectos, su severidad, impacto, priorización y soluciones posibles.

Los invito a intetar un esquema simplista, donde el tester detecta el defecto, lo ingresa en una cola de trabajo inmediato, el equipo en una reunión cercana analiza los defectos acumulados (cola de trabajo), prioriza y resuelve. Tomen fecha de ingreso del defecto a la cola y feche de verificación de la solución.
Tomen exáctamente los mismos tiempos para un defecto que ingresa por una herramienta de gestión de defectos y comparen. Luego me cuentan.

Por lo pronto comparto un interesante artículo que habla de un método de gestión de defectos utilizando la automatización de pruebas como herramienta de evaluación del defecto y entidad documentacional, donde lo que se gana es un activo de software (test case automatizado) y capacidad de repetir la ejecución de la prueba las veces que se requiera.

Este punto de vista es muy efectivo y soluciona enormemente varios problemas a la vez, como la falta de cobertura por caminos alternativos significativos, aumenta el volumen de pruebas de regresión fiables, la registración del defecto, etc.

Source: STAREAST: Agile testing and defect tracking.

Advertisements

La calidad es siempre negociable

La calidad es negociable y en Agile es tan negociable como que la misma es escalable y varia indudablemente con cada iteración, a medida que una historia de usuario emerge como un motor de trabajo para el equipo.

Que “La Calidad No Es Negociable”  lo he leído inclusive en el famoso libro “scrum-y-xp-desde-las-trincheras”, pero queda claro allí que podemos hacer distinciones entre cosas que pueden evolucionar desde diseños y modelos básico, hasta un entregable de avanzada, y cosas que necesariamente deben tener un grado de calidad mínimo y suficiente para garantizar trabajos futuros.

Entre ambas cosas, podemos distinguir para el primer caso, interfaces en general, botones, comandos, scripts, webservices y hasta funciones que son implementadas como soluciones de base y pueden evolucionar completamente en futuras iteraciones. Para el segundo caso, nos referimos a elementos de diseño y arquitectura que mal implementados atentan contra factores de calidad como la mantenibilidad, modularidad, escalabilidad, seguridad, integridad, disponibilidad, etc., e inclusive contra la testeabilidad.

En Agile tenemos presente que la potestad de la calidad la tiene todo el equipo de trabajo y no un “grupo de QA” y para un mejor aseguramiento, preferimos el “testing temprano y colaborativo”, el que nace desde el primer día en que se conversa con dueños de productos (PO), Analista de Negocios, usuarios y otros interesados, el que continúa en nuestras mesas de análisis y continua con las decisiones del equipo y que facilitan que cada involucrado pueda agregar valor a favor de un desarrollo de calidad.

Un principio que sostenemos y nos ayuda en esta cadena iterativa y evolutiva de la calidad del software, es que los equipos Agiles no se dividen en Desarrolladores y Testers (aún cuando hay especialistas en ambas cosas), sino que se mancomunan en la figura de Team Members.

En Agile sabemos que una actividad de testing, exhaustiva o no, al final de la cadena de desarrollo no aporta calidad, aún cuando pueda dar índices y métrica.

Sin embargo esto que suena tan lindo, de ninguna manera se obtiene en los primeras iteraciones, sino que en futuros Sprint, el esperado de calidad comienza a tomar la forma negociada. En nuestras discusiones de proyecto, constantemente evaluamos alguna posible falta de funcionalidad o funcionalidad pobremente desarrollada y la enorme mayoría de la veces, se logra determinar que mientras futuros Sprints darían la cobertura esperada, en el actual contamos con una calidad “lo suficientemente buena”, sin descartar que en cada Sprint finalizamos y demostramos un incremento “potencialmente entregable” Utilizamos un concepto que se llama “good enough quality”, lo cual nos da los límites suficientes y necesarios para el testing que aplicaremos en cada nivel del desarrollo. Lo más importante, negociamos con el PO el grado de calidad de cada incremento.

Puedo decir  a estas alturas de mi experiencia, que cada vez más, y más empresas de cualquier envergadura  migran a Agile, inclusive para sus productos más críticos. Ya lo se, las empresas maduras no buscan “la bala de plata” pues ya saben que no existen, y quien adopte Agile o cualquier otro framework por moda solo está destinado al fracaso rotundo, de hecho atribuyo el fracaso de CMMI a la tendencia fashion de quienes consiguieron una evaluación positiva y luego encajonaron el proceso.

Justamente, sucede que hasta el día de hoy no han podido lidiar con los tiempos de respuesta exigidos cada vez más cortos, los cambios de requerimientos cada vez más demandantes y mayor diversidad de servicios asociados a productos, por lo que vienen dejando enormes “huecos de calidad” que sus metodologías tradicionales facilitan.

No intento debatir sobre metodologías, pero si tal vez un paradigma y éste que a muchos trato de explicar nos dice que “la calidad es siempre negociable”, pero podrás con esta negociación o no, dependiendo de tu paradigma de gestión de proyectos y mucho más que eso, dependerá del paradigma cultural de las organizaciones.

Por eso podremos ver que los managers se entorpecen en intentar modificar sus procesos para adecuar sus organizaciones a las nuevas corriente, pero al carecer de los principios correctos del paradigma al que intentan imitar, solo logran confundir a su plantel y no pasa mucho tiempo en que prefieren retroceder debido a los intensos fracasos.

La evolución es para todos, para algunos de una forma, para otros de otra forma, pero bueno, insisto, no se puede tener cuerpo sin espíritu.

calidad

Cómo ven que a los productos de software desarrollado por un equipo Agile sean probado (testeado) por un equipo no Agile (tradicional)?

No es una locura, pasa bastante seguido. Piensen en un cliente que contrata una empresa de desarrollo Agile o varias de ellas para distintos productos y los pre-releases son enviados a otra organización diferente para el testing de sistema donde se corren exaustivamente distintos tipos de pruebas, como usabilidad, bases de datos, performance, seguridad (autenticación/ autentificación), etc.

Esta discusión la abrí hace 20 días en el grupo ScrumMaster de Linkedin y aún tiene una interesante participación, con variadas opiniones expuestas por los distintos miembros del grupo.

Lo primero que pude notar es que este planteo del testing realizado por un equipo NO AGILE a un producto desarrollado por un equipo AGILE, es algo que en realidad no viene a ser muy común en el mundo del desarrollo del software. Al menos puedo tomar esta deducción en base a que no muchos se animaron (en relación con otros debates) a participar y a su vez, los que participaron, no ofrecieron muchas variantes, desde el punto de vista de experiencias reales con este formato que propuse.

Desde una perspectiva defensiva hacia el equipo Scrum pareciera ser importante evitar a toda costa la irrupción de parte del equipo de testing al equipo de desarrollo y es entonces cuando el verdadero desafío tiene que ver en como resolver situaciones en la que se detectan errores de severidad alta, que tienen estrecha relación con el trabajo “ya finalizado” y requiere modificaciones importantes o cambios en las características originales desarrolladas en Sprints anteriores.

Dicho de manera gráfica, si el equipo independiente de testing detecta issues debe tener en claro que bajo Agile, lo que el equipo de desarrollo ya liberó, no puede ser modificado y cualquier mejora o cambio, requerirá de la introducción de nuevos elementos al backlog del producto y la gestión correspondiente.
Entonces una solución podría ser que el pre-release existente se transforma en un pre-release con issues conocidos y se refleja en las notas del incremento.

Pero que sucede en escenarios en los que el cliente entrega la potestad al equipo de testing independiente, de determinar si el producto se puede liberar o no.

Es sabido que hay organizaciones que exigen que sus productos críticos sean evaluados para la superación de ciertos criterios de calidad a los cuales llaman “Portales de Calidad”, los cuales solo pueden ser superados por el equipo de testing siguiendo los tradicionales planes de calidad y testing de proyectos también tradicionales. Esta situación sin duda pone en una posición precaria al equipo de desarrollo Agile, políticamente hablando.

Desde el punto de vista de Agile, se podría plantear también que mientras el equipo de testing se concentra en registrar issues de iteraciones pasadas, el equipo de desarrollo se concentra en generar un nuevo incremento funcional de valor para el cliente y cabe la posibilidad de que la resolución de la mayoría de los issues detectados por testing, carezcan de algún valor para cliente en Sprint posteriores.

Diferencias metodológicas

Un punto muy importante a considerar es la gran diferencia metodológica del proceso de testing entre un equipo de Testing-Agile y un equipo de Testing-Tradicional. Mientras que los primeros cobran vida y sentido en las mismas fases del desarrollo del producto (para este ejemplo en particular) los segundos tienen sentido cuando el producto ya existe y debe ser evaluado.
Metodológicamente hablando, el Testing-Agile no sería tan exigente en cuanto a la documentación requerida para realizar las pruebas de software, no exigiría un plan detallado, ni evidencias basadas en casos de pruebas del tipo script ejecutadas en determinados ciclos, ni pedirá métricas del testing.
En contraposición, el Testing-Tradicional sería exigente en todos esos aspectos y muchos más para determinar la cobertura de pruebas y calidad para el productos. También habría un plan detallado y varios puntos de control a respetar exaustivamente.

Variaciones de esta naturaleza, exige la comunicación entre ambos equipos y la consiguiente negociación para facilitar los hitos de liberación.
Dicho de otra forma, la colaboración del equipo Agile puede no ser una responsabilidad contractual, pero si es una necesidad imperiosa que el equipo Agile proporciones principalmente su know-how del dominio.

Y por otro lado considero una gran responsabilidad para con el mismo equipo de desarrollo, favorecer que sus creaciones sean correctamente interpretadas y evaluadas. No cabe la posibilidad de un desentendimiento o el mismo trabajo ya “hecho” fracasará por la sola falta de colaboración entre equipos.

Testing Exploratorio Vs. Diseño de Casos de Pruebas?

La principal diferencia no radica en si eres un “Testing tradicional” o un “Testing Agile”, sino en el enfoque del proceso de testing que facilita el aporte de valor al proceso de desarrollo. Ese enfoque es el testing exploratorio, que se basa principalmente en algunos aspectos que son claves para el proyecto, como la velocidad de respuesta y la generación de pruebas de valor.

Velocidad de Respuesta

El primer criterio (velocidad de respuesta) tiene que ver con la prontitud de la ejecución de pruebas para detectar fallos de criticidad, para ello el equipo debe congeniar un muy alto grado de sincronizmo y apertura a la colaboración.

Quiero decir que no debemos trazar líneas divisorias que impidan que algo se pruebe lo antes posible (considerar Fail Fast). Esto a su vez facilita un aprendizaje acelerado y continuo a cerca de las features que se desarrollan, como también la detección temprana de oportunidades de cambio.

Otro valor agregado es que como testers nos volvemos especialistas en el producto y podemos servir mejor a múltipleas áreas, no solo a los developers del equipo.

La imagen de dumies en un automovil prototipo representa la posibilidad real de probar algo sin que esté finalizado.

Pruebas de Valor

La segunda característica (pruebas de valor) radica en la inteligencia puesta en testing, lo cual deja de ser una potestad de los “probadores”, sino que por la falta de líneas divisorias que mencioné antes, todos, inclusive clientes, son responsables y partícipes de esa inteligencia aplicada a las pruebas.

Esto es un buen fundamento que explica por qué NO nos dedicamos al diseño de casos de pruebas al principio, aún cuando fuera posible, sino al diseño de sesiones exploratorias, las cuales no las puedes diseñar con solo tener un documento requerimiento frívolo o solo historias de usuarios, únicamente es posible si interactúas con todo el team para detectar escenarios de criticidad.

No olvidemos que las pruebas exploratorias, no son un procedimiento sino un enfoque y nunca deberíamos poner en riesgo el primer criterio que mencioné (velocidad de respuesta).

Consideremos un par de detalles para justificar la no cración de casos de pruebas y si el diseño de sesiones exploratorias:
Crear un set de pruebas de sistemas al inicio nos resta la posibilidad de interactuar con los productos en sus fases mas temprana, por ende nuestro aporte es menor a cada día que se avanza sobre el desarrollo. Dicho en otro términos, mientras escribo no pruebo.

Quiere decir esto que nunca más escribiremos casos de pruebas funcionales?

La verdad es que la respuesta tiende cada vez más a NO, NO LO HAGAS!.

Cada vez que sea posible busquemos la forma de automatizar el proceso de pruebas funcionales y cada vez que no sea posible automatizar, escribamos pruebas funcionales por que en algún momento a lo largo de nuestro proyecto, normalmente antes de un release, deberíamos considerar correr pruebas regresivas desde el punto de vista del cliente (Aquí es a donde le pido cordura a los desarrolladores que sostienen que las pruebas de regresión bajo CI son suficientes y deberían bastar).

El asunto importante es que no releguemos nunca la posibilida de hacer pruebas funcionales de regresión antes de un release y para hacerlo, te lo aseguro, las sesiones exploratorias podrían no servirnos y si serían útiles casos de pruebas que hayamos diseñado (escritos o automatizados).

La imagen del dumie en un automovil finalizado representa la necesidad de probar tambien en este momento. Pero ojo! lo absurdo seria que este fuera nuestro único momento.

Y cuando diseñamos casos de pruebas?

Sugiero que deben surgir luego de haber corrido cada sesión exploratoria, es decir son la salida del proceso exploratorio y son alimentadas por la inteligencia puesta en el diseño previo de esas sesiones. Nuevamente, utilicemos la inteligencia para comprender que solo debemos escribir casos de pruebas significantes para conseguir dos cosas fundamentales, verificar con caminos normal que las funciones funcionan (valga la redundancia) en su ejecución normal y verificar que las funciones funcionan (valga la redundancia) cuando la ejecución es “fuera de lo normal”.

Why QA guys are allways focused in demonstrations?

 

 

 

 

 

 

 

 

I remember a day that the Scrum Master told me a complain: “why, QA guys are all the time thinking in the demo meeting?”

The question came to me after the “stand up” meeting on Thersday, one day before of the end of the iteration. I also remember the face with a extrange grimace of no aproval.
At the very begining I was surprised, I had not understood the question or why he did that question. Finally, he explained that he was expecting me I offer my help to those who were stuck with the pending testing.

That it makes a lot of sense. I replicated. But remember that in my case, for the product I tested no other responsible will show our results and it’s not so easy to gather all the items to go straight to the relevant things during the demo. Nobody wants that a mistake happen because lack of concepts or wrong dataset in the acceptance testing.
You know, a bad presentation is a kind of failure in the worst moment.

So, what I learned from this very very important coment from my Scrum Master is:

  1. it’s true, QA guy are allways focused in demonstrations and at least for me, this is the main reason, other team involved should discusse face-to-face with the QA guy about the Expected results.
  2. a real QA guy it’s more than just a tester who accomplish with test cases execution. He/she is a professional on strategical thinking and his/her goal is more than checking expected results but helping the rest of the team to reach the general goal (big Y) via the particular actions (the xs)
  3. is possible that an iteration fails for lack of testing, but we can not allow our iteration fail due to poor exposure of our work. Everything is in doubt if our show is poorly done, our capacity for coding and testing, but even worse, our ability to understand and manage the problems.
  4. In any case, if we don’t finish the iteration as expected because the not enough time to test, at this moment we have the evidence that the way we estimate should be adjusted in order to get time to test all the user story committed.
  5. all people of the development team should look into the activities of others involved, not just the names of the activities but that they are. Thereby avoid wrong assumptions and expectations

"Gestión del testing" – Próxima reunión de la Comunidad AGILE Córdoba

El testing de software es una actividad que no detiene su crecimiento y sin importar el contexto en el que se desarrollen aplicaciones o sistemas, el testing es uno de los pilares fundamentales para el aseguramiento de calidad.

Sin embargo, aunque muchos aprendieron a hacer testing en distintos niveles, un gran dilema es, cómo en las metodolgías Agiles podemos organizar un proceso de testing sabiendo de los muy cortos plazos del proceso de desarrollo y con muy bajas posibilidades de realmente hacer aseguramiento de calidad.

Muchos proponen la automatización hasta en sus más mínimos detalles, desde el requisito hasta la aceptación, pasando por el código, la integración y quizás el testing funcional.

Personalmente creo que el testing por si mismo, aunque está ligado a la automatización, no necesariamente está ligado al aseguramiento de la calidad y todo caso ambos, testing y calidad están ligados al factor escencial que es la comunicación.

Sin ir más allá quisiera referirme a un artículo anterior en este mismo blog donde expreso lo siguiente:

con respecto a Testing-Agile James Bach nos dice:

“… cuando di con Agile-Testing encontré un punto de vista desde los desarrolladores que descubrieron Agile y pensaron que esto se trataba de automatizarlo todo y eso es lo que hacen. Por lo tanto solo hablan de herramientas y herramientas y mencionan todas las que conocen.
O lo que realmente significa es, hagamos ingeniería utilizando las habilidades para testar rápidamente las cosas realmente importantes, de una forma sistemática y organizada. El nucleo principal de Agile-Testing se llama SKILLS…………………………………….. la automatización es importante, pero no confundamos Testing con herramientas.

Testing no se trata de herramietas, sino de humanos que pueden hacer algo con las herramientas.”

De mi artículo AGILE con ‘a’ y con ‘A’

Próxima reunión: Jueves 2 de septiembre, 18:30 hs.
Sede:  INTI Córdoba, Av. Vélez Sársfield 1561 (frente a Plaza De Las Américas)

Nota Importante:

  • Por razones de seguridad en sede y espacio, inscribirte para participar
  • Debido a la naturaleza de la actividad, rogamos ser puntuales para facilitar la organización y poder participar y aprovechar los juegos en su totalidad.