Tests et qualité logicielle : construire un processus fiable

Si la qualité des logiciels inclut un objectif tel que « livrer ce que nous avons promis dans les délais et dans les limites du budget » (ce qui devrait être le cas), les tests sont alors essentiels pour atteindre cet objectif.

Il existe au moins trois critères pour mesurer la qualité d’un logiciel :

• Processus de livraison fiable : Pouvons-nous livrer des applications quand nous avons dit que nous le ferions ?
• Faibles coûts d’entretien : Notre organisation peut-elle vivre avec ces applications ?
• Aptitude à l’objectif: Les applications font-elles leur travail ?

Décider si une application ou une amélioration d’une application est « prête pour la publication » implique généralement d’évaluer le moment où deux métriques sont remplies :

• Fonctionnalité implémentée : Lorsque toutes les fonctionnalités ont été implémentées (ou une approximation raisonnablement proche de « toutes »)
• Nombre de bogues : Lorsque le nombre de bogues connus est nul (ou que le risque associé aux bogues restants est faible)

Nous avons besoin des deux mesures car, malgré nos meilleures intentions, l’ajout ou la modification de fonctionnalités – l’écriture de code – génère des bogues (bien qu’il y ait mécanismes d’adaptation pour ralentir leur croissance). Comme les tchotchkes dans le salon de votre tante Edna, les bugs augmentent inévitablement au cours de la vie du projet.

C’est pourquoi nous avons des tests. Tout d’abord, bien sûr, les tests sont la façon dont nous découvrons les bogues. Mais c’est aussi la façon dont nous déterminons si ces bogues ont été corrigés – lorsque nous effectuons à nouveau le test (un test de régression) et obtenons le « bon » résultat, nous déclarons que le bogue a été corrigé et supprimons le bogue du nombre de bogues.

Nos calendriers et nos estimations de coûts sont plongés dans le chaos lorsque nous avons des augmentations inattendues du temps nécessaire pour corriger un bogue (ce qui se traduit par une tendance à réduire les bogues qui s’aplatit au lieu de se rapprocher de zéro) ou lorsque nous avons une forte augmentation du nombre de bogues.

Prédire la livraison

Au moins trois niveaux de test sont impliqués dans la détermination du nombre de bogues et du délai de correction : Tests unitaires par les développeurs pour trouver les bogues au fur et à mesure qu’ils sont créés ; des tests exploratoires et d’autres types de tests par QA pour trouver des bogues après que le code a été archivé ; tests de régression pour signaler à la fois si un bogue a été corrigé et si le code existant est resté sans bogue.

Les tests ne sont pas, bien sûr, une solution complète, mais c’est ce que nous avons. Les tests, par exemple, ne trouvent pas tous les bogues (bien que les tests fournissent les entrées pour estimer le nombre de bogues inconnus). Et le coût/temps pour corriger un bogue n’est pas une constante.

Le temps nécessaire pour corriger un bogue est directement lié au moment où le bogue est trouvé : le coût de la correction d’un bogue trouvé longtemps après qu’il a été écrit est de exponentiellement plus élevé que le coût de la correction d’un bogue trouvé peu de temps après qu’il soit écrit. La principale raison en est que notre logiciel a tendance à s’appuyer sur l’interaction avec d’autres logiciels. Lorsqu’un bogue est détecté tardivement dans le développement, nous devons non seulement corriger le bogue mais, potentiellement, « ajuster » tous les logiciels qui interagissent avec le code corrigé.

Le problème est aggravé parce que nous ne sommes pas très bons pour prédire l’étendue d’un changement dans notre logiciel. Nous le constatons le plus souvent dans les modifications apportées après la sortie de nos applications : nous apportons ce qui semble être une modification bénigne à un système de production, puis commençons à recevoir des appels de personnes dont nous n’avons jamais entendu parler auparavant, se plaignant que leur application a cessé de fonctionner. L’effet équivalent dans le développement se produit lorsque nous corrigeons un bogue : nous générons souvent un tas de nouveaux bogues.

Et cela ne tient pas compte de l’impact que l’augmentation du nombre de bogues et les délais de correction plus longs ont sur notre autre métrique : la fourniture de fonctionnalités. Les développeurs impliqués dans la correction des bogues ne fournissent pas de fonctionnalités. Lorsque la tendance à corriger les bogues s’aplatit, vous constaterez généralement que la tendance à fournir des fonctionnalités a également diminué.

L’augmentation du nombre de bogues, l’allongement du temps de correction et les ralentissements dans la livraison des fonctionnalités réduisent tous la probabilité que nous livrions à temps. Notre processus devient moins fiable.

Résoudre le problème : testez tôt, testez souvent

Heureusement, la solution est bien connue : appliquer un méthodologie de test logiciel qui commence par tests unitaires et se poursuit par des tests d’intégration, divers tests spécialisés (par exemple, essais de charge) et se termine par des tests d’acceptation par les utilisateurs et des tests de fumée.

Les tests de régression sont essentiels ici. Tout d’abord, la régression signale lorsqu’un bogue est corrigé. Deuxièmement, des tests de régression fréquents et complets identifient rapidement les bogues nouvellement générés et, par conséquent, réduisent le temps nécessaire pour corriger ces bogues.

Les tests automatisés contribuent à atteindre les objectifs des tests de régression. Essais automatisés :

• N’immobilisez pas nos ressources les plus limitées et les plus coûteuses (développeurs et testeurs)
• Peut être exécuté à notre convenance (soit sur un calendrier, soit sur un événement – code pertinent en cours d’enregistrement, par exemple)
• Peut signaler automatiquement le nombre de bogues et le temps de correction.

De nombreux autres types de tests peuvent être automatisés (on peut affirmer que les seuls tests de charge utiles sont les tests automatisés). Les tests exploratoires ne peuvent pas être automatisés, mais lorsqu’ils détectent un bogue, ils peuvent conduire à un test de régression automatisé qui suivra la progression du bogue vers sa résolution.

Ce serait bien si cela signifiait que nous ne trouverions pas de bogues longtemps après leur écriture. La réalité est que nous trouverons encore des bogues tardivement et que ces bogues coûteront toujours plus cher à corriger que ceux que nous avons trouvés peu de temps après leur écriture. Mais le nombre de bugs tardifs sera fortement réduit de sorte que leur impact sur les coûts/échéanciers sera… eh bien, sinon nul, du moins « gérable ».

En effet, vous obtenez un processus plus fiable en empêchant tante Edna d’acheter ses tchotchkes au début du processus, au lieu d’attendre qu’ils se présentent à l’improviste dans le salon (où il est beaucoup plus difficile de s’en débarrasser). Vous serez plus heureux, votre direction et vos utilisateurs seront tous les deux plus heureux et puisque, dans cette analogie, tante Edna représente les bogues de notre logiciel… eh bien, nous ne l’avons jamais vraiment aimée de toute façon.