ISTQB Glossary C-d

47 Questions

ISTQB Quizzes & Trivia


Questions and Answers
  • 1. 
    The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions.
  • 2. 
    A framework that describes the key elements of an effective product development and maintenance process. It covers best-practices for planning, engineering and managing product development and maintenance.
  • 3. 
    A minimal software item that can be tested in isolation.
  • 4. 
    Testing performed to expose defects in the interfaces and interaction between integrated components.
  • 5. 
    The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify.
  • 6. 
    A software tool that translates programs expressed in a high-order language into their machine language equivalents.
  • 7. 
    A software product that is developed for the general market, i.e. for a large number of customers, and that is delivered to many customers in identical format.
  • 8. 
    An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g., statement coverage, decision coverage or condition coverage.
  • 9. 
    Computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler or other translator.
  • 10. 
    An experience-based test design technique whereby the experienced tester uses a high-level list of items to be noted, checked, or remembered, or a set of rules or criteria against which a product has to be verified.
  • 11. 
    The process of confirming that a component, system or person complies with its specified requirements, e.g., by passing an exam.
  • 12. 
    A description of a component's function in terms of its output values for specified input values under specified conditions, and required non-functional behavior (e.g., resource-utilization).
  • 13. 
    The testing of individual software components.
  • 14. 
    A logical expression that can be evaluated as True or False, e.g., A>B.
  • 15. 
    The percentage of condition outcomes that have been exercised by a test suite. 100% condition coverage requires each single condition in every decision statement to be tested as True and False.
  • 16. 
    The composition of a component or system as defined by the number, nature, and interconnections of its constituent parts.
  • 17. 
    An element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification.
  • 18. 
    An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process.
  • 19. 
    A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system.
  • 20. 
    The set from which valid input and/or output values can be selected.
  • 21. 
    Formal or informal testing conducted during the implementation of a component or system, usually in the development environment by developers.
  • 22. 
    Any (work) product that must be delivered to someone other than the (work) product's author.
  • 23. 
    An element in a taxonomy of defects. Defect taxonomies can be identified with respect to a variety of considerations, including, but not limited to: Phase or development activity in which the defect is created, e.g., a specification error or a coding error, Characterization of defects, e.g., an "off-by-one" defect, Incorrectness, e.g., an incorrect relational operator, a programming language syntax error, or an invalid assumption, Performance issues, e.g., excessive execution time, insufficient availability.
  • 24. 
    A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of defects and provide reporting facilities.
  • 25. 
    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-of-code, number of classes or function points).
  • 26. 
    A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g., an incorrect statement or data definition. If encountered during execution, may cause a failure of the component or system.
  • 27. 
    A white-box test design technique in which test cases are designed to execute decision outcomes.
  • 28. 
    A black-box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table.
  • 29. 
    A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects), which can be used to design test cases.
  • 30. 
    The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage.
  • 31. 
    The result of a decision (which therefore determines the branches to be taken).
  • 32. 
    A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.
  • 33. 
    A tool used by programmers to reproduce failures, investigate the state of programs and find the corresponding defect. They enable programmers to execute programs step by step, to halt a program at any program statement and to set and examine program variables.
  • 34. 
    The process of finding, analyzing and removing the causes of failures in software.
  • 35. 
    A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. It is often used to support the application of test execution tools such as capture/playback tools.
  • 36. 
    An attribute of data that indicates correctness with respect to some pre-defined criteria, e.g., business expectations, requirements on data integrity, data consistency.
  • 37. 
    An abstract representation of the sequence and possible changes of the state of data objects, where the state of an object is any of creation, usage, or destruction.
  • 38. 
    A tool that provides objective measures of what structural elements, e.g., statements, branches have been exercised by a test suite.
  • 39. 
    The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
  • 40. 
    Testing of software used to convert data from existing systems for use in replacement systems.
  • 41. 
    An approach to structure-based testing in which test cases are designed to execute specific sequences of events. Various techniques exist for this, e.g., decision testing, condition testing, and path testing, that each have their specific approach and level of control flow coverage.
  • 42. 
    A sequence of events (paths) in the execution through a component or system.
  • 43. 
    Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
  • 44. 
    A tool that provides support for the identification and control of configuration items, their status over changes and versions, and the release of baselines consisting of configuration items.
  • 45. 
    A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.
  • 46. 
    Testing that involves the execution of the software of a component or system.
  • 47. 
    A tool that provides run-time information on the state of the software code. These tools are most commonly used to identify unassigned pointers, check pointer arithmetic and to monitor the allocation, use and de-allocation of memory and to flag memory leaks.