Résultats du sondage « Quel testeur agile êtes-vous ?

Avant toute analyse je souhaiterais remercier les plus de 100 personnes qui ont répondues à ce sondage et qui permettent d’avoir une représentation plutôt fiable sur la vision du testeur agile.

Sur les 111 personnes qui ont répondu, quasiment toutes se considèrent comme testeur et travaillent actuellement sur un projet/produit agile

Pour rappel, cet article est le résultat du sondage mené par la taverne aux mois de juillet et mars. Le but de ce sondage était de définir un portrait type du testeur agile et de ses pratiques.

Nous pouvons donc commencer l’analyse des résultats de ce sondage (contactez directement la taverne si vous souhaitez les résultats bruts).

Le rôle tu testeur agile

Le testeur agile est avant tout un « coach » test devant apporté la qualité. Néanmoins il doit également assumer un rôles d’analyste de test, capable de concevoir les test, d’automaticien, ayant un background technique pour faire de l’automatisation et une teinte de test manager pour organiser les tests. En bref, un testeur agile doit idéalement être capable de couvrir plusieurs métiers du test. Dans les faits,on attendra de lui la capacité à bien faire comprendre l’importance de la qualité. Les autres capacités demeurant importantes mais pouvant, dans certains cas être complétées par d’autres membres de l’équipe agile.

Les produits agiles

Les personnes ayant répondues travaillent essentiellement sur des produits « Web ». Les technologies « Web » se prêtent particulièrement bien à l’agilité mais surtout aux techniques de déploiement continu. Il n’est donc pas étonnant de retrouver ce type de produits très représenté. De même, on constate une part non négligeables (plus du tiers) de produits liés à l’industrie mobile.

On peut se dire en voyant ces résultats que les mise en production doivent être très fréquentes. Ce n’est étonnamment par forcément encore le cas. En effet, pour presque 20% des sondés il n’y a qu’1 à 4 livraison par an. Ce pourcentage dépasse les 42% pour les produits livrés 10 fois ou moins par an (donc moins d’une fois par mois). Dès lors on s’aperçoit que la possibilité donnée par l’agilité de livrer plus souvent n’est par forcément (encore) utilisée (Est-ce du à une automatisation insuffisante?). Toujours d’après ce sondage, on peut quand même remarqué que près d’1/3 des sondés proposent plus de 20 livraisons par an.

L’amélioration continue et les testeurs agiles

Un des points essentiels avec l’agilité c’est la capacité à s’améliorer continuellement. Pour cela faire des rétrospectives s’avèrent essentiel. Malheureusement il arrive trop fréquemment que ces rétrospectives soient négligées voire même supprimées pour des raisons de « productivité ». On peut néanmoins s’apercevoir que cette pratique est bien suivie dans les équipes agiles disposant de testeurs. Les testeurs apporteraient-ils cette vision de qualité permettant de bien comprendre l’intérêt de ces réunions. N’ayant pas de chiffres sur les équipes agiles sans testeur je ne peux rien affirmé mais peut par contre annoncer que les rétrospectives sont faites dans plus de 85% des équipes des sondés ce qui est un chiffre qui me semble élevé!

Faire des rétrospectives c’est bien. Ce n’est malheureusement pas suffisant. Il faut définir des actions à l’issue de ces dernières, suivre ces actions et voir l’impact qu’elles ont apportées. Ces étapes sont assez bien suivies dans les équipes agiles disposant de testeurs. On peut cependant remarquer qu’il y a un nombre élevé de Non Applicable pour le suivi des actions. Cela peut s’expliquer de 2 manières: les équipes ne faisant pas de rétro et les équipes n’ayant pas encore fait de seconde rétrospectives.

Les équipes agiles

Sans surprise, la quasi totalité des testeurs agiles travaillent avec des développeurs. Que tester si rien n’est développé ?

Il est cependant malheureusement moins fréquent pour les testeurs de travailler avec des analystes métiers même si la proportion reste proche des 3/4. Ce manque de 25% peut être particulièrement problématique car ajoute un silo entre les exigences et le reste de la chaine de développement, pratique qui va à l’encontre du BDD et de l’ATDD.

Enfin, on s’aperçoit que le DevOps commence à avoir de l’influence car près du 2/3 des sondés travaillent avec des opérationnels!

Enfin, il est également bon de noter que le testeur est rarement le seul à tester dans les équipes agiles et donc qu’il y a une prise de conscience des équipes qui savent que la qualité du produit est l’affaire de tous!

Cette tendance à faire tester toute l’équipe peut expliquer en partie le développement des approches types ATDD/BDD qui sont utilisées dans plus de 40% des des équipes des sondés.

Enfin, il est également bon de voir que les testeurs agiles, qui demandent aux autres membres de tester se dévouent également pour leur équipe en intervenant pour plus de 50% d’entre eux sur des activités comme l’analyse du besoin, la documentation ou les spécifications. Cela n’empêchant pas une partie non négligeable d’entre eux de travailler sur le suivi de la production (shift right).

Les tests exécutés

Sans surprise, lorsqu’il y a un testeur agile dans l’équipe il y a des tests fonctionnels. Les autres types de tests étant également représentés. Je tiens à attirer votre attention sur le fait que cette question mélange des types de tests et des niveaux de test qu’il ne faut pas confondre!

Dans les faits il n’y a pas énormément de surprise sur le pourcentage des tests existants à part pour les tests unitaires qui sont absents dans plus de 40% des produits (on perd le shift left!) et des tests d’acceptation absent dans près de 20% des cas (mais où est le PO?)

Automatisation des tests

On peut s’apercevoir qu’une grande partie des tests sont automatisés (le pourcentage de tests automatisés est généralement supérieur à 2/3 de celui des résultats des tests présent sur le produit), ce qui semble normal tant l’automatisation devient prépondérante en agilité. Je suis par contre très surpris par le fait que certains tests unitaires ne soient pas automatisés!

De même, on peut s’apercevoir qu’il reste encore de nombreux projets d’automatisation des tests au sein des équipes, le but étant de s’approcher du déploiement continu et donc de s’approcher du 100% d’automatisation pour passer en production.

Les outils des tests

Sans surprise, pour automatiser les tests, sur les produit essentiellement Web des sondés, Sélenium occupe une place très importante. On peut également s’apercevoir que les outils de KDT sont encore peut utiliser alors qu’ils permettraient à de nombreux profils non techniques de travailler à l’automatisation des tests.
PS: je m’excuse pour l’erreur sur le graphique du à une modification du sondage en cours de route avec la mise à jour du nouveau nom d’UFT en Lean FT. On peut néanmoins s’apercevoir qu’UFT reste légèrement plus utilisé que TestComplete mais aussi qu’il y a de nombreux outils d’automatisation pas forcément cités (sachant qu’il existe aussi des outils développés en interne).

Il est impossible de parler d’agilité et d’automatisation sans parler de chaine d’intégration continue. Cette chaine existe dans près de 3/4 des cas et il y a près d’1/3 des équipes disposant d’une chaine d’intégration continue qui vont jusqu’au déploiement continu. Ce nombre (28) peut être comparé à celui indiquant un nombre de livraison supérieur à 20 par an (34). En effet, le déploiement continu permet des livraisons très fréquentes.

Enfin, avoir des chaines d’intégration continue n’est pas une fin en soi. Il ne sert à rien d’avoir une chaine d’intégration continue si cette chaine est trop longue. Le temps limitant le nombre d’exécution possibles. On peut en effet estimer qu’une durée inférieure à 10 minutes permet plusieurs exécutions par jour. Une durée entre 10 et 30 également mais en cas de nécessité car sinon il est préférable de les faire tourner la nuit ou pendant les heures de repas. Enfin une exécution de plus de 2 heures peut être rédhibitoire et souvent exécutée uniquement la nuit.
Ici, on peut s’apercevoir que pour plus d’1/3 des sondés, cette chaine d’intégration dure moins de 30 minutes et est donc aisément exécutable. Par contre, il est effrayant de s’apercevoir que pour environ 1 sondé sur 6 il n’y a pas du tout de test dans la chaine d’intégration continue.

Par rapport aux tests présents dans ces chaines, la présence de certains types de test sont obligatoire si l’on veut faire plus que de l’intégration mais aller jusqu’à la livraison voir le déploiement. On peut voir ici que ce n’est pas parce que des tests sont automatisés qu’ils font automatiquement parti de la chaine d’intégration continue:

Framework

Le framework agile qui reste le plus en vogue reste Scrum. De plus, même si les organisation d’agilité à l’échelle tendent à se développer, dans les fait, elles ne représentent que peu de testeurs.

Il est d’ailleurs intéressant de noter que les framework d’agilité à l’échelle les plus connus ne sont pas forcément suivi et qu’il y a donc sûrement des agilités à l’échelle « home made » issues des expériences des sociétés les utilisant.

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.