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/
Navigating the Deluge_ Dubai Floods and the Resilience of Dubai International...
Campbell & Readman - TDD It's Not Tester Driven Development - EuroSTAR 2012
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
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
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