0% found this document useful (0 votes)
101 views30 pages

V Model

The V Model is a software development lifecycle model that uses verification and validation at each stage of development. The left side of the V represents the design phase, while the right side represents the testing phase. Each stage of testing on the right side corresponds to a stage of design on the left side. The V Model helps ensure requirements are met at each stage before moving to the next.

Uploaded by

priya dharshini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
101 views30 pages

V Model

The V Model is a software development lifecycle model that uses verification and validation at each stage of development. The left side of the V represents the design phase, while the right side represents the testing phase. Each stage of testing on the right side corresponds to a stage of design on the left side. The V Model helps ensure requirements are met at each stage before moving to the next.

Uploaded by

priya dharshini
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 30

• What is meant by V Model?

• It is Verification and Validation Model.


• It is called as V Model because it is looks like V
shape.
• Left arm represents the Verification Process.
• Right arm represents Validation Process.
• Result of each phase of verification is used as
input of validation process
V-model
• What is meant by Verification?
• Verification process means to check
that we build the product is right or not?
• Output of each phase of SDLC are review to
and defect.
• Its Static testing as application is not
executed(Application is getting developed).
Phases of Verificaton

• I.Requirements
• II.Software Specication
• III.High Level Design
• IV.Low Level Design
• V.Coding
1.Requirements:-
In this model the requirement are gatheredbefore
development and system test plan iscreated.
2.Software Specification:-
This phase contains the hardware and softwareneeds
according to project
3.High Level Design:-
It defines overall design of a system and architecturedesign of
project
4.Low Level Design:-
It Defines detailed description of every module ofsoftware.
5.Coding:-
• The coding phase includes all programs inproject.
Validation:-
• To check that we are building the product is right or not?
• To check that software being developed satisfies all
functional activities.
• Validation start (after coding) once Verication processis
completed.
Phases of Validation process
• Unit Testing.

• Integration Testing.

• System Testing.

• Acceptance Testing
• 1.Unit Testing:-
• Unit testing is the smallest piece of code.
• This testing is done by developer
2.Integration Testing:-
• Two or more modules are combined together
and then integration testing is done.
• Different system is tested combined way.
3.System Testing:-
• System testing checks
the user expectations are fulfilled or not?.
• System testing is done after whole project is ready.
• It is done by tester.
4.User Acceptance Testing:-
• To test that application meets user requirement.
• It is also called as end-user testing.
• It is done by the User & Tester also.
Advantages

• Easy to understand
• Avoids the downward flow of the defects
• Saves lots of time
Disadvantages
• Very rigid and least flexible
• Not good for a complex project
• If any changes happen in the midway,then the
test documents along with the required
documents has to be updated
Program correctness and verification

• Goal of software testing is to run the potential


gramme on a set iof input data and determine
if it acts according to specification .
• It leads to making assumptions about the
behaviour of the programme at particular
points in the execution and then verifying
these assumptions.
• Programme testers and programme providers
often make kind remarks about how testing
Reliability Versus Safety

• The term "Software Reliability" Operational - dependability. It


is defined as a system or component's capacity to carry out its
essential tasks under constant circumstances for a certain
amount of time.
• The chance that a software system completes its assigned job
in a certain environment for a predetermined number of input
instances, assuming that the hardware and the input are
error-free, is another definition of software reliability.
• Software reliability, together with functionality, usability,
performance, serviceability, capability, installability,
maintainability and documentation, is a crucial component of
software quality.
Failures, Errors and Fault

Software failures
Before describing the steps needed to analyses the
dependability and safety of software, it is critical to
comprehend what a software failure entail.
The random or wear-related failure behavior. we see
in hardware is not present in software.
As long as the same input and computer states are
present, software will always operate in the same
manner.
What is an Error?

• Error is a condition that arises when a developer


or member of the development team does not
comprehend the concept of a need, and this
‘misunderstanding results in defective code.
• Error is the phrase used to describe this
circumstance and was mostly created by the
developers.
• Wrong logic, grammar or loops may produce
errors that affect the end-user experience.
What’s a fault ?

• Sometimes due to specific conditions Tike a lack


of finances or failing to take the necessary
precautions When a softwire error occurs, it
signifies that the logic to manage the
application's problems was not included.
• Although this is a bad condition, it often results
from incorrectly specified stages or a lack of data
definitions.
software Testing Principles

• Software testing is a process that involves putting software or an


application to use in order to find faults or flaws. Following certain
guidelines can help us test software or applications without creating
any problems and it will also save the test engineers' time and effort
as they put their time and effort into doing so. We will learn about
the seven fundamental tenets of software testing in this part.

• Testing shows the presence of defects.


• Exhaustive testing is not possible.
• Early testing.
• Defect clustering.
• Pesticide paradox.
• Testing is context-dependent.
• Absence of errors fallacy.
Testing shows the presence of defects:

– The application will be put through testing by the test


engineer to ensure that there are no bugs or flaws.
– We can only pinpoint the existence of problems in the
application or programme when testing.
– The main goal of testing is to find any flaws that might
prevent the product from fulfilling the client's needs
by using a variety of methods and testing techniques.
– Since the entire test should be able to be traced back
to the customer requirement.
Exhaustive testing is not possible:

• It might often appear quite difficult to test all


the modules and their features throughout
the real testing process using effective and
ineffective combinations of the input data.
Early testing:

early testing refers to the idea that all testing


activities should begin in the early stages of the
requirement analysis stage of the software
development life cycle in order to identify the
defects.
Defect clustering:

The defect clustering specified that we can identify


the quantities of problems that are associated to a
limited number of modules during the testing
procedure
Pesticide paradox:

• This rule said that if the same set of test cases


were run again over a given period of time,
the tests would not be able to discover any
new problems in the programme or
application
Testing is context-dependent

• The testing is a context-dependent concept


that asserts that a variety of markets,
including "e-commerce websites, business
websites and others, are available.
• Every application has its own requirements,
features and functionality, therefore there is a
clear technique to test both commercial and
e-commerce websites.
Steps of inspection
• Planning: The planning phase starts when the entry
criteria for the inspection state are ‘met. A moderator
verifies that the product entry criteria are met.
• Overview: In the overview phase, a presentation is
given to the inspector with some background
information needed to review the software product
properly.
• Preparation: This is considered an individual activity. In
this part of the process, the inspector collects all the
materials needed for inspection, reviews that material
and notes any defects.
• Meeting: The moderator conducts the meeting.
In the meeting, the defects are collected and
reviewed.
• Rework: The author performs this part of the
process in response fo defect disposition
determined at the meeting.
• Follow-up: In follow-up, the moderator makes
the corrections and then compiles the inspection
management and defects summary report.
Stages of Testing
• Unit testing is a part of Test-Driven
Development (TDD), a methodical strategy
that carefully constructs a product via ongoing
testing and refinement.
• Prior to using additional testing techniques
like integration testing, this testing approach is
also the initial level of software testing.

You might also like