Software & Systems Quality Conferences United Kingdom 2006. Aligning Development and Testing Lifecycles. 3 rd October 2006 Facilitated by Graham Thomas Independent Consultant. Abstract.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
United Kingdom 2006
Aligning Development and Testing Lifecycles
Facilitated byGraham ThomasIndependent Consultant
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
First Computer Program
1842 - 43
AGILE e.g. XP
Incremental, user driven, low process
Object oriented, iterative, time-boxed, user driven, high ceremony
Prototyping, iterative, time-boxed, user driven
implementation, verification & maintenance
Aligns testing to
System Integration Test
Detailed System Design
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
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 mistakesAgile - XP explained (2)
+44 7973 387 853