Discussion :

[Francis Walter]

Bonjour,

Je vous présente un tutoriel sur les tests, bugs & rock'n'roll par Bruno Doolaeghe.

Pourquoi les fins de projet sont-elles toujours aussi « rock'n'roll » ? Les méthodologies classiques de développements ont échoué…

Cet article, est bien plus que le rapport d'autopsie d'un énième projet qui a mal fini. Il tentera d'analyser pour vous, développeurs, les raisons de l'échec, et parviendra à vous convaincre j'en suis sûr, de tester une nouvelle eXPérience.

N'hésitez pas à donner vos avis par rapport à ce tutoriel dans ce fil de discussion.

Merci et bonne lecture.

[thierryler]

Waouu, super article, sympa à lire, j'adore...

Bravo.

Dans un style similaire : Mini roman sur 3T en pratique

Th.

[pascalCH]

Merci pour cet article dédramatisant sur les tests.

Quelques pierres supplémentaires à l'édifice...

Dans le cycle en V, mettre en œuvre la technique du TTD (développement piloté par les tests) s'avère une arme ultra efficace car elle nécessite (à tous les niveaux) d’émettre, en plus des spécifications, les conditions de réussites (les jeux de tests nominaux) mais également d'évacuer tout ce qui n'est pas du nominal et de prévoir le comportement du logiciel - composant - méthode en cas de sollicitation hors spécifications.

La difficulté réside bien sûr dans l'élaboration des jeux de tests juste nécessaires pour un résultat efficace; une formation aux techniques de bases (tests aux limites, partitionnement et gestion des domaines) permet aux développeurs d'être à l'aise dans l'écriture des tests, mais cela ne suffit pas, il faut que les prescripteurs soient capables d'en faire autant, ainsi que les intégrateurs, quand on y parvient, la boucle est bouclée, le logiciel sort, en temps et en heure, il ne subsistera que des anomalies de fonctionnement souvent liées à des spécifications erronées - ou mal exprimées - ou qui ont changées.

Pour ma part, je suis partisan d'avoir dans l'équipe, un "gardien des tests", garant de la méthode, capable de faire la revue de code (souvent oubliée) et qui pilotera les campagnes de tests.

Les tests doivent être présentés - à mon sens - comme un élément de confort pour les équipes; les bardées de tests, si elles sont suffisamment fines, permettent de localiser la source d'anomalie de façon ultra rapide et de vérifier, a peu de frais (une campagne de tests automatisée faite en batch la nuit), les éventuels effets de bord des corrections et les régressions éventuelles.

Pour conclure, les outils d'aujourd'hui permettent une automatisation très poussée des tests, y compris les tests d'UI et, au pire, le coût global du développement sera le même à un détail près.... la livraison d'un logiciel réellement testé en profondeur.