Stratégie de test, Qualité et Agilité: la Vision qui change tout

La stratégie de tests est indispensable à tout projet agile.

On dit toujours que l’agilité met l’accent sur la qualité. C’est vrai :

  • des pratiques telles que l’intégration continue, les tests unitaires, les tests de recette, le pair programming mais aussi une volonté évidente d’automatisation jouent indéniablement sur la qualité du produit logiciel…
  • le client sur site et de courtes itérations, pour plus de collaboration et de feedback permettent de s’assurer que le « bon produit » est développé…
  • Avec l’ajout d’un regard Lean et d’une approche ergonomique, le compte est souvent bon…

ET POURTANT dans les faits, stratégie de test et testeurs ont du mal à se retrouver dans les projets Agiles, comme si toute une approche qualité était occultée, menée de manière anarchique, sans ligne directrice…
ça doit changer; ça va changer !

VERS UNE NOUVELLE VISION DES TESTS DANS LES PROJETS AGILES… trois éléments déterminants

Intégrer les testeurs dans l’équipe Agile et enrichir leur rôle (à la fois plus proches et au service de l’équipe mais aussi en soutien fort du Product Owner, du Métier). Cette alerte Agile (Où sont les testeurs) allait dans ce sens, et les résultats sont le plus souvent probants.

Donner un nouvel élan à la stratégie de test dans une dynamique agile. La stratégie de test se doit d’abord d’être envisagée dans une dimension high level en Sprint 0 pour l’ensemble de la version (une version, c’est entre 3 et 6 mois). Ensuite, le challenge du testeur est de l’ajuster en contexte à chaque début de sprint, en fonction du contenu du sprint à venir et de ce qui a été qualifié de Done au sprint précédent. A ce niveau, on va à l’essentiel : la stratégie de test, niveau sprint a la particularité d’être à la fois synthétique et trés précise !

S’appuyer sur le génialissime modéle de Brian Marick (signataire de l’Agile Manifesto et Star de la qualité logiciel) pour formaliser cette stratégie de tests. A chaque sprint, piocher son type de tests dans tel ou tel quadrant. Un modèle, trés visuel, instantanément compréhensible et trés parlant non seulement par le spécialiste QA qui sommeille en vous, mais aussi par toute personne impliquée dans un projet informatique.

gile Testing Quadrants Brian MArick
4 quadrants (initiés par Brian Marick, repris par Lisa Crispin & Janet Gregory dans l’excellent ouvrage Agile Testing)  qui à eux seuls guideront l’ensemble de votre stratégie:

  1. Tests orientés Technologie en soutien de l’équipe (ex : Tests unitaires et approche TDD , le plus automatisé possible)
  2. Tests orientés Business en soutien de l’équipe (ex: les tests sur storyboard, les tests fonctionnels pour vérifier les critères d’acceptation du Product Owner: l’approche de conception centrée utilisateurs et l’ergonome y trouvent leu compte)
  3. Tests orientés Business pour critiquer le produit (c’est avant tout du manuel, à tout moment ou en End Game pour le systéme complet en test d’acceptation. L’approche ergonomique ressort encore : quand on vous dit qu’il faut faire des Tests Utilisateurs !)
  4. Tests orientés Technologie pour critiquer le produit (des tests essentiels qui se doivent d’être outillés et qui peuvent nécessiter la présence de spécialistes, perf / sécurité; souvent en End Game hormis simulations)

5 Comments

  1. Nicolas Ercolano
    à

    Bravo ! Très bon article qui met l’accent sur un aspect particulièrement important exigeant des méthodes agiles.

    Notez que c’est également un point important du cycle en V, du moins en théorie, mais vu que les tests interviennent en fin de cycle, la plupart des organisations les bâclent pour rester dans les délais et ne cherchent pas à les rationaliser, ce n’est alors pas considéré comme une activité productive. (Tout comme la qualité industrielle a été considérée il fut un temps lointain comme une activité secondaire).

  2. Blaquiere guillaume
    à

    Excellent article en effet qui s’applique aussi au cycle en V pour définir quel type de test est à implémenter sur différente partie.
    Les équipes et les chefs de projet qui négligent les tests ont une seule raison de le faire: si leur application n’est pas destinée à évoluer (et encore… pendant la phase de recette, des tests de non régression ne font jamais de mal!!). Dans tous les autres cas, et pour au moins garantir la non régression du développement initial, les tests sont à considérer, et surtout pas en fin de cycle, mais comme une part du développement lui même.

    Sur le projet MsgHub (BFI), l’ajout de tests unitaires nous a pris environ 33% de temps en plus sur le dev. Le résultat est sans appel, la moindre modification peut être faite même si on ne maitrise pas tous les impacts, les tests sont là pour ça! On sécurise ainsi, le code, les modifications et les évolutions.

Les commentaires sont fermés.