As the Lead Principal Software Engineer in ASOS Technology, Nik Crabtree is responsible for Software and QA Engineering, UI Engineering and Data Engineering across the organisation. His role has a simple brief: come in every day with one aim - make engineering and engineers at ASOS better. On May 10th, Nik spoke to the UXDX London audience about test, deploy and solving problems fast! He highlights why people should adopt a test-driven-development approach. Shared understanding, shared ownership and a test-first approach leads to high quality software, trust and high performance.

2. SOLVING PROBLEMS FAST
A ccept ance Test D riven D evelopment
Nik Crabtree
Lead Principal Software Engineer @ ASOS

3.  Why TDD?
 The TDD cycle
 Why ATDD?
 Shared understanding
 Shared ownership
 Test-first approach
 The ATDD cycle
 The big picture
SOLVING PROBLEMS FAST
A ccept ance Test D riven D evelopment

4. WHY TDD?
W hat problems does it solve?
 It’s not clear exactly what needs to be done before writing the code
 It’s not clear whether all of the code you’re writing meets a known requirement
 It’s not clear whether the codebase already meets the requirement, intentionally or otherwise.
 Long feedback cycles
 Documenting the code is done through comments or an entirely separate resource.
TDD also has one key-side effect…
 You implicitly create and maintain a regression test suite that lets you know immediately if
you break something later on.

5. THE TDD CYCLE

6. TDD
Write a test that
exercises the smallest
unit of new externally
visible behaviour
The unit test should fail,
proving that the codebase
does not already support
the new behaviour
Make the simplest code
change possible to
implement the new
behaviour
The unit test should now
pass, indicating that the
code base supports the
new behaviour with a
specific input
The structure of the code
written to pass the test
(not the behaviour) may
need to be altered so that
it is more clear and
maintainable.
1
2
34
5
6
The unit test should still
pass, as the behaviour
should not have changed

7. WHY ATDD?
W hat problems does it solve?
• The flow of requirements is sometimes disconnected
• Unable to take stories into sprint due to poor requirements definition
• Rework when requirements are not implemented as expected
• Acceptance criteria is of variable quality and format and requires
translation/transformation
• Collaboration between the three amigos is inconsistent
• Mini-waterfall testing leads to longer feedback cycles
• Second class citizens in development teams

8. SHARED
OWNERSHIP
High quality software
High trust teams
High performing teams

9. SHARED OWNERSHIP
It ’s a t hree - legged race, not a relay
Let’s talk about Scrum and agile development practices
Scrum makes some very specific statements about ownership

10. SHARED OWNERSHIP
It ’s a t hree - legged race, not a relay
 Scrum recognizes no titles for Development Team members other than
Developer
 Scrum recognizes no sub-teams in the Development Team… like testing
or business analysis.
 Individual Development Team members may have specialized skills and
areas of focus, but accountability belongs to the Development Team as a
whole.
http://www.scrumguides.org/scrum-guide.html

11. SHARED OWNERSHIP
It ’s a t hree - legged race, not a relay
There are no heroes
 The Development Team is responsible for delivering the PBIs in the sprint
backlog.
 The Development Team should feel a collective sense of pride and
achievement in getting those PBIs to done.

12. SHARED OWNERSHIP
It ’s a t hree - legged race, not a relay
There is no ‘dev complete’
 A PBI is done when it is proven to meet all of the acceptance criteria.
 There are no hand-offs in a high-performing team.
 There are no second-class citizens in a high-trust team.

13. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
How do we make sure everyone understands what’s required?
 Write requirements in a common format
 Use ubiquitous language
 Keep a domain dictionary
 Talk!

14. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
One common format is GWT…
 Given this state
 When I perform this action
 Then I see this result

15. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
A GWT is…
A logical function to which we:
 provide known input
 invoke an action
 assert a known output

16. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
A unit test is…
A logical function to which we:
 provide known input
 invoke an action
 assert a known output

17. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
An acceptance test is…
A logical function to which we:
 provide known input
 invoke an action
 assert a known output

18. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
A functional requirement is…
A logical function to which we:
 provide known input
 invoke an action
 assert a known output

19. SHARED UNDERSTANDING
D oes everyone have a copy of t he hymn sheet ?
Which means…?
 Turning functional requirements into acceptance tests into unit tests into
working software can (and should!) be done from exactly the same set of
criteria
 Everyone involved is singing from the same hymn sheet. No-one gets the
words wrong, no-one sings out of tune.

20. TEST-FIRST APPROACH
Set t he course bef ore st art ing t he race
Test first development is…
 A lean approach to development (avoid gold-plating, over-engineering,
YAGNI)
 A way of being confident that software meets requirements from the first
line of code
 All about understanding what you are doing and why

21. TEST-FIRST APPROACH
Set t he course bef ore st art ing t he race
Acceptance criteria
Test-first development is fuelled by acceptance criteria. Acceptance criteria is…
 Defined and agreed by the Development Team with the Product Owner
 Written in a business readable, domain specific language, like Gherkin
 Written from an Outside-In perspective
 Expectations of behaviour, not implementation

22. THE ATDD CYCLE

23. DISCUSS DISTIL
DEVELOPDEMO

24. The team asks questions
They may break down the feature
They may add new features to the backlog
They should establish a shared
understanding
DISCUSS

25. The team formalises
the acceptance criteria
They use a format like Gherkin
They use ubiquitous language
They do not include implementation details
The feature should now be ready to sprint
DISCUSS DISTIL

26. Developers turn formal acceptance
criteria into automated tests
Transform ubiquitous language into domain
objects
Add technical scenarios
Executable requirements
DISCUSS DISTIL
DEVELOP

27. DISCUSS
The feature is ready to demo
They already know it meets the
requirements
They may perform some exploratory
testing, including gamifying, red team/blue
team, etc.
Sprint review
DISTIL
DEVELOPDEMO

28. TDD
Automated
acceptance
tests are red
Automated
acceptance
tests are green
DISCUSS DISTIL
DEVELOPDEMO

29. THE BIG PICTURE

30. LEARN
PROTOTYPEIDEA
BUILDBACKLOG
MEASUREITERATE
ROUGH
IDEA
SELECTED TERRITORY
ROLLOUT
FULL
ROLLOUT
TES
T
NON-FUNCTIONAL
PROTOTYPE
FUNCTIONAL
PROTOTYPE
A/B
MVT TEST
ATDD

31. Q & A
@asostechnik
@asos_careers
https://asos.tech