Software Quality

Assurance

MODULE-4: Software Verification and Validation,

V-test Model:

Janhavi Vadke
janhavi.vadke@vsit.edu.in

Vidyalankar School of
Information Technology
Wadala (E), Mumbai
www.vsit.edu.in
 Certificate
This is to certify that the e-book titled “Software quality
assurance” comprises all elementary learning tools for a better
understating of the relevant concepts. This e-book is comprehensively compiled
as per the predefined eight parameters and guidelines.

Signature Date: 05-03-2021

Ms. Janhavi Vadke
Assistant Professor
Department of IT

DISCLAIMER: The information contained in this e-book is compiled and

distributed for educational purposes only. This e-book has been designed to help
learners understand relevant concepts with a more dynamic interface. The
compiler of this e-book and Vidyalankar School of Information Technology give
full and due credit to the authors of the contents, developers and all websites
from wherever information has been sourced. We acknowledge our gratitude
towards the websites YouTube, Wikipedia, and Google search engine. No
commercial benefits are being drawn from this project.
Unit 4
Software Verification and Validation: Introduction, Verification, Verification Workbench, Methods
of Verification, Types of reviews on the basis of Stage Phase, Entities involved in verification,
Reviews in testing lifecycle, Coverage in Verification, Concerns of Verification, Validation, Validation
Workbench, Levels of Validation, Coverage in Validation, Acceptance Testing, Management of
Verification and Validation, Software development verification and validation activities.
V-test Model: Introduction, V-model for software, testing during Proposal stage, Testing during
requirement stage, Testing during test planning phase, Testing during design phase, Testing during
coding, VV Model, Critical Roles and Responsibilities.

Recommended Books
• Software Testing and Continuous Quality- William E. Lewis
• Software Testing: Principles, Techniques and Tools-M. G. Limaye
• Foundations of Software Testing- Dorothy Graham, Erik van Veenendaal,
Isabel Evans, Rex Black
• Software Testing: A Craftsman’s Approach- Paul C. Jorgenson

Prerequisites and Linking

Unit IV Pre-requisites Sem. VI

Software Verification and SE, SPM Project

Validation, V-test Model

Verification &Validation.

• Verification and Validation activities are complementary &completely dependent on each

other. Two views of quality can be seen in software testing:

• Conformance of requirement' is defined as software developers view of quality.

• It is called as Verification

• Fitness for use, which is defined as customer view of quality performed by tester & given to
customer for acceptance testing.

Verification:

• Verification is also called as 'static technique'

• It is not involving execution of code, program and work product.

• It helps in identification of defect and its location which helps in correction. Advantages of
Verification:
• Verification ensures that the work product is following the processes correctly defined by
organization or customer. It can find the defects & it’s root cause • Cost of finding & fixing
defects is less.

• Disadvantages of Verification: • It cannot show whether the developed software is correct

or not. Rather, it shows whether the processes have been followed or not. • Actual working
software may not be accessed by verification as it does not cover a kind of execution of a
work product.

Validation:

• Validation is an approach to evaluate whether the final built software product meets its
specification or not.

• Validation is also called as 'dynamic testing' because it involves execution of code to find
defects.

• Validation is basically done by the testers during testing

Advantages of Validation

It satisfies customer’s requirement & needs

• It represents actual user interaction with the system

• Black-box testing approach is use for system, integration & acceptance testing
Disadvantages of Validation:

• Test cases can fail to find defects.

• Overhead code needs to be written for drivers & stubs

• Tester might do redundant testing by executing same section of code again & again.

Difference between verification and validation methods.

Prerequisites for verification

Training required by people for conducting verification

Standards, guidelines, tools to be used during verification

Verification Do and Check process definition

Methods of Verification.

There are many methods of verification:

Self-Review:

It is not an official review in verification as it is assumed that everybody does as self-check

before giving product for verification

Defects found in self-review help in self-education & improvement

Advantages of self-review:

It is an excellent tool for self-learning

There is no ego involved as finding is not shared with anybody.

Disadvantages:

Developer will be more focus on coding rather than reviewing the code developed by them

Developer with less confidence may change the correct implementation

Peer review:

This reviews are conducted frequently in SDLC

Code review is done by developer

Test case review is done by tester

Two types of peer review:

Online peer review:

In this review, author & reviewer meet together & give review jointly

Offline peer review:

In this review, author informs reviewer that software is ready for review & reviewer reviews
it according to his time availability & send results to author

Author may accept or reject review comments

Advantages:

It is highly informal & unplanned

Defects are discussed & decision are taken informally

Disadvantages:

Reviewer might not be an expertise

Peer might fix defects but won’t show mistake of his friends

Superior Review:

Superior such as team leader or module leader will review the product made by sub-ordinates

Advantages of superior review:

Superior may have better understanding than author about requirements & design

Superior can share his experience

Disadvantages of superior review:

It can hamper superior’s work itself

If project is related to new technology, then this approach won’t work.

Walk-Through:

It involves larger team along with author reviewing the project

Advantages:

Each & every member is involved in decision-making.

Useful for training entire team at once

Disadvantages:

Time can be constrained

Whole team might not be expert in project

Inspection

It involves domain expert & absence of author. They can be external to the organization

Advantages of inspection

Expert's opinion is available as these people are present during review

Inspection must be very time effective as availability of experts is limited

Defects are recorded but solutions are not given

Disadvantages of inspection

Experts may not be ready with review comments before inspection and time may not be
utilized properly

Expert's opinion may vary from realities

Facilitator's job is critical

Guidelines for inspection

Organization / project must plan for inspection well in advance

Allocation of trained resources for facilitating inspection process, recording the opinions of
experts, presenting artifacts etc is essential to maintain the agenda and inspection flow

Expertise in terms of logistics arrangement is also needed

Moderator / leader must circulate the work product in advance

Product must be clear, compiled, checked for grammar, formatting etc

Inspection team may be of 3 – 5 people

Maximum time allocated must not exceed 1 – 1.5 hours

It is moderator's responsibility to maintain the agenda of inspection

Manager or superior of the author may not be involved in inspection

Many organizations do not allow author to be present in inspection

One must concentrate on locating defect and not on fixing them

Classify and record defects in different categories

Review inspection process for continuous improvement

Inspection is a very formal way of reviewing the work product. A formal review is carried
out in following phases: -

Phases of Inspection

a) Planning for Inspection: - Planning for Inspection involves selecting people for inspection,
allocating roles to other people (such as facilitator, recorder, and presenter). Defining the
entry and exit criteria for inspection, and selecting which parts of artifacts are to be looked at.

b) Kick-off Inspection: - Kick-off Inspection may start by distributing artifacts, explaining

the objectives of inspection, process to be followed for inspection, and checking entry criteria
for the artifacts as well as inspection process.

c) Individual preparation: - Participants must come prepared for the inspection. Work must be
reviewed and comments by each of the participants must be ready before the inspection
meeting.

d) Inspection Meeting: - The participants of the meeting may simply note defects, make
recommendations for handling the defects or make decisions about the defects. Recorder
shall note these comments.

e) Decision on comments: - It is not necessary that all the comments will be accepted.
Comments may be rejected, differed or may undergo another iteration of inspection. For
accepted comments, the fixing of defects is done by the author.

f) Follow Up: - Completing the actions as identified in minutes of meeting like checking that
the defects have been addressed and whether exit criteria has been met or not. the findings
can be used to gather statistics about work product, project or process.

Role and responsibilities of a reviewer includes: -

a) Manager: - Manager is the person responsible for getting the work product inspected. For a
project he may be the project manager. Manager decides on the execution of inspection,
defines the schedule, allocates time, defines the objectives to be met, and determines if the
inspection objectives have been met or not at the end of inspection process.

b) Moderator: - Moderator is the person who leads the inspection of the artifacts, including
planning the inspection, running the meeting and follow-up after the meeting. Moderator is
also called ‘Facilitator’ as he facilitates the entire process.

c) Author: - Author is the writer or the person with chief responsibility of the artifact to be
inspected. He is the person who has created the artifacts, and will be taking action based on
the outcome of the inspection.

d) Reviewers (Checkers/Inspectors): - Individuals with specific technical or business

background who, after necessary preparation, identify and describe findings in the work
product under inspection in the form of comments. Reviewers must be chosen to represent
different perspectives and roles in the inspection process and must take part in meetings.
e) Recorder: - Recorder is the person who documents all the issues, problems, and open
points that are identified during the meeting. The presence of a recorder is a must because if
reviewer or inspectors are discussing something, they have to decide collectively about the
comment. Recorder is also expected to write minutes of meeting.

A review is a systematic examination of a document by one or more people with the main
aim of finding and removing errors early in the software development life cycle. Reviews are
used to verify documents such as requirements, system designs, code, test plans and test
cases.

Success factors for inspections

Each inspection must have a clear predefined objective

The right people must be involved in inspection

Defects found are welcomed and expressed objectively

People issues and psychological aspects are not dealt with in an inspection process

Inspection techniques are applied that are suitable to the type and level of software work
products and inspectors

Checklists or role playing are used if appropriate

Training is to be given in inspection techniques

Management support is essential for a good inspection process

There must be an emphasis on learning lessons and process improvement

Audit

Kickoff audit

Periodic Software Quality Assurance audit

Phase end audit

Predelivery audit

Product audit

Verification can confirm that the work product has followed the processes correctly
It can find defect in terms of deviations from standards easily
Location of the defect can be found
It can reduce the cost of finding and fixing the defects
It can locate the defect easily as work product under review is yet to be integrated
It can be used effectively for training people
Productivity is improved and timescales reduced because the correction of defects in early
stages and work-products will help to ensure that those work-products are clear and
unambiguous.
Testing costs and time is reduced as there is enough time spent during the initial phase.
Reduction in costs because fewer defects in the final software.
Verification helps in lowering down the count of the defect in the later stages of
development.
Verifying the product at the starting phase of the development will help in understanding the
product in a better way.
It reduces the chances of failures in the software application or product.
It helps in building the product as per the customer specifications and needs.

Software Testing -Test Review

https://www.youtube.com/watch?v=YosSY0e5Xy4

Types of review on the basis of stage/phase

In-process review:

This review is conducted to check whether the input given is correct or not whether all
processes are following correctly or not It can take place in between any project of SDLC
Common steps of in-process reviews are: Work product & metric undergoing review are
created & submitted to the stakeholder in advanced Inputs are received from stakeholders to
initiate various actions Risk are identified, reviewed & actions are implemented Issues like
hardware availability, software availability & training are identified & actions are
implemented
Milestone review It is performed periodically basis on time frame, completion of phase or
milestone achieved Ex. Requirement review at the end of requirement phase Three types of
milestone review:

Phase end review: It is performed at the end of any phase of SDLC It is suitable for waterfall
cycle .

Phase-End Review: Phase-end review is conducted at the end of a development phase under
review such as requirements phase, design phase, coding and testing. Phase end reviews are
also termed ‘gate reviews’ by some organizations as the gate at phase. End opens only when
the output criteria of the phase are achieved by the work product. Phase end reviews are used
extensively in agile development as one phase completion is marked by review before the
next phase is started.

Periodic Review: It is performed in weekly, monthly & quarterly manner. When one phase
ends in reality another phase may be half way through. In such cases, we may have review on
some periodic basis such as weekly, monthly, quarterly etc. Project plan must define various
periods when review of project related activities will be conducted. Stakeholders may be
required to review the progress and take actions on any impediments.
Percent Completion Review: It is a combination of both periodic & phase-end Development
activities are assessed on basis of percent completion

Process of In Process Review :

Following are steps of in process reviews are given below :

Work product, and metrics undergoing review are created and submitted to the stakeholders
well in advance.

Inputs are received from stack holders to initiate various actions.

Risks identified by the project are reviewed and actions may be initiated as required. Risks

which no longer exist may be closed and risks which cannot affect the project are retired.

Any issue related to any stakeholder is noted and follow up actions are initiated.

Review reports are generated at the end of review which acts as a foundation for the next

review.

Post-Implementation Review: It is performed after the deployment of project Process: All

activities of project are reviewed.

Post mortem reviews/ post implementation reviews are conducted after the project is over and

delivered to the customer.

Process of Post Implementation Review :

Some of the steps commonly found in post implementation review are as follows :

At the end of the project when final deliverables are send to the customer and when final

payments are received, post implementation reviews are planned.

All the stakeholders of the project gather at a predefined time.

All the activities of project are reviewed and different stakeholders are expected to

retrospect their part of work.

Each and every activity is listed to identify if something went exceptionally good or

exceptionally bad when the project was executed. All project related metrics are reviewed.

All reusable components are added in an organization repository

Review in testing lifecycle

Reviews associated with STLC are as follows:

Test-readiness review:

It is conducted by test managers or test leads with the project manager to ensure that the
product under development is ready for testing It is carried out at every stage of development
(Unit testing, integration testing, system testing, interface testing, system testing acceptance
testing, etc.)

Prerequisites Training:

Prerequisites such as the database, operating system, etc. may be needed during the software
installation. If it is specified in the requirement statement that installation must check for the
availability of such prerequisites, then it must be tested for these requirements.

Updation Testing:

During software installation, it is expected that the system should check whether the same
software already exists there or not.

If the existing version of the software is older than the one being installed, then it also
prompts for a repair or new installation.

Un-installation testing:

This is done by the organizations to verify if the un-installation is clean or not whenever any
application is un-installed, all the associated files should be removed from the disk. Care
should be taken that applications running before installation must be running after installation
and also once un-installation is done.

Test-completion review:

It is conducted when a testing cycle is completed. It recommends about the status of an

application. It indicates the development team whether a product can go to the next phase or
it needs any repairing before it can be declared successful.
Coverage in verification:

Statement coverage

It is a white box testing technique, which involves the execution of all the statements at least
once in the source code.

It is a metric, which is used to calculate and measure the number of statements in the source
code which have been executed.

The main drawback of this technique is that we cannot test the false condition in it.

(Statement coverage = No of statements Executed/Total no of statements in the source code *

100)

Example:

Read A Read B if A>B Print “A is greater than B” else Print "B is greater than A" end if

Set1: If A =5, B =2 No of statements Executed: 5 Total no of statements in the source code: 7

Statement coverage =5/7*100 = 71.00 %

Set1: If A =2, B =5 No of statements Executed: 6 Total nos of statements in the source code:
7 Statement coverage =6/7*100 = 85.20 %

Path Coverage: The way that path coverage testing works is that the testers must look at
each possible scenario, so that all lines of code are covered. In a very basic example, consider
a code function that takes in a variable "x" and returns one of two results: if x is greater than
5, the program will return the result "A" and if x is less than or equal to 5, the program will
return the result "B." The code for the program would look something like this:

input x if x > 5 then return A else return B In order for path coverage testing to effectively
"cover all paths," the two test cases must be run, with x greater than 5 and x less than or equal
to 5. Experts generally consider path coverage testing to be a type of white box testing, which
actually inspects the internal code of a program, rather just relying on external inputs and
strategies that are considered black box testing, which do not consider internal code. Decision
Coverage:

Decision coverage or Branch coverage is a testing method, which aims to ensure that each
one of the possible branch from each decision point is executed at least once and thereby
ensuring that all reachable code is executed.

That is, every decision is taken each way, true and false. It helps in validating all the branches
in the code making sure that no branch leads to abnormal behaviour of the application Read
A Read B IF A+B >10 THEN Print "A+B is Large" ENDIF If A>5 THEN Print "A Large"
ENDIF to calculate Branch Coverage, one has to find out the minimum number of paths
which will ensure that all the edges are covered. In this case there is no single path which
will ensure coverage of all the edges at once. The aim is to cover all possible true/false
decisions. (1)1A-2C-3D-E-4G-5H (2)1A-2B-E-4F HenceDecisionorBranchCoverageis2.

Validation

Advantages of validation

It represents actual user interaction with the system without any

consideration of internal structures or how the system is built

Validation is the only way to show that software is actually functioning

Disadvantages of validation

No amount of testing can prove that software is not having defects

For unit testing and module testing, it needs stubs and drivers to be designed and to be used

Sometimes it may result into redundant testing as tester are not aware of internal structure

Prerequisites for validation

Training required for conducting validation. Training may include domain knowledge,
knowledge about testing and knowledge about various test tools

Standards, guidelines, tools to be used during validation

Validation Do and Check process definition

Coverage in Validation: It is also termed as 'prioritization technique where primary parts of
the system are tested fully so that the system should not have defects under normal
circumstances. And the slices are obtained on the basis of prioritization. Following are some
famous coverage of Validation:

Requirement Coverage: Requirements are defined in 'requirement specification All the

requirements are not mandatory. They can be put in different classes such a must be, 'should
be', and 'could be' and are prioritized accordingly. All high-priority requirements expressed as
'must' and lower level priority requirements expressed as should be' and could be'.
Requirement coverage definition: Priority of requirement P1(Must) P2 (Should be) P3(Could
be) Coverage offered 100% 50% 25%

Functionality Coverage Sometimes, requirements are expressed in terms of functionality

required for the application to work successfully. Functionalities also have different priorities
as per their requirement. Priority of Functionalities P1(Must) P2 (Should be) P3(Could be)
Coverage 100% 50% 25%

Feature coverage

Acceptance testing.

Acceptance Testing generally done by the user and/or customer to understand whether the
software satisfies their requirement or not. Here are some predefined methodologies,
condition and test cases will be used for acceptance testing. There are three levels of
acceptance testing:

Alpha Testing:

Alpha testing is done by the customer in development environment. The testing is done at
development side on dummy data. Alpha testing may be done working properly. There is no
direct impact of such testing on customer as testing is done off-site.

Beta Testing:

Beta testing is done at customer side. Testing is actually conducted by customer in

production/semi-production environment. Tester/Developer may be appointed to help
customer in testing the application and recording the problem, if any.

Gamma Testing:

Gamma testing is used for limited liability testing at selected places. Gamma check is
performed when the application is ready for release to the specified requirements. This is
performed directly without going through all the testing activities at home. The application is
given to few people for using it in production, and feedback is obtained from them.

Management of Verification and Validation (V & V)

Defining the processes for Verification and Validation

Software quality assurance process

Software quality control process

Software development process

Software life cycle definition

Prepare plans for execution of process

Initiate implementation plan

Monitor execution plan

Analyze problems discovered during execution

Report progress of the processes

Ensure product satisfies requirements

Levels of Validations:

Validation can be applied at different stages of software development.

Unit Testing:

Software is made up of many units. Individual unit need to be tested to find whether they
have implemented the design correctly or not. Unit testing is done by developer as they are
capable of understanding individual units under testing. Thus, unit testing needs a definition,
coding and use of stubs and drivers for testing

Integration Testing:

Integration testing involves testing of many units by combining them together to form a sub-
module or module. If designing of stubs/drivers are needed to execute integrated parts, then
in such cases integration is done by developer. And if integration is executed independently,
then integration is done by tester. Integration testing mainly refers to detail design or low-
level design. Testing involves testing of software with environment factors (such as database
and operating system), where application is supposed to work.

If an application is communicating with other application, then third-party components (such

as communication software) combining all these applications and then conducting testing is
termed as 'interface testing.

System Testing:

System testing involves end-to-end testing of a system to find the behaviour of system with
respect to expectations System testing is actually a set of processes which may include
functionality, user interface, performance and security testing. Q. V-Model for Software.
Software Test Life Cycle - Verification Validation Model

https://www.youtube.com/watch?v=WMHjJK7esVI

V-Model is a Validation Model

Validation model describes the validation activities associated with different phases of
software development.

At the requirement phase, during system testing & acceptance testing, the system tester and
users confirm that requirements have been really met or not.

Design phase is associated with interface testing which covers design specification testing as
well as structural testing Program-level designs are associated with integration testing.

At code level, unit testing is done to validate individual units Requirement Analysis:

Requirements are gathered, analysed & studied in this phase.

It is not important how the system is implemented but important is what the system is
supposed to do.

Here, the product requirements are understood from customer's perspective.

System Design:

It is a time to design the complete software, after getting product requirements.

The system design will have the understanding detailing the complete hardware and
communication setup for the product development.

The system test plan is developed based on the system design.

Architectural Design:

In this phase, the data transfer and communication between the internal modules and other
system is clearly understood

Module Design:

In this phase, the system breaks down into small modules.

Coding phase:

Best programming language is decided based on system & architectural requirements

Coding of the system module is designed.

Code goes through multiple code reviews.

Unit Testing:

Unit testing is a white box testing technique, where code is written which invokes a method
(or any other piece of code) to test whether the code fragment is giving the expected output or
not.

Integration Testing:
In this phase the integration test cases are executed.

Integration testing is a technique where tested modules are integrated and tested whether

Integrated modules are giving the expected results.

In simpler words, it validates whether the components of the application work together as
expected.

System Testing:

In this phase all the system test cases, functional test cases and non-functional test cases are
executed.

In other words, the actual and full fledge testing of the application takes place here.

Defects are logged and tracked for its closure.

Acceptance testing is done to validate that business requirements are met in the user
environment.

VV Model:

VV Model is known as Verification and Validation Model.

It is also termed as 'Quality Model’.

VV Model is also known as verification and validation activities associated with software
development during entire life cycle.

The VV-model is an SDLC model where execution of processes happens in a sequential

manner in a V-shape. It is also known as Verification and Validation model. The VV-Model
is an extension of the waterfall model and is based on the association of a testing phase for
each corresponding development stage.
Requirement Analysis

Requirements analysis is critical to the success or failure of a systems or software project.

The requirements should be documented, actionable, measurable, testable, traceable, related
to identified business needs or opportunities, and defined to a level of detail sufficient for
system design.

System Design

Software design usually involves problem solving and planning a software solution. This
includes both a low-level component and algorithm activities and a high-level, architecture
design.

Program Design

Program Design is the process that an organization uses to develop a program. It is most.
often an iterative process involving research, consultation, initial design, testing and.
redesign. A program design is the plan of action that results from that process.

Acceptance testing

Acceptance testing is a level of software testing where a system is tested for acceptability.
The purpose of this test is to evaluate the system’s compliance with the business requirements
and assess whether it is acceptable for delivery.

Interface testing

Interface testing is defined as a software testing type which verifies whether the
communication between two different software systems is done correctly. A connection that
integrates two components is called interface.

Integration testing

Integration testing is a level of software testing where individual units are combined and
tested as a group? The purpose of this level of testing is to expose faults in the interaction
between integrated units. Test drivers and test stubs are used to assist in Integration Testing

Coding, code review, unit testing

Coding methodology includes a diagrammatic notation for documenting the results of the
procedure. It also includes an objective set (ideally quantified) of criteria for determining
whether the results of the procedure are of the desired quality.

Unit testingis a level of software testing where individual units/ components of a software
are tested. The purpose is to validate that each unit of the software performs as designed. A
unit is the smallest testable part of any software. It usually has one or a few inputs and
usually a single output.
Characteristics of good requirements:

Adequate: Requirement must explain entire system from user’s side. Constraints &
Assumptions must be defined & documented with possible solutions Requirement should not
talk about any impossible thing

Clear/Unambiguous: Requirement must be clear for designer as well as for developer. For ex:
if user wants username textbox should contain at least 8 characters then he should specify
that appropriate message should be generated if user don’t enter minimum 8 characters

Measurable: Requirement can be specified within boundaries like minimum & maximum so
that it can be verified

Feasible: Requirement must be feasible Requirement should be supported by technology or

system configuration.

Non-conflicting with each other: Two requirements must not specify anything which is
conflicting with each other Generally, requirements are prioritized.

Questions:-

1. Explain Verification in detail with its Advantages.

2. Write short on Verification Work Bench

3. Write in brief Methods of Verification.

4. Explain Types of Review on the Basis of Stage/Phase.

5. Explain Entities involved in verification.

6. Write short on Review in Testing Life Cycle.

7. . Explain Coverage in Verification (Test Designing) in detail.

8. Write short note on Concerns of verification.

9. Explain Validation in detail.

10. Write short note on Validation Work Bench.

11. Explain Levels of Validations.

12. Explain Coverage in Validation. Or Explain Prioritization/Slice based testing.

13. Write Short note on Acceptance Testing.

14. Explain Management of Verification and Validation (V & V) in detail.

15. Explain Software Development Verification and Validation Activities.

16. Explain V- Model for Software in detail.

17. Write short note on Testing during proposal testing.

18. Explain Testing during Requirement Stage in detail.

19. Explain Testing during Test-Planning phase.

20. Write short note on Testing during Design Phase.

21. Write short note on Testing during Coding. OR. Explain Testing during Coding and
Aspects to be checked.

22. Explain V V Model in detail.

23.Explain Critical Roles and Responsibilities of VV Model.

Multiple Choice Questions:

Q1 Fitness of Use which is defined as the customer view of quality can also be termed
as_______________-

A Verification

B Validation

C Regression

D Confirmation

Q2 Conformance to requirement which is developer view of quality can also be termed

as___________-

A Verification

B Validation

C Regression

D Confirmation

Q3 One of the foolowing is not a component of verification workbench:

A Verification Process
B Process rework

C Standards

D Validation Process

Q4 which of the following is not considered as an official type of review in most of the
software verification

processes

A Self Review

B Peer Review

C Inspection

D Walkthrough

Q5 __________isa formal type of review

A Self Review

B Peer Review

C Inspection

D Walkthrough

Q6 This audit checks whether all the requisite processes of delivery are followed or not and
whether the work

product meets the delivery criteria or not.

A Predelivery Audit

B Phase End Audit

C Periodic Audit

D Product Audit

Q7 In this review the author of the artifact presents it to all the team members and the entire
team discusses

about the various aspects of the artifact

A Audit

B Superior Review

C Inspection
D Walkthrough

Q8 This is the one who leads the complete inspection process including planning the
inspection, running it,

taking the follow up after the meeting.

A Manager

B Moderator

C Author

D Reviewer

Q9 In a typical inspection process which phase follows kickoff preparation

A Individual prepartion

B Inspection Meeting

C Planning for inspection

D Followup

Q10 _________decides the execution of the inspection,defines the schedules,allocates time

and defines

objectives of inspection.

A Manager

B Moderator

C Author

D Reviewer

Q11 Name the step that is precedor to the step 'follow up'

A Decision on comment

B Inspection Meeting

C Planning for inspection

D Individual prepartion

Q12 name the audit that checks whether the phase defined in the SDLC model achieves it
outcome or not

A Predelivery Audit
B Phase End Audit

C Periodic Audit

D Product Audit

Q13 This is the person who prepares the artifact for inspection

A Scribe

B Moderator

C Author

D Reviewer

Q14 One of the following is not a a characteristic of nice domain

A orthogonal

B complete

C linear

D inconsistent

Q15 _____________testing invoves testing of software with software environmental factors

like database ,

operating system , where the application is supposed to work.

A Interface testing

B Integration testing

C System Testing

D Unit Testing

Q16 Name the testing that involves testing of many units by combing them together to form a
module or sub

module.

A Interface testing

B Integration testing

C System Testing

D Unit Testing
Q17 _______matrix starts with the requirements as stated in the requirement specification
and goes forward

upto test results.

A Traceability

B Testing

C Specification

D Execution

Q18 This si a testing program based on specification like requirement specification, design
specification, user

manual etc.

A Feature Coverage

B Specification Based Testing

C Functionality Coverage

D Integration Testing

Q19 One of the folowing is not included in levels of validation.

A Review

B Unit testing

C Integration Testing

D Acceptance testing

Q20 ____________testing involves stubs and drivers in the process of testing

A Review

B Unit testing

C Integration Testing

D Acceptance testing

Q21 This testing is termed as dynamic testing.

A valication testing

B verification testing

C requirement testing
D stress testing

Q22 Name the technique used to find heavily used path from other path present the
application where the

control goes rarely.

A Path Sensitizing

B Path Profiling

C Path Testing

D Path reading

Q23 In this stratergy we find a defect or a bug that go through the paths

A Path Sensitizing

B Path Profiling

C Path Testing

D Path reading

Q24 the testing done to find whher the application is alive or not and also finds whether the
user can work with

it or not.

A Interface testing

B Integration testing

C System Testing

D Smoke Testing