Glossary of Terms
The process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not. It involves executing a system to identify gaps, errors, or missing requirements. (As per ANSI/IEEE 1059: A process of analyzing a software item to detect differences between existing and required conditions and to evaluate features).
Differences between existing and required conditions in a software item, identified during testing.
Testing conducted by developers on individual units or components of source code to isolate each part of the program and show that individual parts are correct in terms of requirements and functionality.
The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. It addresses the concern: "Are you building it right?". Involves static activities like reviews and inspections, typically done by developers.
The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. It addresses the concern: "Are you building the right thing?". Involves dynamic activities like executing the software, typically done by testers.
Testing of a software development artifact, e.g., requirements, design or code, without execution of these artifacts. (Implied by Verification activities like reviews, walkthroughs, inspections).
Testing that involves the execution of the software of a component or system. (Implied by Validation activities).
A validation method suitable for date and numeric data types that checks whether data is within given values. Example: a student's score should be >0 but <100.
A validation method suitable for text and date data types that checks if the input data contains the required number of characters. Example: a telephone number should be 11 digits.
A validation method that checks that the input data does not contain invalid characters based on the expected data type (e.g., Integer, String, Boolean). Example: username should not contain numbers.
A validation method suitable for date and text data types that checks if data is in a specific format. Example: Student ID starts with 3 letters followed by 4 digits (SEM2021).
A validation method suitable for numeric data types, similar to a range check but only one of the boundaries is checked. Example: student's score must be >0.
A validation method, often for primary keys, that checks if data is actually present and has not been missed out. Example: Student's ID should be present.
A validation method suitable for a list of values, where an entered data item is compared to a list of valid entries (often stored in a database table). Example: Country field must be one of the predefined countries.
A validation method, often used for barcodes or ISBNs, that looks at an extra digit calculated from the other digits of a number and then put on the end of the number to verify accuracy.
A verification method where data is entered twice, sometimes by different operators, and the computer system compares both entries for discrepancies.
A verification method involving a manual check by the user entering the data, who confirms its correctness on the screen, often against a paper document or from their own knowledge.
A software testing method in which the internal structure/design/implementation of the item being tested is NOT known to the tester. Testing is based on inputs and outputs.
A software testing method in which the internal structure/design/implementation of the item being tested IS known to the tester. Also called glass-box or open-box testing.
A software testing method which is a combination of Black Box and White Box testing. The tester has limited knowledge of the internal workings, possibly access to design documents or databases.
A type of black-box testing based on the specifications of the software. The application is tested by providing input and examining the output to ensure it conforms to the intended functionality and specified requirements.
The phase in software testing in which individual software modules are combined and tested as a group. It can be done bottom-up (starting with unit-tested modules) or top-down (starting with high-level modules).
Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements and quality standards. Tests the system as a whole.
Selective re-testing 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. Ensures bug fixes don't introduce new faults.
The first stage of testing, typically performed in-house by developer and QA teams. It often combines unit, integration, and system testing. Aspects tested include spelling, broken links, and performance on low-spec machines.
Testing performed after alpha testing, where a sample of the intended audience tests the application in a real-world environment. Also known as pre-release testing.
Testing software from requirements which are non-functional in nature but important, such as performance, security, usability, portability, etc.