Aligning Development and Testing Lifecycles

1. Software & Systems Quality Conferences United Kingdom 2006 Aligning Development and Testing Lifecycles 3rdOctober 2006 Facilitated byGraham ThomasIndependent 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 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 (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

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

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

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

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

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

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. Testing Approach Development Approach Structured Iterative Agile Structured Iterative Agile Shared Experience

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 graham@badgerscroft.com +44 7973 387 853  www.badgerscroft.com