Agile and Automated Testing. Helmut Steineder JIPP.IT GmbH 2015

Transcription

1 Agile and Automated Testing Helmut Steineder JIPP.IT GmbH 2015

2 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

3 References See more at: 3

4 Agenda Traditional vs Agile Testing in an agile world From TDD to BDD

5 state of the art new ground Requirements Traditional vs. Agile project anatomy very instable uncertain, complex Anarchy very certain, stable Technologie Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum von Ken Schwaber and Mike Beedle.

6 Traditional vs. Agile project structure, simplified Traditional Requirements Implementation Test Agile DoR Test Implementation

7 A classic one slightly modified What the client really wants How it has been built How the client describes it

8 Agile Project start end start

9 Agile Project phase start end

10 Agile Projekt phase end start

11 Agile Project end Ende Start

12

13 Purpose of Test Business centric Testing the what

14 Purpose of Test Quality centric Testing the how

15 Purpose of Test Quality centric Testing the how Business centric Testing the what

16 Test Types Functional Testing Non-Functional Testing Structural Testing Regression Testing

17 Test Hierarchy Acceptance Tests System Tests Integration Tests Component Tests

18 Traditional vs. Agile test type implementations

19 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

20 Cost of change Kent Beck Scott W. Ambler

21 Cost of failures Scott W. Ambler

22 Cost of failure by case study IBM 2014 Origin of Software Defects (Source: Crosstalk, the Journal of Defense Software Engineering) 36% 64% Requirements and Design Implementation Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)

23

24 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

25 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)

26 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

27 Business goals Role goals Epics User Stories Acceptance Criterias functionality Scenarios Code Behaviour Driven Development Closing the gap between what and how Level of detail

28 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 So let s start with a short story Dan North 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

29 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

30 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

31 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.

32 Lessons Learned Agile Testing

33 Contact Information JIPP.IT GmbH Just Innovative People and Products. Information Technology Competence Center for Agile Software Development Tel: +43 (0) Helmut Steineder Tel.: +43 (0) Web: Upcoming events Certified Scrum Master, Vienna, Certified Scrum Protuct Owner, Vienna,