Tester permet de détecter des défauts et c’est la tâche du testeur,
Déboguer (De-buguer) permet comme son nom l’indique de défaire des bugs, càd de corriger des défauts.
Le débogage est une tâche réalisée par le développeur.
Quand un testeur trouve un incident, il le communique au développeur qui réalise un debugging pour mettre le doigt sur le défaut dans le code qui a causé la défaillance afin de le corriger.
L’histoire ne s’arrête pas là.
Le testeur doit reprendre la main après la correction, en réalisant le test à nouveau sur son environnement de test pour confirmer que le défaut a bien été corrigé, et non seulement sur le poste du développeur. Ces re-test sont appelés : les tests de confirmation.
La différence entre « tests dynamiques » et « tests statiques » est que :
Les tests dynamiques sont réalisés sur un logiciel en cours d’exécution
alors que les tests statiques sont effectués sur du code source non exécuté et sur de la documentation.
Qu’ils soient statiques ou dynamiques les tests fournissent des informations sur le produit logiciel. Des informations qui pourrait servir pour améliorer la qualité du produit ou améliorer l’efficacité du processus de sa fabrication.
On avait dit précédemment que ce ne sont pas les tests qui améliorent directement la qualité du logiciel mais bien les activités de développement qui le corrigent.
Faire des tests c’est comme faire un diagnostic médical, le diagnostic donne des informations sur l’état de santé d’une personne.
Pour cela, il est possible d’utiliser des approches statiques comme des radios et des scanners
ou des approches dynamiques en mesurant les capacités physiques du patient en analysant ses performances en mouvement c’est à dire en lui faisant faire des exercices spécifiques et vérifier qu’il y arrive bien ou pas.
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).
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).
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 jusqu’à 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 sont des comportements inattendus parce qu’ils sont confrontés à un environnement particulier (des pics de températures, des radiations, magnétismes, champs électriques ou la Pollution).
Ce qu’il faut retenir absolument est que :
Une erreur humaine peut générer un défaut dans un produit statique (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.
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.
Ces principes sont à garder à l’esprit du professionnel du test lors de l’exercice de son activité.
Ils sont sensés être vrais quelques soit le contexte du projet ou le niveau d’expertise du professionnel.
Le professionnel du test doit suffisamment les assimiler pour les appliquer efficacement et être en capacité d’en transmettre l’essence aux clients ainsi qu’aux acteurs-clés des projets.
Principe 1 : Les tests montrent la présence des défauts
L
es tests ne sont pas une assurance d’absence de défauts.
Quelques soit l’importance du nombre de défauts qu’on a trouvé sur l’application, et le temps qu’on a passé dans les tests sans en trouver de nouveaux, ce n’est pas une preuve d’absence de défauts. Cela ne prouve que le risque de défaillance a diminué, sans jamais pour autant prétendre que le risque est nulle ou que le logiciel contient 0% de défauts : Ce qui est impossible à affirmer.
Principe 2 : Les tests exhaustifs n’existent pas.
S
i un client demande de tester toute l’application, c’est qu’il n’a pas compris ce que sont les tests.
Il est impossible de tout tester.
Imaginons qu’on veuille tester une page d’inscription qui contient un formulaire de plus de 10 champs on peut facilement aller vers des milliards de test, ce qu’aucun projet ne peut se permettre à cause du temps et des coûts d’une telle entreprise.
Cela reste vrai qu’on opte pour des tests manuels ou automatiques.
C’est la raison pour laquelle il faut sélectionner les tests importants qui ont un impact sur la qualité de l’application et les séparer des tests qui ont peu de valeur ajoutée.
Principe 3 : Tester tôt
Ce principe encourage à tester le plus tôt possible dans le cycle projet, parce que plus tôt un défaut est détecté, plus tôt il sera corrigé et moins il impactera les activités suivantes du cycle projet.
Ce principe est important et sera revu plus en détail dans les chapitres suivants.
Principe 4 : Regroupement des défauts
Il existe une loi universelle qu’on appelle la loi Pareto qui dit que 80% des problèmes sont issues de 20% des causes.
Cette loi est aussi vrai dans les tests logiciels où 80% des défauts de qualité proviennent des 20% des modules les plus complexes, les plus instables ou les plus utilisés.
Pour tester efficacement un logiciel il faut toujours commencer par trouver les modules les plus critiques de ce logiciel.
Principe 5 : Le paradoxe du pesticide
Ce paradoxe nous explique que parfois utiliser un pesticide pour éliminer un bug (insecte en anglais) peut avoir l’effet contraire et faire proliférer ces bugs.
La même chose risque de se produire dans les tests logiciels quand on lance les même tests sur les mêmes modules en utilisant les mêmes techniques, on trouvera de moins en moins de défauts avec le temps.
Pour tester efficacement dans le temps, il faut varier les angles d’attaque en mettant à jour les tests existants et en ajoutant des tests nouveaux.
Principe 6 : Tester selon le contexte
Tester un site de réservations de voyages et vacances est différents de la démarche de test d’un équipement informatique pour les hôpitaux : Un défaut sur ce dernier peut impacter des vies d’êtres humains contrairement au site de voyage.
Des gens ne seraient pas d’accord, et diront que l’annulation d’un voyage de rêve peut être aussi grave mais bon.. je pense que la majorité des gens conviendraient que les équipements des hôpitaux sont plus critiques.
Les tests sur les systèmes les plus critiques doivent être les plus rigoureux. Et des choix stratégiques doivent être faits : Niveaux de tests, Tests manuels ou tests automatisés, types de tests, techniques de test, niveau de traçabilité…etc
Celui qui a conçu les tests n’est pas forcément celui qui va les exécuter. Chaque test est détaillé en étapes qui décrivent clairement l’action à faire sur l’application et le résultat attendu.
Prenons encore l’exemple de la calculatrice.
Nous avions identifié les cas de tests dans la phase d’analyse et de conception.
Dans la phase d’implémentation et d’exécution, ces cas de tests seront implémentés et étapes de test.
Par exemple le test : Faire une addition entre 2 entiers positifs
Sera détaillé en des étapes claires comme :
Action : Allumer la calculatrice => Résultat attendu : la calculatrice est allumée et affiche un 0
Action : Renseigner la valeur 9 => Résultat attendu : La valeur 9 s’affiche sur l’écran
Action : Appuyer sur le bouton « + » => Résultat attendu : La valeur 9 s’affiche toujours sur l’écran
Action : Renseigner la valeur 11 => Résultat attendu : La valeur 11 s’affiche sur l’écran
Action : Appuyer sur le bouton « = » => Résultat attendu : La valeur 20 s’affiche sur l’écran
Principe 7 : L’illusion d’absence d’erreur
Est-ce que la création d’un logiciel qui fonctionne bien dans le sens ou tous les bugs trouvés ont été corrigés – va satisfaire à coup sûr les clients ?
Ce n’est pas sûr. Un logiciel peut fonctionner correctement sans incident mais sans satisfaire les attentes de l’utilisateur, par exemple le logiciel peut ne pas être intuitif ergonomiquement et donc pas facile d’utilisation, la charte graphique n’est pas au gout des utilisateurs, ou fonctionne bien sur un navigateur X mais pas top sur un autre navigateur Y pourtant le préféré des utilisateurs.
On peut comparer une équipe qui travaille sur un produit logiciel à une équipe de foot : Les développeurs et les testeurs deviennent des attaquants et des défenseurs.
Dans les deux domaines « Se spécialiser » c’est se donner les moyens d’être pointu dans son métier, savoir faire confiance aux autres et être capable de travailler en équipe
La tournure d’esprit à utiliser pendant les tests et les revues est différente de celle utilisée lors de l’analyse ou du développement. Avec la mentalité appropriée, des développeurs sont capables de tester leur propre code, mais affecter cette responsabilité à des testeurs permet typiquement de focaliser l’effort et de fournir des bénéfices additionnels tels qu’une perspective indépendante par des ressources de test entraînées et professionnelles. Les tests indépendants peuvent être effectués à n’importe quel niveau des tests
Pourquoi a-t ’on besoin de testeurs ? est ce que les développeurs ne sont ils pas capables de tester leur code ?
Bien sûr que les développeurs peuvent de trouver des défauts dans leur code, comme un attaquant d’une équipe de foot est tout à fait capable de défendre les buts.
Mais est ce qu’il le ferait mieux qu’un défenseur entraîné aux techniques de défense ?
Est-ce que l’attaquant fera bien son travail qui est de marquer des buts s’il est obligé à chaque fois de revenir en défense ?
Séparer les tâches de développement et de tests permet aux membres des équipes projet d’être pointus sur leurs spécialités respectives.
Les tests indépendants càd réalisés par d’autres que les développeurs qui ont fabriqué le produit peuvent être effectué à n’importe quel niveau de test. Les niveaux de tests seront vus dans les sections suivantes.
Un certain degré d’indépendance (évitant le parti-pris de l’auteur) est souvent plus efficace pour détecter des défauts et des défaillances. L’indépendance n’est pas cependant un remplacement de la familiarité, et les développeurs peuvent efficacement trouver beaucoup d’erreurs dans leur propre code.
Quand on a codé une application ou rédigé un document, on a souvent du mal à se relire ou à prendre du recul sur notre travail. C’est la raison pour laquelle on a besoin d’une autre personne qui a une perspective différente pour y jeter un coup. C’est la notion d’indépendance. C’est une indépendance et un recul par rapport au produit fabriqué.
Cette indépendance vient compléter et ne remplace pas la familiarité qu’a l’auteur ou le développeur qui connait bien son œuvre et peut voir les détails de sa structure. Le travail du testeur n’exonère pas le développeur de sa responsabilité quant à la qualité du produit qu’il fabrique.
Plusieurs niveaux d’indépendance peuvent être définis, comme les niveaux suivants présentés du plus faible au plus élevé
o Tests conçus par la (les) personne(s) qui a (ont) écrit le logiciel à tester (niveau faible d’indépendance).
o Tests conçus par une (des) autre(s) personne(s) (p.ex. de l’équipe de développement).
o Tests conçus par une (des) personne(s) d’un groupe différent au sein de la même organisation (p.ex. équipe de test indépendante) ou par des spécialistes de test (p.ex. spécialistes en tests de performance ou utilisabilité)
o Tests conçus par une (des) personne(s) d’une organisation ou société différente (p.ex. sous-traitance ou certification par un organisme externe)
Quand les tests sont réalisés par les personnes mêmes qui ont fabriqué le produit, là on peut dire que l’indépendance est faible et même inexistante.
Il est possible d’instaurer un niveau plus élevé d’indépendance même si on n’a pas de testeurs dans l’équipe. Cela peut se faire quand chaque développeur teste les fonctionnalités codées par un collègue. Il apporte alors un nouveau regard sur le code source.
Le niveau d’indépendance au-dessus est quand les tests sont par une équipe composée de testeurs fonctionnels ou des spécialistes de tests non fonctionnels comme les tests de performance et les tests d’utilisabilité qui vérifient la facilité d’utilisation de l’application.
Le niveau d’indépendance le plus élevé cité est celui d’une équipe qui n’est pas seulement indépendante des activités de développement mais aussi de la société elle-même, le fait que cette équipe aie travaillé pour d’autres société qui ont peut-être d’autres méthodes de travail lui permet faire bénéficier le projet de ses expériences et d’apporter un recul supplémentaire pour juger la qualité du produit qu’elle teste.
L ’identification de défaillances pendant les tests peut être perçue comme une critique contre le produit et contre son(ses) auteur(s). Les tests sont, de ce fait, souvent vus comme une activité destructrice, même si c‟est très constructif dans la gestion des risques du produit. Rechercher des défaillances dans un système requiert de la curiosité, du pessimisme professionnel, un oeil critique, une attention au détail, une bonne communication avec ses pairs en développement, et de l’expérience sur laquelle baser l’estimation d’erreurs.
Les activités de tests ne construisent pas le produit logiciel, ce sont les activités de développement qui le font, c’est pour cela qu’ils sont vus comme une activité destructrice. Alors qu’en vérité quelle est la valeur d’un système de supervision de la respiration des nouveau-nés dans une couveuse s’il est développé mais pas testé, est ce qu’il est utilisable ?
Les tests est ce qui donne une valeur, une confiance, un moyen de gérer les risques du produit.
Pour pouvoir trouver des défaillances dans un système il faut quelqu’un de :
Curieux
Quelqu’un qui a un pessimisme professionnel, ce qui veut dire qui est capable de penser à ce qui peut mal se passer pour faire en sorte que ça ne se passe pas.
Quelqu’un qui a un œil critique, qui peut voir ce qui est bon et ce qui est moins bon dans un produit même les détails.
Et aussi il faut que le testeur ai un relationnel et une capacité de communication qui mettent à l’aise ses collègues développeurs
Un profil de test expérimenté peut être capable d’estimer le pourcentage d’erreurs moyen qui peuvent être trouvé selon la typologie du projet sur lequel il travaille.
Si des erreurs, défauts ou défaillances sont communiqués de manière constructive, l’animosité entre les testeurs et les analystes, concepteurs et développeurs peut être évitée. Ceci s’applique autant aux revues qu’aux tests.
Les testeurs et le responsable des tests ont besoin de bonnes compétences relationnelles pour communiquer des informations factuelles sur les défauts, les progrès et les risques, de manière constructive.
Un projet logiciel n’est pas une sorte de processus et de formalismes qui fonctionnent tout seuls, c’est surtout un groupe de personnes qui interagissent pour construire quelque chose ensemble.
Les interactions entre ses personnes sont très importantes ou même l’aspect le plus important du projet, encore plus que la compétence.
Beaucoup de projets sont bloqué ou échouent à cause de problèmes d’interactions humaines. Un professionnel se doit de prendre en compte sérieusement l’aspect relationnel de son activité.
Si un testeur qui a trouvé un défaut dans l’application s’adresse au développeur en lui disant : « Tu as fait une erreur sur l’application ».
Cette formulation en « Tu as fait ou tu n’as pas fait » a des contours de critique et de reproche qui risque fortement de déplaire au développeur et le pousser à se mettre à la défensive.
Un testeur se doit d’être neutre et communiquer sur des faits et non des reproches ou critiques. Quand il trouve un défaut il dit que l’Application contient un défaut x et non Le développeur a commis une erreur Y. La différence entre les deux formulations est de taille.
Pour l’auteur du logiciel ou du document, une information sur les défauts peut permettre d’améliorer leur savoir-faire. Les défauts trouvés et corrigés pendant tests permettront de gagner du temps et de l’argent plus tard, et de réduire les risques.
Des problèmes de communication peuvent survenir, particulièrement si les testeurs sont vus uniquement comme messagers porteurs de mauvaises nouvelles concernant des défauts.
Quand le testeur qui a du tact et qui communique ses trouvailles respectueusement, chaque défaut qu’il détecte est perçue comme une occasion d’améliorer le savoir-faire des développeurs, d’augmenter la qualité et d’éviter les pertes d’argent qui se seraient déroulés si les défauts s’étaient révélés en production.
Pour ne pas être vu comme des messagers de mauvais augure, En tant que testeur vous devez rapporter ce qui marche bien comme ce qui marche moins bien.
Pour améliorer les relations entre les testeurs et les développeurs, l’ISTQB a 4 propositions :
Rappeler aux testeurs et aux développeurs qu’on est sur le même bateau, on est une seule équipe et on a tous un même objectif.
Pour n’offusquer personne le testeur doit communiquer sur les résultats de ses tests de façon neutre sans jugement, et factuelle. Le système se comporte ainsi alors qu’il a été spécifié qu’il se comporte comme ça. Cette neutralité doit être observés lors de la communication orale comme écrite, par exemple sur les rapports d’incident que le testeur rédige quand il trouve des défauts.
Le testeur doit avoir de l’empathie càd savoir se mettre à la place des autres et comprendre ce qu’ils ressentent et cela dépasse l’aspect neutre et factuel du point précédent. Il ne doit pas se bloquer sur qui a raison et qui a tort.
La dernière proposition d’amélioration et un classique de la communication, quand un testeur communique une information à son interlocuteur il doit demander un feedback pour s’assurer que la personne a bien compris l’information telle que le testeur l’a voulue et ainsi prévenir les mauvaises interprétations qui sont fréquentes.
Pour les entreprises, recruter des testeurs certifiés ISTQB est une garantie de connaissance et de compétence mais aussi d’éthique professionnelle, vu qu’ils peuvent mettre à sa disposition des données confidentielles pour faire des tests.
Il est peu probable que des questions soient posées sur ce chapitre.
Et si elles sont posées les réponses pourraient sembler évidentes.
L’ISTQB a définit un code éthique simple pour les professionnels du test à l’images des standards de l’IEEE pour les ingénieurs.
Ce code éthique est un petit ensemble de règles simples pour s’assurer que les informations sensibles ne soient pas divulguées ou mal utilisées par les professionnels du test.
Ces règles sont exposées de la plus générale à la plus personnelle.
PUBLIC : Les testeurs servent l’intérêt public. C’est évident.
Client et Employeur : Les testeurs servent l’intérêt de leur clients et employeurs tant que ces intérêts sont en phase avec l’intérêt public.
PRODUIT : Les testeurs ISTQB doivent s’assurer que ce qu’ils produisent corresponde aux normes professionnelles
JUGEMENT : Un testeur est toujours responsable de ses prises de positions professionnelles qui ne doivent pas être altérés par des relations de copinage ou de conflit.
GESTION : Les chefs de projet doivent respecter eux même et promouvoir dans leur sphère d’influence une approche morale pour faire les tests.
PROFESSION : La profession a une réputation qu’il convient à chaque testeur à entretenir par sa manière d’exercer.
COLLEGUES : Le travail en équipe est un prérequis important dans les tests, pour se faire le testeur doit susciter la confiance de ses collègues testeurs et de ses partenaires développeurs.
PERSONNELLEMENT : Le test est en constante évolution et le testeur doit donc se former en permanence et continuer à exercer sa profession de façon morale.
