Agile and Automated Testing

Home , Agile testing, Functional 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 ew

tate of 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

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

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