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.

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.

Introduction aux exigences dans les tests

Cette vidéo est une introduction à la notion d’exigence dans le processus de test. La définition du périmètre grâce aux exigences est un moyen efficace pour cadrer le projet et réduire les ambiguïtés des spécifications. La définition du périmètre fonctionnel passe par des ateliers où les exigences sont collectées et explicitées. L’inclusion des parties prenantes du projet dans ces ateliers assure la cohérence et la pertinence des activités de test. Si cette vidéo vous a plu ou pas n’hésitez pas à le dire en commentaire. Je serai ravi d’en échanger avec vous.

Ce que doit savoir un testeur lors de sa première mission

Quand un testeur fraîchement diplômé – qu’on appellera ici Anas – est recruté par un société, il a besoin de connaître des concepts de bases pour intégrer une équipe et travailler sur un Projet. Voici deux notions (équipe et projet) fondamentales dans le fonctionnement des entreprises. En saisir le sens et la mécanique va considérablement aider Anas à réussir. Qu’est ce qu’une équipe? et pourquoi travailler en équipe? Qu’est ce que c’est qu’un projet? et pourquoi est ce l’outil principal des entreprises pour atteindre leurs objectifs?

Equipe vs Projet

Une équipe est un groupe de personnes, mais pas que. Il y a un point important qui distingue une équipe d’un groupe ordinaire d’individus, et c’est que les membres d’une équipe travaillent sur une tâche commune. Le testeur travaille avec les autres intervenants de conception et de développement pour atteindre un objectif commun qui est de fabriquer (ou maintenir) un produit logiciel. Quand Anas cherche le sens de Projet dans un dictionnaire, il trouve que le mot vient du latin et veut dire littéralement « jeter quelque chose vers l’avant ». Un projet est la fédération d’un ensemble d’actions pour atteindre un objectif dans le futur. Le projet apporte à un groupe de personne l’objectif commun dont ils ont besoin pour devenir une équipe. Travailler ensemble pour atteindre cet objectif est ce qui fait d’un groupe de personnes une Equipe. Pourquoi les entreprises veulent autant travailler en équipe ? parce que c’est ce qui permet de faire de grandes choses. Un proverbe africain le dit si bien :
Tout seul, on va plus vite. Ensemble, on va plus loin.
Et ça! les entreprises l’ont bien compris. A ce stade, Anas sait avec qui il va travailler et pour atteindre quel objectif. Ce qu’il ne sait pas encore par contre c’est « Comment travailler ». Pour cela, il sera utile de connaitre les modèles autour desquels sont structurés les projets.

Modèles de Projets

T ravailler en équipe nécessite des efforts d’organisation et de coordination qui ne sont souvent pas requis en labeur solitaire. Voici des questions qui apparaissent dès qu’on ne travaille plus seul ? Quelle est ma position dans l’équipe ? Quels sont mes interlocuteurs directs ? Fait-il faire un écrit? A quel niveau documenter? Comment communiquer? Avec qui? Quand dois-je commencer à tester ?une fois l’action du collègue finalisée ou travailler en parallèle? Tester au début, au fur et à mesure, ou à la fin du projet? Un projet informatique est complexe par nature, et la multiplicité des intervenants de l’équipe – malgré son utilité – ne le rend pas moins délicat. Anas n’interviendra pas de la même façon selon qu’il soit sur un projet en cascade, en V ou Itératif(Agile ou pas). D’où la nécessité de connaitre chacun de ces types de projets.

Le cycle en Cascade

Le Le cycle en cascade est le modèle le plus ancien des trois. Il a été importé de l’industrie du bâtiment en 1970. Dans ce type de projet, la règle de base est qu’une activité ne peut débuter avant que la précédente ne soit achevée : « on ne peut pas construire la toiture avant les fondations ».
Pour décrire le fonctionnement de ce type de projet, considérons une équipe réduite comme exemple. Le référent fonctionnel on l’appelera Anne et notre développeur sera Mickael. Anas est toujours notre Testeur. Anne qui représente les utilisateurs décrira ce que le nouvelle application doit faire : « Je veux que le système fonctionne sur mobile » « Le système doit être accessible seulement par tel groupe de personnes » « Le système doit permettre de créer, modifier et dupliquer des comptes client » … Mickael qui est un développeur expérimenté ne commencera pas la phase de conception tant que Anne n’a pas fini son expression de besoins, comme l’exige le cadre du cycle en cascade. Une fois l’expression de besoins finalisée, Mickael commence à concevoir une solution logicielle pour satisfaire les exigences contenues dans la documentation d’expression de besoins. Quand la solution imaginée par Mickael est approuvée par Anne, il pourra lancer le codage dans la phase de développement. Ce n’est qu’à ce moment là juste avant la mise en production que Anas pourra intervenir pour faire ses tests. Si Anas trouve un défaut de code lors de ses tests, ce n’est pas très problématique car Mickael devra seulement modifier le code pour le corriger et relivrer pour que Anas valide sa correction. Mais si Anas trouve un défaut de conception ou pire un incident dû à un défaut dans l’expression des besoins, Anne est sollicitée pour modifier la documentation d’expression de besoin, qui a un impact sur la solution conçue, ce qui va amener Mickael à modifier la conception, et qui dit conception changée dit code à changer avant de livrer à Anas pour tester à nouveau. Cet effet Domino a un impact direct sur les délais de mise en production, les anomalies ne peuvent être détectées par le testeur que tardivement lors de l’avant dernière phase, ce qui laisse peu de marge de manœuvre pour les efforts de correction. Voir la vidéo faite sur le principe général des tests : « Tester tôt » Ce modèle existe depuis 48 ans, d’autres ont été créés par la suite pour palier à ses imperfections mais il reste une référence sur laquelle se sont basés les modèles ultérieurs : comme le cycle en V.

Le cycle en V

Comment lire ce graphique ?
Je vous présente Sarah notre nouvelle great-testeuse pour notre projet en mode cycle en V. C’est toujours Anne qui débute par exprimer ses exigences (besoin) mais en même temps Sarah commence déjà à concevoir des tests de haut niveau (tests d’acceptation) pour valider plus tard la satisfaction du besoin par le produit (une fois réalisé). Ensuite, Mickael fait une conception fonctionnelle et technique de la solution à construire, des tests correspondants sont aussi conçus par Anas dès lors pour pouvoir vérifier plus tard la conformité du produit aux spécifications techniques (tests d’intégration) et aux spécifications fonctionnelle (tests système).. Mickael développe la solution et teste lui même son code (les tests unitaires). Une fois livré dans l’environnement approprié, Anas exécute les tests qu’il a préparé lors des phases de conception. Quand les tests Système de Anas sont terminés, la solution est livrée dans l’environnement de Sarah qui valide que le logiciel satisfait bien les besoins décrit par Anne au départ (Tests d’acceptation). C’est donc pendant les phases de la partie gauche du graphique que les tests sont préparés, puis ils sont exécuté lors des phases de droite. Ce modèle apporte une amélioration significative au cycle en cascade, puisqu’il introduit les tests dès le début du projet, ce qui permet – en théorie – de détecter rapidement les défauts les plus coûteux (besoin + conception) en ayant un maximum de temps pour les corriger. Ce modèle implique aussi le développeur en le faisant participer dans les activités de test plus techniques. Ce modèle a l’air génial en théorie mais en pratique il est compliqué à implémenter, et il est difficile de trouver une entreprise qui l’applique de manière stricte. la principale difficulté qu’il présente est sa rigidité. Malgré qu’il introduise le test plus en amont par rapport au cycle en cascade, on est toujours obligés de tout spécifier avant de tout coder puis tout tester. Alors quand Anas ou Sarah détectent des défauts de conception, une stricte application du modèle pousse à retravailler les spécifications fonctionnelles et techniques, à les re-implémenter dans le code et déclencher tous les niveaux de test, ce qui implique des délais importants. La seconde faiblesse de ce modèle est son rapport aux spécifications. Pour fonctionner correctement ce modèle a besoin que les spécifications une fois conçus soient figés car tout ce qui suit est basé dessus. Mais dans la pratique il s’avère que créer des spécifications bonnes et complètes avant de commencer la réalisation est un objectif inatteignable. En réalité, c’est pendant l’implémentation de la solution que l’on rencontre des cas d’usage imprévus, des problèmes conceptuels et des contraintes techniques difficilement envisageables pendant les phases de conception. Il y a donc toujours un delta entre ce qui est spécifié et ce qui développé. Ce qui installe des frustrations, incompréhensions et conflictualité entre les intervenants du projet, entre ceux qui défendent les spécifications et ceux qui défendent le produit. Anas qui par définition vérifie la conformité du produit développé aux spécifications, se trouvera au milieu de ces tractations entre les acteurs de la conception et des acteurs de la réalisation. Anas pourrait a de grandes chances de travailler dans des conditions tendus à cause de ces écarts qui sont souvent légitimes et ne sont la faute de personne sinon du modèle lui même. Le cycle en V améliore significativement l’efficacité des développements et des tests par rapport au cycle en cascade mais son application réelle a fait surgir ses faiblesses et principalement sa rigidité face aux changements dans les spécifications. Peu de projets adoptant ce modèle réussissent à réaliser un produit qui satisfait son utilisateur sans déborder sur le budget ou dépasser le délai. De nouvelles organisations sont apparues plus tard pour améliorer l’efficacité des projets informatiques.

Cycle itératif

Les cycles itératifs apportent une approche plus pragmatique et plus souple. On n’essaie plus de Tout construire d’une traite, mais de fabriquer le produit en plusieurs fois. c’est ce qu’on appelle les itérations.
Ca commence toujours par Anne qui décrit les fonctionnalités qu’elle veut voir dans le produit. Mickael et Anas au lieu de prendre tel quel l’ensemble des besoins exprimés par Anne, sélectionnent ceux qui seront réalisés lors de la première itération. Une fois ce premier lot de fonctionnalités développé et testé, le cycle permet lors d’une étape d’évaluation, de faire le point et prendre du recul sur ce qui reste à réaliser mais sous la lumière de l’expérience gagnée lors de la précédente l’itération. C’est un processus d’apprentissage et d’adaptation continu. Cela permet concrètement de donner une deuxième chance à l’équipe de retravailler le besoin et les spécifications sans gêne ni conflictualité, chose qui n’était pas envisagée par les modèles précédents.
Mais qu’est ce que cela change pour notre Testeur ? Dans un cycle itératif, Anas travaille dans un environnement moins tendu mais il est encore plus sollicité, non plus seulement pour vérifier la conformité aux spécifications mais aussi pour la sélection des fonctionnalités qui feront partie des différentes itérations, et aussi lors de la phase d’évaluation où son retour d’expérience sera attendu pour redéfinir le futur périmètre à réaliser.

Projet Agile

L’agilité n’est pas un cycle projet ni une méthode mais une une Culture. Le sujet de l’agilité sera donc traité séparément. En tant que nouveau testeur connaitre le cycle itératif sur lequel sont basés les projets agiles est un atout important. Le contenu de cet article est améliorable grâce à vos contributions, n’hésitez pas à me laisser vos remarques dans la zone de commentaires.

Qu’est ce qu’un testeur logiciel ?

Le rôle principal d’un testeur est d’apporter une information sur la qualité du Produit testé. Son travail est de fournir une réponse à la question : est ce que le produit est conforme au besoin ? Pour créer un logiciel d’envergure importante, il est nécessaire de constituer une équipe de profils multiples. Si le développeur est l’artisan qui va construire le logiciel (Le produit), le référent fonctionnel (Client, Utilisateur, Product Owner …) quant à lui est la personne dont les exigences sont à satisfaire: il décrit ce que le logiciel doit permettre de faire (Le besoin). Le testeur assure le lien entre les deux tout au long du projet. Le testeur interagit avec le référent fonctionnel afin d’assimiler son besoin initial, il vérifie que ce besoin est claire, cohérent et complet. Puis il accompagne le travail du développeur pour s’assurer que le produit développé correspond bien à ce qui est voulu par le référent. Donc récapitulant :
  • Le référent fonctionnel décrit le Besoin
  • Le développeur construit le Produit
  • Le testeur dit si le produit est conforme au besoin ou pas.
i le mot « dit » est choisit sciemment, parce que la responsabilité du testeur n’est pas de rendre le produit conforme, ni de modifier le besoin initial pour s’adapter au comportement constaté de l’application. La tâche principale du testeur est donc d’apporter une information sur la conformité ou non du produit développé par rapport au besoin exprimé. Cela ne diminue en rien la centralité de son action parce que c’est l’information qu’il apporte qui déclenche concrètement les travaux de correction du développeur et ainsi l’amélioration de la qualité du produit. Le testeur assimile donc le comportement attendu de l’application (Le besoin), le clarifie en faisant la chasse aux manquements et aux zones d’ombres du besoin, assure la bonne transmission de l’attendu entre le référent et le développeur, et vérifie finalement la conformité du produit au comportement attendu. Pour résumer voici les trois facettes du travail d’un testeur :
  1. Le rôle principal : vérifier la conformité de l’application au besoin
  2. Le Bon testeur : Assurer la bonne transmission du comportement attendu de l’application tout au long du projet
  3.  L’excellence : Participer activement à la bonne spécification du besoin dès les premières phases du projet
Ces différentes facettes du travail d’un testeur nécessite comme tout autre métier de la rigueur, tel un inspecteur qui scrute les recoins de l’application pour détecter tout écart avec les spécifications. Et de noter minutieusement toutes les étapes par lesquelles il est passé pour détecter l’anomalie pour permettre au développeur de la reproduire avant de la corriger. Un bon testeur communique « beaucoup », il en faut pour assurer la transmission du comportement voulu par l’utilisateur aux membres de l’équipe de développement. et de faire des retours sur l’état d’avancement et la qualité du produit. Un excellent testeur communique « bien » et a un rapport empathique avec ses interlocuteurs : il sait se mettre à leurs places. Un projet est un ensemble de personnes travaillant pour atteindre un objectif commun. Une personne n’est pas qu’un tas de connexions de neurones, il est un être émotionnel. Le relationnel du testeur est donc indispensable : quand il détecte une anomalie il doit savoir en discuter avec le développeur sans heurter sa sensibilité et le pousser à se mettre à la défensive. Un excellent testeur communique « bien » aussi en étant à l’écoute des besoins de l’utilisateur et des retours et contraintes de l’équipe de développement. Le contenu de cet article est corrigé ou enrichi grâce à vous, n’hésitez pas à me laisser vos remarques et vos contributions dans la zone de commentaires.

Comment estimer un projet de test

Tu es responsable d’une équipe de test et tu souhaites estimer la charge des activités de test de ton projet. Dans cet article tu vas découvrir une méthode simple et efficace pour y parvenir. N’hésites pas à poser des questions dans le zone commentaires pour clarifier tout point traité dans cet article.

Ce qu’il faut savoir avant de commencer :

Le test n’est pas une activité isolée, il dépend fortement de toutes les autres activités du cycle projet, et par conséquent, toi aussi tu dépends des autres acteurs du projet . L’estimation n’est pas une tâche que tu es sensé accomplir seul dans un bureau, il te faut des informations fonctionnelles, techniques et logistiques dont un responsable de test ne dispose pas toujours. Collaborer étroitement avec les autres intervenants du projet est alors capital: les profils métiers, les développeurs, et l’exploitation. Cette collaboration a un autre avantage qui a au moins autant d’importance; un intervenant associé au travail d’estimation, se sent naturellement respecté, sa compétence reconnue, et il a envie que cela dure et que le travail auquel il a participé soit une réussite et fera ce qu’il pourra pour que ça le soit. Impliquer les gens est un moyen respectueux et efficace pour les engager. L’estimation de la charge de test est idéalement réalisée au début du cycle projet, mais il arrive que dans la réalité, le responsable de test et son équipe soient impliqués tardivement dans le cycle projet, et sont donc contraints de fournir une estimation de la charge de test alors qu’une date butoir de mise en Production est déjà décrétée !

Mais comment estimer la charge de test ?

En résumé  :

Etape 1 : Créer la liste « à tester »

Le processus d’estimation commence par un travail de collecte d’information.

En tant que test Manager, tu dois contacter les représentants des autres équipes du projet (Métier, Dev, Opérations) afin de rassembler une liste d’exigences fonctionnelles et non fonctionnelles. Selon les projets, ces exigences peuvent être des fonctionnalités, des user stories, des cas d’utilisation … etc

Cette liste constitueras ton périmètre de test, il s’agit généralement d’une liste très proche de celle fournie à l’équipe de développement par la MOA, cela permet aux différentes équipes de parler un langage commun lors des réunions, cela facilitera grandement la communication et réduira les incompréhensions (phénomène de distorsion du besoin : pertes d’information d’une équipe à l’autre, dû à des interprétations incomplètes ou erronées du besoin initial).

La qualité de cette liste a un impact direct sur la qualité des développements et des tests.

Remarque pratique : Lors des échanges avec les parties prenantes, des points à vérifier par les tests peuvent être cités, il serait utile de bien les noter car cela pourrait apporter une aide non négligeable lors de la quantification des exigences de test correspondants (Etape 2).

Etape 2 : Prioriser les éléments de la liste

L’analyse de risque qualité (ou l’analyse de risque produit) est une façon efficace de prioriser les exigences.

Le risque est la possibilité qu’un événement négatif ou non désiré puisse survenir, on appelle un risque projet tout risque pouvant porter sur des aspects délai et coût du projet (dépassement planning, absence ressources, surcoût ressources..).et on appelle risque produit ou risque qualité tout risque pouvant porter sur la qualité du produit logiciel développé (fonctionnement, sécurité, fiabilité…).

Le test Manager n’est pas le mieux placé pour évaluer le risque qualité de chaque exigence, mais doit apporter la méthode adéquate. Il est donc nécessaire d’impliquer les intervenants clé qui ont fourni ces exigences, leur proposer une méthode de priorisation et les accompagner dans sa réalisation.

Remarque : les Étapes 1 et 2 peuvent être réalisées conjointement.

Etape 2.1 : Evaluer le risque

Pour chaque exigence, 2 valeurs sont à renseigner pour évaluer le risque de dysfonctionnement:

  • La probabilité d’occurrence d’une défaillance :La probabilité est élevée si la fonctionnalité correspondante est de grande taille ou complexe.
  • L’impact en cas de défaillance : Plus les conséquences d’un incident en production au niveau de cet exigence sont importants plus la valeur de l’impact est élevée

Etape 2.2 : calculer les scores de risque qualité des exigences

Evaluer le risque qualité revient à calculer le score de chaque exigence.

Score = Probabilité * Impact

Etape 2.3 : Catégoriser les exigences en classes de priorité

Classer ces exigences en catégories selon le score de risque qualité :

Etape 3 : Associer des approches de tests aux classes de priorité (stratégie de test)

Une stratégie de test sera établie en associant une approche de test (plus ou moins rigoureuse) à chacune des classes de priorité.

Plus le risque est grand plus il faut tester en profondeur

Une approche de test peut être une technique de test : tests exploratoires, valeurs limites, classes d’équivalence… ou simplement une couverture de test : nombre de combinaisons de valeurs des champs d’un formulaire, les profils opérationnels …

Associer à chaque classe de priorité une approche de test. Une approche de test peut combiner plusieurs techniques/couverture de test.

L’approche de test choisie détermine l’effort de test nécessaire pour diminuer le risque d’incident pour chacune des classe de priorité.

Etape 4 : Estimer l’effort de test

Etape 4.1 : Calculer les durées de test de référence

Simuler ou à défaut estimer les actions de préparation et d’exécution pour une exigence de référence simple en utilisant chacune des approches choisies.

La simplicité de l’exigence de référence facilite grandement l’exercice d’estimation. Choisir une exigence de petite taille : Probabilité = 1

Conseil pratique : Il serait utile de noter en commentaire les postulats sur lesquels ont été basé ces estimations de base. Cela aidera à réajuster sereinement les calculs plus tard.

Etape 4.2 : Calculer les charges de test

Estimer l’effort de test pour chaque exigence selon sa taille par rapport à l’exigence de référence(Probabilité) et sa catégorie (Approche):

La charge de test du projet est la somme des charges des exigences du périmètre de test.

Etape 5 : Ajuster l’estimation (nouvelle itération)

Il est toujours possible de réajuster les résultats de l’estimation en cas de besoin, pour cela tu disposes de plusieurs leviers :

  • Appliquer des Coefficients de modération aux charges des exigences: si l’équipe a hérite d’un patrimoine de test existant de précédentes campagnes, ou que le niveau d’expertise des testeurs est élevé, cela réduit significativement le temps de préparation et exécution …
  • Réévaluation du risque ( Importance métier, Complexité fonctionnelle, complexité technique)
  • Modification de la stratégie de test : Modifier l’effort de test ( approches, couverture, profondeur de test..)

Les questions et commentaires des lecteurs améliorent la qualité des articles et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.

Comment prédire la fin d’un projet de test

Les indicateurs d’analyse

L es indicateurs que nous avons vu dans l’article « Comment construite le tableau de bord d’un projet de test » sont des photos prises à un instant donné de la vie du produit logiciel, mais parfois nous avons besoin de plus pour analyser la situation de notre projet.

En réalité, un client demande autre chose que seulement comment se porte son projet à un instant donné, il peut exiger une visibilité sur le futur.

Il peut ainsi poser au responsable de test les questions suivantes :

  • « Quand est ce que tout ça va se terminer ? »
  • « Quel périmètre aura-t-on validé au 1er Juillet ? »
  • « Est ce qu’on aurait tout fini à une date donnée ? »
Quand est ce que tout ça va se terminer ?
Le responsable de test peut bien sûr lui faire une prévision basée sur des estimations et des calculs farfelues mais un Greattesteur se basera lui sur l’historique réel du projet. « Celui qui ne sait pas d’où il vient ne peut savoir où il va car il ne sait pas où il est. En ce sens le passé est la rampe de lancement vers l’avenir » l’Archiduc Otto d’Habsbourg-Lorraine Les résultats de l’exécution des tests sont ainsi sauvegardés et suivis dans le temps :

On peut associer d’autres données à ces courbes pour relever des corrélations :

  • Les fluctuations de la disponibilité de l’infrastructure
  • Les changements du nombre de personnes travaillant sur la préparation et l’exécution des tests et leurs vélocité.
  • La capacité de l’équipe de développement à corriger les anomalies.

Pour répondre alors à la question du client sur la fin des test, le Greattesteur peut donner une réponse en quelques secondes et voici comment il fera!

En se basant sur la courbe de tests en succès (OK), il va dessiner de façon manuelle une ligne de projection optimiste et une ligne de projection pessimiste.

L’écart entre la ligne optimiste et pessimiste symbolise la prédictibilité du projet de test, heureusement cet écart tend généralement à se stabiliser avec le temps.

La question du client fixe un objectif de périmètre à 100 %, mais le temps est variable.

La fin prévue des tests est alors l’intervalle entre les intersections des lignes de projection et la ligne du périmètre 100 %: Ici la fin des test est prévue entre mi-janvier et début Mars.

L’avantage de cet approche est sa simplicité, sa rapidité ainsi que la transparence qu’elle apporte vis à vis du client en communiquant honnêtement sur les incertitudes du projet.

Si le client souhaite une date au lieu d’une période, il est tout à fait possible d’utiliser la courbe de tendance qui existe nativement dans Excel : Outils de Graphique – Création – Ajouter un élément de graphique – Courbe de tendance – Prévision linéaire.

Quel périmètre aura-t-on validé au 1er Juillet ?

Dans ce cas le périmètre est variable et le temps est fixe. Cela donne quelques chose comme ça.

Est ce qu’on aurait tout fini à une date donnée ?

La même logique s’applique ici aussi. On constate que cette question fixe le périmètre à 100 % et fixe aussi la date (par exemple au 1er Décembre). Sur la graphique ça donnera quelques chose qui ressemble à ça :
Ici la réponse à la question du client serait clairement : « Non, on n’aura malheureusement pas tout fini au 1er Décembre ». Voici ce qui est sera validé à la date voulue.
Et voilà le délai nécessaire pour tout valider.

On aura donc le choix entre :

  1. réduire le périmètre : livrer en Décembre et le reste après
  2. ou allonger les délais : ne rien livrer en Décembre et tout livrer après

Le client choisira ce qui lui convient le mieux.

En général il vaut mieux commencer par réduire le périmètre, on peut toujours ainsi faire une deuxième livraison pour couvrir 100 % du périmètre.

Cette approche a l’avantage d’utiliser de vraies données pour ses prévisions et communique en toute transparence sur les incertitudes du projet.

En général il vaut mieux commencer par réduire le périmètre, on peut toujours ainsi faire une deuxième livraison pour couvrir 100 % du périmètre.

Références :

  • Le développement logiciel Agile du point de vue du métier. Vidéo de Henrik Kniberg traduite par Cédric Chevalérias et doublée par Florent Lothon (http://www.agiliste.fr).

Comment prédire la fin des tests

L es indicateurs que nous avons vu dans l’article « Comment construite le tableau de bord d’un projet de test » sont des photos prises à un instant donné de la vie du produit logiciel, mais parfois nous avons besoin de plus pour analyser la situation de notre projet.

En réalité, un client demande autre chose que seulement comment se porte son projet à un instant donné, il peut exiger une visibilité sur le futur.

Il peut ainsi poser au responsable de test les questions suivantes :

  • « Quand est ce que tout ça va se terminer ? »
  • « Quel périmètre aura-t-on validé au 1er Juillet ? »
  • « Est ce qu’on aurait tout fini à une date donnée ? »

Quand est ce que tout ça va se terminer ?

Le responsable de test peut bien sûr lui faire une prévision basée sur des estimations et des calculs farfelues mais un Greattesteur se basera lui sur l’historique réel du projet. « Celui qui ne sait pas d’où il vient ne peut savoir où il va car il ne sait pas où il est. En ce sens le passé est la rampe de lancement vers l’avenir » l’Archiduc Otto d’Habsbourg-Lorraine Les résultats de l’exécution des tests sont ainsi sauvegardés et suivis dans le temps :

On peut associer d’autres données à ces courbes pour relever des corrélations :

  • Les fluctuations de la disponibilité de l’infrastructure
  • Les changements du nombre de personnes travaillant sur la préparation et l’exécution des tests et leurs vélocité.
  • La capacité de l’équipe de développement à corriger les anomalies.

Pour répondre alors à la question du client sur la fin des test, le Greattesteur peut donner une réponse en quelques secondes et voici comment il fera!

En se basant sur la courbe de tests en succès (OK), il va dessiner de façon manuelle une ligne de projection optimiste et une ligne de projection pessimiste.

L’écart entre la ligne optimiste et pessimiste symbolise la prédictibilité du projet de test, heureusement cet écart tend généralement à se stabiliser avec le temps.

La question du client fixe un objectif de périmètre à 100 %, mais le temps est variable.

La fin prévue des tests est alors l’intervalle entre les intersections des lignes de projection et la ligne du périmètre 100 %: Ici la fin des test est prévue entre mi-janvier et début Mars.

L’avantage de cet approche est sa simplicité, sa rapidité ainsi que la transparence qu’elle apporte vis à vis du client en communiquant honnêtement sur les incertitudes du projet.

Si le client souhaite une date au lieu d’une période, il est tout à fait possible d’utiliser la courbe de tendance qui existe nativement dans Excel : Outils de Graphique – Création – Ajouter un élément de graphique – Courbe de tendance – Prévision linéaire.

Quel périmètre aura-t-on validé au 1er Juillet ?

Dans ce cas le périmètre est variable et le temps est fixe. Cela donne quelques chose comme ça.

Est ce qu’on aurait tout fini à une date donnée ?

La même logique s’applique ici aussi. On constate que cette question fixe le périmètre à 100 % et fixe aussi la date (par exemple au 1er Décembre). Sur la graphique ça donnera quelques chose qui ressemble à ça :
Ici la réponse à la question du client serait clairement : « Non, on n’aura malheureusement pas tout fini au 1er Décembre ». Voici ce qui est sera validé à la date voulue.
Et voilà le délai nécessaire pour tout valider.

On aura donc le choix entre :

  1. réduire le périmètre : livrer en Décembre et le reste après
  2. ou allonger les délais : ne rien livrer en Décembre et tout livrer après

Le client choisira ce qui lui convient le mieux.

En général il vaut mieux commencer par réduire le périmètre, on peut toujours ainsi faire une deuxième livraison pour couvrir 100 % du périmètre.

Cette approche a l’avantage d’utiliser de vraies données pour ses prévisions et communique en toute transparence sur les incertitudes du projet.

En général il vaut mieux commencer par réduire le périmètre, on peut toujours ainsi faire une deuxième livraison pour couvrir 100 % du périmètre.

Références :

  • Le développement logiciel Agile du point de vue du métier. Vidéo de Henrik Kniberg traduite par Cédric Chevalérias et doublée par Florent Lothon (http://www.agiliste.fr).

Principe 2 – Les tests exhaustifs sont impossibles

Tout tester (toutes les combinaisons d’entrées et de pré-conditions) n’est pas faisable sauf pour des cas triviaux. Plutôt que des tests exhaustifs, nous utilisons l’analyse des risques et des priorités pour focaliser les efforts de tests.
Qui n’a jamais rencontré un client qui demande de TOUT tester sur son application. Cette vidéo de moins de 3 minutes fournit une réponse rapide et claire. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, N’hésitez pas à m’écrire ci-dessous.

Principe 1 – Les tests montrent la présence de défauts

Les tests peuvent prouver la présence de défauts, mais ne peuvent pas en prouver l’absence. Les tests réduisent la probabilité que des défauts restent cachés dans le logiciel mais, même si aucun défaut n’est découvert, ce n’est pas une preuve d’exactitude.
Plusieurs décennies de tests logiciels ont permis d’identifier des règles auxquelles les tests se soumettent telles des lois de la physique. Re-visiter ces principes se révèle utile même pour des professionnels qui ont des années d’expérience derrière eux. Je vous ai préparé une série de courtes vidéos pour illustrer la substance de ces principes et les rendre accessibles à tous : Clients, Fournisseurs, Manageurs, Développeurs, Testeurs…etc La première vidéo « Principe 1 – Les tests montrent la présence de défauts »explique ce que le test peut faire et ce que le test ne peut pas faire. Les questions et commentaires des lecteurs améliorent la qualité du contenu et font plaisir à l’auteur, n’hésitez pas à m’écrire ci-dessous.