The V-model is a software development lifecycle model where each phase of the development process is validated by an equivalent phase of testing. It emphasizes testing at each development stage. In the V-model, testing begins during the requirements analysis phase, and each subsequent development phase is tested before moving further down the V, and development and testing phases occur in parallel. The benefits of the V-model include preventing faults, avoiding downward flow of defects, lower rework costs, improved quality and risk management.

1. V – Model (Software Development)
By: Abdul Raheem.

2. • V-Model evolved from waterfall Model.
• Each phase must be completed before the next phase begins.
• Instead of moving down in a linear way, the process steps are
bent upwards after the coding phase, to form the typical V shape.
• Testing is emphasized in this model more than in the waterfall
model.
• It is a structured approach to testing.
• Brings high quality into the development of our products.
The V-Shaped Model

3. Steps in the V-Shaped Model
Quality is guaranteed at each project stage.

4. Analyze Design
Detailed
Design
Component
Test
Assembly
Test Prod Test Deploy
Analyze Design
Detailed
Design
Component
Test
Assembly
Test Prod Test Deploy
Defect
Origin
Defect
Discovered
Stage Containment
This term is used to identify problems existing in the product being
developed before proceeding to the following stage.
• More errors than defects.
• Cost and effort for fixing problems is minimized.
With Stage Containment

5. Analyze Design
Detailed
Design
Component
Test
Assembly
Test Prod Test Deploy
Analyze Design
Detailed
Design
Component
Test
Assembly
Test Prod Test Deploy
Defect
Origin
Defect
Discovered
Without Stage Containment
• More defects than errors.
• Fixes become more expensive and difficult.

6. Analyze Design
Detailed
Design
Component
Test
Assembly
Test Prod Test Deploy
Analyze Design
Detailed
Design
Component
Test
Assembly
Test Prod Test Deploy
Defect
Origin
Defect
Discovered
Without Stage Containment
Worst Case!

7. Entry and Exit Criteria
Entry Criteria
• The Term Entry Criteria refers tot the input conditions
required from the previous processes to support a specific
stage.
Exit Criteria
• The term Exit Criteria refers to the output conditions required
by a specific process to determine its thoroughness and
correct completion.
• The Exit Criteria for one stage can constitute part of the
Entry Criteria for the following stage.

8. Deliverable Description
Test Approach Explains the objectives and scope of the test;
Documents entry/exit criteria and key dates
Test Scenarios Provides high-level descriptions of functionality to be
tested
Test Conditions and Expected
Results
Describes all items and results that must be covered
to fulfill each Test Scenarios
Test Cycle Control Sheet Groups test scripts into logical categories (or cycles);
documents when and by whom each cycle will be
executed.
Test Scripts Provides step-bystep instructions and detailed
results for a test executor to follow during test
execution
The Five Key Deliverables of Test Planning

9. Unit testing
 The most ‘micro’ scale of Testing
 A unit = smallest testable software component
 Objects and methods
 Procedures / functions
 Performed by Programmer
 A tester can help.
 Requires detailed knowledge of the internal program
design and code.
 The units are tested in isolation.
 Ensures the component is working according to the detailed
design/build specifications of the module.
 Not to be confused with debugging.
 Also known as component, module, or program testing.

10. Integration Testing
 Testing of more than one (tested) unit together to
determine if they function correctly.
 Focus on interfaces
 Communication between units
 It is done using the integration test design prepared during
the architecture design phase.
 Helps assembling incrementally a whole system, ensuring
the correct ‘flow’ of data from the first through the final
component.
 Done by developers/designers and testers in collaboration
 Also called Interface Testing or Assembly Testing.

11. System testing
Testing the system as a whole - Black-box type testing
that is based on overall requirements specifications; covers
all combined parts of a system.
 Ensures that system meets all functional and business
requirements.
Focus
 Verifying that specifications are met
 Validating that the system can be used for the
intended purpose
 The system test design is derived from the system
design documents and is used in this phase.
 It can involve a number of specialized types of tests to
check performance, stress, documentation etc. Sometimes
testing is automated using testing tools.
 Done by Independent testing group

12. Acceptance testing
 To determine whether a system satisfies its acceptance
criteria and business requirements or not.
 Similar to System testing in that the whole system is
checked, but the important difference is the change in focus.
 Done by real business users.
 It enables the customer to determine whether to accept the
system or not.
 Also called as Beta Testing, Application Testing or End User
Testing.
 Approach
 Should be performed in real operating environment .
 Customer should be able to perform any test based on
their business processes.
 Final Customer sign-off.

13. • Faults are prevented and it stops fault multiplication.
• Avoids the downward flow of defect.
• Lower defect Resolution cost due to earlier detection.
• Improved quality and reliability.
• Reduction in the amount of Re-work.
• Improved Risk Management
• Validation and Verification at each level of stage containment
• Allows testers to be active in the project early in the project’s
lifecycle. They develop critical knowledge about the system.
Benefits of V-Model

14. Thank You!