1 / 21

Aligning Development and Testing Lifecycles

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

lauralawson
Download Presentation

Aligning Development and Testing Lifecycles

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

More Related