Dans le cadre du développement logiciel, la notion de Test Agile – ou Agile Testing en anglais – peut se résumer en une phrase : Il s’agit d’appliquer les valeurs et principes de l’agilité au domaine du test. Mais au-delà de cette définition en quoi le test agile consiste-t-il réellement et comment se différencie-t-il de l’approche traditionnelle d’assurance qualité ?

Analyse par Eric Ferrot – Senior Software Engineer chez Agile Partner 

Le test agile en bref

Le terme « agile » est devenu un buzzword employé par beaucoup de monde avec bien souvent et malheureusement, un sens différent. Pourtant pour s’entendre sur ce qu’est l’agilité il suffit de revenir à l’origine de ce terme et à la rédaction du manifeste agile en 2001 à Snowbird. Dans ce manifeste dix-sept spécialistes s’accordèrent sur 4 valeurs et 12 principes permettant une meilleure approche du développement logiciel.

La notion de test ne figure pas directement dans le manifeste agile. Mais ses valeurs et principes peuvent s’appliquer au domaine du test pour donner une approche très différente de celle traditionnellement utilisée dans un développement dit « en cascade ».

En effet, une approche en cascade séquence le développement en différentes phases consécutives, dont l’une est dédiée aux tests : tout d’abord l’analyse des besoins, puis le design, ensuite le codage, suivi donc d’une phase de tests et enfin la livraison. Appliquer une approche agile ne consiste pas à découper en itérations ce long processus, avec à l’intérieur de chaque itération ces même phases en cascade, mais à considérer qu’elles ne sont plus séquentielles. Le test n’est donc plus vu comme une phase après le codage mais comme une activité faisant partie intégrante de l’itération tout au long de celle-ci.

De la même façon, un développement traditionnel va mettre toute la responsabilité de qualité dans les mains des testeurs. Il y a ainsi une claire séparation des rôles : une personne fera partie soit des analystes, soit des programmeurs, soit de l’équipe qualité. Au contraire de cette approche en silos, l’agilité insiste sur le principe d’une seule équipe avec chaque individu au sein de celle-ci prenant part aux différentes activités et donc aux tests. La qualité est maintenant la responsabilité de tous et tout le monde doit prendre part aux tests.

L’agilité privilégie un pilotage par la valeur. Dans cette optique le test doit servir non pas à vérifier que le logiciel est conforme aux spécifications précédemment établies mais à questionner ces spécifications afin de s’assurer qu’elles satisfont au mieux les besoins métier du client. Il s’agit donc de prévenir en amont les problèmes fonctionnels et de minimiser ainsi leurs coûts. L’écriture de tests d’acceptation lors de l’analyse a donc pour premier objectif d’aider à construire la meilleure application possible.

On vous le dit !

Il ne suffit pas d’être dans une équipe agile, ou qui se dit agile, pour que l’activité de test soit effectuée de manière agile. Pour évaluer votre niveau de test agile dans votre équipe posez-vous les questions suivantes :

• Les testeurs participent-ils à la définition des spécifications et s’impliquent-ils donc dans la compréhension du métier ? Vos spécifications contiennent-elles des tests ? Rappelez-vous que ces tests servent plus à questionner les spécifications qu’à les valider après coup et que le point de vue complémentaire du testeur est primordial pour poser les bonnes questions. Privilégiez-vous une approche agile pour les spécifications telle que « spécification by examples (http://blog.agilepartner.net/specifications-by-examples-avec-gojko-adzic/) » ?
• Les programmeurs participent-ils aux tests ? Ecrivent-il des tests unitaires pour s’assurer de la non régression ? Utilisent-ils TDD pour piloter leur développement ? Ou BDD dans le cas où les spécifications contiennent des tests d’acceptance ?
• Vos tests sont-ils automatisés ? Avez-vous mis en place un système d’intégration continue faisant tourner ces tests automatiquement à chaque fois que du nouveau code est ajouté ? Vérifiez-vous la couverture de votre code par ces tests ? Rappelez-vous aussi qu’une automatisation des tests à 100% n’est pas réaliste et que l’activité de test manuelle est complémentaire.
• La qualité fait-elle partie intégrante de votre « Definition Of Done » ? Essayez-vous continuellement d’améliorer celle-ci ? Et ceci de manière collective par exemple au cours des rétrospectives ?

Alors êtes-vous agile au niveau de vos tests ? N’hésitez pas à venir échanger et partager votre expérience avec nous sur notre blog !