Agile Mëtteg #5: Agile Testing
•Als PPTX, PDF herunterladen•
1 gefällt mir•564 views
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.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Agile Mëtteg #5: Agile Testing
Ähnlich wie Agile Mëtteg #5: Agile Testing (20)
Mehr von Agile Partner S.A.
Mehr von Agile Partner S.A. (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Agile Mëtteg #5: Agile Testing
- 2. 25 June 2015 Agile Mëtteg : Agile Testing
- 3. 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 Let’s get acquainted What is agile testing? Unit testing Test Driven Development Acceptance testing Behavior Driven Development Q&A 28 Feb. 2013 3 OBJECTIVES & AGENDA Introduction to agile methods
- 4. LET’S GET ACQUAINTED 28 Feb. 2013 4Introduction to agile methods
- 5. 28 Feb. 2013 Introduction to agile methods 5 Eric FERROT Senior Software Developer ME
- 6. 6. AGILE PARTNER 28 Feb. 2013 Introduction to agile methods 6 Software Development Knowledge Transfer Innovation Support Consulting
- 7. YOU What about you? What do you know about agility? What are your expectations? 28 Feb. 2013 Introduction to agile methods 7
- 8. WHAT IS AGILE TESTING? 28 Feb. 2013 8Introduction to agile methods
- 9. WHAT IS TESTING? 28 Feb. 2013 9Introduction to agile methods
- 10. 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)
- 11. WHAT IS SOFTWARE TESTING? Definition: Software testing is a way to measure the quality of the product using tests. (me)
- 12. MEASURING QUALITY Measuring quality using tests: tests to find defects functional / non-functional testing Manual / automated tests a LOT of kinds of tests 15 July 2010 12
- 13. SO WHAT IS AGILE TESTING ? … AND WHY? … AND HOW?
- 14. Traditional / Waterfall approach Testing is done after the development Requirements Analysis Design Development Test Release WHAT IS AGILE TESTING? 15 July 2010 Agile Mëtteg - Agile testing 14
- 15. Agile approach Testing is part of the development process WHAT IS AGILE TESTING? 15 July 2010 Agile Mëtteg - Agile testing 15 Iteration 1 Iteration 2 Iteration n No specific order
- 16. Traditional / Waterfall approach Testing is done after the development Clear separation of roles WHAT IS AGILE TESTING? 15 July 2010 Agile Mëtteg - Agile testing 16 Programmer Domain Expert Tester
- 17. Agile approach Testing is part of the development process A whole team WHAT IS AGILE TESTING? 15 July 2010 Agile Mëtteg - Agile testing 17 Programmer Domain Expert Tester Programmer Tester
- 18. 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’t need a test I don’t have time for testing My code is very difficult to test WHAT IS AGILE TESTING?
- 19. 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 19
- 20. 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 )
- 21. AGILE TESTING… HOW? Agile testing… HOW? Unit testing Test Driven Development Acceptance testing Behaviour Driven Development
- 22. BUT FIRST… 15 July 2010 22
- 23. A PAGE OF ADVERTISMENT! 15 July 2010 23
- 25. UNIT TESTING
- 26. UNIT TESTING Definitions Unit : Smallest testable part of an application Unit test : A method to test a unit
- 27. UNIT TESTING The „3A“ pattern Arrange Act Assert
- 28. UNIT TESTING F.I.R.S.T. Fast Independent Repeatable Self-Validating Timely [Clean Code – Robert C. Martin]
- 38. TEST DRIVEN DEVELOPMENT (TDD) What is TDD? Difference to unit testing Write the unit test Unit TestCode FIRST!
- 39. TEST DRIVEN DEVELOPMENT (TDD) Red – Green – Refactor Make it fail write the test first Make it work write the simplest implementation Make it better refactor without changing the behavior 15 July 2010 Agile Mëtteg - Agile testing 44 Test CodeRefactor
- 40. TEST DRIVEN DEVELOPMENT (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.
- 41. TEST DRIVEN DEVELOPMENT (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 GOODDESIGN!
- 42. TEST DRIVEN DEVELOPMENT (TDD) DEMO
- 43. TEST DRIVEN DEVELOPMENT (TDD)
- 44. TEST DRIVEN DEVELOPMENT (TDD)
- 45. TEST DRIVEN DEVELOPMENT (TDD)
- 46. TEST DRIVEN DEVELOPMENT (TDD)
- 48. 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 53
- 49. 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 54
- 51. BEHAVIOUR DRIVEN DEVELOPMENT (BDD) 15 July 2010 Agile Mëtteg - Agile testing 56
- 52. 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 57
- 53. 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 58
- 54. BEHAVIOUR DRIVEN DEVELOPMENT Ubiquitous language based on the business domain Common vocabulary between participants Minimizes translation Avoids miscommunication Makes it easier to validate early 15 July 2010 Agile Mëtteg - Agile testing 59 Domain Expert Programmer Tester
- 55. 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: End of Agile Mëtteg session As a speaker I want to end the session in a beautiful way So that the audience is very impressed
- 56. 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 saves some dino eggs Given Tim is on screen And Tim is holding 3 eggs, When Tim warps out, Then the eggs disappear And player‘s score is increased by 6 points Scenario 2: Tim collects a red lock Given Tim is on screen And a red lock is on screen, When Tim touches the red lock, Then the red lock disappears And a nice message is shown And a wonderful music is played
- 57. 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 62
- 58. BEHAVIOUR DRIVEN DEVELOPMENT DEMO 15 July 2010 Agile Mëtteg - Agile testing 63
- 59. SUMMARY 15 July 2010 Agile Mëtteg - Agile testing 64
- 60. SUMMARY Some things to remember about Agile Testing: Testing is part of the development process Whole-team approach: roles are not strictly separated like in a traditional approach Building a testable architecture leads to a better design Unit tests and acceptance tests are complementary Use agile practices: TDD, BDD, Continuous Integration
- 61. QUESTIONS & ANSWERS 28 Feb. 2013 Introduction to agile methods 66
- 62. YOUR FEEDBACK 28 Feb. 2013 67Introduction to agile methods
- 63. R.O.T.I for this SESSION 28 Feb. 2013 Introduction to agile methods 68 Source: www.qualitystreet.fr
- 64. THANK YOU 28 Feb. 2013 72Introduction to agile methods Retrouvez nous sur : Agile Partner: www.agilepartner.net & http://blog.agilepartner.net
Hinweis der Redaktion
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF(+SZ)
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- SZ
- SZ The 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
- SZ More confidence in the code Avoid regression: If tests are run frequently the developer can see when new code breaks old code. The tests themselves are documentation Encourages better software design: simpler, smaller methods; less coupling instead of strongly coupled code [Compare introduction, maybe too similar?]
- SZ Principles for unit tests It’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
- SZ Originated in XP. Unit tests are essential parts of XP and other agile methods.
- SZ
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- ERF
- SZ
- SZ Acceptance 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
- SZ Fit – the engine The 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 top FitNesse 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 feedback ERF demo -> score computation dino legs
- ERF
- SZI
- SZ Behavior-driven development BDD aims to help focus on the delivery of prioritised, verifiable business value by providing a common vocabulary By 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 naturally BDD 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
- SZ BDD 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.
- SZI Structural templates Feature: 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 Structural templates Feature: 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