SlideShare uma empresa Scribd logo
1 de 126
Great! We found a bug!




    Pascal Van Cauwenberghe
Hello


              Consults
              Programs
              Manages projects
              Creates Games
              Organises conferences



NAYIMA
We make play work

www.nayima.be
blog.nayima.be
SAFETY WARNING
Safety Warning
• This presentation contains code
  – No guarantee that it actually compiles



• This presentation may contain bugs
  – Avoid if suffering from entomophobia
Based on true stories
•   In different countries
•   In different projects
•   With different teams
•   Using different (programming) languages
Great! Another bug!
Or how to spend all day with the whole
        team to fix a tiny bug
Mummy....

Where do bugs come from?
Well....

 Once upon a time
there was a project
Context
•   Global company
•   Large public web application
•   Mission critical, 24/7
•   Major revenue source for the company
•   First agile project for this team
•   I coach the team
•   We need to modify and extend a small section
    of the application
The project




The application

  US
Scene 1:
a developer spots a bug
Great! another bug
How do you react when someone
   says “I’ve found a bug” ?
MERCI!




    Thank You!
11 steps to perfect code
1. SPOT A PROBLEM
2. THANK THE REPORTER
3. ...
MERCI!




    Thank You!
Scene 2:
What do we do now?
THIS IS NOT A BUG
THIS IS AN OPPORTUNITY
TIPS
• Never BLAME
• No need to find the “guilty”

• Watch your language:
  – “Exercise”, “Experiment”, “Learn”, “Improve”
  – “We”, “Our code”, “Our problem”
• “Solution Focus” approach
Scene 3:
The team performs a
 Root Cause Analysis

5 developers + architect
Business rule:
“The customer can ask for a refund
          until delivery”
Who can spot the problem?
boolean refundAllowed(Product product) {
  Datetime now = Datetime.now;

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

    return now <= final ;
}
MERCI!




    Thank You!
Let’s test the application
• Delivery on 27/10/2012 at 16:00
• It is now 26/10/2012 10:20

• 26/10/2012 10:20 <= 27/10/2012 00:00 ?
Let’s test the application
• Delivery on 27/10/2012 at 16:00
• It is now 26/10/2012 10:20

• 26/10/2012 10:20 <= 27/10/2012 00:00 ?


            Refund? YES
Let’s test the application
• Delivery on 26/10/2012 at 16:00
• It is now 26/10/2012 10:20

• 26/10/2012 10:20 <= 26/10/2012 00:00 ?
Let’s test the application
• Delivery on 26/10/2012 at 16:00
• It is now 26/10/2012 10:20

• 26/10/2012 10:20 <= 26/10/2012 00:00 ?


            Refund? NO
11 steps to perfect code
1.   SPOT A PROBLEM
2.   THANK THE REPORTER
3.   REPRODUCE THE PROBLEM
4.   ...
Can we fix the bug?

The fix is really simple!
11 steps to perfect code
1.   SPOT A PROBLEM
2.   THANK THE REPORTER
3.   REPRODUCE THE PROBLEM
4.   ADD (AT LEAST) ONE FAILING TEST
5.   ...
A new 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") ;
}
A new 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") ;
}
Can we fix the bug?

The fix is really simple!
We finally fix the bug
boolean refundAllowed(Product product) {
  Datetime now = Datetime.now;

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

    return now <= final ;
}
Rerun the 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") ;
}
11 steps to perfect code
1.   SPOT A PROBLEM
2.   THANK THE REPORTER
3.   REPRODUCE THE PROBLEM
4.   ADD (AT LEAST) ONE FAILING TEST
5.   CORRECT THE PROBLEM
6.   AND RERUN ALL TESTS UNTIL THEY PASS
7.   ...
“This agile thing is going to be very slow if
we do this for every bug!”
“Yes, but at least now we have some
confidence that the bug is fixed correctly
and that we haven’t broken anything else.”
“We’ve really applied our team value of
‘quality without compromise’. We took
the time to do it right, even if no
customer has complained yet.”
“We should contact the team that’s responsible for
this code and inform them of our correction.”
“There may have been customer complaints already.
We should contact the customer support people to
see if there are complaints and inform them of the
existing problem”
TIPS
• Define and make the team values visible
  at all times
• Keep a list of things to do after the Root
  Cause Analysis (RCA)

• Language:
  – “We should...” => “We will...”
WE WILL...

• Contact the development team responsible
  for this code
• Inform the customer support team
11 steps to perfect code
1.   SPOT A PROBLEM
2.   THANK THE REPORTER
3.   REPRODUCE THE PROBLEM
4.   ADD (AT LEAST) ONE FAILING TEST
5.   CORRECT THE PROBLEM
6.   AND RERUN ALL TESTS UNTIL THEY PASS
7.   PERFORM THE ACTIONS OF THE RCA
8.   ...
“GOOD JOB!”



“Now, back to work!”
THE END
And they lived happily ever after...
Great! another bug
It’s not over yet!
Scene 4:
         After the fix

The tester joins the developers and
              architect
11 steps to perfect code
1.   SPOT A PROBLEM
2.   THANK THE REPORTER
3.   REPRODUCE THE PROBLEM
4.   ADD (AT LEAST) ONE FAILING TEST
5.   CORRECT THE PROBLEM
6.   AND RERUN ALL TESTS UNTIL THEY PASS
7.   PERFORM THE ACTIONS OF THE RCA
8.   IMPROVE YOUR TESTS
9.   ...
How can we improve our tests?

    We should have found this bug
               sooner
How can we improve our tests?

  We should have will fouind this type
            of bug sooner
How can we improve our tests?

  We will find this type of bug sooner
Context (2)
• Almost 80% code coverage with automated
  unit tests in the whole application
• This module has 100% test coverage
• But still contains (at least) one bug
• Why?
• Let’s look at the tests...
Who can spot the problem?
void testRefundGiven() {
 Product product = ...
 product.deliveryAt(“2050-12-31 19:00”) ;
 BusinessRule businessRule = ...
 bool allowed =
  businessRule.refundAllowed(product)
}
MERCI!




    Thank You!
How can we improve our tests?
• There’s no ASSERT !
  – It’s easy to get 100% code coverage that way
• Why 2050?
  – What happens on January 1st 2051?
• We need at least 4 tests
  – Delivery before today
  – Delivery today before now
  – Delivery today after now
  – Delivery after today
Why?
• Developers don’t know how to test date and
  time (and timezone!)-related code
  – Lots of tests use dates in 2050
• Few developers with unit testing experience
• Agile coaching in the past did not include
  technical practices
We will...

• Contact the development team responsible
  for this code
• Inform the customer support team
• Add more tests about dates that can serve as
  examples
• Show our example tests to other teams
Developers: “we have a lot to learn about unit
testing”
Architect: “I’ve always had doubts about our
automated tests. Now I know why.”
Tester: “If you want, I can help you to define and
improve tests”
Let’s dig deeper...
       Why tests without ASSERT?
• Goal: “increase code coverage of automated
  tests” instead of “increase quality”
• Pressure to “do more with less (money and
  time)”
• Not much experience with unit testing
• TEST LAST development instead of Test First
• No training or coaching on technical practices
• Not all Agile coaches in the company have
  experience with technical practices
We will...

• Contact the development team responsible for
  this code
• Inform the customer support team
• Add more tests about dates that can serve as
  examples
• Show our example tests to other teams
• Apply TDD by pairing with the coach and tester
• Raise « lack of technical practice coaching » risk
  at coach meeting
Systems Thinking
11 steps to perfect code
1. SPOT A PROBLEM
2. THANK THE REPORTER
3. REPRODUCE THE PROBLEM
4. ADD (AT LEAST) ONE FAILING TEST
5. CORRECT THE PROBLEM
6. AND RERUN ALL TESTS UNTIL THEY PASS
7. PERFORM THE ACTIONS OF THE RCA
8. IMPROVE YOUR TESTS
9. IMPROVE THE WAY YOU WRITE TESTS
10. ...
Great! another bug
The End
They lived happily ever after...

   “We have a lot to learn”
Great! another bug
It’s not over yet!
Scene 5:
    After the tests

A bug never travels alone...
Is this bug unique?
Let’s search the code...
• We find 10 cases where this datetime is
  parsed
  – 5 times with “yyyy-MM-dd HH:MM”
  – 5 times with “yyyy-MM-dd”
• Each developer analyses one case
• Result: two more bugs
What do you say?
MERCI!




    Thank You!
And again...
MERCI!




    Thank You!
11 steps to perfect code
1.    SPOT A PROBLEM
2.    THANK THE REPORTER
3.    REPRODUCE THE PROBLEM
4.    ADD (AT LEAST) ONE FAILING TEST
5.    CORRECT THE PROBLEM
6.    AND RERUN ALL TESTS UNTIL THEY PASS
7.    PERFORM THE ACTIONS OF THE RCA
8.    IMPROVE YOUR TESTS
9.    IMPROVE THE WAY YOU WRITE TESTS
10.   LOOK FOR SIMILAR PROBLEMS. GOTO 2
11.   ...
Great! another bug
“Quality without compromise”. Easy to
say, hard to do
“Writing tests and correcting problems
is starting to become routine. It goes
faster each time we do it.”
Finally, The End?
Can we live happily ever after now?
It’s not DONE !
Did you spot another problem?
MERCI!




    Thank You!
Digging deeper...
    Why did we introduce the bug?
• We aren’t aware that there’s a date+time
• We have 10x the same parsing code
• => 10 opportunities to make a mistake

• Let’s remove the duplication that leads to
  mistakes
Improving Product
class Product {
...
  // Deprecated: Remove when obsolete
  String deliveryAt() ;
  // New: gradually refactor all clients
  DateTime deliveryAtDateTime() ;
...
}

From “stringly typed” to “strongly typed”
11 steps to perfect code
1.    SPOT A PROBLEM
2.    THANK THE REPORTER
3.    REPRODUCE THE PROBLEM
4.    ADD (AT LEAST) ONE FAILING TEST
5.    CORRECT THE PROBLEM
6.    AND RERUN ALL TESTS UNTIL THEY PASS
7.    PERFORM THE ACTIONS OF THE RCA
8.    IMPROVE YOUR TESTS
9.    IMPROVE THE WAY YOU WRITE TESTS
10.   LOOK FOR SIMILAR PROBLEMS. GOTO 2
11.   MAKE THIS TYPE OF PROBLEM IMPOSSIBLE
TIP
• If you think you have to comment your
  code, think again
With comments
class A {
  void methodA() ;
  // Call methodA before calling these
  void methodB() ;
  void methodC() ;
}
...
a.methodB() ; // ERROR
a.methodA() ; // ERROR!!
Without comment
class A {
  B methodA() ;
}

class B {
  void methodB() ;
  void methodC() ;
}

a.methodA().methodB() ;
Mummy....

Where do strings come from?
The application
                                    ABCDEFGHIJKLMNO


   ABCDEFGHIJKLMNO
                                                      System A

ABCDEFGHIJKLMNO
                  ABCDEFGHIJKLMNO


 Application
            ABCDEFGHIJKLMNO
   ABCDEFGHIJKLMNO
        ABCDEFGHIJKLMNO             ABCDEFGHIJKLMNO

                                                       System B
Great! another bug
The application(vision)
                ABCDEFGHIJKLMNO

                                    System A




L’application
                  ABCDEFGHIJKLMNO


                                     System B
Great! another bug
We will...

• Contact the development team responsible for this
  code
• Inform the customer support team
• Add more tests about dates that can serve as examples
• Show our example tests to other teams
• Apply TDD by pairing with the coach and tester
• Raise « lack of technical practice coaching » risk at
  coach meeting
• Encapsulate data coming from outside
LARGE REFACTORING
Great! another bug
A3 proposal
A3 Proposal
              Problem description
BEFORE                  AFTER




STEPS:                  Visualisation
1. .jdlkjds
2. Kmlkdmlkd
3. Dkqjdlkjds
4. Sqkjlkdlksqmk
5. BEER !
TIPS
• Keep the A3 visible during the whole
  refactoring
• Put the A3 where it can’t be missed
• Limit the number of A3s that can be
  published
Scene 6:
Final act
Looking back
1. 7 team members + one coach have spent all
   afternoon to correct a 6-character bug? Is
   this reasonable?
2. In the end, there were a lot less bugs found
   in test than on “normal” projects. Is there a
   link?
3. This project was delivered in 5 months
   instead of the 8 that were estimated. How
   can you finish faster by going slower?
Theory of Constraints
    in a nutshell
How much do they deliver?

                    Test &
Analysis:   Dev:
  20         10
                    Deploy:
                      15
                                ???
How much do they deliver?

                    Test &
Analysis:   Dev:
  20         10
                    Deploy:
                      15
                                <= 10
How much do they deliver?

                     Test &
 Analysis:   Dev:
   20         10
                     Deploy:
                       15
                                 ???


Analysis:    Dev:
  10          12
How much do they deliver?

                     Test &
 Analysis:   Dev:
   20         10
                     Deploy:
                       15
                                 <= 15


Analysis:    Dev:
  10          12
What if development speeds up?

                     Test &
 Analysis:   Dev:
   20         20
                     Deploy:
                       15
                               ???


Analysis:     Dev:
  10           12
Nothing happens?

                        Test &
 Analysis:      Dev:
   20            20
                        Deploy:
                          15
                                  <= 15


Analysis:        Dev:
  10              12
Buffers start to fill up!

                              Test &
 Analysis:          Dev:
   20                20
                              Deploy:
                                15
                                         < 15


Analysis:            Dev:
  10                  12
How much do they deliver?

                     Test &
 Analysis:   Dev:
   20         10
                     Deploy:
                       15
                                 <= 15


Analysis:    Dev:
  10          12
What if we go slower?

                           Test &
 Analysis:         Dev:
   20               8
                           Deploy:
                             17
                                     <= 17


Analysis:          Dev:
  10                12
Why are we analysing so fast?

                    Test &
 Analysis:   Dev:
   20         8
                    Deploy:
                      17
                              <= 17


Analysis:    Dev:
  10          12
We do less

                      Test &
              Dev:
                                <= 17
 Analysis:
   10                 Deploy:
               8
                        17




Analysis:     Dev:
  10           12
Play The Bottleneck Game
Reading tips
How much does quality cost?
TIPS
• Once you run out of reported bugs...


                            Apply IDD™

   Irritation Driven Development

Contact me if you want to become a Certifiable Irritating Person
TIPS
• Pair with the bottleneck
  – ToC calls this “subordinating”
• Walk a mile in their shoes
  – Carefully observe and note irritations
  – Quietly remove the irritations


• Example: pair-installing dev-ops
Summary
11 steps to a life with less stress
1.    SPOT A PROBLEM
2.    THANK THE REPORTER
3.    REPRODUCE THE PROBLEM
4.    ADD (AT LEAST) ONE FAILING TEST
5.    CORRECT THE PROBLEM
6.    AND RERUN ALL TESTS UNTIL THEY PASS
7.    PERFORM THE ACTIONS OF THE RCA
8.    IMPROVE YOUR TESTS
9.    IMPROVE THE WAY YOU WRITE TESTS
10.   LOOK FOR SIMILAR PROBLEMS. GOTO 2
11.   MAKE THIS TYPE OF PROBLEM IMPOSSIBLE
But, most importantly...
MERCI!




    Thank You!
The End
And they lived happily ever after
SESSION FEEDBACK
MERCI!




    Thank You!
Thank you, Dank u, Merci, Danke, Tak,
Kiitos, Gracias, Grazie, Tack, Obrigado

                                    Consults
                                    Programs
                                    Manages projects
                                    Creates Games
                                    Organises conferences



               NAYIMA
               We make play work
               http://www.nayima.be
               http://www.agilecoach.net
Great! another bug

Mais conteúdo relacionado

Mais procurados

Agile?! Are You Crazy???
Agile?! Are You Crazy???Agile?! Are You Crazy???
Agile?! Are You Crazy???lazygolfer
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Codemotion
 
Visualizing Work: If you can't see it, you can't manage it
Visualizing Work: If you can't see it, you can't manage itVisualizing Work: If you can't see it, you can't manage it
Visualizing Work: If you can't see it, you can't manage itFernando Cuenca
 
Understanding Kanban
Understanding KanbanUnderstanding Kanban
Understanding Kanbannikos batsios
 
Changing business of testing - Testing Assembly Helsinki 2014
Changing business of testing - Testing Assembly Helsinki 2014Changing business of testing - Testing Assembly Helsinki 2014
Changing business of testing - Testing Assembly Helsinki 2014Vasco Duarte
 
Bob Galen : Great sprint reviews
Bob Galen : Great sprint reviews   Bob Galen : Great sprint reviews
Bob Galen : Great sprint reviews AgileDenver
 
Building Cross-Functional Scrum-Teams in a Hardware Project
Building Cross-Functional Scrum-Teams in a Hardware ProjectBuilding Cross-Functional Scrum-Teams in a Hardware Project
Building Cross-Functional Scrum-Teams in a Hardware ProjectStephanie Gasche
 
Why Limit WIP?
Why Limit WIP?  Why Limit WIP?
Why Limit WIP? LeanKit
 
Building Better Products, June 2015
Building Better Products, June 2015Building Better Products, June 2015
Building Better Products, June 2015Jason Fraser
 
Why Does Agile Work?
Why Does Agile Work?Why Does Agile Work?
Why Does Agile Work?Matthew Caine
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Codemotion
 
The Three Things
The Three ThingsThe Three Things
The Three ThingsAgileDenver
 
Kaizen in Action
Kaizen in ActionKaizen in Action
Kaizen in ActionKiro Harada
 
Fixing Continuous Delivery For Mobile
Fixing Continuous Delivery For MobileFixing Continuous Delivery For Mobile
Fixing Continuous Delivery For MobileEvan Schultz
 
10 signs your testing is not enough
10 signs your testing is not enough10 signs your testing is not enough
10 signs your testing is not enoughSQALab
 

Mais procurados (20)

Selling Agile
Selling AgileSelling Agile
Selling Agile
 
Quality is a Mindset
Quality is a MindsetQuality is a Mindset
Quality is a Mindset
 
LKCE16 - Enterprise Flow by Klaus Leopold
LKCE16 - Enterprise Flow by Klaus LeopoldLKCE16 - Enterprise Flow by Klaus Leopold
LKCE16 - Enterprise Flow by Klaus Leopold
 
Agile?! Are You Crazy???
Agile?! Are You Crazy???Agile?! Are You Crazy???
Agile?! Are You Crazy???
 
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
Lars Wolff - Performance Testing for DevOps in the Cloud - Codemotion Amsterd...
 
Visualizing Work: If you can't see it, you can't manage it
Visualizing Work: If you can't see it, you can't manage itVisualizing Work: If you can't see it, you can't manage it
Visualizing Work: If you can't see it, you can't manage it
 
Understanding Kanban
Understanding KanbanUnderstanding Kanban
Understanding Kanban
 
Changing business of testing - Testing Assembly Helsinki 2014
Changing business of testing - Testing Assembly Helsinki 2014Changing business of testing - Testing Assembly Helsinki 2014
Changing business of testing - Testing Assembly Helsinki 2014
 
Bob Galen : Great sprint reviews
Bob Galen : Great sprint reviews   Bob Galen : Great sprint reviews
Bob Galen : Great sprint reviews
 
Building Cross-Functional Scrum-Teams in a Hardware Project
Building Cross-Functional Scrum-Teams in a Hardware ProjectBuilding Cross-Functional Scrum-Teams in a Hardware Project
Building Cross-Functional Scrum-Teams in a Hardware Project
 
BoS2015 Trish Khoo – Engineering Manager, Google
BoS2015 Trish Khoo – Engineering Manager, GoogleBoS2015 Trish Khoo – Engineering Manager, Google
BoS2015 Trish Khoo – Engineering Manager, Google
 
Why Limit WIP?
Why Limit WIP?  Why Limit WIP?
Why Limit WIP?
 
Understanding Scrum
Understanding ScrumUnderstanding Scrum
Understanding Scrum
 
Building Better Products, June 2015
Building Better Products, June 2015Building Better Products, June 2015
Building Better Products, June 2015
 
Why Does Agile Work?
Why Does Agile Work?Why Does Agile Work?
Why Does Agile Work?
 
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
Joshua Hoffman - Should the CTO be Coding? - Codemotion Amsterdam 2019
 
The Three Things
The Three ThingsThe Three Things
The Three Things
 
Kaizen in Action
Kaizen in ActionKaizen in Action
Kaizen in Action
 
Fixing Continuous Delivery For Mobile
Fixing Continuous Delivery For MobileFixing Continuous Delivery For Mobile
Fixing Continuous Delivery For Mobile
 
10 signs your testing is not enough
10 signs your testing is not enough10 signs your testing is not enough
10 signs your testing is not enough
 

Destaque

Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileAgileCoach.net
 
Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 2013AgileCoach.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écisionsAgileCoach.net
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013AgileCoach.net
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business valueAgileCoach.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 gestionAgileCoach.net
 
Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012AgileCoach.net
 
Holy Grail of On-Page Content Conversion Optimization
Holy Grail of On-Page Content Conversion OptimizationHoly Grail of On-Page Content Conversion Optimization
Holy Grail of On-Page Content Conversion OptimizationAngie Schottmuller
 
Bpifrance Le Lab : 10 ans de création d'entreprises innovantes au féminin
Bpifrance Le Lab : 10 ans de création d'entreprises innovantes au fémininBpifrance Le Lab : 10 ans de création d'entreprises innovantes au féminin
Bpifrance Le Lab : 10 ans de création d'entreprises innovantes au fémininBpifrance
 
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 2010AgileCoach.net
 
Real Options - Agile France 2013
Real Options - Agile France 2013Real Options - Agile France 2013
Real Options - Agile France 2013AgileCoach.net
 
Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsAgileCoach.net
 
Presentation de l'incubateur Essaim
Presentation de l'incubateur EssaimPresentation de l'incubateur Essaim
Presentation de l'incubateur EssaimClaude Michaud
 
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013AgileCoach.net
 
Chouette! Encore un bug!
Chouette! Encore un bug!Chouette! Encore un bug!
Chouette! Encore un bug!AgileCoach.net
 
Les essentiels cc&a. : Design Thinking vs. Design Management
Les essentiels cc&a. : Design Thinking vs. Design ManagementLes essentiels cc&a. : Design Thinking vs. Design Management
Les essentiels cc&a. : Design Thinking vs. Design ManagementChristophe Chaptal de Chanteloup
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation GamesAgileCoach.net
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchAgileCoach.net
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinkingAgileCoach.net
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorialAgileCoach.net
 

Destaque (20)

Les Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/AgileLes Bases des Méthodes Lean/Agile
Les Bases des Méthodes Lean/Agile
 
Keynote agile grenoble 2013
Keynote agile grenoble 2013Keynote agile grenoble 2013
Keynote agile grenoble 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
 
Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013Real Options Agile Tour Brussels 2013
Real Options Agile Tour Brussels 2013
 
Agreeing on business value
Agreeing on business valueAgreeing on business value
Agreeing on business value
 
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
 
Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012Chouette! Encore un bug! Agile Tour 2012
Chouette! Encore un bug! Agile Tour 2012
 
Holy Grail of On-Page Content Conversion Optimization
Holy Grail of On-Page Content Conversion OptimizationHoly Grail of On-Page Content Conversion Optimization
Holy Grail of On-Page Content Conversion Optimization
 
Bpifrance Le Lab : 10 ans de création d'entreprises innovantes au féminin
Bpifrance Le Lab : 10 ans de création d'entreprises innovantes au fémininBpifrance Le Lab : 10 ans de création d'entreprises innovantes au féminin
Bpifrance Le Lab : 10 ans de création d'entreprises innovantes au féminin
 
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
 
Real Options - Agile France 2013
Real Options - Agile France 2013Real Options - Agile France 2013
Real Options - Agile France 2013
 
Real Options: How and When (not) to take Decisions
Real Options: How and When (not) to take DecisionsReal Options: How and When (not) to take Decisions
Real Options: How and When (not) to take Decisions
 
Presentation de l'incubateur Essaim
Presentation de l'incubateur EssaimPresentation de l'incubateur Essaim
Presentation de l'incubateur Essaim
 
Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013Real Options Lean Kanban France 2013
Real Options Lean Kanban France 2013
 
Chouette! Encore un bug!
Chouette! Encore un bug!Chouette! Encore un bug!
Chouette! Encore un bug!
 
Les essentiels cc&a. : Design Thinking vs. Design Management
Les essentiels cc&a. : Design Thinking vs. Design ManagementLes essentiels cc&a. : Design Thinking vs. Design Management
Les essentiels cc&a. : Design Thinking vs. Design Management
 
Agile 2010 Estimation Games
Agile 2010 Estimation  GamesAgile 2010 Estimation  Games
Agile 2010 Estimation Games
 
Conflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - FrenchConflict Resolution Diagram Tutorial - French
Conflict Resolution Diagram Tutorial - French
 
Business value by systems thinking
Business value by systems thinkingBusiness value by systems thinking
Business value by systems thinking
 
Conflict resolution diagram tutorial
Conflict resolution diagram tutorialConflict resolution diagram tutorial
Conflict resolution diagram tutorial
 

Semelhante a Great! another bug

Team wide testing
Team wide testingTeam wide testing
Team wide testingEthan Huang
 
Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)
Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)
Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)Dinis Cruz
 
Niels Malotaux - Help We Have a QA Problem!
Niels Malotaux -  Help We Have a QA Problem!Niels Malotaux -  Help We Have a QA Problem!
Niels Malotaux - Help We Have a QA Problem!TEST Huddle
 
Understand regression testing
Understand regression testingUnderstand regression testing
Understand regression testinggaoliang641
 
Striving for zero bugs
Striving for zero bugsStriving for zero bugs
Striving for zero bugsTEST Huddle
 
Machine learning pipeline
Machine learning pipelineMachine learning pipeline
Machine learning pipelineVadym Kuzmenko
 
5 Steps to Detecting Issues Earlier in Your Release Cycles
 5 Steps to Detecting Issues Earlier in Your Release Cycles 5 Steps to Detecting Issues Earlier in Your Release Cycles
5 Steps to Detecting Issues Earlier in Your Release CyclesPerfecto by Perforce
 
iOS Test-Driven Development
iOS Test-Driven DevelopmentiOS Test-Driven Development
iOS Test-Driven DevelopmentPablo Villar
 
Scrum and-xp-from-the-trenches 06 testing
Scrum and-xp-from-the-trenches 06 testingScrum and-xp-from-the-trenches 06 testing
Scrum and-xp-from-the-trenches 06 testingHossam Hassan
 
Real world software launch
Real world software launchReal world software launch
Real world software launchKunal Johar
 
An Introduction To Software Development - Final Review
An Introduction To Software Development - Final ReviewAn Introduction To Software Development - Final Review
An Introduction To Software Development - Final ReviewBlue Elephant Consulting
 
Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)Joel Chippindale
 
Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)FutureLearn
 
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.Coolblue
 
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.Coolblue
 
An Introduction To Software Development - Test Driven Development, Part 1
An Introduction To Software Development - Test Driven Development, Part 1An Introduction To Software Development - Test Driven Development, Part 1
An Introduction To Software Development - Test Driven Development, Part 1Blue Elephant Consulting
 
Bigger Unit Test Are Better
Bigger Unit Test Are BetterBigger Unit Test Are Better
Bigger Unit Test Are BetterPeter Schuler
 
Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...
Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...
Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...AgileNetwork
 
Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...
Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...
Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...TEST Huddle
 

Semelhante a Great! another bug (20)

Team wide testing
Team wide testingTeam wide testing
Team wide testing
 
Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)
Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)
Start with passing tests (tdd for bugs) v0.5 (22 sep 2016)
 
Niels Malotaux - Help We Have a QA Problem!
Niels Malotaux -  Help We Have a QA Problem!Niels Malotaux -  Help We Have a QA Problem!
Niels Malotaux - Help We Have a QA Problem!
 
Understand regression testing
Understand regression testingUnderstand regression testing
Understand regression testing
 
Striving for zero bugs
Striving for zero bugsStriving for zero bugs
Striving for zero bugs
 
Machine learning pipeline
Machine learning pipelineMachine learning pipeline
Machine learning pipeline
 
5 Steps to Detecting Issues Earlier in Your Release Cycles
 5 Steps to Detecting Issues Earlier in Your Release Cycles 5 Steps to Detecting Issues Earlier in Your Release Cycles
5 Steps to Detecting Issues Earlier in Your Release Cycles
 
iOS Test-Driven Development
iOS Test-Driven DevelopmentiOS Test-Driven Development
iOS Test-Driven Development
 
Scrum and-xp-from-the-trenches 06 testing
Scrum and-xp-from-the-trenches 06 testingScrum and-xp-from-the-trenches 06 testing
Scrum and-xp-from-the-trenches 06 testing
 
Real world software launch
Real world software launchReal world software launch
Real world software launch
 
An Introduction To Software Development - Final Review
An Introduction To Software Development - Final ReviewAn Introduction To Software Development - Final Review
An Introduction To Software Development - Final Review
 
Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)
 
Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)Reducing risk through continuous delivery (Nov 2014)
Reducing risk through continuous delivery (Nov 2014)
 
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
 
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
Coolblue Behind the Scenes | Niels Abels - Continuous Delivery.
 
An Introduction To Software Development - Test Driven Development, Part 1
An Introduction To Software Development - Test Driven Development, Part 1An Introduction To Software Development - Test Driven Development, Part 1
An Introduction To Software Development - Test Driven Development, Part 1
 
Bigger Unit Test Are Better
Bigger Unit Test Are BetterBigger Unit Test Are Better
Bigger Unit Test Are Better
 
Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...
Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...
Agile Gurgaon 2016 | Thinking Beyond :: Marry Agile and DevOps for Phenomenal...
 
Tdd
TddTdd
Tdd
 
Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...
Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...
Testing As A Bottleneck - How Testing Slows Down Modern Development Processes...
 

Último

Digital Marketing Training Program skills s
Digital Marketing Training Program skills sDigital Marketing Training Program skills s
Digital Marketing Training Program skills sgodxzyrox
 
Shopclues: Failure & Solutions in Business Model
Shopclues: Failure & Solutions in Business ModelShopclues: Failure & Solutions in Business Model
Shopclues: Failure & Solutions in Business ModelBhaviniSharma12
 
CORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdf
CORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdfCORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdf
CORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdfLouis Malaybalay
 
Streamlining Your Accounting A Guide to QuickBooks Migration Tools.pptx
Streamlining Your Accounting A Guide to QuickBooks Migration Tools.pptxStreamlining Your Accounting A Guide to QuickBooks Migration Tools.pptx
Streamlining Your Accounting A Guide to QuickBooks Migration Tools.pptxPaulBryant58
 
Mist Cooling & Fogging System Company in Egypt
Mist Cooling & Fogging System Company in EgyptMist Cooling & Fogging System Company in Egypt
Mist Cooling & Fogging System Company in Egyptopstechsanjanasingh
 
Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...
Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...
Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...BilalAhmed717
 
The Smart Bridge Interview now Veranda Learning
The Smart Bridge Interview now Veranda LearningThe Smart Bridge Interview now Veranda Learning
The Smart Bridge Interview now Veranda LearningNaval Singh
 
A Comprehensive Case Study on the IL&FS Crisis (final).pptx
A Comprehensive Case Study on the IL&FS Crisis (final).pptxA Comprehensive Case Study on the IL&FS Crisis (final).pptx
A Comprehensive Case Study on the IL&FS Crisis (final).pptxShainaMaheshwari1
 
Importance of Commercial Vehicle Insurance.pptx
Importance of Commercial Vehicle Insurance.pptxImportance of Commercial Vehicle Insurance.pptx
Importance of Commercial Vehicle Insurance.pptxBonano Insurance
 
Olympus 38DL Plus Ultrasonic Thickness Gauge
Olympus 38DL Plus Ultrasonic Thickness GaugeOlympus 38DL Plus Ultrasonic Thickness Gauge
Olympus 38DL Plus Ultrasonic Thickness GaugeStephenKim86
 
pitchdeck ORPC 2019 data info turine.pdf
pitchdeck ORPC 2019 data info turine.pdfpitchdeck ORPC 2019 data info turine.pdf
pitchdeck ORPC 2019 data info turine.pdflebob12
 
L-1 VISA Business (Plan Sample) - Plan Writers
L-1 VISA Business (Plan Sample) - Plan WritersL-1 VISA Business (Plan Sample) - Plan Writers
L-1 VISA Business (Plan Sample) - Plan WritersPlan Writers
 
Dashboards y paneles - CP Home - Area de Operaciones
Dashboards y paneles - CP Home - Area de OperacionesDashboards y paneles - CP Home - Area de Operaciones
Dashboards y paneles - CP Home - Area de OperacionesLPI ONG
 
Business Models and Business Model Innovation
Business Models and Business Model InnovationBusiness Models and Business Model Innovation
Business Models and Business Model InnovationMichal Hron
 
Strategic Resources Corporate Presentation - March 2024 Update
Strategic Resources Corporate Presentation - March 2024 UpdateStrategic Resources Corporate Presentation - March 2024 Update
Strategic Resources Corporate Presentation - March 2024 UpdateAdnet Communications
 
0311 National Accounts Online Giving Trends.pdf
0311 National Accounts Online Giving Trends.pdf0311 National Accounts Online Giving Trends.pdf
0311 National Accounts Online Giving Trends.pdfBloomerang
 
CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)
CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)
CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)CXO 2.0 Conference
 
The Vietnam Believer_Newsletter_Vol.001_Mar12 2024
The Vietnam Believer_Newsletter_Vol.001_Mar12 2024The Vietnam Believer_Newsletter_Vol.001_Mar12 2024
The Vietnam Believer_Newsletter_Vol.001_Mar12 2024believeminhh
 

Último (20)

Digital Marketing Training Program skills s
Digital Marketing Training Program skills sDigital Marketing Training Program skills s
Digital Marketing Training Program skills s
 
Shopclues: Failure & Solutions in Business Model
Shopclues: Failure & Solutions in Business ModelShopclues: Failure & Solutions in Business Model
Shopclues: Failure & Solutions in Business Model
 
WAM Corporate Presentation Mar 12 2024_Video.pdf
WAM Corporate Presentation Mar 12 2024_Video.pdfWAM Corporate Presentation Mar 12 2024_Video.pdf
WAM Corporate Presentation Mar 12 2024_Video.pdf
 
CORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdf
CORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdfCORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdf
CORPORATE SOCIAL RESPONSIBILITY - FINAL REQUIREMENT.pdf
 
Streamlining Your Accounting A Guide to QuickBooks Migration Tools.pptx
Streamlining Your Accounting A Guide to QuickBooks Migration Tools.pptxStreamlining Your Accounting A Guide to QuickBooks Migration Tools.pptx
Streamlining Your Accounting A Guide to QuickBooks Migration Tools.pptx
 
Mist Cooling & Fogging System Company in Egypt
Mist Cooling & Fogging System Company in EgyptMist Cooling & Fogging System Company in Egypt
Mist Cooling & Fogging System Company in Egypt
 
Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...
Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...
Project Work on Consumer Behavior in Fast Food Restaurants. Their behavior to...
 
The Smart Bridge Interview now Veranda Learning
The Smart Bridge Interview now Veranda LearningThe Smart Bridge Interview now Veranda Learning
The Smart Bridge Interview now Veranda Learning
 
A Comprehensive Case Study on the IL&FS Crisis (final).pptx
A Comprehensive Case Study on the IL&FS Crisis (final).pptxA Comprehensive Case Study on the IL&FS Crisis (final).pptx
A Comprehensive Case Study on the IL&FS Crisis (final).pptx
 
Importance of Commercial Vehicle Insurance.pptx
Importance of Commercial Vehicle Insurance.pptxImportance of Commercial Vehicle Insurance.pptx
Importance of Commercial Vehicle Insurance.pptx
 
Olympus 38DL Plus Ultrasonic Thickness Gauge
Olympus 38DL Plus Ultrasonic Thickness GaugeOlympus 38DL Plus Ultrasonic Thickness Gauge
Olympus 38DL Plus Ultrasonic Thickness Gauge
 
pitchdeck ORPC 2019 data info turine.pdf
pitchdeck ORPC 2019 data info turine.pdfpitchdeck ORPC 2019 data info turine.pdf
pitchdeck ORPC 2019 data info turine.pdf
 
L-1 VISA Business (Plan Sample) - Plan Writers
L-1 VISA Business (Plan Sample) - Plan WritersL-1 VISA Business (Plan Sample) - Plan Writers
L-1 VISA Business (Plan Sample) - Plan Writers
 
Dashboards y paneles - CP Home - Area de Operaciones
Dashboards y paneles - CP Home - Area de OperacionesDashboards y paneles - CP Home - Area de Operaciones
Dashboards y paneles - CP Home - Area de Operaciones
 
Business Models and Business Model Innovation
Business Models and Business Model InnovationBusiness Models and Business Model Innovation
Business Models and Business Model Innovation
 
Strategic Resources Corporate Presentation - March 2024 Update
Strategic Resources Corporate Presentation - March 2024 UpdateStrategic Resources Corporate Presentation - March 2024 Update
Strategic Resources Corporate Presentation - March 2024 Update
 
WAM Corporate Presentation Mar 12 2024.pdf
WAM Corporate Presentation Mar 12 2024.pdfWAM Corporate Presentation Mar 12 2024.pdf
WAM Corporate Presentation Mar 12 2024.pdf
 
0311 National Accounts Online Giving Trends.pdf
0311 National Accounts Online Giving Trends.pdf0311 National Accounts Online Giving Trends.pdf
0311 National Accounts Online Giving Trends.pdf
 
CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)
CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)
CXO 2.0 Conference (Event Information Deck | Dec'24-Mar'25)
 
The Vietnam Believer_Newsletter_Vol.001_Mar12 2024
The Vietnam Believer_Newsletter_Vol.001_Mar12 2024The Vietnam Believer_Newsletter_Vol.001_Mar12 2024
The Vietnam Believer_Newsletter_Vol.001_Mar12 2024
 

Great! another bug

  • 1. Great! We found a bug! Pascal Van Cauwenberghe
  • 2. Hello Consults Programs Manages projects Creates Games Organises conferences NAYIMA We make play work www.nayima.be blog.nayima.be
  • 4. Safety Warning • This presentation contains code – No guarantee that it actually compiles • This presentation may contain bugs – Avoid if suffering from entomophobia
  • 5. Based on true stories • In different countries • In different projects • With different teams • Using different (programming) languages
  • 6. Great! Another bug! Or how to spend all day with the whole team to fix a tiny bug
  • 8. Well.... Once upon a time there was a project
  • 9. Context • Global company • Large public web application • Mission critical, 24/7 • Major revenue source for the company • First agile project for this team • I coach the team • We need to modify and extend a small section of the application
  • 11. Scene 1: a developer spots a bug
  • 13. How do you react when someone says “I’ve found a bug” ?
  • 14. MERCI! Thank You!
  • 15. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. ...
  • 16. MERCI! Thank You!
  • 17. Scene 2: What do we do now?
  • 18. THIS IS NOT A BUG
  • 19. THIS IS AN OPPORTUNITY
  • 20. TIPS • Never BLAME • No need to find the “guilty” • Watch your language: – “Exercise”, “Experiment”, “Learn”, “Improve” – “We”, “Our code”, “Our problem” • “Solution Focus” approach
  • 21. Scene 3: The team performs a Root Cause Analysis 5 developers + architect
  • 22. Business rule: “The customer can ask for a refund until delivery”
  • 23. Who can spot the problem? boolean refundAllowed(Product product) { Datetime now = Datetime.now; Datetime final = Datetime.parse("yyyy-MM-dd“, product.deliveryAt()); return now <= final ; }
  • 24. MERCI! Thank You!
  • 25. Let’s test the application • Delivery on 27/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 27/10/2012 00:00 ?
  • 26. Let’s test the application • Delivery on 27/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 27/10/2012 00:00 ? Refund? YES
  • 27. Let’s test the application • Delivery on 26/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 26/10/2012 00:00 ?
  • 28. Let’s test the application • Delivery on 26/10/2012 at 16:00 • It is now 26/10/2012 10:20 • 26/10/2012 10:20 <= 26/10/2012 00:00 ? Refund? NO
  • 29. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ...
  • 30. Can we fix the bug? The fix is really simple!
  • 31. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. ...
  • 32. A new 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") ; }
  • 33. A new 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. Can we fix the bug? The fix is really simple!
  • 35. We finally fix the bug boolean refundAllowed(Product product) { Datetime now = Datetime.now; Datetime final = Datetime.parse("yyyy-MM-dd HH:MM”, product.deliveryAt()); return now <= final ; }
  • 36. Rerun the 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") ; }
  • 37. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. ...
  • 38. “This agile thing is going to be very slow if we do this for every bug!” “Yes, but at least now we have some confidence that the bug is fixed correctly and that we haven’t broken anything else.”
  • 39. “We’ve really applied our team value of ‘quality without compromise’. We took the time to do it right, even if no customer has complained yet.”
  • 40. “We should contact the team that’s responsible for this code and inform them of our correction.” “There may have been customer complaints already. We should contact the customer support people to see if there are complaints and inform them of the existing problem”
  • 41. TIPS • Define and make the team values visible at all times • Keep a list of things to do after the Root Cause Analysis (RCA) • Language: – “We should...” => “We will...”
  • 42. WE WILL... • Contact the development team responsible for this code • Inform the customer support team
  • 43. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. ...
  • 45. THE END And they lived happily ever after...
  • 48. Scene 4: After the fix The tester joins the developers and architect
  • 49. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. ...
  • 50. How can we improve our tests? We should have found this bug sooner
  • 51. How can we improve our tests? We should have will fouind this type of bug sooner
  • 52. How can we improve our tests? We will find this type of bug sooner
  • 53. Context (2) • Almost 80% code coverage with automated unit tests in the whole application • This module has 100% test coverage • But still contains (at least) one bug • Why? • Let’s look at the tests...
  • 54. Who can spot the problem? void testRefundGiven() { Product product = ... product.deliveryAt(“2050-12-31 19:00”) ; BusinessRule businessRule = ... bool allowed = businessRule.refundAllowed(product) }
  • 55. MERCI! Thank You!
  • 56. How can we improve our tests? • There’s no ASSERT ! – It’s easy to get 100% code coverage that way • Why 2050? – What happens on January 1st 2051? • We need at least 4 tests – Delivery before today – Delivery today before now – Delivery today after now – Delivery after today
  • 57. Why? • Developers don’t know how to test date and time (and timezone!)-related code – Lots of tests use dates in 2050 • Few developers with unit testing experience • Agile coaching in the past did not include technical practices
  • 58. We will... • Contact the development team responsible for this code • Inform the customer support team • Add more tests about dates that can serve as examples • Show our example tests to other teams
  • 59. Developers: “we have a lot to learn about unit testing” Architect: “I’ve always had doubts about our automated tests. Now I know why.” Tester: “If you want, I can help you to define and improve tests”
  • 60. Let’s dig deeper... Why tests without ASSERT? • Goal: “increase code coverage of automated tests” instead of “increase quality” • Pressure to “do more with less (money and time)” • Not much experience with unit testing • TEST LAST development instead of Test First • No training or coaching on technical practices • Not all Agile coaches in the company have experience with technical practices
  • 61. We will... • Contact the development team responsible for this code • Inform the customer support team • Add more tests about dates that can serve as examples • Show our example tests to other teams • Apply TDD by pairing with the coach and tester • Raise « lack of technical practice coaching » risk at coach meeting
  • 63. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. ...
  • 65. The End They lived happily ever after... “We have a lot to learn”
  • 68. Scene 5: After the tests A bug never travels alone...
  • 69. Is this bug unique?
  • 70. Let’s search the code... • We find 10 cases where this datetime is parsed – 5 times with “yyyy-MM-dd HH:MM” – 5 times with “yyyy-MM-dd” • Each developer analyses one case • Result: two more bugs
  • 71. What do you say?
  • 72. MERCI! Thank You!
  • 74. MERCI! Thank You!
  • 75. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. LOOK FOR SIMILAR PROBLEMS. GOTO 2 11. ...
  • 77. “Quality without compromise”. Easy to say, hard to do “Writing tests and correcting problems is starting to become routine. It goes faster each time we do it.”
  • 78. Finally, The End? Can we live happily ever after now?
  • 80. Did you spot another problem?
  • 81. MERCI! Thank You!
  • 82. Digging deeper... Why did we introduce the bug? • We aren’t aware that there’s a date+time • We have 10x the same parsing code • => 10 opportunities to make a mistake • Let’s remove the duplication that leads to mistakes
  • 83. Improving Product class Product { ... // Deprecated: Remove when obsolete String deliveryAt() ; // New: gradually refactor all clients DateTime deliveryAtDateTime() ; ... } From “stringly typed” to “strongly typed”
  • 84. 11 steps to perfect code 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. LOOK FOR SIMILAR PROBLEMS. GOTO 2 11. MAKE THIS TYPE OF PROBLEM IMPOSSIBLE
  • 85. TIP • If you think you have to comment your code, think again
  • 86. With comments class A { void methodA() ; // Call methodA before calling these void methodB() ; void methodC() ; } ... a.methodB() ; // ERROR a.methodA() ; // ERROR!!
  • 87. Without comment class A { B methodA() ; } class B { void methodB() ; void methodC() ; } a.methodA().methodB() ;
  • 89. The application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System A ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO Application ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO ABCDEFGHIJKLMNO System B
  • 91. The application(vision) ABCDEFGHIJKLMNO System A L’application ABCDEFGHIJKLMNO System B
  • 93. We will... • Contact the development team responsible for this code • Inform the customer support team • Add more tests about dates that can serve as examples • Show our example tests to other teams • Apply TDD by pairing with the coach and tester • Raise « lack of technical practice coaching » risk at coach meeting • Encapsulate data coming from outside
  • 97. A3 Proposal Problem description BEFORE AFTER STEPS: Visualisation 1. .jdlkjds 2. Kmlkdmlkd 3. Dkqjdlkjds 4. Sqkjlkdlksqmk 5. BEER !
  • 98. TIPS • Keep the A3 visible during the whole refactoring • Put the A3 where it can’t be missed • Limit the number of A3s that can be published
  • 100. Looking back 1. 7 team members + one coach have spent all afternoon to correct a 6-character bug? Is this reasonable? 2. In the end, there were a lot less bugs found in test than on “normal” projects. Is there a link? 3. This project was delivered in 5 months instead of the 8 that were estimated. How can you finish faster by going slower?
  • 101. Theory of Constraints in a nutshell
  • 102. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 ???
  • 103. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 <= 10
  • 104. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 ??? Analysis: Dev: 10 12
  • 105. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 106. What if development speeds up? Test & Analysis: Dev: 20 20 Deploy: 15 ??? Analysis: Dev: 10 12
  • 107. Nothing happens? Test & Analysis: Dev: 20 20 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 108. Buffers start to fill up! Test & Analysis: Dev: 20 20 Deploy: 15 < 15 Analysis: Dev: 10 12
  • 109. How much do they deliver? Test & Analysis: Dev: 20 10 Deploy: 15 <= 15 Analysis: Dev: 10 12
  • 110. What if we go slower? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17 Analysis: Dev: 10 12
  • 111. Why are we analysing so fast? Test & Analysis: Dev: 20 8 Deploy: 17 <= 17 Analysis: Dev: 10 12
  • 112. We do less Test & Dev: <= 17 Analysis: 10 Deploy: 8 17 Analysis: Dev: 10 12
  • 115. How much does quality cost?
  • 116. TIPS • Once you run out of reported bugs... Apply IDD™ Irritation Driven Development Contact me if you want to become a Certifiable Irritating Person
  • 117. TIPS • Pair with the bottleneck – ToC calls this “subordinating” • Walk a mile in their shoes – Carefully observe and note irritations – Quietly remove the irritations • Example: pair-installing dev-ops
  • 119. 11 steps to a life with less stress 1. SPOT A PROBLEM 2. THANK THE REPORTER 3. REPRODUCE THE PROBLEM 4. ADD (AT LEAST) ONE FAILING TEST 5. CORRECT THE PROBLEM 6. AND RERUN ALL TESTS UNTIL THEY PASS 7. PERFORM THE ACTIONS OF THE RCA 8. IMPROVE YOUR TESTS 9. IMPROVE THE WAY YOU WRITE TESTS 10. LOOK FOR SIMILAR PROBLEMS. GOTO 2 11. MAKE THIS TYPE OF PROBLEM IMPOSSIBLE
  • 121. MERCI! Thank You!
  • 122. The End And they lived happily ever after
  • 124. MERCI! Thank You!
  • 125. Thank you, Dank u, Merci, Danke, Tak, Kiitos, Gracias, Grazie, Tack, Obrigado Consults Programs Manages projects Creates Games Organises conferences NAYIMA We make play work http://www.nayima.be http://www.agilecoach.net

Notas do Editor

  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.