Testing Vocabulary-1.2

Recovery Test
Evaluates the contingency features built into the application for handling
interruptions and for returning to specific points in the application processing cycle, including checkpoints, backups, restores, and restarts. This test also assures that disaster recovery is possible.

Regression Testing
Testing of a previously verified program or application following program
modification for extension or correction to ensure no new defects have been introduced.

Risk Matrix
Shows the controls within application systems used to reduce the identified risk, and in what segment of the application those risks exist. One dimension of the matrix is the risk, the second dimension is the segment of the application system, and within the matrix at the intersections are the controls. For example, if a risk is “incorrect input” and the systems segment is “data entry,” then the intersection within the matrix would show the controls designed to reduce the risk of incorrect input during the data entry segment of the application system.

Scatter Plot Diagram
A graph designed to show whether there is a relationship between two
changing variables.

Standards
The measure used to evaluate products and identify nonconformance. The basis upon which adherence to policies is measured.

Statement of Requirements
The exhaustive list of requirements that define a product.

Statement Testing
A test method that executes each statement in a program at least once during program testing.

Static Analysis
Analysis of a program that is performed without executing the program. It
may be applied to the requirements, design, or code.

Stress Testing
This test subjects a system, or components of a system, to varying
environmental conditions that defy normal expectations. For example, high transaction volume, large database size or restart/recovery circumstances. The intention of stress testing is to identify constraints and to ensure that there are no performance problems.

Structural Testing
A testing method in which the test data is derived solely from the program structure.

Stub
Special code segments that when invoked by a code segment under testing, simulate the behavior of designed and specified modules not yet constructed.

System Test
During this event, the entire system is tested to verify that all functional,
information, structural and quality requirements have been met.

Test Case
Test cases document the input, expected results, and
execution conditions of a given test item.

Test Plan
A document describing the intended scope, approach, resources, and schedule of testing activities. It identifies test items, the features to be tested, the testing tasks, the personnel performing each task, and any risks requiring contingency planning.

Test Scripts
A tool that specifies an order of actions that should be performed during a test session. The script also contains expected results. Test scripts may be manually prepared using paper forms, or may be automated using
capture/playback tools or other kinds of automated scripting tools.

Test Suite Manager
A tool that allows testers to organize test scripts by function or other grouping.

Unit Test
Testing individual programs, modules, or components to demonstrate that the work package executes per specification, and validate the design and technical quality of the application. The focus is on ensuring that the detailed logic within the component is accurate and reliable according to pre-determined specifications. Testing stubs or drivers may be used to simulate behavior of interfacing modules.

Usability Test
The purpose of this event is to review the application user interface and other human factors of the application with the people who will be using the application. This is to ensure that the design (layout and sequence, etc.) enables the business functions to be executed as easily and intuitively as possible. This review includes assuring that the user interface adheres to documented User Interface standards, and should be conducted early in the design stage of development. Ideally, an application prototype is used to walk the client group through various business scenarios, although paper copies of screens, windows, menus, and reports can be used.

User Acceptance Test
User Acceptance Testing (UAT) is conducted to ensure that the system meets the needs of the organization and the end user/customer. It validates that the system will work as intended by the user in the real world, and is based on real world business scenarios, not system requirements. Essentially, this test validates that the right system was built.

Validation
Determination of the correctness of the final program or software produced from a development project with respect to the user needs and requirements.

Verification
1. The process of determining whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase.
2. The act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether items, processes, services, or documents conform to specified requirements.

Walkthroughs
During a walkthrough, the producer of a product “walks through” or
paraphrases the products content, while a team of other individuals follow along. The team’s job is to ask questions and raise issues about the product that may lead to defect identification.

White-box Testing
A testing technique that assumes that the path of the logic in a program unit or component is known. White-box testing usually consists of testing paths, branch by branch, to produce predictable results. This technique is usually used during tests executed by the development team, such as Unit or Component testing.