Terms related to Foundation 2018

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.
Testing to determine the ease by which users with disabilities can use a component or system.
A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control script for the test.
User or any other person or system that interacts with the test object in a specific way.
The behavior produced/observed when a component or system is tested.
The behavior produced/observed when a component or system is tested.
A review technique carried out by independent reviewers informally, without a structured process.
Any condition that deviates from expectation based on requirements specifications, design documents, user documents, standards, etc., or from someone's perception or experience. Anomalies may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation.
A type of interface in which the components or systems involved exchange information in a defined formal structure.
The response of a component or system to a set of input values and preconditions.
A procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.
A publicly displayed chart that depicts the outstanding effort versus time in an iteration. It shows the status and trend of completing the tasks of the iteration. The X-axis typically represents days in the sprint, while the Y-axis is the remaining effort (usually either in ideal engineering hours or story points).
An analysis technique aimed at identifying the root causes of defects. By directing corrective measures at root causes, it is hoped that the likelihood of defect recurrence will be minimized.
A review technique guided by a list of questions or required attributes.
Testing based on an analysis of the internal structure of the component or system.
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.
Testing based on an analysis of the internal structure of the component or system.
A standard that describes the characteristics of a design or a design description of data or program components.
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.
The degree to which a component or system can exchange information with other components or systems, and/or perform its required functions while sharing the same hardware or software environment.
A test approach in which the test suite comprises all combinations of input values and preconditions.
The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify.
The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions.
Testing performed to expose defects in the interfaces and interactions between integrated components.
The composition of a component or system as defined by the number, nature, and interconnections of its constituent parts.
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.
Testing to determine the portability of a software product.
Acceptance testing conducted to verify whether a system satisfies its contractual requirements.
A sequence of events, e.g., executable statements, of a component or system from an entry point to an exit point.
The total costs incurred on quality activities and issues and often split into prevention costs, appraisal costs, internal failure costs and external failure costs.
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.
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. Data-driven testing is often used to support the application of test execution tools such as capture/playback tools.
Code that cannot be reached and therefore is impossible to execute.
The process of finding, analyzing and removing the causes of failures in software.
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.
The process of evaluating behavior, e.g., memory performance, CPU usage, of a system or component during execution.
Testing that involves the execution of the software of a component or system.
A human action that produces an incorrect result.
A statement which, when compiled, is translated into object code, and which will be executed procedurally when the program is running and may perform an action on data.
A test approach in which the test suite comprises all combinations of input values and preconditions.
A procedure to derive and/or select test cases based on the tester's experience, knowledge and intuition.
Testing based on the tester's experience, knowledge and intuition.
A software engineering methodology used within Agile software development whereby core practices are programming in pairs, doing extensive code review, unit testing of all code, and simplicity and clarity in code.
A test is deemed to fail if its actual result does not match its expected result.
A distinguishing characteristic of a component or system.
A result of an evaluation that identifies some important issue, problem, or opportunity.
An integration approach that combines the components or systems for the purpose of getting a basic functionality working early.
The degree to which a component or system provides functions that meet stated and implied needs when used under specified conditions.
Testing based on an analysis of the internal structure of the component or system.
An organizational improvement model that serves as a roadmap for initiating, planning, and implementing improvement actions. The IDEAL model is named for the five phases it describes: initiating, diagnosing, establishing, acting, and learning.
Separation of responsibilities, which encourages the accomplishment of objective testing.
Supplied instructions on any suitable media, which guides the installer through the installation process. This may be a manual guide, step-by-step procedure, installation wizard, or any other similar process description.
The process of combining components or systems into larger assemblies.
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
Testing to determine the interoperability of a software product.
A type of software development lifecycle model in which the component or system is developed through a series of repeated cycles.
A metric that supports the judgment of process performance.
A scripting technique that uses data files to contain not only test data and expected results, but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control script for the test.
On large projects, the person who reports to the test manager and is responsible for project management of a particular test level or a particular set of testing activities.
Testing performed to expose defects in the interfaces and interactions between integrated components.
Testing based on an analysis of the internal structure of the component or system.
Testing based on an analysis of the internal structure of the component or system.
Testing the changes to an operational system or the impact of a changed environment to an operational system.
The number or category assigned to an attribute of an entity by making a measurement.
The process of assigning a number or category to an entity to describe an attribute of that entity.
A memory access failure due to a defect in a program's dynamic store allocation logic that causes it to fail to release memory after it has finished using it, eventually causing the program and/or other concurrent processes to fail due to lack of memory.
A measurement scale and the method used for measurement.
A point in time in a project at which defined (intermediate) deliverables and results should be ready.
A human action that produces an incorrect result.
Testing based on or involving models.
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.
Operational testing in the acceptance test phase, typically performed in a (simulated) operational environment by operations and/or systems administration staff focusing on operational aspects, e.g., recoverability, resource-behavior, installability and technical compliance.
Hardware and software products installed at users' or customers' sites where the component or system under test will be used. The software may include operating systems, database management systems, and other applications.
A high-level document describing the principles, approach and major objectives of the organization regarding testing.
The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports, and communication messages sent out.
A test is deemed to pass if its actual result matches its expected result.
A sequence of events, e.g., executable statements, of a component or system from an entry point to an exit point.
The degree to which a component or system uses time, resources and capacity when accomplishing its designated functions.
A metric that supports the judgment of process performance.
Testing to determine the performance of a software product.
A test tool that generates load for a designated test item and that measures and records its performance during test execution.
A review technique whereby reviewers evaluate the work product from different viewpoints.
A review technique whereby reviewers evaluate the work product from different viewpoints.
A consensus-based estimation technique, mostly used to estimate effort or relative size of user stories in Agile software development. It is a variation of the Wideband Delphi method using a deck of cards with values representing the units in which the team estimates.
The ease with which the software product can be transferred from one hardware or software environment to another.
Testing to determine the portability of a software product.
A meeting at the end of a project during which the project team members evaluate the project and learn lessons that can be applied to the next project.
The level of (business) importance assigned to an item, e.g., defect.
The effect on the component or system by the measurement instrument when the component or system is being measured, e.g., by a performance testing tool or monitor. For example performance may be slightly worse when performance testing tools are being used.
An unknown underlying cause of one or more incidents.
A set of interrelated activities, which transform inputs into outputs.
A program of activities designed to improve the performance and maturity of the organization's processes, and the result of such a program.
Operational testing in the acceptance test phase, typically performed in a (simulated) operational environment by operations and/or systems administration staff focusing on operational aspects, e.g., recoverability, resource-behavior, installability and technical compliance.
A project is a unique set of coordinated and controlled activities with start and finish dates undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources.
The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations.
Part of quality management focused on providing confidence that quality requirements will be fulfilled.
A category of product attributes that bears on quality.
A set of activities designed to evaluate the quality of a component or system.
Coordinated activities to direct and control an organization with regard to quality that include establishing a quality policy and quality objectives, quality planning, quality control, quality assurance, and quality improvement.
A proprietary adaptable iterative software development process framework consisting of four project lifecycle phases: inception, elaboration, construction and transition.
A degradation in the quality of a component or system due to a change.
Acceptance testing conducted to verify whether a system conforms to relevant laws, policies and regulations.
A model that shows the growth in reliability over time during continuous testing of a component or system as a result of the removal of defects that result in reliability failures.
A tool that supports the recording of requirements, requirements attributes (e.g., priority, knowledge responsible) and annotation, and facilitates traceability through layers of requirements and requirements change management. Some requirements management tools also provide facilities for static analysis, such as consistency checking and violations to pre-defined requirements rules.
A meeting at the end of a project during which the project team members evaluate the project and learn lessons that can be applied to the next project.
A factor that could result in future negative consequences.
The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions.
A review technique where reviewers evaluate a work product from the perspective of different stakeholder roles.
A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed.
An analysis technique aimed at identifying the root causes of defects. By directing corrective measures at root causes, it is hoped that the likelihood of defect recurrence will be minimized.
A review technique where the review is guided by determining the ability of the work product to address specific scenarios.
An iterative incremental framework for managing projects commonly used with Agile software development.
Testing to determine the security of the software product.
A type of development lifecycle model in which a complete system is developed in a linear way of several discrete and successive phases with no overlap between them.
A technique to enable virtual delivery of services which are deployed, accessed and managed remotely.
An approach in which test activities are planned as test sessions.
The degree of impact that a defect has on the development or operation of a component or system.
The representation of selected behavioral characteristics of one physical or abstract system by another system.
A device, computer program or system used during testing, which behaves or operates like a given system when provided with a set of controlled inputs.
Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.
The activities performed at each stage in software development, and how they relate to one another logically and chronologically.
A distinguishing characteristic of a component or system.
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 lifecycle 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.
An entity in a programming language, which is typically the smallest indivisible unit of execution.
Documentation that provides a detailed description of a component or system for the purpose of developing and testing it.
Formal, possibly mandatory, set of requirements developed and used to prescribe consistent approaches to the way of working or to provide guidelines (e.g., ISO/IEC standards, IEEE standards, and organizational standards).
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 another.
A transition between two states of a component or system.
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 another.
An entity in a programming language, which is typically the smallest indivisible unit of execution.
The percentage of executable statements that have been exercised by a test suite.
Coverage measures based on the internal structure of a component or system.
Testing based on an analysis of the internal structure of the component or system.
Testing based on an analysis of the internal structure of the component or system.
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.
Testing an integrated system to verify that it meets specified requirements.
A set of one or more test cases.
The use of software to perform or support test activities, e.g., test management, test design, test execution and results checking.
An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test.
The activity that makes test assets available for later use, leaves test environments in a satisfactory condition and communicates the results of testing to relevant stakeholders.
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.
Execution of the test process against a single identifiable release of the test object.
A type of test tool that enables data to be selected from existing databases or created, generated, manipulated and edited for use in testing.
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.
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.
An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test.
The calculated approximation of a result related to various aspects of testing (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.
The process of running a test on the component or system under test, producing actual result(s).
A test tool that executes tests against a designated test item and evaluates the outcomes against expected results and postconditions.
A type of test tool that enables data to be selected from existing databases or created, generated, manipulated and edited for use in testing.
A test environment comprised of stubs and drivers needed to execute a test.
The organizational artifacts needed to perform testing, consisting of test environments, test tools, office environment and procedures.
The data received from an external source by the test object during test execution. The external source can be hardware, software or human.
On large projects, the person who reports to the test manager and is responsible for project management of a particular test level or a particular set of testing activities.
A tool that provides support to the test management and control part of a test process. It often has several capabilities, such as testware management, scheduling of tests, the logging of results, progress tracking, incident management and test reporting.
The person responsible for project management of testing activities and resources, and evaluation of a test object. The individual who directs, controls, administers, plans and regulates the evaluation of a test object.
The component or system to be tested.
A reason or purpose for designing and executing a test.
The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports, and communication messages sent out.
The activity of establishing or updating a test plan.
A high-level document describing the principles, approach and major objectives of the organization regarding testing.
A sequence of test cases in execution order, and any associated actions that may be required to set up the initial preconditions and any wrap up activities post execution.
A program of activities designed to improve the performance and maturity of the organization's test processes and the results of such a program.
Documentation summarizing test activities and results.
Collecting and analyzing data from testing activities and subsequently consolidating the data in a report to inform stakeholders.
The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports, and communication messages sent out.
An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test.
A list of activities, tasks or events of the test process, identifying their intended start and finish dates and/or times, and interdependencies.
A sequence of test cases in execution order, and any associated actions that may be required to set up the initial preconditions and any wrap up activities post execution.
An uninterrupted period of time spent in executing tests. In exploratory testing, each test session is focused on a charter, but testers can also explore new opportunities or issues during a session. The tester creates and executes on the fly and records their progress.
A procedure used to derive and/or select test cases.
A software product that supports one or more test activities, such as planning and control, specification, building initial files and data, test execution and test analysis.
A skilled professional who is involved in the testing of a component or system.
The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation 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.
The capability of the software product to enable the user to understand whether the software is suitable, and how it can be used for particular tasks and conditions of use.
A tool that provides an environment for unit or component testing in which a component can be tested in isolation or with suitable stubs and drivers. It also provides other support for the developer, such as debugging capabilities.
Code that cannot be reached and therefore is impossible to execute.
A sequence of transactions in a dialogue between an actor and a component or system with a tangible result, where an actor can be a user or anything that can exchange information with the system.
A person's perceptions and responses resulting from the use or anticipated use of a software product.
All components of a system that provide information and controls for the user to accomplish specific tasks with the system.
A high-level user or business requirement commonly used in Agile software development, typically consisting of one sentence in the everyday or business language capturing what functionality a user needs and the reason behind this, any non-functional criteria, and also includes acceptance criteria.
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.
An element of storage in a computer that is accessible by a software program by referring to it by a name.
Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.
A procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.
Testing based on an analysis of the internal structure of the component or system.
An expert-based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.