![]() |
Questionnaire for the Testing Maturity Model Glossary |
ability to perform See common features.
acceptance testing Formal testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system. [IEEE-STD- 610]
activities performed See common features.
activity Any step taken or function performed, both mental and physical, toward achieving some objectives. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization.
appraisal A generic term for either software process assessment or software capability evaluation.
artifact An object produced or shaped by human workmanship. For model based process appraisals, artifacts are the products resulting from enacting a process.
assessment See software process assessment.
baseline A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]
black-box testing A fundamental testing strategy that considers the functional design specification, without regard to the internal program structure. This testing tests the product against the end user, external specifications.
capture/replay tool A test tool that records test inputs and outcomes (e.g., screens) and provides facilities for subsequent reexecution or replay of the test.
commitment A pact that is freely assumed, visible, and expected to be kept by all parties.
commitment to perform See common features.
common features The subdivision categories of the key process areas. The common features are attributes that indicate whether the implementation and institutionalization of a key process area are effective, repeatable, and lasting. The common features are the following:
- commitment to perform (I) The actions the organization must take to ensure that the process is established and will endure. Commitment to perform typically involves establishing organizational policies and leadership.
- ability to perform (II) The preconditions that must exist in the project or organization to implement the software process competently. Ability to perform typically involves resources, organizational structures, and training.
- activities performed (III) A description of the activities, roles, and procedures necessary to implement a key process area. Activities performed typically involve establishing plans and procedures, performing and tracking the work, and taking corrective actions as necessary.
- measurement and analysis (IV) A description of the basic measurement practices that are necessary to determine status related to the process. These measurements are used to control and improve the process. Measurement and analysis typically includes examples of the measurements that could be taken.
- verifying implementation (V) The steps to ensure that the activities are performed in compliance with the process that has been established. Verification typically encompasses reviews and audits by management and software quality assurance.
configuration management 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. [IEEE-STD- 610]
consensus A method of decision making that allows team members to develop a common basis of understanding and develop general agreement concerning a decision.
customer The individual or organization responsible for accepting the product and authorizing payment to the developing organization.
debugging The process of locating, analyzing, and correcting suspected faults.
defect A flaw in a system or system component that causes the system or component to fail to perform its required function. A defect, if encountered during execution, may cause a failure of the system.
defect prevention The activities involved in identifying defects or potential defects and preventing them from being introduced into a product.
emulator Hardware, software, or firmware that performs emulation.
end user The individual or group who will use the system for its intended operational purpose when it is deployed in its environment.
evaluation See software capability evaluation.
event-driven review/activity A review or activity whose performance is based on the occurrence of an event within the project (e.g., a formal review or the completion of a life cycle stage).
formal review A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.
goals A summary of the key practices of a key process area that can be used to determine whether an organization or project has effectively implemented the key process area. The goals signify the scope, boundaries, and intent of each key process area.
infrastructure The underlying framework of an organization or system, including organizational structures, policies, standards, training, facilities, and tools, that supports its ongoing performance.
institutionalization The building of infrastructure and culture that support methods, practices, and procedures so that they are the ongoing way of doing business, even after those who originally defined them are gone.
integration See software integration.
integration testing An orderly progression of testing in which software elements, hardware elements, or both are combined and tested until the entire system has been integrated.
key practice The infrastructure and activities that contribute most to the effective implementation and institutionalization of a key process area.
key process area A cluster of related activities that, when performed collectively, achieve a set of goals considered to be important for establishing process capability. The key process areas have been defined to reside at a single maturity level.
manager A role that encompasses providing technical and administrative direction and control to individuals performing tasks or activities within the manager's area of responsibility. The traditional functions of a manager include planning, resourcing, organizing, directing, and controlling work within an area of responsibility.
maturity level A well-defined evolutionary plateau toward achieving a mature software process.
maturity questionnaire See software process maturity questionnaire.
measurement The dimension, capacity, quantity, or amount of something (e.g., 300 source lines of code or 7 document pages of design).
measurement and analysis See common features.
method A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.
organization A unit within a company or other entity within which many projects are managed as a whole. All projects within an organization share a common top-level manager and common policies.
periodic review/activity A review or activity that occurs at specified, regular time intervals.
policy A guiding principle, typically established by senior management, that is adopted by an organization or project to influence and determine decisions.
procedure A means or techniques whereby the performance of a task, or process is assured. The procedure may involve several organizational elements, and its documentation may include some combination of function statements, operating plans, position description. The documentation defines what should be performed, how it should be performed, and who is accountable for the results.
process A sequence of steps performed for a given purpose [IEEE 91].
project An undertaking requiring concerted effort that is focused on developing and/or maintaining a specific product. The product may include hardware, software, and other components. Typically a project has its own funding, cost accounting, and delivery schedule.
project manager The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project building a software or hardware/software system. The project manager is the individual ultimately responsible to the customer.
quality (1) The degree to which a system, component, or process meets specified requirements. (2) The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]
quantitative criteria When the number of defects/unit time we find a certain level, when a certain level of reliability is reached, when a certain level of trustworthiness is reached, when software products is certified with usage testing with a given degree of confidence.
quantitative method Reliability, trustworthiness measurement, and certification of software product.
required training Training designated by an organization to be required to perform a specific role.
resource The needs to support testing process such as funding, materials or tools, technical training, standard documents, schedules, test-related metric, and etc.
review The evaluation of software products through presentation of form and technical content.
risk Possibility of suffering loss.
risk management An approach to problem analysis that weighs risk in a situation by using risk probabilities to give a more accurate understanding of the risks involved. Risk management includes risk identification, analysis, prioritization, and control.
role A unit of defined responsibilities that may be assumed by one or more individuals.
senior manager A management role at a high enough level in an organization that the primary focus is the long-term vitality of the organization, rather than short-term project and contractual concerns and pressures. In general, a senior manager for engineering would have responsibility for multiple projects.
simulator A device, data processing system, or computer program that represents certain features of the behavior of a physical or abstract system.
software capability evaluation An appraisal by a trained team of professionals to identify contractors who are qualified to perform the software work or monitor the state of the software process used on an existing software effort.
software integration A process of putting together selected software components to provide the set or specified subset of the capabilities the final software system will provide.
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, requirement phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. [IEEE-STD-610]
software process assessment An appraisal by a trained team of software professionals to determine the state of an organization's current software process, to determine the high-priority software process-related issues facing an organization, and to obtain the organizational support for software process improvement.
software quality assurance (1) A planned and systematic pattern of all actions necessary to provide adequate confidence that a software work product conforms to established technical requirements. (2) A set of activities designed to evaluate the process by which software work products are developed and/or maintained. [IEEE-STD-610]
software work product Any artifact created as part of defining, maintaining, or using a software process. They can include process descriptions, plans, procedures, computer programs, and associated documentation. which may or may not be intended for delivery to a customer or end user.
standard Mandatory requirement employed and enforced to prescribe a disciplined uniform approach to software development. [IEEE- STD-610]
system testing The process of testing an integrated hardware and software system to verify that the system meets its specified requirements.
technical requirements Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.
test case A specific set of test data along with expected results for a particular test objectives, such as to exercise a program feature or to verify compliance with a specific requirement [Hetzel, 1984].
testing The process of exercising or evaluating a system or system component, by manual or automated methods, in order to verify that it satisfies specified requirements or identifies differences between expected and actual results.
testing maturity questionnaire A set of questions that supports an assessment team in determining the testing maturity level of an organization. It concerns the implementation of important software testing practices in a software organization.
test tools The software, hardware, systems, or other instruments that are used to measure and test an item.
test work product Any artifact created as part of testing process. They can include test plans, test cases specifications, test procedures, and test documents.
unit testing Aggregate of technical activities involved in demonstrating that a unit has been correctly coded, that the code and the design of a unit are consistent, and that the unit design is correct.
V-model A framework to describe the software development life- cycle activities from requirement specification to maintenance. (Modified V model including test development and execution activities)
validation The process of evaluating the software development process to ensure compliance with software requirements.
verification (1) The process of determining whether or not the products of a given phase of the software development cycle fulfill the requirements established during the previous phase. (2) Formal proof of program correctness. (3) The act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether or not items, processes, services, or documents conform to specified requirements.
verifying implementation See common features.
white-box testing A fundamental testing strategy that requires knowledge of the internal program structure and is derived from the internal design specification or the code.