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.
