Savoir quand il faut arrêter de tester avant les mises en production

On ne le répètera jamais assez mais il faut tester, tester et encore tester l’ensemble de vos développements et applicatifs avant leur mise en production. Mais, dans une grande majorité des projets, les tests sont souvent les premiers évincés quand le temps imparti est écoulé ou quand le budget est épuisé. Il va de soi que l’on court aux dysfonctionnements si l’on ne considère que deux paramètres pour déterminer l’arrêt des tests. Mais alors, quand doit-on arrêter les tests ???

Remontées d’informations suffisantes.

Les tests devraient s’arrêter quand suffisamment d’informations ont été fournies pour prendre des décisions sur :

• Les mises en production : les fonctionnalités critiques ne remontent aucun dysfonctionnement sur la ou les couvertures déterminées et avec les jeux de données correspondant. – Avoir couvert la majorité des cas d’utilisation
  
• Le prochain développement : la fonctionnalité est fiable et les équipes de développement peuvent passer à l’intégration suivante. – Eviter les “faire et défaire”
• La livraison aux clients : il n’est plus temps de tester après la mise à disposition du logiciel aux clients. – Assumer le livrable

Un niveau de qualité acceptable.

Avant toute campagne de test il convient de définir les exigences de l’applicatif.  Il faut faire une description claire et exhaustive du niveau de développement nécessaire pour être accepté par le prescripteur et utilisable convenablement par les utilisateurs. Cela passe par :

• Un arbitrage : quel est le pourcentage acceptable d’anomalies présent en MEP ? Trop d’anomalie et cela aura un impact sur l’utilisation du logiciel. Et vouloir tout tester pour supprimer 100% des anomalies a un coût dont il faut tenir compte. Quel est le risque et qu’est-ce qu’il coûte (R.O.I.)?
• Une couverture exhaustive : il est presque impossible de tester un développement sur tous ses environnements de vie. Cela prendrait un temps considérable et un coût disproportionné au regard du bénéfice utilisateur. Il convient de déterminer la couverture de test adéquate pour balayer 90 à 95% des cas utilisateurs (sauf besoin de correspondre à une norme ou une utilisation très spécifique).
• • Pour exemple si vous devez vérifier que le module de recherche est fonctionnel, il ne faut pas chercher à tester toutes les combinaisons possibles de votre fonction, comme trop souvent on nous le demande : toutes les catégories puis toutes les sous catégories puis toutes les tailles, ….

Ces deux paramètres reviennent à fixer des critères de sortie et c’est lorsque les tests effectués attesteront que le développement répond à ces critères qu’il sera temps d’arrêter les tests.

Il se peut que des dysfonctionnements aient été identifiés lors des tests sans pour autant que le développement ne réponde aux critères de sortie. Dans ce cas, les dysfonctionnements sont mineurs et n’altèrent pas le bon fonctionnement du logiciel et ces derniers seront corrigés lors de la prochaine mise en production.

Pour conclure.

En résumé, il faut arrêter de tester lorsque les exigences (*) sont validées. Nous entendons par là que si et seulement si le développement répond aux exigences fixées et que les critères de sorties sont atteints il convient d’arrêter les tests. Ces derniers ne doivent JAMAIS être arrêtés pour manque de temps ou de budget : c’est un signal d’alarme ! Si vous êtes régulièrement face à cette situation c’est que les projets ne sont pas suffisamment encadrés dès le départ et que les budgets sont sous évalués. On arrête de tester quand les remontées d’informations sont suffisantes et que le développement répond à un niveau de qualité définie par les exigences.

(*) Une exigence qui spécifie une fonction qu’un composant ou système doit remplir.