Accelerate Testing in Agile through a Shared Business Domain Language
- 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