Thursday, October 20, 2005

IEEE Standard 829 Test Summary Report - Google Search

Acceptance criteria: The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity.

Acceptance testing: (1) Formal testing conducted to determine whether a system satisfies its acceptance criteria and enables the customer to determine whether to accept the system. (2) Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component.

Computer Software Configuration Item (CSCI): An aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process. Contrast with: Hardware configuration item See also: Configuration item

Configuration item (CI): An aggregation of hardware, software, or both, that is designated for configuration management and treated as a single entity in the configuration management process. See also: Hardware configuration item; Computer software configuration item.

Development testing: Formal or informal testing conducted during the development of a system or component, usually in the development environment by the developer.

Functional testing: (1) Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. Contrast with: Structural testing. (2) Testing conducted to evaluate the compliance of a system or component with specified functional requirements. See also: Performance testing.

Hardware Configuration Item: Hardware items that include disks, disk drives, display screens, keyboards, printers, boards, and chips.

Independent Verification and Validation (IV&V): Verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization.

Installation and checkout phase: The period of time in the software life cycle during which a software product is integrated into its operational environment and tested in this environment to ensure that it performs as required.

Integration testing: Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. See also: System testing; Unit testing.

Load testing: Testing that studies the behavior of the program when it is working at its limits. See also: Stress Testing.

Operational testing: Testing conducted to evaluate a system or component in its operational environment.

Path testing (coverage): Testing that is designed to execute all or selected paths through a computer program.

Pass/Fail criteria: Decision rules used to determine whether a software item or software feature passes or fails a test.

Performance testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements. See also: Functional testing.

Quality Assurance (QA): (1) The process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. (2) The organizational unit that is assigned responsibility for quality assurance. [A Guide to the Project Management Body of Knowledge (PMBOK Guide), 2000 Edition]

Quality Control (QC): (1) The process of monitoring specific project results to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance. (2) The organizational unit that is assigned responsibility for quality control. [A Guide to the Project Management Body of Knowledge (PMBOK Guide), 2000 Edition]

Quality Management (QM): The processes required to ensure that the project would satisfy the needs for which it was undertaken.

Regression testing: Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements.

Scenario: (1) A description of a series of events that could be expected to occur simultaneously or sequentially. (2) An account or synopsis of a projected course of events or actions. [IEEE Std 1362-1998, Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document]

Software item: Source code, object code, job control code, control data, or a collection of items.

Stress testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements. See also: Load testing.

Structural testing: Testing that takes into account the internal mechanism of a system or component. Types include branch testing, path testing, statement testing. Contrast with: Functional testing.

System testing: Testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. See also: Integration testing; Unit testing.

Test: An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component.

Test case specification: A document specifying inputs, predicted results, and a set of execution conditions for a test item.

Test design specification: Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.

Test Incident Report (TIR): A document reporting on any event that occurs during the testing process that requires investigation.

Test item: A software item that is an object of testing.

Test log: A chronological record of relevant details about the execution tests.

Test phase: The period of time in the life cycle during which components of a system are integrated, and the product is evaluated to determine whether or not requirements have been satisfied.

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

Test procedure: (1) Detailed instructions for the set-up, execution, and evaluation of results for a given test case. (2) A document containing a set of associated instructions as in (1). (3) Documentation specifying a sequence of actions for the execution of a test.

Test Readiness Review (TRR): A review conducted to evaluate preliminary test results for one or more configuration items and verify that the test procedures for each configuration item are complete, comply with test plans and descriptions, and satisfy test requirements. Verify that a project is prepared to proceed to formal testing of the configuration item.

Test summary report: A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items.

Testability: (1) The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met. (2) The degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria have been met.

Testing: (1) The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. (2)The process of analyzing a software item to detect the differences between existing and required conditions (i.e., bugs) and to evaluate the features of the software items. See also: Acceptance testing; Development testing; Integration testing; Operational testing; Performance testing; Regression testing; System testing; Unit testing.

Unit Testing: The testing of individual hardware or software units or groups of related units (i.e., component, modules). See also: Integration testing; System testing.
Post a Comment