Tests Agile Grenoble 2011

Cette page à pour objectif de préparer la session Tests Agiles à Grenoble  du 19 Mais 2011.
Cette session sera animé par le CARA de Lyon et Johan à Grenoble.

Horaire : 19h à 20h30
Lieu : ENSIMAG sur le campus de Saint Martin d’Hères – Batiment H – Salles D111+D117

Diapositives de la soirée

Introduction (5', Nicolas)

Historique & Approche classique (10', Nicolas)

Historique rapide Génie logiciel & façon de concevoir des softs

En 1968, formalisation du "Génie logiciel" en réponse à la crise du logiciel:
Le prix du hard diminue, celui du soft augmente avec sa complexité
On s’aperçoit que la qualité des softs laisse à désirer:
=> Pas livrés à temps
=> coutent plus cher que prévu
=> peu fiables / performants
=> Chers à maintenir

On applique les méthodes connues de production au logiciel => méthodes "classiques" cycle en V, Waterfall...
3 points à améliorer

* Décorrélation des tests du besoin client, du dev
Effet tunnel...

On lance le dev a partir d'un beau cahier de specs et de test
on dev
on dev
on dev...
on a fini, on envoie tout à la QA et on se rend compte qu'on a des problèmes (besoin couverts ? / qualité de l'appli ? / Bugs ?)

* Focus mis sur la doc et pas sur la communication ou e produit
On se concentre sur une doc exhaustive et on la fait passer l'équipe en equipe au fur et à mesure
=> lourd
=> perte de temps à chaque changement de lecteur
=> gestion des corrections...
=> utile ?

* Rôle de la QA
Quand la QA est responsable de la qualité du produit
=> Position de "dernier rempart" (ie protège le client d'une release trop bugguée)
=> tensions avec le dev, avec les clients...

Coût d'un bug (5', Nicolas)

Détail des sources de coût
   - Détection 
      Td = (Origine du bug - Détection du bug) ; impact / propagation du bug dépendant de Td...
      Interruption de service
   - Rémontée & communication : temps client et temps support
   - Compréhension Ti = (1' à ... l'infini ?) : temps R&D
   - Résolution : temps R&D
         - Hors contexte - contournement Thc = (Solution + Intégration + Livraison)
         - Dans le contexte - correction Tc = (Remise en contexte + Correction + Intégration + Livraison)
   - Estimation du coût d'un bug sorti dans une version (prix support, prix chez le client).

(Avoir en tête le débat sur le Cost of Change : Barry Boehm, Kent Beck... Le délai de la boucle de détection de la non qualité est critique http://www.ambysoft.com/essays/whyAgileWorksFeedback.html
   - Quelles conclusions tirer de la courbe de Cost of Change ? Emphase sur les phases amont vs Emphase sur la granularité ?
   - Quelle est la pente de mon Cost of Change ?)

The Economic Impacts of Inadequate Infrastructure for Software Testing http://www.cse.lehigh.edu/~gtan/bug/localCopies/nistReport.pdf

En résumé : 
   - Le temps est votre ennemi
   - Tout est question de granularité :
      o Granularité des tests dans le temps
      o Granularité de l'architecture
      o Granularité des versions
      o Granularité de l'environnement
   - Des choix et des compromis sont nécessaires

Testing agile / Brian Marick's test categorisation (5', Nicolas)

Présentation de ce carré en faisant référence au  livre Agile testing.

* Agile testing Quadrant
Brian Marick (expert test /qualité, signataire du manifeste agile)
=> Répertorier les différents types de tests.

* Team Support
=> qualité interne du soft
Q1: Diminuer ou au moins mesurer la dette technique Automatisable (TDD...)
Q2: Tests fonctionnels au niveau feature, qualité visible de l'appli => automatisable (selenium...cucumber...)

* Critique du produit
Q3: Efficacité / adaptation du soft aux besoins (démos, exploratory testing...)
Q4 Aspects moins visibles mais nécéssaires (sécu/ergonomie, perfs...

=> critique au sens positif !

*Conclusion
=> checklist utile pr l'equipe
=> permet de positionner sa stratégie de test

Apports de l'agilité (5', Nicolas)

Slide 2 : Tests en agilité
Retours sur les principes agiles et mise en application
  • QA & Dev travaillent ensemble pour arriver au Done (on favorise le dialogue entre les teams plutôt que le process)
  • On fait des releases régulières en essayant de:
    • Tester au plus tot => TDD
    • Tester plus vite => Automatisation des tests
    • Tester plus souvent => Intégration continue
    • + faciliter le refactoring (revue de code, analyse de code, non-regression & couverture des TU)
  • Rôle de "service provider"
    • Collaboration avec les devs pour améliorer la testabilité
    • Boucles d'interaction courtes avec les devs (tests de petites features
    • Automatisation de tout ce qu'on peut (tests regression, Unit test, livraison)
    • Impliquer les clients dans l'écriture des tests d'acceptance.
    • Tester ce qui est important (Priorisation des test, Risk Based Testing?)
Sources:
http://www.slideshare.net/jubehr/prsentation-agile-testing
http://www.agilistas.org/presentations/pycon05/
 

Pourquoi faut-il soigner sa pyramide de tests (10', Johan Martinsson)
  • La pyramide de tests :
    • Les tests haut niveau
      • grosse confiance
      • mais combinatoire, lenteur d'exécution, long à débugger, dommages collateraux
      • Coût de maintenance : "exponentiel"
      • Impossible d'aller très loin dans l'élimination des défauts
      • "Trop de tests?" => oui c'est possible
    • Les tests unitaires
      • Une classe en isolation
      • Ne donne pas une confiance total (assemblage, niveau sémantique)
      • Mais, coût de maintenance constant!
    • Conclusion : "soigner sa pyramide" permet d'aller très loin dans l'élimination des défauts
 Divers
Indicateurs de qualité agiles (20'/30' ?, Sylvain)
  • La vision "Tester juste"
    • Tester coûte cher
    • Inconvénients de l'automatisation
    • Difficulté d'obtenir une bonne vision de la pertinence de ses tests
    • Prioriser ses tests
  • La vision "Tester juste" appliquée aux tests unitaires
    • Inconvénients du TDD (Test Driven Development)
    • Cibler ses tests unitaires
    • Le mirage des mesures brutes de "coverage"
  • La vision "Tester juste" appliquée aux tests fonctionnels
    • Quelle stratégie de tests pour tester les nouveaux développements et éviter les non-régressions ?
    • Cibler les modifications
    • Mesurer le périmètre de code testé
    • Lien avec les tests unitaires
  • Les spécificité d'un projet Agile
    • Risques de certaines techniques de développement (e.g. refactoring)
    • Adaptabilité à l'évolution des besoins / risques de régression
    • Relation développeur-testeur
    • Rythme de livraison
    • Indicateur de DONE
     

Quelle réponse apporte l'Agilité  + Débat ? (10', Tous)

Diagramme du process Agile et indicateurs qui poussent à faire des tests en début de spec / de dev, pour minimiser les coûts.
Bonne pratiques: revue de code, intégration continue
Voir les points ici : http://www.ambysoft.com/essays/agileTesting.html




Références

The Economic Impacts of Inadequate Infrastructure for Software Testing http://www.cse.lehigh.edu/~gtan/bug/localCopies/nistReport.pdf
What does it cost you to fix a defect ? And why you should care ? http://www.jrothman.com/Papers/Costtofixdefect.html
Tips to encourage collaborative testing    http://blog.testyredhead.com/
Test-Driven Development Is Not About Testing http://java.sys-con.com/node/37795
Test-driven Development Is Not About Testing http://parlezuml.com/blog/?postid=517
How test-driven development works (and more!) http://blog.jbrains.ca/permalink/how-test-driven-development-works-and-more
TDD is not test-first. TDD is specify-first and test-last. http://blog.orfjackal.net/2009/10/tdd-is-not-test-first-tdd-is-specify.html
TDD en video : http://jamesshore.com/Blog/Lets-Play/
Retour de l'échange AAFTT par Elizabeth Hendrickson http://www.infoq.com/interviews/elizabeth-hendrickson-aaftt
Elle dit qu'il n'y a pas de wiki pour l'instant, mais qu'il y a un groupe Yahoo http://tech.groups.yahoo.com/group/aa-ftt/

Autres sujets

Actualités du mois :
    - Agenda de l'agilité : http://www.agenda-agile.org
    - Agile Grenoble 2010, le programme des sessions : http://agile-grenoble.org/programme
    - Demie-Journée Agile à Lyon en 2011 : Une utopie ?




Voici les présentations de la soirée


Comments