La taverne du testeur

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

Une réponse

  1. Merci pour cet article (old but gold !)
    Je rejoins le constat que tu fais. C’est aussi pour ça que je pense que les QA gagnent à être dans la boucle dès le cadrage de chaque projet, pour alerter sur les aspects non-fonctionnels à anticiper.

Laisser un commentaire

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

culture générale

Les 7 principes du test: le paradoxe du pesticide / usure des tests (5/7)

Dans cette série vous pourrez trouver dans chaque article une présentation d’une des 7 principes fondamentaux du test. Paradoxe du pesticide / Usure des tests Description Ce principe est probablement un des principes les plus complexe à comprendre au premier abord. C’est pourquoi c’est le seul principe qui a déjà

Lire la suite »
Agilité

12 : Des scénarios de test d’une US INVEST aux tests

Les scénarios de test sont identifiés grâce à l’algorithme des tamis successifs. Reste à “valoriser” les scénarios de test (critères d’acceptation avec leurs valeurs intermédiaires) pour obtenir les “tests” de l’US. Principe le plus courant de valorisation des données On pourra s’attacher à analyser chaque affirmation de chaque RG. Il

Lire la suite »
Stratégie

A partir de quand faut-il faire évoluer ses tests ?

Introduction Le paradoxe du pesticide est un des 7 principes du test et probablement celui qui a fait l’objet du plus grand nombre d’articles dans la taverne. Cet article met en avant la nécessité de faire évoluer ses tests car ces derniers sont de moins en moins efficaces! Savoir qu’il

Lire la suite »