The document proposes a Vgile methodology that combines elements of the traditional V-model lifecycle with agile principles like risk-based testing and small cross-functional teams. It advocates a hybrid approach to address the need for flexible yet reliable systems within shorter development cycles. Case studies and best practices are provided, including continuous integration, test-driven development, and maximizing communication through frequent meetings. The methodology aims to make testing activities more efficient through a focus on prevention and early static testing.

1. V-
Agile model
Risk
Based
Vgile
ryonish@tact.co.il
A copyright of Ram Yonish. Do not use without an explicit permission

2. My self
My company
My idea

3. Agenda
Basic assumptions & Motivation
Traditional vs. Current trends
Case study - example
Risk based testing
Vgile concept
Vgile best practices
summary
3

4. Basic assumptions & Motivation
• More competition requires more flexible & reliable
systems = much more features and changes in a
Flexible
systems shorter time frame
• Vmodel is the most common L.C development
model
Vmodel • Many organizations want to stay with Vmodel
• Many organizations are interested in Agile but
afraid to make a dramatic move towards such a
Agile model
???
4

5. Many types of life cycles to choose from 1/2
A cynical senior manager said, “It feels as if I‟m stuck between
the traditionalists and the agilistas. We can‟t use phase-gate
anymore, because it‟s not „agile‟ enough. And the last time,
when that multisite project tried Scrum, they failed miserably.
Isn‟t there a right approach to our projects?”
serial iterative incremental agile
waterfall spiral Design to scrum
schedule
V model XP
© 2008 Johanna Rothman
http://www.jrothman.com/Papers/Cutter/whatlifecycle.html
5

6. Many types of life cycles to choose from 2/2
6

7. Traditional vs. Current trends
“There are still
no silver bullets,
but we can
accept that
there are new
kinds of regular
bullets
available”
Richard Turner
(cmmi & agile expert) http://www.stsc.hill.af.mil/CrossTalk/2007/04/0704Turner.html
7

8. Case study - what do you think?
 100 < new features/ changes per version (all have FD)
 1:5 testers/ developers ratio (5-10 testers)
 A version every 4-6 weeks
What would you do?
 STP?
 Reviews?  Test coverage?
 STD?  Exit/ entry criteria?
 Scripted testing?  Classic/ modern
techniques?
8

9. Risk based testing
 The amount of testing is based on “feature risk level”
 The feature owner/ designer determine the “risk level”
 Risk level 1: STP, reviews, simulations, scripted testing, high
coverage (100% successful testing) and documentation. Vgile teams
 Risk level 2: medium coverage (80% successful testing) and doc’
 Risk level 3: low coverage (50% successful testing) no doc’, Mainly
exploratory testing.
9

10. Testing Highlights
 Develop a generic list (use brain storming)
 Adjust according to the specific version/ feature
 Part of the design document (Responsibility of the designer)
 Early in the process (prevention activity):
 Better design
 Basis for dev testing
 Skeleton for STP (what to test)
Example
10

11. Vgile concept
A classic “serial” life cycle
Design Development Validation
Different owner for different feature life cycle phase
Prod Dev‟ Test
uct
Business, Business, Business,
Technology, Technology, Technology,
Standards & Standards & Standards &
regulations regulations regulations
Development Test Test Product Product Development
11

12. Vgile - the PDT triangle
Small team:
Product/Feature owner (designer, product manager, user)
Developer
Tester Product
Team responsibility for a feature L.C Business,
Technology,
Standards &
Team member leader according to the
regulations
development phase Development Test
Team activities: review, dry run, unit, simulations,
integration and system testing
More than one feature per every team
12

13. Vgile - best practices
Max 3 months for every release
Weekly meetings (also by remote access tools)
“KISS” - hands on, short, just enough doc‟
In addition to traditional QA methodologies:
Unit & Integration test by developers ( also: continues
integration, nightly builds, TDD)
Entry & Exit criteria
Product
Test documentation (STP, STD, STR)
Business,
Technology,
Risk based testing Standards &
regulations
Static testing (e.g. early test design) Developer Tester
13

14. Vgile - the PDT triangle HEART
Every action in every phase should be monitored
and reviewed based on 3 essentials:
Business: understand your users and business
process
Technology: understand your environment, hardware
and software issues, system architecture and user
configurations
Standards & Regulations: understand
industry standards, organization policy and Business,
regulations, measurements & metrics Technology
, Standards
&
regulations
14

15. Vgile concept conclusion
Based on the V model “serial” LC process
Risk based testing & prevention activities
Agile elements:
More communication
Team responsibility
15

16. I’m not alone, this is what Forrester have to say about
Mixing methodologies (January 20, 2010 )
16

17. References
“agile development mainstream adoption has
changed agility”, Forrester - Dave west and Tom grant, January
20, 2010
“Testing and scrum”, van roosmalen, fall 2007
“What Lifecycle? Selecting the Right Model for Your
Project”, Johanna Rothman, 2008
“Toward Agile Systems Engineering Processes”,
Dr. Richard Turner, Systems and Software Consortium, April 2007
“A Few Good (Agile) Testers - Introducing Agile Testing
Brings Quality Without An Army Of Testers”, Forrester - Margo
Visitacion VP, December 18, 2009
17

18. Vgile methodology
Easy to understand
Easy to implement
Easy to maintain
Thanks 
ryonish@tact.co.il
www.tact.co.il
18