ISTQB Certification Foundation Level Terms 6

Software Fault Tree Analysis (SFTA): See Fault Tree Analysis (FTA).

software life cycle: The period of time that begins when a software product is conceived and
ends when the software is no longer available for use. The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note these phases may overlap or be performed iteratively.

software quality: The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs.

Software Usability Measurement Inventory (SUMI): A questionnaire based usability test
technique to evaluate the usability, e.g. user-satisfaction, of a component or system.

specification: A document that specifies, ideally in a complete, precise and verifiable manner,
the requirements, design, behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have been satisfied.

specified input: An input for which the specification predicts a result.

stability: The capability of the software product to avoid unexpected effects from modifications
in the software.

staged representation: A model structure wherein attaining the goals of a set of process areas
establishes a maturity level; each level builds a foundation for subsequent levels.

state diagram: A diagram that depicts the states that a component or system can assume, and
shows the events or circumstances that cause and/or result from a change from one state to

state table: A grid showing the resulting transitions for each state combined with each possible event, showing both valid and invalid transitions.

state transition: A transition between two states of a component or system.

state transition testing: A black box test design technique in which test cases are designed to
execute valid and invalid state transitions.

statement: An entity in a programming language, which is typically the smallest indivisible unit of execution.

statement coverage: The percentage of executable statements that have been exercised by a test suite.

statement testing: A white box test design technique in which test cases are designed to execute statements.

static analysis: Analysis of software artifacts, e.g. requirements or code, carried out without execution of these software artifacts.

static analyzer: A tool that carries out static analysis.

static code analysis: Analysis of source code carried out without execution of that software.

static code analyzer: A tool that carries out static code analysis. The tool checks source code, for certain properties such as conformance to coding standards, quality metrics or data flow anomalies.

static testing: Testing of a component or system at specification or implementation level without execution of that software, e.g. reviews or static code analysis.

statistical testing: A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases.

status accounting: An element of configuration management, consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed  changes to the   configuration, and the implementation status of the approved changes.

stress testing: A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified work loads, or with reduced availability of resources such as access to memory or servers.

stress testing tool: A tool that supports stress testing.
structural coverage: Coverage measures based on the internal structure of a component or system.

stub: A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component.

subpath: A sequence of executable statements within a component.

suitability: The capability of the software product to provide an appropriate set of functions for specified tasks and user objectives.

suspension criteria: The criteria used to (temporarily) stop all or a portion of the testing activities on the test items.

syntax testing: A black box test design technique in which test cases are designed based upon the definition of the input domain and/or output domain.

system: A collection of components organized to accomplish a specific function or set of functions.

system of systems: Multiple heterogeneous, distributed systems that are embedded in networks at multiple levels and in multiple domains interconnected addressing large-scale
inter-disciplinary common problems and purposes.

system integration testing: Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet).

system testing: The process of testing an integrated system to verify that it meets specified requirements.

technical review: A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken.

test: A set of one or more test cases.

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.

test automation: The use of software to perform or support test activities, e.g. test management, test design, test execution and results checking.

test basis: All documents from which the requirements of 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 a frozen test basis.

test case: A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.

test case specification: A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item.

test charter: A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing.

test closure: During the test closure phase of a test process data is collected from completed activities to consolidate experience, testware, facts and numbers. The test closure phase consists of finalizing and archiving the testware and evaluating the test process, including preparation of a test evaluation report.

test comparator: A test tool to perform automated test comparison of actual results with expected results.

test comparison: The process of identifying differences between the actual results produced
by the component or system under test and the expected results for a test. Test comparison can be performed during test execution (dynamic comparison) or after test execution.

test condition: An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element.

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.

test cycle: Execution of the test process against a single identifiable release of the test object.

test data: Data that exists (for example, in a database) before a test is executed, and that affects or is affected by the component or system under test.

test data preparation tool: A type of test tool that enables data to be selected from existing
databases or created, generated, manipulated and edited for use in testing.

test design: (1) See test design specification.
(2) The process of transforming general testing objectives into tangible test conditions and
test cases.

test design specification: A document specifying the test conditions (coverage items) for a
test item, the detailed test approach and identifying the associated high level test cases.

test design technique: Procedure used to derive and/or select test cases.

test design tool: A tool that supports the test design activity by generating test inputs from a
specification that may be held in a CASE tool repository, e.g. requirements management
tool, from specified test conditions held in the tool itself, or from code.

test driven development: A way of developing software where the test cases are developed,
and often automated, before the software is developed to run those test cases.

test environment: An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test.

test estimation: The calculated approximation of a result (e.g. effort spent, completion date, costs involved, number of test cases, etc.) which is usable even if input data may be incomplete, uncertain, or noisy.

test evaluation report: A document produced at the end of the test process summarizing all testing activities and results. It also contains an evaluation of the test process and lessons learned.

test execution: The process of running a test on the component or system under test, producing actual result(s).

test execution automation: The use of software, e.g. capture/playback tools, to control the execution of tests, the comparison of actual results to expected results, the setting up of test preconditions, and other test control and reporting functions.

test execution phase: The period of time in a software development life cycle during which the components of a software product are executed, and the software product is evaluated to determine whether or not requirements have been satisfied.

test execution schedule: A scheme for the execution of test procedures. The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed.

test execution technique: The method used to perform the actual test execution, either manual or automated.

test execution tool: A type of test tool that is able to execute other software using an automated test script, e.g. capture/playback.

test harness: A test environment comprised of stubs and drivers needed to execute a test.

test implementation: The process of developing and prioritizing test procedures, creating test
data and, optionally, preparing test harnesses and writing automated test scripts.

test infrastructure: The organizational artifacts needed to perform testing, consisting of test environments, test tools, office environment and procedures.

test input: The data received from an external source by the test object during test execution. The external source can be hardware, software or human.

test item: The individual element to be tested. There usually is one test object and many test  items.

test level: A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test.

test log: A chronological record of relevant details about the execution of tests.

test logging: The process of recording information about tests executed into a test log.


Post a Comment