martes, 29 de octubre de 2013

La difícil tarea de responder a la pregunta “¿cómo vamos con el testing?”

 
p,A todos los que, con distintos roles, hemos participado alguna vez de un proyecto de software nos ha tocado lidiar con esta pregunta. Ya sea haciéndosela a alguien o recibiéndola para responderla.

Es importante entender qué es lo que en realidad nos están preguntando, es decir, qué es lo que el interlocutor quiere saber. En mi experiencia personal resulta muy útil desmenuzar este tipo de preguntas amplias en preguntas más concretas y si es necesario repetir este procedimiento hasta tener preguntas puntuales sobre aspectos concisos y medibles.

La experiencia de haber tenido que responder esta pregunta a diferentes tipos de interlocutores, me llevaron a descubrir también que otro aspecto de importancia para responderla es el conocimiento de quién la hace para saber qué tipo de respuesta está esperando recibir. No es lo mismo que la persona guste de porcentajes y métricas a que simplemente quiera saber si podemos avanzar con el despliegue planificado para el próximo ambiente o no.

De la conjunción de ambas cosas, es decir, de nuestra capacidad para hacer de una pregunta vaga un conjunto de preguntas concretas y del entendimiento que tengamos sobre las expectativas del interlocutor, es que podremos brindar una “buena” respuesta, es decir, una respuesta que satisfaga a quién la hizo y le sirva para tomar la decisión que deba tomar. Una respuesta que agregue valor a la actividad de Testing y no un simple “bien” o “aun no terminé”.

Comencemos desmenuzando la pregunta. En mi experiencia esta pregunta tiene 2 grandes aristas: avance y calidad.
 

Avance

Por avance nos referimos a poder indicar cuánto hemos progresado desde el momento que comenzamos con la tarea de testing al momento en que hay que responder a la pregunta. Esta métrica uno la quiere ir revisando mientras se está ejecutando el ciclo de pruebas.

Por supuesto la estrategia que se haya definido para guiar al testing del ciclo en curso es la que determinará cómo medir el avance. Por ejemplo, si se define como estrategia aplicar testing en profundidad en cierto ciclo pero solo un test de cobertura (a lo ancho) en otro, entonces no mediremos igual el avance al responder a la misma pregunta en uno u otro ciclo.

El avance puede, a su vez, medirse teniendo en cuenta diferentes dimensiones. Algunas de las que me han resultado útiles o, mejor dicho, le han resultado útiles a quien me hizo la pregunta fueron:

  • Cubrimiento: “De lo que hay que testear ¿qué ya se testeó y cuánto falta aún por testear?
  • Esfuerzo: “¿cuánto esfuerzo (horas/hombre) ya se ha insumido en relación al esfuerzo total estimado?”
  • Calendario: “¿cuánto tiempo calendario ya ha transcurrido respecto de la duración total planificada para el ciclo de pruebas?”

No siempre es necesario medir todas estas dimensiones, eso dependerá en última instancia de lo que necesite nuestro interlocutor y del costo/beneficio de obtener cada métrica. Sin embargo, cuantas más dimensiones midamos, más herramientas tendremos para responder a preguntas más complejas como ser: “teniendo en cuenta el tiempo que nos queda del ciclo de pruebas, la capacidad de testing de la que disponemos y el esfuerzo estimado en completar el cubrimiento restante, se llegará a completar el testing?”, “Si no se llegase a completar todo, ¿se llegarán a completar al menos los casos prioritarios?”, “¿Necesitaremos aumentar la capacidad de testing?”, “¿Debemos evaluar reducir alcance, o ampliar el ciclo de pruebas?”.

De estas dimensiones, la más importante y que a su vez es la más difícil de medir es la de cubrimiento.
 

Cubrimiento


El cubrimiento de las pruebas realizadas se puede obtener midiendo diferentes elementos. Por ejemplo, supongamos un ciclo de pruebas donde el alcance es testear 20 casos de uso:

  • al Manager del Proyecto probablemente le interese saber el cubrimiento en relación a esos 20 casos de uso, como ser: “estamos en un 60% de cubrimiento dado que ya testeamos (con un grado aceptable de profundidad) 12 de los 20 casos de uso“.
  • mientras que al Líder de Testing o al Líder del Proyecto, adicionalmente a esa métrica, le interese saber con qué grado de profunidad, es decir, si para esos 12 casos de uso ya testeadas, se ejecutaron todos los casos de prueba, o solo los imprescindibles, o qué porcentaje, o si todos los aspectos, o cuáles aspectos (seguramente compartidos entre los diferentes casos de uso) aun no fueron testeados.

Es decir, en este ejemplo, tenemos 2 elementos medibles: caso de uso y caso de prueba.

Entonces, lo primero que necesitamos para poder medir cubrimiento es una lista de lo que nos solicitan testear, que llamaremos de forma genérica: los requerimientos de prueba planificados. Los requerimientos de prueba pueden ser casos de negocio, casos de uso, funcionalidades, pedidos de cambio, correcciones a bugs de iteraciones anteriores, etc, es decir, todo aquello que debe ser testeado en el ciclo de pruebas en curso.

Lo segundo que necesitamos es, para cada requerimiento de prueba, los casos de prueba que posteriormente se ejecutarán. Los casos a su vez, pueden armarse y agruparse de muchísimas formas diferentes dependiendo del tipo de artefacto recibido, de la naturaleza del proyecto, del tipo de aplicación, de la habilidad del equipo de testing en diseñar los casos, del conocimiento de la arquitectura, etc.

Como vemos estas listas pueden armarse de variadas maneras y con distintos niveles de detalle dependiendo principalmente de la metodología de trabajo establecida, del tipo de proyecto y de la habilidad del equipo de testing.

A su vez, dependiendo de la cantidad de requerimientos de prueba y del objetivo del ciclo, en algunos casos resulta útil indicar para cada elemento (requerimientos de prueba, casos de prueba o ambos) cuáles son aquellos imprescindibles de testear y cuales son menos prioritarios.

Estas listas no siempre son simples de mantener para el equipo de testing. Esto puede darse porque varía el alcance de la iteración en curso (se agregan o quitan requerimientos de prueba) o porque los requerimientos existentes no están del todo estables, por ejemplo cuando el cliente es “indeciso” o “cambiante en sus definiciones”, y se reciben muchos cambios sobre el contenido de los mismos (lo cual impacta en la lista de casos de prueba).

Es importante notar que cambios en estas lista, nos van a “deformar” la métrica que vayamos obteniendo en el tiempo (ya que ante el mismo dividendo, por ejemplo: requerimientos ejecutados, nos cambia el divisor: cantidad total de requerimientos), es por ello que, si se está en un proyecto con dichas características, es recomendable no abrirla demasiado para que pueda recibir la menor cantidad de modificaciones ante las cambiantes situaciones descriptas. Es decir, agrupar la cantidad de elementos por lo que consideremos más probable que no cambie, y medir en relación a ese agrupador. También es muy importante que el proyecto cuente con un proceso definido e instrumentado de gestión y comunicación de los cambios para mantener informado de los mismos al equipo de testing para que éste pueda actualizar estas listas con la información correcta de lo que entra en el alcance y/o de lo que se desea construir y, por ende, testear.

Lo tercero que necesitamos para poder medir cubrimiento es registrar el resultado obtenido, tanto en caso de éxito (se obtuvo el resultado esperado) como de falla (no se obtuvo el resultado esperado). Muchas personas creen que no es necesario registrar que una prueba dio un resultado correcto (pasó); pero si no registramos aquello que ya probamos y está funcionando bien, no podremos dar una métrica de cubrimiento, ¡esta es la razón! ¡Esto es muy importante!
 

Calidad

“De lo que ya se probó, ¿cómo está funcionando? ¿Funciona correctamente? ¿Funciona más o menos? ¿Funciona horrible?”

Esta pregunta a su vez puede responderse mirando 2 aspectos:

  • La métrica (casos pasaron / casos ejecutados) de cada requerimiento de prueba. Esta métrica nos sirve para medir lo que funciona “bien” de lo que funciona “mal”.



  • Analizando los issues identificados. Hay muchos análisis que se pueden hacer. Los dos más importantes para evaluar calidad son:
    •  “¿Se identificaron issues/bugs que impiden operar una funcionalidad (stoppers)?” “¿La mayoría de los issues identificados de qué criticidad son? Este análisis de acuerdo a la criticidad de los issues/bugs identificados nos permite dimensionar qué tan grave es lo que funciona “mal”.
    •  “¿Cuántos issues/bugs fueron causados por especificaciones incompletas? ¿cuántos por errores de programación?” Este análisis llamado “de causa raíz” nos permite identificar acciones tendientes a mejorar el desempeño del equipo y la calidad del proyecto en las siguientes iteraciones con el objetivo de evitar repetir situaciones o comportamientos que den origen a issues y mejorar la calidad del producto generado.

 

Conclusiones

Como vimos, la clave para poder dar respuesta a la pregunta de “¿cómo vamos con el testing?” es la registración. Distintos detalles en la registración permitirán responder con mayor o menor detalle la pregunta, lo que está claro es que sin registración del alcance del testing, de las pruebas realizadas, de los resultados obtenidos, de los issues identificados y del estado de cada uno de ellos, no se puede dar respuesta a esta difícil pregunta.

Responder a esta pregunta también sirve al equipo de testing para identificar y mitigar riesgos, como ser: “no vamos a llegar a testear cierta funcionalidad” o “se están identificando muchos issues críticos con tal funcionalidad”, etc.

En conclusión, cuando nuestra respuesta incluye los aspectos mencionados, ésta es muy apreciada por nuestro interlocutor ya que le sirve para tener una visión completa del estado del testing y le provee de la información necesaria para poder tomar decisiones inteligentemente respaldada por argumentos y datos concretos.

En Baufest solemos aplicar estas buenas practicas en nuestra Practica de Testing.

Gracias a Cecilia Briozzo por el artículo.