Verification and Validation 101 Flashcards
It is a technical discipline of systems engineering
Software verification and validation
It is a static process of verifying documents, design, and code.
Verification
It is a dynamic process of validating/testing the actual product
Validation
It does not involve executing code.
Verification
It involves executing the code.
Validation
It is human based checking of documents/files
Verification
It is the computer-based execution of program
Validation
Target is requirements specification, application architecture, high level and detailed design, and database design.
Verification
Target is the actual product— a unit, a module, a set of integrated modules, and the final product
Validation
It uses methods like inspections, walk throughs, desk-checking, etc.
Verification
It uses methods like black-box, gray-box, and white-box testing.
Validation
It generally, comes first before validation
Verification
It generally follows verification
Validation
It answers the question —- Are we building the product right?
Verification
It answers the question —- Are we building the right product?
Validation
It can catch errors that validation cannot catch
Verification
It can catch errors that verification cannot catch
Validation
The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled.
Quality Assurance
The observation techniques and activities used to fulfill requirements for quality.
Quality Control
It is process related
Quality Assurance
It is product related
Quality Control
It focuses on the process used to develop a product
Quality Assurance
It focuses on testing a product developed or a product under development
Quality Control
It involves the quality of the processes
Quality Assurance
It involves the quality of the products
Quality Control
It is a preventive control
Quality Assurance
It is a detective control
Quality Control
Allegiance is to development
Quality Assurance
Allegiance is not to Development
Quality Control
A V&V Limitation that no general-purpose testing or analysis can prove program correctness
Theoretical Foundations
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
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
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
A V&V Technique that ensures each software requirement aligns with system requirements and no unnecessary requirements are added.
Traceability Analysis
A V&V Technique that verifies consistency of derived requirements with original objectives, physical laws, and technologies
Traceability Analysis
A V&V Technique that examines interface requirements between software,, hardware, users, and external software, ensuring they meet specification standards.
Interface Analysis
A V&V Technique that assigns criticality levels to requirements and updates them as changes occur.
Criticality Analysis
A V&V Technique that identifies high-risk areas and ensures critical functions (e.g., safety, security) are properly addressed.
Criticality Analysis
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
