Explain about V-model?

Question Posted / rajendra

3 Answers
8959 Views
AppLabs, I also Faced
E-Mail Answers

Answers were Sorted based on User's Feedback

Explain about V-model?..

Answer / muthu

V-Model is one of the software development model, it is
suitable for short-term projects.
here both verification & validation activities are done
parallely as soon as get the requirement from the customer.
In v-model, left side of v is Verification done and right
side of v is validation done.
In verifiction side, get the requirement from customer(CRS)
& then that CRS is extracted as Software Requirement
Specification(SRS)& then SRS is converted to Architect
design(HLD)ie,high level design document it's done by
Senior Architect & then HLD is divided as LLD(low level
design document)is done by Senior software enggr.
and then coding will be done based on LLD.here all
documents are verified and reviewed.

and other side of v-model is Validation activity,
here from bottom to up like wise unit tesing is done based
on LLD document,then Integration testing is done based on
HLD document, then System testing is done based on SRS
document after finish the System testing , end project move
across to Customer side, here customer done Acceptance
testing based on CRS.it consists of two testing one is
alpha testing is done controlled environment at developer's
site with customer involvement,
and another one is beta testing is done by end user at real
world condition.

Is This Answer Correct ?

6 Yes

1 No

Explain about V-model?..

Answer / hari

V-model is a model in which we do verification and
validation parallely...

Is This Answer Correct ?

1 Yes

1 No

Explain about V-model?..

Answer / nag

V-MODEL

V stands for Verification and Validation. This model defines
conceptual mapping in between development stages and testing
stages

W.r.p.t
BRS/CRS/URS--------------------- User Acceptance Testing

Analysis reviews
SRS--------------------- System Testing

HLD-----------Integration testing (programmers)

Designer reviews

LLDUnit Testing (programmers)

Coding (programmers)

In the above V-Model the multiple stages of development
process is embedding (combining) with multiple stages of
testing process. From this model, the maximum organizations
are maintaining separate testing team only for system
testing stage because, that stage is a bottleneck stage
(phase) in software development process. After system
testing the organizations are planning to release the
software to customer site.

1. The Reviews In Analysis:

Generally the software development process starting with
requirements gathering and analysis. In this phase business
analyst category people are developing BRS and SRS
documents. For completeness and correctness of documents,
the same business analyst category people conducting a
review meeting. In this review they are concentrating on
below factors.

Are they right requirements?
(Is they are correct)

Are they complete
requirements? (Is any missing?)

Are they achievable
requirements? (Whether it is possible)

Are they reasonable
requirements? (Time factor)

Are they testable
requirements? (E.g. satellite applications)

2. Reviews In Design:
After completion
of analysis and their testing. Designer category people are
developing HLD and LLD. To verify completeness and
correctness of those documents the same designer category
people are conducting a review meeting. In this review they
are concentrate on below factors

Are they understandable designs?
(Flow of diagram)

Are they designing right
requirements? (With correct functions)

Are they designing complete
requirements? (What the project need)

Are they following able designs?
(Understandable to next level 1)

3. Unit Testing:
After completion of design
and their reviews programmers are concentrating on coding,
to physically construct a software build. In this phase
programmers are writing programs and verify that programs
using white box testing techniques. They are of four types

a. Basis Path Testing
b. Control Structure Testing
c. Program Technique Testing
d. Mutation Testing

a. Basis Path Testing:
During these test,
programmers is verifying that whether a program is running
or not. In this basis path testing programmers are following
on below procedure to test complete program.
Step 1: Draw flow diagram for that program
Step 2: Calculate number of independent paths in that program

IF
T F

IF IF
T F T F

(Cyclomatic complexity) = 4

b. Control Structure Testing:

During this test, programmers are concentrating on the
correctness and completeness of corresponding programs
output. They are check every statement including if
conditions, for loops, memory allocations? etc.

c. Program Technique Testing:

During this test, programmers are verifying the
execution speed of corresponding programs. In this testing
programmers are taking the help of monitors and profilers.
If the program speed is not good then, programmers are
performing changes in structure of that program with out
disturbing functionality.

d. Mutation Testing:
Mutation means a
change in program. Programmers are performing wanted changes
in programs and performing test repeatedly. In this test
repetition programmers are verifying completeness and
correctness of that test on program.

Test Test
Test

Executable Change
Change
Statements

Passed
Passed Passed Failed

(Incomplete Testing) (Complete Testing)

4. Integration Testing:
After
completion of dependent programs development and unit
testing, programmers are connecting them to form a complete
software build. In this Integration of programs, programmers
are verifying interfaces in between every two programs on
modules. There are four types of approaches to integration
modules such as top down, bottom up, hybrid and big bang
approaches.

a. Top-down Approach:
In this
model programmers are interconnecting main modules to sub
modules in the place of under constructive, programmers are
using temporary programs called as stubs (or) called programs

Main

Stub (Diverts control to main
module)

Disconnects

Sub1
Sub2

b. Bottom-up Approach:
In this
model programmers are interconnecting sub modules with out
using under constructive main module. In this place of that
under constructive main module, programmers are using a
temporary program called as driver (or) calling program

Main

Driver (Diverts to next stage)

Sub1

Sub2

c. Hybrid-Approach:
This approach
is a combined form of top down of top down and bottom up
approaches. It is also known as sandwich approach.

Main

Driver

Sub1

Stub

Sub2
Sub3

d. Big-Bang Approach:
In this
model programmers are interconnecting programs after
completion of complete coding.

5. System Testing:
After completion
of integration testing development people are releasing
software build to the separate testing team. This separate
testing team is validating that software build w.r.p.t
customer requirements. In this level of testing, the
separate testing team is using Black Box Testing Techniques.
These techniques are classified into 3 categories

a. Usability Testing
b. Functional Testing
c. Non-Functional Testing

a. Usability Testing:
Generally the
system test execution is a starting with usability testing.
During this test, test engineers are validating user
friendliness of every screen in our application build. This
usability testing is also known as Accessibility Testing.
This usability testing consists of two sub techniques.

1. User Interface Testing
2. Manual Support Testing

1. User Interface Testing:

(Testing as early as possible before build) during this
test, test engineers are applying below 3 factors on every
screen of our application build.

Screens of Build

Ease of use (understandable screens)
Look & Feel (Attractive)
Speed in Interface. E.g. short navigations.

2. Manual Support Testing:

During this test, test engineers are studying help documents
of our application build to estimate context sensitiveness
(Test is applied before releasing software build)

Conclusion:
Generally the technical writers of our
company are developing user manuals before release the
software to customer site. Due to this reason the manual
support testing is coming in to picture at the end of system
testing.

Receive software build from developers

User Interface
Testing

Usability
Testing Functional & Non
Functional Testing

Manual Support Testing

b. Functional Testing:
It is a
mandatory (Compulsory) testing level in system testing.
During this functional testing, test engineers are
concentrating on ?meet customer requirements?. This
functional testing is classified into two sub testing
techniques. They are functionality testing and sanitation
testing

1. Functionality Testing:
During this test, test engineers are
verifying that whether our build functionalities are working
as correct or not? In this this testing, test engineers are
concentrating on below coverage?s.

GUI Coverage (or) Behavior Coverage (Changes in properties

of objects in screens).

Error Handling Coverage (Verify the prevention of wrong
Operations)

Input Domain Coverage (Verify the size & type of every input
object values)

Manipulations Coverage (Correctness of outputs)

Backend Coverage (The impact of front-end operations on
back-end tables)

Order of Functionalities Coverage (

2. Sanitation Testing:
It is also
known as Garbage Testing. During this test, test engineers
are finding extra functionalities in our application build
w.r.p.t customer requirements.

Note:
One defect means not only missing functionality,
not only mistake in functionality but also extra functionality.

c. Non-Functional Testing:

During this non-functional testing, testing team is
concentrating on extra characteristics of that software
build to satisfy customer site people.

1. Compatibility Testing:
It is
also known as Portability Testing. During this testing, test
engineers are validating that whether our application build
is running on customers expected platform or not? Platform
means that operating system, compilers, browsers, and other
system software?s

2. Configuration Testing:
It is
also known as Hardware Compatibility Testing. During this
test, test engineers are running our application build with
various technologies of hardware devices to estimate
hardware compatibility.

E.g. Different technology printers, different technology
network, different topology networks.

3. Recovery Testing:
It is also
known as Reliability Testing. During this test, test
engineers are validating that whether our application build
is changing from abnormal state to normal state or not?

Abnormal

Changing from Abnormal to normal
using back-up and Recovery
Procedures

Normal

4. Inter-System Testing:
It is also known as
Interoperability Testing (or) End-to-End Testing. During
this test, test engineers are validating that
whether our application build is co-existence with other
software applications to share common resources.

E-Seva

Server

WBA server
EBA Local
TBA
DB server
ITA

Server
News component
(Existing Component) Common Resource

5. Security Testing:
It is also known
as penetration testing. During this test, test engineers are
validating below three factors such as

a. Authorization Testing
b. Access Control (Authentication) Testing
c. Encryption / Decryption Testing

a. Authorization Testing:
In
Authorization Testing, test engineers are validating that
whether our application build is allowing valid users and is
preventing invalid users or not?

b. Access control Testing:

In Access Control Testing, test engineers are validating
permissions of users to utilize our application build services.

c. Encryption / Decryption Testing:

In Encryption / Decryption Testing, test
engineers are trying to trace cipher text to original text.

Client
Server

Receiver
Response
Request (Sender)
Receiver Original Text (sender)

Encryption
Decryption
Description
Cipher Text
Encryption

Cipher Text

Note:
In above Security Testing, Authorization and
Access Control Tests are reasonable to be applied by test
engineers. But Encryption / Decryption test is conducted by
separate people in security team

6. Data Volume Testing:
It is
also known as Storage Testing (or) Memory Testing. During
this test, test engineers are finding peek limit of data
handled by our application build.

E.g. Ms-Access technology database are supported 2 GB
database as maximum

7. Load Testing:
Load means that the
numbers of con-current users, which are accessing our
application, build. The execution of our application build
on customer expected configuration and customer expected
load to estimate performance is called Load Testing.

8. Stress Testing:
The execution of our
application build under customer expected configuration and
various loads levels to estimate stability is called Stress
Testing.

9. Installation Testing:
During this
test, test team is doing a practice on software
installation. During this testing, testing team is taking
software build and remaining supported software?s to run our
application build in customer side.

10. Parallel Testing:
It is also known
as Comparative (or) Competitive Testing. During this test,
test engineers are comparing our software build with
old-version of software build (or) with other company?s.
This testing is applicable to software products only.

6. User Acceptance Testing:

After completion of system testing and bugs resolving, the
project management is concentrating on User Acceptance
Testing to collect feedback from Real Customers (or) Model
customers. There are two ways to conduct User Acceptance
Testing.

Alpha Testing Beta Testing

By Real Customers By Model Customers
In our development site In Model customers site
For Software applications For Software products

After Completion of user acceptance testing and their
modifications, project management is concentrating on
software release and maintenance.

7. Maintenance (or) Support:

Project Management is defining the release team along with
few developer, few test engineers and few hardware
engineers. This release team is conducting Port Testing (or)
Deployment (or) Release Testing. During this test release
team is observing below factors.

Complete Installation

Overall Functionality

Input Devices Handling

Output Devices Handling

Secondary Storage Devices Handling

Operating System Error Handling

Co-Existence with other Software Applications

After Completion of above observations release team is
giving training to customer site people and then coming back
to our organization.

During Utilization of that software, customer site people
are sending change request to our organization. The
responsible team in your organization is handling the change
request to provide service to customer site. This
responsible team is also known as Change Control Board (C.C.B).

Change Request C.C.B

Enhancement
Missed Defect

Impact Analysis
Impact Analysis

Perform Software Changes Perform Software Changes

Test Software Changes
Test Software Changes

Improve Test
Efficiency

Case Study

Numbers Testing Phase Testing Techniques Responsibility
1 Testing in Analysis Reviews Business Analyst
2 Testing in Design Reviews & Prototype Designers (or)
Architects
3 Unit Testing White Box Testing Techniques Programmers
4 Integration Testing Top-down, Bottom-up, Hybrid,
Big-bang approaches Programmers
5 System Testing Black box testing Techniques Test Engineers
6 User Acceptance Testing Alpha, Beta Testing Real Customers
(or) Model customers
7 Port Testing Complete Installation, Overall
Functionalities, Input & Output Devices Handling, Secondary
Storage Devices Handling, Operating System Error Handling,
Co-Exist Nance with other Software Applications Release Team
8 Test Software Changes in Maintenance Regression Testing
Change Control Board (C.C.B)

Is This Answer Correct ?

0 Yes

3 No

Post New Answer