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

3. CLAUSE DE NON-RESPONSABILITÉ

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...

8. Le projet
L’application
Nous

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...” ?

13. MERCI!

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?

16. CECI N’EST PAS UN 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 ;
}

22. MERCI!

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

41. “Travail bien fait!”
“Retournons au boulot!”

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)
}

51. MERCI!

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

66. Qu’est-ce que vous dites?

67. MERCI!

68. Encore une fois

69. MERCI!

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!”

73. ENFIN, LA FIN?

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

88. GRAND REFACTORING

90. Proposition A3

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

93. Scene 6:
Acte final

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?

95. En résumé

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

97. Mais surtout

98. MERCI!

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

102. 7/7 SESSION FEEDBACK

103. MERCI
Consultant.
Project Manager.
Créateur de Jeux
NAYIMA
We make play work
His Blog: blog.nayima.be