Invitation to collaborate on A-TDD Research, presented at the 1st International Workshop on Test-driven Development (TDD 2010), co-located with the 3rd International Conference on Software Testing, Verification and validationICST 2010 - April 10, 2010 – Paris, France

1. A-TDD Research
Collaboration
Catherine Louis & Raj Mudhar

2. Catherine Louis
• Independent contractor, founder CLL-Group -
www.cll-group.com
• Specializing in Agile transitions in the scope of
large, multi-nodal solutions, high-reliability systems,
with large teams of several hundred to several
thousand R&D employees.
• Over 20 years of software development
experience in complex product development in
large telecommunications firms. Her focus is on
Agile methods, Agile R&D, and managing
Organizational Agile transitions

3. Raj Mudhar
• Leading the Agile transition in the W-CDMA
business at ALU, serving a population of over 3000
as servant-leader - www.rajile.com
• Over 15 years of development experience in large-
scale complex product development for high-
reliability telecom solutions.
• Pioneer in outsourcing partnerships, created best-
in-class high-performance development teams in
India
• Instrumental in setting up and running the R&D
joint venture with LG-Nortel, building & deploying
the nation-wide W-CDMA network in Korea.

4. “Instead of waiting for the next big thing to transform
our lives, why don't we give it a shot ourselves?”

5. A-TDD
ACCEPTANCE TEST DRIVEN DEVELOPMENT

6. Story
+ Acceptance Test
Requirement

7. WHY A-TDD?
• Acceptance tests are needed to show Done-
Done at the Story level
• Written in Behaviour-driven text (exactly
how the Customer defines done!)
• Large Requirements get broken down into
Testable stories by elaborating on the
scenarios
• Executable Requirements documentation
become the Automated acceptance tests

8. Test Driven Development
If a User Story cannot be acceptance tested, then
how do you know it can be DONE-DONE?
Acceptance
“The Power of Three” - Lisa Crispin, “Agile Testing”
http://lisacrispin.com/wordpress/ Test
(every feature)
Unit Test
(every few
lines of code)

9. TDD exists on 2 levels
• Level 1 - Unit Test - get into the habit of defining tests
before writing code
• Express design requirements as tests
• Automate the tests
• Level 2 - Acceptance test - Involve System Test at the
front end to drive requirements to testability of the
the sub-stories.
• We need to gain experience breaking epic user
stories into sub-stories and link the related
acceptance at the sub-story level to the epic level.
•Maximize test automation

10. Ready-Ready to Done-Done

11. Ready-Ready to Done-Done
Acceptance
Defined

12. Ready-Ready to Done-Done
Acceptance Definition of
Defined Done

13. Ready-Ready to Done-Done
Acceptance Definition of
Defined Sprint Done
1 to 4 wks

14. Ready-Ready to Done-Done
Daily Standup
Acceptance Definition of
Defined Sprint Done
1 to 4 wks

15. Ready-Ready to Done-Done
Daily Standup
Acceptance I m p e d i m e n t R e m o v a l Definition of
Defined Sprint Done
1 to 4 wks

16. Ready-Ready to Done-Done
Daily Standup
Acceptance I m p e d i m e n t R e m o v a l Definition of
Defined Sprint Done
If the water leaks - you have
1 to 4 wks
holes in your ACCEPTANCE
definition and/or your
definition of DONE.

17. HYPER-PRODUCTIVE
SCRUM
s
y” Scrum i
“ ordinar t (ATDD) was
ee n this and elopmen st hat wer
e
n ce betw en Dev t est case s was the
e differe nce Test Driv deliver hi
“Th pt a st s would rs. Only after t as possible
t...Acce ss analy ogramme on
tha rs /busine y the pr h ed as so
use d. Teste directly b ac complis sprint.
ed ing was he
imp lement e d. Test end of t ...”
de complet and before the s by 40%
a ctual co ompletion uc e defect
d ec and red
after co e veloci
ty tt
tly doubl e rland, Sco
co nsisten um - Jeff Suth
“...AT DD will ductive Scr
or Hyper-Pro
AB ootstrap f
ck Therapy -
From Sho n Granvik
Do wney, Bjor
A-TDD is a key ingredient for
high performance Scrum...

18. RESEARCH GOALS
1. Collaborating on a framework for
introducing Acceptance Test-Driven
Development in large, complex product
development
2. Iterating and improving on that framework
3. Publishing the resulting research, identifying
all critical success factors.

19. COLLABORATION
BREEDS INNOVATION!
By collaborating together we will:
• Find new and Innovative ways to
introduce A-TDD into Large Scale
Complex Product Development
• Maximize your chances of Success with
A-TDD introduction in your
development practices
• Explore the frontier of Change adoption

20. Instead of this...
MC Escher
Letʼs drive towards coherent system
design, testability, and quality!

21. FOR DISCUSSION
How does A-TDD:
• Help to break down large requirements
into appropriately sized testable ones?
• Help to crystallize architectural decisions?
• Help you re-factor your backlog?
• Increase the behavioural predictability of
your software?
• Help developers write less code?

22. Q&A