Complexité et effort de test

Dans le post précédent, je posais la question ‘Qu’est ce qu’une grosse application ?’ et je proposais deux tables de mesures, basées sur le nombre de lignes de codes (LOC) ou le nombre d’objets afin de catégoriser les applications en ‘simple’, ‘moyenne’, ‘grosse’ et ‘très grosse’.

Evidemment, comme je m’y attendais, la discussion sur les forums traitant d’analyse de code ou de métriques software s’est immédiatement orientée sur les points de fonction, sur la définition de ce qu’est une application (unité de code ou unité organisationnelle) ou sur le type de mesure utilisée par chacun afin d’estimer la taille d’une application. Les nombres que j’ai avancés n’ont pas prêté à discussion.

Cette semaine encore, un autre ‘quizz’ du même type : ‘Qu’est ce qu’une application complexe ?’ et surtout ‘Est-il possible de prévoir l’effort de test en fonction de la complexité d’une application ?’.

Nous savons tous que la Complexité Cyclomatique de McCabe (CC) est la principale métrique utilisée pour mesurer la complexité, et qu’elle est communément admise par tous, sans contestation ou polémique comme ce peut être le cas de la LOC pour la mesure de la taille. Rappelons le principe de cette métrique : mesurer le nombre de chemins indépendants dans l’algorithme du code source.

Prenons un exemple concret. Soit la règle de gestion suivante : ‘si commande > 50, ristourne = 1%’. En pseudo-code, cela se traduira de la manière suivante :

IF commande > 50
  THEN ristourne = 1%
ELSE
  Ristourne = 0%
ENDIF

L’algorithme pour cette règle de gestion comportera donc deux chemins distincts correspondants aux deux parties de la condition : la commande donne droit à une ristourne ou non. Ces deux chemins équivalent à deux points de Complexité Cyclomatique.

Compliquons maintenant nous cette règle, ou plutôt, ajoutons de nouvelles règles : ‘si commande > 500, ristourne = 10%’, ‘si commande > 300, ristourne = 5%’, ‘si commande > 200, ristourne = 2%’.

Le pseudo-code correspondant devient dés lors :

 IF commande > 500
   THEN ristourne = 10%
   ELSEIF commande > 300
     THEN ristourne = 5%
     ELSEIF commande > 200
       THEN ristourne = 2%
       ELSEIF commande > 50
         THEN ristourne = 1%
         ELSE Ristourne = 0%
       ENDIF
     ENDIF
   ENDIF
 ENDIF

Remarquez que j’ai (volontairement) choisi la manière la plus complexe et la moins correcte de ‘pesudo-coder’ ces différentes règles, avec plusieurs IF imbriqués. Mais ce n’est pas l’objet de ce post.

Dans cet exemple, nous avons quatre conditions plus un cas dans lequel aucune condition ne sera remplie. Ou pour le dire autrement, nous avons ajouté trois règles supplémentaires au cas précédent et notre Complexité Cyclomatique sera donc plus élevée.
Tous les outils d’analyse de code ne calculent pas la Complexité Cyclomatique de la même manière, donc le résultat pourra varier (de plus ou moins un) selon celui que vous utiliserez, mais là encore, ce n’est pas l’objet de ce post. Disons simplement que nous avons là une CC égale à 5, correspondant à cina chemins distincts dans l’algorithme, à cinq valeurs distinctes pour les objets ‘ristourne’ ou ‘commande’.

Diriez-vous que, dans une phase de QA, il faut tester ces différentes valeurs ?

Si votre réponse est positive, alors cela signifie que la Complexité Cyclomatique constitue un bon indicateur du nombre de cas de tests. Evidemment, si vous avez une application avec 10 000 points de CC, cela ne veut pas dire qu’il vous faille tester 10 000 cas différents, ni même que vous aurez une application ne présentant aucun défaut si vous testez tous les cas possibles. Mais au moins, vous pouvez estimer plus précisément l’effort de test, selon que la CC sera de 2 000 points, 20 000 ou 100 000 points.

La question de notre ‘quizz’ précédent était : ‘Qu’est-ce qu’une grosse application ?’. Cette semaine, la question sera double :

  • Qu’est ce qu’une application complexe ?
  • Quel niveau de QA préconiser en fonction de quel niveau de complexité ?

Voici le tableau que je vous propose :

Complexité de l’application en points de CC

Complexité

Basse

Moyenne

Elevée

Très élevée

Points de CC

6 000

16 000

50 000

> 50 000

Application peu complexe

Avec moins de 6 000 ‘chemins’ dans l’application, des tests unitaires au niveau de l’équipe de projet devraient suffire pour vérifier la plupart des cas. Cela suppose bien évidemment une bonne connaissance fonctionnelle de l’application.

Généralement, les spécifications sont très peu formalisées, les développeurs sont en contact direct avec les utilisateurs ou leur représentant jouant un rôle de MOA (Maîtrise d’ouvrage, interface entre les utilisateurs et l’équipe projet).

Application moyennement complexe

Entre 6 000 et 16 000 points de CC, les tests unitaires sont nécessaires, comme précédemment et deviennent suffisamment nombreux pour que l’équipe de projet se dote d’un outillage permettant d’automatiser ceux-ci. La taille du code et surtout le nombre de cas de test croît de manière importante.

La connaissance des spécifications fonctionnelles est répartie sur divers membres de l’équipe de projet : on commence à voir apparaître une spécialisation des développeurs sur certaines parties du code ou différents modules fonctionnels. Une étape spécifique d’intégration est nécessaire, afin de vérifier que l’assemblage des différents composants en chaînes de traitements fonctionnels correspond aux demandes métier.

Application complexe

Les seuils peuvent varier entre 16 000 et 20 000 points de CC pour la limite basse, et 50 000 et 60 000 points de CC pour la limite haute, notamment en fonction des technologies ou de l’architecture de l’application ou de la fréquence d’évolution du code. Il n’existe évidemment pas de limite précise, mais plus on se rapproche d’un seuil et plus la stratégie de test correspondante devient applicable.

Au-delà de 16 000 points de CC (et surtout au-delà de 20 000), l’application est complexe. La taille de l’équipe projet peut devenir importante, notamment si les corrections ou évolutions sont fréquentes.

Outre les tests unitaires et d’intégration au niveau de l’équipe de projet, il devient indispensable d’effectuer une phase spécifique de tests fonctionnels avec une équipe de QA dédiée. La formalisation des cas de tests sur la base d’un document de spécifications fonctionnelles est de plus en plus indispensable lorsque la complexité se rapproche de la limite haute.

Application très complexe

Au-delà de 50 000 ou 60 000 points, l’application est très complexe. Il est nécessaire de s’équiper d’outils pour automatiser les tests unitaires, d’intégration ou de QA. Les spécifications fonctionnelles doivent impérativement être rédigées et figées avant la phase de développement.

J’ai rencontré peu d’applications au-delà des 100 000 points de CC, même dans le monde mainframe. Il existe peu de situations ‘métier’ avec des règles de gestion aussi complexes. On les rencontre généralement dans les domaines administratifs où la réglementation évolue très fréquemment : par exemple les traitements de calcul des allocations familiales, avec des règles nouvelles qui s’ajoutent à des règles anciennes rarement supprimées.

La plupart du temps, de tels monstres supposent une dérive du management qui a laissé l’application devenir de plus en plus complexe. On les rencontre dans des secteurs correspondant à des marchés qui sont passés rapidement d’une croissance très forte, justifiant des évolutions applicatives fréquentes et sans aucun souci de la dette technique, à une phase de stabilisation voire de déclin des parts de marché entraînant une réduction des budgets informatiques et rendant impossible tout refactoring pour diminuer cette dette technique. Les intérêts de celle-ci resteront élevés encore longtemps.

Et vous, pensez-vous que la mesure de la complexité soit un indicateur de l’effort de QA ?

 

Ce article est également disponible en Leer este articulo en castellano et Read that post in english.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *