L’agilité c’est pas bien…

« Scrum, ce n’est pas bien pour les testeurs, car les développeurs n’ont pas le temps ne nous fournir des livrables suffisamment bons pour qu’on puisse tester à la fin de l’itération…»

C’est ce que j’ai entendu il y a pas très longtemps  dans un entretien de recrutement pour un poste de testeur avec une expérience de l’agilité. Le candidat n’a pas été retenu … mais ce qu’il m’a dit est finalement riche d’enseignements !

Tout d’abord, dire qu’on a mis en place une démarche agile, ça ne suffit pas et quand bien même aujourd’hui presque tout le monde le prétend (le World Quality Report indique que 93% des entreprises ayant répondu en 2014 ont conduit au moins un projet agile), il faut le faire en comprenant les fondements, sinon ça ne sert à rien. Passer à l’agilité, nécessite d’abord un réel investissement en formation et en accompagnement car c’est un changement majeur par rapport au modèle suivant lequel la plupart des développeurs ou testeurs ont été formés, et si je pense que la plupart sont capables d’assimiler le nouveau paradigme (je ne partage pas la vision très pessimiste à ce sujet de Ken Schwaber : Can Software Developers Meet the Need ? ), ce n’est jamais fait sans efforts. Notons qu’il y a des outils très simples permettant de s’assurer que les fondements sont connus et maîtrisés, comme les Professional Scrum Assesments de Scrum.org. Ensuite, une fois que le déploiement est terminé, et bien, ce n’est pas fini… car il faut en permanence évaluer ses pratiques et les adapter.

L’autre aspect concerne la qualité. La qualité, qu’on soit agile ou pas d’ailleurs, doit être l’affaire de tous les contributeurs des projets de développement, et en particulier évidemment des développeurs. Même si elles sont encore souvent négligées pour de mauvaises raisons (on ne sait pas trop comment faire, ça prend trop de temps,…) les pratiques de tests commencent dès le développement (TU à minima, TDD c’est mieux), voir même avant (ATDD, par exemple). Et de manière plus générale, il est indispensable d’avoir une stratégie globale, incluant la qualité tout au long du cycle de vie complet du logiciel, afin que tous les acteurs contribuent efficacement (et en connaissance de cause) à la qualité des systèmes informatiques.