Software Testing Glossary

• Validation: The word validation has several related meanings:* In general, validation is the process of checking if something satisfies a certain criterion. Examples would be: checking if a statement is true, if an appliance works as intended, if a computer system is secure, or if computer data is compliant with an open standard. This should not be confused with verification.
• Verification: In the context of hardware and software systems,formal verification is the act ofproving or disproving the correctness of a systemwith respect to a certain formal specification or property,using formal methods.
• 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 Data: The definition (usually formal) of a collection of test input values that are consumed during the execution of a test, and expected results referenced for comparative purposes
• Test Case: The specification (usually formal) of a set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a Target Test Item.
• Test Cycle: A formal test cycle consists of all tests performed. In software development, it can consist of, for example, the following tests: unit/component testing, integration testing, system testing, user acceptance testing and the code inspection.
• Test Approach: The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project's goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed
• Software Quality Assurance: Software testing is a process used to identify the correctness, completeness and quality of developed computer software. Actually, testing can never establish the correctness of computer software, as this can only be done by formal verification (and only when there is no mistake in the formal verification process). It can only find defects, not prove that there are none.
• Bug: Bugs arise from mistakes and errors, made by people, in either a program's source code or its design that prevents it from working correctly or produces an incorrect result
• Black Box Testing / Functional Testing: Black box testing, concrete box or functional testing is used to check that the outputs of a program, given certain inputs, conform to the functional specification of the program. It performs testing based on previously understood requirements (or understood functionality), without knowledge of how the code executes.
• Defect: An anomaly, or flaw, in a delivered work product. Examples include such things as omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved.
• Defect density: The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g. lines-ofcode, number of classes or function points)
• Equivalence Partitioning: A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.
• Failure: The inability of a system or component to perform its required functions within specified performance requirements. A failure is characterized by the observable symptoms of one or more defects that have a root cause in one or more faults.
• Fault: An accidental condition that causes the failure of a component in the implementation model to perform its required behavior. A fault is the root cause of one or more defects identified by observing one or more failures.
• Grey Box Testing: The typical grey box tester is permitted to set up or manipulate the testing environment, like seeding a database, and can view the state of the product after their actions, like performing a SQL query on the database to be certain of the values of columns. It is used almost exclusively of client-server testers or others who use a database as a repository of information,or who has to manipulate XML files (DTD or an actual XML file) or configuration files directly, or who know the internal workings or algorithm of the software under test and can write tests specifically for the anticipated results.

I will be back with some more Testing Glossaries which will be good for all testing guys.