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

• Traditional vs Agile

• Testing in an agile world

• From TDD to BDD

Agenda

Traditional vs. Agile project anatomy

Anarchy

complex

Technologie

Re

qu

ire

me

nts

very instable

uncertain,

very certain,

stable

sta

te o

f

the

art

new

gro

un

d

Source: Strategic Management and

Organizational Dynamics by Ralph

Stacey in Agile Software Development

with Scrum von Ken Schwaber and

Mike Beedle.

Traditional vs. Agile project structure, simplified

Requirements Implementation Test

DoR

Implementation Test

Traditional

Agile

A classic one slightly modified

What the

client really

wants

How the

client

describes it

How it has

been built

Agile Project Lifecycle @project start

start

end

Agile Project Lifecycle @start phase

start end

Agile Projekt Lifecycle @interim phase

start

end

Agile Project Lifecycle @project end

Start

Ende

• Business centric

• Testing the what

Purpose of Test

Purpose of Test

• Quality centric

• Testing the how

• Business centric

• Testing the what

Purpose of Test

• Quality centric

• Testing the how

• Functional Testing

• Non-Functional Testing

• Structural Testing

• Regression Testing

Test Types

• Acceptance Tests

• System Tests

• Integration Tests

• Component Tests

Test Hierarchy

Traditional vs. Agile test type implementations

• Continuous change impacts testing

– Continuous change of test cases

• Continuous integration needs

regression testing

– Perform tests after each build

Agile Impact on Testing

– Manual Testing is inefficient

Go for automation

Testers

Cost of change

© Scott W. Ambler

Kent Beck

Cost of failures

© Scott W. Ambler

Cost of failure by case study IBM 2014

64%

36%

Origin of Software Defects (Source: Crosstalk, the Journal of Defense

Software Engineering)

Requirementsand Design

Implementation

Relative Costs to Fix Software Defects

(Source: IBM Systems Sciences Institute)

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 current situation

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

TDD Possible Benefits

• 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

Acceptance TDD Goals and Problems

Behaviour Driven Development Closing the gap between what and how

functionalit

y

Level of detail

Busin

ess g

oals

Role

goals

Epic

s

User

Sto

ries

Accepta

nce

Crite

rias

Scenarios

Code

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

BDD, Scenarios and all that stuff a short intro

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 1: Account is in credit

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

Scenario 2: Account is overdrawn

past the overdraft limit

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

Scenarios key features

Lessons Learned Agile Testing

JIPP.IT GmbH Just Innovative People and Products. Information Technology

Competence Center for Agile Software Development

Tel: +43 (0)3112 90 300 | office@jipp.it

Helmut Steineder

Tel.: +43 (0) 664 3968721

Email: helmut.steineder@jipp.it

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

Contact Information

33