La taverne du testeur

L’ATDD 2 / 4 :  Une spécification hiérarchique des fonctionnalités

Nous avons vu les différentes vues d’un système. Même en agile, il faut les avoir pour comprendre le système et le tester (PO et testeurs : validation des « nouveautés » et de la régression).

Alors comment gérer tous ces artefacts et comment poursuivre la décomposition du système jusqu’à aboutir aux US, dont les critères INVEST sont si souvent vantés ?

Architecture d’un produit et agilité : les avantages de l’ATDD 

Les avantages sont multiples :

  1. Le métier capitalise son savoir.

Pour lui la compréhension d’une fonctionnalité est meilleure, au lieu de multiplier des modélisations de features/epics qui ne représentent, en fait, que les nombreux éléments temporaires de développement.

  • Les analyses de régression vont être facilitées

En effet, en particulier, les UC qui sont modifiés (par une tâche interne modifiée ou une tâche supprimée) doivent subir des tests pour les points qui n’ont pas de raison d’être impactés. Dans Jira si vous fermez une epic Scrum en la déclarant terminée, il vous faudra en recréer une pour des modifications ultérieures. Or ces 2 epics sont en fait deux évolutions d’une même UC (il faudra un tag par exemple pour mettre en évidence ce lien).  L’ATDD vous le montre directement.

Nous pouvons donc aboutir à structurer tout système :

  • En « cas d’usage » (une modélisation pour un parcours client bien clair). Ex : vente d’un produit de type X à des couples mariés ou Pacsés. En traditionnel on aurait réalisé des processus valables pour différents cas d’usage, en complexifiant l’analyse et le développement.
  • En éléments pour le cas d’usage considéré : le système est un produit composé, avec de multiples sous-parties
  • De manière hiérarchique : les éléments sont plus ou moins « gros »
  • En montrant leurs enchaînements fonctionnels (mais sans les expliquer)
  • Avec des « éléments fonctionnels stables » : ce qu’est le produit à un instant T, sans rendre compte des itérations de développement (nous verrons le lien entre fonctionnalités et artefacts agiles par la suite).

En définitive on a, par exemple :

Exemple d’architecture métier avec l’outil YEST : liste des éléments fonctionnels à un instant T pour le cas d’usage A

On notera que les « UC » peuvent être réutilisés. 

Un outil ATDD permet des analyses d’utilisation des éléments.

Exemple d’analyse d’utilisation d’un élément (ici un UC) avec YEST

L’analyse va maintenant se poursuivre avec toute l’équipe agile.

On doit, en effet, décomposer chaque UC en “tâches” élémentaires pour l’usage du produit.

A priori lorsqu’on les définit, par analyse de décomposition des UC, ces tâches ATDD sont initialement des US ayant les critères INVEST : c’est le principe à retenir pour commencer à lier ATDD et agilité !

Exemple de décomposition d’un UC en tâches avec YEST

En résumé

3 points important à retenir :

  •  l’ATDD, est une spécification des tests qui utilise généralement une forme graphique de modélisation de l’enchaînement d’éléments fonctionnels, en limitant l’utilisation du système à un cas d’usage  (un contexte précis de qui utilise le produit et le type de résultat attendu). On y voit en effet les dépendances entre eux, sans en comprendre les rouages, les règles qui expliquent leurs enchaînements.
  • Les tâches sont les plus petits éléments, non décomposables. Ils n’ont donc pas cette forme graphique.
  • Les tâches peuvent être initialement des US ayant de la valeur métier, estimable, testable (heureusement !). Nous y reviendrons plus tard, mais disons pour faire simple, INVEST, par opposition aux modifications de détail (par exemple un changement de style de police, l’ajout d’un logo, la modification de détail dans une règle de gestion, etc.).

Laisser un commentaire

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

Automatisation

Le calcul du ROI des tests automatisés, que prendre en compte ?

Pour calculer le ROI des tests automatisés il faut d’abord bien estimer le coût des tests. J’en avais déjà parlé dans cet article. Le coût des tests ce n’est pas que leur exécution. Le coût des tests c’est : ·        L’écriture du cas (coût qui n’arrive qu’une seule fois) ·        Le coût de

Lire la suite »