Tests et Agilité

Lorsque l’on vous parle d’équipe de test ou de QA, cela vous évoque-t-il des personnes essayant de faire planter le logiciel réalisé pour démontrer à l’équipe de développement qu’elle s’est trompée ?

Si c’est le cas vous êtes dans l’erreur et il serait bon que vous réfléchissiez encore à la situation.

Dans notre culture, le rôle du testeur est généralement dévalué par rapport à celui du développeur (parfois même au niveau du salaire), et pour certains développeurs, le développement de tests est considéré comme une tâche subalterne n’ayant aucun aspect « noble ».

Continuer la lecture de « Tests et Agilité »

Code « fully tested » avec Scrum

Avec un peu de retard (1 petite semaine de vacances en roulotte au bord de la Charente … c’était vraiment super), et en réponse à Bruno et Manu, je rédige un petit article sur ma perception de comment générer du code déployable.

En fait je ne vois qu’une seule solution, et elle est basique, c’est de faire tourner le code sur des serveurs de production (ou similaire) pour s’assurer qu’il est bien déployable.

Sur un de nos anciens projets (abandonnés depuis) nous avions mis en place un test de nuit qui consistait à:

  1. Builder la dernière version (fichiers dans le tronc commun)
  2. Déployer automatiquement le build sur des serveurs de tests,
  3. Jouer un certains nombres de tests de non-régression
  4. Nettoyer le serveur.

Tous les matins, l’équipe avait donc une information sur la « deployabilité » ou non du build généré. Bien entendu, cela nous avait demandé un investissement pour mettre en place cette infrastructure mais on a rien sans rien.

Certains projets en Asie ont mis en place une notion de « Feature Freeze »que je préconise en interne, cela n’a rien à voir avec le Code Freeze qui est une totale abhération et que pourtant je vois encore pratiquée.  Cette notion consiste à figer quelques jours avant la fin du sprint les features qui l’ont considère comme « chippables » (donc DONE) afin d’avoir le temps de jouer quelques tests plus complexes (comme des tests de performance) sur un build stable avant la fin du sprint. Durant cette période, les développeurs peuvent continuer à travailler sur les features restantes afin de respecter leur engagement de début de sprint et de les démontrer en revue de fin, mais elles ne seront pas considérées comme shippable pour ce sprint. Je suis conscient que c’est une entorse à la méthode (pas taper Jeff, pas taper) mais c’est pour l’instant la meilleure solution que j’ai trouvé pour tenir compte des contraintes de la vie réelle.

PS: Joseph, je suis désolé, mais je n’ai pas de solution toute faite pour débuter avec l’agilité, mais un des sites que j’apprécie paticulièrement est le blog de Claude Aubry qui contient beaucoup d’information (y compris la traduction en Français des slides de Mike Cohn de présentation de Scrum).

De l’intérêt des conférences …

Aujourd’hui j’ai eu un moment de pure satisfaction … et cela fait vraiment plaisir.

Cela fait 6 mois que j’incite fortement les collègues à participer à des conférences autour de l’Agilité car je considère que c’est une vraie opportunité pour récolter des idées d’amélioration et partager avec ceux qui ont l’expérience d’avoir vécu des changements Agile réussis.

Pour ma part, comme je vais régulièrement à Londres pour quelques jours, je participe régulièrement à des soirées gratuites d’échanges autour de l’agilité. Je retire toujours beaucoup des ces réunions car elles m’obligent à remettre en question en permanence la façon dont j’aborde l’agilité … « Inspect and Adapt » diront certains 🙂

Donc pour revenir à ce qui s’est passé aujourd’hui, j’ai eu l’occasion de partager le retour d’expérience d’une collègue de l’équipe test qui a participé à la conférence STAREAST en assistant à beaucoup de sessions sur les Tests et l’Agilité. Cette personne contribuait depuis quelques mois à des projets en mode Scrum, mais n’avait pas eu l’opportunité de prendre le recul nécessaire pour analyser les bénéfices réels apportés par cette nouvelle approche.

Son enthousiasme et son envie de partager ses nouvelles convictions faisaient plaisir à voir et je sais que je peux compter sur elle maintenant pour aider d’autres personnes de l’entreprise à, non pas ‘faire de l’agile’ mais à ‘penser agile’ … ce qui est bien l’objectif à atteindre (« Agile is a journey, not a destination »)