Agile and Automated Testing Helmut Steineder JIPP.IT GmbH 2015 About myself CoFounder of JIPP.IT GmbH Covered areas over years • SW development • Requirements Engineering • (agile) Project Management • Agile Testing Current activities • Agile Coach • Agile Trainer • Scrum Master, Product Owner References 3 See more at: http://www.jipp.it/references Agenda • Traditional vs Agile • Testing in an agile world • From TDD to BDD Traditional vs. Agile project anatomy very instable uncertain, Anarchy complex Source: Strategic Management and Organizational Dynamics by Ralph Requirements Stacey in Agile Software Development with Scrum von Ken Schwaber and very certain, Mike Beedle. stable Technologie ew n tate of tate the art the ground s Traditional vs. Agile project structure, simplified Traditional Requirements Implementation Test Agile DoR Test Implementation A classic one slightly modified What the client really wants How it has been built How the client describes it Agile Project Lifecycle @project start end start Agile Project Lifecycle @start phase start end Agile Projekt Lifecycle @interim phase end start Agile Project Lifecycle @project end Ende Start Purpose of Test • Business centric • Testing the what Purpose of Test • Quality centric • Testing the how Purpose of Test • Business centric • Quality centric • Testing the what • Testing the how Test Types • Functional Testing • Non-Functional Testing • Structural Testing • Regression Testing Test Hierarchy • Acceptance Tests • System Tests • Integration Tests • Component Tests Traditional vs. Agile test type implementations Agile Impact on Testing • Continuous change impacts testing – Continuous change of test cases • Continuous integration needs regression testing – Perform tests after each build Testers – Manual Testing is inefficient Go for automation Cost of change Kent Beck © Scott W. Ambler Cost of failures © Scott W. Ambler Cost of failure by case study IBM 2014 Origin of Software Defects (Source: Crosstalk, the Journal of Defense Software Engineering) 36% Requirements and Design 64% Implementation Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute) TDD current situation Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests. Martin Fowler • Most TDD implementations cover – Automated component tests – Automated integration tests • Some implementations cover – Automated system tests TDD Possible Benefits • Avoid over-engineering • Get API feedback • Avoid Logical errors • Create Usage Documentation • Separate interface from implementation • Get a better Agreement • Reduce Risk (e.g. during refactoring) Acceptance TDD Goals and Problems • Goals – Provide better understanding about the what – Refine knowledge about story • Problems – Most acceptance criterias are informal – Are a matter of interpretation There is a need to formalize the description Behaviour Driven Development Closing the gap between what and how Code functionality Scenarios Criterias Acceptance Epics User Stories User goals goals Role Business Business Level of detail BDD, Scenarios and all that stuff a short intro A story’s behaviour is simply its acceptance criteria – if the system fulfills all the acceptance criteria, it’s behaving correctly; if it doesn’t, it isn’t Dan North So let‘s start with a short story As a bank customer I want to withdraw cash from an ATM, So that I don‘t have to wait in line at the bank And get some Scenarios Scenario 1: Account is in credit Given the account is in credit And the card is valid And the dispenser contains cash When the customer requests cash Then ensure the account is debited And ensure cash is dispensed And ensure the card is returned Scenario 2: Account is overdrawn past the overdraft limit Given the account is overdrawn And the card is valid When the customer requests cash Then ensure a rejection message is displayed And ensure cash is not dispensed And ensure the card is returned Scenarios key features • Scenarios use a domain specific language – Can be understood by customer and developer – Establish a common terminology across the product/project • Are exceutable – Various frameworks exist which can be used to the map scenarios to real code. • Provide a living documentation – As stories change the behavior of a system. The scenarios are changed as well. Lessons Learned Agile Testing Contact Information JIPP.IT GmbH Just Innovative People and Products. Information Technology Competence Center for Agile Software Development Tel: +43 (0)3112 90 300 | [email protected] Helmut Steineder Tel.: +43 (0) 664 3968721 Email: [email protected] Web: http://www.jipp.it/it-training Upcoming events Certified Scrum Master, Vienna, 11.01.2016 – 12.01.2016 Certified Scrum Protuct Owner, Vienna, 13.01.2016 – 14.01.2016 33 .