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

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

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 R UAT A SIT D ST B UT V-Model Structured testing
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

6. History of Development Methodologies
First Computer Program ( Ada Lovelace)
First Computer ( )
Languages
Started with Machine Code
Assembler 1951
COBOL 1959
BASIC 1964 C C
Visual Basic 1991 C#

7. History of Development Methodologies
Waterfall ( Royce )
Requirements, Design, Implementation, Verification & Maintenance
V-Model (1980 ish – Anon)
Aligns testing to waterfall development
Spiral Model (Barry Boehm – 1985)
Iterative
RAD (1991 – James Martin)
Prototyping, Iterative, Time-boxed, user driven
RUP (1998 – Rational)
Object Orientated, Iterative, user driven, high ceremony
Agile e.g. XP (1999 – Kent Beck)
Incremental, user driven, low process

8. The V-Model a closer look (1)

9. The V-Model a closer look (2)
Conical
Model
Unit
Testing
Component
Integration
Testing
System
Testing
User
Acceptance
Testing

10. The V-Model a closer look (3)
OAT
Rqmts
- NFR
- Func
UAT {
Use Cases/DBD
BAD
System Integration Test
Business Scenarios
EIT
Design Overview
Detailed System Design
System Test

11. Iterative e.g. RAD/Spiral (1)

12. Iterative e.g. RAD/Spiral (2)

13. Agile - XP explained (1) The Values Communication Simplicity Feedback
Courage
Respect (added in the latest version)

14. Agile - XP explained (2)
Test First Programming Test 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

15. 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!

16. 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 ?

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

18. Shared Experience
Structured
Iterative
Agile
Testing Approach
Development Approach

19. Conclusions
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)

20. CONTACT DETAILS Graham Thomas Independent Consultant  