KC 7.3.1 - Validation Methods

a. Test Concepts

Ø Static Black Box Testing

• Testing the specification

Ø Dynamic Black Box Testing

• Behavioral Testing

Testing a running program without any knowledge of how the software behaves.

• Test to pass

Test-to-pass approach is where test cases are developed to clarify if the software produced fundamentally works in ordinary circumstances.

Ø Dynamic Black Box Testing

• Data Testing

1. Data testing is performing tests to check the information a user inputs and the results that are received.

• Boundary Conditions

Test data by inputting the boundary values.

Ø Dynamic Black Box Testing

• Invalid data

1. Provide invalid data to the software to check if the software still works.
2. Example of a Test-to-fail condition.

• State Transitions: This is testing a program’s logic flow through its various states.
• Regression: The process of re-running test cases to ensure that changes have not propagated unintended side effects.

Ø Static White Box Testing

• Code review and analysis

• Formal Reviews

Detailed rigorous inspection of code to identify problems and decide to follow rules.

• Peer Reviews

An informal meeting between the programmer and other programmers, getting together to discuss the code.

Ø Static White Box Testing

• Walkthroughs

A formal presentation given by the programmer to a group of other programmers & testers, explaining code, its purpose and reason. Key points covered would be to summarize the inputs and how bugs would be addressed.

• Inspection & Coding Standards

The Code would be reviewed by a number of other programmers from a different perspective, such as a user, tester, or a product support person, thus help identify different bugs.Guidelines are adopted for coding standards.

Ø Static White Box Testing

• Generic Code review checklist

1. Data Reference Errors.

To identify bugs caused by a variable, constant, array, string or record.

2. Data Declaration Errors

To identify improper declaration, usage of variables and constants.

3. Computation Errors.

To identify errors in usage of less than, equal, not equal, true, false comparators.

4. Control Flow Errors

To identify errors in usage of loops.

5. I/O Errors: To identify errors due to improper usage of I/O statements.

Ø Dynamic White Box Testing

• Structural Testing

This testing is using information you gain from seeing what the code does and how it works to determine what to test, what not to test, and how to approach the testing.

• Unit Testing

i) Data Coverage

Divide the code into data and its states.

ii) Data Flow

Track a piece of data completely through the software.

iii) Code coverage

Program and line, Branch , Condition coverage

Ø Other Types of Testing

1. User Interface Testing

Test the user interface for operability, ease of use.

2. Performance

Testing the performance of the computations.

3. Load

Testing the performance of the system under varying load conditions.

4. Stress

Testing the performance and accuracy of system under resource crunch or any other kind of stress.

5. Volume: Testing with high volume of data.

6. Configuration

Testing the system under various hardware/software configurations.

7. Compatibility

Testing the system for ability to interact with other systems.

8. Installation

Testing the installation of system under one or more configurations.

9. Documentation

Testing the system for documentation clarity.

10. Random- Monkey & Gorillas

Testing for errors with no background on system.

B.2.a.iv. Independent Verification and Validation

Independent Verification and Validation (IV&V) is a process whereby the products of the
software development life cycle phases are independently reviewed, verified, and validated by
an organization that is neither the developer nor the acquirer of the software.  The IV&V agent
should have no stake in the success or failure of the software.  The IV&V agent's only interest
should be to make sure that the software is thoroughly tested against its complete set of
requirements.

The IV&V activities duplicate the V&V activities step-by-step during the life cycle, with the
exception that the IV&V agent does no informal testing.  If there is an IV&V agent, the formal
acceptance testing may be done only once, by the IV&V agent.  In this case, the developer will
do a formal demonstration that the software is ready for formal acceptance.