22 Mar
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.
