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 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
• 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 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
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
Contact Information
33