Menu
Cet article fait partie d’une série de publications qui expliquent section par section et paragraphe par paragraphe le contenu du syllabus de préparation à la certification ISTQB Niveau Fondation « Testeur Certifié ».
Le premier chapitre est un des chapitres les plus importants dans l’examen de certification, il regroupe 7 questions des 40 qui seront posées.
Chaque article couvrira en général une section du syllabus.
Cet article explique la section 1 du chapitre « Fondamentaux des tests » : « Pourquoi les tests sont-ils nécessaires? »
Qui d’entre nous n’a pas eu l’expérience d’un logiciel qui ne fonctionne pas comme prévu :
Les comportements inattendus des logiciels peuvent avoir des conséquences allant de pertes financières ou d’image (comme un bug sur un module de paiement d’un site e-commerce), jusqu’à des pertes humaines (comme les équipements de santé et des moyens de transports).
Plusieurs termes sont utilisés pour désigner un comportement inattendu d’une application : Bug, Erreur, Défaut, anomalies, défaillance…
Parfois ces termes sont utilisés de façon totalement confuse.
L’ISTQB Fondation commence par le vocabulaire pour démarrer sur de bonnes bases.
Une erreur est commise par une « Personne » : un être humain
Faire des erreurs est une des caractéristiques de l’homme qui est un être faillible.
Les hommes sont ingénieux, ils sont capables de fabriquer des choses fabuleuses mais ils font aussi des erreurs, des méprises et cela ne réduit en rien leur ingéniosité.
Les méprises sont un synonyme acceptable aux erreurs dans l’ISTQB Fondation.
Un défaut est lié à un produit comme le code d’une application ou le contenu d’un document.
Une erreur humaine produit un défaut sur un produit logiciel ou un document (produit textuel).
Un développeur peut introduire un défaut dans un produit logiciel, un concepteur peut introduire un défaut dans un document de spécifications.
Le terme défaut a des synonymes tels que : Bug et Anomalie.
Quand un défaut qui réside dans le code d’un logiciel est exécuté cela peut générer une défaillance.
Une défaillance est liée à un produit en cours d’exécution : S’il n’y a pas d’exécution, il n’y a pas de défaillance.
Une défaillance peut être un affichage incorrect sur l’écran, comme il peut être un crash total d’une application.
La relation de causalité entre défaut et défaillance n’est pas automatique :
Un défaut peut générer une défaillance ou pas : un défaut dans un code qui n’est jamais parcouru lors de l’exécution ne génère pas de défaillance.
Toutes les défaillances ne sont pas forcément dues à un défaut : parfois des systèmes informatiques ont des comportements inattendus parce qu’ils sont confrontés à un environnement particulier (des pics de températures, des radiations, magnétismes, champs électriques ou Pollution).
Les tests permettent de détecter des défauts dans le logiciel avant de l’utiliser dans un environnement opérationnel en production.
Cela permet d’éviter que ces défauts génèrent des défaillances dans l’environnement de production.
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 respect des normes de 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 s’il y a peu ou pas de défauts trouvés avec le temps.
L’assurance qualité est tout le processus dont font partie les tests pour gé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 des tests.
Il n’y a pas de réponde toute faite à cette question.
C’est aux décideurs de trancher sur la base des paramètres tels que :
Le risque est une notion qui va être abordée en détail dans les chapitres suivants.
Ce qu’il faut savoir à ce stade est que le risque qualité est la possibilité qu’un problème logiciel se produise.
Avant l’exécution des 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 budgets 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 testée de l’application et le niveau du risque restant.
Des critères de sortie basés sur la qualité et le risque peuvent être définis avant de commencer l’exécution.
Les décisions qui peuvent être prises grâce aux informations produites par les tests sont par exemple :
N’hésitez pas à poser des questions dans la zone de commentaires en bas de la page pour approfondir le sujet ou échanger sur le contenu de l’article.
