Transcript Slide 1

Software & Systems
Quality Conferences
United Kingdom
2006
Aligning
Development and
Testing Lifecycles
3rd October 2006
Facilitated by
Graham Thomas
Independent Consultant
1
Abstract
The first objective of a test strategy is to align the testing activities with the
development activities. It’s obvious really, but sometimes hard to do. In fact, it
seems to be getting much harder recently with the advent of iterative and agile
development lifecycles – hasn’t it?
Developers change their development approach in order to be more efficient and
effective (and ‘up-to-date’). But testers and their approach haven’t kept pace.
While the developers have changed their methods, by adopting an iterative or
agile approach for example, the test team will probably be used to a more
traditional, structured, V-Model approach.
It’s no surprise that testing and development activities aren’t aligned.
This session will take a look at traditional (structured), iterative (RAD) and agile
(incremental) development lifecycles and their associated testing lifecycle
counterparts
2
3
Agenda
 Introduction
now
 Setting the scene
15mins
 Group Discussion
20mins
 Conclusion
5mins
4
A brief slideshow
 Identification of the main methodologies
 History of development methodologies
 Strengths & Weaknesses
 Implications for developing a test Strategy
5
Types of Methodology
A
D
B
UAT
SIT
ST
UT
Depth
R
Breadth
V-Model
• Structured
testing
• Large projects
• Fixed interfaces
• Legal/statutory
Rqmts.
Iterative Testing
• Several iterations
(3)
• Changing
Incremental (Agile)
• Small items of
work
• Less structured
requirements
approach
• Business driven
• Time-boxed
• Continuous
integration
6
History of Development Methodologies
Visual Studio
Programming Languages
C#
Java
Visual Basic
C++
C
Basic
Cobol
Assembler
First Computer
Program
(Ada Lovelace)
1842 - 43
First
Computer
Machine Code
1930 –
1940
51
59 64 72
83
91
2000
7
History of Development Methodologies
AGILE e.g. XP
(Kent Beck)
RUP (Rational)
Methodologies
WATERFALL (Royce)
Requirements, design
implementation,
verification &
maintenance
Waterfall
1960
1970
Incremental, user
Object oriented,
driven, low process
iterative, time-boxed,
RAD
user driven, high
(James Martin)
ceremony
RUP
Prototyping,
iterative, time-boxed,
user driven
RAD
SPIRAL MODEL
(Barry Boehm)
V-MODEL (Anon)
Iterative Spiral Model
Aligns testing to
Waterfall
development V-Model
1980
85
91
98 99
8
The V-Model a closer look (1)
9
The V-Model a closer look (2)
Conical
Model
Component
Unit
System
Integration
Testing
Testing
Testing
User
Acceptance
Testing
10
The V-Model a closer look (3)
- A/C
Rqmts - NFR
- Func
OAT
UAT
BAD
Use Cases/DBD
{Business
Scenarios
System Integration Test
EIT
Design Overview
Detailed
System Design
System Test
11
Iterative e.g. RAD/Spiral (1)
12
Iterative e.g. RAD/Spiral (2)
Development
Testing
13
Agile - XP explained (1)
The Values
•
•
•
•
•
Communication
Simplicity
Feedback
Courage
Respect
(added in the latest version)
15
Agile - XP explained (2)
1. Test First Programming
Test First without code
2. The Planning Game
- Business Stories
- Customer decides, Prog.
Implements
3. Small, Frequent Releases
- Release early and release often
4. Always use the Simplest design
- that adds business value
5. System Metaphor
- Programmers define a handful of
classes and patterns that shape
the core business problem and
solution
- Like a primitive Architecture
6. On-site Customer
- Customer has authority to define
functionality
- encourages face-to-face dialogue
7. Refactoring
- Restructuring code without
changing its functionality
- Mainly Simplification
8. Pair Programming
9. Collective Code Ownership
10.Coding Standards
- Everyone should use the same
coding styles.
11.Continuous Integration
- At least a few times a day
- All unit tests must pass prior to
integration
- All functional tests must pass
afterwards
12.Forty Hour Week !
- Tired programmers write poor code
and make more mistakes
16
How to correctly identify the development model
• Structured implies driven by top-down products
e.g. Requirements
-
It is quite common for the top-down products to
be late, missing or incomplete, e.g. requirements
• Iterative means a functional delivery per
iteration that can be tested and implemented
-
Projects often have iterations which just mimic
phases, i.e. not complete until all are finished
• Agile projects are highly disciplined and staffed
with committed people
-
Commonly agile is a term used to excuse existing
bad practice!
17
A few Questions
1. Do we [as testers] know the development
lifecycle employed by our developers ?
2. Is our testing aligned to the development
lifecycle ?
3. Are we trying to do testing in a way that is not
compatible with our development approach ?
4. Do we need more than one testing approach ?
18
Implications of misaligned lifecycles
• Lets examine the lifecycles to see how the
development and testing approaches align
• Making the assumption that matching
development and testing lifecycles work as
described
• Factors to consider
-
Development and test activities
-
Lifecycle products
-
Timing of activities, dependencies, constraints
-
Objectives of approach
-
Deliverables
-
Measurement
19
Group Discussion
Development Approach
Structured
Iterative
Agile
Dev.
Dev.
–Dev.
Structured
Iterative
– Agile
Structured
– Agile
Iterative
Test
Test
Test
Testing Approach
 Agile
Expectation
Complex
Test
Testers
Testing
expectations
testing
may
not
integration
in
of
be
approach
touch
full
perceived
of
coverage
with
complete
may
will
requirements
not
as
not
testing
slowing
be
driving
deliver
suitable
but
depth
development,
time-boxed
for
products
and
an
scope
of
agile
documentation
e.g.
testing
approach
but
requirements
not
delivered
to the
required
sameby
extent
Structured
Iterative
Agile
structured
specification
Structured
approach
will
Testing
not
be
met
 as

Testers
Iterations
Driving
products
have
may
to
be
wait
for
toountil
testing
large
waterfall
for
willagile
not be
Structured
Iterative
Agile
 Agile

Difficulty
May
stages
testing
delivered
be
testers
deliver
difficult
team
with
in the
will
–early
may
to
form
be
identify
not
test
kicking
required
have
planning
iterations
their
resource
heelsor
time may
for
code
deliveries
 waiting

Faults
Expectation
Developers
Testing
approach
not
and
of early
be
testers
copes
fixed
testing
have
in
will
time
may
with
a difficult
for
not
next
be
 met
Agile
Faults
testby
relationship
incremental
iteration
testing
may
test environment
not
and
leading
team
beevolutionary
fixed
may
to conflict
finish
quickly
and test
early
enough
data
and
move
for
availability
onable
testers
to
approach
project
 development

Mayagile
Pressure
be
onanother
to
testers
test early
to deliver ‘earlier’


Continuous
Complimentary
Testing
withperceived
a Release
Integration
Testing
progressing
may
inapproach
co-location,
beapproach
too
 Fits

Testers
Testing
not
may
seen
takepractices
as
aas
risk
delivering
based
– takes
beneficial
slowly
but may
and
take
time-boxed
longer
to
 business
Complimentary
too long, driven
costs
too
practices
much
in co-location,
 implement

Continuous
Pressure
business
on
driven
Integration
testers
totime-boxed
deliver
will be
‘earlier’
beneficial
Testing
does
not and
keep
pace
with
 Benefit
come from
co-location
of out
Fits
product
withwill
development
a Release
Testing
and
isapproach
seen as






developers
and testers the value of
of touch – questioning
 Agile
testing
testers should cope better with
change
20
Conclusion
• Find out the development approach being used
by your developers
• Work to align the testing activities with the
development activities
• Don’t assume that it is just a case of influencing
the developers to fit the testing mould
• Ask yourself if it is actually the testing approach
that is causing the problems
• Work together with your developers to find the
right testing solution(s)
• Iterative or Agile testing misaligns better than
Structured testing !!!
21
CONTACT DETAILS
Graham Thomas
Independent Consultant
 [email protected]
 +44 7973 387 853
 www.badgerscroft.com
22