jXmlCoverage

La cobertura ayuda a saber lo que no estamos probando. Nos ayuda poco a saber si estamos probando bien lo que estamos probando.

Hay discusión sobre la utilidad de la mediciones de cobertura. Por ejemplo ver el resumen de una discusión sobre el tema, de donde tomo la idea que lo único seguro sobre la cobertura es que nos indica que partes no hemos probado.

Por mi parte, hice un rant sobre el uso del % de cobertura como métrica, sobre todo por parte de personas que aprendieron el concepto sólo como un subproducto de TDD.

Pero si entendemos las características de la cobertura, puede ser una ayuda importante para la actividad de prueba (sea quien sea que haga esa actividad).

Hay muchos tipos de cobertura. Por ejemplo, podemos comprobar si estamos probando que se cumplan los objetivos de negocio, o los requerimientos, si hemos probado todos los riesgos identificados, todo el código o las entradas y salidas del programa.

La cobertura de código es la más común de las métricas de cobertura, quizás porque es la más fácil de medir. Incluso dentro de las cobertura de código, hay muchas posibles coberturas: de clase, de método, de linea, de instrucción, condicionales, de camino, etc.

En toda métrica de cobertura, se define el universo de los puntos posibles, y luego se mide cuantos de estos puntos están siendo cubiertos por algún caso de prueba.

Por ejemplo, en una cobertura de líneas de código, cada línea es un punto. Si esa linea es ejecutada al correr alguna prueba, se dice que ese punto está cubierto.

Se puede tomar el porcentaje de cobertura como la cantidad de puntos cubiertos sobre la cantidad total de puntos.

Pero como dijimos anteriormente, es más valioso conocer los puntos no cubiertos.

La herramienta

La herramienta que estoy por comentar, jXmlCoverage, mide cobertura basada en los XML utilizados por el Sistema bajo Prueba (en inglés, SUT).

En muchos SUT se utiliza XML, como entrada, salida o configuración. Por ejemplos, los Web Service. En estos SUT, se dispone, o se puede crear, un XSD que corresponda al contrato que daebe cumplir los XML correspondientes.

Nos interesa el grado en que nuestras pruebas ejercitan las diferentes posibilidades de valores en los XML, y sobre todo, saber que valores no estamos probando.

Para esto, debemos definir el universo que queremos medir. Lo que hacemos es, para cada elemento definido en el XSD, decidir las particiones de equivalencia que son interesantes tomar. Por ejemplo, para un entero, podrían ser los enteros positivos, el cero, los negativos y un valor fuera de rango. A esto lo llamamos subdominio. Cada subdominio es un punto sobre el que se medirá cobertura.

Pasada la etapa de definición y configuración del universo de prueba, medimos la cobertura.

Para medir la cobertura se toma el conjunto de los XML usados y se evalúan contra los subdominios, contando cuantas veces un subdominio es utilizado (cubierto) por los casos de prueba.

Como resultado, podemos obtener los subdominios que no fueron cubiertos.

Como en todas las mediciones de cobertura, se debe evitar caer en la tentación de considerar un sub-dominio cubierto como un sub-dominio bien probado.

Libertad vs estándares

Como parte de la Scrum week @ Bs As, unas 15 personas nos encontramos en las oficinas de Southworks para pensar sobre los problemas y soluciones sobre el Escalamiento en Implementaciones de Scrum (Scaling Scrum). La consigna inicial era hacer una actividad guiada por Tobias, pero lamentablemente no pudo venir, y lo re-definimos como un open space.
Comento una de las sesiones (50 min) que hicimos.

Libertad vs Estándares

Pensamos que los estándar pueden un surgir como una imposición desde fuera del equipo, o como un aprendizaje compartido.
La primera elección debería ser que los estándar sean el resultado de compartir experiencias.
En los casos de imposición, la pregunta es quien impone. Eso nos llevó a hablar sobre quien es el dueño de los estándar (ownership).
En el caso del aprendizaje compartido, la pregunta nos llevó a como compartir el conocimiento.

¿Quién crea y mantienen los estándar? (ownership)

Los personas que están realizando las tareas son las mejor posicionadas para definir estándar sobre como hacer esas tareas. Pero solo lo harán si tienen motivación y liderazgo.
Grupos como las PMO y grupos de Arquitectura suelen ser los que hacen los estándar en muchas empresas. Pero tienen el problema que muchas veces fueron formados con personas que tienen experiencia, pero que luego quedan aislados del día a día de los proyectos. Aún así, sería bueno tener en cuenta toda la experiencia (libros, implementaciones) sobre PMO y grupos de Arquitectura.

Responsabilidad: algunos de los estándar requieren el uso de algún recurso compartido, o sincronización entre equipos. Por ejemplo, los repositorios de fuentes y los ambientes de integración continua. Sin un responsable, se produce una degradación que atenta contra la utilidad del estándar. Tiene que haber una clara responsabilidad. Una persona, un grupo de personas o un equipo.

Disciplina: los estándar deben cumplirse (mientras tenga sentido, ver más abajo). Si el estándar es una restricción auto-impuesta, entonces necesitamos auto-disciplina (auto en este caso es primero individual y luego grupal). Sin auto-disciplina, aparecen los mecanismos para imponer disciplina desde afuera (registros, auditorias) que nos llevan a algo inefectivo.

¿Cómo difundimos los estándar?

No profundizamos mucho en esto. Las formas de comunicación que surgieron son: Wiki y reuniones. Con respecto a las reuniones, el consenso es que debe ir uno o dos miembros de cada equipo. No necesariamente la misma persona, y debe ser la persona que sepa del tema a tratar. Por ejemplo, no tiene sentido que el SM vaya a una reunión sobre estándar de arquitectura. Esta reunión sirve tanto para definir como para comunicar. Luego cada asistente comunica los resultados en cada grupo. Los asistentes pueden ser rotativos, para evitar que surja el “rol de arquitecto”.

¿Qué significa tener un estándar?

Una sugerencia: nos pusimos de acuerdo con una forma de hacer las cosas que nos parece apropiada en muchos de los casos que analizamos. Pero la decisión final sobre aplicar o no es del equipo. Esto está muy ligado con la Disciplina que comentamos antes. Si no hay disciplina, va a haber muchas excepciones. No debería pasar que las excepciones sean comunes, ya que esto indicaría que el estándar no es bueno. Las excepciones son una oportunidad para revisar el estándar, pero no necesitamos un estándar que responda todas las preguntas. Sería demasiado complejo.

La representación del conocimiento actual de equipo extendido: es la forma en que comunicamos las decisiones de arquitectura/diseño, organización, etc. Deben evolucionar a medida que el equipo aprende.

Alineado con los objetivos de la empresa: lo que hacen los equipos debe contribuir a lograr los objetivos de la empresa (*). Mientras se desarrollan y revisan los estándar, es bueno tener esto presente, lo que nos ayuda a traducir los objetivos (alto nivel) con nuestras prácticas (bajo nivel).

En el cierre de esta sesión quedó inconclusa una discusión sobre Scrum y Auto-organización. Hasta donde entiendo: lo que hablamos en la sesión, aplica a Scrum o a cualquier Auto-organización. Implícita está la discusión: Scrum incluye toda forma de auto-organización, o auto-organización incluye toda forma de Scrum, o ninguna de estas.

(*) Mientras escribo este resumen, me encuentro tentado a agregar comentarios propios, no dichos durante la sesion (de la que fui moderador, por lo tanto traté de no participar opinando... mucho). En el caso de los objetivos de la empresa, por ejemplo, sería importante que los principios de Scrum (y/o auto-organización :D) se apliquen a todos los niveles. Por lo tanto, esos objetivos deberían ser un emergente de todos las personas de la organización.