Maîtriser un outil d’automatisation apporte un vrai plus au profil d’un testeur logiciel.
Si j’avais juste assez de temps pour maitriser un seul outil d’automatisation, lequel je choisirai?
Il existe une variété d’outils d’automatisation et chacun permet d’automatiser un type de test particulier. Certains sont spécialisés dans les tests d’applications Web, d‘autres pour les logiciels bureautiques, certains dans les applications mobiles, et encore d’autres dans les tests d’interfaçage par API.
Apprendre un outil d’automatisation exige souvent d’apprendre un langage de programmation. Or programmer n’est pas le cœur de métier d’un testeur logiciel. Ainsi apprendre un langage de programmation est un investissement non négligeable.
Si je devais choisir un seul outil d’automatisation mon choix est fait!
Je choisirai RobotFramework!
Robotframwork est un outil d’automatisation conçu par des testeurs pour des testeurs contrairement aux autres outils. Quand on sait utiliser RobotFramework, on peut automatiser des tests pour des applications web, des logiciels installés en local, des applications mobiles, ainsi que des API.
De plus, on n’est pas obligé de maitriser un langage de programmation pour automatiser des tests sur RobotFramework. On peut créer des cas de tests sur RobotFramework en utilisant des mots clé.
Les mots-clés est ce qui s’approche le plus du langage naturel humain. Ceci rend sa syntaxe assez simple et le code des cas de tests sont facilement lisibles par les profils non techniques.
RobotFramework est un outil open source. Il est donc gratuit et extensible à volonté. C’est un argument de poids pour convaincre un client de l’adopter pour automatiser leurs tests.
Quelques-uns de mes clients les plus pointus technologiquement l’ont sélectionné comme leur outil d’automatisation généralisé. RobotFramework bénéficie d’une forte communauté dynamiques. qui le font évoluer régulièrement ainsi que les bibliothèques qui lui donnent toute sa puissance. Grâce à ces bibliothèques mises à votre disposition, Utiliser RobotFramework revient à utiliser en même temps : Selenium, Swing, Appium, API Soap, API REST, Kafka, Les bases de données…
Le métier de Testeur logiciel est un des métiers les plus intéressants dans le domaine de l’informatique mais il est souvent méconnu. La demande des profils d’assurance qualité qualifiés est forte par les entreprises qui souvent ne trouvent pas chaussure à leur pied.
Aujourd’hui nous allons parler Argent.
Combien gagne un Testeur logiciel?
Quels sont les salaires proposés actuellement sur le marché de l’emploi pour ce type de poste ?
Quelles sont les évolutions possibles si on veut gagner en responsabilité et en revenus?
Peut-on devenir indépendant et travailler en tant que Testeur freelance?
Si je suis Freelance quel TJM puis-je demander pour mes missions?
Nous allons essayer de répondre à ces questions et plus.
Combien gagne un Testeur logiciel?
Pour savoir combien gagne réellement un Testeur logiciel, nous allons nous baser sur les témoignages des testeurs qui exercent déjà. C’est quelque chose que vous pouvez faire chez vous à cet instant même.
Vous allez sur un site d’emploi comme glassdoor.com
Vous tapez le nom du métier qui vous intéresse et la position géographique.
Ici je m’intéresse au métier de Quality Assurance qui est l’appellation de poste choisie par la plupart des témoignages.
Je vais donc renseigner le métier de Quality Assurance
Ensuite je vais taper France dans la position géographique pour voir combien sont payés les testeurs en France.
En validant la recherche nous avons une représentation de la distribution des salaires du minimum au maximum recensé en passant par le salaire moyen.
Par exemple ici nous savons que les testeurs qui ont témoigné ont des salaires annuels commençant par 26000€ jusqu’à 65000€ avec un salaire moyen de 40000€ annuel brut.
En France on raisonne beaucoup en salaire Brut annuel, ce qui n’est pas simple à se représenter tant la fiscalité et les cotisations salariales et patronales sont complexes en France.
Deux personnes qui ont un même salaire brut peuvent recevoir des sommes différentes sur leurs comptes bancaires.
Mais ici nous allons simplifier les choses en donnant un ordre d’idée des salaires net.
Il existe des simulateurs gratuits sur internet pour calculer approximativement les salaires net à partir du brut.
Sur notre exemple alors, selon les témoignages recensés, un Testeur logiciel peut gagner entre 1624€ par mois jusqu’à 4063€ par mois.
Le salaire varie selon la zone géographique, le niveau d’étude du professionnel et d’autres paramètres plus subjectives qui ont un impact pendant les entretiens d’embauche.
Le salaire moyen pour un Testeur junior statistiquement serait de 2500€
Nous allons comparer cela avec les revenus d’un développeur qui gagnerai selon les témoignages entre 30k€ jusqu’à 53k€ ce qui donnerait un salaire net de 1875€ jusqu’à 3313€
Le salaire net moyen pour un développeur junior est de 2500€,
Un développeur et un testeur junior entrent donc dans les mêmes tranches de salaires.
Nous allons voir si le métier de testeur reste intéressant dans le temps quand on l’a exercé pendant plusieurs années.
Une évolution possible d’un Testeur logiciel est de devenir Test Manager.
Nous allons faire une recherche pour voir les salaires associés à ce poste en France.
Un Test Manager serait payé en France selon les témoignages entre 38k€ jusqu’à 79k€ ce qui fait un salaire qui va de 2400€ jusqu’à 5000€ ce qui est juste excellent.
Voyons voir si on évolue de Manager à Directeur combien cela représenterait en salaire.
Un Quality Director gagnerait entre 60K€ jusqu’à 164k€ ce qui correspond à des salaires allant de environ 3750€ à plus de 10000€ par mois ce qui est énorme.
Pour se le représenter nous allons voir les évolutions possibles d’un développeur selon les témoignages recensés.
Un développeur sénior gagnerait entre 30k€ brut annuel jusqu’à 67k€ brut annuel ce qui correspond à un salaire net mensuel allant de 2375€ jusqu’à 4188€ par mois.
Un développeur après quelques années d’expérience et s’il est bon il peut devenir Architecte logiciel.
Un architecte logiciel gagnerait entre 44k€ jusqu’à 79k€ ce qui correspond à un net mensuel allant de 2750€ jusqu’à 4938€ net mensuel.
Et si le développeur devient un Directeur de projet il pourrait gagner entre 3000€ par mois jusqu’à 6375€ par mois ce qui correspond à des brut annuels entre 48k€ jusqu’à 102k€
Les salaires de testeurs et ceux des développeurs peuvent donc exploser avec le temps et peuvent être multipliés plusieurs fois quand on gagne en expérience.
Les salaires des testeurs en Suisse
Nous avons pris des exemples en France mais cela reste vrai dans les autres pays comme la Suisse où les salaires sont encore plus hauts même pour les Juniors.
Un Testeur en Suisse commencerait selon les témoignages à 4834 francs suisse net mensuel jusqu’à 7052 francs net mensuel.
L’indice du francs suisse est généralement un peu plus bas que l’euro.
Un Quality Manager peut dépasser les 9000 francs et le Quality Director peut dépasser les 11000 francs.
La niveau de vie en Suisse est plus cher qu’en France mais il y a des centaines de milliers de personnes de nationalités suisses ou des non suisses qui travaillent en Suisse et résident dans un pays à la frontière, ce qui leur permet de tirer partie en même temps de la hausse des revenus suisses et des prix plus bas des pays à la frontières, on les appelle les frontaliers.
Les frontaliers ne payent les impôts qu’une seule fois et c’est dans le pays où ils travaillent, c’est à dire en Suisse, en sachant que l’imposition en Suisse est bien plus avantageuse qu’en France.
Les salaires suisses exposés précédemment sont net d’impôt.
Les revenus d’un Testeur indépendant
Devenir Freelance est un moyen pour gagner en liberté tout en augmentant ses revenus.
Le TJM est un acronyme pour Taux journalier Moyen qui est le revenu brut journalier.
Le TJM est donc combien est payé le freelance par jour sans extraire les impôts et les cotisations.
Un freelance qui serait payé avec un TJM de 500€ par jour combien devrait il gagner par mois?
Si le freelance a travaillé un mois de 30 jours, ce mois de 30 jours contiendrait 20 jours ouvrables c’est à dire des jours hors weekends et jours fériés.
Les freelance a donc travaillé 20 jours à 500€ par jour, cela fait un revenu brut de 10000€ pendant ce mois
Ce revenu est brut donc pour calculer son revenu net il faut extraire les taxes et les cotisations qu’on doit à l’état.
Le revenu net variera beaucoup selon si on a choisi de se reverser un salaire mensuel, ou des dividendes annuelles, si on a choisit de payer l’impôt sur les sociétés ou l’impôt sur le revenu et du statut de la société.
Mais pour simplifier nos calculs nous allons considérer que le revenu net serait 50% du revenu brut.
Pour découvrir les revenus d’un testeur logiciel indépendant nous allons consulter le site spécialisé freelance-info
En consultant les contribution qui ne sont que les témoignages collectés des freelances, les testeurs logiciels acceptent des TJM allant de 250€ jusqu’à 849€
Le testeur aurait donc des revenus mensuels qui varieront entre 2500€ à plus de 8000€ mensuel.
Ces recensement montre que peu de juniors de 1 à 3 ans d’expérience travaillent en Freelance puis plus les années d’expérience augmentent plus les professionnels préfèrent devenir indépendant que rester salariés.
La plupart des freelances sont recrutés pour des missions par des sociétés de services pour intervenir chez des clients finaux, et un faible pourcentage réalise une prestation directement pour un client final sans intermédiaire commercial.
Portage salarial
Devenir indépendant apporte de la liberté mais pas forcément de la simplicité au début.
Un freelance est un chef d’entreprise qui doit réaliser des factures et suivre soigneusement sa comptabilité.
Ce sont là des tâches administratives qui ne sont pas le cœur de métier d’un Testeur logiciel.
Il peut alors choisir de réaliser lui même ses tâches. ou bien des les déléguer à un comptable professionnel qui les réalisera pour lui contre rémunération. Ce qui constituera des frais supplémentaires à prendre en compte.
Aussi, Le freelance contrairement à un salarié n’a pas un filet de sécurité comme l’assurance chômage quand son contrat se termine.
Quand une mission s’arrête, les revenus s’arrêtent aussi.
Il n’y a pas de période d’intercontrat comme un salarié en CDI (Contrat à durée indéterminée) où lorsque on n’est plus affecté à une mission, on est payé quand même.
Avoir des revenus fluctuants est un risque qui va de paire avec la liberté apportée par l’entreprenariat, quand on est un informaticien expérimenté c’est plutôt rare de ne pas trouver une nouvelle mission.
Il existe toutefois une solution qui permet en même temps de profiter de la liberté d’un freelance et de la sécurité d’un salarié.
C’est le portage salarial.
Le portage salariale est un contrat entre 3 entités, le professionnel, un client et une société de portage.
Le professionnel “porté” travaille comme le ferait un indépendant chez son client mais sans s’occuper des démarches administratives.
La société de portage lui rédige un contrat de travail avec la durée de la mission et s’occupe de toutes les démarches y compris la comptabilité et le règlement des impôts et des cotisations dues
Le professionnel se concentre seulement sur son cœur de métier et laisse à la société de portage le soin de s’occuper de tout le reste contre une rémunération qui varie généralement de 6 à 8% du TJM.
Quand la mission du professionnel se termine pour une raison ou pour une autre, le statut de portage salarial lui permet de bénéficier de l’assurance chômage tout comme un Salarié.
C’est un statut qui apporte un avantage financier intéressant et un équilibre entre liberté et sécurité bien apprécié.
N’hésitez pas à réagir à cet article dans la zone des commentaires.
Ils sont vrais quelques soit le contexte des projets ou le niveau d’expertise des professionnels.
Le testeurs doit les assimiler car il est souvent amené à les expliquer à ces principaux interlocuteurs dans les projets informatiques.
Principe 1 : Les tests montrent la présence des défauts
Les tests ne sont pas une assurance d’absence de défauts
Quelques soit l’importance du nombre de défauts qu’on a trouvé sur l’application, et le temps qu’on a passé dans les tests sans en trouver de nouveaux, ce n’est pas une preuve d’absence de défauts. Cela ne prouve que le risque de défaillance a diminué. Sans jamais pour autant prétendre que le risque est nulle ou que le logiciel contient 0% de défauts. Ce qui est impossible à affirmer.
Principe 2 : Les tests exhaustifs n’existent pas.
Si un client demande aux testeurs de tester toute l’application, c’est qu’il n’a pas compris ce que sont les tests.
Il est impossible de tout tester.
Imaginons qu’on veuille tester une page d’inscription qui contient un formulaire de plus de 10 champs on peut facilement aller vers des milliards de tests, ce que aucun projet ne peut se permettre à cause du temps et des coûts d’une telle entreprise, et cela reste impossible qu’on opte pour pour des tests manuels ou automatiques.
C’est la raison pour laquelle il faut sélectionner les tests importants qui ont un impact sur la qualité de l’application et les séparer des tests qui ont peu de valeur ajoutée.
Principe 3 : Tester tôt
Ce principe encourage à tester le plus tôt possible dans le cycle projet. Parce que plus tôt un défaut est détecté, plus tôt il sera corrigé, moins cher sera le coût de cette correction et moins cela impactera les activités suivantes du cycle de vie du projet. Ce principe est important et serait revu dans d’autres articles.
Principe 4 : Regroupement des défauts
Il existe une loi universelle qu’on appelle la loi Pareto qui dit que 80% des problèmes sont issues de 20% des causes.
Cette loi est aussi vrai dans les tests logiciels où 80% des défauts de qualité proviennent des 20% des modules les plus complexes, les plus instables ou les plus utilisés.
Pour tester efficacement un logiciel il faut toujours commencer par trouver et cibler les modules les plus critiques de ce logiciel.
Principe 5 : Le paradoxe du pesticide
Ce paradoxe nous explique que parfois utiliser un pesticide pour éliminer un bug (insecte en anglais) peut avoir l’effet contraire et faire proliférer ces bugs.
La même chose risque de se produire dans le domaine des tests logiciels quand on lance les même tests sur les mêmes modules en utilisant les mêmes techniques, on trouvera de moins en moins de défauts avec le temps.
Pour tester efficacement dans le temps, il faut varier les angles d’attaques en mettant à jour les tests existants et en ajoutant des tests nouveaux.
Principe 6 : Tester selon le contexte
Tester un site de réservations de voyages et vacances est différent de la démarche de test d’un équipement informatique pour les hôpitaux.
Un défaut sur ce dernier peut impacter des vies d’êtres humains contrairement au site de voyage.
Des gens ne seraient pas d’accord, et diront que l’annulation d’un voyage de rêve peut être aussi grave mais bon.. je pense que la majorité des gens conviendraient que les équipements des hôpitaux sont plus critiques.
Les tests sur les systèmes les plus critiques doivent être les plus rigoureux. Et des choix stratégiques doivent être faits : Niveaux de tests, outils de tests, profondeurs de test, couverture des tests manuels ou des tests automatisés, types de tests, techniques de test, niveau de traçabilité…etc
Principe 7 : L’illusion d’absence d’erreur
Est-ce que la création d’un logiciel qui fonctionne bien – dans le sens ou le logiciel est conforme aux spécifications fonctionnels et que tous les bugs trouvés ont été corrigés – est ce que ce logiciel va satisfaire les clients ?
Ce n’est pas sûr. Un logiciel peut fonctionner correctement sans incident mais être inutilisable dans la réalité et ne pas satisfaire les attentes des utilisateurs finaux,
Par exemple :
Un logiciel de gestion des dossiers de demandes d’aide qui est parfaitement conforme aux spécifications fonctionnelles mais ces spécifications telles qu’imaginés théoriquement s’avèrent finalement dans la pratique inutilisables en cas de saisie de grande quantités de dossiers. Une ergonomie compliquée et non intuitive nuit gravement à la facilité d’utilisation d’un logiciel ainsi qu’à la productivité du personnel qui va l’utiliser.
Un logiciel qui fonctionne bien sur un navigateur mais pas sur le navigateur préféré des utilisateurs, cela est vrai aussi sur les variétés des systèmes d’exploitation et les appareils (Ordinateurs, tablettes, téléphones..)
Un logiciel avec une charte graphique qui ne correspond aux attentes des utilisateurs
.. etc
Les tests d’acceptation permettent d’éviter plusieurs désagrément de ce genre puisque contrairement aux tests systèmes qui vérifient la conformité du produit logiciel par rapport aux spécifications fonctionnelles (qui elle même peut être une conception théorique erronée), les tests d’acceptation quant à elles valident le produit logiciel par rapport aux besoins métier réels.
Tester permet de détecter des défauts et c’est la tâche du testeur,
Déboguer (De-buguer) permet comme son nom l’indique de défaire des bugs, càd de corriger des défauts.
Le débogage est une tâche réalisée par le développeur.
Quand un testeur trouve un incident, il le communique au développeur qui réalise un debugging pour mettre le doigt sur le défaut dans le code qui a causé la défaillance afin de le corriger.
L’histoire ne s’arrête pas là.
Le testeur doit reprendre la main après la correction, en réalisant le test à nouveau sur son environnement de test pour confirmer que le défaut a bien été corrigé, et non seulement sur le poste du développeur. Ces re-test sont appelés : les tests de confirmation.
La différence entre « tests dynamiques » et « tests statiques » est que :
Les tests dynamiques sont réalisés sur un logiciel en cours d’exécution
alors que les tests statiques sont effectués sur du code source non exécuté et sur de la documentation.
Qu’ils soient statiques ou dynamiques les tests fournissent des informations sur le produit logiciel. Des informations qui pourrait servir pour améliorer la qualité du produit ou améliorer l’efficacité du processus de sa fabrication.
On avait dit précédemment que ce ne sont pas les tests qui améliorent directement la qualité du logiciel mais bien les activités de développement qui le corrigent.
Faire des tests c’est comme faire un diagnostic médical, le diagnostic donne des informations sur l’état de santé d’une personne.
Pour cela, il est possible d’utiliser des approches statiques comme des radios et des scanners
ou des approches dynamiques en mesurant les capacités physiques du patient en analysant ses performances en mouvement c’est à dire en lui faisant faire des exercices spécifiques et vérifier qu’il y arrive bien ou pas.
Cet article apporte des éléments de réponses aux questions suivantes :
Est ce que en tant que testeur je dois réaliser tous les tests dans un projet?
Est ce que dès qu’il y a le mot test alors c’est moi qui est responsable?
Est ce que quand il y a un problème dans le logiciel c’est ma faute?
Les mauvaises réponses
Il y a effectivement des croyances largement répondues qui conduisent à mal répondre à ces question, par exemple :
Oui dès qu’il s’agit de tester c’est au Testeur de faire. (Les développeurs développent et les testeurs testent.)
Dès qu’un incident apparait sur l’application déployée en production c’est la faute du testeur, car c’est à lui de veiller à ce que aucun défaut ne traverse jusque là.
Pourquoi ces réponses sont mauvaises
a. “Les développeurs développent et les testeurs testent”
Cette réponse est fausse pour les raisons suivantes :
Le temps
L’argent
La main d’œuvre : les compétences
L’équilibre des pouvoirs : l’indépendance
Le temps et l’argent
Pour illustrer ce point, imaginons une équipe composée de 3 développeurs et un testeur.
Souvenons nous des niveaux de test : Les fonctionnalités programmées par les développeurs doivent passer par plusieurs niveaux de test : les tests unitaires, les tests d’intégration, les tests système et les tests d’acceptation
Disons que chaque développeur travaille sur une fonctionnalité qui prend 2 jours de codage et 1 jour de tests unitaire.
Si c’est le testeur qui doit coder les tests unitaires (parce que c’est tests sont codés avec un langage de programmation), alors il devra y travailler pendant 3 jours (1 jour x 3 fonctionnalités)
alors que chaque développeur n’a travaillé jusque là que 2 jours (codage de la fonctionnalité)
Et cela sans prendre en compte le fait que dans la réalité le testeur aura besoin de plus qu’un jour pour coder les tests unitaires d’une fonctionnalité développée par quelqu’un d’autres, il doit donc l’assimiler avant de créer les tests unitaires correspondants.
Ajoutons à cela 1 jour par fonctionnalité pour faire les tests d’intégration et 2 jours par fonctionnalité pour faire les tests système.
Cela fait donc 3+3+6 = 12 jours/homme de travail pour le testeur.
Alors le testeur travaillerait 12 jours pour chaque 2 jours de travail d’un développeur.
Pour absorber cette charge de travail, le gestionnaire du projet doit alors recruter une équipe de 6 testeurs pour que les testeurs et les développeurs finissent le travail au même moment.
Et les tests d’acceptation qui les fait? si ce sont les même testeurs alors la charge augmentera encore plus ainsi que les coûts associés.
La main d’œuvre
Même si on est prêts à payer le prix, ou est ce qu’on peut trouver des testeurs qui maîtrisent autant de sujets différents, par exemple : Java pour le code, JUnit pour les tests unitaires, Jenkins pour l’intégration continue, Git pour le versioning du code, les techniques de tests statiques, les techniques de test dynamique, les outils de gestions de test comme XRAY, ALM ou Squash, les outils de gestion des anomalies comme Mantis, les protocoles d’interfaçage, les outils des tests d’intégration comme Postman, les tests de régression, les tests automatisés , les tests de sécurités et les tests de performances qui sont des domaines à part entières…etc.
Autant chercher des moutons à 5 pattes.
C’est une mauvaise affaire pour le client puisque même s’il met plus de temps et d’argent sur cette configuration, le travail sera finalement moins bien fait.
L’équilibre et l’indépendance des pouvoir
Un autre point qui fait qu’on ne peut pas juste mettre les testeur partout, c’est que le testeur doit garder une distance par rapport à la technologie pour qu’il puisse préserver sa capacité à juger un logiciel par “ce qu’il permet de faire” et non par “comment il est fabriqué”.
Un logiciel qui est codé avec les technologies les plus récentes ne doit pas émouvoir le testeur si ces technologies ne permettent pas d’atteindre l’utilité fonctionnelle attendue.
Pour juger de cette utilité un testeur doit garder le recul nécessaire pour se concentrer sur la valeur ajoutée contrairement au développeur qui doit plonger dans les considérations techniques.
ce sont là deux paradigmes différents et tous les deux sont nécessaires pour la réussite d’un projet.
Pour faire le parallèle avec l’équilibre des pouvoir politiques, le pouvoir législatif, le pouvoir exécutif et le pouvoir judiciaire
Le rédacteur des spécifications représente le pouvoir législatif car il crée la loi qui est ensuite suivie par les développeurs qui représentent le pouvoir exécutif, Et finalement le travail des testeurs ressemble au pouvoir judiciaire car ils jugent la qualité du produit par rapport aux spécifications.
Les spécifications jouent le rôle de la loi dans un projet logiciel.
Dès qu’un incident apparait sur l’application déployée en production c’est la faute du testeur, car c’est à lui de veiller à ce que aucun défaut ne traverse jusque là.
Si ton client pense ça alors il faut être pédagogue et lui rappeler les principes généraux des tests:
Les tests exhaustifs n’existent pas
Les tests montrent la présence de défauts mais ne garantissent pas l’absence de défauts
Et l’illusion de l’absence de défauts
Les tests ne garantissant pas l’absence des défauts, les testeurs ne peuvent pas non plus garantir l’absence des défauts.
Le testeur travaille sur la base du risque.
S’il n’y a pas de risque il n’y a pas de test.
Tout le travail du testeur est de réduire le risque au maximum selon les moyens à disposition.
Un testeur n’annonce donc jamais un risque 0.
Comme il a un temps limité pour tester un périmètre, il essaye de trouver les défauts les plus critiques au plus tôt pour se donner le temps de les corriger.
L’idéal c’est que si des incidents réussissent à se retrouver en production , alors ces incidents sont mineurs, car on a trouvé et corrigés tous les défauts majeurs bien avant.
Mais ça c’est l’idéal.
Alors le testeur ne garantie pas l’absence d’incidents en production.
La bonne réponse
La qualité est l’affaire de tout le monde et pas seulement des testeurs.
Le testeur peut piloter tous les aspects de la qualité s’il a assez d’expérience mais ne peut prendre en charge toutes les actions de test.
En se basant sur la pyramide des niveau de test nous pouvons faire une première distribution des responsabilités
Les niveaux de tests unitaires et intégration sont réalisés en général par les développeurs.
Les niveaux de test système et acceptation sont réalisés par des testeurs mais pas les mêmes
Les tests systèmes ont pour objectif de vérifier le produit par rapport aux spécifications fonctionnelles et sont alors réalisés par les testeurs de l’entité qui a fabriqué le produit : la maitrise d’œuvre, le fournisseur de service ou l’éditeur logiciel
Les tests d’acceptation ont pour objectif de valider que le produit répond aux besoins métier alors ces tests sont réalisés par des testeurs appartenant à l’entité qui va recevoir le produit : le client ou la maîtrise d’œuvre.
Les tests de sécurité et de performances sont aujourd’hui quant à eux assez pointus et sont réalisés par des spécialistes dont c’est le métier.
Quand un testeur réalise des tests système ou d’acceptation, il donne des résultats de test sous forme d’indicateurs qui expriment clairement le niveau de qualité de la partie couverte par les tests et le niveau de risque résiduel de la partie non couverte par les tests.
Dites moi dans la zone commentaires ce que vous pensez de cette distribution de travail théorique à adapter bien sûr à chaque contexte?
Dites moi aussi comment les tests sont organisées dans votre projet?
Or, would you prefer a straightforward response that covers key points and makes sense of abstract concepts? Though clarity is key, Google also places a high value on being thorough. This means marketers need to be careful…
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 :
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.
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.
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.
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.
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.
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.
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 :
les procédures sont écrites pour les tests manuels et que les scripts sont programmés pour les tests automatisés.
Les tests dans l’ordre d’exécution souhaité.
Les données de tests et toutes les informations qui seraient utiles aux tests sont ajoutés aux tests
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 testsont 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 testveut 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 :
Action : Allumer la calculatrice => Résultat attendu : la calculatrice est allumée et affiche un 0
Action : Renseigner la valeur 9 => Résultat attendu : La valeur 9 s’affiche sur l’écran
Action : Appuyer sur le bouton « + » => Résultat attendu : La valeur 9 s’affiche toujours sur l’écran
Action : Renseigner la valeur 11 => Résultat attendu : La valeur 11 s’affiche sur l’écran
Action : Appuyer sur le bouton « = » => Résultat attendu : La valeur 20 s’affiche sur l’écran
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.
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.
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.
