SlideShare une entreprise Scribd logo
Chouette! Encore un bug!




     Pascal Van Cauwenberghe
Bonjour

              Consultant.
              Project Manager.
              Créateur de Jeux




NAYIMA
We make play work

www.nayima.be
blog.nayima.be
CLAUSE DE NON-RESPONSABILITÉ
Clause de non-responsabilité (1)
• Cette présentation contient du code
  – Sans garantie que ça compile
• Cette présentation peut contenir 0, 1 ou plus
  insectes
  – A éviter pour les entomophobes
Clause de non-responsabilité (2)
• Basé sur des histoires vraies
  – Equipes différentes
  – Projets différents
  – Langages différents
  – Pays différents
• Chantier en cours
  – Notre code contient encore des bugs
Chouette! Encore un bug!

Comment passer toute la journée
  à corriger un tout petit bug
Maman, d’où viennent les bugs?

         Il était une fois...
Le projet




L’application

Nous
Contexte
•   Grande application web
•   Mission critical
•   Premier projet Agile de l’équipe
•   Nous devons modifier et étendre une petite
    partie de l’application
Scene 1:
un développeur trouve un bug
Chouette! Encore un bug!
Que faites vous quand on vous
 dit “j’ai trouvé un bug...” ?
MERCI!
Algoritme du code parfait
1. TROUVER UN BUG
2. DIRE “MERCI!”
3. ....
Scene 2:
Qu’est-ce qu’on fait avec le bug?
CECI N’EST PAS UN BUG
CECI EST UNE OPPORTUNITE
ASTUCE
• On ne cherche pas à reprocher
• On ne veut pas trouver le “coupable”
• Il faut un environnement sans blâme

• Attention au langage:
  – “Exercice”, “Apprendre”, “Améliorer”
  – “Nous”, “Notre code”, “Notre problème”
• Approche “Solution Focus”
Scene 3:
L’équipe fait une Root Cause Analysis

      5 développeurs + architecte
“Le client a droit à un
remboursement jusqu’au moment
        de la livraison”
Qui voit le problème?
boolean refundAllowed(Product product) {
  Datetime now = Datetime.now;

    Datetime final = Datetime.parse("yyyy-MM-dd“,
    product.deliveryAt());

    return now <= final ;
}
MERCI!
On teste l’application
• Livraison le 26/05/2012 à 16:00
• Il est maintenant 25/05/2012 12:00

• 25/05/2012 12:00 <= 26/05/2012 00:00 ?
On teste l’application
• Livraison le 26/05/2012 à 16:00
• Il est maintenant 25/05/2012 12:00

• 25/05/2012 12:00 <= 26/05/2012 00:00 ?


   Remboursement: OUI
On teste l’application
• Livraison le 25/05/2012 à 16:00
• Il est maintenant 25/05/2012 12:00

• 25/05/2012 12:00 <= 25/05/2012 00:00 ?
On teste l’application
• Livraison le 25/05/2012 à 16:00
• Il est maintenant 25/05/2012 12:00

• 25/05/2012 12:00 <= 25/05/2012 00:00 ?


  Remboursement: NON
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI!”
3.   REPRODUIRE LE PROBLEME
4.   ...
Qu’est-ce qu’on fait maintenant?
  Est-ce qu’on corrige le bug?
        C’est tellement facile!
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI!”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   ...
Un nouveau test
void testRefundGivenWhenDeliveryLaterToday() {
Datetime now = DateTime.now ;
String endofDay = now.strftime(“yyyy-MM-dd")
  + " 23:59" ;
Product product = ...
product.deliveryAt(endOfDay) ;
BusinessRule businessRule = ...
bool refund = businessRule.refundAllowed(product);
assertTrue(refund,“Remboursement jusqu'au moment de
  la livraison, aussi si c'est le même jour") ;
}
Un nouveau test
void testRefundGivenWhenDeliveryLaterToday() {
Datetime now = DateTime.now ;
String endofDay = now.strftime("YYYY-MM-DD")
  + " 23:59" ;
Product product = ...
product.deliveryAt(endOfDay) ;
BusinessRule businessRule = ...
bool refund = businessRule.refundAllowed(product);
assertTrue(refund,“Remboursement jusqu'au moment de
  la livraison, aussi si c'est le même jour") ;
}
Est-ce qu’on peut corriger le bug
          maintenant?
On corrige le bug
boolean refundAllowed(Product product) {
  Datetime now = Datetime.now;

    Datetime final = Datetime.parse("yyyy-MM-dd
    HH:MM”,
    product.deliveryAt());

    return now <= final ;
}
Un nouveau test
void testRefundGivenWhenDeliveryLaterToday() {
Datetime now = DateTime.now ;
String endofDay = now.strftime("YYYY-MM-DD")
  + " 23:59" ;
Product product = ...
product.deliveryAt(endOfDay) ;
BusinessRule businessRule = ...
bool refund = businessRule.refundAllowed(product);
assertTrue(refund,“Remboursement jusqu'au moment de
  la livraison, aussi si c'est le même jour") ;
}
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI!”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS REUSSISSENT
Reactions de l’équipe (1)
• “Ce truc agile prendra beaucoup de temps si
  on va faire ça pour tous les bugs!”
• “Oui mais, on a plus de confiance qu'on a bien
  corrigé le bug en qu'on n'a pas cassé autre
  chose”
• “On a vraiment suivi notre principe ‘qualité
  sans compromis’: on a amélioré le code,
  même si le bug n'est pas dans notre code et
  avant que le client réclame”
Reactions de l’équipe (2)
• “On devrait contacter l'équipe responsable
  pour leur dire qu'on a corrigé le bug.”
• “Il y a peut-être déjà des réclamations des
  clients. Il faudrait aussi informer le service
  support client”
ASTUCE
• Maintenez une liste de choses à faire
  après la Root Cause Analysis (RCA)
• “On devrait...” => “On va...”
ON VA...
• Contacter l’équipe dev responsable
• Informer le service support client
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI!”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS REUSSISSENT
7.   EXECUTER LES ACTIONS ISSUES DU RCA
“Travail bien fait!”



“Retournons au boulot!”
LA FIN
   Et ils vécurent
heureux à tout jamais
Chouette! Encore un bug!
Ce n’est pas encore fini !
Scene 4:
     Après la correction

Le testeur rejoint les développeurs
           et l’architecte
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI!”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS REUSSISSENT
7.   EXECUTER LES ACTION ISSUES DU RCA
8.   AMELIORER LES TESTS
Comment améliorer nos tests?

  On aurait du trouver ce bug plus tôt
Comment améliorer nos tests?

  On aurait du va trouver ce genre de
             bug plus tôt
Contexte (2)
• Presque 80% de code coverage par les tests
  automatiques sur toute l’application

•   Ce module a une couverture de tests de 100%
•   Mais contient quand même un bug
•   Pourquoi?
•   Regardons les tests...
Qui voit le problème?
void testRefundGiven() {
 Product product = ...
 product.deliveryAt(“2050-12-31 19:00”) ;
 BusinessRule businessRule = ...
 bool allowed =
  businessRule.refundAllowed(product)
}
MERCI!
Comment améliorer les tests?
• Il n’y a pas d’ ASSERT !
  – Facile d’atteindre 100% de couverture
• Pourquoi 2050?
  – Qu’est-ce qui se passe le 1 janvier 2051?
• Il faut au moins 4 tests
  – Livraison avant aujourd’hui
  – Livraison aujourd’hui avant maintenant
  – Livraison aujourd’hui après maintenant
  – Livraison après aujourd’hui
Pourquoi?
• Les développeurs ne savent pas comment bien
  tester du code qui contient des dates
  – “2050” apparait souvent dans les tests
• Très peu de développeurs avec experience en
  unit testing
• Pas de formation ou coaching sur les aspects
  techniques Agile
ON VA...
• Contacter l’équipe dev responsable
• Informer le service support client
• Ajouter des tests pour les dates, qui peuvent
  servir comme exemple
• Montrer les exemples aux autres équipes
Reactions de l’équipe (3)
• Développeurs: « on a encore beaucoup à
  apprendre sur le unit testing »
• Architecte: « j'ai toujours eu des doutes au
  sujet de l'efficacité des tests automatiques.
  Maintenant je comprends mieux pourquoi. »
• Testeur: « Si vous voulez, je peux vous aider à
  définir les tests. »
Creusons encore un peu...
    Pourquoi des tests sans ASSERT?
• Peu d’experience en testing
• But: “augmenter la couverture par les tests
  automatiques” au lieu de “augmenter la
  qualité”
• Pression pour livrer des fonctionnalités
• Développement TEST LAST au lieu de TEST
  FIRST
• Pas de formation ou coaching sur les aspects
  techniques Agile
ON VA...
• Contacter l’équipe dev responsable
• Informer le service support client
• Ajouter des tests pour les dates, qui peuvent
  servir comme exemple
• Montrer les exemples aux autres équipes
• Appliquer le TDD en binôme avec le coach
• Ajouter « manque de coaching technique » à
  la liste des risques du coach meeting
Algoritme du code parfait
1.   TROUVER UN BUG
2.   DIRE “MERCI!”
3.   REPRODUIRE LE PROBLEME
4.   AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.   CORRIGER LE PROBLEME
6.   TOUS LES TESTS REUSSISSENT
7.   EXECUTER LES ACTION ISSUES DU RCA
8.   AMELIORER LES TESTS
9.   AMELIORER LA FACON D’ECRIRE LES TESTS
Chouette! Encore un bug!
LA FIN
          Et ils vécurent
       heureux à tout jamais

“On a encore beaucoup à apprendre”
Chouette! Encore un bug!
Ce n’est pas encore fini !
Scene 5:
      Après les tests

Un bug ne vient jamais tout seul
Est-ce que ce bug est unique?
On cherche dans le code...
• On trouve 10 instances où on parse cette date
  – 5 fois avec HH:MM
  – 5 fois sans HH:MM
• Chacun analyse un cas
• Resultat: encore deux bugs
Qu’est-ce que vous dites?
MERCI!
Encore une fois
MERCI!
Algoritme du code parfait
1. TROUVER UN BUG
2. DIRE “MERCI!”
3. REPRODUIRE LE PROBLEME
4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5. CORRIGER LE PROBLEME
6. TOUS LES TESTS REUSSISSENT
7. EXECUTER LES ACTION ISSUES DU RCA
8. AMELIORER LES TESTS
9. AMELIORER LA FACON D’ECRIRE LES TESTS
10. DES PROBLEMES SIMILAIRES? GOTO 2
Chouette! Encore un bug!
Reactions de l’équipe (4)
• “Qualité sans compromis”. C’est facile à dire
  mais très dur à implementer
• “Ecrire les tests et corriger les problèmes
  devient de plus en plus de la routine. Ca va de
  plus en plus vite!”
ENFIN, LA FIN?
Ce n’est pas encore fini !
Est-ce que vous voyez encore un
           problème?
Creusons encore un peu...
 Pourquoi est-ce qu’on s’est trompé?
• On ne se rend pas compte qu’il y a une date +
  temps
• On a 10x le même code
• => 10 opportunités de se tromper

• Eliminons la duplication
Améliorer Product
class Product {
...
  // A enlever quand obsolète
  String deliveryAt() ;
  // Nouveau. Refactoring graduel des
  clients
  DateTime deliveryAtDateTime() ;
...
}
Algoritme du code parfait
1.    TROUVER UN BUG
2.    DIRE “MERCI!”
3.    REPRODUIRE LE PROBLEME
4.    AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.    CORRIGER LE PROBLEME
6.    TOUS LES TESTS REUSSISSENT
7.    EXECUTER LES ACTION ISSUES DU RCA
8.    AMELIORER LES TESTS
9.    AMELIORER LA FACON D’ECRIRE LES TESTS
10.   RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2
11.   RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
ASTUCE
• Si vous pensez qu’il faut écrire du
  commentaire pour votre code, repensez
  votre code
Avec commentaire
class A {
  void methodeA() ;
  // Il faut d’abord appeler methode A
  void methodeB() ;
  void methodeC() ;
}
...
a.methodeB() ; // ERREUR
a.methodeA() ; // ERREUR!!
Sans commentaire
class A {
  B methodeA() ;
}

class B {
  void methodeB() ;
  void methodeC() ;
}

a.methodeA().methodeB() ;
Maman, d’où viennent les
       strings?
   Creusons encore un peu...
Le projet
                                    ABCDEFGHIJKLMNO


   ABCDEFGHIJKLMNO
                                                      Systeme A

ABCDEFGHIJKLMNO
                  ABCDEFGHIJKLMNO


L’application
            ABCDEFGHIJKLMNO
   ABCDEFGHIJKLMNO
        ABCDEFGHIJKLMNO             ABCDEFGHIJKLMNO

                                                       Systeme B
Chouette! Encore un bug!
Le projet (vision)
                ABCDEFGHIJKLMNO

                                    Systeme A




L’application
                  ABCDEFGHIJKLMNO


                                     Systeme B
Chouette! Encore un bug!
ON VA...
• Contacter l’équipe dev responsable
• Informer le service support client
• Ajouter des tests pour les dates, qui peuvent
  servir comme exemple
• Montrer les exemples aux autres équipes
• Appliquer le TDD en binôme avec le coach
• Ajouter « manque de coaching technique » à la
  liste des risques du coach meeting
• Encapsuler toutes les données qui viennent de
  l’exterieur
GRAND REFACTORING
Chouette! Encore un bug!
Proposition A3
Proposition A3
          Description du problème
AVANT                     APRES




Etapes:                   Visualisation
1. .jdlkjds
2. Kmlkdmlkd
3. Dkqjdlkjds
4. Sqkjlkdlksqmk
5. BIERE !
ASTUCE
• L’A3 est visible pendant toute la période
  de refactoring
• Affichez l’A3 là où on ne peut pas le
  louper
• Limitez le nombre d’A3 qu’on peut
  afficher
Scene 6:
Acte final
Résultats
1. On a travaillé tout l’après-midi avec une équipe de 7
   personnes + un consultant pour corriger un bug de 6
   caractères. Est-ce raisonnable?
2. On a trouvé beaucoup moins de bugs en test que
   dans des projets “normaux”. Est-ce qu’il y a un lien?
3. Ceci a soulagé le travail de l’équipe test, goulot
   d’étranglement du projet. Est-ce qu’il faut économiser
   sur l’effort d’une équipe non-goulot?
4. Le projet a été livré en 5 mois au lieu des 8 estimés.
   Est-ce que la qualité coute cher?
En résumé
Algoritme du code parfait
1.    TROUVER UN BUG
2.    DIRE “MERCI!”
3.    REPRODUIRE LE PROBLEME
4.    AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5.    CORRIGER LE PROBLEME
6.    TOUS LES TESTS REUSSISSENT
7.    EXECUTER LES ACTION ISSUES DU RCA
8.    AMELIORER LES TESTS
9.    AMELIORER LA FACON D’ECRIRE LES TESTS
10.   RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2
11.   RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
Mais surtout
MERCI!
Le challenge
•   J’applique ceci avec mes équipes
•   On est loin du code parfait...
•   Je mesure les effets pendant un an
•   Je présente les résultats à la Conférence 2013
•   Si vous appliquez ces techniques
•   Contactez-moi
•   On présente nos résultats ensemble
CECI EST UNE OPPORTUNITE
LA FIN
   Et ils vécurent
heureux à tout jamais
7/7 SESSION FEEDBACK
MERCI

               Consultant.
               Project Manager.
               Créateur de Jeux




NAYIMA
We make play work

His Blog: blog.nayima.be
Chouette! Encore un bug!

Contenu connexe

En vedette

Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013
AgileCoach.net
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013
AgileCoach.net
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation Games
AgileCoach.net
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business value
AgileCoach.net
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinking
AgileCoach.net
 
Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestion
AgileCoach.net
 
Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010
AgileCoach.net
 
Bug Bounty Secrets
Bug Bounty Secrets Bug Bounty Secrets
Présentation Bug Busters
Présentation Bug BustersPrésentation Bug Busters
Présentation Bug Busters
Bug Busters
 
Bug, un "objet" du numérique
Bug, un "objet" du numériqueBug, un "objet" du numérique
Bug, un "objet" du numérique
Régis Chatellier
 
Real Options - Agile France 2013
Real Options - Agile France 2013Real Options - Agile France 2013
Real Options - Agile France 2013
AgileCoach.net
 
Bug Bounty 101
Bug Bounty 101Bug Bounty 101
Bug Bounty 101
Shahee Mirza
 
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013
AgileCoach.net
 
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisionsDevoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
AgileCoach.net
 
Bug Bounty Hunter Methodology - Nullcon 2016
Bug Bounty Hunter Methodology - Nullcon 2016Bug Bounty Hunter Methodology - Nullcon 2016
Bug Bounty Hunter Methodology - Nullcon 2016
bugcrowd
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - French
AgileCoach.net
 
Python debugger
Python debuggerPython debugger
Python debugger
Damien Garaud
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorial
AgileCoach.net
 
Business Value of Agile Methods: Using Return on Investment
Business Value of Agile Methods: Using Return on InvestmentBusiness Value of Agile Methods: Using Return on Investment
Business Value of Agile Methods: Using Return on Investment
David Rico
 
Great! another bug
Great! another bugGreat! another bug
Great! another bug
AgileCoach.net
 

En vedette (20)

Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation Games
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business value
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinking
 
Vous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestionVous pouvez ignorerr les controleurs de gestion
Vous pouvez ignorerr les controleurs de gestion
 
Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010Lean out your backlog - Lean and Kanban Belgium 2010
Lean out your backlog - Lean and Kanban Belgium 2010
 
Bug Bounty Secrets
Bug Bounty Secrets Bug Bounty Secrets
Bug Bounty Secrets
 
Présentation Bug Busters
Présentation Bug BustersPrésentation Bug Busters
Présentation Bug Busters
 
Bug, un "objet" du numérique
Bug, un "objet" du numériqueBug, un "objet" du numérique
Bug, un "objet" du numérique
 
Real Options - Agile France 2013
Real Options - Agile France 2013Real Options - Agile France 2013
Real Options - Agile France 2013
 
Bug Bounty 101
Bug Bounty 101Bug Bounty 101
Bug Bounty 101
 
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013
 
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisionsDevoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
Devoxx fr 2013 Real Options - Comment et Quand (ne pas) prendre des décisions
 
Bug Bounty Hunter Methodology - Nullcon 2016
Bug Bounty Hunter Methodology - Nullcon 2016Bug Bounty Hunter Methodology - Nullcon 2016
Bug Bounty Hunter Methodology - Nullcon 2016
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - French
 
Python debugger
Python debuggerPython debugger
Python debugger
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorial
 
Business Value of Agile Methods: Using Return on Investment
Business Value of Agile Methods: Using Return on InvestmentBusiness Value of Agile Methods: Using Return on Investment
Business Value of Agile Methods: Using Return on Investment
 
Great! another bug
Great! another bugGreat! another bug
Great! another bug
 

Similaire à Chouette! Encore un bug!

Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
Frederic Hardy
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
CGI Québec Formation
 
Techdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continuTechdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continu
vlabatut
 
La qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesLa qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitaires
Gauthier Delamarre
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
Christophe Rochefolle
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
Djamel Zouaoui
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
Thierry Gayet
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
Christophe Villeneuve
 
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads France
 
The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014
Matthieu de Canteloube
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
Cyrille Grandval
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
martinsson
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
French Scrum User Group
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
Geeks Anonymes
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration Continue
Normandy JUG
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Agile Tour 2009 Québec
 
Lightning talk meetup SWC : Pyramide des tests - épisode 2
Lightning talk meetup SWC : Pyramide des tests - épisode 2Lightning talk meetup SWC : Pyramide des tests - épisode 2
Lightning talk meetup SWC : Pyramide des tests - épisode 2
Damien Beaufils
 
AFUP Day 2020 Nantes - Mutation Testing
AFUP Day 2020 Nantes - Mutation TestingAFUP Day 2020 Nantes - Mutation Testing
AFUP Day 2020 Nantes - Mutation Testing
Julien Braure
 
Lean IT : Pourquoi l informatique a besoin du lean !
Lean IT : Pourquoi l informatique a besoin du lean !Lean IT : Pourquoi l informatique a besoin du lean !
Lean IT : Pourquoi l informatique a besoin du lean !
Operae Partners
 

Similaire à Chouette! Encore un bug! (20)

Anatomie du test
Anatomie du testAnatomie du test
Anatomie du test
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
Techdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continuTechdays 2013 : ALM et eCommerce, des challenges en continu
Techdays 2013 : ALM et eCommerce, des challenges en continu
 
La qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitairesLa qualité au meilleur prix grâce aux tests unitaires
La qualité au meilleur prix grâce aux tests unitaires
 
Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Présentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisésPrésentation Alt.net - Tests unitaires automatisés
Présentation Alt.net - Tests unitaires automatisés
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
Valider par des tests - Blend
Valider par des tests - BlendValider par des tests - Blend
Valider par des tests - Blend
 
CocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - EpitezCocoaHeads Toulouse - Xcode et les tests - Epitez
CocoaHeads Toulouse - Xcode et les tests - Epitez
 
The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014The DevOps Wonder @ PHPTour Lyon 2014
The DevOps Wonder @ PHPTour Lyon 2014
 
Les tests-unitaires-en-java
Les tests-unitaires-en-javaLes tests-unitaires-en-java
Les tests-unitaires-en-java
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
 
Une architecture agile et testable
Une architecture agile et testableUne architecture agile et testable
Une architecture agile et testable
 
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
TDD/BDD: ou comment j’ai appris à ne plus m’en faire avec les tests (et la doc)
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
AT2010 Principes Integration Continue
AT2010 Principes Integration ContinueAT2010 Principes Integration Continue
AT2010 Principes Integration Continue
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
Lightning talk meetup SWC : Pyramide des tests - épisode 2
Lightning talk meetup SWC : Pyramide des tests - épisode 2Lightning talk meetup SWC : Pyramide des tests - épisode 2
Lightning talk meetup SWC : Pyramide des tests - épisode 2
 
AFUP Day 2020 Nantes - Mutation Testing
AFUP Day 2020 Nantes - Mutation TestingAFUP Day 2020 Nantes - Mutation Testing
AFUP Day 2020 Nantes - Mutation Testing
 
Lean IT : Pourquoi l informatique a besoin du lean !
Lean IT : Pourquoi l informatique a besoin du lean !Lean IT : Pourquoi l informatique a besoin du lean !
Lean IT : Pourquoi l informatique a besoin du lean !
 

Chouette! Encore un bug!

  • 1. Chouette! Encore un bug! Pascal Van Cauwenberghe
  • 2. Bonjour Consultant. Project Manager. Créateur de Jeux NAYIMA We make play work www.nayima.be blog.nayima.be
  • 4. Clause de non-responsabilité (1) • Cette présentation contient du code – Sans garantie que ça compile • Cette présentation peut contenir 0, 1 ou plus insectes – A éviter pour les entomophobes
  • 5. Clause de non-responsabilité (2) • Basé sur des histoires vraies – Equipes différentes – Projets différents – Langages différents – Pays différents • Chantier en cours – Notre code contient encore des bugs
  • 6. Chouette! Encore un bug! Comment passer toute la journée à corriger un tout petit bug
  • 7. Maman, d’où viennent les bugs? Il était une fois...
  • 9. Contexte • Grande application web • Mission critical • Premier projet Agile de l’équipe • Nous devons modifier et étendre une petite partie de l’application
  • 10. Scene 1: un développeur trouve un bug
  • 12. Que faites vous quand on vous dit “j’ai trouvé un bug...” ?
  • 14. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. ....
  • 15. Scene 2: Qu’est-ce qu’on fait avec le bug?
  • 17. CECI EST UNE OPPORTUNITE
  • 18. ASTUCE • On ne cherche pas à reprocher • On ne veut pas trouver le “coupable” • Il faut un environnement sans blâme • Attention au langage: – “Exercice”, “Apprendre”, “Améliorer” – “Nous”, “Notre code”, “Notre problème” • Approche “Solution Focus”
  • 19. Scene 3: L’équipe fait une Root Cause Analysis 5 développeurs + architecte
  • 20. “Le client a droit à un remboursement jusqu’au moment de la livraison”
  • 21. Qui voit le problème? boolean refundAllowed(Product product) { Datetime now = Datetime.now; Datetime final = Datetime.parse("yyyy-MM-dd“, product.deliveryAt()); return now <= final ; }
  • 23. On teste l’application • Livraison le 26/05/2012 à 16:00 • Il est maintenant 25/05/2012 12:00 • 25/05/2012 12:00 <= 26/05/2012 00:00 ?
  • 24. On teste l’application • Livraison le 26/05/2012 à 16:00 • Il est maintenant 25/05/2012 12:00 • 25/05/2012 12:00 <= 26/05/2012 00:00 ? Remboursement: OUI
  • 25. On teste l’application • Livraison le 25/05/2012 à 16:00 • Il est maintenant 25/05/2012 12:00 • 25/05/2012 12:00 <= 25/05/2012 00:00 ?
  • 26. On teste l’application • Livraison le 25/05/2012 à 16:00 • Il est maintenant 25/05/2012 12:00 • 25/05/2012 12:00 <= 25/05/2012 00:00 ? Remboursement: NON
  • 27. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. ...
  • 28. Qu’est-ce qu’on fait maintenant? Est-ce qu’on corrige le bug? C’est tellement facile!
  • 29. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. ...
  • 30. Un nouveau test void testRefundGivenWhenDeliveryLaterToday() { Datetime now = DateTime.now ; String endofDay = now.strftime(“yyyy-MM-dd") + " 23:59" ; Product product = ... product.deliveryAt(endOfDay) ; BusinessRule businessRule = ... bool refund = businessRule.refundAllowed(product); assertTrue(refund,“Remboursement jusqu'au moment de la livraison, aussi si c'est le même jour") ; }
  • 31. Un nouveau test void testRefundGivenWhenDeliveryLaterToday() { Datetime now = DateTime.now ; String endofDay = now.strftime("YYYY-MM-DD") + " 23:59" ; Product product = ... product.deliveryAt(endOfDay) ; BusinessRule businessRule = ... bool refund = businessRule.refundAllowed(product); assertTrue(refund,“Remboursement jusqu'au moment de la livraison, aussi si c'est le même jour") ; }
  • 32. Est-ce qu’on peut corriger le bug maintenant?
  • 33. On corrige le bug boolean refundAllowed(Product product) { Datetime now = Datetime.now; Datetime final = Datetime.parse("yyyy-MM-dd HH:MM”, product.deliveryAt()); return now <= final ; }
  • 34. Un nouveau test void testRefundGivenWhenDeliveryLaterToday() { Datetime now = DateTime.now ; String endofDay = now.strftime("YYYY-MM-DD") + " 23:59" ; Product product = ... product.deliveryAt(endOfDay) ; BusinessRule businessRule = ... bool refund = businessRule.refundAllowed(product); assertTrue(refund,“Remboursement jusqu'au moment de la livraison, aussi si c'est le même jour") ; }
  • 35. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT
  • 36. Reactions de l’équipe (1) • “Ce truc agile prendra beaucoup de temps si on va faire ça pour tous les bugs!” • “Oui mais, on a plus de confiance qu'on a bien corrigé le bug en qu'on n'a pas cassé autre chose” • “On a vraiment suivi notre principe ‘qualité sans compromis’: on a amélioré le code, même si le bug n'est pas dans notre code et avant que le client réclame”
  • 37. Reactions de l’équipe (2) • “On devrait contacter l'équipe responsable pour leur dire qu'on a corrigé le bug.” • “Il y a peut-être déjà des réclamations des clients. Il faudrait aussi informer le service support client”
  • 38. ASTUCE • Maintenez une liste de choses à faire après la Root Cause Analysis (RCA) • “On devrait...” => “On va...”
  • 39. ON VA... • Contacter l’équipe dev responsable • Informer le service support client
  • 40. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT 7. EXECUTER LES ACTIONS ISSUES DU RCA
  • 42. LA FIN Et ils vécurent heureux à tout jamais
  • 44. Ce n’est pas encore fini !
  • 45. Scene 4: Après la correction Le testeur rejoint les développeurs et l’architecte
  • 46. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT 7. EXECUTER LES ACTION ISSUES DU RCA 8. AMELIORER LES TESTS
  • 47. Comment améliorer nos tests? On aurait du trouver ce bug plus tôt
  • 48. Comment améliorer nos tests? On aurait du va trouver ce genre de bug plus tôt
  • 49. Contexte (2) • Presque 80% de code coverage par les tests automatiques sur toute l’application • Ce module a une couverture de tests de 100% • Mais contient quand même un bug • Pourquoi? • Regardons les tests...
  • 50. Qui voit le problème? void testRefundGiven() { Product product = ... product.deliveryAt(“2050-12-31 19:00”) ; BusinessRule businessRule = ... bool allowed = businessRule.refundAllowed(product) }
  • 52. Comment améliorer les tests? • Il n’y a pas d’ ASSERT ! – Facile d’atteindre 100% de couverture • Pourquoi 2050? – Qu’est-ce qui se passe le 1 janvier 2051? • Il faut au moins 4 tests – Livraison avant aujourd’hui – Livraison aujourd’hui avant maintenant – Livraison aujourd’hui après maintenant – Livraison après aujourd’hui
  • 53. Pourquoi? • Les développeurs ne savent pas comment bien tester du code qui contient des dates – “2050” apparait souvent dans les tests • Très peu de développeurs avec experience en unit testing • Pas de formation ou coaching sur les aspects techniques Agile
  • 54. ON VA... • Contacter l’équipe dev responsable • Informer le service support client • Ajouter des tests pour les dates, qui peuvent servir comme exemple • Montrer les exemples aux autres équipes
  • 55. Reactions de l’équipe (3) • Développeurs: « on a encore beaucoup à apprendre sur le unit testing » • Architecte: « j'ai toujours eu des doutes au sujet de l'efficacité des tests automatiques. Maintenant je comprends mieux pourquoi. » • Testeur: « Si vous voulez, je peux vous aider à définir les tests. »
  • 56. Creusons encore un peu... Pourquoi des tests sans ASSERT? • Peu d’experience en testing • But: “augmenter la couverture par les tests automatiques” au lieu de “augmenter la qualité” • Pression pour livrer des fonctionnalités • Développement TEST LAST au lieu de TEST FIRST • Pas de formation ou coaching sur les aspects techniques Agile
  • 57. ON VA... • Contacter l’équipe dev responsable • Informer le service support client • Ajouter des tests pour les dates, qui peuvent servir comme exemple • Montrer les exemples aux autres équipes • Appliquer le TDD en binôme avec le coach • Ajouter « manque de coaching technique » à la liste des risques du coach meeting
  • 58. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT 7. EXECUTER LES ACTION ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS
  • 60. LA FIN Et ils vécurent heureux à tout jamais “On a encore beaucoup à apprendre”
  • 62. Ce n’est pas encore fini !
  • 63. Scene 5: Après les tests Un bug ne vient jamais tout seul
  • 64. Est-ce que ce bug est unique?
  • 65. On cherche dans le code... • On trouve 10 instances où on parse cette date – 5 fois avec HH:MM – 5 fois sans HH:MM • Chacun analyse un cas • Resultat: encore deux bugs
  • 70. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT 7. EXECUTER LES ACTION ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. DES PROBLEMES SIMILAIRES? GOTO 2
  • 72. Reactions de l’équipe (4) • “Qualité sans compromis”. C’est facile à dire mais très dur à implementer • “Ecrire les tests et corriger les problèmes devient de plus en plus de la routine. Ca va de plus en plus vite!”
  • 74. Ce n’est pas encore fini !
  • 75. Est-ce que vous voyez encore un problème?
  • 76. Creusons encore un peu... Pourquoi est-ce qu’on s’est trompé? • On ne se rend pas compte qu’il y a une date + temps • On a 10x le même code • => 10 opportunités de se tromper • Eliminons la duplication
  • 77. Améliorer Product class Product { ... // A enlever quand obsolète String deliveryAt() ; // Nouveau. Refactoring graduel des clients DateTime deliveryAtDateTime() ; ... }
  • 78. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT 7. EXECUTER LES ACTION ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2 11. RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
  • 79. ASTUCE • Si vous pensez qu’il faut écrire du commentaire pour votre code, repensez votre code
  • 80. Avec commentaire class A { void methodeA() ; // Il faut d’abord appeler methode A void methodeB() ; void methodeC() ; } ... a.methodeB() ; // ERREUR a.methodeA() ; // ERREUR!!
  • 81. Sans commentaire class A { B methodeA() ; } class B { void methodeB() ; void methodeC() ; } a.methodeA().methodeB() ;
  • 82. Maman, d’où viennent les strings? Creusons encore un peu...
  • 83. Le projet ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO Systeme A ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO L’application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO Systeme B
  • 85. Le projet (vision) ABCDEFGHIJKLMNO Systeme A L’application ABCDEFGHIJKLMNO Systeme B
  • 87. ON VA... • Contacter l’équipe dev responsable • Informer le service support client • Ajouter des tests pour les dates, qui peuvent servir comme exemple • Montrer les exemples aux autres équipes • Appliquer le TDD en binôme avec le coach • Ajouter « manque de coaching technique » à la liste des risques du coach meeting • Encapsuler toutes les données qui viennent de l’exterieur
  • 91. Proposition A3 Description du problème AVANT APRES Etapes: Visualisation 1. .jdlkjds 2. Kmlkdmlkd 3. Dkqjdlkjds 4. Sqkjlkdlksqmk 5. BIERE !
  • 92. ASTUCE • L’A3 est visible pendant toute la période de refactoring • Affichez l’A3 là où on ne peut pas le louper • Limitez le nombre d’A3 qu’on peut afficher
  • 94. Résultats 1. On a travaillé tout l’après-midi avec une équipe de 7 personnes + un consultant pour corriger un bug de 6 caractères. Est-ce raisonnable? 2. On a trouvé beaucoup moins de bugs en test que dans des projets “normaux”. Est-ce qu’il y a un lien? 3. Ceci a soulagé le travail de l’équipe test, goulot d’étranglement du projet. Est-ce qu’il faut économiser sur l’effort d’une équipe non-goulot? 4. Le projet a été livré en 5 mois au lieu des 8 estimés. Est-ce que la qualité coute cher?
  • 96. Algoritme du code parfait 1. TROUVER UN BUG 2. DIRE “MERCI!” 3. REPRODUIRE LE PROBLEME 4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE 5. CORRIGER LE PROBLEME 6. TOUS LES TESTS REUSSISSENT 7. EXECUTER LES ACTION ISSUES DU RCA 8. AMELIORER LES TESTS 9. AMELIORER LA FACON D’ECRIRE LES TESTS 10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2 11. RENDRE IMPOSSIBLE DE REFAIRE LA MEME ERREUR
  • 99. Le challenge • J’applique ceci avec mes équipes • On est loin du code parfait... • Je mesure les effets pendant un an • Je présente les résultats à la Conférence 2013 • Si vous appliquez ces techniques • Contactez-moi • On présente nos résultats ensemble
  • 100. CECI EST UNE OPPORTUNITE
  • 101. LA FIN Et ils vécurent heureux à tout jamais
  • 103. MERCI Consultant. Project Manager. Créateur de Jeux NAYIMA We make play work His Blog: blog.nayima.be

Notes de l'éditeur

  1. Portia and Pascal introduce themselves by sharing a bit about their background.
  2. Portia and Pascal introduce themselves by sharing a bit about their background.