Complejidad y esfuerzo de QA

En el post anterior, yo pregunté “¿Qué es una aplicación de gran tamaño? ‘Y propusé clasificar aplicaciones en tamaño ‘simple’, ‘medio’, ‘grande’ y ‘muy grande’ basándose en diferentes medidas de número de líneas de código (LOC) o de número de objetos .

Esta semana, otro ‘quizz’ del mismo tipo ‘¿Qué es una aplicación compleja? ¿Es posible evaluar el esfuerzo de pruebas en función de la complejidad de la aplicación?’

Todos sabemos que la Complejidad Ciclomática de McCabe (CC) es el principal indicador para medir la complejidad, aceptado por todos, sin controversia como puede ser el caso de la métrica LOC para la medición de tamaño. El objetivo de este indicador: medir el número de caminos independientes en el código fuente del algoritmo.

Un ejemplo concreto, la siguiente regla: “si factura > 50, rebaja = 1%”. En pseudo-código, esto se traducirá de la siguiente manera:

IF Factura > 50
  THEN Rebaja = 1%
ELSE
  Rebaja = 0%
ENDIF

El algoritmo para esta regla tiene dos caminos distintos por las dos partes de la condición: la factura da derecho a un descuento o no. Estos dos caminos son equivalentes a dos puntos de Complejidad Ciclomática.

Ahora vamos a complicar esta regla, o más bien, agregar nuevas reglas: “si la factura > 500, 10% de descuento; si la factura > 300, 5% de descuento; si la factura >200, 2% de descuento.

El pseudo-código para los dados se convierte entonces en:

 IF Factura > 500
   THEN Rebaja = 10%
   ELSEIF Factura > 300
     THEN Rebaja = 5%
     ELSEIF Factura > 200
       THEN Rebaja = 2%
       ELSEIF Factura > 50
         THEN Rebaja = 1%
         ELSE Rebaja = 0%
       ENDIF
     ENDIF
   ENDIF
 ENDIF

He eligido (voluntariamente) la más compleja y menos correcta manera de escribir el pseudo-código para estas reglas, con varios IF añadidos. Pero no es el tema de este post.

En este ejemplo, tenemos cuatro condiciones y un caso en el que no se cumple cualquier condición. O para decirlo de otra manera, hemos añadido tres reglas adicionales al caso anterior y nuestra complejidad ciclomática es ahora más alta.

Todas las herramientas de análisis de código no calculan la Complejidad Ciclomática de la misma manera, por lo que el resultado puede variar (más o menos uno) pero de nuevo, esto no es el objeto de este post. Digamos que tenemos una CC igual a 5, lo que corresponde a cinco caminos distintos en el algoritmo, cinco valores diferentes para los objetos ‘Factura’ y ‘Rebaja’.

¿Dirías tu que se deben probar estos valores diferentes en una fase de QA?

Si tu respuesta es positiva, entonces significa que la Complejidad Ciclomática es un buen indicador del número de casos de prueba. Claro, si tienes una aplicación con 10 000 puntos de CC, esto no significa que tienes que probar 10 000 casos diferentes, o incluso que la aplicación no tendra defectos si se prueba todos los casos posibles. Pero por lo menos se puede calcular con mayor precisión el esfuerzo de QA, no el mismo cuando la CC será de 2 000 puntos, 20 000 o 100 000 puntos.

El ‘quiz’ de esta semana tiene doble pregunta:

  • ¿Qué es una aplicación compleja?
  • ¿Qué nivel de QA para qué nivel de complejidad?

Os propongo los siguientes valores:

Complejidad de la aplicación en puntos de CC

Complejidad

Baja

Media

Alta

Muy alta

Puntos de CC

6 000

16 000

50 000

> 50 000

Application poca compleja

Con menos de 6 000 ‘caminos’ en la aplicación, las pruebas unitarias por parte del equipo de proyecto deben ser suficientes para controlar la mayoría de los casos. Este presupone un buen conocimiento funcional de la aplicación.

Por lo general, las especificaciones no son muy formalizadas porque los desarrolladores están en contacto directo con los usuarios o sus representantes.

Aplicación moderadamente compleja

Entre 6 000 y 16 000 puntos de CC, las pruebas unitarias se requieren, como antes, y son bastante numerosas para que el equipo del proyecto las automatiza con una herramienta. El tamaño del código y el número de casos de pruebas aumentan significativamente.

El conocimiento de las especificaciones funcionales se reparte entre varios miembros del equipo del proyecto: empezamos a ver los desarrolladores especializados con algún código o diferentes módulos funcionales. Una etapa específica de pruebas de integración es necesaria para verificar que el conjunto de las diferentes cadenas de componentes corresponde a las exigencias funcionales de los usuarios.

Aplicación compleja

Los umbrales pueden variar entre 16 000 y 20 000 puntos de CC para el límite inferior y 50 000 y 60 000 puntos de CC para el límite superior, según las tecnologías o la arquitectura de la aplicación o la frecuencia de evolución del código. Obviamente no hay un límite específico, pero cuanto más nos acercamos a un umbral, más la estrategia de QA correspondiente será aplicable.

Más allá de 16 000 puntos (sobre todo más allá de 20 000), la aplicación es compleja. El tamaño del equipo de proyecto puede llegar a ser importante cuando las correcciones o los cambios son frecuentes.

Además de las pruebas unitarias y de integración en el equipo de proyecto, es esencial llevar a cabo una fase específica de pruebas con un equipo dedicado de QA. La formalización de los casos de pruebas basandose en un documento de especificaciones funcionales es cada vez más necesaria cuando la complejidad se acerca al límite superior.

Aplicación muy compleja

Más allá de 50 000 o 60 000 puntos, la aplicación es muy compleja. Se necesitan herramientas para automatizar las pruebas unitarias, de integración o de control de calidad. Las especificaciones funcionales deben estar siempre formalizadas antes de la fase de desarrollo.

Conocí a pocas aplicaciones más allá de 100 000 puntos de CC, incluso en el mundo mainframe. Se encuentran generalmente en áreas con cambios reglamentarios frecuentes, por ejemplo tratamientos de cálculo de subsidio familiar, con siempre nuevas reglas sin que se quitan las reglas anteriores.

La mayoría de las veces, estos monstruos son la consecuencia de las derivas del management que ha permitido que la aplicación se vuelva cada vez más compleja. Se encuentran en mercados que pasaron de un crecimiento rápido y muy fuerte, lo que justifica cambios frecuentes en la aplicación sin ninguna preocupación por la deuda técnica, a un período de estabilización o de disminución de cuotas de mercado y en una reducción de los presupuestos de TI, y imposible reducir esta deuda técnica por que no hay más dinero para una refactorización. Los intereses de esta deuda permanecen elevados para siempre.

¿Que opinas tu? ¿Crees que la medida de la complejidad es un buen indicador del esfuerzo de QA?

 

Esta entrada está también disponible en Lire cet article en français y Read that post in english.

Deja un comentario

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