1. Definition
    A description of the meaning of a word
  2. Risk
    A factor that could result in future negative consequenses; usually expressed as impact and likelihood.
  3. Error (Mistake)
    A human action that produces an incorrect result
  4. Defect (bug,fault)
    A flaw in a component or system that can cause the component or system to fail to perform it's desired function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.
  5. Failure
    Deviation of the component or system from it's expected delivery, service or result.
  6. Quality
    The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations.
  7. Exhaustive testing (complete testing)
    A test approach in which the test suite comprises all input values and preconditions
  8. Testing
    The process consisting of all life cycle activites both static and dynamic, concerned with planning, preperation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.
  9. Requirement
    A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
  10. Review
    An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough.
  11. Test Case
    A set of input values, execution preconditions expected results and execution preconditions, developed for a particular objective or test condtion, such as to exercise a particular program path or to verify compliance with a specific requirement.
  12. Test Objective
    A reason or purpose for designing and executing a test.
  13. Debugging
    The process of finding, analyzing and removing causes of failure in software.
  14. Test Plan
    A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others, test terms, features to be tested, the testing tasks, who will do each task, degree of tester independence, the test enviorment, the test design techniques and entry and exit criteria to be used and the rationale for their choice, any risks requiring contingency planning. It is a record of the test planning process.
  15. Test Policy
    A high-level document describing the principles, approach and the major objectives of the organization regarding testing.
  16. Test Strategy
    A high-level description of test levels to be performed and the testing within those levels for an organization or program (one or more projects).
  17. Test Approach
    The implementation of the test strategy for a specific project. It typically includes the decisions made based on the (test) projects 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.
  18. Coverage (test coverage)
    The degree expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
  19. Exit Criteria
    The set of generic and specific conditions, agreed upon with stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used by testing to report against and to plan when to stop testing.
  20. Test Control
    A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned.
  21. Test Monitoring
    A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actual status to which was planned.
  22. Test basis
    All documents from which the requirements if a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called the frozen test basis.
  23. Test condition
    An item or event of a component or system that could be verified
Card Set
Foundations of Software Testing