slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Aligning Development and Testing Lifecycles PowerPoint Presentation
Download Presentation
Aligning Development and Testing Lifecycles

Loading in 2 Seconds...

play fullscreen
1 / 21

Aligning Development and Testing Lifecycles - PowerPoint PPT Presentation


  • 140 Views
  • Uploaded on

Software & Systems Quality Conferences United Kingdom 2006. Aligning Development and Testing Lifecycles. 3 rd October 2006 Facilitated by Graham Thomas Independent Consultant. Abstract.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Aligning Development and Testing Lifecycles' - kris


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Software & Systems

Quality Conferences

United Kingdom 2006

Aligning Development and Testing Lifecycles

3rdOctober 2006

Facilitated byGraham ThomasIndependent Consultant

abstract
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

agenda
Agenda
  • Introduction now
  • Setting the scene 15mins
  • Group Discussion 20mins
  • Conclusion 5mins
a brief slideshow
A brief slideshow
  • Identification of the main methodologies
  • History of development methodologies
  • Strengths & Weaknesses
  • Implications for developing a test Strategy
types of methodology
Types of Methodology

R

UAT

Depth

A

SIT

D

ST

B

UT

Breadth

V-Model

  • Structured testing
  • Large projects
  • Fixed interfaces
  • Legal/statutory Rqmts.

Iterative Testing

  • Several iterations (3)
  • Changing requirements
  • Business driven
  • Time-boxed

Incremental (Agile)

  • Small items of work
  • Less structured approach
  • Continuous integration
history of development methodologies
History of Development Methodologies

Visual Studio

Programming Languages

C#

Java

Visual Basic

C++

C

Basic

Cobol

Assembler

First Computer Program

(Ada Lovelace)

First Computer

Machine Code

1842 - 43

1930 –

1940

51

59

64

72

83

91

2000

history of development methodologies8
History of Development Methodologies

AGILE e.g. XP

(Kent Beck)

Incremental, user driven, low process

Methodologies

RUP (Rational)

Object oriented, iterative, time-boxed, user driven, high ceremony

RAD

(James Martin)

Prototyping, iterative, time-boxed, user driven

RUP

RAD

SPIRAL MODEL

(Barry Boehm)

Iterative

WATERFALL (Royce)

Requirements, design

implementation, verification & maintenance

V-MODEL (Anon)

Aligns testing to

Waterfall development

Spiral Model

Waterfall

V-Model

1960

1970

1980

85

91

98

99

the v model a closer look 2

Component

Integration

Testing

Unit

Testing

User

Acceptance

Testing

System

Testing

The V-Model a closer look (2)

Conical

Model

the v model a closer look 3
The V-Model a closer look (3)

- A/C

OAT

Rqmts

- NFR

- Func

UAT

{

Use Cases/DBD

BAD

System Integration Test

Business Scenarios

EIT

Design Overview

System Test

Detailed System Design

agile xp explained 1
Agile - XP explained (1)

The Values

  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Respect (added in the latest version)
agile xp explained 2
Test First ProgrammingTest First without code

The Planning Game- Business Stories- Customer decides, Prog. Implements

Small, Frequent Releases- Release early and release often

Always use the Simplest design - that adds business value

System Metaphor- Programmers define a handful of classes and patterns that shape the core business problem and solution- Like a primitive Architecture

On-site Customer- Customer has authority to define functionality- encourages face-to-face dialogue

Refactoring- Restructuring code without changing its functionality- Mainly Simplification

Pair Programming

Collective Code Ownership

Coding Standards- Everyone should use the same coding styles.

Continuous Integration- At least a few times a day- All unit tests must pass prior to integration- All functional tests must pass afterwards

Forty Hour Week !- Tired programmers write poor code and make more mistakes

Agile - XP explained (2)
how to correctly identify the development model
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!
a few questions
A few Questions
  • Do we [as testers] know the development lifecycle employed by our developers ?
  • Is our testing aligned to the development lifecycle ?
  • Are we trying to do testing in a way that is not compatible with our development approach ?
  • Do we need more than one testing approach ?
implications of misaligned lifecycles
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
group discussion

Testing Approach

Development Approach

Structured

Iterative

Agile

Structured

Iterative

Agile

Group Discussion
  • Structured Dev. – Iterative Test
  • Expectation of full coverage testing but time-boxed testing delivered
  • Testers have to wait until waterfall stages deliver
  • Faults may not be fixed in time for next test iteration
  • May be able to test early
  • Testers may take a risk based approach
  • Structured Dev. – Agile Test
  • Agile testing approach will not deliver depth of documentation required by structured approach
  • Agile testers will be kicking their heels waiting for code deliveries
  • Agile testing team may finish early and move on to another project
  • Continuous Integration may be beneficial but may take longer to implement
  • Benefit will come from co-location of developers and testers
  • Agile testers should cope better with change
  • Iterative Dev. – Agile Test
  • Complex integration may not be suitable for an agile approach
  • Iterations may be too large for agile testing team – may not have resource or time
  • Faults may not be fixed quickly enough for agile testers
  • Complimentary practices in co-location, business driven and time-boxed
  • Continuous Integration will be beneficial
  • Fits with a Release Testing approach
  • Iterative Dev. – Structured Test
  • Test expectations of complete driving products e.g. requirements specification will not be met
  • Difficulty with early test planning
  • Expectation of early testing may not be met by test environment and test data availability
  • Testing perceived as progressing too slowly
  • Pressure on testers to deliver ‘earlier’
  • Agile Dev. – Structured Test
  • Testers not in touch with requirements and scope
  • Driving products for testing will not be delivered in the form required
  • Developers and testers have a difficult relationship leading to conflict
  • Pressure on testers to deliver ‘earlier’
  • Testing not seen as delivering – takes too long, costs too much
  • Testing does not keep pace with product development and is seen as out of touch – questioning the value of testing
  • Agile Dev. – Iterative Test
  • Testing may be perceived as slowing development, but not to the same extent as Structured Testing
  • May be difficult to identify iterations
  • Testing approach copes will with incremental and evolutionary development approach
  • Fits with a Release Testing approach
  • Complimentary practices in co-location, business driven and time-boxed
conclusion
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 !!!
c ontact d etails
CONTACT DETAILS

Graham Thomas

Independent Consultant

graham@badgerscroft.com

+44 7973 387 853

 www.badgerscroft.com