Commencer ici
Commencer ici
logotype
mars 2020
22 Mar
GENERALBy Anir RADID

1.4 Processus de test fondamental

Nous avions comparé les tests à un Iceburg dont la petite partie visible à la surface de l’eau est l’activité d’exécution. D’autres activités importantes de test sont moins connues mais elles ont un impact direct sur le succès de l’exécution des tests. Le test et comme le développement, la partie la plus connue est le codage mais les autres activités sont importantes pour la réussite de la phase de codage et ces activités interviennent avant et après celui-ci. La planification du projet, l’expression de besoin, la conception de la solution, le codage, l’exécution des tests et le déploiement. Ces activités sont liées entre elles et constitues un processus, et respectent généralement l’ordre séquentiel suivant : Planification des tests et contrôle Analyse et conception des tests Implémentation et exécution des tests Evaluer les critères de sortie et informer Activités de clôture des tests

Nous allons parcourir ces activités une par une pour découvrir ce qu’elles contiennent

L

e processus de test débute par la planification. Le responsable des tests commence par déterminer l’objectif des tests qu’il va piloter, nous avions dit que les objectifs peuvent être de :

  • Trouver des défauts
  • Acquérir de la confiance dans le produit,
  • Acquérir des informations pour prendre une décision
  • Ou prévenir des défauts

Quand l’objectif de test est précisé, une stratégie doit être définie pour atteindre cet objectif et un planning doit organiser dans le temps les actions des activités futures.

Quand cela est fait alors, le responsable des tests a un Plan.

Contrôle des tests

L ’activité de contrôle est la tâche qui consiste de s’assurer que le projet progresse bien selon le plan initial. Grâce à l’activité de contrôle le responsable des tests détecte tout écart entre le déroulement du projet et le Plan initial et agit en conséquence pour ajuster la trajectoire tout au long de l’avancement du projet.
  • La planification est réalisée au début du processus.
  • Le contrôle se déroule tout au long du processus de test.

Analyse et conception des tests

Durant cette phase, les testeurs préparent les tests qu’ils vont exécuter plus tard. Cela permet de construire un patrimoine de test structuré et s’assurer qu’aucun test n’est oublié ou qu’un élément du logiciel est testé deux fois sans raison. Cette phase du processus démarre de l’objectif définie dans la planification, et s’appuie sur le comportement attendu de l’application décrit dans les spécifications ou tout autre documentation pour sélectionner les conditions de test et concevoir les tests correspondants. Par exemple :
  • Pour l’exemple d’une calculatrice.
  • L’objectif peut être de détecter des défauts.
  • Les conditions de test sont : Faire une addition, Faire une soustraction, Faire un multiplication et faire une division
  • Les tests pour la condition de test « Faire une addition » peuvent être :
    • Faire la somme de deux entiers positifs
    • Faire une addition en un entier positif et un entier négatif
    • Faire la somme de deux entiers négatifs
    • Faire la somme de plus de 5 valeurs … etc
Durant l’analyse et la conception des tests, le testeur peut accomplir une ou plusieurs de ces tâches :
  1. Réviser les bases de test : les bases de test sont la documentation de référence sur laquelle se base le testeur pour juger que le comportement qu’il a constaté sur le logiciel et correct ou pas. Une base de test est un document qui décrit le comportement attendu de l’application. Le test est une comparaison entre le comportement attendu de l’application et le comportement réel constaté de l’application, s’il y a un écart entre les deux, le testeur remonte un défaut.
      • Les exigences sont une représentation atomique des spécifications, au lieu de s’appuyer sur un document texte qui peut être sujet à interprétation, les exigences permettent de représenter le comportement attendu spécifié sous forme d’une liste finie mesurable et plus facile à exploiter.
      • Un rapport d’Analyse de risque est un document qui identifie les partie du logiciels les plus critiques, cela peut amener le testeur à tester plus en profondeurs les parties les plus risquées, concevoir plus de tests pour les couvrir ou exécuter en priorité les tests correspondants pour détecter au plus vite des défauts s’il y en a pour pouvoir les corriger rapidement avant de manquer de temps quand le projet s’approchera de la deadline.
      • L’architecture est la conception technique du logiciel.
      • Les interfaces sont les passerelles et des protocoles par lesquelles des composants ou des systèmes communiquent entre eux.
  2. Toutes les exigences ne sont pas forcément testables, quand une exigence dit que le logiciel doit être « joli » ce n’est pas une exigence exploitable, il faut une charte graphique claire, quand une exigence dit que le logiciel doit être « suffisemment rapide », ce n’est pas testable non plus. Il ne faut pas hésiter dans ce cas d’échanger avec le référent fonctionnel qui a rédigé la base de test pour expliciter l’exigence et définir par exemple le délai de réponse souhaité de l’application.
  3. Organiser les conditions de test de façon cohérente permet de structurer les tests conçus et exécuté et générer des résultats claires et une information précise sur la progression des tests  et la qualité du logiciel.
  4. Des tests de haut niveau peuvent être conçu pour faire des tests de bout en bout qui permet de voir rapidement les faiblesses du produit logiciel.
  5. Les tests peuvent être conçus sans préciser les données de tests dont on aura besoin pour les exécuter :
      • Dans l’exemple d’une calculatrice nous avons identifié le test « Faire une addition entre deux entier positifs »
      • Nous avons identifié le besoin en données de test : 2 entiers positifs
      • Mais à ce stade, ces entiers positifs ne sont pas précisés, ça peut petre n’importe quels entiers positifs. Ils seront précisés lors de la phase d’implémentation.
  6. Pour faire des tests on peut avoir besoin d’un environnement spécifique, un système d’exploitation, des bouchons, des applications tierces pour communiquer avec notre produit logiciel ou des outils de comparaison pour vérifier les résultats de nos tests. Tout ces éléments peuvent être prévus dès cette phase pour commencer à les préparer avant la phase d’exécution.
  7. La traçabilité est assurées par des liens entre la base de test comme des exigences et les cas de tests. Ça permet dans la phase de conception de vérifier qu’on a bien conçus des tests pour toutes les exigences. Et dans la phase d’exécution, pour vérifier quels sont les exigences qui sont couvertes par les tests et quels sont le niveau de validation à un instant donné.

Implémentation et exécution des tests

C’est durant cette phase que :

 

  1. les procédures sont écrites pour les tests manuels et que les scripts sont programmés pour les tests automatisés.
  2. Les tests dans l’ordre d’exécution souhaité.
  3. Les données de tests et toutes les informations qui seraient utiles aux tests sont ajoutés aux tests
  4. Le produit logiciel à tester est livré et installé dans l’environnement de test. Et l’exécution commence dès que tout est prêt.

Finaliser, développer et prioriser les cas de test sont les actions de conception qu’on n’a pas pu faire dans la phase précédente et qu’on peut faire maintenant, peut être par manque de temps ou parce que ce qui reste à finaliser dépend de l’environnement d’exécution.

Développer les procédures de test veut dire que les cas de tests qui ont été conçus dans la phase précédente doivent être détaillés et spécifiés dans cette phase en étapes spécifiques et claires que les testeurs exécuteront facilement.

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 :

  1. Action : Allumer la calculatrice => Résultat attendu : la calculatrice est allumée et affiche un 0
  2. Action : Renseigner la valeur 9 => Résultat attendu : La valeur 9 s’affiche sur l’écran
  3. Action : Appuyer sur le bouton « + » => Résultat attendu : La valeur 9 s’affiche toujours sur l’écran
  4. Action : Renseigner la valeur 11  => Résultat attendu : La valeur 11 s’affiche sur l’écran
  5. Action : Appuyer sur le bouton « = » => Résultat attendu : La valeur 20 s’affiche sur l’écran

Créer des suites de tests à partir des procédures de test pour une exécution rentable des tests

Les suites de test permettent de rassembler plusieurs tests et de les exécuter dans un ordre qui a un sens fonctionnel. Cela permet de rendre les tests plus efficaces et en rendant par exemple possible que chaque test prépare les prérequis nécessaires pour exécuter le test suivant.

Vérifier que les environnements de tests ont été mis en place correctement

Vérifier que les différents composants du logiciel ainsi que la base de données ont été bien installés pour commencer l’exécution dans de bonnes conditions.

Vérifier et mettre à jour la traçabilité bi-directionnelle entre les bases de test et les cas de test

Ce sont les liens dont nous avions parlé précédemment entre les exigences et les cas de test, pour structurer les tests et permettre de s’assurer qu’on a pas oublié de concevoir des tests pour une exigences.

Exécuter les procédures de test soit manuellement soit en utilisant des outils d’exécution de tests, en suivant la séquence planifiée

C’est la phase d’exécution concrète des tests en suivant l’ordre prévu soit manuellement en utilisant des logiciels bureautique ou en utilisant un outil spécial de gestion des tests comme HP ALM, SQUASH, TESTLINK, XSTUDIO et autres…

Consigner les résultats de l’exécution des tests et enregistrer les identités et versions des logiciels en test, outils de test et testware

Quand les tests sont exécutés il faut rapporter les résultats en veillant à décrire les conditions dans lesquelles les tests ont été déroulés comme le système d’exploitation MAC, Windows, Android ou IOS pour que le développeur puisse une vision la plus complète possible de l’origine des défauts s’il y en a.

Comparer les résultats actuels et les résultats attendus.

Et vérifier s’il y a un écart, si oui => Anomalie et on crée une fiche pour la décrire au développeur sinon on exécute le test suivant

Signaler les divergences comme des incidents et les analyser de façon à établir leur cause (p.ex. défaut dans le code, dans les données de test, dans la documentation de test, ou méprise dans la manière d’exécuter le test)

Répéter les activités de test en réponse aux actions prises pour chaque divergence. Par exemple, réexécution d’un test qui était préalablement défaillant de façon à valider une correction (test de confirmation), exécution d’un test corrigé et/ou exécution de tests de façon à s’assurer que des défauts n’ont pas été introduits dans des secteurs non modifiés du logiciel ou que le défaut corrigé n’a pas découvert d’autres défauts (test de régression)

Ce dernier points abordes deux types de test qu’il ne faut pas oublier de réaliser :Les tests de confirmation et les tests de régression.

Quand une anomalie est détéctée elle est signalée par le testeur au développeur à l’aide d’une fiche d’anomalie. Le développeur reçoit la fiche et corrige l’anomalie. Une fois corrigée le testeur rafait un test pour vérifier et confirmer que la correction a été bonne. C’est le test de confirmation.

Et ce n’est pas fini, pour corriger l’anomalie, le développeur a du modifier le code de l’application, ce qui peut impacter des endroits de l’application qui fonctionnait bien avant et qui ne fonctionne plus maintenant que c’est modifié. C’est ce que l’on appelle des régréssions. Les testeurs sont amenés à refaire des tests sur des fonctionnalités déjà vérifiés : c’est ce que l’on appelle des tests de régression.

Evaluer les critères de sortie

Evaluer les critères de sortie est l‟activité où l‟exécution des tests est évaluée en fonction des objectifs définis. Ceci devrait être fait pour chacun des niveaux de test.

Evaluer les critères de sortie est ce qui permet de décider d’arrêter les tests ou pas. On arrête les tests quand on a atteints les objectifs initiaux qu’on a défini. Chaque niveau de test a ses propres objectifs. Nous verrons ce que sont les « niveaux de test » dans les sections suivantes.

Comment on réalise cette activité ?

Vérifier les registres de tests en fonction des critères de sortie spécifiés dans la planification des tests

En comparant au cours de l’exécution les résultats de test avec les critères de sortie définis lors de la phase de planification.

Evaluer si des tests supplémentaires sont requis ou si les critères de sortie doivent être changés

Si les critères de sorties ne sont pas encore atteint, alors soit on décide de continuer l’exécution des tests, soit on décide de redéfinir les critères de sortie si on juge qu’il ne correspondent plus à la réalité du projet.

Ecrire un rapport de synthèse des tests pour les parties prenantes

A la fin de l’exécution, le responsable fournit un rapport de synthèse des tests pour rendre compte aux parties prenantes de l’avancement final du projet, de la qualité atteinte et éventuellement des risques restants.

Activités de clôture des tests

Cette activité est une phase de prise de recul ou on rassemble tous ce qui a été produit lors de la campagne qui vient de se terminer pour le réutiliser dans les prochaines campagnes et revenir sur l’expérience acquise pour mieux faire la prochaine fois. En vérifiant que tout ce qui devait être livré par l’équipe de test a été bien livré. En archivant les fiches des anomalies qui ont été rapportés et corrigés. Et quant aux anomalies qui n’ont pas été corrigé et qui sont toujours dans le produit logiciel, on peut transformer ces fiches d’anomalies en demandes d’évolution pour devenir une base de test pour le prochain cycle de développement. Tracer les résultats des tests d’acceptation dans un compte rendu. Et archiver tous les cas de test conçus, les données de test, les outils de comparaisons, les écrans.. etc pour les réutiliser à nouveau. Si une autre équipe prendra en charge les travaux sur la qualité du produit c’est durant cette phase que l’équipe sortante leur fournira tout ce qui a été produit durant les tests. L’équipe peut se réunir pour reparler à tête reposée de ce qui s’est passé durant ce projet pour identifier ce qui s’est bien passé pour le reproduire et les erreurs et les points à améliorer.
Les tests fournissent des informations sur la qualité du produit testé mais pas que, les tests peuvent aussi donner une idée sur l’efficacité du processus de développement. Si beaucoup d’anomalies sont dues à des mauvaises interprétations de la base de test, c’est qu’il y a un problème dans la spécification du comportement attendu ou la communication entre les référents fonctionnels qui écrivent la documentation et les développeurs. Si beaucoup d’anomalies sont des erreurs de codage alors il faut renforcer les tests statiques sur le code et multiplier les tests unitaires par exemple. C’est ainsi qu’une équipe peut améliorer la maturité de ses tests grâce à l’expérience passée et les informations collectées.
READ MORE
22 Mar
ISTQBBy Anir RADID

La psychologie des tests

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.
READ MORE
22 Mar
ISTQBBy Anir RADID

Le code d’éthique des tests

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.
READ MORE