1 Aligning Development and Testing Lifecycles Software & Systems Quality Conferences United Kingdom rd 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

4 Agenda  Introductionnow  Setting the scene15mins  Group Discussion20mins  Conclusion 5mins

5 A brief slideshow  Identification of the main methodologies  History of development methodologies  Strengths & Weaknesses  Implications for developing a test Strategy

6 Types of Methodology V-Model Structured testing Large projects Fixed interfaces Legal/statutory Rqmts. R A D BUT ST SIT UAT Iterative Testing Several iterations (3) Changing requirements Business driven Time-boxed Incremental (Agile) Small items of work Less structured approach Continuous integration Depth Breadth

7 History of Development Methodologies First Computer Program (Ada Lovelace) First Computer Machine Code – 1940 Assembler Cobol 5159 Basic 64 C 72 C++ 83 Visual Basic 91 C# 2000 Java Visual Studio Programming Languages

8 History of Development Methodologies WATERFALL (Royce) Requirements, design implementation, verification & maintenance Methodologies V-MODEL (Anon) Aligns testing to Waterfall development SPIRAL MODEL (Barry Boehm) Iterative RAD (James Martin) Prototyping, iterative, time-boxed, user driven RUP (Rational) Object oriented, iterative, time-boxed, user driven, high ceremony AGILE e.g. XP (Kent Beck) Incremental, user driven, low process 9899 WaterfallV-Model Spiral Model RAD RUP

9 The V-Model a closer look (1)

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

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

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

13 Iterative e.g. RAD/Spiral (2) Development Testing

14 Iterative e.g. RAD/Spiral (3)

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

16 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

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

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

19 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

20 Group Discussion StructuredIterativeAgile Structured Iterative Agile Testing Approach Development Approach     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

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

22 C ONTACT D ETAILS Graham Thomas Independent Consultant  