Your SlideShare is downloading. ×
 Agile Mëtteg series - Session 5
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Mëtteg series - Session 5

2,921
views

Published on

Agile Testing …

Agile Testing
15 July 2010

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,921
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
43
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • GFA
  • GFA
  • ERF/SZ
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF(+SZ)
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • SZ
  • SZThe goal of unit testing is to isolate each part of the program and show that the individual parts are correct.Unit tests find problems early in the development cycle.A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits.
  • SZ
  • SZMore confidence in the codeAvoid regression: If tests are run frequently the developer can see when new code breaks old code.The tests themselves are documentationEncourages better software design: simpler, smaller methods; less coupling instead of strongly coupled code[Compare introduction, maybe too similar?]
  • SZPrinciples for unit testsIt’s much easier to see:What is being set up and initialized in the arrange section What method is being executed in the act section What determines the outcome of the test in the assert section
  • SZ
  • SZOriginated in XP.Unit tests are essential parts of XP and other agile methods.
  • SZ
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • ERF
  • SZ
  • SZAcceptance tests are specifications for the desired behavior and functionality of a system. WHY?Although acceptance testing traditionally takes place at the end of development or major milestones, in agile software development acceptance testing needs to be performed at the user story level. There are several reasons for why this is important:A passed test case becomes a measure of completeness of a user story; that is, a user story cannot be considered complete till it has passed all acceptance tests associated with it. Even though there is thorough unit testing performed, this is not enough. Unit tests, by their nature, test for a localized used case and are not concerned about the overall system. When we have iterations longer than a couple of weeks, it becomes easy to loose focus on initial agreements; acceptance test cases made for each story at the beginning of each iteration help the developers to keep things within the expectations. Acceptance test cases can serve as an excellent guide to developers to better interpret the requirements from a user story
  • SZFit – the engineThe customers' examples are formatted in tables and saved as HTML using ordinary business tools such as Microsoft Excel. When Fit checks the document, it creates a copy and colors the tables green, red, and yellow according to whether the software behaved as expected. Fitnesse – Also the wiki on topFitNesse allows users of a developed system to enter specially formatted input (its format is accessible to non-programmers). This input is interpreted and tests are created automatically. These tests are then executed by the system and output is returned back to the user. The advantage of this approach is very fast feedback from users. The developer of the system to be tested needs to provide some support (classes named "fixtures", conforming to certain conventions). fast user feedbackERF demo -> score computation dino legs
  • ERF
  • SZI
  • SZBehavior-driven developmentBDD aims to help focus on the delivery of prioritised, verifiable business value by providing a common vocabularyBy using terminology focused on the behavioural aspects of the system rather than testing, BDD attempts to help direct developers towards a focus on the real value to be found in TDD at its most successful. "Behavior-driven development is what you are doing already, if you are doing Test-driven development well." (Dave Astels)Behavior Driven Development is more about interactions with the application than just unit testing. It forces the developer to understand the responsibility of the method he is about to write. Using good tools, the specs written to test the application can be used as specifications. Doing what comes naturallyBDD isn't anything new or revolutionary. It's just an evolutionary offshoot of TDD in which the word "test" is replaced by the word "should." Semantics aside, many people find the concept of should a much more natural development driver than the concept of testing. Thinking in terms of behavior (shoulds) somehow paves the way into writing specification classes first, which, in turn, can be a very efficient implementation driver.For many developers, the shift from test-driven development to BDD is a smart move. With BDD, you don't have to think about tests, you can just pay attention to the requirements of your application and ensure that the application behavior does what it should to meet those requirements. Using BDD to drive development Behavior driven development (BDD) is an evolutionary result of test driven development (TDD) in the sense that rather than thinking in terms of tests (which have the tendency to make you think after the fact) you can more easily think in terms of a specification. By thinking about an application’s specification or behavior, it becomes easier to validate things early– in fact, when thinking in terms of a specification, it becomes quite easy to write things upfront.
  • SZ
  • SZBDD relies on the use of a very specific (and small) vocabulary to minimize miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words. BDD provides a “ubiquitous language” for analysis Around this time, Eric Evans published his bestselling book Domain-Driven Design. In it, he describes the concept of modeling a system using a ubiquitous language based on the business domain, so that the business vocabulary permeates right into the codebase.
  • SZIStructural templatesFeature:As a [X]I want [Y]so that [Z] (In order)The template had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them. We started describing the acceptance criteria in terms of scenarios, which took the following form:Scenarios:Given some initial context (the givens),When an event occurs,then ensure some outcomes.
  • SZIStructural templatesFeature:As a [X]I want [Y]so that [Z] (In order)The template had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them. We started describing the acceptance criteria in terms of scenarios, which took the following form:Scenarios:Given some initial context (the givens),When an event occurs,then ensure some outcomes.
  • SZI
  • ERF
  • SZI
  • SZI
  • Transcript

    • 1. Agile testing
      Agile Mëtteg – 15 July 2010
    • 2. Agile Mëtteg in 2010
      Complete Agile Mëtteg calendar on
      www.agilepartner.net/agility_seminars.html
      15 July 2010
      Agile Mëtteg - Agile Testing
      2
    • 3. OBJECTIVES & AGENDA
      Objectives
      This session will focus on a Agile Testing and provide you with practical examples and techniques to help your team understand what is behind this approach.
      Agenda
      Introduction of Agile Partner
      The attendees
      What is agile testing? And why? And how?
      Unit testing
      Behaviour Driven Development
      Test Driven Development
      Acceptance testing
      Q&A
      15 July 2010
      Agile Mëtteg - Agile Testing
      3
    • 4. AGILE PARTNER SERVICES
      15 July 2010
      Agile Mëtteg - Agile testing
      4
      IS users Services
      1
      Custom Software Development & Maintenance
      Our core business to answer customer needs
      IS services
      Thanks to our expertise we can support IT team to reach their productivity & quality objectives (Assessment, Coaching, Support, Training, Resource delegation…)
      IS Solutions
      Take benefit from commercial or Open Source platform to answer as quick as possible to specific needs
      IS users services
      We can support Product & Services owners to work closely with the IT team (Assessment, Coaching, Support, Training, Resource delegation…)
      4
      Software Development & SoftwareMaintenance
      2
      ISSolutions
      IS Services
      Agility
      Agility
      3
      1
      2
      3
      4
      Agility
    • 5. NEXT TRAININGS & CERTIFICATIONS
      15 July 2010
      Agile Mëtteg - Agile testing
      5
      -15%
      Complete calendar on: http://www.agilepartner.net/training/training_calendar.html
    • 6. Let’s get acquainted
      July 15th, 2010
      Agile Mëtteg – Agile Testing
      6
    • 7. PRESENTATION OF THE ATTENDEES
      Who are you ?
      What is your role ?
      What do you know about agility ?
      What are your expectations ?
      July 15th, 2010
      Agile Mëtteg – Agile Testing
      7
    • 8. AGENDA
      Agenda
      What is agile testing? And why? And how?
      Unit testing
      Test Driven Development
      Acceptance testing
      Behaviour Driven Development
      15 July 2010
      Agile Mëtteg - Agile testing
      8
    • 9. WHAT IS SOFTWARE TESTING?
      Definition:
      Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.
      (Wikipedia)
      15 July 2010
      Agile Mëtteg - Agile testing
      9
    • 10. WHAT IS SOFTWARE TESTING?
      Definition:
      Software testing is a way to measure the quality of the product using tests.
      (Stephan Zimmer & Eric Ferrot)
      15 July 2010
      Agile Mëtteg - Agile testing
      10
    • 11. MEASURING QUALITY
      Measuring quality using tests:
      tests to find defects
      functional / non-functional testing
      a LOT of kinds of tests
      15 July 2010
      Agile Mëtteg - Agile testing
      11
    • 12. 15 July 2010
      Agile Mëtteg - Agile testing
      12
      SO WHAT IS AGILE TESTING ?… AND WHY?… AND HOW?
    • 13. Traditional / Waterfall approach
      Testing is done after the development
      WHAT IS AGILE TESTING?
      15 July 2010
      Agile Mëtteg - Agile testing
      13
    • 14. Agile approach
      Testing is part of the development process
      WHAT IS AGILE TESTING?
      15 July 2010
      Agile Mëtteg - Agile testing
      14
      Iteration 1
      Iteration 2
      Iteration n
      No specific order
    • 15. WHAT IS AGILE TESTING?
      15 July 2010
      Agile Mëtteg - Agile testing
      15
      Programmer
      Traditional / Waterfall approach
      Testing is done after the development
      Clear separation of roles
      Domain Expert
      Tester
    • 16. Agile approach
      Testing is part of the development process
      A whole team
      WHAT IS AGILE TESTING?
      15 July 2010
      Agile Mëtteg - Agile testing
      16
      Programmer
      Programmer
      Domain Expert
      Tester
      Tester
    • 17. Agile testing places an increased portion of the testing in the hands of the developers
      Wait… WHAT?!?!
      I’m a programmer not a tester
      It’s trivial I don’tneed a test
      I don’t have time for testing
      My code isverydifficult to test
      WHAT IS AGILE TESTING?
      15 July 2010
      Agile Mëtteg - Agile testing
      17
    • 18. WHY AGILE TESTING?
      WHY should developers write tests?
      Fear / Confidence
      Do you dare to change the code?
       Tests = safety net
      It places developers as users
       Better usability
      It makes the code testable
       Better design
      15 July 2010
      Agile Mëtteg - Agile testing
      18
    • 19. WHY AGILE TESTING?
      A better design
      “How good the design is doesn't matter near as much as whether the design is getting better or worse.
      If it is getting better, day by day, I can live with it forever.
      If it is getting worse, I will die.”
      (Kent Beck )
      15 July 2010
      Agile Mëtteg - Agile testing
      19
    • 20. AGILE TESTING… HOW?
      Agile testing… HOW?
      Unit testing
      Test Driven Development
      Acceptance testing
      Behaviour Driven Development
      15 July 2010
      Agile Mëtteg - Agile testing
      20
    • 21. BUT FIRST…
      15 July 2010
      Agile Mëtteg - Agile testing
      21
    • 22. LET US INTRODUCE YOU TO…
      15 July 2010
      Agile Mëtteg - Agile testing
      22
      TIME MASTER TIM!
    • 23. AGILE TESTING… HOW?
      DINO LEGS
      A real project
      A new feature:
      „The Crystal Quest“
      15 July 2010
      Agile Mëtteg - Agile testing
      23
      http://dinolegs.blogspot.com/
    • 24. UNIT TESTING
      15 July 2010
      Agile Mëtteg - Agile testing
      24
    • 25. UNIT TESTING
      Definitions
      Unit :
      Smallest testable part of an application
      Unit test :
      A method to test a unit
      15 July 2010
      Agile Mëtteg - Agile testing
      25
    • 26. UNIT TESTING
      Some bad things about unit tests:
      Expensive to write and expensive to maintain
      You can test too much
      You can test the wrong things
      Possibility to get false sense of security when all tests pass
      No integration tests
      15 July 2010
      Agile Mëtteg - Agile testing
      26
    • 27. UNIT TESTING
      Why write unit tests?
      More confidence in the code
      Avoid regression
      Tests themselves are documentation
      Encourages better software design: minimal interfaces and modularity
      15 July 2010
      Agile Mëtteg - Agile testing
      27
    • 28. UNIT TESTING
      The „3A“ pattern
      Arrange
      Act
      Assert
      15 July 2010
      Agile Mëtteg - Agile testing
      28
    • 29. UNIT TESTING
      F.I.R.S.T.
      Fast
      Independent
      Repeatable
      Self-Validating
      Timely
      [Clean Code – Robert C. Martin]
      15 July 2010
      Agile Mëtteg - Agile testing
      29
    • 30. UNIT TESTING
      „The act of writing a unit test is more an act of design than of verification“
      (Robert C. Martin)
      15 July 2010
      Agile Mëtteg - Agile testing
      30
    • 31. UNIT TESTING
      A lot of existing unit testing…
      xUnit (NUnit, Junit, csUnit, …), MSTest, Pex, Visual Studio UTF, etc.
      …and mocking frameworks
      Moq, Rhino Mocks, Moles, TypeMock, JMock, etc.
      15 July 2010
      Agile Mëtteg - Agile testing
      31
    • 32. TEST DRIVEN DEVELOPMENT (TDD)
      15 July 2010
      Agile Mëtteg - Agile testing
      32
    • 33. TEST DRIVEN DEVELOPMENT (TDD)
      15 July 2010
      Agile Mëtteg - Agile testing
      33
      Unit Test
      What is TDD?
      Difference to unit testing
      Write the unit test
      Code
      FIRST!
    • 34. TEST DRIVEN DEVELOPMENT (TDD)
      What is TDD?
      Difference to unit testing
      Write the unit test FIRST!
      « Red – Green – Refactor » pattern
      15 July 2010
      Agile Mëtteg - Agile testing
      34
    • 35. TEST DRIVEN DEVELOPMENT (TDD)
      Red – Green – Refactor
      Make it failwrite the test first
      Make it workwrite the simplest implementation
      Make it betterrefactor without changing the behavior
      15 July 2010
      Agile Mëtteg - Agile testing
      35
    • 36. TEST DRIVEN DESIGN (TDD)
      TDD is not only about testing
      Also called Test Driven Design
      TDD is a methodology that helps creating a good design when developing code.
      15 July 2010
      Agile Mëtteg - Agile testing
      36
    • 37. TEST DRIVEN DESIGN (TDD)
      TDD is not only about testing
      Also called Test Driven Design
      TDD consequences
      YAGNI
      DRY
      Law of Demeter
      Single responsibility principle
      Interface segregation principle
      Inversion of control
      15 July 2010
      Agile Mëtteg - Agile testing
      37
      GOOD DESIGN !
    • 38. TEST DRIVEN DEVELOPMENT (TDD)
      DEMO
      15 July 2010
      Agile Mëtteg - Agile testing
      38
    • 39. ACCEPTANCE TESTING
      15 July 2010
      Agile Mëtteg - Agile testing
      39
    • 40. ACCEPTANCE TESTING
      Unit testing tells us that the code is meeting the programmer‘s expectations
      Unit testing is essential but not sufficient
      Acceptance tests are specifications for the
      desired behaviour and functionality of a system.
      Customer oriented
      About the what and not the how
      Usually black box system tests
      Integration tests character
      15 July 2010
      Agile Mëtteg - Agile testing
      40
    • 41. ACCEPTANCE TESTING
      Implementing acceptance tests
       means automation
      Examples of automation tools:
      Framework for Integrated Test (Fit) is an open-source tool for automated acceptance test
      Fitnesse is a webserver, a wiki and an automated testing tool based on Fit
      15 July 2010
      Agile Mëtteg - Agile testing
      41
    • 42. ACCEPTANCE TESTING
      DEMO
      15 July 2010
      Agile Mëtteg - Agile testing
      42
    • 43. BEHAVIOUR DRIVEN DEVELOPMENT (BDD)
      15 July 2010
      Agile Mëtteg - Agile testing
      43
    • 44. BEHAVIOUR DRIVEN DEVELOPMENT
      Behaviour Driven Development (BDD)
      Evolution of TDD introduced by Dan North
      Using terminology focused on the behavioural aspects of the system rather than testing
       Unit ≠ behaviour
       Focus on why the code should be created
       Business value > Code
       Specification > Test
      15 July 2010
      Agile Mëtteg - Agile testing
      44
    • 45. BEHAVIOUR DRIVEN DEVELOPMENT
      Outside-in methodology
       from the known to the unknown
      Helps the developer to think YAGNI
       Leads to better design
       BDD = Behaviour Driven Design
      Don‘t forget about the roots (TDD)
       Red – Green – Refactor
      15 July 2010
      Agile Mëtteg - Agile testing
      45
    • 46. BEHAVIOUR DRIVEN DEVELOPMENT
      Programmer
      Ubiquitous language
      based on the business domain
      Common vocabulary between participants
      Minimizes translation
      Avoids miscommunication
      Makes it easier to validate early
      Domain Expert
      Tester
      15 July 2010
      Agile Mëtteg - Agile testing
      46
    • 47. BEHAVIOUR DRIVEN DEVELOPMENT
      Story framework
      Each feature is captured in a „story“, which defines the scope of the feature along with its acceptance criteria
      Feature
      Feature: Title
      As a [role]
      I want [feature]
      so that [benefit]
      Feature: Crystal quest
      As a player
      I want to collect time crystals
      so that I am able to complete the crystal quest
      15 July 2010
      Agile Mëtteg - Agile testing
      47
    • 48. BEHAVIOUR DRIVEN DEVELOPMENT
      Scenario / Acceptance criteria
      Scenario:Title
      Given some initial context,
      And some additional context,
      When an event occurs,
      Then ensure some outcomes
      Scenario 1:Tim loses a crystal
      Given a Tim is on screen
      And a crystal is on screen,
      When Tim dies,
      Then the crystal disappears
      And Tim‘s player score is decreased by 20
      Scenario 2:Tim collects a crystal
      Given Tim is on screen
      And a crystal is on screen,
      When Tim touches the crystal,
      Then the crystal disappears
      And a nice music is played
      And Tim‘s player score is increased by 100
      15 July 2010
      Agile Mëtteg - Agile testing
      48
    • 49. BEHAVIOUR DRIVEN DEVELOPMENT
      Several existing tools for automation
      JBehave, NBehave, JSpec, NSpec, CppSpec, PHPSpec, SpecFlow, RSpec, Cucumber, …
       Executable specification
       Quick feedback and regression testing
       Requirements are tests
       Tests are documentation
      15 July 2010
      Agile Mëtteg - Agile testing
      49
    • 50. BEHAVIOUR DRIVEN DEVELOPMENT
      DEMO
      15 July 2010
      Agile Mëtteg - Agile testing
      50
    • 51. SUMMARY
      15 July 2010
      Agile Mëtteg - Agile testing
      51
    • 52. SUMMARY
      Some things to remember about Agile Testing:
      Testing is part of the development process
      Whole-team approach: roles not that strictly separated as in traditional approach
      Building a testable architecture leads to a better design
      ... and don‘t forget!
      Setup a working environment
      15 July 2010
      Agile Mëtteg - Agile testing
      52
    • 53. QUESTIONS
      53
      Agile Mëtteg - Agile testing
      15 July 2010
    • 54. NEXT TRAININGS & CERTIFICATIONS
      15 July 2010
      Agile Mëtteg - Agile testing
      54
      Complete calendar on: http://www.agilepartner.net/training/training_calendar.html
    • 55. RESOURCES
      Agile Partner: www.agilepartner.net
      Agile Interest Group Luxembourg:www.aiglu.org
      Agile Alliance: www.agilealliance.org
      Scrum alliance: www.scrumalliance.org
      Scrum.org
      15 July 2010
      Agile Mëtteg - Agile testing
      55
    • 56. CONTACTS
      Thank You
      15 July 2010
      Agile Mëtteg - Agile testing
      56

    ×