Recommended
Recommended
More Related Content
What's hot
What's hot (10)
Viewers also liked
Viewers also liked (13)
Similar to Agile testen vts politie Nederland
Similar to Agile testen vts politie Nederland (20)
Recently uploaded
Recently uploaded (20)
Agile testen vts politie Nederland
- 1. AGILE TESTING NAJAARS EVENEMENT VOOR VTSPN TEST PROFESSIONALS PASCAL DUFOUR, NOV 2011 CODECENTRIC AG
- 2. SPEAKER PASCAL DUFOUR • AGILE TEST CONSULTANT AND SCRUM MASTER • TESTER FOR MORE THAN 12 YEARS • ORGANIZER ONLINE CONFERENCE THE BATHTUB CONFERENCE. • BACKGROUND IN JAVA AND .NET TECHNOLOGY. • BLOG PASCALDUFOUR.NL • TWITTER @PASCAL_DUFOUR CODECENTRIC NEDERLAND
- 3. TESTING • WHY AGILE TESTING? • HOW AGILE TESTING? • THE ROLE OF AN AGILE TESTER. CODECENTRIC NEDERLAND
- 4. QUESTION? • WHAT IS AGILE? • WHAT IS THE ROLE OF AN TESTER IN AGILE? CODECENTRIC NEDERLAND
- 5. AGILE IS FEEDBACK • TO THE PRODUCT OWNER • TO THE DEVELOPER • TO THE BUSINESS • TO THE COSTUMER • TO THE QA • TO THE ARCHITECT • TO THE TESTER • TO ....... SUCCESS BY AGILITY CODECENTRIC NEDERLAND 5
- 6. WHY AGILE TESTING? CODECENTRIC NEDERLAND 6
- 7. SELF-ASSESSMENT I IN YOUR EXPERIENCE, HOW MANY PROJECTS STAYED IN BUDGET AND DELIVERED ON TIME? 0% 100% SOURCE: ANDREAS CODECENTRIC NEDERLAND 11/13/11 7
- 8. SUCCESS OF SOFTWARE PROJECTS 32% 44% succeeding cancelled challenged 24% SOURCE: CHAOS REPORT 2009, STANDISH GROUP CODECENTRIC NEDERLAND SOURCE: ANDREAS
- 9. SELF-ASSESSMENT II HOW LARGE IS THE FRACTION OF REQUIREMENTS KNOWN AT THE BEGINNING OF A PROJECT COMPARED TO THE RELEASED PRODUCT? 0% 100% SOURCE: ANDREAS CODECENTRIC NEDERLAND 11/13/11 9
- 10. KNOWLEDGE OF REQUIREMENTS Requirements Usage of implemented Req‘s 35% 65% 60% often new or changed seldom or never unchanged SOURCE: SCRUM IN DEPTH, KEN SCHWABER CODECENTRIC NEDERLAND
- 11. ORIGINS OF DEFECTS HUMAN LOGIC/DESIGN DOCUMENTATION 5% ENVIRONMENT 28% 2% 5% DATA 6% INTERFACE 6% OTHERS 7% REQUIREMENTS ERRORS 41% CODECENTRIC NEDERLAND
- 12. ORIGINS OF DEFECTS HUMAN LOGIC/DESIGN DOCUMENTATION 5% ENVIRONMENT 28% 2% 5% DATA 6% INTERFACE 6% OTHERS 7% REQUIREMENTS ERRORS TOM GILB. 2002 41% CODECENTRIC NEDERLAND
- 13. "THIS CREATIVE DESIGN PROCESS IS COMPLICATED BY THE GENERALLY POOR STATUS OF MOST REQUIREMENTS DESCRIPTIONS. THIS IS NOT BECAUSE THE USERS OR THE SYSTEM'S DESIGNERS ARE INCOMPETENT BUT BECAUSE OF WHAT I CALL THE REQUIREMENTS UNCERTAINTY PRINCIPLE: FOR A NEW SOFTWARE SYSTEM, THE REQUIREMENTS WILL NOT BE COMPLETELY KNOWN UNTIL AFTER THE USERS HAVE USED IT. CODECENTRIC NEDERLAND 11/13/11 12
- 14. COMPLEX PROBLEM UNCERTAINTY IS INHERENT AND INEVITABLE IN SOFTWARE DEVELOPMENT PROCESSES AND PRODUCTS. (ZIV‘S UNCERTAINTY PRINCIPLE IN SOFTWARE ENGINEERING) CODECENTRIC NEDERLAND 11/13/11 SOURCE: CESARIO RAMOS 13
- 15. PRODUCTION VS. PRODUCT DEVELOPMENT WHAT ARE CHARACTERISTICS OF PRODUCTION AND PRODUCT DEVELOPMENT? WHAT DOES IT MEAN FOR THE APPROACH? CODECENTRIC NEDERLAND SOURCE: CESARIO RAMOS
- 16. HOW DO WE DO TESTING TODAY? CODECENTRIC NEDERLAND 15
- 17. TESTING CODECENTRIC NEDERLAND 11/13/11 16
- 18. Requirements Test Code Specifications Verify POPPENDIECK. CODECENTRIC NEDERLAND 2010
- 19. Requirements e ss o c p r ti on Test ec Code Specifications n j ct-i e fe D Verify POPPENDIECK. CODECENTRIC NEDERLAND 2010
- 21. HOW AGILE TESTING? CODECENTRIC NEDERLAND 19
- 22. WHAT CAN WE DO? •REDUCE THE DELAY BETWEEN MAKING A MISTAKE AND FINDING THE MISTAKE. •IMPROVE COLLABORATION BETWEEN BUSINESS, TESTING AND DEVELOPMENT. •POSSIBILITY FOR DEFERRING DECISIONS. •EASILY ESTIMATION AND PRIORITIZATION RELEARNING DELAY HAND- OFFS DEFECTS CODECENTRIC NEDERLAND
- 23. Implemented and accepted throughout the project CODECENTRIC NEDERLAND SOURCE: CESARIO RAMOS
- 24. Requirements are prioritized, refined and written down in collaboration. CODECENTRIC NEDERLAND SOURCE: CESARIO RAMOS
- 26. e nt cr em d In a n n a tio Iter e ry E v CODECENTRIC NEDERLAND
- 27. Knowledge transfer Specification Development Verification
- 28. Knowledge transfer Specification Development Verification
- 29. Knowledge transfer Specification Development Verification
- 30. A-TDD (ACCEPTANCE TEST DRIVEN DEVELOPMENT) “EXAMPLE ISN'T ANOTHER WAY TO TEACH, IT IS THE ONLY WAY TO TEACH” CODECENTRIC NEDERLAND
- 31. A-TDD (ACCEPTANCE TEST DRIVEN DEVELOPMENT) • INCREASES LEARNING • IMPROVES FEEDBACK CYCLE • EXAMPLES ARE IMAGINABLE • ENABLES YOU TO VERIFY THAT THINGS ARE IMPLEMENTED COMPLETELY AND CORRECTLY “EXAMPLE ISN'T ANOTHER WAY TO TEACH, IT IS THE ONLY WAY TO TEACH” CODECENTRIC NEDERLAND
- 32. Discuss in Develop in Deliver for workshop concurrence acceptance Automatic acceptance/functional testing Exploratory/Usability testing CONTINUOUSLY RUN ALL TESTS INCLUDING NON 26 FUNCTIONAL TESTS CODECENTRIC NEDERLAND 11/13/11
- 33. A-TDD IDEAS • TESTS AS REQUIREMENTS • AS FORMALITY INCREASES TESTS AND REQUIREMENTS BECOME INDISTINGUISHABLE • WORKSHOPS FOR CLARIFYING REQUIREMENTS • THE MOST EFFECTIVE WAY OF CONVEYING INFORMATION IS FACE- TO-FACE CONVERSATION • CONCURRENT ENGINEERING • TWO WEEK ITERATIONS WHERE TESTED SOFTWARE IS DELIVERED • PREVENTION RATHER THEN DETECTION • THE PURPOSE OF TESTING MUST BE PREVENTION • IT’S NOT ABOUT FINDING DEFECTS! CODECENTRIC NEDERLAND 11/13/11 27
- 34. HOW? Requirements ELABORATE VERIFY Executable Specification Tests Examples CAN BECOME CODECENTRIC NEDERLAND 11/13/11 28
- 35. TESTS AS REQUIREMENTS CANCELLATION POLICY FOR ALL IN AGREEMENTS • CANCELLATION MORE THEN 6 MONTHS BEFORE ARRIVAL, NO COSTS • CANCELLATION MORE THEN 3 MONTHS BEFORE ARRIVAL, 10% OF THE TOTAL PRICE • CANCELLATION MORE THEN 2 MONTHS BEFORE ARRIVAL, 15% OF THE TOTAL PRICE • CANCELLATION MORE THEN 1 MONTH BEFORE ARRIVAL, 35% OF THE TOTAL PRICE • CANCELLATION MORE THEN 14 DAYS BEFORE ARRIVAL, 60% OF THE TOTAL PRICE • CANCELLATION MORE THEN 7 DAYS BEFORE ARRIVAL, 85% OF THE TOTAL PRICE • CANCELLATION LESS THEN 7 DAYS BEFORE ARRIVAL, 100% OF THE TOTAL PRICE CODECENTRIC NEDERLAND 11/13/11 SOURCE: CESARIO RAMOS 29
- 36. ANOTHER REQUIREMENT EXAMPLE CODECENTRIC NEDERLAND 11/13/11 SOURCE: CESARIO RAMOS 30
- 37. IT IS ALSO A TEST CODECENTRIC NEDERLAND 11/13/11 SOURCE: CESARIO RAMOS 31
- 38. AND SO IS THIS ONE CODECENTRIC NEDERLAND 11/13/11 SOURCE: CESARIO RAMOS 32
- 39. CODECENTRIC NEDERLAND 11/13/11 SOURCE: CESARIO RAMOS 33
- 40. AGILE TESTER • HELPS THE TEAM FIGURE OUT WHAT NEEDS TO BE DONE IN THE SPRINT. • CONTINUOUSLY PROVIDE FEEDBACK TO THE REST OF THE TEAM TO ENSURE THE RIGHT THING IS BUILD CORRECTLY THE FIRST TIME. • WORKS ON REQUIREMENT EXAMPLES PRIOR TO SPRINT PLANNING TOGETHER WITH THE REQUIREMENTS PEOPLE. • EFFECTIVE COLLABORATION WITH YOUR OTHER TEAM MEMBERS. • HAVE AUTOMATIC REGRESSION TESTS AVAILABLE EVERY BUILD. • HAS GREAT SKILLS IN EXPLORATORY TESTING • FIND DEFECTS EARLIER. CODECENTRIC NEDERLAND
- 41. AGILE TESTING NAJAARS EVENEMENT VOOR VTSPN TEST PROFESSIONALS PASCAL DUFOUR, NOV 2011 CODECENTRIC AG
- 42. Real life example Let’s say we have software running version 3.6. The product owner want feature A to be in for the release 4.0.
- 43. CODECENTRIC NEDERLAND SOURCE: CESARIO RAMOS
- 44. Process PBL (user stories) BDD Specification , SBL 1 Software Capability SBL 2 Development Attack Plan Capability SBL 3 Software Improvement SBL ….. Execute BDD Delivery Plan Specification + Exploratory test Report Evidence Risk Analysis Product (Plan) Functional specification For release For release
- 45. Delivery and responsibility Delivery Capability Improvement Product Backlog Specificatio Software with risk analysis Specification n / Test Delivery (CIS) Risk Analysis Test Report (Test / specification Evidence Plan) Product Functional Spec. Responsible Product Product Development Development Development Manager Owner Team Team Team
- 46. Traceability Delivery Capability Improvement Specificatio Specification n / Test (CIS) Product Backlog with risk analysis Responsible Product Product Development Development Development Manager Owner Team Team Team
- 47. Traceability Delivery Capability Improvement Specificatio Specification n / Test (CIS) Product Backlog with risk analysis Product Functional Responsible Product Product Development Development Development Manager Owner Team Team Team
- 48. User story Risk Analysis For specification Brief description Brief description + acceptance + acceptance Make criteria criteria + HMI sketches + Initial HMI Brief description + Demonstration Brief description checklist Buy known unknown feedback
- 49. Testing triangle by Patrick Wilson-Welsh
- 50. User story Risk Analysis For testing Exploratory test Automatic acceptance charter. test Impact Exploratory test charter / scenario (test cases) Integration test Exploratory test charter / checklist Error guessing likelihood
- 51. Create a test plan • Test plan consist of • What (not) to test (scope) • How to test RISK mitigation • PRA on user stories • What techniques to use based on risk
- 52. Create test dashboard The test dashboard consist of the translation of the test plan into • The (non) functional status (the green lights) • Regression test • Technical (software craftsmanship) • Performance test • Security test • Usability .............
- 53. WIKI overview
- 54. Continuous Integration and Continuous deploying
- 55. DOD
- 56. DOD • Ship it
- 57. DOD • Ship it • (or)
- 58. DOD • Ship it • (or) • DOD for sprint
- 59. DOD • Ship it • (or) • DOD for sprint • DOD for product release
- 60. Software test rapport • It is the retrospective of the test and advice to the product owners and its stake holders • Did we do what we promised. • DOD • if not? why
Editor's Notes
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Watts S. Humphrey. A Discipline for Software Engineering. SEI Series in Software Engineering.\nAddison-Wesley, 1995.\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Want to know if it really works, see of the specs are good or full of errors!\n
- Prioritized and\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Lisa crispin and janet gregory refers to this one.\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- James Marcus bach\n\nNear the beginning of the project, rapid testing is often a process of very rapid cycles of determining that there are major problems. Our focus is mostly on learning and developing the infrastructure for better testing, later on.\nIn the middle of the project, we are find a lot of problems. We feel productive.\nIt’s near the end of the project that rapid testing becomes very important, because we have very little time to discover whether the product has been seriously degraded by that most recent change. A year long project can come down to an hour or two of retesting at the end. This is where rapid testing skill becomes very important\n
- \n
- \n
- \n