Pourquoi faut-il tester?

Les tests ne corrigent pas les défauts, mais permettent de les détecter méthodiquement pour que les développeurs puissent les appréhender et les corriger.

C’est par ce processus indirect que les tests participent à l’amélioration de la qualité des logiciels.

Les tests ne servent pas seulement à prévenir les comportements non désirés des applications, mais aussi à veiller à leurs conformités vis-à-vis de certaines exigences légales ou contractuelles ou le respects des normes correspondants à certaines industries spécifiques.

Les tests permettent de mesurer la qualité d’un logiciel, et ne permettent pas de directement l’améliorer. Ce sont les développeurs qui corrigent les anomalies et impactent ainsi directement la qualité du logiciel.

Les tests peuvent augmenter le niveau de confiance dans un logiciel si peu ou pas de défauts sont trouvés.

L’assurance qualité est tout le processus dont font partie les tests pour générer la qualité d’une application.

Cela va des activités de revue de la documentation jusqu’aux formations, en passant pas les standards de développement et les tests.

Combien de test est suffisant ?

Il n’y a pas de réponde toute faite à cette question.

C’est aux décideurs de trancher sur la base de paramètres tels que :

Le niveau de risque, c’est-à-dire la possibilité qu’un problème se produise.
Ou le respect des contraintes du projet.

Le risque est une notion qui va être abordée en détail dans d’autres articles de testacademy.fr

Ce qu’il faut savoir à ce stade est que le risque qualité est la possibilité qu’un problème logiciel se produise.

Avant les tests, le risque est à son maximum.

Au fur et à mesure que les tests progressent, le risque sur la qualité du logiciel diminue avec le temps.

Dans la réalité des projets logiciels, on dispose rarement de temps et de budget suffisants.

C’est la raison pour laquelle il faut faire des arbitrages pour décider du moment ou arrêter les tests.

Les tests permettent de prendre cette décision en toute connaissance de cause, en sachant le niveau de qualité sur la partie couverte par les tests de l’application et le niveau du risque résiduel (c’est à dire restant) dans la partie non couverte par les tests.

Des critères de sortie basés sur la qualité et le risque peuvent être définis avant même de commencer l’exécution.

Les décideurs comme le chef de projet, le directeur de projet, le client, les sponsors… attendent avec un grand intérêts les résultats des tests pour décider des actions futures à faire.

Les décisions qui peuvent être prises à la lumière des informations résultant des tests peuvent être par exemple :

Donner le feu vert pour mettre en production une application ( Décision GO MEP) : càd rendre accessible l’application à l’utilisateur final.
Lancer une nouvelle campagne de correction pour améliorer la qualité : la qualité actuelle étant non encore suffisante pour la mise en production.
Continuer les tests (pour gagner en visibilité)
Arrêter les tests pour cause d’une qualité médiocre (moyens insuffisants ou démarche défaillante).