In agile projects, when the cycle from ideas to production shortens from months to hours, each software development activity—including testing—is impacted. Reaching this level of agility in testing requires massive automation. But test execution is only one side of the coin. How do we design and maintain tests at the required speed and scale? Testing should start very early in the development process and be used as acceptance criteria by the project stakeholders. Early test design, using a business domain language to write tests, is an efficient solution to support rapid iterations and helps align the team on the definition of done. These principles are the basis of acceptance test-driven development practices. Laurent Py shows you how the use of business domain languages enables test refactoring and accelerates automation. Come and learn how you can leverage acceptance tests and key test refactoring techniques.

1. T9
Test Automation
5/8/2014 11:15:00 AM
Accelerate Testing in Agile
through a Shared Business
Domain Language
Presented by:
Laurent Py
Smartesting
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888-268-8770 ∙ 904-278-0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. Laurent Py
Smartesting
A founder and chief executive officer of Smartesting® Laurent Py began exploring advanced
testing techniques in the 1990s and has extensive experience in software testing. Laurent also
has a product management role for Zest, the new testing platform in the cloud, and is engaged
with customers to ensure Smartesting products meet the needs of the next generation of
developers and testers. He is passionate about lean startups and agility. For Laurent it’s all
about using early feedback to test and validate assumptions as soon as possible.

3. 26/04/2014
1
Laurent PY
CEO, Smartesting
Laurent.py@smartesting.com
@py_laurent
www.smartesting.com
Defining a Shared Business
Domain Language to accelerate
testing in Agile Projects
Our long and painful
journey
towards DevOps

4. 26/04/2014
2
Product: CertifyIt, eclipse plug-in in JAVA (Model-Based-Testing)
– Waterfall process
– 1 release every 6 months
– Few tests and no TDD
– 1 month (x5 people) to do release testing before
deployment
– Poor quality impacting customers’ feedback and adoption
Overview of our development process 2004/06
3
Product: CertifyIt, eclipse plug-in in JAVA (Model-Based-Testing)
– First XP and then Scrum process
– We do TDD
– Continuous integration (code & unit test)
– 1 customer release every 3 months (1 operation release every 3 weeks)
– 1 man/month to do release testing before deployment
– Good feedback from customers!
Tasting agility end of 2006
4

5. 26/04/2014
3
Product: Zest, testing platform in the cloud
– Still Scrum process
– We do TDD and
– Acceptance Testing Driven Development (ATDD), 100% automated
– Acceptance tests are part of the CI process
– We do several deployments a day (≈10)
Now we are experiencing DevOps - 2012
5
Shorter iterations (1 to 4 weeks) lead to
massive test automation completed by
exploratory testing
Acceptance tests become the specification
Testing starts earlier in the development
process: Shift left!
What we’ve learnt
Req
Management
& Definition
Test
Planning
Execution
Defect
management

6. 26/04/2014
4
What we’ve learnt
7
To achieve this level of speed (DevOps context),
acceptance tests should be:
– Understandable to both developers and business
experts to strengthen alignment and enable the ‘shift
left’
– Maintainable to manage efficiently changes in
requirements and keep pace with continuous
deployment
– Automated to enable rapid execution and feed-back
ATDD with Business Domain Language
and refactoring capabilities
ATDD & Refactoring
My view as product owner & tester:
Acceptance tests need to be continually
reviewed and refactored just like code!!!
Martin Fowler

7. 26/04/2014
5
Acceptance testing
driven development
Shift left
PO developers testers Scrum
master
Scrum team
Acceptance testingAcceptance testing
Shift left
Product Backlog
Sprint Backlog Sprint
1 to 4 weeks
Product at the end of the
iteration
Daily meeting

8. 26/04/2014
6
Acceptance Testing Driven Development (ATDD)
Acceptance test is a powerful artifact to improve
communication
Test as the definition of ‘STOP’
Written prior to development by tester
Based on a business DSL (domain specific Language)
Confirmed with stakeholders
Mostly automated
Test in natural language
Test fixture
Code
Acceptance Testing Driven Development (ATDD)
Benefits:
– Improve communication and collaboration between project
stakeholders
– Shared understanding of what a successful implementation
means
– Better coverage of business expectations
– Faster feed back
Challenges:
– New methodology that requires rigor and discipline
– Find the right balance between people/process/tool

9. 26/04/2014
7
Build your
acceptance tests
and DSL at the
same time
Key features:
– Define progressively your Action Words and your business domain language for test
authoring
– Suggestion to promote the reuse of Action Word and avoid duplication
– Refactoring: when an Action Word is modified, impacts are performed automatically across
the tests
– Optimization: inspection features enable to continuously optimize the acceptance tests
– Create scripts and accelerate test automation (Ruby, Java, XML )
Integrations with:
Zest: create acceptance tests with DSL
14
Watir, Appium

10. 26/04/2014
8
Collaboration through acceptance tests & DSL
15
Product Owner
Validate acceptance
tests
Tester
Create acceptance
Tests
Developer
Automate acceptance
tests
• DSL
• Refactoring capabilities
Define new business entities
Define progressively your business terminology with
Action Words. Enable collaboration based on acceptance
tests.

11. 26/04/2014
9
or define business entities right from the tests
Promote test steps into Action Words (what developers
call extract function). This is refactoring!
Evils of duplication

12. 26/04/2014
10
A fundamental principle
Reuse, reuse and reuse Action Words!
Create and maintain consistent scenarios for
your project
Suggestions

13. 26/04/2014
11
Analyse and optimize continuously your tests
When duplications are identified, refactoring
options are suggested!
Add, remove, modify Action Words and Scenarios
Test refactoring enables to perform automatically
impact analysis and test maintenance tasks
Add parameters to Action WordAdd parameters to Action Word
Propagate automatically to
the scenarios
Propagate automatically to
the scenarios

14. 26/04/2014
12
Generate scripts
Use of Action Words significantly decrease the
cost of automation and accelerate the overall testing
cycle
So your acceptance tests are
Understandable
Definition of business domain tests enable
better alignment of the team
Maintainable
Refactoring and optimization features
dramatically accelerate maintenance
Can be automated
Good design based on Action Words
streamlines the test automation phase
• DSL
• Refactoring capabilities

15. 26/04/2014
13
And remember
Acceptance tests need to be
continually reviewed and
refactored just like code!!!
Q&A
Laurent PY
CEO, Smartesting
Laurent.py@smartesting.com
@py_laurent
www.smartesting.com