Le test arrive-t-il plus tôt avec les méthodes Agiles ?

Teste-t-on plus tôt avec les méthodes Agiles ??

La question peut paraître triviale mais il me semble important de se la poser… Surtout que la réponse ne l’ai pas forcément!

En effet, même si l’Agile permet de grandes avancées sur le shift left ces dernières ne sont pas globales comme nous allons le voir avec cet article.

Les méthodes Agiles permettent de tester plus tôt le fonctionnel

S’il est une chose que l’on ne peut pas retirer aux méthodes Agiles c’est bien de permettre au test d’arriver très tôt dans le processus. On le voit par exemple avec:

  • L’intégration des testeurs dans les équipes Agile ce qui permet au testeur d’être présent dès les premières lignes de code et de partager leurs connaissances avec l’ensemble des autres membres de l’équipe
  • L’adoption de nouvelles méthodes de développement comme le TDD et le BDD afin de permettre aux tests d’être toujours présents et exécuter mais surtout d’orienter le développement
  • La présence de revues! Faire des revues régulière est une excellente pratique. On peut d’ailleurs faire des revues de beaucoup de livrables comme les spécifications, les tests ou le code. En Agile il y a généralement une revue qui est toujours faite, c’est celle des User Story. En effet, au plus tard, lors de l’estimation de ces dernières une revue est intégrée ce qui permet à l’équipe de bien comprendre le besoin.
  • La présence d’un représentant du client (le PO en Scrum). Cela peut paraitre anodin mais c’est particulièrement important. Le PO permet de donner des retours réguliers sur ce qui est développé et donc d’éviter des cas comme celui-ci.

Il est donc impossible de le nier, en Agile, on teste (généralement) plus tôt le fonctionnel qu’en cycle en V et ce grâce à plusieurs paramètres liés à l’Agile, le plus important étant la présence de testeurs dans l’équipe.

Néanmoins, même si l’Agile a apporté des améliorations, il est difficile de dire sans arrières pensées qu’en Agile on teste plus tôt qu’avec des méthodes dîtes traditionnelles.

Si je devais me prononcer sans nuances (ce qui est rarement une bonne idée) je dirai sans hésiter qu’en Agile on ne teste pas plus tôt car la majorité des critères de tests sont soit:

  • toujours fait au dernier moment
  • toujours inexistants

Je parle ici bien sûr des tests non-fonctionnels, tests particulièrement importants!

En Agile le non-fonctionnel est encore trop souvent à la fin du projet voir totalement ignorés.

Attention, je n’écris pas cette phrase dans le but de faire polémique. Je suis malheureusement très sérieux et ne suis pas le seul à le dire. Je pense par exemple à l’infographie DevSecOps de IT-Social qui prend comme source des enquêtes de 2018 et 2019.

Au delà de l’enquête je le vois également dans la vie de tous les jours. Prenons queques exemples:

  • Les tests de sécurité: ils sont souvent négligés. Dans le cas où ce n’est pas le cas il arrive régulièrement que ces tests soient consécutifs à un audit juste avant (ou même après) un déploiement. Il est vrai que les secteurs fortement impactés par ce critère y font plus attention (ex: automaobile) mais ils restent une exception.
  • Les tests de performances: ces tests sont de plus en plus présents… Mais ils arrivent là encore quand le système a l’eensemble de ses composants… Et donc quand cela coûte très cher d’apporter des corrections. Lorsque ces tests ne sont pas implémentés, les retours sur la performances se font souvent au « ressenti » lors des tests d’acceptation. A la décharge des équipes, les tests de performances sont des tests assez techniques et par forcément simples à implémenter
  • Les tests de fiabilité: pour être honnête, à part les tests de robustesses qui sont souvent conçus par les testeurs en implémentant des valeurs invalides, ces tests sont souvent carrément oubliés. Je n’ai croisé que très peu d’équipes incluant des tests de réccupérabilité et de disponibilité.
  • Les tests de maintenabilité: ces tests sont étonnamment maintenant assez présents, partiulièrement pour le critère de testabilité (merci le TDD et le BDD pour ça) et la modularité (merci les micros-services)
  • Les tests de portabilité: ces tests sont généralement fait lors de phases de bêta test
  • Les tests de compatibilité: ces tests sont rarement effectués ‘Agile ou non)
  • Les tests d’utilisabilité: ces derniers sont rarement faits et quand ils existent se résument à des tests d’ergonomie. Les retours se font généralement par les utilisateurs finaux. De même, le critère d’accessibilité est souvent ignoré alors alors que certaines bonnes pratiques sont assez simples et bien décrites avec le WCAG.

Pourquoi ce constat ?

Ce constat peut paraitre très sévère mais il est à relativiser!

Tout d’abord, les tests fonctionnels sont vraiment faits et pensés plus tôt.

De même, les tests non-fonctionnels ont toujours été les parents pauvres du test… qui lui même était le parent pauvre du développement logiciel.

Sans oublier que les tests sont souvent conçus à partir de spécifications, hors, les spécifications liés aux critères non-fonctionnels sont rarement présentes.

Enfin, l’émergence (ou plutôt la démocratisation) du déploiement continu, qui permet une mise en production sans œil humain va forcer les équipes à développer ces tests car les testeurs manuels ne peuvent pas, avec le déploiement continu, assurer le filet de sécurité qu’ils proposaient sur ces parties de la qualité du logiciel.

Conclusion

En Agile on teste plus tôt le fonctionnel. Lee critères non-fonctionnels sont encore généralement exécutés (et pensés) à la fin lorsqu’ils existent. Néanmoins, ce n’est pas une fatalité et s’explique aisément par le fait que culturellement les critères non-fonctionnels ont rarement été mis en avant et que les spécifications non-fonctionnelles étant incomplètes ou inexistantes limitent la possibilité de concevoir des tests de qualité.

Enfin le développement du déploiement continu va forcer les équipes à incorporer des tests non-fonctionnels car cet outil supprime le filet de sécurité du test manuel qui permettait de lever certains problèmes non-fonctionnels qui n’était pas repérés par les tests.

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

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Publié par

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s