L’impact du manifeste agile sur le test

Nous avons généralement tous entendu parlé du manifeste agile. Ce dernier a très souvent été expliqué et même réutilisé sous d’autres formes comme j’ai pu le faire avec ma proposition de manifeste du testeur. Néanmoins, je n’ai encore jamais vu d’article analysant ce manifeste et son impact direct sur le test et le travail des testeur. Je vous propose donc aujourd’hui cette analyse.

Pour rappel, le manifeste agile c’est ça:

  • Les individus et leurs interactions plus que les processus et les outils

Cette valeur est particulièrement impactante pour les testeurs malgré le fait que certains points devraient également être appliqués que l’on soit en agile ou non.
Pour le testeur, cette valeur se traduit par le fait qu’il va se retrouver à devoir échanger régulièrement avec des développeurs, des analystes métiers, des opérationnels…
Cet aspect de communication fréquente est également une (très) bonne pratique à mettre en place lorsque l’on n’est pas en agile. Je n’ai que trop souvent vu des échanges de fiches de bugs avec le développeurs qui se plaint du testeur (il soule le testeur, ça marche sur ma machine son scénario) et inversement (quel glandeur ce développeur qui ne fait rien mais dit que le bug est corrigé).
Ces échanges fréquents (et souvent oraux) devront prendre une place plus importante que les processus et les outils.
Par plus important il ne faut pas entendre que les processus et les outils vont disparaitre, par contre cela veut dire que certains problèmes seront plus rapidement (et efficacement) résolus en discutant et en échangeant que par des processus et outils (ex: pour un bug détecté, le testeur va directement voir le développeur pour le reproduire et le corriger directement).
De même, ce point indique également que, selon le contexte, les processus et outils peuvent être amenés à évoluer. Ces évolutions arrivent, normalement, suite à des changements de contexte ou des rétrospectives permettant une amélioration continue. L’aspect amélioration continue est d’ailleurs un point clé du succès des projets/produits développés en agile.

  • Des logiciels opérationnels plus qu’une documentation exhaustive

Là encore ce point force le testeur à évoluer. On a avec cette valeur le fait que le logiciel sera fonctionnel, au moins partiellement, avant de être totalement documenté ce qui est en parfaite adéquation avec la dernière valeur. Le testeur aura donc à tester un produit qui ne sera pas définitif, dont on ne connaitra pas non plus l’aspect final, mais qui sera utilisable/livrable.
Avec ce point il est bien sûr sous-entendu, avec l’utilisation du pluriel dans « logiciels opérationnels », que l’agilité propose un mode de développement incrémental du produit afin de livrer de la valeur plus rapidement. Cela engendre donc la multiplication des campagnes de test car le test se doit d’assurer que les produits livrés régulièrement sont opérationnels et qu’ils atteignent le niveau de qualité souhaité. Cela crée donc, pour le testeur, la nécessité d’automatiser certains tests (au moins une partie des tests de régression).
De même ce point indique que le testeur devra travailler différemment pour concevoir ses tests, la documentation n’arrivant pas forcément en amont de cette conception. Avec le BDD et l’ATDD on peut même parler de documentation par les tests. Bref, le testeur se retrouve à tester « plus tôt » (ce qui correspond à un des 7 principes du test) et n’attends donc plus forcément la documentation, qui peut, dans certaines équipes et selon la charge de travail des la personne ayant le rôle d’analyste métier arriver après la conception des tests.
Dans tous les cas, le testeur devra travailler et échanger avec l’ensemble des membres de l’équipe agile (souvent le PO) pour concevoir ses tests. Certaines informations ne se trouvant que grâce à ces échanges et non plus dans une documentation préalablement écrite.

  • La collaboration avec les clients plus que la négociation contractuelle

Cette valeur est celle qui, d’un point de vue extérieur, semble être celle qui impacte le moins le testeur. Néanmoins c’est peut être celle qui nécessite le plus gros changement pour le testeur car elle demande un changement d’état d’esprit.
En effet, la première valeur semble être du bon sens et ne devrait pas être limité à l’agilité. La seconde valeur, quant à elle engendre un besoin d’automatisation (qui était déjà en cours avant l’agilité) et la nécessité de tester plus tôt qui est un des 7 principes du test. Enfin, la dernière valeur avec l’adaptation au changement est quelque chose auquel les testeurs de cycle en V font régulièrement face et qui est explicité.
Dans ces 3 cas l’état d’esprit du testeur évolue « peu », ce dernier continuant d’appliquer des bonnes pratiques liées à son métier quelque soit le mode de développement employé.
La valeur « La collaboration plutôt que celle de la négociation contractuelle » engendre 2 gros changements.
Le premier c’est le fait de travailler avec les clients. Pour travailler avec les client il faut collecter leurs retours, connaitre la production, connaitre leurs attentes sur le produit ainsi que la valeur, pour les utilisateurs, de ce qui sera livré. Le testeur est donc amené à voir son ancien périmètre d’action s’élargir et voir le produit dans son ensemble. Dans le même temps, le testeur peut trouver plus de sens à son travail car il comprend mieux l’utilisation des fonctionnalité qu’il teste.
Le second changement, qui ne semble pas à première vu directement lié directement à la « négociation contractuelle » mais qui est en fait particulièrement important, c’est que le testeur ne devra plus se cantonner à être « testeur » (même si son contrat stipule qu’il est testeur et lui donne une liste de mission). Le testeur devra là encore se dépasser et être capable de faire autre chose que du test!
Au foot ou dans tout autre sport on parlerai de « dépassement de fonction ». Or dans une équipe de foot, comme dans une équipe agile, ce qui fait qu’une équipe est performante c’est justement la solidarité et le dépassement de fonctions des membres de l’équipe qui jouent pour l’équipe!

  • L’adaptation au changement plus que le suivi d’un plan

Cette valeur est la dernière valeur énoncée dans le manifeste agile. Elle reste néanmoins aussi importante que les autres. Elle impacte le testeur sur sa visibilité à long terme. En agilité il n’y a plus de plan précis prévu sur plusieurs mois voir années (dans le cas contraire on perd toute adaptation au changement). Le testeur va avoir une bonne visibilité sur les évolutions à court terme (1 mois). Pour le reste cela pourra être aisément modifié notamment avec les retours des utilisateurs ou des changements de priorités liés à des raisons marketing.
Le testeur se retrouve donc dans un environnement changeant et est donc amené à retravailler des points déjà développés et ne pas pouvoir anticiper sur le long terme. Le testeur devra également se faire à l’idée qu’il travaille sur un produit en constante évolution (les tests automatisés devront donc être bien aisément maintenables). Par contre, le testeur saura, que la fonctionnalité sur laquelle il travaille sera utile pour le produit (ce qui n’est pas forcément vrai pour toutes les fonctionnalités d’un produit développé en cycle en V) et qu’elle apportera de la valeur aux utilisateurs et ce, si nécessaire, très rapidement après avoir été imaginée.

Conclusion:

Le manifeste agile prône des valeurs qui changent complètement le travail d’un testeur.
Afin de bien s’adapter à ce nouveau contexte, le testeur agile se doit de bien les comprendre afin d’adopter le bon état d’esprit nécessaire à l’agilité.

 

Si le rôle du testeur Scrum et son travail en agile vous intéresse, je vous invite à mon article sur le rôle du testeur dans cette méthode, les 12 principes du testeur agile ainsi que la journée type du testeur.
De manière générale, vous trouverez de nombreuses informations en faisant une recherche avec le mot clé Agilité.

Enfin, si vous avez le temps, pouvez-vous répondre à ce sondage ayant pour but de définir un profil de « testeur agile ».
Un grand merci à touts ceux qui ont déjà répondu ou qui y répondent!

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Agilité

Livre CFTL – Rex – Echec d’un projet/produit agile

Dans ce chapitre, nous nous attarderons sur un projet agile qui fût un « échec ». Par échec, je ne veux pas dire pas que le produit n’a jamais vu le jour mais plutôt que le projet, ou devrais-je dire le produit, a :  Explosé les coûts prévus  Explosé le temps prévu (près

Lire la suite »
culture générale

La maturité des tests: les modèles actuels (1/3)

La maturité des tests est un sujet complexe dans le monde du test logiciel. Il n’est d’ailleurs pas étonnant que pour mesurer cette maturité ou même élaborer des moyens d’industrialiser l’évaluation de cette maturité on passe par des « experts ». Dans cette série je vous propose une description de ce sujet

Lire la suite »
Automatisation

Outil de test: Automatisation avec Katalon studio

Katalon en bref Katalon studio est un outil d’automatisation de test développé par Katalon LLC. Katalon permet d’automatiser des tests d’application web et de bureau, application mobile, API’s. Katalon studio ne nécessite aucune dépendance tierce car il intègre déjà une série de librairie, les webdrivers des différents navigateurs pour les

Lire la suite »