Agile Mëtteg series - Session 5
•Télécharger en tant que PPTX, PDF•
1 j'aime•2,260 vues
Agile Testing 15 July 2010
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (12)
Similaire à Agile Mëtteg series - Session 5
Similaire à Agile Mëtteg series - Session 5 (20)
Plus de Agile Partner S.A.
Plus de Agile Partner S.A. (20)
Dernier
Dernier (20)
Agile Mëtteg series - Session 5
- 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
Notes de l'éditeur
- 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