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? »
1.1.1 Contexte des systèmes logiciels (K1)
Qui d’entre nous n’a pas eu l’expérience d’un logiciel qui ne fonctionne pas comme prévu :
- Une application sur un smartphone
- Un achat sur une boutique en ligne
- Un écran bleu sur votre ordinateur
- …etc
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).
1.1.2 Origine des défauts logiciels (K2)
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.
Les erreurs :
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.
Les défauts :
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.
Les défaillances :
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).
Ce qu’il faut retenir absolument est que :
- Une erreur est humaine.
- Un défaut est lié à un produit non exécuté
- Une défaillance est liée à un produit logiciel exécuté
- Une erreur humaine peut générer un défaut dans un produit qui n’est pas en exécution comme le code d’une application ou une documentation.
- Un défaut peut générer une défaillance quand l’application est exécutée.
1.1.3 Rôle des tests dans le développement, la maintenance et l’opération des logiciels (K2)
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.
1.1.4 Tests et qualité (K2)
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.
1.1.5 Combien de test est suffisant? (K2)
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 des paramètres tels que :
- Le niveau de qualité
- Le niveau de risque, c’est-à-dire la possibilité d’un problème se produise.
- Et le respect des contraintes du projet : Coûts et Délais
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 :
- Donner le feu vert pour mettre en production une application : c’est à dire rendre accessible l’application à l’utilisateur final.
- Lancer une nouvelle campagne de correction pour améliorer la qualité.
- Continuer les tests (pour gagner en visibilité)
- Ou arrêter les tests pour cause d’une qualité médiocre 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.
Laisser un commentaire