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

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 Introduction now Setting the scene 15mins Group Discussion 20mins Conclusion 5mins

A brief slideshow Identification of the main methodologies History of development methodologies Strengths & Weaknesses Implications for developing a test Strategy

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

History of Development Methodologies First Computer Program (1842-43 Ada Lovelace) First Computer (1930-1940) Languages Started with Machine Code Assembler 1951 COBOL 1959 BASIC 1964 C 1972 C++ 1983 Visual Basic 1991 C# 2000

History of Development Methodologies Waterfall (1970 - 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

The V-Model a closer look (1)

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

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

Iterative e.g. RAD/Spiral (1)

Iterative e.g. RAD/Spiral (2)

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

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

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

Shared Experience Structured Iterative Agile Testing Approach Development Approach

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)

CONTACT DETAILS Graham Thomas Independent Consultant  graham@badgerscroft.com  +44 7973 387 853  www.badgerscroft.com