safety: The capability of the software product to achieve acceptable levels of risk of harm to people, business, software, property or the environment in a specified context of use.
safety critical system: A system whose failure or malfunction may result in death or serious injury to people, or loss or severe damage to equipment, or environmental harm.
safety testing: Testing to determine the safety of a software product. sanity test: See smoke test.
scalability: The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]
scalability testing: Testing to determine the scalability of the software product. scenario testing: See use case testing.
scorecard: A representation of summarized performance measurements representing progress towards the implementation of long-term goals. A scorecard provides static measurements of performance over or at the end of a defined interval. See also balanced scorecard, dashboard.
scribe: The person who records each defect mentioned and any suggestions for process improvement during a review meeting, on a logging form. The scribe should ensure that the logging form is readable and understandable.
scripted testing: Test execution carried out by following a previously documented sequence of tests.
scripting language: A programming language in which executable test scripts are written, used by a test execution tool (e.g. a capture/playback tool).
SCRUM: An iterative incremental framework for managing projects commonly used with agile software development. See also agile software development.
security: Attributes of software products that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data. [ISO 9126] See also functionality.
security testing: Testing to determine the security of the software product. See also functionality testing.
security testing tool: A tool that provides support for testing security characteristics and vulnerabilities.
security tool: A tool that supports operational security. serviceability testing: See maintainability testing.
session-based test management: A method for measuring and managing session-based testing, e.g. exploratory testing.
session-based testing: An approach to testing in which test activities are planned as uninterrupted sessions of test design and execution, often used in conjunction with exploratory testing.
severity: The degree of impact that a defect has on the development or operation of a component or system.
simulation: The representation of selected behavioral characteristics of one physical or abstract system by another system.
simulator: 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. [After IEEE 610, DO178b] See also emulator.
site acceptance testing: Acceptance testing by users/customers at their site, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes, normally including hardware as well as software.
smoke test: A subset of all defined/planned test cases that cover the main functionality of a component or system, to ascertaining that the most crucial functions of a program work, but not bothering with finer details. A daily build and smoke test is among industry best practices. See also intake test.
software: Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.
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 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.
Software Process Improvement: A program of activities designed to improve the performance and maturity of the organization’s software processes and the results of such a program. [After CMMI]
software quality: The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs.
software quality characteristic: See quality attribute. software test incident: See incident.
software test incident report: See incident report.
Software Usability Measurement Inventory (SUMI): A questionnaire-based usability test technique for measuring software quality from the end user’s point of view. [Veenendaal04]
source statement: See statement.
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.
specification-based testing: See black box testing. specification-based technique: See black box test design technique.
specification-based test design technique: See black box test design technique.
specified input: An input for which the specification predicts a result.
SPI: See Sofware Process Improvement.
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.
standard: 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).
standard software: See off-the-shelf software. standards testing: See compliance testing.
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 another.
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. See also N-switch testing.
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.