4. Clause de non-responsabilité
• Cette présentation contient du code
– Sans garantie que ça compile
• Cette présentation contient des insectes
– A éviter pour les entomophobes
5. Based on true stories
• In different countries
• In different projects
• With different teams
• Using different (programming) languages
6. Chouette! Encore un bug!
Comment passer toute la journée à
corriger un tout petit bug
9. Contexte
• Société globale
• Grande application web
• Mission critical, 24/7
• Majeure source de revenue
• Premier projet Agile de l’équipe
• Je les accompagne comme coach
• Nous devons modifier et étendre une petite
partie de l’application
24. On teste l’application
• Livraison le 23/11/2012 à 16:00
• Il est maintenant 22/11/2012 17:45
• 22/11/2012 17:45 <= 23/11/2012 00:00 ?
25. Let’s test the application
• Livraison le 23/11/2012 à 16:00
• Il est maintenant 22/11/2012 17:45
• 22/11/2012 17:45 <= 23/11/2012 00:00 ?
Remboursement? OUI
26. On teste l’application
• Livraison le 22/11/2012 à 20:00
• Il est maintenant 22/11/2012 17:45
• 22/11/2012 17:45 <= 22/11/2012 00:00 ?
27. Let’s test the application
• Livraison le 22/11/2012 à 20:00
• Il est maintenant 22/11/2012 17:45
• 22/11/2012 17:45 <= 22/11/2012 00:00 ?
Remboursement? NON
28. Algoritme du code parfait
1. TROUVER UN BUG
2. DIRE “MERCI !”
3. REPRODUIRE LE PROBLEME
4. ...
30. Algoritme du code parfait
1. TROUVER UN BUG
2. DIRE “MERCI !”
3. REPRODUIRE LE PROBLEME
4. AJOUTER (AU MOINS) UN TEST QUI ECHOUE
5. ...
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,“Refund allowed until delivery,
even on the day of delivery") ;
}
32. 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,“Refund allowed until delivery,
even on the day of delivery") ;
}
34. Enfin, on corrige le bug
boolean refundAllowed(Product product) {
Datetime delivery = Datetime.parse(
"yyyy-MM-dd HH:MM“,product.deliveryAt());
Datetime now = Datetime.now;
return now <= delivery ;}
35. On relance le 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,“Refund allowed until delivery,
even on the day of delivery") ;
}
36. 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 PASSENT
7. ...
37. “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 et qu’on n’a pas cassé
autre chose.”
38. “On a vraiment suivi notre principe
‘qualité sans compromis’.”
39. “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 par
nos clients. On devrait informer les service
support client”
40. Astuce
• Définir et afficher les valeurs de l’équipe
• Maintenez un liste visible des actions
issues de la Root Cause Analysis (RCA)
• Langage:
– “On devrait ...” => “On va ...”
41. ON VA...
• Contacter l’équipe dev responsable
• Informer le service support client
42. 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 PASSENT
7. EXECUTER LES ACTIONS ISSUES DU RCA
8. ...
47. Scene 4:
Après la correction
Le testeur rejoint les développeurs
et l’architecte
48. 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 PASSENT
7. EXECUTER LES ACTIONS ISSUES DU RCA
8. AMELIORER LES TESTS
9. ...
52. Contexte (2)
• L’application a presque 80% de couverture de
code avec des tests automatiques
• Ce module a une couverture de 100%
• Mais contient (au moins) un bug
• Pourquoi ?
• Regardons les tests ...
55. Comment améliorer nos tests?
• Il n’y a pas d’ ASSERT !
– Facile d’avoir 100% de couverture
• Pourquoi 2050?
– Qu’est-ce qui se passe le 1er 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
56. Pourquoi?
• Développeurs ne savent pas comment tester
du code avec des dates (et des zones horaires)
– Beaucoup de tests avec des dates en 2050
• Peu de développeurs avec de l’experience en
tests unitaires
• Coaching Agile dans le passé ne contenait pas
de formation technique
57. On va...
• Contacter l’équipe de dev responsable
• Informer le service support client
• Ajouter des tests pour les dates, qui peuvent
servir comme exemple
• Montrer nos exemples aux autres équipes
58. Développeurs: “On a encore beaucoup à
apprendre”
Architecte: “J’ai toujours eu des doutes au
sujet des tests. Maintenant je sais
pourquoi.”
60. Creusons un peu ...
Pourquoi des tests sans ASSERT?
• But: “augmenter la couverture par les tests
automatiques” au lieu de “augmenter la qualité”
• Pression pour livrer des fonctionnalités
• Peu d’experience en testing
• TEST LAST au lieu de TEST FIRST
• Pas de formation ou coaching sur les aspects
techniques Agile
• Peu de coaches avec de l’experience technique
61. On va...
• Contacter l’équipe de dev responsable
• Informer le service support client
• Ajouter des tests pour les dates, qui peuvent
servir comme exemple
• Montrer nos exemples aux autres équipes
• Appliquer le TDD en binôme avec le coach et le
testeur
• Ajouter « Manque de coaching technique » à la
liste des risques du coach meeting
63. 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 PASSENT
7. EXECUTER LES ACTIONS ISSUES DU RCA
8. AMELIORER LES TESTS
9. AMELIORER LA FACON D’ECRIRE LES TESTS
10. ...
64.
65. The End
Et ils vécurent heureux à tout jamais..
“On a beaucoup à apprendre”
70. Cherchons dans le code...
• 10 cas où on parse cette date
– 5 fois avec “yyyy-MM-dd HH:MM”
– 5 fois avec “yyyy-MM-dd”
• Chaque développeur analyse un cas
• Résultat: deux bugs en plus
75. 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 PASSENT
7. EXECUTER LES ACTIONS ISSUES DU RCA
8. AMELIORER LES TESTS
9. AMELIORER LA FACON D’ECRIRE LES TESTS
10. RECHERCHER DES PROBLEMES SIMILAIRES. GOTO 2
11. ...
76. “Qualité sans compromis”. Facile à dire,
difficile à faire
“Ecrire les tests et corriger les
problèmes devient de plus en plus de la
routine. Ca va de plus en plus vite.”
81. Creusons un peu...
Pourquoi est-ce qu’on a écrit ce bug?
• On ne se rend pas compte qu’il y a une date +
temps
• On a 10x le même code de parsing
• => 10 opportunités pour des erreurs
• Enlevons la duplication
82. Améliorons Product
class Product {
...
// Deprecated: Remove when obsolete
String deliveryAt() ;
// New: gradually refactor all clients
DateTime deliveryAtDateTime() ;
...
}
From “stringly typed” to “strongly typed”
83. 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 PASSENT
7. EXECUTER LES ACTIONS 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
85. L’application
ABCDEFGHIJKLMNO
ABCDEFGHIJKLMNO
System A
ABCDEFGHIJKLMNO
ABCDEFGHIJKLMNO
Application
ABCDEFGHIJKLMNO
ABCDEFGHIJKLMNO
ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO
System B
89. On va...
• Contacter l’équipe de dev responsable
• Informer le service support client
• Ajouter des tests pour les dates, qui peuvent servir
comme exemple
• Montrer nos exemples aux autres équipes
• Appliquer le TDD en binôme avec le coach et le testeur
• Ajouter « Manque de coaching technique » à la liste
des risques du coach meeting
• Encapsuler les données qui viennent de l’exterieur
94. ASTUCE
• La proposition A3 reste visible pendant
toute la durée
• Affichez l’A3 où on ne peut pas la
manquer
• Limitez le nombre de propositions A3
96. Qu’est-ce qui s’est passé?
1. 7 membres de l’équipe + un coach ont passé
tout l’après-midi à corriger un bug de 6
caractères. Est-ce raisonable?
2. On a trouvé beaucoup moins de bugs que
dans les projets “normaux”? Y a-t-il un lien?
3. Le projet a été livré en 5 mois au lieu de 8.
Comment peut-on finir plus vite en allant
plus lentement?
113. PUB
• Quand il n’y a plus de bugs...
Appliquez IDD™
Irritation Driven Development®
Contact me if you want to become a Certifiable Irritating Person
114. ASTUCES
• Binomez avec le goulot d’étranglement
• Marchez dans leurs souliers
• Observez et notez les irritations
– Eliminez les irritations, sans fanfare
• Exemple: installation dev-ops
116. 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 PASSENT
7. EXECUTER LES ACTIONS 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
123. Merci, Dank u, Thank you, Danke, Tak,
Kiitos, Gracias, Grazie, Tack, Obrigado,
Arigatou Gozaimasu
Donne des conseils
Programme
Gère des projets
Crée des Jeux
Organise des conférences
NAYIMA
We make play work
http://www.nayima.be
http://www.agilecoach.net
Notas del editor
Portia and Pascal introduce themselves by sharing a bit about their background.
Portia and Pascal introduce themselves by sharing a bit about their background.