Software Verification and Validation: Techniques and Testing

Static and Dynamic Verification

Static verification involves inspections of software. It is related to the analysis of static representations of the system to discover problems. It can be supplemented by document-based tools and code analysis. (The application does not need to be running).

Dynamic verification involves testing software. It is related to exercising and observing the behavior of the product. The system is run with test data, and its operational performance is observed. (The application is running).

Test Program

A test program can reveal the presence of defects but not the absence of them. It is the main validation technique for non-functional requirements since the software is run to see how it behaves. It should be used in conjunction with static verification to provide full coverage of Verification and Validation (V & V).

Test Types

• Validation Test: Aims to show that the software meets your requirements. A successful test shows that a requirement was properly implemented.
• Defect Test: Tests designed to discover defects in the system. A successful defect test reveals the presence of defects in a system.

Testing and debugging of defects are distinct processes. Find error -> Project repair -> Retest program. Verification and validation are related to establishing the existence of defects in a program.

Inspection Process

Planning -> Features -> General -> Single Meeting Inspection -> Rework -> Monitoring

Inspection Procedure

1. System overview presented to the inspection team.
2. Code and associated documents are distributed prior to the inspection team.
3. Inspection occurs, and the errors discovered are noted.
4. Modifications are made to repair the errors discovered.
5. A new inspection may or may not be necessary.

Inspection Checklists

A checklist of common errors should be used to direct inspection. Checklists of errors are dependent on the programming language and reflect the characteristic errors most likely to emerge in the language. In general, type checking is a weak point in most checklists.

Examples: Beginner, names of constants, termination of loops, vector limits, etc.

System Test

System testing is based on a system specification that involves the integration of two or more components to create a system or subsystem. It may involve testing an increment to be delivered to the customer. It has two phases:

• Integration Test: The test team has access to the source code, and the system is tested as the components are integrated.
• Release Test: The test team tests the complete system to be delivered as a black box. The primary goal is to increase the supplier's confidence that the system meets your requirements.

Defect Test

The goal of defect testing is to find defects in programs. A successful defect test makes a program behave in an anomalous way. Tests show the presence, not the absence, of defects.

Performance Test

Part of the test releases may involve testing the emergent properties of a system, such as performance and reliability. Performance tests generally involve planning a series of tests where the load is steadily increased until the system performance is unacceptable.

Stress Test

Stress tests exercise the system beyond its design load. The stress of a system often causes the appearance of defects. Stress testing tests the behavior of failure because the systems should not fail catastrophically. The stress test checks for unacceptable loss of service or data. The stress test is particularly relevant for distributed systems that can exhibit severe degradation when a network becomes overloaded.

White-Box Test (Structural)

White-box testing is one that has access to the source code. It is used in units of programs and subroutines (Test Drive, Test basic path, where each path is executed at least once). The goal is to exercise all program statements (not all combinations of paths).

Black-Box Testing (Functional)

Black-box testing is one where there is no access to the source code, hence the following test cases (inputs and outputs corresponding specified). Prioritize testing the functionality of the application. (System Test).

Test Based on Requirements

It is an approach where each requirement is considered, and a set of tests is made for it. It is a validation test to show that the system has properly implemented its requirements.

Regression Testing

Regression testing is intended to provide confidence that the changed portions of modified software behave as expected and that the parties that have not changed the software were not affected by the changes.