IEEE Definitions in Software Testing

IEEE Definitions

1.Black-box testing , or 2.Functional testing: 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.



3.White-box testing , or 4.Stnsctural testing: Testing that takes into account the internal mechanism of a system or component Types include branch testing, path testing, statement testing. (Also Glass box or white box testing)



5.Unit testing: Testing of individual hardware or software units or groups of related units.

6.Integretion testing: Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them

7.system testing: Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements

8.Acceptance testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

9.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.

10.Anomaly: Anything observed in the documentation or operation of software that deviates from expectations based on previously verified software products or reference documents.

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

12.Formal testing: Testing conducted in accordance with test plans and procedures that have been reviewed and approved by a customer, user, or designated level of management.

13.1nformal testing: Testing conducted in accordance with test plans and procedures that have not been reviewed and approved by a customer, user, or designated level of management.

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

15.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

16.Testing: 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

17.Test item: A software item, which is an object of testing

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

19.Test log: A chronological record of all relevant details about the execution of a test

20.Test case: It has two definitions:
1.A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
2.Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.

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

22.Test procedure: It has two definitions
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.

23.Test report: A document that describes the conduct and results of the testing carried out for a system or component

24.Test Scenario: A test that verifies one specific instance of a single product feature.
For example, when testing a word-processing application, one scenario would be to verify that the Paste command correctly pastes text a the beginning of a line