EuroSTAR Software Testing Conference 2012 presentation on TDD It's Not Tester Driven Development by Campbell & Readman. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/

1. TDD it’s not Tester Driven Development
Stephen Readman, Sopra Group &
Kevin Campbell, CloudReach
www.eurostarconferences.com
@esconfs
#esconfs
#trackw07

2. 2
TDD it’s not tester driven development
EuroSTAR 2012,
Amsterdam RAI
#trackw07 @esconfs #esconfs

3. 3
Who are we?
 Stephen Readman
 Lead Consultant @ Sopra Group
 14 years experience in Software Testing
 Multiple business environments
 Based in Edinburgh, UK
 Kevin Campbell
 Quality Assurance Manager @ Cloudreach
 18 years in the financial services industry
Aspiring cloud computing aficionado
 Also based in Edinburgh, UK

4. 4
Why are you here?
 Maybe you got lost? This is track W07!
 More likely, you know of TDD / Practice TDD
 This is a case study, with a difference ;-)
We'll talk about the background
We'll talk about the process and content
We'll give you some tips - take it or leave it!

5. 5
Tweeting
 Be interactive
 Mobiles at the ready!
 Please Tweet your questions or observations
 We'll read and answer some later on
#trackw07 @esconfs #esconfs

6. 6
Twitter Poll:
What is the main barrier to TDD?
 Testers not technical enough?
 Business engagement?
 Cost of change?
 Lack of experience?
 Cultural fit/change?
 Technology/Infrastructure limitations?
.... Please share your thoughts

7. 7
Innovate & Renovate
 ... is testing really dead?
 You need to Innovate and Renovate your
testing, this is EuroSTAR 2012 after all

8. 8
Project Overview
 Replacing an existing consumer web platform
 Major architectural rewrite of a core business application
 Improving the customer experience
 UX designers mapping stories to personas
 UI developers focussing on UI only
 Big focus on customer experience

9. 9
Testing with Visual Studio 2010

10. 10
Business Analysts
define and write User
Stories and Use Cases
Use
Cases User
Stories
Testers define and
prepare « business »
Test Cases
Test
Cases
Developers implement
and unit-test their code
(with the TDD practice)
The TDD practice
is siloed inside
the developer’s
activities
Application
Unit Tests
Traditional Test Driven Development

11. 11
Business Analysts, Testers and developers
work together to understand the requirements,
define the associated tests, whether they can be
automated, and who executes them
Use
Cases
User
Stories
Test
Cases
The differents roles’
points of view are
complementary: they
help each other
Developers have a
better understanding
of what has to be
developed, and why
Testers have a good
view of what can be
tested by developers,
and can focus on high-value
business tests
A real collaboration,
highly efficient in an
agile process with
short iterations

12. 12
So that’s “Why TDD”
 Conversation is powerful
 Examples are powerful
 Automated examples are powerful
 Red -> Green ->Refactor
 Sitting on the fence between BDD and TDD
 Remove Testing Silos
Collaboration is key!

13. 13
We’ve been on a journey
 Culture Change
Collaboration between the key players
Role changes
Responsibilities
 Behavioural Shift
Testers asked to operate out side
the perceived norm
Ownership

14. 14
We’ve been on a journey
 Software Changes
Hello Visual Studio 2010
Hello Gherkin
Hello Selenium
Hello SpecFlow
 Technology Changes
.NET based technology
Completely new Infrastructure

15. 15
Twitter Poll:
What is the main barrier to TDD?
 Testers not technical enough?
 Business engagement?
 Cost of change?
 Lack of experience?
 Cultural fit/change?
 Technology/Infrastructure limitations?
.... Please share your thoughts

16. 16
 Business: Acceptance is formal structured English
 Developer: Responsible for automation services
Key Point
It is important to create concrete
examples to ensure high quality
stories/designs through the
Three Amigos process
Three Amigos
The Three Amigos
 Testers: Contribute to product definition

17. 17
Human Aspects: Developer
 Stories are throw away once tests written
 More time implementing tests than developing
application code
 It doesn’t feel like TDD
 Gherkin tests not ready - I’ll just develop!
 Developers can write Gherkin Tests too
 Unit Test Code Coverage was mandatory
#trackw07 @esconfs #esconfs

18. 18
Human Aspects: Tester
 I can’t do automation code
 I am the gateway to quality
 A developer has changed my test
 Acceptance Criteria on stories missing. I can’t therefore
write tests
 I can’t see test results, is this quality code?
 So I’ll just do everything I used to do then.
 Ownership of scenario automation and exploratory
testing to compliment automation
#trackw07 @esconfs #esconfs

19. 19
Human Aspects: Business
 Gherkin Tests make it easy for me to
understand the way the system is designed to
work
 Pickles ‘living documentation’ really works for
me, with high levels of visibility
 I can’t see test results, is this quality code?
 I am part of the team and a key sign-off stage
#trackw07 @esconfs #esconfs

20. 20
What the Management said
 I can’t see the results of the tests
 Progress through stories seems slow
 Sprint planning metrics seem mysterious
 Delighted with the iterative delivery
 Documentation is always accessible
#trackw07 @esconfs #esconfs

21. 21
Summary: Human Aspects
 Test Analyst
 Test Analyst – focussed on ‘what’ to test
 Tests are formal but not technical
 Developer
 Focussed on the ‘how’ i.e. writing the automation
 Test Automation Engineer or Software Developer but
not the Test Analyst
 Business
Actively engaged throughout the SDLC
 Continuous show case and sign off
#trackw07 @esconfs #esconfs

22. 22
Bringing excellent testing foward
 There’s a big difference between testing and checking
 A check has three linked parts:
 An observation
 A decision rule
 The “setting of a bit”
 A check can be applied non-sapiently, without human
involvement, but…
 Excellent checking is surrounded by sapient activities
that require testing skill and programming skill
 Checking is very valuable when we don’t fall asleep
Michael Bolton, Burning Issue of the day , Scottish Testing Group – May 2010

23. 23
Twitter Poll :
What is the main barrier to TDD?
 Lack of technical testers?
 Business engagement?
 Cost of change?
 Lack of experience?
 Cultural fit/change?
 Technology/Infrastructure limitations?
.... Please share your thoughts

24. 24
Online survey
What is the main barrier to introducing TDD?

25. 25
What helped us: Hints & Tips
 Exploratory Test sessions and activity in HP
Quality Center (QC)
 Synced defects between HP QC and MS TFS
 Pickles: Docs always up to date and available
 Team Build Screen
 TFS Work Bench

26. 26
What worked well
 Developers can be automation kings
 Testers will always be testing kings
 We didn’t develop, if when pushed, the business
often can’t specify what they wanted clearly
 All layers of management must demand clear
metrics
 TDD isn’t faster than other methods
 TDD enforces rigor and therefore quality

27. 27
Summary: Human Aspects
 Test Analyst
 Test Analyst – focussed on ‘what’ to test
 Tests are formal but not technical
 Developer
 Focussed on the ‘how’ i.e. writing the automation
 Test Automation Engineer or Software Developer but
not the Test Analyst
 Business
Actively engaged throughout the SDLC
 Continuous show case and sign off
#trackw07 @esconfs #esconfs

28. 28
Questions & Thank You
Contact:
sreadman@uk.sopragroup.com | @sarcx
kevin.campbell@cloudreach.co.uk | @zooldafool
#trackw07 @esconfs #esconfs