accelerate testing in agile through a shared business domain language
DESCRIPTION
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.TRANSCRIPT
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 ∙ [email protected] ∙ www.sqe.com
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.
26/04/2014
1
Laurent PY
CEO, Smartesting
@py_laurent
www.smartesting.com
Defining a Shared Business
Domain Language to accelerate
testing in Agile Projects
Our long and painful
journey
towards DevOps
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
26/04/2014
3
� Product: Zest, testing platform in the cloud
– Still Scrum process
– We do TDD andA
– AAcceptance 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
PlanningExecution
Defect
management
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
26/04/2014
5
Acceptance testing
driven development
Shift left
PO developers testers Scrum
master
Scrum team
Acceptance testingAcceptance testingShift left
Product Backlog
Sprint Backlog Sprint 1 to 4 weeks
Product at the end of the
iteration
Daily meeting
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 automatedTest 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
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, XMLA)
� Integrations with:
Zest: create acceptance tests with DSL
14
Watir, AppiumA
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 entitiesA
Define progressively your business terminology with
Action Words. Enable collaboration based on acceptance
tests.
26/04/2014
9
Aor define business entities right from the tests
Promote test steps into Action Words (what developers
call extract function). This is refactoring!
Evils of duplication
26/04/2014
10
A fundamental principle
Reuse, reuse and reuse Action Words!
Create and maintain consistent scenarios for
your project
Suggestions
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
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 areA
UnderstandableDefinition of business domain tests enable
better alignment of the team
MaintainableRefactoring and optimization features
dramatically accelerate maintenance
Can be automatedGood design based on Action Words
streamlines the test automation phase
• DSL
• Refactoring capabilities
26/04/2014
13
And remember
Acceptance tests need to be
continually reviewed and
refactored just like code!!!
Q&ALaurent PY
CEO, Smartesting
@py_laurent
www.smartesting.com