Tests agiles

Dans le numéro de juin de Software Test & Performance :

  • un article (et la couverture) sur l'utilisation de Scrum pour les activités de test
  • et surtout une excellente présentation des différents tests dans un cadre agile par Dean Leffingwell "Take the Agile Path to true Balance". Il présente bien la problématique des tests dans un développement agile.

Il suggère notamment qu'une itération de "durcissement" est bien souvent nécessaire à la fin d'une release, après les itérations "normales". C'est une évidence pour les projets débutant dans l'agilité auxquels je participe : tant qu'on n'a pas complètement automatisé, tous les tests concernant une user story ne peuvent pas être passés dans l'itération où elle est réalisée. Cela nécessite déjà un gros changement dans les habitudes pour y commencer les tests fonctionnels.

Commentaires

1. Le mercredi 07 juin 2006, 01:06 par Oaz

De mon point de vue, cette itération de durcissement n'est rien de plus que la réapparition du vieux démon du "choc de l'intégration".
Nombre d'éléments mentionnés comme candidats à cette itération (performance en environnement de production, support de diverses plateformes, mise à jour de diverses docs) sont étonnament risqués pour n'apparaître qu'à ce moment là.
Par définition, si on arrive près de la release sans les avoir adressés, c'est que le client n'y apporte qu'une importance mineure...

S'ils sont vraiment importants, se cacher derrière une non-automatisation des tests pour ne les faire qu'à la fin ne ferait qu'empirer le problème. Chaque chose à un cout. Si certains éléments sont chers car leur test ne peut pas être automatisé, c'est au client à faire un choix de manière consciente par sa prioritisation et à accepter le cout induit par le besoin (c'est à dire régulièrement passer les tests manuels en question ou une partie d'entre eux pendant le projet sans attendre la dernière minute).

2. Le samedi 10 juin 2006, 23:29 par claude aubry

Oui, à la réflexion la notion d'itération de durcissement n'est pas bonne. La non-automatisation des tests ne justifie pas de repousser à la fin des choses importantes. Et bien souvent la performance est une de ces choses importantes.

En revanche, la dernière itération est tout de même particulière : on ne fait généralement pas les mêmes activités que dans les itérations normales. En effet on n'ajoute plus de fonctionnalités (mais il peut rester des bugs à corriger), mais on y exécute des activités qu'il n'est pas nécessaire de faire avant (ou qu'on ne peut pas faire avant) comme déployer le produit dans l'environnement cible, migrer les données, préparer du matériel (démos, docs) et former les utilisateurs...

La discussion continue ailleurs

1. Le samedi 24 juin 2006, 00:11 par L'Agilitateur

Que fait-on dans la dernière itération ?

Dans un billet récent, Claude Aubry rapporte l'existence de plusieurs articles sur l'agilité dans l'édition de juin 2006 de 'Software Test & Performance'. Un de ces articles, signé Dean Leffingwell,...