Verification and Validation 101 Flashcards

(39 cards)

1
Q

It is a technical discipline of systems engineering

A

Software verification and validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

It is a static process of verifying documents, design, and code.

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

It is a dynamic process of validating/testing the actual product

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

It does not involve executing code.

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

It involves executing the code.

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

It is human based checking of documents/files

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

It is the computer-based execution of program

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Target is requirements specification, application architecture, high level and detailed design, and database design.

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Target is the actual product— a unit, a module, a set of integrated modules, and the final product

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

It uses methods like inspections, walk throughs, desk-checking, etc.

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

It uses methods like black-box, gray-box, and white-box testing.

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

It generally, comes first before validation

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

It generally follows verification

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

It answers the question —- Are we building the product right?

A

Verification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

It answers the question —- Are we building the right product?

A

Validation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

It can catch errors that validation cannot catch

17
Q

It can catch errors that verification cannot catch

18
Q

The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.

A

Quality Assurance

19
Q

The observation techniques and activities used to fulfill requirements for quality.

A

Quality Control

20
Q

It is process related

A

Quality Assurance

21
Q

It is product related

A

Quality Control

22
Q

It focuses on the process used to develop a product

A

Quality Assurance

23
Q

It focuses on testing a product developed or a product under development

A

Quality Control

24
Q

It involves the quality of the processes

A

Quality Assurance

25
It involves the quality of the products
Quality Control
26
It is a preventive control
Quality Assurance
27
It is a detective control
Quality Control
28
Allegiance is to development
Quality Assurance
29
Allegiance is not to Development
Quality Control
30
A V&V Limitation that no general-purpose testing or analysis can prove program correctness
Theoretical Foundations
31
A V&V Limitation that means the sheer number of possible inputs makes exhaustive testing impossible, requiring selective test cases and a testing oracle.
Impracticality of Testing All Data
32
A V&V Limitation that means the sheer number of execution paths grows exponentially, making complete path testing unfeasible. Path feasibility cannot always be determined algorithmically
Impracticality of Testing All Paths
33
A V&V Limitation that means correctness can only be demonstrated as equivalence between different representations of a program, not as absolute correctness. Formal specifications must be verified to truly reflect user expectations.
No Absolute Proof of Correctness
34
A V&V Technique that ensures each software requirement aligns with system requirements and no unnecessary requirements are added.
Traceability Analysis
35
A V&V Technique that verifies consistency of derived requirements with original objectives, physical laws, and technologies
Traceability Analysis
36
A V&V Technique that examines interface requirements between software,, hardware, users, and external software, ensuring they meet specification standards.
Interface Analysis
37
A V&V Technique that assigns criticality levels to requirements and updates them as changes occur.
Criticality Analysis
38
A V&V Technique that identifies high-risk areas and ensures critical functions (e.g., safety, security) are properly addressed.
Criticality Analysis
39
A V&V Technique that are conducted during requirements definition to identify and assess risks in system requirements, refining them into details software requirements.
Hazard and Risk Analysis