Principe 9 – Les tests c’est pas pour le nuls !
2008
» En développement agile, le test est intégré dans l’ensemble du cycle de vie, des tests continuent tout au long du développement du logiciel. »
Le développement Agile ne possède pas une phase de test en tant que telle. Les développeurs sont fortement engagés dans les tests et l’écriture des tests unitaires automatiques pour valider leur code.
En complément d’être orienté vers une meilleure qualité des logiciels, c’est aussi important de mettre en œuvre le principe « Des petits développements, itératifs et des livraisons incrémentales ». Avec des tests unitaires automatisés, les tests peuvent être effectués dans le cadre de la compilation, en veillant à ce que tous les éléments fonctionnent correctement chaque fois que la compilation est produite. Cette compilation doit être réalisée régulièrement, au moins une fois par jour, pour que l’intégration soit réalisée au fur et à mesure.
Le but de ces principes est de maintenir le logiciel dans état dit : « livrable » tout au long du développement, afin qu’il puisse être expédié chaque fois que c’est approprié. Il s’avère aussi utile pour ne pas laisser le logiciel accumuler les anomalies et attendre le dernier moment pour les corriger (méthode traditionnelle de développement)
Le XP (Extreme Programming) cette méthodologie Agile va encore plus loin. XP recommande le développement piloté par les tests, l’écriture des tests avant d’écrire le logiciel.
Mais les tests ne doivent pas seulement être réalisés par les développeurs tout au long du développement. Il y a un rôle très important dans l’équipe : l’intégrateur. Comme nous le savons, tous » les développeurs ne peuvent pas tester le caramel ! » 
Le rôle d’un intégrateur peut changer considérablement en développement agile, dans un rôle plus proche de l’assurance de la qualité que de simples tests. Il y a des avantages considérables d’avoir un intégrateur impliqué dès le début.
Cette situation est amplifiée encore par « Des besoins macro, léger et visuel » en développement agile, l’accent est mis sur la conversation et la collaboration des exigences par rapport à une approche traditionnelle d’écriture lourde des spécifications et des documentations.
Bien que les exigences peuvent être précisées en détail dans le développement agile (tant qu’ils se font juste à temps et pas tout à l’avance), il est tout à fait possible que cela puisse se traduire par une certaine ambiguïté et /ou dans certains cas, les membres de l’équipe n’ont pas la même compréhension des exigences.
Alors qu’est-ce que cela signifie pour un intégrateur agile ? Une préoccupation commune des intégrateurs en particulier pour ceux qui changent régulièrement d’environnement projet – est qu’ils ne savent pas précisément ce qu’ils doivent faire comme test. Ils n’ont pas une spécification détaillée pour effectuer le test, alors comment peuvent-ils tester?
Même dans un environnement plus traditionnel de développement, j’ai toujours fait valoir que les testeurs ont besoin de spécification, et pourtant le produit pourrait encore être de mauvaise qualité, peut-être
parce que les exigences ont été mal spécifiées ou parce qu’elle a été clairement mal écrite. Une spécification n’est pas nécessairement le bon produit !
En développement agile, il y a une conviction que, parfois – peut-être même souvent – ces choses ne sont réellement évidentes que quand on peut voir le logiciel fonctionner en livrant des petites livraisons incrémentales et progressives et en mesurant le progrès sur un logiciel fonctionnel, le test décisif est de voir le logiciel et alors seulement vous pouvez juger si oui ou non, il est de bonne qualité.
Les tests Agile induisent donc à plus de jugement de la part de l’intégrateur, d’une expertise de ce qui est bon et ce qui ne l’est pas, la capacité d’être plus flexible et avoir la connaissance et la vision de ce que doit être un bon logiciel. Ce n’est pas certainement une simple affaire de suivi de scénario de test, en s’assurant que le logiciel fait ce qui est écrit dans les spécifications.
C’est pour ces raisons, que les tests en Agile nécessitent une très expérience et une expertise !

commentaire