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
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
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
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
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
44. Process
PBL (user stories) BDD
Speciļ¬cation ,
SBL 1
Software
Capability SBL 2 Development
Attack Plan
Capability SBL 3
Software
Improvement SBL ā¦.. Execute BDD Delivery
Plan Speciļ¬cation
+ Exploratory
test
Report
Evidence
Risk Analysis Product
(Plan) Functional
speciļ¬cation
For release For release
45. Delivery and responsibility
Delivery
Capability
Improvement Product Backlog Speciļ¬catio Software
with risk analysis
Speciļ¬cation n / Test Delivery
(CIS)
Risk Analysis Test Report
(Test / speciļ¬cation Evidence
Plan)
Product
Functional
Spec.
Responsible
Product Product Development Development Development
Manager Owner Team Team Team
46. Traceability
Delivery
Capability
Improvement Speciļ¬catio
Speciļ¬cation n / Test
(CIS)
Product
Backlog
with risk analysis
Responsible
Product Product Development Development Development
Manager Owner Team Team Team
47. Traceability
Delivery
Capability
Improvement Speciļ¬catio
Speciļ¬cation 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 speciļ¬cation
Brief description Brief description
+ acceptance + acceptance
Make
criteria criteria
+ HMI sketches + Initial HMI
Brief description
+ Demonstration
Brief description checklist
Buy
known unknown
feedback
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 .............
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
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