octobre
2009
Un article de dgueguen
La qualité est-elle uniquement l’affaire des testeurs?
Dans ce contexte la qualité représente l’adéquation avec les besoins utilisateurs et de fiabilité.
Cette idée est de plus en plus mise en avant: équipe de test intégrée aux services qualités, possibilité de refuser une livraison, les testeurs maîtrisent la spécification et les points de vue utilisateurs et les activités de développement et de test sont séparées.
Pour avoir travailler dans ce type d’organisation, j’ai observé les travers suivants:
– mauvaise qualité des tests unitaires
– le développement ne se préoccupe pas des expériences utilisateurs et celle des autres intervenants d’ailleurs (production, administration …)
– mauvaise communication entre équipe projet et test
– dé-responsabilisation du chef de projet vis à vis de la décision de livrer
etc …
La qualité ne devrait-elle pas être un objectif commun à toute l’équipe?
C’est possible en définissant en amont pour un produit quels sont les objectifs en terme de qualité (utilisabilité, fiabilité, maintenabilité, sécurité …) à atteindre et les partager sur toutes les activités (définition des exigences, conception, développement et test).
En effet comment avoir un produit robuste aux attaques si on a pas pris cette objectif en compte lors de la conception? Comment avoir un produit fiable si les tests unitaires n’ont pas été effectués?
Quelques pratiques peuvent nous aider à améliorer la qualité:
– Définir en amont les objectifs qualité à atteindre.
– Définir avec tous les intervenants en amont les principaux scénarios utilisateurs y compris ceux des administrateurs, opérateurs et production.
– Mettre en place des pratiques de TDD (test driven development)plutôt que de s’acharner sur des conceptions détaillées.
– Former les équipes aux tests, pas uniquement les testeurs.
etc …
Une chose est sûre, c’est que lorsque les développeurs sont déchargés de la responsabilité de la qualité, on prend le risque de voir augmenter les besoins en test et en maintenance.
En 2000, on me racontait l’histoire d’une SSII qui avait vu croitre l’équipe de maintenance de façon plus importante que l’équipe de développement… Preuve que les développeurs ne livrait plus le meilleur d’eux même.