Glossar

A
ablaufbasierter Test Testen mit dem Ziel festzustellen, ob die Komponente oder das System im Zusammenspiel mit neuen oder vorhandenen Benutzer-Geschäftsprozessen oder Betriebsprozessen arbeiten kann.
Ablauftest Ein Ansatz zum Komponentenintegrationstest, bei dem die fortlaufende Integration der Komponenten entsprechend der Umsetzung von Untermengen von Anforderungen durchgeführt wird, im Gegensatz zu der Integration nach Hierarchiestufen (Top-Down, Bottom-Up etc.).
Abnahmekriterien Diejenigen Kriterien, die ein System oder eine Komponente erfüllen muss, um durch den Benutzer, Kunden oder eine bevollmächtigte Instanz abgenommen zu werden. [Nach IEEE 610]
Abnahmetest Formales Testen hinsichtlich der Benutzeranforderungen und -bedürfnisse bzw. der Geschäftsprozesse. Es wird durchgeführt, um einem Auftraggeber oder einer bevollmächtigten Instanz die Entscheidung auf der Basis der Abnahmekriterien zu ermöglichen, ob ein System anzunehmen ist oder nicht. [Nach IEEE 610]
Abschluss der Testaktivitäten Während des Abschlusses der Testaktivitäten werden die gesammelten Daten aus den abgeschlossenen Aktivitäten verwendet, um die Erfahrungen, und Testmittel, Fakten und Zahlen zu konsolidieren. Der Abschluss der Testaktivitäten umfasst die Konsolidierung und Archivierung der Testmittel und die Bewertung des Testprozesses einschließlich eines Testbewertungsberichtes. Siehe auch Testprozess.
abstrakter Testfall Ein Testfall ohne konkrete Ein- und Ausgabewerte für Eingabedaten und vorausgesagte Ergebnisse. Er verwendet logische Operatoren, weil die konkreten noch nicht definiert oder verfügbar sind.

Siehe auch konkreter Testfall.

Abweichung Jedes Ereignis, welches während des Testens auftritt und weiterer Untersuchungen bedarf. [Nach IEEE 1008]
Abweichungsprotokollierung Aufzeichnungen der Details einer beliebigen Abweichung, z.B. während des Testens.
Ad-hoc-Testen Informelles Testen, bei dem keine Testvorbereitung stattfindet und keine anerkannten Testentwurfsverfahren verwendet werden. Es werden keine erwarteten Ergebnisse vorab spezifiziert und die Testdurchführung erfolgt mehr oder minder improvisiert.
Affentest Ein Test, bei dem aus einer größeren Menge von möglichen Eingaben diese zufällig ausgewählt und Tasten zufällig betätigt werden, unabhängig davon, wie das Produkt im Betrieb tatsächlich verwendet wird.
Agieren (IDEAL) Die Phase im IDEAL-Modell, in der die Verbesserungen entwickelt, in die Praxis umgesetzt und unternehmensweit eingesetzt werden. Die Agierenphase besteht aus den Aktivitäten: Lösung erstellen, Lösung erproben/testen, Lösung verfeinern und Lösung umsetzen.

Siehe auch IDEAL.

agile Softwareentwicklung Eine auf iterativer und inkrementeller Entwicklung basierende Gruppe von Softwareentwicklungsmethoden, wobei sich Anforderungen und Lösungen durch die Zusammenarbeit von selbstorganisierenden funktionsübergreifenden Teams entwickeln.
Agiles Manifest Eine Aussage über die Werte, die der agilen Softwareentwicklung zugrunde liegen. Diese Werte sind: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge, Reagieren auf Veränderungen ist wichtiger als die Befolgung eines Plans, Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen, funktionierende Software ist wichtiger als umfassende Dokumentation.
agiles Testen Testvorgehensweise in einem Projekt mit agiler Softwareentwicklung, die Techniken und Methoden wie z.B. Extreme Programming (XP) einbindet, die Entwicklung als den Kunden des Testens ansieht, und die den Test-First-Entwicklungsansatz hervorhebt. Siehe auch testgetriebene Entwicklung.
Akteur Benutzer oder irgendeine andere Person oder ein System, welche mit dem zu testenden System auf eine bestimmte Art interagiert.
aktionswortgetriebener Test Siehe schlüsselwortgetriebener Test.
Alpha-Test Testen beim Hersteller durch potenzielle Kunden/Benutzer oder ein unabhängiges Testteam in einer Simulations– oder Nutzungsumgebung, die nicht anderweitig für die Entwicklung der Software genutzt wird. Ein Alpha-Test kann als interner Abnahmetest für Standardsoftware betrachtet werden.
Analysator Siehe statischer Analysator.
Analysierbarkeit Die Fähigkeit eines Softwareprodukts, die Diagnose von Mängeln oder Ursachen von Fehlerwirkungen zu ermöglichen oder änderungsbedürftige Teile zu bestimmen. [ISO 9126]

Siehe auch Wartbarkeit/Änderbarkeit.

analytische Teststrategie Eine Teststrategie, bei der das Testteam die Testbasis analysiert um zu überdeckende Testbedingungen zu identifizieren.
analytisches Testen Testen, das auf einer systematischen Analyse von z.B. Produktrisiken oder Anforderungen basiert.
Änderungskontrolle Siehe Konfigurationskontrolle.
Änderungsmanagement (1) Ein strukturierter Ansatz, Personen, Teams und Organisationen vom aktuellen Zustand in einen gewünschten zukünftigen Zustand zu bringen. (2) Ein kontrollierter Weg, um eine (vorgeschlagene) Veränderung eines Produktes oder Dienstes umzusetzen. Siehe auch Konfigurationsmanagement.
Anforderung Eine vom Benutzer benötigte Eigenschaft oder Fähigkeit, die eine Software erfüllen oder besitzen muss, um einen Vertrag, einen Standard, eine Spezifikation oder ein anderes formales Dokument zu erfüllen. [Nach IEEE 610]
anforderungsbasierter Test Ein Ansatz zum Testen, der auf den Anforderungen basiert. Aus ihnen werden die Testziele und Testbedingungen abgeleitet. Dazu gehören Tests, die einzelne Funktionen tätigen oder solche, die nicht funktionalen Eigenschaften wie Zuverlässigkeit oder Gebrauchstauglichkeit untersuchen.
Anforderungsmanagementwerkzeug Ein unterstützendes Werkzeug für die Erfassung, Kommentierung und Verwaltung von Anforderungen und deren zugeordnete Attribute (z.B. Priorität, Know-How-Träger). Es ermöglicht die Rückverfolgbarkeit über die Anforderungsstufen bis ins Änderungsmanagement der Anforderungen. Einige Anforderungsmanagementwerkzeuge erlauben statischen Analysen (z.B. Konsistenzprüfungen und die Aufdeckung der Abweichung von definierten Anforderungsregeln).
Anforderungsphase Eine Phase im Softwarelebenszyklus, in der die Anforderungen eines Softwareprodukts (ermittelt,) definiert und dokumentiert werden. [IEEE 610]
Angemessenheit Die Fähigkeit eines Softwareprodukts für spezifizierte Aufgaben und Zielsetzungen der Benutzer einen geeigneten Satz Funktionen zu liefern. [ISO 9126]

Siehe auch Qualitätsmerkmal.

Angemessenheitstest Testen mit dem Ziel, die Angemessenheit eines Softwareprodukts zu bestimmen.
Angreifer Eine Person oder ein Prozess, die bzw. der unberechtigt und in potenziell böser Absicht versucht, auf Daten, Funktionen oder zugriffsbeschränkte Bereiche des Systems zuzugreifen.

Siehe auch Hacker

Angriff Siehe Fehlerangriff.
Angrifferkennungssystem Ein System, das Aktivitäten auf den sieben Schichten des OSI-Modells von der Netzwerk- bis zur Anwendungsschicht überwacht, um Verstöße gegen die Sicherheitspolitik zu erkennen.

Siehe auch Schadprogramm-Scan.

angriffsbasiertes Testen Ein erfahrungsbasiertes Testverfahren, das Softwareangriffe nutzt, um Fehlerwirkungen, insbesondere solche im Bereich der Zugangssicherheit, zu erzeugen. Siehe auch Angriff.
Angriffsvektor Ein Pfad oder ein Mittel, über den ein Angreifer mit böser Absicht Zugriff auf ein System erlangen kann.
Anomalie Unstimmigkeit, die durch Abweichung von (berechtigten) Erwartungen an das Softwareprodukt ausgelöst ist. Die Erwartungen können auf einer Anforderungsspezifikation, Entwurfsspezifikationen, Benutzerdokumentation, Standards, bestimmten Vorstellungen oder sonstigen Erfahrungen basieren. Anomalien können auch, aber nicht nur, durch Reviews, Testen, Analysen, Kompilierung oder die Benutzung des Softwareprodukts oder seiner Dokumentation aufgedeckt werden. [IEEE 1044]

Siehe auch Fehlerzustand, Fehlhandlung, Fehlerwirkung, Abweichung, Problem.

Anpassbarkeit Die Fähigkeit eines Softwareprodukts, dass sie auf verschiedene Laufzeitumgebungen angepasst werden kann und dabei nur die Anpassungen vorzunehmen sind, die genau diesem Zweck dienen. [ISO 9126]

Siehe auch Übertragbarkeit.

Anti-Pattern Wiederholte Aktion, Prozess, Struktur oder wiederverwendbare Lösung, die anfangs vorteilhaft erscheint und allgemein genutzt wird, die aber in der Praxis ineffektiv oder kontraproduktiv ist.
Antivirenprogramm Software, die bekannte Schadprogramme aufspürt und blockiert. Siehe auch Schadprogramm.
Anweisung Syntaktisch definierte Einheit einer Programmiersprache (z.B. Zuweisung an eine Variable), die typischerweise die kleinste, unteilbare ausführbare Einheit darstellt.
Anweisungstest Ein White-Box-Testentwurfsverfahren, bei dem die Testfälle auf das Ausführen von Anweisungen ausgelegt sind.
Anweisungsüberdeckung Der Anteil der Anweisungen, die durch eine Testsuite ausgeführt wurden, bezogen auf alle Anweisungen.
Anwendungsfall Eine Folge von Vorgängen in einem Dialog zwischen einem Akteur und einer Komponente oder einem System, die zu einem konkretem Ergebnis führen. Ein Akteur kann dabei ein Benutzer sein, oder irgend etwas, was Informationen mit dem System austauschen kann.
anwendungsfallbasierter Test Ein Black-Box-Testentwurfsverfahren, bei dem Testfälle so entworfen werden, dass damit Szenarien der Anwendungsfälle durchgeführt werden.
API Akronym für Application Programming Interface (Anwendungsprogrammierungsschnittstelle).
API-Testen Testen durch Senden von Kommandos an das zu testende System über die direkte Nutzung der Programmierschnittstelle der Applikaton.
Äquivalenter manueller Testaufwand Aufwand, der benötigt wird, um die Tests manuell durchzuführen.
Äquivalenzklasse Teil des Wertebereichs von Ein- oder Ausgaben, in dem ein gleichartiges Verhalten der Komponente oder des Systems angenommen wird, basierend auf der zugrunde liegenden Spezifikation.
Äquivalenzklassenbildung Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle im Hinblick auf Äquivalenzklassenüberdeckung entworfen werden. Grundsätzlich werden Testfälle so ausgewählt, dass jede Äquivalenzklasse mindestens einmal abgedeckt wird.
Äquivalenzklassenüberdeckung Der Anteil der Äquivalenzklassen, die durch eine ausgeführte Testsuite überdeckt werden.
Äquivalenzpartition Siehe Äquivalenzklasse.
Arbeitsergebnis Jedes Ergebnis der Arbeit, das vom Ersteller an jemand anderen übergeben werden muss.
Assessment-Bericht Ein Dokument, das die Ergebnisse eines Assessments zusammenfasst, z.B. Schlussfolgerungen, Empfehlungen und Befunde. Siehe auch Prozessbewertung.
Assessor Eine Person, die ein Assessment durchführt, ein Mitglied eines Assessment-Teams.
atomare Bedingung Eine Bedingung die nicht mehr weiter zerlegt werden kann, d.h. eine Bedingung, die keine zwei oder mehr Einzelbedingungen enthält, die durch logische Operatoren (UND, ODER, EX-ODER) verbunden sind.
Attraktivität Die Fähigkeit eines Softwareprodukts, für den Benutzer attraktiv zu sein. [ISO 9126]

Siehe auch Gebrauchstauglichkeit.

Audit Ein unabhängiges Testen von Softwareprodukten und -prozessen, um die Konformität mit Standards, Richtlinien, Spezifikationen, und/oder Prozeduren basierend auf objektiven Kriterien zu bestimmen, einschließlich der Dokumente, welche (1) die Gestaltung oder den Inhalt der zu erstellenden Produkte festlegen,

(2) den Prozess der Erstellung der Produkte beschreiben

(3) und spezifizieren, wie die Übereinstimmung mit den Standards und Richtlinien nachgewiesen bzw. gemessen werden kann. [IEEE 1028]

Audit Trail Ein Pfad, bei dem der Prozess-Output als Startpunkt verwendet wird und durch den Prozess bis zum Beginn/Input (z.B. Daten) zurückverfolgt wird. Dies erleichtert die Überprüfung von Ergebnissen und erlaubt ein Prozess-Audit. [Nach TMap®]
Aufrufgraph Repräsentation der Aufrufbeziehungen der Unterprogramme eines Programmes.
Ausfallrate Das Verhältnis aus der Anzahl der Fehlerwirkungen einer bestimmten Kategorie zu einer vorgegebenen Maßeinheit (z.B. Anzahl der Fehlerwirkungen pro Zeitintervall, Fehlerwirkungen pro Anzahl von Transaktionen, Fehlerwirkungen pro Anzahl von Rechnerläufen). [IEEE 610]
Ausfallsicherheitstest Testen durch Simulation von Ausfällen oder durch die Erzeugung tatsächlicher Ausfälle in einer kontrollierten Umgebung. Nach einem Ausfall wird der Ausfall-Umschalt-Mechanismus getestet, um sicherzustellen, dass keine Daten verloren gehen oder zerstört werden, und dass die vereinbarte Lieferbereitschaft erhalten bleibt (z.B. Verfügbarkeit der Funktionalität oder Antwortzeiten). Siehe auch Wiederherstellbarkeitstest.
ausführbare Anweisung Eine Anweisung, die nach ihrer Kompilierung zu Objektcode zur Laufzeit Aktionen auf bzw. mit den Daten ausführen kann.
ausführbarer Pfad Ein Pfad, für den eine Menge von Eingabewerten und Vorbedingungen existiert, die den Pfad zur Ausführung bringen.
Ausgabe Eine Variable, die durch eine Komponente geschrieben wird (und innerhalb oder außerhalb einer Komponente gespeichert wird).
Ausgabewert Ein konkreter Wert einer Ausgabe.

Siehe auch Ausgabe.

Ausgabewertebereich Die Menge der Werte, aus der gültige Ausgabewerte ausgewählt werden können. Siehe auch Wertebereich.
Ausgangskriterien Siehe Endekriterien.
ausgeführt Ein Strukturelement (z.B. Anweisung, Entscheidung, …) wird als ausgeführt bezeichnet, wenn Eingabewerte im Testfall seine Ausführung bewirken.
Ausnahmebehandlung Verhalten einer Komponente oder eines Systems als Antwort auf fehlerhafte Eingaben durch einen Benutzer, eine andere Komponente, ein anderes System oder eine andere interne Fehlermeldung.
Austauschbarkeit Die Fähigkeit eines Softwareprodukts an Stelle einer anderen spezifizierten Software zum selben Zweck in der gleichen Umgebung genutzt zu werden. [ISO 9126]

Siehe auch Übertragbarkeit.

Austrittspunkt Eine ausführbare Anweisung oder ein Prozessschritt, an dem ein gegebener Prozess enden soll.
Auswirkungsanalyse Die Untersuchung und Darstellung der Auswirkungen einer Änderung von spezifizierten Anforderungen auf die Entwicklungsdokumente, auf die Testdokumentation und auf die Komponenten.
Authentifizierung Ein Verfahren zur Ermittlung, ob die behauptete Identität einer Person oder eines Prozesses den Tatsachen entspricht.

Siehe auch Berechtigung

automatisierte Testmittel Testmittel, z.B. in einer Skriptsprache formulierte Anweisungen, die im automatisierten Testen eingesetzt werden.
Automatisierung der Testdurchführung Die Verwendung einer Software, z.B. eines Capture/Replay-Werkzeugs, um die Ausführung von Tests zu steuern, tatsächliche mit erwarteten Ergebnissen zu vergleichen, die definierten Vorbedingungen herzustellen sowie weitere Testüberwachungs– und Berichtsfunktionen durchzuführen.
B
Back-to-Back-Test Siehe Mutationstest.
Balanced Scorecard Ein strategisches Werkzeug zur Messung im Unternehmen, in wie weit die operationalen Aktivitäten mit deren Vorgaben im Hinblick auf Geschäftsvision und Strategie im Einklang sind.

Siehe auch Unternehmensübersicht, Scorecard.

Barrierefreiheit Der Grad, zu dem ein Produkt oder System von einer in Bezug auf ihre Fähigkeiten möglichst weit gefassten Gruppe von Menschen genutzt werden kann, um ein gegebenes Ziel in einem gegebenen Nutzungskontext zu erreichen. [ISO 25010] Siehe auch Gebrauchstauglichkeit.
Basisblock Eine Folge von einer oder mehreren aufeinanderfolgenden Anweisungen, welche keine Verzweigungen enthalten.

Anmerkung: Ein Knoten in einem Kontrollflussgraphen repräsentiert einen Basisblock.

Basis-Testfallmenge Eine aus der internen Struktur einer Komponente oder Spezifikation abgeleitete Menge von Testfällen, durch die eine 100% Überdeckung bzgl. eines spezifizierten Überdeckungskriteriums (z.B. Zweigüberdeckung) erreicht werden kann.
Bedingungs-/Entscheidungstest Ein White-Box-Testentwurfsverfahren, in dem die Testfälle im Hinblick auf Bedingungsergebnisse und Entscheidungsausgänge entworfen werden.
Bedingungs-/Entscheidungsüberdeckung Der Anteil an allen Bedingungs- und Entscheidungsausgängen, die durch eine Testsuite ausgeführt wurden. 100% Bedingungs-/Entscheidungsüberdeckung schließt sowohl 100% Bedingungsüberdeckung als auch 100% Entscheidungsüberdeckung ein.
Bedingungsergebnis Die Bewertung einer Bedingung zu WAHR oder FALSCH.
Bedingungskombinationstesten Siehe Mehrfachbedingungstest.
Bedingungskombinationsüberdeckung Siehe Mehrfachbedingungsüberdeckung.
Bedingungstest Ein White-Box-Testentwurfsverfahren, bei dem Testfälle so entworfen werden, dass Bedingungsausgänge zur Ausführung kommen.
Bedingungsüberdeckung Der Anteil der Teilbedingungsergebnisse, die durch eine Testsuite ausgeführt worden sind. 100% Bedingungsüberdeckung bedeutet, dass jede atomare Teilbedingung in jeder Entscheidung mindestens einmal mit True und einmal mit False ausgeführt wurde.
Befund Ein Ergebnis einer Bewertung, das eine wichtige Fehlerwirkung, ein Problem, oder eine Möglichkeit beschreibt.
Benchmarktest (1) Ein Standard, gegen den Messungen oder Vergleiche gemacht werden können. (2) Test, der verwendet werden kann, um Komponenten oder Systeme gegeneinander oder gegen einen Standard wie in (1) zu vergleichen. [Nach IEEE 610]
Benutzer-Abnahmetest Abnahmetest, der durch zukünftige Benutzer in einer (simulierten) betrieblichen Umgebung durchgeführt wird mit dem Fokus auf Benutzeranforderungen und -bedürfnisse.
benutzerbasierte Qualität Eine Qualitätsdarstellung, bei der Qualität durch die Fähigkeit bestimmt wird, den Bedarf und die Wünsche der Benutzer zu erfüllen. Produkte oder Dienstleistungen, die den Bedarf der Benutzer nicht erfüllen, werden kaum Nutzer finden. Das ist ein kontextabhängiger, möglicher Ansatz zur Qualität, da unterschiedliche Geschäftsmerkmale unterschiedliche Qualitäten eines Produkts erfordern. [Nach Garvin]

Siehe auch herstellungsbasierte Qualität, produktbasierte Qualität, transzendenzbasierte Qualität, wertbasierte Qualität.

Benutzerbefragung Eine benutzerzentrierte Evaluierung, bei der eine repräsentative Auswahl an Benutzern nach ihrer subjektiven Bewertung, basierend auf ihren Erfahrungen mit der Nutzung einer Komponente oder eines Systems, mittels Fragebogen befragt wird.
Benutzererlebnis Wahrnehmungen und Reaktionen einer Person, die aus der tatsächlichen und/oder der erwarteten Benutzung eines Softwareproduktes resultieren. [DIN ISO 9241-210]
Benutzertest Test, bei dem reale Benutzer die Gebrauchstauglichkeit einer Komponente oder eines Systems bewerten.
benutzerzentrierte Evaluierung Ein Prozess, mit dessen Hilfe Informationen über die Gebrauchstauglichkeit eines Systems gesammelt werden, um das System zu verbessern (auch bekannt als gestaltende Bewertung) oder um die Leistung oder den Wert des Systems zu bewerten (auch bekannt als abschließende Bewertung). Siehe auch formative Evaluierung, summative Evaluierung.
Benutzungsschnittstelle Alle Bestandteile eines Systems, die Informationen und Steuerelemente zur Verfügung stellen, die für den Benutzer notwendig sind, um eine bestimmte Arbeitsaufgabe mit dem System zu erledigen.
beratungsunterstützte Teststrategie Eine Teststrategie, bei der das Testteam auf die Informationseingaben eines oder mehrerer Stakeholder vertraut um die Details der Teststrategie zu bestimmen.
beratungsunterstütztes Testen Testen, das von geeigneten Experten außerhalb des Testteams angeleitet und beraten wird (z.B. von Experten der Technologie oder des Geschäftsbereiches).
Berechtigung Einem Benutzer oder Prozess erteilte Erlaubnis zum Zugriff auf bestimmte Ressourcen.

Siehe auch Authentifizierung.

Best Practice Eine überlegene Methode oder innovative Vorgehensweise, die zu einer gesteigerten Leistungsfähigkeit einer Organisation unter gegebenen Bedingungen beiträgt. Üblicherweise herrscht bei vergleichbaren Unternehmen Einigkeit darüber, was jeweils Best Practice ist.
bestanden Ein Test wird als bestanden bezeichnet, wenn das tatsächliche mit dem vorausgesagten Ergebnis übereinstimmt.
bestanden/nicht bestanden-Kriterien Regeln, die dazu dienen, für ein Testobjekt entscheiden zu können, ob ein Test bestanden oder nicht bestanden wurde. [IEEE 829]
Bestätigungstest Siehe Fehlernachtest.
bestimmende Bedingungsüberdeckung Siehe modifizierte Bedingungs-/Entscheidungsüberdeckung.
bestimmender Bedingungstest Siehe modifizierter Bedingungs-/Entscheidungstest.
Beta-Test Testen oder testweiser Betrieb eines Softwareprodukts durch repräsentative Kunden/Benutzer in der Einsatzumgebung des Kunden/Benutzers, um zu ermitteln, ob eine Komponente oder ein System die Kundenbedürfnisse erfüllt und zu den Geschäftsprozessen passt. Mit einem Beta-Test wird eine Art externer Abnahmetest durchgeführt, um vor der endgültigen Freigabe eine Rückmeldung vom Markt einzuholen.
betrieblicher Abnahmetest Ein Betriebstest innerhalb des Abnahmetests, üblicherweise in einer (simulierten) Produktionsumgebung durch den Betreiber und/oder Administrator durchgeführt, mit Schwerpunkt bei den operationalen Aspekten, z.B. Wiederherstellbarkeit, Ressourcenverwendung, Installierbarkeit und technische Kompatibilität. Siehe auch Operationaler Test.
Betriebsfähigkeitstest Siehe Wartbarkeitstest.
Betriebstest Test, der durchgeführt wird, um eine Komponente oder ein System in ihrer operativen Umgebung (Arbeits- bzw. Produktivumgebung) zu bewerten. [IEEE 610]
Bewertungssitzung Eine Sitzung am Ende eines Projekts, bei der die Mitglieder des Projektteams das Projekt rückblickend bewerten und aus den Erfahrungen für die nächsten Projekte lernen.
Big-Bang-Integrationstest Ein Ansatz des Integrationstests, bei welchem verschiedene Software– und Hardwareelemente in einem großen Schritt zu einer Komponente oder einem Gesamtsystem integriert werden, anstatt sie schrittweise zu integrieren. [Nach IEEE 610]

Siehe auch Integrationstest.

Black-Box-Test Funktionales oder nicht-funktionales Testen ohne Nutzung von Informationen über Interna eines Systems oder einer Komponente.
Black-Box-Testentwurfsverfahren Ein Verfahren zur Herleitung und Auswahl von Testfällen. Es basiert auf einer Analyse der funktionalen oder nicht-funktionalen Anforderungen (Spezifikationen) einer Komponente oder Systems ohne Berücksichtigung ihrer internen Struktur.
Black-Box-Verfahren Siehe Black-Box-Testentwurfsverfahren.
blockierter Testfall Zur Durchführung eingeplanter Testfall, der nicht ausgeführt werden kann, weil die Voraussetzungen für seine Ausführung nicht erfüllt sind.
Bot-Netz Ein Netzwerk von kompromittierten Computern, den sogenannten Bots (aus Englisch: robot), die unter der Kontrolle einer dritten Partei stehen, mit dem Ziel, Schadsoftware oder Spam zu versenden, oder Angriffe auszulösen.
Bottom-Up-Integrationstest Ein inkrementeller Ansatz zum Integrationstest, bei dem die Komponenten der untersten Ebene zuerst getestet werden, um sie dann beim Testen von Komponenten höherer Ebenen zu nutzen. Dieses Verfahren wird bis zur Komponente an der Spitze der Hierachie wiederholt.

Siehe auch Integrationstest.

Breitband-Delphi Ein expertenbasiertes Verfahren zur Testschätzung, mit dem Ziel, durch Einbeziehung von Teammitgliedern zu einer möglichst genauen Schätzung zu kommen.
Build-Verifizierungstest Eine Menge von automatisierten Tests, welche die Integrität jedes neuen Builds validieren, und ihre Kernfunktionalität, Stabilität und Testbarkeit verifizieren. Es handelt sich um eine verbreitete Industriepraxis bei häufigen Builds (z.B. in agilen Projekten). Er wird bei jedem neuen Build vor der Freigabe für weitere Tests durchgeführt. Siehe auch Smoke-Test.
Burndown-Chart Ein öffentlich zugängliches Diagramm, das ausstehende Aufwände gegenüber der Zeit in einem Sprint (Iteration) zeigt. Es zeigt Status und Trend der Erledigung der Tasks in einem Sprint. Die X-Achse repräsentiert typischerweise die Tage in einem Sprint, während die Y-Achse die offenen Aufwände darstellt (üblicherweise entweder in Nettoarbeitszeit oder in Story-Points).
BVT Akronym für Build-Verifizierungstest.
C
Capability Maturity Model Integration Ein Rahmenwerk, das Schlüsselelemente einer effektiven Softwareentwicklung und -wartung beschreibt. Capability Maturity Model Integration deckt Best Practice-Ansätze für die Planung, das Engineering und das Management einer Softwareentwicklung und -wartung ab.
Capture/Replay-Werkzeug Siehe Mitschnittwerkzeug.
CASE Abkürzung für Computer Aided Software Engineering.
CAST Abkürzung für Computer Aided Software Testing.
Change Control Board Siehe Konfigurationskontrollboard.
Charta Siehe Test-Charta.
Checklisten-basiertes Testen Ein erfahrungsbasiertes Testentwurfsverfahren, bei dem der erfahrene Tester eine Liste von Kontrollpunkten nutzt, die beachtet, überprüft oder in Erinnerung gerufen werden müssen, oder eine Menge von Regeln oder Kriterien gegen die ein Produkt verifiziert werden muss. Siehe auch erfahrungsbasiertes Testen.
Chow´s Überdeckungsmetrik Siehe N-Switch-Überdeckung.
Clear-Box-Test Siehe White-Box-Test.
CLI Akronym für Command-Line Interface (Kommandozeilenschnittstelle).
CLI-Testen Testen durch Senden von Kommandos an eine Komponente oder ein System über die Nutzung einer speziell dafür vorgesehenen Kommandozeilenschnittstelle.
CMMI Akronym für Capability Maturity Model Integration.
Co-abhängiges Verhalten Exzessive emotionale oder psychologische Abhängigkeit von einer anderen Person, speziell durch den Versuch, das derzeitige (ungewünschte) Verhalten dieser Person zu ändern während man sie unterstützt, das derzeitige Verhalten fortzusetzen. Beispiel: Ein Tester beschwert sich über die verspätete Übergabe der Software, ist aber eigentlich ganz froh darüber, weil er somit als Held durch Zusatzarbeit den Termin noch retten kann.
Code Anweisungen und Datendefinitionen einer Programmiersprache (Quellcode) oder wie sie durch einen Assemblierer, Compiler oder einen anderen Übersetzer erzeugt werden. [IEEE 610]
codebasierter Test Siehe White-Box-Testentwurfsverfahren.
Codeüberdeckung Eine Analysemethode, die bestimmt, welche Teile einer Software durch eine Testsuite ausgeführt wurden und welche Teile nicht ausgeführt wurden, z.B. Anweisungs-, Entscheidungs– und Bedingungsüberdeckung.
Compiler Ein Softwarewerkzeug, welches ein Programm, geschrieben in einer höheren Programmiersprache, in eine Maschinensprache transformiert. [IEEE 610]
Computer-Forensik Das Vorgehen zur Feststellung, wie ein Sicherheitsangriff gelingen konnte, und die Bewertung des verursachten Schadens.
Critical Testing Processes Ein inhaltsbasiertes Modell für Testprozesse, das auf zwölf kritischen Prozessen aufgebaut ist. Diese enthalten gut sichtbare Prozesse, durch welche Mitarbeiter und das Management die Kompetenz und die erfolgskritischen Prozesse bewerten können, deren Leistungsfähigkeit den Gewinn und den Ruf des Unternehmens beeinflusst.

Siehe auch Inhaltsbasiertes Modell.

CTP Akronym für Critical Testing Processes .
D
Daily Build Prozess in der Entwicklung, bei dem ein vollständiges System täglich (oftmals über Nacht) neu übersetzt und gebunden wird, damit jederzeit ein konsistentes System einschließlich seiner letzten Änderungen verfügbar ist.
Dashboard Eine Darstellung der dynamischen Messung der operationalen Leistung von Unternehmen oder Aktivitäten. Dazu werden visuelle Darstellungen der Metriken mittels Zeiger– oder Zählerinstrumenten genutzt, die an das Amaturenbrett eines Autos erinnern, so dass der Effekt von Ereignissen oder Aktivitäten leicht verstanden und zu operationalen Zielen in Beziehung gesetzt werden kann. Siehe auch Unternehmens-Dashboard, Scorecard.
Datenbankintegritätstest Testen der Methoden und Prozesse für den Zugriff und die Administration der Datenbank. Dies umfasst die Prüfung, dass Zugriffsmethoden, Prozesse und Integritätsregeln wie erwartet funktionieren und durch einen Datenbankzugriff Daten nicht beschädigt, unerwartet gelöscht, geändert oder neu angelegt werden.
Datendefinition Eine ausführbare Anweisung, bei der einer Variablen ein Wert zugewiesen wird.
Datenfluss Eine abstrakte Darstellung der Abfolge von Zustandsänderungen eines Datenobjekts, bei der die Zustände des Objekts sind: Definition/Neuanlage, Verwendung oder Löschung. [Beizer]
Datenflussanalyse Statisches Analyseverfahren, das auf der Definition und Verwendung von Variablen basiert und fehlerhafte Zugriffssequenzen auf die Variablen des Testobjekts nachweist.
Datenflusstest Ein White-Box-Testentwurfsverfahren, bei dem Testfälle entworfen werden, um Definition-Verwendungspaare von Variablen auszuführen.
Datenflussüberdeckung Der Anteil der Definition-Verwendungspaare, die durch eine Testsuite ausgeführt werden.
datengetriebenes Testen Ein skriptbasiertes Verfahren, bei dem die Testeingaben und vorausgesagten Ergebnisse in einer (Kalkulations-) Tabelle gespeichert werden, sodass ein Steuerungsskript alle Tests in der Tabelle ausführen kann. Datengetriebenes Testen wird oft unterstützend beim Einsatz von Testausführungswerkzeugen wie Mitschnittwerkzeugen verwendet. [Fewster und Graham]

Siehe auch schlüsselwortgetriebener Test.

Datenmaskierung Transformation von Daten, die es den Menschen schwer macht, die Originaldaten zu erkennen.
Datenqualität Eine Dateneigenschaft, welche die Richtigkeit bezüglich vorgegebener Kriterien angibt, z.B. Geschäftserwartungen, Anforderungen an Datenintegrität oder Datenkonsistenz.
Datenschutz Der Schutz personenbezogener oder in sonstiger Weise sensibler Information vor unerwünschter Offenlegung.
DDP Akronym für Fehlerfindungsrate.
dd-Pfad Ein Pfad zwischen zwei Entscheidungen eines Algorithmus, bzw. zwischen zwei Entscheidungsknoten eines zugehörigen Graphen, der keine weiteren Entscheidungen beinhaltet.

Siehe auch Pfad.

Debugger Siehe Debugging-Werkzeug.
Debugging Tätigkeit des Lokalisierens/Identifizierens, Analysierens und Entfernens der Ursachen von Fehlerwirkungen in der Software.
Debugging-Werkzeug Ein Entwicklungswerkzeug, das benutzt wird, um Fehlerwirkungen zu reproduzieren und Zustände von Programmen und ihre korrespondierenden Fehlerzustände zu untersuchen. Mit einem Debugger können Entwickler ein Programm Schritt für Schritt ausführen, an einer beliebigen Stelle anhalten und den Wert von Variablen setzen bzw. sich den aktuellen Wert anzeigen lassen.
Defekt-Taxonomie Siehe Fehlertaxonomie.
Definition-Verwendungspaar Die Verknüpfung einer Definition einer Variablen (im Sinne einer Wertzuweisung) mit einer nachfolgenden Verwendung dieser Variablen in der dynamischen Ausführung. Variablenverwendungen können in Berechnungen sein (z.B. Multiplikation) oder die Ausführung von Pfaden steuern (prädikative Verwendung).
Demingkreis Ein iterativer Problemlösungsprozess, der aus vier Phasen besteht (planen, ausführen, überprüfen, umsetzen) und typischerweise in der Prozessverbesserung genutzt wird. [Nach Deming]
Diagnose (IDEAL) Die Phase im IDEAL-Modell, in welcher der derzeitige Stand bestimmt wird (in Relation zum angestrebten Stand). Die Diagnose-Phase enthält die Aktivitäten: derzeitigen und angestrebten Stand beschreiben und Empfehlungen entwickeln. Siehe auch IDEAL.
Dienstblockade Ein Sicherheitsangriff mit dem Ziel, das System mit Anfragen so zu überlasten, dass es berechtigte Anfragen nicht mehr bedienen kann.
DMZ Akronym für Demilitarized zone (entmilitarisierte Zone).
Dokumentationstest Testen der Qualität der Dokumentation, z.B. des Benutzer- oder Installationshandbuchs.
DOS Akronym für Denial of Service (Dienstblockade).
Dreipunktschätzung Ein Verfahren zur Schätzung des Testens, das für das betrachtete Thema drei Schätzwerte jeweils für den besten Fall, den schlimmsten Fall und den höchstwahrscheinlichsten Fall benutzt, um den Grad der Gewissheit des Schätzungsergebnisses zu bestimmen.
dynamische Analyse Prozess der Bewertung des Verhaltens (z.B. Speichereffizienz, CPU-Nutzung) eines Systems oder einer Komponente während der Nutzung. [Nach IEEE 610]
dynamischer Test Prüfung des Testobjekts durch Ausführung auf einem Rechner.
dynamischer Vergleich Vergleich der tatsächlichen mit den vorausgesagten Ergebnissen, ausgeführt zur Laufzeit, z.B. durch ein Testausführungswerkzeug.
dynamisches Analysewerkzeug Ein Werkzeug, das zur Ausführungszeit Informationen über den Programmcode bereitstellt. Solche Werkzeuge werden meistens genutzt, um undefinierte Zeiger zu identifizieren, Zeigerberechnungen zu prüfen und die Speicherzuteilung, -verwendung und -freigabe zu überwachen und Speicherengpässe zu kennzeichnen.
E
Effektivität (1) Die Fähigkeit, ein beabsichtigtes Ergebnis zu erzielen.

(2) Der Umfang in welchem richtige und vollständige Ziele erreicht werden. [DIN ISO 9241-11]

Siehe auch Effizienz.

Effizienz 1. Die Fähigkeit eines Softwareproduktes, in Relation zu den eingesetzten Mitteln und festgelegten Bedingungen, angemessene Performanz zu erzielen.

2. Die Fähigkeit eines Prozesses, in Relation zu den eingesetzten Mitteln, ein beabsichtigtes Ergebnis zu erbringen.

3. Eingesetzte Mittel im Verhältnis zu dem Ausmaß, in dem Benutzer spezifische Ziele erreichen. [DIN ISO 9241-11]

Siehe auch Effektivität.

Effizienztest Ein Test, mit dem die Effizienz eines Softwareprodukts ermittelt wird.
EFQM Akronym für European Foundation for Quality Management Exzellenzmodell.
Eingabe Eine Variable, die durch eine Komponente eingelesen wird (unabhängig davon, ob sie innerhalb oder außerhalb der Komponente gespeichert wird).
Eingabewert Eine Instanz einer Eingabe. Siehe auch Eingabe.
Eingabewertebereich Die Menge der Werte, aus der gültige Eingabewerte ausgewählt werden können.

Siehe auch Wertebereich.

Eingangskriterien Die Menge der generischen und spezifischen Bedingungen, die es in einem Prozess ermöglichen, mit einer bestimmten Aktivität fortzuschreiten, z.B. mit einer Testphase. Der Zweck von Eingangskriterien ist, die Durchführung der Aktivität zu verhindern, wenn dafür ein höherer Mehraufwand benötigt (verschwendet) wird als für die Schaffung der Eingangskriterien. [Gilb und Graham]
eingebettete iterative Entwicklung Ein Entwicklungslebenszyklus-Untermodell, das innerhalb eines übergeordneten sequenziellen Modells einen iterativen Ansatz beim detaillierten Design, bei der Kodierung und beim Testen nutzt. In diesem Falle werden die übergeordneten Designdokumente für das gesamte Projekt erstellt und genehmigt, aber das tatsächliche detaillierte Design, die Codierung und das Testen werden in Iterationen durchgeführt.
eingefrorene Testbasis Ein Testbasisdokument, das nur durch einen formalen Änderungsprozess angepasst werden darf.

Siehe auch Referenzkonfiguration.

Eintrittspunkt Eine ausführbare Anweisung oder ein Prozessschritt, an dem ein gegebener Prozess beginnen soll.
Eintrittswahrscheinlichkeit des Risikos Die geschätzte Wahrscheinlichkeit dafür, dass ein Risiko eintritt.
elementarer Vergleichstest Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle im Hinblick auf Kombinationen von Eingaben nach dem Konzept der modifizierten Bedingungs-/Entscheidungsüberdeckung entworfen werden. [TMap]
E-Mail-Einfangen Vorgehen zum Erwerb von E-Mail-Adresslisten, um Massen-E-Mails an diese zu verschicken.
emotionale Intelligenz Die Fähigkeit und Fertigkeit, eigene und fremde Gefühle sowie Gefühlszustände von ganzen Gruppen zu erkennen, zu bewerten und mit ihnen umzugehen.
EMTE Akronym für Equivalent Manual Test Effort (äquivalenter maueller Testaufwand).
Emulator Ein Gerät, Computerprogramm oder System, das die gleichen Eingaben akzeptiert und die gleichen Ausgaben wie ein gegebenes System erzeugt. [IEEE 610]

Siehe auch Simulator.

Endekriterien Die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden. Endekriterien für eine Aktivität verhindern es, dass die Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind. Endekriterien werden in Berichten referenziert und zur Planung der Beendigung des Testens verwendet. [Nach Gilb und Graham]
entgangener Fehler Ein Fehlerzustand, der in einer früheren Teststufe nicht entdeckt wurde, obwohl jene Teststufe solche Fehler aufdecken sollte.

Siehe auch Fehlerfindungsrate.

entmilitarisierte Zone Ein physikalisches oder logisches Teil-Netzwerk, das die nach außen gerichteten Dienste eines Unternehmens enthält und einem nicht vertrauenswürdigen Netzwerk, in der Regel dem Internet, zugänglich macht.

Siehe auch Netzwerkzone.

Entscheidung Eine Stelle in einem Programm, an der der Kontrollfluss in zwei oder mehrere alternative Wege verzweigen kann. Ein Knoten mit zwei oder mehreren ausgehenden Kanten.
Entscheidungsausgang Das Ergebnis einer Entscheidung, das den einzuschlagenden Weg im Kontrollfluss bestimmt.
Entscheidungstabelle Eine Tabelle von Regeln, die jeweils aus einer Kombination von Bedingungen (z.B. Eingaben und/oder Auslösern) und den dazugehörigen Aktionen (z.B. Ausgaben und/oder Wirkungen) bestehen. Entscheidungstabellen können zum Entwurf von Testfällen verwendet werden.
Entscheidungstabellentest Ein Black-Box-Testentwurfsverfahren, bei dem Testfälle im Hinblick auf die Ausführung von Regeln einer Entscheidungstabelle entworfen werden. [Egler63]

Siehe auch Entscheidungstabelle.

Entscheidungstest Ein White-Box-Testentwurfsverfahren, bei dem Testfälle im Hinblick auf die Überdeckung der Entscheidungsausgänge entworfen werden.
Entscheidungsüberdeckung Der Anteil an Entscheidungsausgängen, die durch eine Testsuite geprüft wurden. 100% Entscheidungsüberdeckung schließt sowohl 100% Zweigüberdeckung als auch 100% Anweisungsüberdeckung ein.
Entwicklungstest Formelles oder informelles Testen, das während der Entwicklung einer Komponente/eines Systems durchgeführt wird, gewöhnlich durch Entwickler in der Entwicklungsumgebung. [Nach IEEE 610] Siehe auch Komponententest.
entwurfsbasierter Test Ein Ansatz zum Testen, bei dem Testfälle auf der Basis der Architektur und/oder des detaillierten Entwurfs einer Komponente oder eines Systems entworfen werden, wie z.B. Test der Schnittstellen zwischen Komponenenten oder Systemen sein.
erfahrungsbasiertes Testen Testen, das auf der Erfahrung, dem Wissen und der Intuition des Testers basiert.
erfahrungsbasiertes Testentwurfsverfahren Vorgehensweise, mit der Testfälle aus den Erfahrungen, dem Wissen und der Intuition der Tester abgeleitet und/oder ausgewählt werden.
erfahrungsbasiertes Verfahren Siehe erfahrungsbasiertes Testentwurfsverfahren.
erfolgreich bestandener Test Siehe bestanden.
Ergebnis Das Ergebnis der Ausführung eines Tests. Dazu gehören die Bildschirmausgaben, Datenänderungen, Berichte und versendete Mitteilungen.

Siehe auch Istergebnis, vorausgesagtes Ergebnis.

Erkundung Die Erforschung eines Zielgebietes mit der Absicht, nützliche Information für einen Angriff zu gewinnen.
Erlernbarkeit Die Fähigkeit eines Softwareprodukts, einem Benutzer das Erlernen der Anwendung leicht zu machen. [ISO 9126]

Siehe auch Gebrauchstauglichkeit.

erschöpfender Test Testansatz, bei dem die Testsuite alle Kombinationen von Eingabewerten und Vorbedingungen umfasst.
erwartetes Verhalten Siehe vorausgesagtes Ergebnis.
Etablieren (IDEAL) Die Phase im IDEAL-Modell, in der im Detail geplant wird, wie das Unternehmen seine Ziele erreichen will. Die Etablierungsphase besteht aus den Aktivitäten: Prioritäten setzen, Vorgehen entwickeln und Aktionen planen. Siehe auch IDEAL.
ethischer Hacker Ein Sicherheitstester, der Hacker-Verfahren benutzt.
European Foundation for Quality Management Exzellenzmodell Ein unverbindliches Rahmenwerk für Qualitätsmanagementsysteme von Unternehmen, welches durch die European Foundation for Quality Management (EFQM) definiert und verwaltet wird. Es basiert auf den fünf Befähigern (die das abdecken, was eine Organisation tut) und den vier Ergebniskriterien (die das abdecken, was eine Organisation erreicht).
Experten-Review der Gebrauchstauglichkeit Ein informelles Review der Gebrauchstauglichkeit, bei dem die Gutachter Experten sind. Die Gutachter können Gebrauchstauglichkeitsexperten oder Fachexperten oder beides sein. Siehe auch informelles Review.
exploratives Testen Ein informelles Testentwurfsverfahren, bei dem der Tester den Entwurf der Tests aktiv steuert, indem er testet und die Informationen, die er während des Testens erhält, zum Entwurf neuer besserer Tests verwendet. [Nach Bach]
Extreme Programming Eine Softwareentwicklungsmethode, die innerhalb der agilen Softwareentwicklung angewandt wird. Die Kernpraktiken sind das Programmieren in Paaren, umfangreiche Code-Reviews, Unit-Tests für den gesamten Code, sowie Einfachheit und Klarheit des Codes.

Siehe auch agile Softwareentwicklung.

F
falsch negatives Ergebnis Ein Ergebnis, das einen Fehlerzustand nicht anzeigt, obwohl der Fehlerzustand im Testobjekt enthalten ist.
falsch positives Ergebnis Ein Testergebnis, das einen Fehlerzustand anzeigt, obwohl der Fehlerzustand nicht im Testobjekt enthalten ist.
Feature Ein Attribut einer Komponente oder eines Systems, spezifiziert oder abgeleitet aus der Anforderungsspezifikation (z.B. Zuverlässigkeit, Gebrauchstauglichkeit oder Entwurfsrestriktionen). [Nach IEEE 1008]
Feature-getriebene Entwicklung Ein iterativ inkrementeller Softwareentwicklungsprozess, der mit Blick auf die Funktionalitäten mit Kundenwert (Features) betrieben wird. Feature-getriebene Entwicklung wird meist bei agiler Softwareentwicklung genutzt. Siehe auch agile Softwareentwicklung.
Fehler- und Abweichungsbericht Ein Dokument, das ein Ereignis auflistet, welches während des Testens aufgetreten ist und untersucht werden muss. [Nach IEEE 829]
Fehler- und Abweichungsmanagement Der Prozess der Erkennung, Untersuchung, Maßnahmenergreifung und Behebung von Fehlerzuständen und Abweichungen. Dazu gehört Protokollierung, Klassifizierung und Analyse der Auswirkung von Fehlerzuständen und Abweichungen. [Nach IEEE 1044]
Fehler- und Abweichungsmanagementwerkzeug Ein Werkzeug zur Aufzeichnung und Statusverfolgung von Fehlerzuständen und Abweichungen während des Testens. Es enthält oft eine Workflow-Komponente, um die Sammlung, Korrektur und den Fehlernachtest von Vorfällen/Abweichungen verfolgen, steuern und über Berichtsfunktionen darstellen zu können. Siehe auch Fehlermanagementwerkzeug.
Fehlerangriff Gezielter Versuch, ein bestimmtes Qualitätsmerkmal eines Testobjekts zu bewerten, indem versucht wird, spezifische Fehlerwirkungen zu provozieren. Meistens liegt der Schwerpunkt auf Zuverlässigleit oder Sicherheit (im Sinne von Zugriffsschutz).

Siehe auch Negativtest, Sicherheitsangriff

Fehlerart Ein Element in der Fehlertaxonomie. Fehlertaxonomien können nach verschiedenen Aspekten bestimmt werden, unter Anderem nach: Phase oder Entwicklungsaktivität, in der der Fehlerzustand entstanden ist, z.B. ein Spezifikationsfehler oder ein Kodierfehler, Charakterisierung des Fehlers, z.B. ein „um-eins-daneben“ Fehler, Unkorrektheit, z.B. ein falscher Relationsoperator, ein Syntaxfehler in der Programmiersprache oder eine ungültige Annahme, Performanzprobleme, z.B. übermäßige Ausführungszeit oder unzureichende Verfügbarkeit.
Fehlerauswirkung Das physikalische oder funktionale Erscheinungsbild eines Fehlers. So kann eine Fehlerauswirkung zu einer langsamen Ausführung, zu inkorrekten Ausgaben oder zu einem Abbruch der Ausführung führen. [IEEE 610]
fehlerbasiertes Testentwurfsverfahren Ein Testentwurfsverfahren, bei dem die Testfälle im Hinblick auf die Aufdeckung von bestimmten Fehlerarten entworfen werden, ausgehend von Kenntnissen über diese Fehlerarten. Siehe auch Fehlertaxonomie.
fehlerbasiertes Verfahren Siehe fehlerbasiertes Testentwurfsverfahren.
Fehlerbaum-Analyse Ein Verfahren zur Ursachenanalyse von Fehlerzuständen. Das Verfahren stellt anschaulich dar, wie logische Zusammenhänge von Fehlerzuständen, Fehlhandlungen, und externen Ereignissen zu spezifischen Fehlerwirkungen führen können.
Fehlerbericht Ein Dokument, das über einen Fehlerzustand einer Komponente oder eines Systems berichtet, der dazu führen kann, dass System oder Komponente die geforderte Funktion nicht erbringt. [Nach IEEE 829]
Fehlerdichte Die Anzahl der Fehlerzustände, die in einer Komponente oder einem System identifiziert wurden, dividiert durch die Größe der Komponente oder des Systems. Die Größe wird mit bekannten Maßen ausgedrückt, z. B. über die Anzahl Codezeilen oder über Funktionspunkte.
Fehlerdichte des Automatisierungscodes Fehlerdichte einer Komponente des Testautomatisierungscodes.
Fehlereindämmung innerhalb der Phase Der Anteil der Fehlerzustände, die in derselben Phase des Softwareprozesses behoben werden, in welcher diese verursacht wurden.
Fehlereinfügen Das absichtliche Einfügen von Fehlern in ein System mit dem Zweck, herauszufinden, ob das System den Fehler entdecken und sich möglicherweise wiederherstellen kann. Fehlereinfügung beabsichtigt die Imitation von Fehlern wie sie im produktiven Einsatz vorkommen können. Siehe auch Fehlertoleranz.
Fehlereinpflanzung Das absichtliche Hinzufügen von bekannten Fehlerzuständen zu einer Komponente oder einem System, um aus dem Anteil der aufgedeckten bekannten Fehlerzustände eine Schätzung über die verbliebenen Fehlerzustände machen zu können . Fehlereinpflanzung ist i.d.R. Teil des Entwicklungstests und kann auf jeder Teststufe (Komponente, Integration, System) durchgeführt werden. [Nach IEEE 610]
Fehlereinpflanzungswerkzeug Ein Werkzeug zur Einpflanzung (d.h. zum beabsichtigten Einfügen) von Fehlerzuständen in eine Komponente oder ein System.
Fehlerfindungsrate Anzahl der Fehlerzustände, die in einer Teststufe gefunden wurden, dividiert durch die Gesamtzahl der Fehlerzustände, die in dieser Teststufe und danach mit jeglichen Mitteln gefunden wurden.
Fehlerkategorie siehe Fehlerart.
Fehlermanagement Prozess der Erkennung, der Analyse, der Bearbeitung und des Abschlusses eines aufgedeckten Fehlerzustands. Er umfasst Aufzeichnung, Klassifizierung und die Identifikation der Auswirkungen. [Nach IEEE 1044]
Fehlermanagement-Ausschuss Eine bereichsübergreifende Gruppe von Stakeholdern, die gemeldete Fehler managen, von ihrer ersten Entdeckung bis zur endgültigen Lösung (ihre Behebung, Zurückstellung oder Stornierung). In manchen Fällen ist es dasselbe Team wie das Konfigurationskontrollboard.
Fehlermanagementwerkzeug Ein Werkzeug zur Aufzeichnung und Statusverfolgung von Fehlerzuständen und Änderungen. Es enthält oft eine Workflow-Komponente, um die Zuweisung, Korrektur und den Fehlernachtest von Fehlern verfolgen, steuern und über Berichtsfunktionen darstellen zu können. Siehe auch Fehler- und Abweichungsmanagementwerkzeug.
Fehlermaskierung Ein Umstand, bei dem ein Fehlerzustand die Aufdeckung eines anderen verhindert. [Nach IEEE 610]
Fehler-Möglichkeits- und Einfluss-Analyse Ein systematischer Ansatz zur Risikoidentifikation sowie zur Analyse möglicher Fehler(aus)wirkungen und zu ihrer Vermeidung. Siehe auch Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse.
Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse Eine Erweiterung von FMEA, die über die FMEA hinaus eine Kritikalitätsanalyse enthält, die die Wahrscheinlichkeit der Fehlermöglichkeiten der Schwere ihrer Wirkung gegenüberstellt. Das Ergebnis hebt die Fehlermöglichkeiten mit relativ hoher Wahrscheinlichkeit und ernsten Auswirkung hervor, um den Aufwand zur Abhilfe gezielt dort zu erbringen, wo der größte Nutzen erzielt wird.

Siehe auch Fehler-Möglichkeits- und Einfluss-Analyse.

Fehlernachtest Die Wiederholung aller Testfälle, die vor der Fehlerkorrektur eine Fehlerwirkung erzeugt haben. Sie dient der Überprüfung, ob die Korrektur des ursächlichen Fehlerzustands erfolgreich war.
Fehlerschweregrad Der Grad der Auswirkungen, den ein Fehlerzustand auf Entwicklung oder Betrieb einer Komponente oder eines Systems hat. [Nach IEEE 610]
Fehlertaxonomie Eine systematische Liste von Fehlerarten mit ihrer hierarchischen Gliederung in Fehlerkategorien. Sie dient der Klassifikation von Fehlerzuständen.
Fehlertoleranz Die Fähigkeit eines Softwareprodukts, ein spezifiziertes Leistungsniveau auch bei Fehlfunktionen oder trotz Fehleingaben (z. B. falsche Bedienung) aufrecht zu erhalten. [ISO 9126]

Siehe auch Zuverlässigkeit, Robustheit.

Fehler-Triage-Ausschuss Siehe Fehlermanagement-Ausschuss.
Fehlerverfolgungswerkzeug Siehe Fehlermanagementwerkzeug.
Fehlerwirkung Abweichung einer Komponente/eines Systems von der erwarteten Lieferung, Leistung oder dem Ergebnis. [Nach Fenton]
Fehlerzustand Defekt (innerer Fehlerzustand) in einer Komponente oder einem System, der eine geforderte Funktion des Produkts beeinträchtigen kann, z.B. inkorrekte Anweisung oder Datendefinition. Ein Fehlerzustand, der zur Laufzeit angetroffen wird, kann eine Fehlerwirkung einer Komponente oder Systems verursachen.
Fehlhandlung Die menschliche Handlung, die zu einem falschen Ergebnis führt. [Nach IEEE 610]
Fehlschlag Ein Test schlägt fehl, wenn das aktuelle Ergebnis nicht mit dem vorausgesagten Ergebnis übereinstimmt.
Feldtest Siehe Beta-Test.
Fertigungsabnahmetest Abnahmetest, der von Mitarbeitern der Lieferantenorganisation am Standort der Produktentwicklung durchgeführt wird, um festzustellen, ob eine Komponente oder ein System die Anforderungen erfüllt, normalerweise Hardware als auch Software beinhaltend.
Firewall Eine Komponente oder eine Gruppe von Komponenten, welche die ein- und ausgehende Netzwerkkommunikation anhand von vorgegebenen Sicherheitsregeln kontrolliert.
Fischgrätendiagramm Siehe Ursache-Wirkungs-Diagramm.
FMEA Akronym für Fehler-Möglichkeits- und Einfluss-Analyse.
FMECA Akronym für Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse.
formales Review Eine Reviewtechnik, die durch ein dokumentiertes Vorgehen und Anforderungen charakterisiert ist, z.B. eine Inspektion.
Formative Evaluierung Eine Art der Bewertung, die dazu dient, die Qualität einer Komponente oder eines Systems zu verbessern, inbesondere während ihres bzw. seines Entwurfs. Siehe auch summative Evaluierung.
FPA Akronym für Funktionspunktanalyse.
funktionale Anforderung Anforderung, die ein funktionales Verhalten spezifiziert, die ein System oder eine Systemkomponente ausführen können muss. [IEEE 610]

Siehe auch Funktionalität.

funktionale Integration Ein Ansatz zur Integration, bei dem Komponenten oder Systeme mit der Absicht kombiniert werden, eine Basisfunktionalität früh bereit zu stellen. Siehe auch Integrationstest.
funktionale Sicherheit Die Fähigkeit eines Softwareprodukts, akzeptable Stufen des Risikos der Gefährdung von Menschen, von Unternehmen, von Software, von Vermögen oder von der Umwelt in einem spezifizierten Fall der Anwendung zu erreichen. [ISO 9126]
funktionales Testen Testen, das auf der Analyse der funktionalen Spezifikation einer Komponente oder eines Systems basiert.

Siehe auch Black-Box-Test.

funktionales Testentwurfsverfahren Ein Verfahren zur Herleitung und Auswahl von Testfällen, das auf der Analyse der funktionalen Spezifikation einer Softwarekomponente oder eines Softwaresystems basiert, ohne Bezug auf dessen innere Struktur. Siehe auch Black-Box-Testentwurfsverfahren.
Funktionalität Die Fähigkeit eines Softwareprodukts beim Einsatz unter spezifizierten Bedingungen Funktionen zu liefern, die festgelegte und vorausgesetzte Erfordernisse erfüllen. [ISO 9126]
Funktionalitätstest Testen, um die Funktionalität eines Softwareprodukts zu bestimmen.
Funktionspunktanalyse Eine Methode, die darauf abzielt, den Umfang der Funktionalität eines Informationssystems zu messen. Die Messung ist unabhängig von der Technologie. Sie kann als Basis zur Messung der Produktivität verwendet werden, zur Schätzung der benötigten Ressourcen und zur Projektsteuerung.
Fuzz-Testen Ein Testverfahren zur Entdeckung von Sicherheitsschwachstellen durch die massenhafte Eingabe von zufälligen Daten (Fuzz genannt) in die Komponente oder das System.
G
Gebrauchstauglichkeit Ausmaß, in dem ein Softwareprodukt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um festgelegte Ziele effektiv, effizient und zufriedenstellend zu erreichen. [DIN ISO 9241-11]
Gebrauchstauglichkeitsanforderung Eine Anforderung an die Gebrauchstauglichkeit einer Komponente oder eines Systems.
Gebrauchstauglichkeitstest Testen mit dem Ziel herauszufinden inwieweit das System durch spezifizierte Benutzer in einem bestimmten Kontext mit Effektivität, Effizienz und Zufriedenheit genutzt werden kann.
Gebrauchstauglichkeitstest mit lautem Denken Ein Verfahren des Gebrauchstauglichkeitstests, bei dem die Teilnehmer ihre Gedanken mit dem Modearator und den Beobachtern teilen, indem sie laut denken, während sie Gebrauchstauglichkeitstestaufgaben lösen. Lautes Denken hilft dabei, die Gedanken und den Wortschatz der Testteilnehmer zu verstehen.
Gebrauchstauglichkeitstestaufgabe Eine Aktivität bei der Durchführung des Gebrauchstauglichkeitstests, die innerhalb eines vorgegebenen Zeitraums oder zu einem Termin fertig gestellt werden muss, um auf die vom Moderator gesetzten Ziele hinzuarbeiten.
Gebrauchstauglichkeitstestsitzung Eine Testsitzung im Gebrauchstauglichkeitstest, bei welcher ein Gebrauchstauglichkeitstestteilnehmer unter Moderation und unter Beobachtung Tests ausführt.
Gebrauchstauglichkeitstestskript Ein Dokument, das eine Folge von Aktionen zur Ausführung eines Gebrauchstauglichkeitstests festlegt. Es wird vom Moderator genutzt, um die Einweisung, die Interviews vor der Sitzung, die Gebrauchstauglichkeitstestaufgaben und die Interviews nach der Sitzung zu verfolgen. Siehe auch Testablaufspezifikation.
Gebrauchstauglichkeitstestteilnehmer Ein repräsentativer Benutzer, der in einem Gebrauchstauglichkeitstest typische Aufgaben löst.
Gefährdung durch Betriebsangehörige Eine Gefährdung der Sicherheit, die innerhalb eines Unternehmens entsteht, oft durch einen berechtigten Systembenutzer.
Gefährdungsanalyse Ein Verfahren zur Beschreibung der Risikobestandteile. Entsprechend dem Ergebnis der Gefährlichkeitsanalyse sind für das System geeignete Entwicklungs- und Testverfahren einzusetzen. Siehe auch Risikoanalyse.
Genauigkeit Die Fähigkeit eines Softwareprodukts, die richtigen oder vereinbarten Ergebnisse oder Wirkungen mit dem benötigten Grad an Genauigkeit zu liefern. [ISO 9126]

Siehe auch Funktionalität.

Genauigkeitstest Testen, um die Genauigkeit eines Softwareprodukts zu bestimmen.

Siehe auch Genauigkeit.

Generische Testautomatisierungsarchitektur Eine Darstellung der Schichten, Komponenten und Schnittstellen einer Testautomatisierungsarchitektur, die einen strukturierten und modularen Ansatz ermöglicht, um Testautomatisierung umzusetzen.
geschäftsprozessbasierter Test Ein Ansatz zum Testen, bei dem der Testentwurf auf Beschreibungen und/oder auf der Kenntnis von Geschäftsprozessen basiert.
Glass-Box-Test Siehe White-Box-Test.
Goal Question Metric Ein Ansatz zur Messung von Software, das ein dreistufiges Modell verwendet: Die konzeptionelle Ebene (Goal), die operationelle Ebene (Question) und die quantitative Ebene (Metric).
GQM Akronym für Goal Question Metric.
Grad der Intrusion Grad zu dem ein Testobjekt geändert wird, um es in Bezug auf seine Testbarkeit anzupassen.
Grenzwert Ein Ein- oder Ausgabewert, der am Rand einer Äquivalenzklasse liegt oder im kleinstmöglichen inkrementellen Abstand auf der einen oder anderen Seite vom Rand, z.B. der kleinste und der größte Wert eines Bereichs.
Grenzwertanalyse Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle unter Nutzung von Grenzwerten entworfen werden.

Siehe auch Grenzwert.

Grenzwertüberdeckung Der Anteil der Grenzwerte, die durch eine Testsuite ausgeführt werden.
Grundursache Die Ursache eines Fehlerzustands. Wenn man sie behebt, dann wird das Vorkommen der Fehlerart reduziert oder eliminiert. [CMMI]
Grundursachenanalyse Eine Analysetechnik, die die Grundursachen von Fehlerzuständen identifizieren soll. Dadurch, dass man die Korrekturmaßnahmen auf Grundursachen ausrichtet, soll die Wahrscheinlichkeit des Wiederauftretens eines Fehlerzustands minimiert werden.
GUI Abkürzung von Graphical User Interface (graphische Benutzungsoberfläche).
GUI Testen Testen durch Interaktion mit der Komponente oder dem System über die grafische Benutzungsoberfläche.
Gutachter Eine Person, die im Rahmen eines Review Anomalien in einem Produkt oder Projekt identifiziert und beschreibt. Gutachtern (auch Reviewer genannt) können unterschiedliche Sichtweisen und Rollen in einem Reviewprozess zugewiesen werden.
H
Hacker Eine Person oder ein Unternehmen, die bzw. das aktiv an Sicherheitsangriffen beteiligt ist, üblicherweise in böswilliger Absicht.

Siehe auch Angreifer.

Hardware-Software Integrationstest Testen mit der Absicht, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen Hardware- und Softwarekomponenten aufzudecken.
Hashfunktion Abbildung einer Zeichenkette variabler Länge auf einen normalerweise kürzeren Wert oder Schlüssel mit fester Länge. Die Hash-Werte werden üblicherweise in Tabellen- oder Datenbanksuchen verwendet. Kryptographische Hashfunktionen werden zur Sicherung von Daten gebraucht.
Hauptleistungsindikator Siehe Leistungsindikator.
herstellungsbasierte Qualität Eine Qualitätssicht, bei der Qualität dadurch gemessen wird, inwieweit Produkte oder Dienstleistungen dem beabsichtigten Entwurf entsprechen oder die spezifizierten Anforderungen erfüllen. Qualität entsteht durch den genutzten Prozess oder die genutzten Prozesse. [Nach Garvin] Siehe auch produktbasierte Qualität, transzendenzbasierte Qualität, benutzerbasierte Qualität, wertebasierte Qualität.
Heuristik Eine allgemein anerkannte Faustregel, die dabei hilft, ein Ziel zu erreichen.
heuristische Evaluierung Spezifische Form eines Reviews auf Gebrauchstauglichkeit, wobei die Gutachter die Benutzungsschnittstelle oder deren Design prüfen, um ihre Konformität zu anerkannten Grundsätzen der Ergonomie (den Heuristiken) zu bewerten.
horizontale Rückverfolgbarkeit Das Verfolgen von Anforderungen einer Teststufe über die Ebenen der Testdokumentation (z.B. Testkonzept, Testentwurfsspezifikation, Testfallspezifikation, Testablaufspezifikation oder Testskripte).
Hyperlink Ein Verweis in einer Webseite, der zu einer anderen Webseite oder einer anderen Stelle der Webseite führt.
Hyperlink Testwerkzeug Ein Werkzeug, das überprüft, ob es ungültige Verweise auf einer Webseite gibt.
I
IDEAL Ein Verbesserungsmodell für Unternehmen, das als Orientierungshilfe für das Aufsetzen, die Planung und die Durchführung von Verbesserungsmaßnahmen dient. Das IDEAL-Modell ist nach den fünf Phasen benannt, die es beschreibt: Initiating (Initiierung), Diagnosing (Diagnose), Establishing (Etablieren), Acting (Agieren) und Learning (aus Erfahrung lernen): Änderungen in den Ebenen der Entwicklungsdokumente, Testdokumente und Komponenten werden bewertet, bevor eine vorgegebene Änderung der spezifizierten Anforderungen implementiert wird.
Indikator Ein Maß, das benutzt werden kann, um ein anderes Maß abzuschätzen oder vorherzusagen. [ISO 14598]
Individualsoftware Software, die für einen einzelnen oder eine kleine Gruppe von Kunden oder Benutzer entwickelt wird. Das Gegenstück ist Standardsoftware.
Informationsschutz Maßnahmen, die Informationen und Informationssysteme durch die Sicherstellung ihrer Verfügbarkeit, Integrität, Echtheit, Vertraulichkeit und Zweifelsfreiheit schützen und verteidigen. Solche Maßnahmen umfassen Vorkehrungen zur Wiederherstellung eines Informationssystems durch Fähigkeiten zum Schutz, zur Aufdeckung und zur Reaktion auf Beeinträchtigungen. [NIST.IR.7298]
Informationssicherheit Der Schutz von Informationen und Informationssystemen vor unberechtigtem Zugriff, Nutzung, Offenlegung, Störung, Änderung oder Zerstörung, um deren Vertraulichkeit, Integrität und Verfügbarkeit zu gewährleisten. [NIST.IR.7298]
informelles Review Review ohne festgelegten formalen (dokumentierten) Ablauf.
Inhaltsbasiertes Modell Ein Prozessmodell, dass eine detaillierte Beschreibung von guten Engineering-Praktiken, wie z.B. Testpraktiken, liefert.
Inhaltsreferenzmodell Siehe inhaltsbasiertes Modell
Initiierung (IDEAL) Die Phase innerhalb des IDEAL-Modells, in der die grundlegende Arbeit für ein erfolgreiches Verbesserungsvorhaben gelegt wird. Die Initiierungsphase besteht aus den Aktivitäten: Zusammenhang herstellen, Sponsoring aufbauen und Infrastruktur errichten. Siehe auch IDEAL.
inkrementeller Test Test, bei dem die Komponenten oder Systeme integriert werden und einzeln oder in Gruppen getestet werden, bis alle Komponenten oder Systeme integriert und getestet sind.
inkrementelles Entwicklungsmodell Ein Entwicklungsmodell, bei dem ein größeres Projekt als Serie von Inkrementen entwickelt wird, von denen jedes einen Teil der gesamten Anforderungen an das Projekt umsetzt. Die Anforderungen werden dabei priorisiert und in entsprechender Reihenfolge in den Inkrementen ausgeliefert. In einigen, aber nicht in allen Versionen dieses Modells durchläuft jedes Inkrement ein „Mini-V-Modell“ mit den Phasen Entwurf, Implementierung und Testen.
Insourcing des Testens Testen durch Personen, die am selben Ort wie das Projektteam tätig sind, aber nicht Mitarbeiter des gleichen Unternehmens sind.
Inspektion Eine Reviewart, die Mängel durch die Sichtprüfung von Dokumenten finden soll. Solche Mängel können sein: Nicht-Einhaltung von Entwicklungsstandards, Nicht-Konformität gegenüber zugrundeliegenden Dokumenten. Es ist die formalste Reviewtechnik und sie folgt deshalb einem dokumentierten Vorgehen. [Nach IEEE 610, IEEE 1028]

Siehe auch Peer Review.

Inspektor Siehe Gutachter.
Installationsanleitung Als Installationsanleitung bezeichnet man die auf einem geeigneten Medium mitgelieferten Instruktionen, die durch den Installationsprozess führen. Das können sein: eine textuelle Beschreibung, eine ausführbare Installationsprozedur oder eine ähnliche Prozessbeschreibung.
Installationstest Testen der Installierbarkeit eines Softwareprodukts.

Siehe auch Portabilitätstest.

Installationswizard Als Installationswizard bezeichnet man auf einem geeigneten Medium ausgelieferte Software, die durch den Installationsprozess führt. Normalerweise wird damit die Installation ausgeführt. Während der Installation können Optionen gesetzt werden, und beim Abschluss der Installation werden Rückmeldungen über das Ergebnis ausgegeben.
Installierbarkeit Die Fähigkeit eines Softwareprodukts, in einer spezifizierten Umgebung installierbar zu sein. [ISO 9126]

Siehe auch Übertragbarkeit.

Instrumentierer Ein Softwarewerkzeug, das für die Instrumentierung verwendet wird.
Instrumentierung (Werkzeuggestütztes) Einfügen von Protokoll- oder Zählanweisungen in den Quell- und/oder Objektcode eines Testobjekts, um während der Ausführung Informationen über das Programmverhalten zu sammeln. Damit lässt sich beispielsweise die Codeüberdeckung messen.
Integration Der Prozess der Verknüpfung von Komponenten zu größeren Gruppen.
Integrationstest Testen mit dem Ziel, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten aufzudecken.

Siehe auch Komponentenintegrationstest, Systemintegrationstest.

Interoperabilität Die Fähigkeit eines Softwareprodukts, mit einer oder mehreren spezifizierten Komponenten zusammenzuwirken. [Nach ISO 9126]

Siehe auch Funktionalität.

Interoperabilitätstest Testen zur Bestimmung der Interoperabilität eines Softwareprodukts.

Siehe auch funktionales Testen, Interoperabilität.

intuitive Testfallermittlung Ein Testentwurfsverfahren, bei dem die Erfahrung und das Wissen der Tester genutzt werden, um vorherzusagen, welche Fehlerzustände in einer Komponente oder einem System aufgrund der Fehlhandlungen vorkommen könnten, und um Testfälle so abzuleiten, dass diese Fehlerzustände aufgedeckt werden.
Ishikawa-Diagramm Siehe Ursache-Wirkungs-Diagramm.
Isolationstest Testen von einzelnen Komponenten getrennt von anderen Komponenten ihrer Umgebung. Falls notwendig, werden Komponenten der Umgebung durch Treiber und Platzhalter simuliert.
Istergebnis Im Test beobachtetes/erzeugtes Verhalten einer Komponente oder eines Systems unter festgelegten Bedingungen.
iteratives Entwicklungsmodell Ein Entwicklungsmodell, bei dem das Projekt in eine größere Anzahl von Iterationen aufgeteilt wird. Eine Iteration ist ein vollständiger Entwicklungszyklus, der eine (interne oder externe) Freigabe eines ausführbaren Produkts ergibt. Dieses Produkt ist eine Teilmenge des zu entwickelnden Endprodukts. Die Entwicklung schreitet von Iteration zu Iteration bis zum Endprodukt hin fort.
K
Klassifikationsbaum Ein Baum, der Äquivalenzklassen hierarchisch gliedert, und der in der gleichnamigen Verfahren zum Entwurf von Testfällen genutzt wird. Siehe auch Klassifikationsbaumverfahren.
Klassifikationsbaumverfahren Ein Black-Box-Testentwurfsverfahren, bei dem die durch einen Klassifikationsbaums dargestellten Testfälle so entworfen werden, dass Kombinationen der Repräsentanten von Eingabe– und/oder Ausgabebereichen (Äquivalenzklassen) ausgeführt werden. [Grochtmann]
Koexistenz Die Fähigkeit eines Softwareprodukts, mit anderer Software in einer gemeinsamen Umgebung die gemeinsamen Ressourcen zu teilen. [ISO 9126]

Siehe auch Portabilitätstest.

kombinatorisches Testen Ein Verfahren zur Festlegung einer geeigneten Menge von Kombinationen aus Parameterwerten oder Parameterbereichen, um einen vorher festgelegten Überdeckungsgrad zu erreichen, wenn man ein Objekt mit mehreren Parametern testet und wenn die Werte dieser Parameter zu mehr Kombinationen führen als mit vertretbarem Aufwand in der zur Verfügung stehenden Zeit getestet werden kann. Siehe auch Klassifikationsbaumverfahren, n-weises Testen, paarweises Testen, Testen mit orthogonalen Arrays.
kommerzielle Standardsoftware Siehe Standardsoftware.
Kompabilitätstest Siehe Interoperabilitätstest.
Komparator Siehe Testkomparator.
Komplexität Schwierigkeitsgrad, mit dem der Entwurf und/oder die interne Struktur einer Komponente oder eines Systems zu verstehen, zu warten und zu prüfen ist. Siehe auch zyklomatische Komplexität.
Komponente (1) Kleinste Softwareeinheit, die für sich getestet werden kann.

(2) Kleinste Softwareeinheit, für die eine separate Spezifikation verfügbar ist.

Komponentenintegrationstest Testen wird durchgeführt mit dem Ziel, Fehlerzustände in den Schnittstellen und dem Zusammenwirken der integrierten Komponenten aufzudecken.
Komponentenspezifikation Die Beschreibung der Funktionalität einer Komponente in Form der Vorgabe von Ausgabewerten für spezifizierte Eingabewerte unter spezifizierten Bedingungen sowie der geforderten nicht funktionalen Eigenschaften (z.B. Ressourcennutzung).
Komponententest Testen einer (einzelnen) Komponente. [Nach IEEE 610]
Konfidenzintervall Zeitraum beim Management der Projektrisiken, in dem eine Korrekturmaßnahme implementiert werden muss, damit diese zur Minderung der Risikoauswirkungen wirksam wird.
Konfiguration Die Anordnung eines Computersystems bzw. einer Komponente oder eines Systems, wie sie durch Anzahl, Beschaffenheit und Verbindungen seiner Bestandteile definiert ist.
Konfigurationsaudit Prüfung des Inhalts von Bibliotheken hinsichtlich der Konfigurationsobjekte, z.B. auf Konformität mit Standards. [IEEE 610]
Konfigurationsbuchführung Ein Element des Konfigurationsmanagements, bestehend aus der Informationsaufzeichnung und Berichterstattung, um eine Konfiguration effektiv zu managen. Diese Information enthält eine Liste der freigegebenen Konfigurationsidentifizierung, den Status der vorgeschlagenen Konfigurationsänderungen und den Umsetzungsstatus der freigegebenen Änderungen. [IEEE 610]
Konfigurationsidentifikation Bestandteil des Konfigurationsmanagements, bestehend aus der Festlegung der Konfigurationsobjekte eines Systems und der Aufzeichnung ihrer funktionalen und physischen Eigenschaften in einer technischen Dokumentation. [IEEE 610]
Konfigurationskontrollboard Eine Gruppe von Personen, die verantwortlich ist für die Bewertung und Freigabe/Nichtfreigabe der Implementierung von vorgeschlagenen Änderungen an freigegebenen Konfigurationsobjekten und für die Sicherstellung der freigegebenen Änderungen. [IEEE 610]
Konfigurationskontrolle Bestandteil des Konfigurationsmanagements, bestehend aus der Bewertung, Koordination, Freigabe oder Nichtfreigabe der Implementierung von Änderungen an den Konfigurationsobjekten nach der Etablierung der Identifikation der Konfiguration. [IEEE 610]
Konfigurationsmanagement Technische und administrative Maßnahmen zur Identifizierung und Dokumentation der fachlichen und physischen Merkmale eines Konfigurationsobjekts, zur Überwachung und Protokollierung von Änderungen solcher Merkmale, zum Verfolgen des Änderungsprozesses, Umsetzungsstatus und zur Verifizierung der Übereinstimmung mit spezifizierten Anforderungen. [IEEE 610]
Konfigurationsmanagementwerkzeug Ein Werkzeug zur Unterstützung der technischen und administrativen Maßnahmen des Konfigurationsmanagements. Es schließt die Freigabe einer Bezugskonfiguration ein, die aus Konfigurationsobjekten besteht. Siehe auch Konfigurationsmanagement.
Konfigurationsobjekt Eine Zusammenstellung von Hardware, Software oder beidem, die im Konfigurationsmanagement festgelegt ist und als atomarer Baustein im Konfigurationsmanagementprozess betrachtet werden kann. [IEEE 610]
Konfigurationstest Siehe Portabilitätstest.
Konformität Die Fähigkeit eines Softwareprodukts, anwendungsspezifische Normen oder Vereinbarungen oder gesetzliche Bestimmungen und ähnliche Vorschriften zu erfüllen. [ISO 9126]
Konformitätstest Testen mit dem Ziel, die Konformität einer Komponente oder eines Systems zu bestimmen.
konkreter Testfall Ein Testfall mit konkreten Werten für Eingaben und vorausgesagte Ergebnisse. Logische Operanden der abstrakten Testfälle werden durch konkrete Werte ersetzt. Siehe auch abstrakter Testfall.
kontinuierliches Modell Ein Reifegradmodell, in dem die Reifegrade zu einer empfohlenen Reihenfolge von Verbesserungsmaßnahmen in den verschiedenen Prozessbereichen führen. [CMMI]
Kontrolldiagramm Ein Werkzeug mit dem man darstellen und überwachen kann, ob ein Prozess statistisch kontrolliert ist. Es stellt grafisch den Mittelwert dar sowie die obere und untere Kontrollgrenze für den Prozess.
Kontrollfluss Eine Abfolge von Ereignissen (Pfaden) während der Ausführung einer Komponente oder Systems.
Kontrollflussanalyse Statisches Analyseverfahren, das auf einer Darstellung von Pfaden (Ereignisfolgen) in der Ausführung einer Komponente oder eines Systems basiert. Die Kontrollflussanalyse evaluiert die Integrität von Kontrollflussstrukturen mit dem Ziel, Anomalien wie Endlosschleifen oder logisch nicht erreichbare Prozessschritte zu finden.
Kontrollflussgraph Eine abstrakte Repräsentation von allen möglichen Sequenzen von Ereignissen (Pfaden) der Ausführung in einer Komponente oder einem System.
Kontrollflusspfad Siehe Pfad.
Kontrollflusstest Ein Ansatz für White-Box-Testentwurfsverfahren, bei dem Testfälle erstellt werden, um bestimmte Abfolgen von Ereignissen auszuführen. Es gibt verschiedene Verfahren zum Kontrollfluss-Testen, z.B. Entscheidungstesten, Bedingungstesten und Pfadtesten, die jede ihre eigenen Verfahren und ihr Maß an Überdeckung haben. Siehe auch Entscheidungstest, Bedingungstest, Pfadtest.
Konvergenzmetrik Eine Metrik, welche die Annäherung an einen definierten Wert zeigt, z.B. die Konvergenz der Gesamtzahl der durchgeführten Testfälle gegen die Gesamtzahl der zur Durchführung geplanten Testfälle.
Konvertierungstest Testen von Software, die verwendet wird, um Daten zu konvertieren (z.B. von einem vorhandenen System zur Verwendung in einem das alte System ersetzenden System).
kritischer Erfolgsfaktor Ein notwendiges Element zur Zielerfüllung einer Organisation oder eines Projektes. Kritische Erfolgsfaktoren sind diejenigen kritischen Faktoren oder Aktivitäten, die für die Sicherstellung des Erfolges erforderlich sind.
Kundenakzeptanztest Abnahmetest durch repräsentative Kunden/Benutzer in der Einsatzumgebung des Kunden/Benutzers, um vor der endgültigen Freigabe eine Rückmeldung vom Markt einzuholen und das Interesse des potenziellen Kunden zu erzeugen.
kundenindividuelle Software Siehe Individualsoftware.
L
Lastprofil Eine Spezifikation der Arbeitslast, die eine Komponente oder ein System in Produktion erfährt. Ein Lastprofil besteht aus einer bestimmten Anzahl von virtuellen Benutzern, die eine definierte Menge von Transaktionen in einem vorgegebenen Zeitraum und entsprechend eines vorgegebenen Nutzungsprofils durchführen.

Siehe auch Nutzungsprofil.

Lasttest Eine Art von Performanztest, die das Systemverhalten eines System oder einer Komponente in Abhängigkeit steigender Systemlast (z.B. Anzahl parallele Benutzer, und/oder Anzahl Transaktionen) misst, um zu bestimmen, welche Last durch ein System oder eine Komponente bewältigt werden kann. Siehe auch Performanztest, Stresstest.
Lasttestwerkzeug Ein Werkzeug zur Unterstützung des Lasttests, welches ansteigende Last simulieren kann, z.B. die Anzahl gleichzeitiger Benutzer und/oder Transaktionen innerhalb einer gewissen Zeitraums. Siehe auch Performanztestwerkzeug.
Lead Assessor Die Person, die ein Assessment leitet. In einigen Fällen, zum Beispiel bei CMMi und TMMi, wenn formelle Assessments durchgeführt werden, muss der Lead Assessor akkreditiert und formell ausgebildet sein.
Leistungsindikator Ein Maß auf einer höheren Abstraktionsstufe zum Messen der Effizienz und/oder Effektivität des Entwicklungsfortschritts, z.B. Fehlerfindungsrate im Bereich Testen. [CMMI]
Leitender Testmanager Ein erfahrener Manager, der die Testmanager leitet. Siehe auch Testmanager.
Leiter einer Inspektion Siehe Moderator.
Lernen (IDEAL) Die Phase im IDEAL-Modell, in der man aus Erfahrungen lernt und die Fähigkeit verbessert, künftig neue Prozesse und Technologien zu übernehmen. Die Lernphase besteht aus den Aktivitäten: analysieren und validieren, sowie zukünftige Aktionen vorschlagen. Siehe auch IDEAL.
lineare Skripterstellung Ein einfaches Verfahren der Skripterstellung ohne Verwendung von Kontrollstrukturen in Testskripten.
Linktest Siehe Komponentenintegrationstest.
logik-getriebener Test Siehe White-Box-Test.
Logik-Überdeckungstest Siehe White-Box-Test.
logische Bedingung Ein logischer Ausdruck, der entweder als „wahr“ oder „falsch“ bewertet werden kann, z.B. A>B. Siehe auch Testbedingung.
logischer Testfall Siehe abstrakter Testfall.
M
Managementreview Eine systematische Bewertung des Softwarebeschaffungs-, Lieferungs-, Entwicklungs-, Wartungsprozesses und des Betreibens von Software. Sie wird durchgeführt im Auftrag des Managements, das den Fortschritt überwacht, den Status des Vorhabens und Zeitplans bestimmt und Anforderungen und Budget bestätigt. Es kann auch die Effektivität und Zweckmäßigkeit des Managementansatzes bewerten. [Nach IEEE 610, IEEE 1028]
Man-in-the-middle-Angriff Das Abfangen, Nachahmen und/oder Verändern und nachfolgendes Weiterleiten von Kommunikation (z.B. Kreditkartentransaktionen) durch einen Dritten dergestalt, dass der Nutzer das Vorhandensein der dritten Partei nicht bemerkt.
Maß Die Zahl oder Kategorie, die einem Attribut einer Einheit durch die Durchführung einer Messung zugeordnet wird. [ISO 14598]
maßgeschneidertes Werkzeug Ein Software-Werkzeug, welches speziell für eine Gruppe von Nutzern oder Kunden entwickelt wurde.
Mastertestkonzept Ein Testkonzept, das sich typischerweise auf mehrere Teststufen bezieht. Siehe auch Testkonzept.
MBT Akronym für modellbasiertes Testen.
MBTI Akronym für Myers-Briggs-Typindikator.
MBT-Modell Jedes Modell das in modellbasiertem Testen genutzt wird.
MC/DC Akronym für modifizierte Bedingungs-/Entscheidungsüberdeckung.
Mean Time Between Failures Der arithmetische Mittelwert für die Zeitspanne zwischen Fehlerwirkungen aufeinander folgender Ausfälle einer Betrachtungseinheit oder eines Systems. Die MTBF ist typischerweise Teil eines Zuverlässigkeitswachstumsmodells, welches annimmt, dass die ausgefallene Betrachtungseinheit im Rahmen eines Fehlerbehebungs-Prozesses sofort repariert wird. Siehe auch Zuverlässigkeitswachstumsmodell.
Mean Time To Repair Der arithmethische Mittelwert der Zeit zum Wiederherstellen eines Systems nach Fehlerwirkungen. Dies umfasst typischerweise neben der Reparatur auch den Test, um sicher zu gehen, dass der Fehler behoben ist.
Mehrfachbedingung Siehe zusammengesetzte Bedingung.
Mehrfachbedingungstest Ein White-Box-Testentwurfsverfahren, das die Überdeckung der atomaren Teilbedingungen einer Entscheidung mit WAHR und FALSCH in allen Kombinationen fordert.
Mehrfachbedingungsüberdeckung Der Anteil von Kombinationen der atomaren Teilbedingungen einer Bedingung, die durch eine Menge von Testfällen ausgeführt wurden. 100% Mehrfachbedingungsüberdeckung schließt 100% modifizierte Bedingungs-/Entscheidungs-Bedingungsüberdeckung ein.
Meilenstein Markiert einen Zeitpunkt im Projekt(-prozess), zu dem ein bestimmtes Arbeitsergebnis oder definiertes Zwischenergebnis fertig gestellt sein soll.
Menschzentrierte Gestaltung Herangehensweise bei der Gestaltung und Entwicklung von Systemen, die darauf abzielt, interaktive Systeme gebrauchstauglicher zu machen, indem sie sich auf die Verwendung des Systems konzentriert und Kenntnisse und Techniken aus den Bereichen der Arbeitswissenschaft/Ergonomie und der Gebrauchstauglichkeit anwendet.

[DIN ISO 9241-210]

Mess-Skala Eine Skala, die den Typ der Datenanalyse einschränkt, der auf ihr ausgeführt werden kann. [ISO 14598]
Messung Der Prozess, eine Zahl oder Kategorie einer Einheit zuzuweisen, um ein Attribut dieser Einheit zu beschreiben. [ISO 14598]
methodische Teststrategie Eine Teststrategie, bei der das Testteam einen festgelegten Satz an Testbedingungen nutzt, z.B. einen Qualitätsstandard, eine Prüfliste, oder einen Satz verallgemeinerter abstrakter Testbedingungen, die ggf. zu einer spezifischen Domäne, Applikation oder Testart gehören.
methodisches Testen Testen, das auf einem Standardsatz von Tests basiert, z.B. einer Prüfliste, einem Qualitätsstandard, oder einem Satz verallgemeinerter Testfälle.
Metrik Die Mess-Skala und das genutzte Verfahren einer Messung. [ISO 14598]
Migrationstest Siehe Konvertierungstest.
Mind Map Ein Diagramm zum Darstellen von Worten, Ideen, Aufgaben oder anderen Dingen, die mit einem zentralen Schlüsselwort oder einer zentralen Idee verbunden oder ringsherum angeordnet sind. Mind Maps werden genutzt, um Ideen zu erzeugen, zu visualisieren, zu strukturieren und zu klassifizieren. Sie werden als ein Hilfsmittel im Studium, in der Organisation, bei der Problemlösung, zur Entscheidungsfindung und beim Schreiben genutzt.
Missbrauchsfall Ein Anwendungsfall, bei dem Akteure mit böser Absicht andere Akteure oder das System schädigen.

Siehe auch Anwendungsfall.

Mitschnitt Ein Testautomatisierungsansatz, bei dem Eingaben der Benutzer in das Testobjekt während der manuellen Testdurchführung zum Erzeugen ausführ- und wiederholbarer Testskripte aufgezeichnet werden, die später ausgeführt werden können (Wiedergabe).
Mitschnittwerkzeug Ein Werkzeug zur Unterstützung der Testausführung. Eingaben der Benutzer werden während der manuellen Testdurchführung zum Erzeugen von ausführ- und wiederholbarer Testskripten aufgezeichnet und verwendet. Solche Testwerkzeuge werden häufig zur Unterstützung automatisierter Regressionstests genutzt.
modellbasierte Teststrategie Eine Teststrategie, bei der das Testteam Testmittel von Modellen ableitet.
modellbasiertes Testen Testen, das auf Modellen basiert oder diese involviert.
Modellierungswerkzeug Ein Werkzeug, das die Erstellung, Pflege und Verifizierung von Modellen einer Software oder eines Systems unterstützt. [Graham]
Modellüberdeckung Der Grad, ausgedrückt in Prozent, zu dem Modellelemente durch eine Testsuite geplant sind ausgeführt zu werden oder ausgeführt wurden.
Moderator 1. Der Leiter oder die Hauptperson, die für eine Inspektion oder einen Reviewprozess verantwortlich ist.

2 Eine neutrale Person, die eine Gebrauchstauglichkeitstestsitzung leitet.

Modifizierbarkeit Die Fähigkeit eines Softwareprodukts, die Durchführung spezifizierter Änderungen zu ermöglichen. [ISO 9126]

Siehe auch Wartbarkeit/Änderbarkeit.

modifizierte Bedingungs-/Entscheidungsüberdeckung Der Anteil aller einfachen Bedingungsergebnisse, die von einer Testsuite ausgeführt wurden und unabhängig voneinander einen Entscheidungsausgang beeinflussen. 100% modifizierte Bedingungs-/Entscheidungsüberdeckung schließt 100% Bedingungs-/Entscheidungsüberdeckung ein.
modifizierter Bedingungs-/Entscheidungstest Ein White-Box-Testentwurfsverfahren, bei dem Testfälle so entworfen werden, dass diejenigen Bedingungsergebnisse zur Ausführung kommen, die unabhängig voneinander einen Entscheidungsausgang beeinflussen.
modifizierter Mehrfach-Bedingungstest Siehe modifizierter Bedingungs-/Entscheidungstest.
Modul Siehe Komponente.
Modultest Siehe Komponententest.
MTBF Akronym für Mean Time Between Failures.
MTTR Akronym für Mean Time To Repair.
Mutationsanalyse Ein Verfahren zur Bestimmung der Gründlichkeit der Testsuite durch das Messen des Grades, in wieweit die Testsuite zwischen leichten Varianten (Mutanten) des Programms unterscheiden kann.
Mutationstest Ein Test, bei dem zwei oder mehr Varianten einer Komponente oder eines Systems mit gleichen Eingaben ausgeführt und deren Ergebnisse dann verglichen werden. Im Fall von Abweichungen wird die Ursache analysiert.
Myers-Briggs-Typindikator Ein Indikator psychologischer Präferenzen, die unterschiedliche Persönlichkeiten und Kommunikationsstile von Menschen repräsentieren.
N
Nachbedingung Zustand des Testobjekts (und/oder der Umgebung), in dem sich das Testobjekt (oder die Umgebung) nach Ausführung eines Testfalls oder einer Testsequenz befinden muss.
Nebenläufigkeitstest Ein Test, mit dem sich feststellen lässt, wie das Auftreten von zwei oder mehreren Aktivitäten innerhalb des gleichen Zeitintervalls durch die Komponente oder das System gehandhabt wird. Dies wird entweder durch verschränkte oder durch gleichzeitige Ausführung der Aktivitäten erreicht. [Nach IEEE 610]
Negativtest Ein Test, der zeigen soll, dass eine Komponente oder ein System nicht funktioniert. Der Begriff bezeichnet eher die Einstellung des Testers als einen bestimmten Testansatz oder ein bestimmtes Testentwurfsverfahren, wie etwa das Testen mit ungültigen Eingabewerten oder Ausnahmen. [Nach Beizer]
Netzwerkzone Ein Teil-Netzwerk mit einem bestimmten Vertrauensniveau. Das Internet oder ein öffentliches Netzwerk würden beispielsweise als nicht vertrauenswürdig angesehen werden.
nicht ausführbarer Pfad Ein Pfad, der mit keiner Kombination von Eingabewerten zur Ausführung gebracht werden kann.
nicht bestandener Test Siehe Fehlschlag.
nicht-funktionale Anforderung Eine Anforderung welche sich nicht auf die Funktionalität des Systems bezieht sondern auf Merkmale wie Zuverlässigkeit, Gebrauchstauglichkeit, Effizienz, Änderbarkeit und Übertragbarkeit.
nicht-funktionaler Test Testen der Eigenschaften eines System, die nicht direkt mit der Funktionalität in Verbindung stehen, z.B. Zuverlässigkeit, Effizienz, Gebrauchstauglichkeit, Änderbarkeit und Übertragbarkeit.
nicht-funktionales Testentwurfsverfahren Ein Vorgehen, um nicht-funktionale Testfälle abzuleiten bzw. auszuwählen, basierend auf der Analyse der Spezifikation einer Komponente oder eines Systems ohne Kenntniss der internen Struktur.

Siehe auch Black-Box-Testentwurfsverfahren.

Nichtkonformität Nichterfüllung einer spezifizierten Anforderung. [ISO 9000]
N-Switch-Test Eine Ausprägung des zustandsbasierten Testens, in welcher Testfälle entworfen werden, um alle gültigen Folgen von (N+1) aufeinanderfolgenden Zustandsübergängen auszuführen. [Chow]

Siehe auch zustandsbasierter Test.

N-Switch-Überdeckung Der Anteil der Folgen von (N+1) aufeinanderfolgenden Zustandsübergängen, die durch eine Testsuite ausgeführt wurden. [Chow]
Nutzungskontext Benutzer, Arbeitsaufgaben, Ausrüstung (Hardware, Software und Materialien) und die physische und soziale Umgebung, in der ein Softwareprodukt genutzt wird. [DIN ISO 9241-11]
Nutzungsprofil Die Darstellung einer bestimmten Menge von Aufträgen an die Komponente bzw. an das System mit ihren Eintrittswahrscheinlichkeiten, ggf. basierend auf dem Benutzerverhalten bei seiner Interaktion mit der Komponente bzw. dem System. Ein Auftrag ist hierbei eher abstrakt als physisch, und kann sich auf mehreren Maschinen oder in nicht zusammenhängenden Zeiträumen ausgeführt werden.
Nutzungsprofilerstellung Der Prozess der Entwicklung und Implementierung eines Nutzungsprofiles. Siehe auch Nutzungsprofil.
nutzungsprofilorientierter Test Statistischer Test unter Verwendung eines Modells von Systemoperationen und der Wahrscheinlichkeit ihrer typischen Nutzung. [Musa]
n-weises Testen Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle so entworfen werden, dass alle möglichen diskreten Kombinationen aller n-Tupel von Eingabeparametern ausgeführt werden.

Siehe auch Testen mit orthogonalen Arrays, paarweises Testen.

O
Objektübergabebericht Siehe Release Note.
offline MBT Ansatz zum modellbasierten Testen, bei dem Testfälle für eine zukünftige Ausführung in ein Repository generiert werden.
online MBT Ansatz zum modellbasierten Testen, bei dem Testfälle gleichzeitig generiert und ausgeführt werden.
Open-Source-Werkzeug Ein Software-Werkzeug, das allen potentiellen Nutzern als Quell-Code, üblicherweise über das Internet, zur Verfügung steht. Den Nutzern ist es erlaubt, die Software zu studieren, zu verändern, zu verbessern und manchmal auch weiter zu verkaufen.
Operabilität Die Fähigkeit eines Softwareprodukts, das es dem Benutzer ermöglicht mit dem Produkt zu arbeiten. [ISO 9126]

Siehe auch Gebrauchstauglichkeit.

Orakel Siehe Testorakel.
orthogonale Arrays Ein zweidimensionales Array mit speziellen mathematischen Eigenschaften, bei dem jede Kombination von zwei Spalten alle Kombinationen der Werte enthält.
Outsourcing des Testens Testen durch Personen, die nicht an einem gemeinsamen Ort mit dem Projektteam arbeiten und nicht Mitarbeiter im Unternehmen des Projektteams sind.
P
paarweiser Integrationstest Eine Form des Integrationstests, die auf solche Paare von Komponenten abzielt, die entsprechend der Darstellung im Aufrufgraphen zusammenarbeiten.
paarweises Testen Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle so entworfen werden, dass alle möglichen diskreten Kombinationen aller Paare von Eingabeparametern ausgeführt werden.

Siehe auch n-weises Testen, Testen mit orthogonalen Arrays.

Pareto Analyse Eine statistische Technik zur Entscheidungsfindung auf Basis der Auswahl einer begrenzten Anzahl von Faktoren, die einen signifikanten Effekt auf die Qualität haben. Im Rahmen der Qualitätsverbesserung werden die Mehrheit der Probleme (80%) durch einige wenige Ursachen hervorgerufen.
Passwort knacken Ein Sicherheitsangriff, der geheime Passwörter aus dem Speicher eines Computersystems oder aus einer Übertragung im Netzwerk wiedergewinnt. [NIST.IR.7298]
Peer Review Ein Review eines Arbeitsergebnisses durch gleichgestellte Kollegen des Erstellers mit dem Ziel, Fehlerzustände aufzudecken und Verbesserungsvorschläge zu identifizieren. Beispiele sind Inspektion, technisches Review und Walkthrough.
Penetrationstest Ein Testverfahren mit dem Ziel, über die Nutzung von (bekannten oder unbekannten) Sicherheitsschwachstellen unberechtigten Zugriff zu erlangen.
Performanz Der Grad, in dem ein System oder eine Komponente seine vorgesehenen Funktionen innerhalb vorgegebener Bedingungen (z.B. konstanter Last) hinsichtlich Verarbeitungszeit und Durchsatzleistung erbringt. [Nach IEEE 610]

Siehe auch Effizienz.

Performanzprofilierung Die toolunterstützte Analyse, z.B. durch Identifikation von Performanzengpässen basierend auf generierten Metriken, und die Anpassung der Performanz einer Softwarekomponente oder eines Systems.
Performanztest Testen zur Bestimmung der Performanz eines Softwareprodukts.

Siehe auch Effizienztest.

Performanztestwerkzeug Ein Werkzeug zur Unterstützung der Performanztests. Es enthält im Wesentlichen zwei Funktionen:

Lastgenerierung und Messung der Testtransaktionen. Durch die Lastgenerierung werden entweder viele Anwender oder hohe Eingabedatenvolumen simuliert. Während der Testdurchführung werden Antwortzeiten von ausgewählten Transaktionen gemessen und protokolliert. Performanz-Testwerkzeuge liefern in der Regel Berichte auf der Basis der Testprotokolle und Diagramme des Verhaltens unter Last in Relation zu den Antwortzeiten.

Pfad Eine Folge von Ereignissen wie z.B. ausführbaren Anweisungen einer Komponente oder eines Systems von einem Eintrittspunkt bis zu einem Austrittspunkt.
Pfadsensitivierung Auswahl einer Menge von Eingabewerten, um die Ausführung eines bestimmten Pfades zu erzwingen.
Pfadtest Ein White-Box-Testentwurfsverfahren, bei dem die Testfälle im Hinblick auf die Ausführung von Pfaden entworfen werden.
Pfadüberdeckung Der Anteil der vollständigen Pfade, die durch eine Testsuite ausgeführt wurden.
Pharming Ein Sicherheitsangriff, der Anfragen an eine Website ohne Wissen oder Zustimmung des Benutzers auf eine betrügerische Website umleitet.
Phasenmodell Eine Aufteilung der Lebensdauer eines Produktes oder Projektes in Phasen. [CMMI]

Siehe auch Softwarelebenszyklus.

Phasentestkonzept Ein Testkonzept, das sich typischerweise auf eine Testphase bezieht.

Siehe auch Testkonzept.

Phishing Ein Versuch, in einer elektronischen Kommunikation persönliche oder vertrauliche Informationen zu erwerben, indem man vorgibt, eine vertrauenswürdige Instanz zu sein.
Planungspoker Ein konsensbasiertes Schätzverfahren, das hauptsächlich zum Schätzen des Aufwands oder der relativen Größe von User-Storys in der agilen Softwareentwicklung verwendet wird. Es ist eine Variante des Breitband-Delphi-Verfahrens, bei der das Team einen Stapel an Karten mit vorgegebenen Werten für die Schätzung verwendet. Siehe auch agile Softwareentwicklung, Breitband-Delphi.
Platzhalter Eine rudimentäre oder spezielle Implementierung einer Softwarekomponente, die verwendet wird, um eine noch nicht implementierte Komponente zu ersetzen bzw. zu simulieren. [Nach IEEE 610]
Portabilitätstest Testen zur Bestimmung der Übertragbarkeit eines Softwareprodukts.
Prädikat Eine Aussage, welche die Werte wahr oder falsch annehmen kann, und welche die Steuerung des nachfolgenden Kontrollflusses bestimmen kann. Siehe auch Entscheidung.
Priorität Die Stufe der Wichtigkeit, die einem Objekt (z.B. Fehlerzustand) zugeordnet worden ist.
PRISMA Ein systematischer Ansatz zum risikobasierten Test welche von der Identifikation und Analyse der Produktrisiken ausgeht, um eine Produktrisikomatrix mit Eintrittswahrscheinlichkeit und Schadensausmaß zu erstellen.

Die Bezeichnung ist von Product RISk MAnagement abgeleitet.

Problem Siehe Fehlerzustand.
Problemmanagement Siehe Fehlermanagement.
Problemmeldung Siehe Fehler- und Abweichungsbericht.
Product RISk MAnagement Siehe PRISMA.
produktbasierte Qualität Eine Qualitätsdarstellung, bei der Qualität auf einem definierten Satz von Qualitätsmerkmalen basiert. Die Qualitätsmerkmale müssen objektiv und quantitativ gemessen werden. Qualitätsunterschiede bei Produkten der selben Art erlauben Rückschlüsse auf die Art der Implementierung der spezifischen Qualitätsmerkmale. [Nach Garvin]

Siehe auch benutzerbasierte Qualität, wertbasierte Qualität, transzendenzbasierte Qualität.

Produktionsabnahmetest Siehe betrieblicher Abnahmetest.
Produktivumgebung Beim Benutzer oder Betreiber eingesetzte Hard- und Softwareprodukte, auf denen die zu testende Komponente oder das System betrieben wird. Die Software kann Betriebssysteme, Datenbankmanagementsysteme und andere Applikationen enthalten.
Produktrisiko Ein Risiko, das direkt auf ein Testobjekt bezogen ist.

Siehe auch Risiko.

Programmieren in Paaren Ein Ansatz zur Softwareentwicklung, bei dem die Codezeilen einer Komponente durch zwei Programmierer gemeinsam an einem Computer entwickelt und/oder getestet werden. Implizit bedeutet das, dass ein Codereview in Echtzeit durchgeführt wird.
Programminstrumentierer Siehe Instrumentierer.
Programmtest Siehe Komponententest.
Projekt Ein Projekt ist eine einmalige Menge von abgestimmten und gelenkten Tätigkeiten mit Anfangs- und Endterminen. Es wird durchgeführt, um ein Ziel zu erreichen, das spezifische Anforderungen erfüllt, wobei Zeit-, Kosten- und Ressourcenbeschränkungen eingeschlossen sind. [ISO 9000]
Projekt-Abschluß-Sitzung Siehe Bewertungssitzung.
Projektretrospektive Die strukturierte Erfassung der gesammelten Erfahrungen und Aufstellung eines Maßnahmenplans von Verbesserungen für die nächsten Projekte oder Projektphasen.
Projektrisiko Ein Risiko bezogen auf das Management und die Steuerung eines (Test-)Projekts, z.B. Mangel an personellen Ressourcen, ein zu enger Zeitrahmen, sich ändernde Anforderungen, usw.

Siehe auch Risiko.

Projektstrukturplan Anordnung von Arbeitselementen und ihre Beziehungen untereinander und zum Endprodukt. [CMMI]
Protokollant Eine Person, die sämtliche während einer Reviewsitzung erwähnten Befunde und Verbesserungsvorschläge in einem Reviewprotokoll erfasst. Ein Protokollant sollte sicherstellen, dass das Reviewprotokoll lesbar und nachvollziehbar ist.
Protokollführer Siehe Protokollant.
Prozess Ein Satz von in Wechselbeziehungen stehenden Aktivitäten und Ressourcen, die Eingaben in Ergebnisse umgestalten. [ISO 12207]
Prozess-Assessment Eine systematische Bewertung der Softwareprozesse in einer Organisation unter Verwendung eines Referenz-Modells. [Nach ISO/IEC 15504]
prozessgetriebene Skripterstellung Ein Verfahren der Skripterstellung, bei dem Skripte in Szenarien strukturiert werden, welche Anwendungsfälle des zu testenden Systems darstellen. Die Skripte können mit Testdaten parametrisiert werden.
prozesskonforme Teststrategie Eine Teststrategie, bei der das Testteam vorgegebenen Prozessen folgt, wobei die Prozesse Elemente adressieren wie Dokumentation, die angemessene Identifikation und Nutzung der Testbasis und der Testorakel, und die Organisation des Testteams.
prozesskonformes Testen Testen, welches definierten Prozessen folgt, die z.B. von einer externen Organisation wie einem Standardisierungs-Gremium definiert werden.

Siehe auch standardkonformes Testen.

Prozessmodell Ein Rahmenwerk zur Klassifizierung von Prozessen des gleichen Typs in einem übergeordneten Modell z.B. ein Testprozessverbesserungsmodell.
Prozessreferenzmodell Ein Prozessmodell, das ein Grundgerüst an Best Practices, zusammen mit einem Verfahren zur schrittweisen Verbesserung, aufstellt.
Prozessverbesserung Ein Maßnahmenprogramm zum Zweck der Verbesserung der Leistungsfähigkeit und Reife der Prozesse eines Unternehmens, und das Ergebnis eines solchen Programms. [CMMI]
Prozesszyklustest Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle für Geschäftsprozesse und -abläufe entworfen werden. [TMap] Siehe auch ablaufbasierter Test.
Pseudozufall Eine Reihe, die zufällig erscheint, aber tatsächlich in einer definierten Reihenfolge generiert wird.
PSP Akronym für Projektstrukturplan.
Puffer Ein Gerät oder Speicherbereich zur Zwischenspeicherung von Daten bei ihrer Übertragung oder gemeinsamen Nutzung durch verschiedene Geräte oder Prozesse. Der Puffer dient zum Ausgleich von Unterschieden von Datenflussraten bzw. Auftrittshäufigkeiten von Ereignissen oder Datenmengen, die von Geräten oder Prozessen bewältigt werden können. [IEEE 610]
Pufferüberlauf Fehlerwirkung verursacht durch den Versuch eines Prozesses, Daten ausserhalb der Grenzen des ihm zugewiesenen Bereiches fester Länge zu schreiben. Ein Pufferüberlauf kann das Überschreiben von benachbarten Speicherbereichen verursachen, oder zu einer Ausnahmebedingung führen. Siehe auch Puffer.
Q
QFD Akronym für Qualitätsfunktionendarstellung.
Qualifikation Nachweisverfahren der Fähigkeit, bestimmte Anforderungen zu erfüllen.

Bemerkung: Der Begriff „qualifiziert“ bezeichnet den entsprechenden Status. [ISO 9000]

Qualität (1) Der Grad, in dem ein System, eine Komponente oder ein Prozess die Kundenerwartungen und -bedürfnisse erfüllt. [Nach IEEE 610] (2) Der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt. [ISO 9000:2000]
Qualitätseigenschaft Siehe Qualitätsmerkmal.
Qualitätsfunktionendarstellung Eine Methode zur Umsetzung von Benutzeranforderungen in Entwurfsqualität, um die qualitätsbildenden Funktionen darzustellen, um Methoden zum Erreichen der Qualität über Subsysteme und Komponenten darzustellen, und letztendlich um spezifische Elemente des Herstellungsprozesses darzustellen. [Akao]
Qualitätskontrolle Betriebliche Verfahren und Aktivitäten im Rahmen des Qualitätsmanagements, die auf die Erfüllung von Qualitätsanforderungen ausgerichtet sind. [Nach ISO 8402]
Qualitätskosten Die gesamten Kosten, die durch Qualitätssicherungsaktivitäten und durch Fehlerwirkungen entstehen. Sie werden oft in Kosten der Fehlervorbeugung, der -Ermittlung, der internen Fehlerwirkungen und den externen Fehlerwirkungen aufgeteilt.
Qualitätsmanagement Aufeinander abgestimmte Tätigkeiten zum Leiten und Lenken einer Organisation bezüglich Qualität. Leiten und Lenken bezüglich Qualität umfassen üblicherweise das Festlegen der Qualitätspolitik und der Qualitätsziele, die Qualitätsplanung, die Qualitätssicherung und die Qualitätsverbesserung. [ISO 9000]
Qualitätsmerkmal (1) Fähigkeit oder Eigenschaft, welche die Qualität einer Einheit beeinflusst. [IEEE 610] (2) Ein Satz von Eigenschaften eines Softwareprodukts, anhand dessen seine Qualität beschrieben und beurteilt wird. Ein Softwarequalitätsmerkmal kann über mehrere Stufen in Teilmerkmale verfeinert werden. [ISO 9126] Qualitätsmerkmale sind Funktionalität, Zuverlässigkeit,Gebrauchstauglichkeit, Effizienz, Änderbarkeit und Übertragbarkeit. [ISO 9126]
Qualitätsrisiko Ein Risiko bezüglich eines Qualitätsmerkmals. Siehe auch Qualitätsmerkmal, Produktrisiko.
Qualitätssicherung Teil des Qualitätsmanagements, das darauf gerichtet ist, Vertrauen in die Erfüllung der Qualitätsanforderungen zu erzeugen. [ISO 9000]
Quality Gate Ein spezieller Meilenstein im Projekt. Quality Gates stehen zwischen Projektphasen, die stark von den Arbeitsergebnissen der vorherigen Phase abhängen. Sie enthalten die formale Kontrolle der Arbeitsergebnisse der vorherigen Phase.
Quellcodeanweisung Siehe Anweisung.
R
RACI-Matrix Eine Matrix, welche die Kernverantwortlichkeiten der verschiedenen beteiligten Rollen an der Fertigstellung von Aufgaben oder Arbeitsergebnissen in einem Projekt oder Prozess beschreibt. Sie ist besonders hilfreich bei der Klarstellung von Rollen und Verantwortlichkeiten. RACI ist eine Abkürzung der vier üblichen Kernverantwortlichkeiten: Responsible (durchführungsverantwortlich), Accountable (ergebnisverantwortlich), Consulted (mitwirkend), Informed (informiert).
Rational Unified Process Ein proprietäres anpassbares iteratives Rahmenwerk für Software Entwicklungsprozesse, bestehend aus vier Projektphasen: Konzeptionsphase, Entwurfsphase, Konstruktionsphase, Übergabephase.
reaktive Teststrategie Eine Teststrategie, bei der das Testteam erst mit dem Erhalt der Software Testfälle entwirft und realisiert, wobei auf das getestete System reagiert wird.
reaktives Testen Testen, welches dynamisch auf das Testobjekt und bereits erhaltene Testergebnisse reagiert. Typischerweise hat reaktives Testen eine verkürzte Planungsphase, und die Entwurfs- und Realisierungsphase werden nicht vor Verfügbarkeit des Testobjekts ausgeführt.
Record/Playback-Werkzeug Siehe Mitschnittwerkzeug.
Referenzkonfiguration Eine Spezifikation oder ein Softwareprodukt, welches formal geprüft bzw. dem zugestimmt wurde. Anschließend dient diese Referenzkonfiguration als Basis für die weitere Entwicklung und darf nur durch ein formales Änderungskontrollverfahren geändert werden. [Nach IEEE 610]
Regressionstest Erneutes Testen eines bereits getesteten Programms bzw. einer Teilfunktionalität nach deren Modifikation. Ziel ist es nachzuweisen, dass durch die vorgenommenen Änderungen keine Fehlerzustände eingebaut oder (bisher maskierte Fehlerzustände) freigelegt wurden.

Anmerkung:

Ein Regressionstest wird durchgeführt, wenn die Software oder ihre Umgebung verändert wurde.

regressionsvermeidende Teststrategie Eine Teststrategie, bei der das Testteam verschiedene Verfahren für das Management des Risikos von Regression verwendet, z.B. durch funktionale und/oder nicht-funktionale Regressionstestautomatisierung auf einer oder mehreren Teststufen.
regressionsvermeidendes Testen Testen unter Verwendung verschiedener Verfahren für das Management des Risikos von Regression, z.B. durch Entwurf von wiederverwendbaren Testmitteln und durch umfassende Automatisierung auf einer oder mehreren Teststufen.
regulatorischer Abnahmetest Siehe Konformitätstest.
Reife (1) Das Ausmaß, in welchem eine Organisation ihre Prozesse (Abläufe) effizient und effektiv gestaltet hat.

Siehe auch Capability Maturity Model Integration, Test Maturity Model Integration. (2) Die Fähigkeit eines Softwareprodukts, kritische Fehlerwirkungen aufgrund von Fehlerzuständen in der Software zu vermeiden. [ISO 9126]

Siehe auch Zuverlässigkeit.

Reifegrad Grad der Prozessverbesserung in einem vordefinierten Satz von Prozessgebieten, in dem alle spezifischen und generischen Ziele erreicht werden. [TMMi]
Reifegradmodell Eine strukturierte Menge von Elementen, die bestimmte Aspekte des Reifegrades einer Organisation beschreiben und die bei der Definition und dem Verstehen der Prozesse der Organisation helfen. Ein Reifegradmodell stellt oft eine allgemeine Sprache, eine gemeinsame Vision und ein Rahmenwerk zur Priorisierung von Verbesserungsaktionen zur Verfügung.
Release Note Ein Dokument, das im Rahmen der Übergabe von der Entwicklung zum Test zu Beginn der Testdurchführung die Testobjekte identifiziert, ihre Konfiguration, aktuellen Status und andere Informationen. [Nach IEEE 829]
Ressourcennutzung Die Fähigkeit eines Softwareprodukts, angemessene Mengen und Arten von Ressourcen zu nutzen. Das können sein: die Menge des vom Programm verwendeten Haupt- und Sekundärspeichers und die Größen der angeforderten temporären Dateien oder Überlaufdateien, wenn die Software ihre Funktion unter festgelegten Bedingungen ausführt. [Nach ISO 9126]

Siehe auch Effizienz.

Review Eine Bewertung eines Produkts oder eines Projektstatus. Sie dient dazu, Diskrepanzen zu den geplanten Ergebnissen aufzudecken und Verbesserungspotenziale zu identifizieren. Review ist ein Oberbegriff für Management Review, informelles Review, technisches Review, Inspektion und Walkthrough. [Nach IEEE 1028]
Review auf Testbarkeit Eine detaillierte Prüfung der Testbasis daraufhin, ob sich die Testbasis auf einem geeigneten Qualitätsniveau befindet, um als Ausgangspunkt für den Testprozess zu dienen. [Nach TMap]
Reviewer Siehe Gutachter.
Reviewplan Ein Dokument, welches den Ansatz, die Ressourcen und den Zeitplan für die beabsichtigten Reviewaktivitäten beschreibt. Es beschreibt unter anderem folgendes: zu prüfende Dokumente und Code, zu verwendende Reviewarten, Teilnehmer, Eingangs- und Endekriterien für formale Reviews und Begründung für deren Auswahl. Der Reviewplan ist ein Ergebnis des Reviewplanungsprozesses.
Reviewwerkzeug Ein Werkzeug zur Unterstützung des Reviewprozesses. Typische Fähigkeiten sind: Reviews planen, Maßnahmen verfolgen, Kommunikationsunterstützung, verteilte Reviews unterstützen und ein Repository für das Sammeln und Berichten von Metriken.
Richtlinie für barrierefreie Webinhalte Ein Teil einer Serie von Barrierefreiheits-Richtlinien, veröffentlicht von der Web Accessibility Initiative (WAI) des World Wide Web Consortium (W3C), der wichtigsten Organisation für Internet-Standards. Die Teilserie besteht aus einem Satz von Richtlnien, um Inhalte zugänglich zu machen, insbesondere für Menschen mit Behinderungen..
Richtlinie für Benutzungsschnittstellen Ein untergeordnetes, spezifisches Regelwerk oder eine Empfehlung zum Design der Benutzungsschnittstelle, welches wenig Interpretationsspielraum lässt, so dass die Designer es entsprechend implementieren. Es wird oft dazu genutzt, für die Systeme, die von einem Unternehmen erstellt werden, ein konsistentes Erscheinungsbild und Verhalten der Benutzungsschnittstelle sicherzustellen.
Risiko Ein Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte, gewöhnlich ausgedrückt durch das Schadensausmaß und die Eintrittswahrscheinlichkeit.
Risikoanalyse Bewertung von identifizierten Projektrisiken oder Produktrisiken um ihre Risikostufe zu bestimmen, typischerweise durch die Bewertung von Schadensausmaß und Eintrittswahrscheinlichkeit.
Risikobegrenzung Der Prozess, mit dem Entscheidungen getroffen und Schutzmaßnahmen getroffen werden, um das Risiko auf eine vorgegebene Stufe zu reduzieren oder um es auf einer Stufe zu halten.
Risikobewertung Der Prozess der Identifizierung und der anschließenden Analyse des identifizierten Projektrisikos oder Produktrisikos, um die Risikostufe festzustellen, typischerweise durch die Bewertung von Eintrittswahrscheinlichkeit und Schadensausmaß.

Siehe auch Produktrisiko, Projektrisiko, Risiko, Risikoauswirkung, Risikostufe, Risikowahrscheinlichkeit.

Risikogefährdung siehe Risikostufe
Risikoidentifizierung Der Prozess der Identifikation von Risiken mit Verfahren wie Brainstorming, Checklisten und Fehlerhistorie.
Risikokategorie Siehe Risikotyp.
Risikomanagement Systematische Anwendung von Praktiken für die Aufgaben der Risikoidentifizierung, Risikoanalyse, Risikopriorisierung und Risikoüberwachung.
risikoorientierter Test Ein Ansatz zum Testen, um Produktrisiken zu reduzieren und die Stakeholder hinsichtlich der Produktrisiken zu informieren, beginnend in den frühen Phasen des Projekts. Risikoorientiertes Testen beinhaltet die Identifizierung der Produktrisiken und die Verwendung von Risikostufen zur Steuerung des Testprozesses.
Risikostufe Diskretes Maß der Wichtigkeit eines Risikos, bestimmt durch seine Bestandteile Auswirkung und Eintrittswahrscheinlichkeit. Die Risikostufe kann genutzt werden, um die geplante Testintensität entsprechend zu bestimmen. Die Skala kann entweder qualitativ (z.B. hoch, mittel, niedrig) oder quantitativ sein.
Risikotyp Eine Menge von Risiken, die einen oder mehrere gemeinsame Aspekte aufweisen, wie Qualitätsmerkmal, Ursache, Ort oder mögliche Auswirkung des Risikos.

Bestimmte Risikotypen können durch eine bestimmte Testart reduziert (kontrolliert) werden.

Zum Beispiel kann das Riskio missverstandener Bedienerinteraktionen durch Gebrauchstauglichkeitstests verringert werden.

Risikoüberwachung Siehe Risikobegrenzung.
Robustheit Der Grad, zu welchem Ausmaß eine Komponente oder ein System bei ungültigen Eingaben und extremen Umgebungsbedingungen korrekt funktioniert. [IEEE 610]

Siehe auch Fehlertoleranz.

Robustheitstest (1) Test zum Ermitteln der Robustheit eines Softwareprodukts. (2) Siehe Negativtest.
Rückverfolgbarkeit Die Fähigkeit, zusammengehörige Teile von Dokumentation und Software zu identifizieren, insbesondere die Anforderungen mit den dazu gehörigen Testfällen.

Siehe auch horizontale Rückverfolgbarkeit, vertikale Rückverfolgbarkeit.

Rückverfolgbarkeitsmatrix Eine zweidimensionale Tabelle, die die gegenseitigen Beziehungen zweier Entitäten wie z.B. Anforderungen und Testfälle darstellt. Die Tabelle wird zur Bestimmung und Erreichung der Überdeckung verwendet, um von einer Entität zur anderen und zurück zu verfolgen, und um die Auswirkung von Änderungsvorschlägen zu bewerten.
RUP Akronym für Rational Unified Process.
S
S.M.A.R.T. Zieldefinitionsmethode Eine Methode, bei der sehr spezifische Ziele anstelle von allgemeinen Zielen definiert werden. SMART ist eine Abkürzung der Eigenschaften eines zu definierenden Zieles: Specific (spezifisch), Measurable (messbar), Attainable (erreichbar), Relevant (relevant) und Timely (termingerecht).
Safety Test Testen, um die funktionale Sicherheit eines Softwareprodukts zu bestimmen.
Salzen Ein kryptographisches Verfahren, das den Benutzerdaten vor der Anwendung der Hashfunktion Zufallsdaten („Salz“) hinzufügt.

Siehe auch Hashfunktion.

Sanity-Test Siehe Smoke-Test.
Schadensausmaß Siehe Schadensausmaß des Risikos.
Schadensausmaß des Risikos Der Schaden, der entsteht, wenn ein Risiko eintritt.
Schadprogramm Software, die dazu bestimmt ist, ein System oder seine Komponenten zu schädigen.
Schadprogramm-Scan Statische Analyse zum Aufspüren und Beseitigen von böswilligem Code, der über eine Schnittstelle empfangen wurde.

Siehe auch Angrifferkennungssystem.

schlüsselwortgetriebener Test Ein skriptbasiertes Verfahren, das nicht nur Testdaten und vorausgesagte Ergebnisse aus Dateien einliest, sondern auch spezielle Schlüsselworte zur Steuerung. Diese Schlüsselworte können von speziellen Skripts interpretiert werden und den Test während der Laufzeit steuern.

Siehe auch datengetriebenes Testen.

Schnittstellentest Eine Art des Integrationstests, die sich mit dem Testen der Schnittstellen von Komponenten und Systemen beschäftigt.
Schreibtischtest Testen einer Software oder einer Spezifikation durch manuelle Simulation ihrer Ausführung. Siehe auch statisches Testen.
Schwachstellenscanner Ein statischer Analysator, der zum Auffinden bestimmter Sicherheitsschwachstellen im Code genutzt wird.
Scorecard Eine zusammengefasste Darstellung von Leistungsmessungen, die den Fortschritt der Umsetzung eines Langzeit-Ziels darstellen. Eine Scorecard stellt statische Messwerte der Leistung während oder am Ende eines definierten Zeitraums dar.

Siehe auch Balanced Scorecard, Dashboard.

SCRUM Ein iterativ inkrementelles Vorgehensmodell für das Projektmanagement, das im Allgemeinen bei agiler Softwareentwicklung verwendet wird. Siehe auch agile Softwareentwicklung.
Shewhart-Kontrolldiagramm Siehe Kontrolldiagramm.
Sicherheit (im Sinne von Zugriffsschutz) Eigenschaften der Software, die sich auf die Fähigkeit beziehen, nicht autorisierte Zugriffe auf Programme oder Daten zu verhindern, unabhängig davon, ob diese versehentlich oder vorsätzlich erfolgen. [ISO 9126]

Siehe auch Funktionalität.

Sicherheitsangriff Ein Versuch, unberechtigten Zugriff auf Komponenten, Ressourcen, Information oder ein System zu erlangen, oder ein Versuch, die Systemintegrität zu beschädigen. [NIST.IR.7298]
Sicherheitsaudit Ein Audit zur Bewertung von Sicherheitsverfahren und Infrastruktur eines Unternehmens.
sicherheitskritisches System Ein System, bei dem eine Fehlerwirkung oder Fehlfunktion zum Tod oder ernsthafter Verletzung von Personen führen kann, oder zum Verlust oder schwerem Schaden von Gerätschaften, oder zu Umweltschäden.
Sicherheitsprüfwerkzeug Ein Werkzeug, das Unterstützung leistet beim Aufdecken von Sicherheitslücken des Zugriffs.
Sicherheitsrichtlinie Ein Dokument auf hohem Abstraktionsniveau, das die Grundsätze, den Ansatz und die wichtigsten Ziele des Unternehmens bezüglich der Sicherheit beschreibt.
Sicherheitsschwachstelle Eine Schwachstelle des Systems, die einen erfolgreichen Sicherheitsangriff zulassen könnte.
Sicherheitsverfahren Eine Menge an Schritten, die zur Umsetzung einer Sicherheitsrichtlinie und bei einem Sicherheitsstörfall zu unternehmen sind.
Sicherheitswerkzeug Ein Werkzeug, das die operative Sicherheit unterstützt.
Simulation Die Darstellung von ausgewählten Verhaltensmustern eines physikalischen oder abstrakten Systems durch ein anderes System. [ISO 2382/1]
Simulator Gerät, Computerprogramm oder Testsystem, das sich wie ein festgelegtes System verhält, wenn man es mit einem definierten Satz kontrollierter Eingaben versorgt. [Nach IEEE 610, DO178b]

Siehe auch Emulator.

sitzungsbasiertes Testen Ein Ansatz zum Testen, bei dem die Testaktivitäten – insbesondere Testentwurf und Testdurchführung – als unterbrechungsfreie Sitzungen geplant werden, oft in Verbindung mit explorativem Testen.
Sitzungsbasiertes Testmanagement Eine Methode zur Messung und Steuerung des Testens in Sitzungen („sitzungsbasiertes Testen„), z.B. explorativen Testens.
Skalierbarkeit Die Fähigkeit eines Softwareprodukts, so aufgerüstet zu werden, dass es eine erhöhte Last verkraftet. [Nach Gerrard]
Skalierbarkeitstest Testen zur Bestimmung der Skalierbarkeit eines Softwareprodukts.
skriptbasiertes Testen Durchführung einer vorher festgelegten und dokumentierten Abfolge von Testschritten.
Skriptkiddie Eine Person, die von anderen Hackern vorgefertigte Sicherheitsangriffe ausführt, anstatt eigene zu entwickeln.

Siehe auch Hacker.

Skriptsprache Eine Programmiersprache zur Erstellung ausführbarer Skripte, die dann durch ein Testausführungswerkzeug (z.B. Capture/Replay-Werkzeug) verwendet werden.
SMART Akronym für S.M.A.R.T. Zieldefinitionsmethode.
Smoke-Test Eine Teilmenge aller definierten/geplanten Testfälle, die die Hauptfunktionalität einer Komponente oder eines Systems überdecken. Der Test soll feststellen, ob die wichtigsten Funktionen eines Programms arbeiten, ohne jedoch einzelne Details zu berücksichtigen. Ein täglicher Build und ein Smoke-Test gehören in der Industrie zur Best Practice. Siehe auch Testeingangsprüfung.
Software Programme, Prozeduren und möglicherweise zugeordnete Dokumentation und Daten für die betreffende Verarbeitung auf einem Computersystem. [IEEE 610]
Softwareabweichung Siehe Abweichung.
Softwarefeature Siehe Feature.
Softwarefehler-Möglichkeits- und Einfluss-Analyse Siehe Fehler-Möglichkeits- und Einfluss-Analyse.
Softwarefehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse Siehe Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse.
Software-Gebrauchstauglichkeits-Messinventar Ein Testverfahren zur Bewertung der Gebrauchstauglichkeit der Software aus Endbenutzersicht, das auf einem Fragenkatalog basiert. [Kirakowski93]
Software-Integritätsstufe Der erfüllte oder geforderte Grad der Konformität einer Software zu einer durch Stakeholder festgelegten Menge von Sofwareeigenschaften oder softwarebasierten Systemeigenschaften (z.B. Softwarekomplexität, Risikobewertung, Stufe der funktionalen Sicherheit und Zugriffssicherheit, gewünschte Performanz, Zuverlässigkeit, oder Kosten), entsprechend der Bedeutung der Software für die Stakeholder.
Softwarelebenszyklus Der Zeitraum, der bei der Konzeption eines Softwareprodukts beginnt und dann endet, wenn die Software nicht mehr für die Nutzung verfügbar ist. Der Softwarelebenszyklus enthält üblicherweise eine Konzeptionsphase, Anforderungsphase, Entwurfsphase, Implementierungsphase, Testphase, Installationsphase, Betriebs- und Wartungsphase, und manchmal eine Außerbetriebnahme. Bemerkung: Diese Phasen können sich überlappen oder iterativ durchgeführt werden.
Software-Prozessverbesserung Eine Reihe von Tätigkeiten zur Verbesserung der Leistung und Reife der Software-Prozesse einer Organisation sowie die Ergebnisse einer solchen Aktivität. [Nach CMMI]
Softwarequalität Gesamtheit der Funktionalitäten und Merkmale eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. [Nach ISO 9126]

Siehe auch Qualität.

Softwarequalitätsmerkmal Siehe Qualitätsmerkmal.
Softwaretestfehler-/abweichungsbericht Siehe Fehler- und Abweichungsbericht.
Sollverhalten Siehe vorausgesagtes Ergebnis.
soziale Manipulation Ein Versuch, eine Person hereinzulegen, damit sie Information (z.B. ein Passwort) preisgibt, die zum Angriff auf Systeme oder Netzwerke genutzt werden kann. [NIST.IR.7298]
Speicher Siehe Ressourcennutzung.
Speicherleck Eine Fehlerwirkung, die sich zeigt, indem ein Programm und/oder andere parallele Prozesse infolge Speicherplatzmangels nicht funktionieren. Ursache hierfür ist ein Fehlerzustand bei der dynamischen Speicherverwaltung, der zur fehlerhaften Freigabe von Speicher nach dessen Verwendung führt.
Speichertest Siehe Test der Ressourcennutzung.
Spezifikation Ein Dokument, das die Anforderungen, den Aufbau, das Verhalten oder andere Charakteristika des Systems bzw. der Komponente beschreibt, idealerweise genau, vollständig, konkret und nachprüfbar. Häufig enthält die Spezifikation auch Vorgaben zur Prüfung der Anforderungen. [Nach IEEE 610]
spezifikationsorientierter Test Siehe Black-Box-Test.
spezifikationsorientiertes Testentwurfsverfahren Siehe Black-Box-Testentwurfsverfahren.
spezifikationsorientiertes Verfahren Siehe Black-Box-Testentwurfsverfahren.
spezifizierte Eingabe Eine Eingabe, für die die Spezifikation ein Ergebnis vorgibt.
SQL-Einschleusung Ein Sicherheitsangriff, der in ein Eingabefeld böswillige SQL-Befehle zwecks Ausführung einfügt.
Stabilität Die Fähigkeit eines Softwareprodukts, unerwartete Auswirkungen von Änderungen zu vermeiden. [ISO 9126]

Siehe auch Wartbarkeit/Änderbarkeit.

Standard Ein Satz von formalen und gegebenenfalls zwingend notwendigen Anforderungen, die entwickelt und verwendet werden, um einheitliche Vorgehensweisen für die Arbeit vorzuschreiben oder um Richtlinien vorzugeben (z.B. ISO/IEC Normen, IEEE Standards, DIN Normen und andere Organisationsstandards). [Nach CMMI]
standardkonforme Teststrategie Eine Teststrategie, bei der das Testteam einem Standard folgt. Die zu folgenden Standards können gültig sein für z.B. ein Land (rechtliche Standards), oder Geschäftsbereiche (Bereichsstandards), oder intern (Organisationsstandards).
standardkonformes Testen Testen, welches eine Menge an Anforderungen erfüllt, welche durch einen Standard definiert werden, z.B. Industrieteststandard oder ein Standard für das Testen von sicherheitskritischen Systemen. Siehe auch prozesskonformes Testen.
Standardsoftware Ein Softwareprodukt, das für den allgemeinen Markt entwickelt wurde, d.h. eine große Anzahl von Kunden, und das in identischer Form an viele Kunden ausgeliefert wird.
statische Analyse Die Analyse von Software-Entwicklungsartefakten, z.B. Anforderungen oder Quelltext, ohne diese auszuführen. Statische Analyse wird in der Regel mit Werkzeugunterstützung durchgeführt.
statische Codeanalyse Eine Analyse des Quellcodes ohne Ausführung der Software.
statischer Analysator Ein Werkzeug, das eine statische Analyse durchführt.
statischer Test Testen von Software-Entwicklungsartefakten, z.B. Anforderungen oder Quelltext, ohne diese auszuführen, z.B. durch Reviews oder statische Analyse.
statisches Analysewerkzeug Siehe statischer Analysator.
statistischer Test Ein Testentwurfsverfahren, in dem das Modell der statistischen Verteilung der Eingaben verwendet wird, um repräsentative Tests zu konstruieren.

Siehe auch nutzungsprofilorientierter Test.

STEP Akronym für Systematischer Test- und Evaluierungsprozess.
Stresstest Spezifische Form des Performanztests, die durchgeführt wird, um ein System oder eine Komponente an oder über den Grenzen, die in den Anforderungen spezifiziert wurden, zu bewerten. [Nach IEEE 610]

Siehe auch Performanztest, Lasttest.

Stresstestwerkzeug Ein Werkzeug, das den Stresstest unterstützt.
strukturbasiertes Testentwurfsverfahren Siehe White-Box-Test.
strukturbasiertes Testentwurfsverfahren Siehe White-Box-Test.
strukturbasiertes Verfahren Siehe White-Box-Testentwurfsverfahren.
strukturelle Überdeckung Überdeckung, die auf Basis der internen Struktur von Komponenten oder eines Systems gemessen wird.
struktureller Test Siehe White-Box-Testentwurfsverfahren.
strukturelles Testentwurfsverfahren Siehe White-Box-Testentwurfsverfahren.
strukturierte Skripterstellung Ein Verfahren der Skripterstellung, das eine Bibliothek wiederverwendbarer (Teil-) Skripte aufbaut und nutzt.
strukturierter Walkthrough Siehe Walkthrough.
Stufendarstellung Eine Modellstruktur, in der das Erreichen der Ziele in einer Gruppe von Prozessbereichen einen Reifegrad bestimmt. Jeder Reifegrad bildet den Ausgangspunkt für folgende Reifegrade. [CMMI]
Stufentestkonzept Ein Testkonzept, das typischerweise für genau eine Teststufe gilt.

Siehe auch Testkonzept.

SUMI Akronym für Software-Gebrauchstauglichkeits-Messinventar (engl. Software Usability Measurement Inventory).
Summative Evaluierung Eine Art der Qualitätsbewertung, die zu dem Zweck entworfen und genutzt wird, Schlussfolgerungen über die Qualität einer Komponente oder eines Systems zusammenzustellen, insbesonderre wenn das Design größtenteils bereits fertig gestellt ist. Siehe auch formative Evaluierung, Testen.
SUS Akronym für System Usability Scale (Systemgebrauchstauglichkeitsskala).
SUT Akronym für system under test.
Syntaxtest Ein Black-Box-Testentwurfsverfahren, bei dem Testfälle auf Basis der Definition der Eingangsdaten erstellt werden.
System Eine Zusammenstellung von Komponenten, um eine spezifische Funktion oder eine Menge von Funktionen zu erfüllen. [IEEE 610]
system under test Siehe Testobjekt.
System von Systemen Mehrere heterogene verteilte Systeme, die in Netzwerken auf mehreren Ebenen und in mehreren verbundenen Domänen eingebunden sind, um große interdiziplinäre gemeinsame Probleme und Fragestellungen zu adressieren, üblicherweise ohne eine gemeinsame Managementstruktur.
Systematischer Test- und Evaluierungsprozess Eine strukturierte Testmethode, die auch als inhaltsbasiertes Modell für die Testprozessverbesserung genutzt wird. Sie fordert keine bestimmte Reihenfolge für die Verbesserungsmaßnahmen. Siehe auch inhaltsbasiertes Modell.
System-Gebrauchstauglichkeits-Skala Eine einfache zehnstufige Skala, die eine globale Sicht auf subjektive Bewertungen der Gebrauchstauglichkeit liefert.
Systemhärtung Schrittweise Reduktion der Sicherheitsschwachstellen eines Systems durch Anwendung einer Sicherheitsrichtlinie und verschiedener Schichten des Zugriffsschutzes.
Systemintegrationstest Testen der Integration von Systemen und Paketen, Testen der Schnittstellen zu einer externen Organisation (z.B. Electronic Data Interchange oder Internet).
Systemtest Testen eines integrierten Systems, um sicherzustellen, dass es spezifizierte Anforderungen erfüllt. [Hetzel]
szenarienbasierter Test Siehe anwendungsfallbasierter Test.
Szenariotest Siehe anwendungsfallbasierter Test.
T
tatsächliches Verhalten Siehe Istergebnis.
technisches Review Eine Diskussion in einer Gruppe gleichgestellter qualifizierter Mitarbeiter, die sich darauf konzentriert, eine Übereinstimmung über technische Vorgehensweisen zu erreichen. [Gilb und Graham], [IEEE 1028] Siehe auch Peer Review.
Teilpfad Eine Folge von ausführbaren Anweisungen in einer Komponente.
Test Eine Menge von einem oder mehreren Testfällen. [IEEE 829]
Test der Ressourcennutzung Testen, um die Ressourcennutzung eines Softwareprodukts festzustellen.

Siehe auch Effizienztest.

Test gegen Standards Siehe Konformitätstest.
Test Hook Eine indiviualisierte Softwareschnittelle, die es erlaubt, ein Testobjekt automatisiert zu testen.
Test Maturity

Model Integration

Ein fünfstufiges Rahmenwerk für die Testprozessverbesserung, das mit dem Capability Maturity Model Integration (CMMI®) verwandt ist, und die Schlüsselelemente eines effektiven Testprozesses beschreibt.
Testablauf Siehe Testablaufspezifikation.
Testablaufspezifikation Ein Dokument, das eine Folge von Schritten zur Testausführung festlegt. Auch bekannt als Testskript oder Testdrehbuch. [Nach IEEE 829]

Siehe auch Testspezifikation.

Testabschlussbericht Ein Dokument, das die Testaktivitäten und -ergebnisse zusammenfasst. Es enthält eine Bewertung der durchgeführten Tests gegen definierte Endekriterien. [Nach IEEE 829]
Testabweichung Siehe Abweichung.
Testabweichungsbericht Siehe Abweichungsbericht.
Testadaptierungsschicht Die Schicht in einer Testautomatisierungsarchitektur, die den notwendigen Code zur Anpassung automatisierter Testskripte auf einer abstrakten Stufe für verschiedene Komponenten, Konfigurationen oder Schnittstellen des SUT zur Verfügung stellt.
Testanalyse Der Vorgang, die Testbasis zu analysieren und Testziele zu definieren.
Testanforderung Siehe Testbedingung.
Testarbeitsergebnis Jedes Ergebnis aus dem Testprozess, das ein Autor an andere Personen oder Stellen liefert.

Siehe auch Arbeitsergebnis.

Testarchitekt (1) Eine Person, die Leitlinien und die strategische Ausrichtung für eine Testorganisation und ihre Beziehungen zu anderen Disziplinen erstellt. (2) Eine Person, die die Art und Weise definiert, wie Testen für ein bestimmtes System strukturiert wird, einschließlich der Themen wie Testwerkzeuge und Testdatenmanagement.
Testart Eine Gruppe von Testaktivitäten, mit der Absicht, eine Komponente oder ein System auf einige zusammenhängende Qualitätsmerkmale zu prüfen. Eine Testart ist auf ein bestimmtes Testziel fokussiert, wie z.B. Zuverlässigkeitstest, Regressionstest, Gebrauchstauglichkeitstest. Die Testart kann sich auch auf eine oder mehrere Teststufen oder -phasen beziehen. [Nach TMap]
Testaufzeichnung Siehe Testprotokollierung.
Testausführungsphase Der Zeitraum im Softwarelebenszyklus, in dem die Komponenten eines Softwareprodukts ausgeführt werden und damit für das Softwareprodukt bewertet wird, ob die Anforderungen erfüllt werden oder nicht. [IEEE 610]
Testausführungsplan Ein Plan für die Ausführung von Testabläufen.

Anmerkung: Der Testausführungsplan enthält die Testabläufe mit ihrem Kontext und der auszuführenden Reihenfolge.

Testausführungsschicht Die Schicht in einer generischen Testautomatisierungsarchitektur, die die Ausführung von Testsuiten und/oder Testfällen unterstützt.
Testausführungswerkzeug Ein Testwerkzeug, das mit einem automatisierten Testskript eine andere Software steuern kann, z.B. ein Capture/Replay-Werkzeug.
Testausgang Siehe Ergebnis.
Testauswahlkriterien Die Kriterien, die genutzt werden, um die Generierung von Testfällen oder das Auswählen von Testfällen zu steuern, mit dem Ziel, den Testumfang zu limitieren.
Testautomatisierung Einsatz von Softwarewerkzeugen zur Durchführung oder Unterstützung von Testaktivitäten, z.B. Testmanagement, Testentwurf, Testausführung und Soll/Ist-Vergleich.
Testautomatisierungsarchitektur Eine Instanziierung der generischen Testautomatisierungsarchitektur, um die Architektur einer Testautomatisierungslösung zu definieren, z.B. seine Schichten, Komponenten, Dienste und Schnittstellen.
Testautomatisierungsentwickler Eine Person, die für Entwurf, Entwicklung und Wartung einer Testautomatisierungsarchitektur verantwortlich ist sowie für die technische Weiterentwicklung der daraus resultierenden Testautomatisierungslösung.
Testautomatisierungs-Framework Ein Werkzeug, das eine Umgebung zur Testautomatisierung bereitstellt. Es beinhaltet üblicherweise einen Testrahmen und Testbibliotheken.
Testautomatisierungslösung Die Umsetzung/Realisierung einer Testautomatisierungsarchitektur, z.B. eine Kombination von Komponenten, die einen spezifischen Testautomatisierungsauftrag umsetzt. Die Komponenten könnten Standard-Testwerkzeuge, Testautomatisierungs-Frameworks sowie Testhardware beinhalten.
Testautomatisierungsmanager Eine Person, die für die Planung und Überwachung der Neu- und Weiterentwicklung einer Testautomatisierungslösung verantwortlich ist.
Testautomatisierungsstrategie Ein abstrakter Plan, um langfristige Ziele der Testautomatisierung unter gegebenen Randbedingungen zu erreichen.
testbare Anforderung Eine Anforderung, die so formuliert ist, dass Testbedingungen (und in weiterer Folge Testfälle) festgelegt werden können, und dass sich bei der Durchführung der Testfälle feststellen lässt, ob die Anforderung erfüllt ist. [Nach IEEE 610]
Testbarkeit Die Fähigkeit eines Softwareprodukts für einen Test nach einer Änderung. [ISO 9126]

Siehe auch Wartbarkeit/Änderbarkeit.

Testbasis Alle Dokumente, aus denen die Anforderungen ersichtlich werden, die an eine Komponente oder ein System gestellt werden, bzw. die Dokumentation, auf der die Herleitung oder Auswahl der Testfälle beruht.

Wenn ein Dokument nur über das formale Änderungsverfahren geändert werden kann, handelt es sich um eine festgelegte Testbasis. [Nach TMap]

Testbedingung Eine Einheit oder ein Ereignis, z.B. eine Funktion, eine Transaktion, ein Feature, ein Qualitätsmerkmal oder ein strukturelles Element einer Komponente oder eines Systems, welche bzw. welches durch einen oder mehrere Testfälle verifiziert werden kann.
Testbericht Siehe Testabschlussbericht.
Testberichterstattung Sammlung und Analyse der Daten über Testaktivitäten und ihre anschließende Konsolidierung in einem Bericht, um die Stakeholder zu informieren. Siehe auch Testprozess.
Testbewertungsbericht Ein Dokument, das zum Abschluss eines Testprojekts erstellt wird und sämtliche Testaktivitäten und Ergebnisse zusammenfasst. Es enthält auch eine Bewertung des Testprozesses und einen Erfahrungsbericht.
Test-Charta Eine Anweisung von Testzielen und möglichen Testideen wie getestet werden soll. Test-Chartas werden oft im explorativen Testen verwendet. Siehe auch exploratives Testen.
Testdaten Daten die (z.B. in einer Datenbank) vor der Ausführung eines Tests existieren, und die die Ausführung der Komponente bzw. des Systems im Test beeinflussen bzw. dadurch beeinflusst werden.
Testdateneditor und -generator Ein Testunterstützungswerkzeug, mit dem Daten generiert, bereitgestellt, verändert oder aus einer Datenbank selektiert werden können.
Testdatenmanagement Der Prozess der Anforderungsanalyse an Testdaten, des Entwurfs von Testdatenstrukturen und der Erstellung und Wartung von Testdaten.
Testdefinitionsschicht Die Schicht in einer generischen Testautomatisierungsarchitektur, die die Testrealisierung durch Definition von Testsuiten und/oder Testfällen unterstützt, z.B. durch Anbieten von Vorlagen bzw. Richtlinien.
Testdurchführung Der Prozess der Ausführung eines Tests für eine Komponente oder ein System, der Istergebnisse erzeugt.
Testdurchführungsverfahren Die Methode, mit der die Tests tatsächlich – entweder manuell oder automatisiert – ausgeführt werden.
Testebene Siehe Teststufe.
Testeingabe Die Daten, die das Testobjekt während der Testdurchführung von einer externen Quelle empfängt. Die externe Quelle kann Hardware, Software oder ein Mensch sein.
Testeingangsprüfung Eine spezielle Ausprägung eines Smoke-Tests, um entscheiden zu können, ob eine Komponente oder ein System die notwendige Testreife hat.

Eine Testeingangsprüfung findet typischerweise zu Beginn einer Testausführungsphase statt.

Siehe auch Smoke-Test.

Testelement Das einzelne Element, das getestet wird. Gewöhnlich existieren ein Testobjekt und viele Testelemente. Siehe auch Testobjekt.
Testen Der Prozess, der aus allen Aktivitäten des Lebenszyklus besteht (sowohl statisch als auch dynamisch), die sich mit der Planung, Vorbereitung und Bewertung eines Softwareprodukts und dazugehöriger Arbeitsergebnisse befassen. Ziel des Prozesses ist sicherzustellen, dass diese allen festgelegten Anforderungen genügen, dass sie ihren Zweck erfüllen, und etwaige Fehlerzustände zu finden.
Testen der Barrierefreiheit Testen, um festzustellen, wie leicht es Benutzern mit Behinderungen fällt, eine Komponente oder ein System zu benutzen. [Gerrard]
Testen in Paaren Zwei Personen, z.B. zwei Tester, ein Entwickler und ein Tester oder ein Benutzer und ein Tester arbeiten daran Fehlerzustände zu finden. Typischerweise teilen sie sich während des Testens einen Computer gleichberechtigt.
Testen mit orthogonalen Arrays Eine systematische Technik zur Abdeckung aller paarweisen Kombinationen von Variablen durch den Einsatz orthogonaler Arrays. Im Vergleich zum Test aller Kombinationen von Variablen wird dadurch die Zahl der Testfälle signifikant reduziert. Siehe auch n-weises Testen, paarweises Testen.
Testen von ungültigen Eingaben Ein Test, der Eingabewerte verwendet, die durch eine Komponente oder ein System zurückgewiesen werden sollten.

Siehe auch Fehlertoleranz, Negativtest.

Testendekriterien Siehe Endekriterien.
Testentwurf (1) Siehe Testentwurfsspezifikation.

(2) Der Vorgang, allgemeine Testziele in handfeste Testbedingungen und Testfälle zu überführen.

Testentwurfsspezifikation Ein Ergebnisdokument, das die Testbedingungen für ein Testobjekt, die detaillierte Testvorgehensweise und die zugeordneten abstrakten Testfälle identifiziert. [Nach IEEE 829]

Siehe auch Testspezifikation.

Testentwurfsverfahren Eine Vorgehensweise, nach der Testfälle abgeleitet oder ausgewählt werden.
Testentwurfswerkzeug Ein Werkzeug zur Erzeugung von Testdaten entweder (a) auf Basis einer Spezifikation, die in einem CASE Repository (z.B. in einem Anforderungsmanagementwerkzeug) abgelegt sein kann, oder (b) aus spezifizierten Testbedingungen, die im Testentwurfswerkzeug selbst abgelegt sind, oder (c) aus dem Code selbst.
Tester Eine sachkundige Fachperson, die am Testen einer Komponente oder eines Systems beteiligt ist.
Testergebnis Siehe Ergebnis.
Testfall Umfasst folgende Angaben: die für die Ausführung notwendigen Vorbedingungen, die Menge der Eingabewerte (ein Eingabewert je Parameter des Testobjekts), die Menge der vorausgesagten Ergebnisse, sowie die erwarteten Nachbedingungen. Testfälle werden entwickelt im Hinblick auf ein bestimmtes Ziel bzw. auf eine Testbedingung, wie z.B. einen bestimmten Programmpfad auszuführen oder die Übereinstimmung mit spezifischen Anforderungen zu prüfen (wie Eingaben an das Testobjekt zu übergeben und Sollwerte abzulesen sind). [Nach IEEE 610]
Testfallentwurfsverfahren Siehe Testentwurfsverfahren.
Testfallergebnis Die finale Bewertung der Testdurchführung und ihrer Ergebnisse, wie bestanden, fehlgeschlagen oder fehlerhaft. Letzteres wird für Situationen benutzt, in denen nicht klar ist, ob das Problem im Testobjekt liegt.
Testfallexplosion Der unverhältnismässige Anstieg der Zahl an Testfällen mit ansteigender Größe der Testbasis, bei Anwendung einer bestimmten Testentwurfsverfahren. Testfallexplosion tritt ggf. auch auf, wenn das Testentwurfsverfahren zum ersten Mal systematisch angewendet wird.
Testfallspezifikation Ein Dokument, das eine Menge von Testfällen für ein Testobjekt spezifiziert (inkl. Testdaten und Vor-/Nachbedingung), bei dem die Testfälle jeweils Ziele, Eingaben, Testaktionen, vorausgesagte Ergebnisse und Vorbedingungen für die Ausführung enthalten. [Nach IEEE 829].

Siehe auch Testspezifikation.

Testfallsuite Siehe Testsuite.
Testfortschrittsbericht Ein Dokument, das die Testaktivitäten und -ergebnisse zusammenfasst, und das in regelmäßigen Zeiträumen erstellt wird. Es berichtet über den Fortschritt der Testaktivitäten gegenüber einer definierten Vergleichsbasis (wie z.B. dem ursprünglichen Testkonzept) und kommuniziert Risiken und Alternativen, die eine Managemententscheidung erfordern.
Testgenerator Siehe Testdateneditor und -generator.
Testgenerierungsschicht Die Schicht in einer generischen Testautomatisierungsarchitektur, die den manuellen oder automatisierten Entwurf von Testsuiten und/oder Testfällen unterstützt.
testgetriebene Entwicklung Ein Entwicklungsvorgehen bei dem die Entwicklung der Testfälle und oft auch ihre Automatisierung vor der Entwicklung der Software erfolgen.
Testinfrastruktur Die organisatorischen Elemente, die für die Durchführung des Tests benötigt werden, bestehend aus Testumgebung, Testwerkzeugen, Büroräumen, Verfahren usw.
Testkomparator Werkzeug zum automatischen Vergleich der tatsächlichen (Ist-) mit den vorausgesagten (Soll-) Ergebnissen.
Testkonzept Ein Dokument, das u.a. den Gültigkeitsbereich, die Vorgehensweise, die Ressourcen und die Zeitplanung der beabsichtigten Tests mit allen Aktivitäten beschreibt.

Es identifiziert u.a. die Testobjekte, die zu testenden Features und die Testaufgaben. Es ordnet den Testaufgaben die Tester zu und legt den Unabhängigkeitsgrad der Tester fest. Es beschreibt die Testumgebung, die Testentwurfsverfahren und die anzuwendenden Verfahren zur Messung der Tests, und begründet deren Auswahl. Außerdem werden Risiken beschrieben, die eine Planung für den Fall des Eintretens erfordern. Ein Testkonzept ist somit die Niederschrift des Testplanungsprozesses. [Nach IEEE 829]

Testlauf Die Ausführung eines oder mehrerer Testfälle mit einer bestimmten Version des Testobjekts.
Testlaufprotokoll Siehe Testprotokoll.
Testleistungsindikator Eine auf Effektivität und/oder Effizienz bezogene Metrik auf höherer Ebene, die zur Lenkung und Steuerung progressivem Testmanagements einer fortlaufenden Entwicklung des Testprozesses verwendet wird (z.B. Fehlerfindungsrate).
Testleitbild Der Zweck des Testens für eine Organisation, oft als Teil der Testrichtlinie dokumentiert. Siehe auch Testrichtlinie.
Testleiter Siehe Testmanager.
Testmanagement Planung, Aufwandsschätzung, Überwachung und Kontrolle von Testaktivitäten, die üblicherweise durch einen Testmanager erfolgen.
Testmanagementwerkzeug Ein Werkzeug, das das Management und die Steuerung eines Testprozesses unterstützt und verschiedene Leistungsmerkmale umfasst: Management der Testmittel, zeitliche Planung der Reihenfolge der durchzuführenden Tests, Protokollierung der Ergebnisse, Fortschrittsüberwachung, Fehler- und Abweichungsmanagement und Testabschlussberichterstattung.
Testmanager Die Person, die für das Management der Testaktivitäten, der Testressourcen und für die Bewertung des Testobjekts verantwortlich ist. Zu den Aufgaben gehören Anleitung, die Steuerung, die Verwaltung, Planung und Regelung der Aktivitäten zur Bewertung des Testobjekts.
Testmenge Siehe Testsuite.
Testmittel Alle Artefakte, die während des Testprozesses erstellt werden und die erforderlich sind, um die Tests zu planen, zu entwerfen oder auszuführen.

Dazu gehören: Dokumente, Skripte, Eingabedaten, erwartete Ergebnisse, Prozeduren zum Aufsetzen und Aufräumen von Testdaten, Dateien, Datenbanken, Umgebungen und weitere zusätzliche Software– und Dienstprogramme, die für das Testen verwendet werden. [Nach Fewster und Graham]

Testmodell Ein Modell, das die Testmittel beschreibt, die zum Testen einer Komponente oder eines zu testenden Systems genutzt werden.
Testmonitor Ein Softwarewerkzeug oder eine Hardwareeinheit, die parallel zu dem zu testenden System/der Komponente arbeitet und den Betrieb überwacht, aufzeichnet und/oder analysiert. [Nach IEEE 610]
Testobjekt Die Komponente oder das System, welches getestet wird. Siehe auch Testelement.
Testobjektübergabebericht Siehe Release Note.
Testorakel Informationsquelle zur Ermittlung der jeweiligen vorausgesagten Ergebnisse, die mit den tatsächlichen Ergebnissen einer Software im Test zu vergleichen sind.

Anmerkung: Ein Testorakel kann ein existierendes System (als Benchmark), ein Benutzerhandbuch oder das Spezialwissen einer Person sein, sollte aber nicht der Code sein. [Nach Adrion]

Testphase Eine abgegrenzte Menge von Testaktivitäten, die einer Projektphase zugeordnet sind, z.B. Ausführungsaktivitäten einer Teststufe. [Nach Gerrard]
Testplan Eine Liste von Aktivitäten, Aufgaben oder Ereignissen des Testprozesses, mit Angabe ihrer geplanten Anfangs- und Endtermine sowie ihrer gegenseitigen Abhängigkeiten.
Testplanung Eine Aktivität im Testprozess zur Erstellung und Fortschreibung des Testkonzepts.
Testprotokoll Eine chronologische Aufzeichnung von Einzelheiten der Testausführung. [IEEE 829]
Testprotokollierung Der Prozess der Aufzeichnung von Informationen über durchgeführte Tests in einem Testprotokoll.
Testprozess Der fundamentale Testprozess umfasst die folgenden Aktivitäten: Planung und Steuerung, Analyse und Design, Realisierung und Durchführung, Bewertung und Berichterstattung sowie den Abschluss der Testaktivitäten.
Testprozessgruppe Team von (Test-) Spezialisten, welche die Definition, Pflege und Verbesserung der von der Organisation verwendeten Prozesse fördern. [Nach CMMI]
Testprozessverbesserer Person, welche Verbesserungen am Testprozess auf der Grundlage des Testverbesserungskonzepts vornimmt.
Testprozessverbesserung Ein Programm an Aktivitäten, um die Leistungsfähigkeit und Reife des Testprozesses einer Organisation zu verbessern, und die Ergebnisse eines solchen Programms.
Testprozessverbesserungsmanifest Angelehnt an das agile Manifest. Definiert die Werte für die Verbesserung des Testprozesses. Diese Werte sind:

– Flexibilität ist wichtiger als detaillierte Prozesse

– Bewährte Verfahren sind wichtiger als Vorlagen.

– Ausrichtung auf die Lieferung ist wichtiger als Prozessorientierung

Peer Reviews sind wichtiger als (Abteilungen für) Qualitätssicherung

– Fokus auf das Geschäft ist wichtiger als Fokus auf das Modell. [Veenendaal08].

Testpunktanalyse Eine formelbasierte Schätzmethode für das Testen auf Grundlage der Funktionspunktanalyse. [TMap]
Testrahmen Eine Testumgebung, die aus den für die Testausführung benötigten Treibern und Platzhaltern besteht.
Testrealisierung Prozess der Entwicklung und Priorisierung von (konkreten) Testfällen, Erstellung von Testdaten und, optional, Vorbereitung von Testrahmen und Schreiben von automatisierten Testskripten.
Testreproduzierbarkeit Die Eigenschaft eines Tests, bei jeder Testausführung die gleichen Ergebnisse zu erzeugen.
Testrichtlinie Ein Dokument, das auf hohem Abstraktionsniveau die Prinzipien, den Ansatz und die wichtigsten Ziele einer Organisation in Bezug auf das Testen zusammenfasst.
Testschätzung Ermittelte Näherung eines Ergebnisses zu einem Aspekt des Testens (z.B. Aufwand, Endzeitpunkt, erforderliche Kosten, Anzahl der Testfälle usw.), das auch dann brauchbar ist, wenn die Eingabedaten unvollständig, unsicher oder gestört sind.
Testsituation Siehe Testbedingung.
Testsitzung Ein ununterbrochener Zeitraum, der mit Testdurchführung verbracht wird. Beim explorativen Testen konzentriert sich jede Sitzung auf eine Test-Charta, aber die Tester können in dieser Zeit auch neue Möglichkeiten oder Angelegenheiten erkunden. Der Tester erstellt Testfälle und führt sie durch und hält deren Fortschritt fest.

Siehe auch exploratives Testen.

Testskript Bezeichnet üblicherweise eine Testablaufspezifikation, insbesondere eine automatisierte.
Testsoll Eine Menge von Testendekriterien.
Testspezifikation Ein Dokument, das aus der Testentwurfspezifikation, der Testfallspezifikation und/oder der Testablaufspezifikation besteht.
Testspezifikationsverfahren Siehe Testentwurfsverfahren.
Teststeuerung Als Teststeuerung bezeichnet man die Managementaufgabe zur Entwicklung und Anwendung von Korrekturmaßnahmen, um in einem Testprojekt eine Abweichung vom geplanten Vorgehen zu beherrschen.

Siehe auch Testmanagement.

Teststrategie Abstrakte Beschreibung der vorgesehenen Teststufen und der Art und Weise, wie innerhalb dieser Teststufen vorzugehen ist, für eine Organisation oder ein Programm – gültig für ein oder mehrere Projekte.
Teststufe Eine Teststufe ist eine Gruppe von Testaktivitäten, die gemeinsam ausgeführt und verwaltet werden. Teststufen sind mit Zuständigkeiten in einem Projekt verknüpft. Beispiele für Teststufen sind der Komponententest, der Integrationstest, der Systemtest und der Abnahmetest. [Nach TMap]
Testsuite Die Zusammenstellung (Aggregation) mehrerer Testfälle für den Test einer Komponente oder eines Systems, bei der Nachbedingungen des einen Tests als Vorbedingungen des folgenden Tests genutzt werden können.
Testszenario Siehe Testablaufspezifikation.
Testtreiber Siehe Treiber.
Testüberdeckung Siehe Überdeckungsgrad.
Testüberwachung Eine Testmanagementaufgabe, die sich auf die periodische Überwachung des Testfortschritts bezieht. In der Testabschlussberichterstattung wird die tatsächliche Situation mit dem Plan verglichen.

Siehe auch Testmanagement.

Testumgebung Eine Umgebung, die benötigt wird, um Tests auszuführen. Sie umfasst Hardware, Instrumentierung, Simulatoren, Softwarewerkzeuge und andere unterstützende Hilfsmittel. [Nach IEEE 610]
Testunterbrechungskriterien Die Kriterien, die verwendet werden, um temporär sämtliche oder einen Teil der Testaktivitäten zu stoppen. [Nach IEEE 829]
Testverbesserungskonzept Ein Konzept zur Verbesserung des Testprozesses, das auf einem umfassenden Verständnis der Stärken und Schwächen des bestehenden Testprozesses basiert und beschreibt, wie die Verbesserungsziele erreicht werden können. [Nach CMMI]
Testverfahren Siehe Testentwurfsverfahren.
Testvergleich Der Prozess der Identifikation von Unterschieden zwischen den tatsächlichen und vorausgesagten Ergebnissen für einen Testfall. Ein Vergleich der Ergebnisse kann während des Tests oder nach dem Test durchgeführt werden.
Testvorgehensweise Die Umsetzung einer Teststrategie in einem spezifischen Projekt. Typischerweise enthält sie die getroffenen Entscheidungen zur Erreichung der (Test-)Projektziele, die Ergebnisse der Risikoanalyse, die Testentwurfsverfahren, die Endekriterien und die geplanten durchzuführenden Tests (Testarten).
Testvorrichtung Siehe Testumgebung.
Testwerkzeug Ein Werkzeug, das eine oder mehrere Testaktivitäten, wie Planung und Steuerung, Spezifikation, Erstellung von Testdaten, Testdurchführung und Bewertung, unterstützt. [TMap]

Siehe auch CAST.

Testziel Ein Grund oder Zweck für den Entwurf und die Ausführung von Tests.
Testzyklus Durchführung des Testprozesses für ein einzelnes bestimmtes Release des Testobjekts.
TMMi Akronym für Test Maturity

Model Integration.

Toleranz gegen Fehleingaben Die Fähigkeit eines Systems oder einer Komponente, das spezifizierte Leistungsniveau trotz Fehleingaben beizubehalten. [Nach IEEE 610]
Top-Down-Integrationstest Ein inkrementeller Ansatz zum Integrationstest, bei dem die Komponenten an der Spitze der Komponentenhierarchie zuerst getestet werden und die Komponenten der unteren Hierarchieebenen durch Platzhalter simuliert werden. Getestete Komponenten werden verwendet, um die Komponenten der darunterliegenden Ebenen zu testen. Dieser Prozess wird solange wiederholt, bis die Komponenten der untersten Ebene getestet wurden. Siehe auch Integrationstest.
Total Quality Management Auf der Mitwirkung aller Mitarbeiter beruhender Managementansatz einer Organisation, der Qualität in den Mittelpunkt stellt und durch Zufriedenstellung der Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder des Unternehmens und für die Gesellschaft zielt. Das Total Quality Management beinhaltet Planung, Organisation, Führung, Kontrolle und Absicherung. [Nach ISO 8402]
toter Code Siehe unerreichbarer Code.
TPA Akronym für Testpunktanalyse.
TPG Akronym für Testprozessgruppe.
TPI Next Ein durchgängiges Rahmenwerk für die Testprozessverbesserung, das die Schlüsselelemente eines effektiven und effizienten Testprozesses beschreibt.
TQM Akronym für Total Quality Management.
Transaktionsanalyse Die Analyse von Transaktionen zwischen Personen und im menschlichen Bewusstsein. Eine Transaktion ist dabei definiert als ein Auslöser und eine Antwort. Transaktionen finden zwischen Personen statt und zwischen den Ego-Zuständen (Persönlichkeitsbereichen) innerhalb des Bewusstseins einer einzelnen Person.
transzendenzbasierte Qualität Eine Qualitätsdarstellung, bei der Qualität nicht genau definiert werden kann, aber man erkennt, wenn sie vorhanden ist, und man nimmt ihre Abwesenheit wahr. Qualität hängt ab von der Wahrnehmung und den Gefühlen von Einzelpersonen oder Personengruppen für ein Produkt. [Nach Garvin]

Siehe auch benutzerbasierte Qualität, herstellungsbasierte Qualität, produktbasierte Qualität, wertbasierte Qualität.

Treiber Ein Testwerkzeug, das eine zu testende Komponente/ein System aufruft und/oder steuert. [Nach TMap]
U
Überdeckungsanalysator Ein Werkzeug, welches objektiv misst, zu welchem Grad die Strukturelemente durch eine Testsuite ausgeführt werden.
Überdeckungsanalyse Die Messung der erreichten Überdeckung für ein spezifiziertes Überdeckungselement während der Testausführung. Sie misst mit Bezug auf ein vorher festgelegtes Kriterium, um festzustellen, ob zusätzliches Testen nötig ist, und sofern dies der Fall ist, welche Testfälle noch notwendig sind.
Überdeckungselement Eine Einheit oder eine Eigenschaft als Basis für den Überdeckungsgrad, z.B. Äquivalenzklasse oder Anweisung auf Implementierungsebene.
Überdeckungsgrad Der Grad, ausgedrückt in Prozent, zu dem ein spezifiziertes Überdeckungselement (z.B. Zweig) durch eine Testsuite ausgeführt wurde.
Überdeckungsmessungswerkzeug Siehe Überdeckungsanalysator.
Übernahmetest Siehe Smoke-Test.
Übertragbarkeit Die Einfachheit, mit der eine Software von einer Hardware- oder Softwareumgebung in eine andere übertragen werden kann. [ISO 9126]
Umgebungsintegrationstest Eine Form des Intergrationstests, bei der all diejenigen Knoten Basis für den Integrationstest sind, die mit einem vorgegebenen Knoten verbunden sind.
unabhängiges Testen Das Trennen der Verantwortungen von Analyse/Entwicklung und Test, um unvoreingenommenes Testen zu fördern. [Nach DO-178b]
unerreichbarer Code Code, der nicht erreicht werden kann und deshalb nicht ausgeführt werden kann.
Unit Siehe Komponente.
Unittest Siehe Komponententest.
Unittest-Framework Ein Werkzeug, das eine Umgebung für einen Komponententest bereitstellt. In dieser Umgebung wird die Komponente isoliert oder mit geeigneten Treibern und Platzhaltern getestet. Darüber hinaus wird dem Entwickler zusätzliche Unterstützung (z.B. Debugging) zur Verfügung gestellt. [Graham]
Unternehmens-Dashboard Eine übersichtliche Darstellung der derzeitigen Unternehmensperformanzdaten. Siehe auch balanced scorecard, dashboard.
Untersuchungseffekt Der Effekt/der Einflussnahme auf eine Komponente oder ein System durch die Messung, z.B. durch ein Lasttestwerkzeug oder durch einen Monitor. So kann sich etwa die Performanz verschlechtern, wenn ein Lasttestwerkzeug verwendet wird.
Ursachenanalyse Siehe Grundursachenanalyse.
Ursache-Wirkungs-Analyse Siehe Ursache-Wirkungs-Graph.
Ursache-Wirkungs-Diagramm Eine graphische Darstellung zur Organisation und Darstellung der Zusammenhänge verschiedener möglicher Ursachen eines Problems . Mögliche Gründe einer echten oder potentiellen Fehlerursache oder -wirkung sind in Kategorien und Subkategorien einer horizontalen Baumstruktur organisiert, deren Wurzelknoten die (potentielle) Fehlerursache/-wirkung darstellt. [Nach Juran]
Ursache-Wirkungs-Entscheidungstabelle Siehe Entscheidungstabelle.
Ursache-Wirkungs-Graph Eine graphische Darstellung der Eingaben und/oder Auslöser (Ursachen) und der zugeordneten Ausgaben (Wirkungen), die für den Entwurf von Testfällen verwendet werden können.
Ursache-Wirkungs-Graph-Analyse Ein Black-Box-Testentwurfsverfahren, bei dem die Testfälle unter Nutzung des Ursache-Wirkungs-Graphen entworfen werden. [BS 7925/2]
User-Story Eine in Alltags- oder Geschäftssprache formulierte Benutzer- oder Geschäftsanforderung auf hoher Abstraktionsebene. User-Storys werden oft in der agilen Softwareentwicklung benutzt und erfassen die Funktionalität, welche ein Benutzer benötigt, nicht-funktionale Kriterien und auch Abnahmekriterien. Siehe auch agile Softwareentwicklung, Anforderung.
User-Story-basiertes Testen Ein Black-Box-Testverfahren, bei welchem Testfälle auf Basis von User-Storys entworfen werden, um deren korrekte Implementierung zu verifizieren. Siehe User-Story.
V
Validierung Bestätigung durch Bereitstellung eines

objektiven Nachweises, dass die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine spezifische beabsichtigte Anwendung erfüllt worden sind. [ISO 9000]

Variable Ein Speicherelement in einem Computer, das innerhalb eines Softwareprogramms über seinen Namen angesprochen werden kann.
verbilligter Gebrauchstauglichkeitstest Eine Teststrategie beim Gebrauchstauglichkeitstest, die Wert darauf legt, die Kosten niedrig zu halten, ohne dabei die Qualität der Bewertung der Gebrauchstauglichkeit zu sehr zu beeinträchtigen.
Verfügbarkeit Der Grad, zu dem eine Komponente oder ein System im operativen Betrieb bzw. für die Nutzung zur Verfügung steht. [IEEE 610]

Siehe auch Zuverlässigkeit.

Vergleich (nach Ausführung) Vergleich des aktuellen mit dem vorausgesagten Ergebnis. Der Vergleich erfolgt nach Abschluss der Testdurchführung.
Verifizierung Bestätigung durch Bereitstellung eines

objektiven Nachweises, dass

festgelegte Anforderungen erfüllt worden sind. [ISO 9000]

verkürzte Auswertung Eine Programmiersprachen/Interpreter-Technik für die Auswertung von zusammengesetzten Bedingungen, bei welcher eine Bedingung auf der einen Seite eines logischen Operators nicht ausgewertet wird, falls die Bedingung auf der anderen Seite ausreicht, um das Endergebnis zu bestimmen.
Verschlüsselung Das Kodieren von Information, so dass nur Beteiligte mit Berechtigung die Originalinformation zurückgewinnen können, meistens mithilfe eines speziellen Dekodierungs-Schlüssels oder -Prozesses.
Versionskontrolle Siehe Konfigurationskontrolle.
Verständlichkeit Die Fähigkeit eines Softwareprodukts, den Benutzer in die Lage zu versetzen zu verstehen, ob die Software geeignet ist, und wie sie für für eine bestimmte Aufgabe und Benutzungsbedingungen brauchbar ist. [ISO 9126]

Siehe auch Gebrauchstauglichkeit.

vertikale Rückverfolgbarkeit Die Rückverfolgung von Anforderungen durch die Ebenen der Entwicklungsdokumentation bis zu den Komponenten.
V-Modell Vorgehensmodell für die Softwareentwicklung, um die Aktivitäten des Software-Entwicklungslebenszyklus von der Anforderungsspezifikation bis zur Wartung zu beschreiben. Das V-Modell stellt dar, wie Prüf- und Testaktivitäten in jede Phase des Software-Entwicklungslebenszyklus integriert und die Zwischenprodukte geprüft (validiert und verifiziert) werden können.

Anmerkung: Hier ist das allgemeine Vorgehensmodell von Barry Boehm gemeint.

vollständiger Test Siehe erschöpfender Test.
Volumentest Ein Test, bei dem große Datenvolumen manipuliert werden oder das System durch große Datenmengen beansprucht wird.

Siehe auch Test der Ressourcennutzung, Lasttest, Stresstest.

vorausgesagtes Ergebnis Das Verhalten eines Systems oder einer Komponente unter festgelegten Bedingungen, das durch die Spezifikation oder durch eine andere Quelle festgelegt ist.

Siehe auch Testorakel.

Vorbedingung Bedingungen an den Zustand des Testobjekts und seiner Umgebung, die vor der Durchführung eines Testfalls oder Testablaufs erfüllt sein müssen.
Vortest Siehe Testeingangsprüfung.
W
Walkthrough Eine schrittweise Präsentation eines Dokuments durch den Autor, um Informationen zu sammeln und ein gemeinsames Verständnis des Inhalts aufzubauen. [Freedman und Weinberg], [IEEE 1028]

Siehe auch Peer Review.

WAMMI Akronym für Website Analysis and MeasureMent Inventory.
Wartbarkeit/Änderbarkeit Die Leichtigkeit, mit der ein Softwareprodukt zur Korrektur von Fehlerzuständen, wegen neuer Anforderungen, zur Verbesserung der Wartung oder zur Anpassung an eine veränderte Umgebung geändert werden kann. [ISO 9126]
Wartbarkeitstest Testen, um die Änderbarkeit eines Softwareprodukts zu bestimmen.
Wartung Modifikation eines Softwareprodukts nach seiner Auslieferung, um Fehlerzustände zu korrigieren, die Performanz oder andere Merkmale zu verbessern oder das Produkt für eine andere Umgebung zu adaptieren. [IEEE 1219]
Wartungstest Testen der Änderungen an einem laufenden System oder der Auswirkungen einer geänderten Umgebung auf ein laufendes System.
WCAG Akronym für Web Content Accessibility Guidelines (Richtlinie für barrierefreie Webinhalte).
webseitenübergreifendes Skripten Eine Sicherheitsschwachstelle, die es Angreifern erlaubt, bösartigen Code in eine ansonsten gutartige Webseite einzufügen [NIST.IR.7298].
Website Analysis and MeasureMent Inventory Ein fragebogenbasiertes Verfahren des Gebrauchstauglichkeitstests zum Messen der Softwarequalität einer Webseite aus der Sicht des Endbenutzers.
wertbasierte Qualität Eine Qualitätsdarstellung, bei der Qualität durch den Preis bestimmt wird. Produkte oder Dienstleistungen sind von guter Qualität, wenn sie die gewünschte Leistung für akzeptable Kosten erbringen. Qualität wird in einem Entscheidungsprozess mit Stakeholdern durch die Abwägung der zeitlichen Aufwands- und Kosten-Aspekte bestimmt.

Siehe auch benutzerbasierte Qualität, herstellungsbasierte Qualität, produktbasierte Qualität, transzendenzbasierte Qualität.

Wertebereich Die Menge, aus der gültige Eingabe– und/oder Ausgabewerte gewählt werden.
Wertebereichsanalyse Ein Black-Box-Testentwurfsverfahren zur Ermittlung von effizienten und effektiven Testfällen, wenn mehrere Variablen zusammen getestet werden können oder sollen. Es basiert auf Äquivalenzklassenbildung und Grenzwertanalyse, und verallgemeinert diese Verfahren. Siehe auch Grenzwertanalyse, Äquivalenzklassenbildung.
White-Box-Test Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
White-Box-Testentwurfsverfahren Ein dokumentiertes Verfahren zur Herleitung und Auswahl von Testfällen, basierend auf der internen Struktur einer Komponente oder eines Systems.
White-Box-Verfahren Siehe White-Box-Testentwurfsverfahren.
Wiederaufnahme-Anforderungen Die definierte Menge von Aktivitäten, welche wiederholt werden muss, wenn das Testen nach einer Unterbrechung wiederaufgenommen wird. [Nach IEEE 829]
Wiederaufnahmekriterien Die Testaktivitäten, die wiederholt werden müssen, nachdem ein unterbrochener Test wiederaufgenommen wird. [Nach IEEE 829]
Wiederherstellbarkeit Die Fähigkeit eines Softwareprodukts, bei einer Fehlerwirkung das spezifizierte Leistungsniveau des Systems wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen. [ISO 9126]

Siehe auch Zuverlässigkeit.

Wiederherstellbarkeitstest Testen, um die Wiederherstellbarkeit eines Softwareprodukts zu ermitteln.

Siehe auch Zuverlässigkeitstest.

Wiederherstellungstest Siehe Wiederherstellbarkeitstest.
wilder Zeiger Ein Zeiger, der auf eine Speicherstelle verweist, die außerhalb des Gültigkeitsbereichs dieses Zeigers ist oder die nicht existiert. Siehe auch Zeiger.
X
XP Akronym für Extreme Programming.
Z
Zeiger Ein Datenelement, das die Adresse eines anderen Datenelements enthält, zum Beispiel ein Datenelement, das die Adresse des nächsten zu verarbeitenden Mitarbeitersatzes enthält. [IEEE 610]
Zeitverhalten Siehe Performanz.
Zertifizierung Der Prozess der Bestätigung, dass Komponenten, Systeme oder Personen die für sie spezifizierten Anforderungen erfüllen, z.B. durch Bestehen einer Prüfung.
Zufallstest Ein Black-Box-Testentwurfsverfahren, bei dem Testfälle, unter Umständen unter Verwendung eines pseudozufälligen Generierungsalgorithmus, ausgewählt werden, um einem Nutzungsprofil in der Produktivumgebung zu entsprechen.
Zugriffssicherheitstest Die Durchführung von Tests, um die Sicherheit (im Sinne von Zugriffsschutz) eines Softwareprodukts zu bestimmen.

Siehe auch Funktionalitätstest.

zusammengesetzte Bedingung Zwei oder mehrere einfache Bedingungen, die durch logische Operatoren (AND, OR oder XOR) miteinander verknüpft werden (z.B. A>B AND C>1000).
Zustandsautomat Ein Berechnungsmodell, bestehend aus einer endlichen Anzahl von Zuständen und Zustandsübergängen, ggf. mit begleitenden Aktionen. [IEEE 610]
zustandsbasierter Test Ein Black-Box-Testentwurfsverfahren, mit dem Testfälle entworfen werden, um gültige und ungültige Zustandsübergänge zu prüfen.

Siehe auch N-Switch-Test.

Zustandsdiagramm Ein Diagramm, das die Zustände beschreibt, die ein System oder eine Komponente annehmen kann, und die Ereignisse bzw. Umstände zeigt, die einen Zustandswechsel verursachen und/oder ergeben. [IEEE 610]
Zustandstest Siehe zustandsbasierter Test.
Zustandsübergang Ein Übergang zwischen zwei Zuständen einer Komponente oder eines Systems.
Zustandsübergangstabelle Eine Tabelle, die für jeden Zustand in Verbindung mit jedem möglichen Ereignis die resultierenden Übergänge darstellt. Das können sowohl gültige als auch ungültige Übergänge sein.
Zuverlässigkeit Eine Menge von Merkmalen, die sich auf die Fähigkeit einer Software/eines Systems beziehen, ihr/sein Leistungsniveau unter festgelegten Bedingungen über einen festgelegten Zeitraum oder über eine festgelegte Anzahl von Transaktionen zu bewahren. [ISO 9126]
Zuverlässigkeitstest Testen, um die Zuverlässigkeit eines Softwareprodukts zu bestimmen.
Zuverlässigkeitswachstumsmodell Ein Modell, das ein auf Fehlerbehebungen begründetes Wachstum der Zuverlässigkeit einer Komponente oder eines Systems im Zeitverlauf zeigt.
Zweig Ein Basisblock, der zur Ausführung ausgewählt werden kann, basierend auf einem Programmkonstrukt, bei dem einer von zwei oder mehreren alternativen Pfaden möglich ist. Z.B. case, if-then-else.
Zweigbedingung Siehe (logische) Bedingung.
Zweigbedingungskombinationstesten Siehe Mehrfachbedingungstest.
Zweigbedingungskombinationsüberdeckung Siehe Mehrfachbedingungsüberdeckung.
Zweigbedingungsüberdeckung Siehe Bedingungsüberdeckung.
Zweigtest Ein White-Box-Testentwurfsverfahren, bei dem die Testfälle so entworfen werden, dass die Zweige durchlaufen werden.
Zweigüberdeckung Der Anteil der Zweige, die durch eine Menge von Testfällen ausgeführt wurden. Anmerkung: 100% Zweigüberdeckung schließt sowohl 100% Entscheidungsüberdeckung als auch 100 % Anweisungsüberdeckung ein.
zyklomatische Komplexität Die maximale Anzahl der linear unabhängigen Pfade in einem Programm. Die zyklomatische Komplexität kann wie folgt berechnet werden: L – N + 2P, wobei

L: Anzahl der Kanten eines Kontrollflussgraphen

N: Anzahl der Knoten eines Kontrollflussgraphen

P: Anzahl der Verbundkomponenten eines Kontrollflussgraphen (z.B. ein aufgerufener Kontrollflussgraph oder eine Unterroutine).

[Nach McCabe]

zyklomatische Zahl Siehe zyklomatische Komplexität.
A
abstract test case See high-level test case.
abuse case A use case in which some actors with malcious intent are causing harm to the system or to other actors.

See also use case.

acceptance criteria The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [After IEEE 610]
acceptance testing 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 [after IEEE 610].
accessibility The degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use. [ISO 25010] See also usability.
accessibility testing Testing to determine the ease by which users with disabilities can use the component or system [Gerrard].
account harvesting The process of obtaining lists of email addresses for use in bulk email messages.
accuracy The capability of the software product to provide the right or agreed results or effects with the needed degree of precision [ISO 9126].

See also functionality.

accuracy testing The process of testing to determine the accuracy of a software product. See also accuracy.
acting (IDEAL) The phase within the IDEAL model where the improvements are developed, put into practice, and deployed across the organization. The acting phase consists of the activities: create solution, pilot/test solution, refine solution and implement solution. See also IDEAL.
action word-driven testing See keyword-driven testing
actor User or any other person or system that interacts with the system under test in a specific way.
actual outcome See actual result.
actual result The behavior produced / observed when a component or system is tested under specified conditions.
ad hoc testing Testing carried out informally, no formal test preparation takes place, no recognized test design technique is used, there are no expectations for results and arbitrariness guides the test execution activity.
adaptability The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered [ISO 9126].

See also portability.

Agile Manifesto A statement on the values that underpin Agile software development. The values are: individuals and interactions over processes and tool, responding to change over following a plan, customer collaboration over contract negotiation, working software over comprehensive documentation.
agile software development A group of software development methodologies based on iterative incremental development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
agile testing Testing practice for a project using agile software development methodologies, incorporating techniques and methods, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm. See also test-driven development.
alpha testing Simulated or actual operational testing by potential customers/users or an independent test team at the software developers’ site, but outside the development organization. Alpha testing is employed for off-the-shelf software as a form of internal acceptance testing.
analytical test strategy A test strategy whereby the test team analyzes the test basis to identify the test conditions to cover.
analytical testing Testing based on a systematic analysis of e.g., product risks or requirements.
analyzability The capability of the software product to be diagnosed for deficiencies or causes of failures in the software, or for the parts to be modified to be identified [ISO 9126].

See also maintainability.

analyzer See static analyzer.
anomaly 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 [IEEE 1044].

See also defect, error, fault, failure, incident, problem.

anti-malware Software that is used to detect and inhibit malware. See also malware.
anti-pattern Repeated action, process, structure or reusable solution that initially appears to be beneficial and is commonly used but is ineffective and/or counterproductive in practice.
API Acronym for Application Programming Interface.
API testing Testing performed by submitting commands to the software under test using programming interfaces of the application directly.
assessment report A document summarizing the assessment results, e.g. conclusions, recommendations and findings. See also process assessment.
assessor A person who conducts an assessment; any member of an assessment team.
atomic condition A condition that cannot be decomposed, i.e., a condition that does not contain two or more single conditions joined by a logical operator (AND, OR, XOR).
attack See fault attack.
attack vector A path or means by which an attacker can gain access to a system for malicious purposes.
attack-based testing An experience-based testing technique that uses software attacks to induce failures, particularly security related failures. See also attack.
attacker A person or process that attempts to access data, functions or other restricted areas of the system without authorization, potentially with malicious intent.

See also hacker.

attractiveness The capability of the software product to be attractive to the user [ISO 9126].

See also usability.

audit An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify: (1) The form or content of the products to be produced (2) The process by which the products shall be produced (3) How compliance to standards or guidelines shall be measured [IEEE 1028].
audit trail A path by which the original input to a process (e.g. data) can be traced back through the process, taking the process output as a starting point. This facilitates result checking and allows a process audit to be carried out [after TMap].
authentication A procedure determining whether a person or a process is, in fact, who or what it is declared to be.

See also authorization

authorization Permission given to a user or process to access resources.

See also authentication

automated testware Testware used in automated testing, such as tool scripts.
automation code defect density Defect density of a component of the test automation code.
availability The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage [IEEE 610].
B
back-to-back testing See mutation testing.
balanced scorecard A strategic performance management tool for measuring whether the operational activities of a company are aligned with its objectives in terms of business vision and strategy. See also corporate dashboard, scorecard.
baseline A specification or software product that has been formally reviewed or agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control process [after IEEE 610].
basic block A sequence of one or more consecutive executable statements containing no branches.

Note: A node in a control flow graph represents a basic block.

basis test set A set of test cases derived from the internal structure of a component or specification to ensure that 100% of a specified coverage criterion will be achieved.
bebugging See fault seeding [Abbott].
benchmark test (1) A standard against which measurements or comparisons can be made. (2) A test that is to be used to compare components or systems to each other or to a standard as in (1) [after IEEE 610].
bespoke software See custom software.
best practice A superior method or innovative practice that contributes to the improved performance of an organization under given context, usually recognized as ´best` by other peer organizations.
beta testing Operational testing by potential and/or existing customers/users at an external site not otherwise involved with the developers, to determine whether or not a component of system satisfies the user needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing in order to acquire feedback from the market.
big-bang testing An integration testing approach in which software elements, hardware elements, or both are combined all at once into a component or an overall system, rather than in stages. [After IEEE 610] See also integration testing.
black-box technique See black-box test design technique.
black-box test design technique 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.
black-box testing Testing, either functional or non-functional, without reference to the internal structure of the component or system.
blocked test case A test case that cannot be executed because the preconditions for its execution are not fulfilled.
botnet A network of compromised computers, called bots or robots, which is controlled by a third party and used to transmit malware or spam, or to launch attacks.
bottom-up testing An incremental approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested. See also integration testing.
boundary value An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge, for example the minimum and maximum value of a range.
boundary value analysis A black-box test design technique in which test cases are designed based on boundary values. See also boundary value.
boundary value coverage The percentage of boundary values that have been exercised by a test suite.
branch A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available, e.g. case, if-then-else.
branch condition See condition.
branch condition combination coverage See multiple condition coverage.
branch condition combination testing See multiple condition testing.
branch condition coverage See condition coverage.
branch coverage The percentage of branches that have been exercised by a test case suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.
branch testing A white-box test design technique in which test cases are designed to execute branches.
buffer A device or storage area used to store data temporarily for differences in rates of data flow, time or occurrence of events, or amounts of data that can be handled by the devices or processes involved in the transfer or use of the data [IEEE 610].
buffer overflow A memory access failure due to the attempt by a process to store data beyond the boundaries of a fixed length buffer, resulting in overwriting of adjacent memory areas or the raising of an overflow exception. See also buffer.
bug See defect.
bug report See defect report.
bug taxonomy See defect taxonomy.
bug tracking tool See defect management tool.
build verification test A set of automated tests which validates the integrity of each new build and verifies its key/core functionality, stability and testability. It is an industry practice when a high frequency of build releases occurs (e.g., agile projects) and it is run on every new build before being released for further testing. See also smoke testing.
burndown chart A publicly displayed chart that depicts the outstanding effort versus time in a sprint (iteration). It shows the status and trend of completing the tasks of the sprint. The X-axis typically represents days in the sprint, while the Y-axis is effort remaining (usually either in ideal engineering hours or story points).
business process-based testing An approach to testing in which test design is based on descriptions and/or knowledge of business processes.
BVT Acronym for build verification test.
C
call graph An abstract representation of calling relationships between subroutines in a program.
Capability Maturity Model Integration A framework that describes the key elements of an effective product development and maintenance process. The Capability Maturity Model Integration covers best-practices for planning, engineering and managing product development and maintenance. [CMMI]
capture/playback A test automation approach, where inputs to the test object are recorded during manual testing in order to generate automated test scripts that could be executed later (i.e. replayed).
capture/playback tool A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that could be executed later (i.e. replayed). These tools are often used to support automated regression testing.
capture/replay tool See capture/playback tool.
CASE Acronym for Computer Aided Software Engineering.
CAST Acronym for Computer Aided Software Testing.
causal analysis See root cause analysis.
cause-effect analysis See cause/effect graphing.
cause-effect decision table See decision table.
cause-effect diagram A graphical representation used to organize and display the interrelationships of various possible root causes of a problem. Possible causes of a real or potential defect or failure are organized in categories and subcategories in a horizontal tree-structure, with the (potential) defect or failure as the root node. [After Juran]
cause-effect graph A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects), which can be used to design test cases.
cause-effect graphing A black-box test design technique in which test cases are designed from cause-effect graphs [BS 7925/2].
CCB Acronym for configuration control board.
certification The process of confirming that a component, system or person complies with its specified requirements, e.g. by passing an exam.
change control See configuration control.
change control board See configuration control board.
change management (1) A structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. (2) Controlled way to effect a change, or a proposed change, to a product or service. See also configuration management.
changeability The capability of the software product to enable specified modifications to be implemented [ISO 9126].

See also maintainability.

charter See test charter.
checker See reviewer.
checklist-based testing 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. See also experience-based testing.
Chow’s coverage metrics See N-switch coverage.
classification tree A tree showing equivalence partitions hierarchically ordered, which is used to design test cases in the classification tree method. See also classification tree method.
classification tree method A black-box test design technique in which test cases, described by means of a classification tree, are designed to execute combinations of representatives of input and/or output domains. [Grochtmann]
clear box testing See white-box testing.
CLI Acronym for Command-Line Interface.
CLI testing Testing performed by submitting commands to the software under test using a dedicated command-line interface.
CMMI Acronym for cCapability Maturity Model Integration.
code Computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler or other translator [IEEE 610].
code coverage 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.
code-based testing See white-box testing.
codependent behavior Excessive emotional or psychological dependence on another person, specifically in trying to change that person’s current (undesirable) behavior while supporting them in continuing that behavior. For example, in software testing, complaining about late delivery to test and yet enjoying the necessary “heroism” working additional hours to make up time when delivery is running late, therefore reinforcing the lateness.
co-existence The capability of the software product to co-exist with other independent software in a common environment sharing common resources [ISO 9126].

See also portability.

combinatorial testing A means to identify a suitable subset of test combinations to achieve a predetermined level of coverage when testing an object with multiple parameters and where those parameters themselves each have several values, which gives rise to more combinations than are feasible to test in the time allowed. See also classification tree method, n-wise testing, pairwise testing, orthogonal array testing.
commercial off-the-shelf 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.
comparator See test comparator.
compatibility testing See interoperability testing.
compiler A software tool that translates programs expressed in a high order language into their machine language equivalents [IEEE 610].
complete testing See exhaustive testing.
completion criteria See exit criteria.
complexity The degree to which a component or system has a design and/or internal structure that is difficult to understand, maintain and verify. See also cyclomatic complexity.
compliance The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions [ISO 9126].
compliance testing The process of testing to determine the compliance of the component or system.
component A minimal software item that can be tested in isolation.
component integration testing Testing performed to expose defects in the interfaces and in the interaction between integrated components.
component specification A description of a component´s function in terms of its output values for specified input values under specified conditions, and required non-functional attributes (e.g. resource-utilization).
component testing The testing of individual software components [after IEEE 610].
compound condition Two or more single condition joined by means of a logical operator (AND, OR or XOR), e.g. ‘A>B AND C>1000’.
computer forensics The practice of determining how a security attack has succeeded and assessing the damage caused.
concrete test case See low-level test case.
concurrency testing Testing to determine how the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or system. [After IEEE 610]
condition An logical expression that can be evaluated as True or False, e.g. A>B.

See also test condition.

condition combination coverage See multiple condition coverage.
condition combination testing See multiple condition testing.
condition coverage 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.
condition determination coverage See modified condition decision coverage.
condition determination testing See modified condition decision testing.
condition outcome The evaluation of a condition to TRUE or FALSE.
condition testing A white-box test design technique in which test cases are designed to execute condition outcomes.
confidence interval In managing project risks, the period of time within which a contingency action must be implemented in order to be effective in reducing the impact of the risk.
confidence test See smoke test.
configuration The composition of a component or system as defined by the number, nature, and interconnections of its constituent parts.
configuration auditing The function to check on the contents of libraries of configuration items, e.g. for standards compliance [IEEE 610].
configuration control An element of configuration management, consisting of the evaluation, co-ordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification [IEEE 610].
configuration control board (CCB) A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes [IEEE 610].
configuration identification An element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation [IEEE 610].
configuration item An aggregation of hardware, software or both, that is designated for configuration management and treated as a single entity in the configuration management process [IEEE 610].
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 610].
configuration management tool 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.

See also configuration management.

configuration testing See portability testing.
confirmation testing Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
conformance testing See compliance testing.
consultative test strategy A test strategy whereby the test team relies on the input of one or more key stakeholders to determine the details of the strategy.
consultative testing Testing driven by the advice and guidance of appropriate experts from outside the test team (e.g., technology experts and/or business domain experts).
content reference model See content-based model.
content-based model A process model providing a detailed description of good engineering practices, e.g. test practices.
context of use Users, tasks, equipment (hardware, software and materials), and the physical and social environments in which a software product is used. [ISO 9241-11]
continuous representation A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within specified process area [CMMI].
control chart A statistical process control tool used to monitor a process and determine whether it is statistically controlled. It graphically depicts the average value and the upper and lower control limits (the highest and lowest values) of a process.
control flow A sequence of events (paths) in the execution through a component or system.
control flow analysis A form of static analysis based on a representation of unique paths (sequences of events) in the execution through a component or system. Control flow analysis evaluates the integrity of control flow structures, looking for possible control flow anomalies such as closed loops or logically unreachable process steps.
control flow graph An abstract representation of all possible sequences of events (paths) in the execution through a component or system.
control flow path See path.
control flow testing An approach to structure-based testing in which test cases are designed to execute specific sequences of events. Various techniques exist for control flow testing, e.g., decision testing, condition testing, and path testing, that each have their specific approach and level of control flow coverage. See also decision testing, condition testing, path testing.
convergence metric A metric that shows progress toward a defined criterion, e.g., convergence of the total number of test executed to the total number of tests planned for execution.
conversion testing Testing of software used to convert data (e.g. from existing systems for use in replacement systems).
corporate dashboard A dashboard-style representation of the status of corporate performance data. See also balanced scorecard, dashboard.
cost of quality The total costs incurred on quality activities and issues and often split into prevention costs, appraisal costs, internal failure costs and external failure costs.
COTS Acronym for commercial off-the-shelf.
coverage The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite.
coverage analysis Measurement of achieved coverage to a specified coverage item during test execution referring to predetermined criteria to determine whether additional testing is required and if so, which test cases are needed.
coverage item An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements.
coverage measurement tool See coverage tool.
coverage tool A tool that provides measures of what structural elements have been exercised by the test suite.
critical success factor An element necessary for an organization or project to achieve its mission. Critical success factors are the critical factors or activities required for ensuring the success.
Critical Testing Processes A content-based model for test process improvement built around twelve critical processes. These include highly visible processes, by which peers and management judge competence and mission-critical processes in which performance affects the company’s profits and reputation. See also content-based model.
cross-site scripting A vulnerability that allows attackers to inject malicious code into an otherwise benign website [NIST.IR.7298].
CTP Acronym for Critical Testing Processes.
custom software Software developed specifically for a set of users or customers. The opposite is off-the-shelf software.
custom tool A software tool developed specifically for a set of users or customers.
cyclomatic complexity The maximum number of linear, independent paths through a program. Cyclomatic complexity may be computed as: L – N + 2P, where

– L = the number of edges/links in a graph

– N = the number of nodes in a graph

– P = the number of disconnected parts of the graph (e.g. a called graph or subroutine)

[After McCabe]

cyclomatic number See cyclomatic complexity.
D
daily build A development activity whereby a complete system is compiled and linked every day (often overnight), so that a consistent system is available at any time including all latest changes.
dashboard A representation of dynamic measurements of operational performance for some organization or activity, using metrics represented via metaphores such as visual “dials”, “counters”, and other devices resembling those on the dashboard of an automobile, so that the effects of events or activities can be easily understood and related to operational goals. See also corporate dashboard, scorecard.
data definition An executable statement where a variable is assigned a value.
data flow 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 [Beizer].
data flow analysis A form of static analysis based on the definition and usage of variables.
data flow coverage The percentage of definition-use pairs that have been exercised by a test case suite.
data flow testing A white-box test design technique in which test cases are designed to execute definition-use pairs of variables.
data obfuscation Data transformation that makes it difficult for a human to recognize the original data.
data privacy The protection of personally identifiable information or otherwise sensitive information from undesired disclosure
data quality An attribute of data that indicates correctness with respect to some pre-defined criteria, e.g., business expectations, requirements on data integrity, data consistency.
database integrity testing Testing the methods and processes used to access and manage the data(base), to ensure access methods, processes and data rules function as expected and that during access to the database, data is not corrupted or unexpectedly deleted, updated or created.
data-driven testing 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. [Fewster and Graham] See also keyword-driven testing.

DDP Acronym for Defect Detection Percentage.
dd-path A path between two decisions of an algorithm, or two decision nodes of a corresponding graph, that includes no other decisions. See also path.
dead code See unreachable code.
debugger See debugging tool.
debugging The process of finding, analyzing and removing the causes of failures in software.
debugging tool A tool used by programmers to reproduce failures, investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step by step, to halt a program at any program statement and to set and examine program variables.
decision A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.
decision condition coverage The percentage of all condition outcomes and decision outcomes that have been exercised by a test suite. 100% decision condition coverage implies both 100% condition coverage and 100% decision coverage.
decision condition testing A white-box test design technique in which test cases are designed to execute condition outcomes and decision outcomes.
decision coverage 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.
decision outcome The result of a decision (which therefore determines the branches to be taken).
decision table 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.
decision table testing A black-box test design technique in which test cases are designed to execute combinations of inputs and/or stimuli (causes) shown in a decision table. [Egler63]

See also decision table.

decision testing A white-box test design technique in which test cases are designed to execute decision outcomes.
defect 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. A defect, if encountered during execution, may cause a failure of the component or system.
defect category See defect type.
defect density The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms for that product, e.g. lines-of-code or function points).
Defect Detection Percentage The number of defects found by a test phase, divided by the number found by that test phase and any other means afterwards.
defect management The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact [after IEEE 1044].
defect management committee A cross-functional team of stakeholders who manage reported defects from initial detection to ultimate resolution (defect removal, defect deferral, or report cancellation). In some cases, the same team as the configuration control board.
defect management tool 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.

See also incident management tool.

defect masking An occurrence in which one defect prevents the detection of another [after IEEE 610].
defect report A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function [after IEEE 829].
defect taxonomy A system of (hierarchical) categories designed to be a useful aid for reproducibly classifying defects.
defect tracking tool See defect management tool.
defect triage committee See defect management committee.
defect type 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.
defect-based technique See defect-based test design technique.
defect-based test design technique A procedure to derive and/or select test cases targeted at one or more defect types, with tests being developed from what is known about the specific defect type. See also defect taxonomy.
definition-use pair The association of a definition of a variable with the subsequent use of that variable. Variable uses include computational (e.g. multiplication) or to direct the execution of a path (“predicate” use).
deliverable Any (work) product that must be delivered to someone other that the (work) product’s author.
demilitarized zone A physical or logical subnetwork that contains and exposes an organization’s external-facing services to an untrusted network, commonly the Internet.

See also network zone.

Deming cycle An iterative four-step problem-solving process, (plan-do-check-act), typically used in process improvement. [After Deming]
denial of service A security attack that is intended to overload the system with requests such that legitimate requests cannot be serviced.
design-based testing An approach to testing in which test case are designed based on the architecture and/or detailed design of a component or system (e.g. tests of interfaces between components or systems).
desk checking Testing of software or a specification by manual simulation of its execution. See also static testing.
development testing Formal or informal testing conducted during the implementation of a component or system, usually in the development environment by developers [after IEEE 610]. See also component testing.
deviation See incident.
deviation report See incident report.
diagnosing (IDEAL) The phase within the IDEAL model where it is determined where one is, relative to where one wants to be. The diagnosing phase consists of the activities: characterize current and desired states and develop recommendations. See also IDEAL.
dirty testing See negative testing.
discount usability testing A test strategy for usability testing that puts emphasis on keeping costs down without compromising too much on the quality of the usability evaluation.
DMZ Acronym for demilitarized zone.
documentation testing Testing the quality of the documentation, e.g. user guide or installation guide.
domain The set from which valid input and/or output values are selected.
domain analysis A black-box test design technique that is used to identify efficient and effective test cases when multiple variables can or should be tested together. It builds on and generalizes equivalence partitioning and boundary values analysis. See also boundary value analysis, equivalence partitioning.
DOS Acronym for denial of service.
driver A software component or test tool that replaces a program that takes care of the control and/or the calling of a component or system [after TMap].
dynamic analysis The process of evaluating the behaviour, e.g. memory performance, CPU usage, of a system or component during execution [after IEEE 610].
dynamic analysis tool 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.
dynamic comparison Comparison of actual and expected results, performed while the software is being executed, for example by a test execution tool.
dynamic testing Testing that involves the execution of the software of the component or system.
E
effectiveness (1) The capability of producing an intended result. (2) Extent to which correct and complete goals are achieved. [ISO 9241]

See also efficiency.

efficiency (1) The capability of the software product to provide appropriate performance, relative to the amount of resources used under stated conditions. [ISO 9126] (2) The capability of a process to produce the intended outcome, relative to the amount of resources used.

(3) Resources expended in relation to the extent with which users achieve specified goals. [ISO 9241].

See also effectiveness.

efficiency testing The process of testing to determine the efficiency of a software product.
EFQM Acronym for European Foundation for Quality Management excellence model.
elementary comparison testing A black-box test design technique in which test cases are designed to execute combinations of inputs using the concept of modified decision condition coverage. [TMap]
embedded iterative development model A development lifecycle sub-model that applies an iterative approach to detailed design, coding and testing within an overall sequential model. In this case, the high-level design documents are prepared and approved for the entire project but the actual detailed design, code development and testing are conducted in iterations.
emotional intelligence The ability, capacity, and skill to identify, assess, and manage the emotions of one’s self, of others, and of groups.
EMTE Acronym for Equivalent Manual Test Effort.
emulator A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system [IEEE 610]. See also simulator.
encryption The process of encoding information so that only authorized parties can retrieve the original information, usually by means of a specific decryption key or process.
entry criteria the set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. The purpose of entry criteria is to prevent a task from being done which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria [Gilb and Graham].
entry point An executable statement or process step which defines a point at which a given process is intended to begin.
equivalence class See equivalence partition.
equivalence partition A portion of an input or output domain for which the behavior of a component or system is assumed to be the same, based on the specification.
equivalence partition coverage The percentage of equivalence partitions identified that have been exercised by a test suite.
equivalence partitioning A black-box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle, test cases are designed to cover each partition at least once.
equivalent manual test effort Effort required for running tests manually.
equivalent manual test effort (EMTE) Effort required for running tests manually.
error Human action that produces an incorrect result [after IEEE 610].
error guessing A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them.
error seeding See fault seeding.
error seeding tool See fault seeding tool.
error tolerance The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [after IEEE 610].
escaped defect A defect that was not detected in a previous test level which is supposed to find such defects. See also Defect Detection Percentage.
establishing (IDEAL) The phase within the IDEAL model where the specifics of how an organization will reach its destination are planned. The establishing phase consists of the activities: set priorities, develop approach and plan actions. See also IDEAL.
ethical hacker A security tester using hacker techniques.
European Foundation for Quality Management excellence model A nonprescriptive framework for an organisation’s quality management system, defined and owned by the European Foundation for Quality Management, based on five ‚Enabling‘ criteria (covering what an organisation does), and four ‚Results‘ criteria (covering what an organisation achieves).
exception handling Behavior of a component or system in response to erroneous input, from either a human user or from another component or system, or to an internal failure.
executable statement 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.
exercised A program element is said to be exercised by a test case when the input value causes the execution of that element, such as a statement, decision, or other structural element.
exhaustive testing A test approach in which the test suite comprises all combinations of input values and preconditions.

Synonym: complete testing.

exit criteria The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [After Gilb and Graham]
exit point An executable statement or process step which defines a point at which a given process is intended to cease.
expected outcome See expected result.
expected result The behavior predicted by the specification, or another source, of a component or system under specified conditions.

See also test oracle.

experience-based testing Testing based on the tester’s experience, knowledge and intuition.
experienced-based technique See experienced-based test design technique.
experienced-based test design technique Procedure to derive and/or select test cases based the tester’s experience, knowledge and intuition.
expert usability review An informal usability review in which the reviewers are experts. Experts can be usability experts or subject matter experts, or both. See also informal review.
exploratory testing An informal test design technique where that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests [after Bach].
extreme programming 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. See also agile software development.
F
factory acceptance testing Acceptance testing conducted at the site at which the product is developed and performed by employees of the supplier organization, to determine whether or not a component or system satisfies the requirements, normally including hardware as well as software.
fail A test is deemed to fail if its actual result does not match its expected result.
failover testing Testing by simulating failure modes or actually causing failures in a controlled environment. Following a failure, the failover mechanism is tested to ensure that data is not lost or corrupted and that any agreed service levels are maintained (e.g., function availability or response times). See also recoverability testing.
failure Deviation of the component or system from its expected delivery, service or result [after Fenton].
failure mode The physical or functional manifestation of a failure. For example, a system in failure mode may be characterized by slow operation, incorrect outputs, or complete termination of execution [IEEE 610].
Failure Mode and Effect Analysis A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence.

See also Failure Mode, Effect and Criticality Analysis.

Failure Mode, Effects, and Criticality Analysis An extension of FMEA, as in addition to the basic FMEA, it includes a criticality analysis, which is used to chart the probability of failure modes against the severity of their consequences. The result highlights failure modes with relatively high probability and severity of consequences, allowing remedial effort to be directed where it will produce the greatest value. See also Failure Mode and Effect Analysis (FMEA).
failure rate The ratio of the number of failures of a given category to a given unit of measure; e.g. failures per unit of time, failures per number of transactions, failures per number of computer runs [IEEE 610].
false-fail result See false-positive result.
false-negative result A test result which fails to identify the presence of a defect that is actually present in the test object.
false-pass result See false-negative result.
false-positive result A test result in which a defect is reported although no such defect actually exists in the test object.
fault See defect.
fault attack Directed and focused attempt to evaluate a specific quality characteristic of a test object by attempting to force specific failures to occur. Usually focused on reliability or on security.

See also negative testing, security attack

fault density See defect density.
Fault Detection Percentage See Defect Detection Percentage.
fault injection The process of intentionally adding defects to a system for the purpose of finding out whether the system can detect, and possibly recover from, a defect. Fault injection intended to mimic failures that might occur in the field. See also fault tolerance.
fault masking See defect masking.
fault seeding The process of intentionally adding defects to those already in the component or system for the purpose of monitoring the rate of detection and removal, and estimating the number of remaining defects. Fault seeding is typically part of development (prerelease) testing and can be performed at any test level (component, integration, or system). [After IEEE 610]
fault seeding tool A tool for seeding (i.e. intentionally inserting) faults in a component or system.
fault tolerance The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface [ISO 9126]. See also reliability, robustness.
Fault Tree Analysis A technique used to analyze the causes of faults (defects). The technique visually models how logical relationships between failures, human errors, and external events can combine to cause specific faults to disclose.
FDP Acronym for Fault Detection Percentage.
feasible path A path for which a set of input values and preconditions exists which causes it to be executed.
feature An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints) [after IEEE 1008].
feature-driven development An iterative and incremental software development process driven from a client-valued functionality (feature) perspective. Feature-driven development is mostly used in agile software development. See also agile software development.
field testing See beta testing.
finding A result of an evaluation that identifies some important issue, problem, or opportunity.
finite state machine A computational model consisting of a finite number of states and transitions between those states, possibly with accompanying actions [IEEE 610].
finite state testing See state transition testing.
firewall A component or set of components that controls incoming and outgoing network traffic based on predetermined security rules.
fishbone diagram See cause/effect diagram.
FMEA Acronym for Failure Mode and Effect Analysis.
FMECA Acronym for Failure Mode, Effects, and Criticality Analysis.
formal review A review characterized by documented procedures and requirements, e.g. inspection.
formative evaluation A type of evaluation designed and used to improve the quality of a component or system, especially when it is still being designed. See also summative evaluation.
FPA Acronym for Function Point Analysis.
frozen test basis A test basis document that can only be amended by a formal change process. See also baseline.
FTA Acronym for Fault Tree Analysis.
Function Point Analysis Method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources, and project control.
functional integration An integration approach that combines the components or systems for the purpose of getting a basic functionality working early. See also integration testing.
functional requirement A requirement that specifies a function that a system or system component must be able to perform [IEEE 610]. See also functionality.
functional test design technique Procedure to derive and select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure. See also black-box test design technique.
functional testing Testing based on an analysis of the specification of the functionality of a component or system.

See also black-box testing.

functionality The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions [ISO 9126].
functionality testing The process of testing to determine the functionality of a software product.
fuzz testing A software testing technique used to discover security vulnerabilities by inputting massive amounts of random data, called fuzz, to the component or system.
G
generic test automation architecture Representation of the layers, components, and interfaces of a test automation architecture, allowing for a structured and modular approach to implement test automation.
glass box testing See white-box testing.
Goal Question Metric An approach to software measurement using a three-level model: conceptual level (goal), operational level (question) and quantitative level (metric).
GQM Acronym for Goal Question Metric.
GUI Acronym for Graphical User Interface.
GUI testing Testing performed by interacting with the software under test via the graphical user interface.
H
hacker A person or organization who is actively involved in security attacks, usually with malicious intent.

See Also attacker.

hardware-software integration testing Testing performed to expose defects in the interfaces and interaction between hardware and software components. See also integration testing.
hashing Transformation of a variable length string of characters into a usually shorter fixed-length value or key. Hashed values, or hashes, are commonly used in table or database lookups. Cryptographic hash functions are used to secure data.
hazard analysis A technique used to characterize the elements of risk. The result of a hazard analysis will drive the methods used for development and testing of a system. See also risk analysis.
heuristic A generally recognized rule of thumb that helps to achieve a goal.
heuristic evaluation A usability review technique that targets usability problems in the user interface or user interface design. With this technique, the reviewers examine the interface and judge its compliance with recognized usability principles (the „heuristics“).
high-level test case A test case without concrete (implementation level) values for the input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. See also low level test case.
horizontal traceability The tracing of requirements for a test level through the layers of test documentation (e.g. test plan, test design specification, test case specification, test procedure specification or test script).
human-centered design An approach to design that aims to make software products more usable by focusing on the use of the software products and applying human factors, ergonomics, and usability knowledge and techniques. [ISO 9241-210]
hyperlink A pointer within a web page that leads

to other web pages.

hyperlink test tool A tool used to check that no broken hyperlinks are present on a web site.
I
IDEAL 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 impact analysis: The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.
impact See risk impact.
impact analysis The assessment of change to the layers of development documentation, test documentation and components, to implement a given change to specified requirements.
incident Any event occurring during testing that requires investigation [after IEEE 1008].
incident logging Recording the details of any incident that occurred, e.g. during testing.
incident management The process of recognizing, investigating, taking action and disposing of incidents. It involves logging incidents, classifying them and identifying the impact [after IEEE 1044].
incident management tool A tool that facilitates the recording and status tracking of incidents found during testing. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of incidents and provide reporting facilities.

See also defect management tool.

incident report A document reporting on any event that occurred during the testing which requires investigation [after IEEE 829].
incremental development model A development life cycle where a larger project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this life cycle model, each subproject follows a ‘mini V-model’ with its own design, coding and testing phases.
incremental testing Testing where components or systems are integrated and tested one or some at a time until all the components or systems are integrated and tested.
independence of testing Separation of responsibilities, which encourages the accomplishment of objective testing [after DO-178b].
indicator A measure that can be used to estimate or predict another measure. [ISO 14598]
infeasible path A path that cannot be exercised by any set of possible input values.
informal review A review not based on a formal (documented) procedure.
information assurance Measures that protect and defend information and information systems by ensuring their availability, integrity, authentication, confidentiality, and non-repudiation. These measures include providing for restoration of information systems by incorporating protection, detection, and reaction capabilities. [NIST.IR.7298]
information security The protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability. [NIST.IR.7298]
initiating (IDEAL) The phase within the IDEAL model where the groundwork is laid for a successful improvement effort. The initiating phase consists of the activities: set context, build sponsorship and charter infrastructure. See also IDEAL.
input A variable (whether stored within a component or outside it) that is read by a component.
input domain The set from which valid input values can be selected. See also domain.
input value An instance of an input. See also input.
insider threat A security threat originating from within the organization, often by an authorized system user.
insourced testing Testing performed by people who are co-located with the project team but are not fellow employees.
inspection A type of review that relies on visual examination of documents to detect defects, e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a documented procedure [after IEEE 610, IEEE 1028].

See also peer review.

inspection leader See moderator.
inspector See reviewer.
installability The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability.
installability testing The process of testing the installability of a software product.

See also portability testing.

installation guide 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.
installation wizard Supplied software on any suitable media, which leads the installer through the installation process. It normally runs the installation process, provides feedback on installation results, and prompts for options.
instrumentation The (tool-supported) insertion of additional code into the program in order to collect information about program behavior during execution, e.g. for measuring code coverage.
instrumenter A software tool used to carry out instrumentation.
intake test A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase.

See also smoke test.

integration The process of combining components into larger assemblies.
integration testing Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing, system integration testing.
interface testing An integration test type that is concerned with testing the interfaces between components or systems.
interoperability The capability of the software to interact with one or more specified components or systems [after ISO 9126]. See also functionality.
interoperability testing The process of testing to determine the interoperability of a software product.

See also functional testing, interoperability.

intrusion detection system A system which monitors activities on the 7 layers of the OSI model from network to application level, to detect violations of the security policy.

See also malware scanning.

invalid testing Testing using input values that should be rejected by the component or system. See also error tolerance, negative testing.
Ishikawa diagram See cause/effect diagram.
isolation testing Testing of individual components in isolation from surrounding components, with surrounding components being simulated by stubs and drivers, if needed.
item transmittal report See release note.
iterative development model A development life cycle where a project is broken into a, usually large, numbers of iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows from iteration to iteration to become the final product.
K
key performance indicator See performance indicator.
keyword-driven testing 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. See also data-driven testing.
L
lead assessor The person who leads an assessment. In some cases, for instance CMMi and TMMi when formal assessments are conducted, the lead assessor must be accredited and formally trained.
learnability The capability of the software product to enable the user to learn its application [ISO 9126].

See also usability.

learning (IDEAL) The phase within the IDEAL model where one learns from experiences and improves one’s ability to adopt new processes and technologies in the future. The learning phase consists of the activities: analyze and validate, and propose future actions. See also IDEAL
level of intrusion The level to which a test object is modified by adjusting it for testability.
level test plan A test plan that typically addresses one test level. See also test plan.
lifecycle model A partitioning of the life of a product or project into phases. [CMMI] See also software lifecycle.
linear scripting A simple scripting technique without any control structure in the test scripts.
link testing See component integration testing.
load profile A specification of the activity which a component or system being tested may experience in production. A load profile consists of a designated number of virtual users who process a defined set of transactions in a specified time period and according to a predefined operational profile. See also operational profile.
load testing A type of performance testing conducted to evaluate the behavior of a component or system with increasing load, e.g. number of parallel users and/or numbers of transactions to determine what load can be handled by the component or system. See also performance testing, stress testing.
load testing tool A tool to support load testing whereby it can simulate increasing load, e.g., numbers of concurrent users and/or transactions within a specified time-period. See also performance testing tool.
logical test case See high-level test case.
logic-coverage testing See white-box testing.
logic-driven testing See white-box testing.
low-level test case A test case with concrete (implementation level) values for the input data and expected results. Logical operators from high-level test cases are replaced by actual values that correspond to the objectives of the logical operators. See also high-level test case.
M
maintainability The ease with which a software product can be modified to correct defects, modified to meet new requirements, modified to make future maintenance easier, or adapted to a changed environment [ISO 9126].
maintainability testing The process of testing to determine the maintainability of a software product.
maintenance Modification of a software product after delivery to correct defects, to improve performance or other attributes, or to adapt the product to a modified environment [IEEE 1219].
maintenance testing Testing the changes to an operational system or the impact of a changed environment to an operational system.
malware Software that is intended to harm a system or its components.
malware scanning Static analysis aiming to detect and remove malicious code received at an interface.

See also intrusion detection system.

management review A systematic evaluation of software acquisition, supply, development, operation, or maintenance process, performed by or on behalf of management that monitors progress, determines the status of plans and schedules, confirms requirements and their system allocation, or evaluates the effectiveness of management approaches to achieve fitness for purpose [after IEEE 610, IEEE 1028].
man-in-the-middle attack The interception, mimicking and/or altering and subsequent relaying of communications (e.g., credit card transactions) by a third party such that a user remains unaware of that third party’s presence.
manufacturing-based quality A view of quality, whereby quality is measured by the degree

to which a product or service conforms to its intended design and requirements. Quality arises from the process(es) used. [After Garvin] See also product-based quality, transcendent-based quality, user-based quality, value-based quality.

master test plan A test plan that typically addresses multiple test levels. See also test plan.
maturity (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and work practices. See also Capability Maturity Model Integration, Test Maturity Model integration. (2) The capability of the software product to avoid failure as a result of defects in the software. [ISO 9126] See also reliability.
maturity level Degree of process improvement across a predefined set of process areas in which all goals in the set are attained. [TMMi]
maturity model A structured collection of elements that describe certain aspects of maturity in an organization, and aid in the definition and understanding of an organization’s processes. A maturity model often provides a common language, shared vision and framework for prioritizing improvement actions.
MBT Acronym for model-based testing.
MBT model Any model used in model-based testing.
MBTI Acronym for Myers-Briggs Type Indicator.
MC/DC Acronym for modified condition / decision coverage.
Mean Time Between Failures The arithmetic mean (average) time between failures of a system. The MTBF is typically part of a reliability growth model that assumes the failed system is immediately repaired, as a part of a defect fixing process. See also reliability growth model.
Mean Time To Repair The arithmetic mean (average) time a system will take to recover from any failure. This typically includes testing to insure that the defect has been resolved.
measure The number or category assigned to an attribute of an entity by making a measurement [ISO 14598].
measurement The process of assigning a number or category to an entity to describe an attribute of that entity [ISO 14598].
measurement scale A scale that constrains the type of data analysis that can be performed on it [ISO 14598].
memory leak 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.
methodical test strategy A test strategy whereby the test team uses a pre-determined set of test conditions such as a quality standard, a checklist, or a collection of generalized, logical test conditions which may relate to a particular domain, application or type of testing.
methodical testing Testing based on a standard set of tests, e.g., a checklist, a quality standard, or a set of generalized test cases.
metric A measurement scale and the method used for measurement [ISO 14598].
migration testing See conversion testing.
milestone A point in time in a project at which defined (intermediate) deliverables and results should be ready.
mind map A diagram used to represent words, ideas, tasks, or other items linked to and arranged around a central keyword or idea. Mind maps are used to generate, visualize, structure, and classify ideas, and as an aid in study, organization, problem solving, decision making, and writing.
mistake See error.
model coverage The degree, expressed as a percentage, to which model elements are planned to be or have been exercised by a test suite.
model-based test strategy A test strategy whereby the test team derives testware from models.
model-based testing Testing based on or involving models.
modeling tool A tool that supports the creation, amendment and verification of models of the software or system [Graham].
moderator (1) The leader and main person responsible for an inspection or review process.(2) A neutral person who conducts a usability test session.
modified condition / decision testing A white-box test design technique in which test cases

are designed to execute single condition outcomes that independently affect a decision outcome.

modified condition decision coverage The percentage of all single condition outcomes that

independently affect a decision outcome that have been exercised by a test case suite.

100% modified condition decision coverage implies 100% decision condition coverage.

modified multiple condition coverage See modified condition decision coverage.
modified multiple condition testing See modified condition decision testing.
module See component.
module testing See component testing.
monitoring tool A software tool or hardware device that run concurrently with the component or system under test and supervises, records and/or analyses the behavior of the component or system [after IEEE 610].
monkey testing Testing by means of a random selection from a large range of inputs and by randomly pushing buttons, ignorant of how the product is being used.
MTBF Acronym for mean time between failures.
MTTR Acronym for mean time to repair.
multiple condition See compound condition.
multiple condition coverage The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% modified decision condition coverage.
multiple condition testing A white-box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement).
mutation analysis A method to determine test suite thoroughness by measuring the extent to which a test suite can discriminate the program from slight variants (mutants) of the program.
mutation testing Testing in which two or more variants of a component or system are executed with the same inputs, the outputs compared, and analyzed in cases of discrepancies.
Myers-Briggs Type Indicator (MBTI) An indicator of psychological preference representing the different personalities and communication styles of people.
N
negative testing Tests aimed at showing that a component or system does not work. Negative testing is related to the testers’ attitude rather than a specific test approach or test design technique, e.g. testing with invalid input values or exceptions [after Beizer].
neighborhood integration testing A form of integration testing where all of the nodes that connect to a given node are the basis for the integration testing.
network zone A sub-network with a defined level of trust. For example, the Internet or a public zone would be considered to be untrusted.
non-conformity Non fulfillment of a specified requirement [ISO 9000].
non-functional requirement A requirement that does not relate to functionality, but to attributes of such as reliability, efficiency, usability, maintainability and portability.
non-functional test design techniques Procedure to derive and/or select test cases for nonfunctional testing based on an analysis of the specification of a component or system without reference to its internal structure. See also black-box test design technique.
non-functional testing Testing the attributes of a component of system that do not relate to functionality, e.g. reliability, efficiency, usability, maintainability and portability.
N-switch coverage The percentage of sequences of (N+1)-transitions that have been exercised by a test suite [Chow].
N-switch testing A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions [Chow]. See also state transition testing.
n-wise testing A black-box test design technique in which test cases are designed to execute all possible discrete combinations of any set of n input parameters. See also orthogonal array testing, pairwise testing.
O
offline MBT Model-based testing approach whereby test cases are generated into a repository for future execution.
off-the-shelf software See commercial off-the-shelf.
online MBT Model-based testing approach whereby test cases are generated and executed simultaneously.
open source tool A software tool that is available to all potential users in source code form, usually via the internet; its users are permitted to study, change, improve and, at times, to distribute the software.
operability The capability of the software product to enable the user to operate and control it [ISO 9126].

See also usability.

operational acceptance testing 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. See also operational testing.
operational environment 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.
operational profile The representation of a distinct set of tasks performed by the component or system, possibly based on user behavior when interacting with the component or system, and their probabilities of occurrence. A task is logical rather that physical and can be executed over several machines or be executed in non-contiguous time segments.
operational profile testing Statistical testing using a model of system operations (short duration tasks) and their probability of typical use [Musa].
operational profiling The process of developing and implementing an operational profile. See also operational profile.
operational testing Testing conducted to evaluate a component or system in its operational environment [IEEE 610].
oracle See test oracle.
orthogonal array A 2-dimensional array selected with special mathematical properties, such that choosing any two columns in the array provides every pair combination of each number in the array.
orthogonal array testing A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations. See also n-wise testing, pairwise testing.
outcome See result.
output A variable (whether stored within a component or outside it) that is written by a component.
output domain The set from which valid output values can be selected.

See also domain.

output value An instance of an output.

See also output.

outsourced testing Testing performed by people who are not co-located with the project team and are not fellow employees.
P
pair programming A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-time code reviews are performed.
pair testing Two persons, e.g. two testers, a developer and a tester, or an end-user and a tester, working together to find defects. Typically, they share one computer and trade control of it while testing.
pairwise integration testing A form of integration testing that targets pairs of components that work together, as shown in a call graph.
pairwise testing A black-box test design technique in which test cases are designed to execute all possible discrete combinations of each pair of input parameters. See also n-wise testing, orthogonal array testing.
Pareto analysis A statistical technique in decision making that is used for selection of a limited number of factors that produce significant overall effect. In terms of quality improvement, a large majority of problems (80%) are produced by a few key causes
partition testing See equivalence partitioning [Beizer].
pass A test is deemed to pass if its actual result matches its expected result.
pass/fail criteria Decision rules used to determine whether an test item (function) or a feature passes or failed a test [IEEE 829].
password cracking A security attack recovering secret passwords stored in a computer system or transmitted over a network. [NIST.IR.7298]
path A sequence of events, e.g. executable statements, of a component or system from an entry point to an exit point.
path coverage The percentage of paths that have been exercised by a test suite.
path sensitizing Choosing a set of input values to force the execution of a given path.
path testing A white-box test design technique in which test cases are designed to execute paths.
peer review A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection, technical review and walkthrough.
penetration testing A testing technique aiming to exploit security vulnerabilities (known or unknown) to gain unauthorized access.
performance The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate [after IEEE 610]. See also efficiency.
performance indicator A high-level metric of effectiveness and/or efficiency used to guide and control progressive development, e.g. Defect Detection Percentage (DDP) for testing [CMMI].
performance profiling The task of analyzing, e.g., identifying performance bottlenecks based on generated metrics, and tuning the performance of a software component or system using tools.
performance testing The process of testing to determine the performance of a software product. See also efficiency testing.
performance testing tool A tool to support performance testing that usually has two main facilities: load generation and test transaction measurement. Load generation can simulate either multiple users or high volumes of input data. During execution, response time measurements are taken from selected transactions and these are logged. Performance testing tools normally provide reports based on test logs and graphs of load against response times.
pharming A security attack intended to redirect a web site’s traffic to a fraudulent web site without the user’s knowledge or consent.
phase containment The percentage of defects that are removed in the same phase of the software lifecycle in which they were introduced.
phase test plan A test plan that typically addresses one test phase. See also test plan.
phishing An attempt to acquire personal or sensitive information by masquerading as a trustworthy entity in an electronic communication.
planning poker 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 Wide Band Delphi method using a deck of cards with values representing the units in which the team estimates. See also agile software development, Wide Band Delphi.
pointer A data item that specifies the location of another data item; for example, a data item that specifies the address of the next employee record to be processed [IEEE 610].
portability The ease with which the software product can be transferred from one hardware or software environment to another [ISO 9126].
portability testing The process of testing to determine the portability of a software product.
postcondition Environmental and state conditions that must be fulfilled after the execution of a test or test procedure.
post-execution comparison Comparison of actual and expected results, performed after the software has finished running.
post-project meeting See retrospective meeting.
precondition Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.
predicate A statement that can evaluate to true or false and may be used to determine the control flow of subsequent decision logic. See also decision.
predicted outcome See expected result.
pretest See intake test.
priority The level of (business) importance assigned to an item, e.g. defect.
PRISMA A systematic approach to risk-based testing that employs product risk identification and analysis to create a product risk matrix that considers likelihood and impact. Term is derived from Product RISk MAnagement.
probe effect 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.
problem See defect.
problem management See defect management.
problem report See defect report.
procedure testing Testing aimed at ensuring that the component or system can operate in conjunction with new or existing users’ business procedures or operational procedures.
process A set of interrelated activities, which transform inputs into outputs [ISO 12207].
process assessment A disciplined evaluation of an organization’s software processes against a reference model. [after ISO 15504]
process cycle test A black-box test design technique in which test cases are designed to execute business procedures and processes [TMap].

See also procedure testing.

process improvement A program of activities designed to improve the performance and maturity of the organization’s processes, and the result of such a program [CMMI].
process model A framework wherein processes of the same nature are classified into a overall model, e.g. a test improvement model.
process reference model A process model providing a generic body of best practices and how to improve in a prescribed step-by-step manner.
process-compliant test strategy A test strategy whereby the test team follows a set of predefined processes, whereby the processes address such items as documentation, the proper identification and use of the test basis and test oracle(s), and the organization of the test team.
process-compliant testing Testing that follows a set of defined processes, e.g., defined by an external party such as a standards committee. See also standard-compliant testing.
process-driven scripting A scripting technique where scripts are structured into scenarios which represent use cases of the software under test. The scripts can be parameterized with test data.
product risk A risk directly related to the test object. See also risk.
Product RISk MAnagement See PRISMA.
product-based quality A view of quality, wherein quality is based on a well-defined set of quality attributes. These attributes must be measured in an objective and quantitative way. Differences in the quality of products of the same type can be traced back to the way the specific quality attributes have been implemented. [After Garvin] See also manufacturing based quality, quality attribute, transcendent-based quality, user-based quality, value-based quality.
production acceptance testing See operational acceptance testing.
program instrumenter See instrumenter.
program testing See component testing.
project A project is a unique set of coordinated and controlled activities with start and finish dates undertaken an objective conforming to specific requirements, including the constraints of time, cost and resources [ISO 9000].
project retrospective A structured way to capture lessons learned and to create specific action plans for improving on the next project or next project phase.
project risk A risk related to management and control of the (test) project, e.g. lack of staffing, strict deadlines, changing requirements, etc. See also risk.
pseudo-random A series which appears to be random but is in fact generated according to some prearranged sequence.
Q
QFD Acronym for quality function deployment.
qualification The process of demonstrating the ability to fulfill specified requirements.

Note: the term ‘qualified’ is used to designate the corresponding status [ISO 9000].

quality (1) The degree to which a component, system or process meets specified requirements and/or user/ customer or user needs or expectations [after IEEE 610]. (2) The degree to which a set of inherent characteristics fulfills requirements [ISO 9000:2000].
quality assurance Part of quality management focused on providing confidence that quality requirements will be fulfilled [ISO 9000].
quality attribute (1) A feature or characteristic that affects an item’s quality [IEEE 610]. (2) A set of attributes of a software product by which its quality is described and evaluated. A software quality characteristic may be refined into multiple levels of sub-characteristics [ISO 9126]. Quality characteristics are functionality, reliability, usability, efficiency, maintainability and portability [ISO 9126].
quality characteristic See quality attribute.
quality control The operational techniques and activities, part of quality management, that are focused on fulfilling quality requirements. [after ISO 8402]
Quality Function Deployment A method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process. [Akao]
quality gate A special milestone in a project. Quality gates are located between those phases of a project strongly depending on the outcome of a previous phase. A quality gate includes a formal check of the documents of the previous phase.
quality management Coordinated activities to direct and control an organization with regard to quality. Direction and control with regard to quality generally includes the establishment of the quality policy and quality objectives, quality planning, quality control, quality assurance and quality improvement [ISO 9000].
quality risk A risk related to a quality attribute. See also quality attribute, product risk.
R
RACI matrix A matrix describing the participation by various roles in completing tasks or deliverables for a project or process. It is especially useful in clarifying roles and responsibilities. RACI is an acronym derived from the four key responsibilities most typically used: Responsible, Accountable, Consulted, and Informed.
random testing A black-box test design technique where test cases are selected, possibly using a pseudo-random generation algorithm, to match an operational profile.
Rational Unified process A proprietary adaptable iterative software development process framework consisting of four project lifecycle phases: inception, elaboration, construction and transition.
reactive test strategy A test strategy whereby the test team waits to design and implement tests until the software is received, reacting to the actual system under test.
reactive testing Testing that dynamically responds to the actual system under test and test results being obtained. Typically reactive testing has a reduced planning cycle and the design and implementation test phases are not carried out until the test object is received.
reconnaissance The exploration of a target area aiming to gain information that can be useful for an attack.
record/playback tool See capture/playback tool.
recorder See scribe.
recoverability The capability of the software product to re-establish a specified level of performance and recover the data directly affected in case of failure [ISO 9126]. See also reliability.
recoverability testing The process of testing to determine the recoverability of a software product. See also reliability testing.
recovery testing See recoverability testing.
regression testing Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. Note:

It is performed when the software or its environment is changed.

regression-averse test strategy A test strategy whereby the test team applies various techniques to manage the risk of regression such as functional and/or non-functional regression test automation at one or more levels.
regression-averse testing Testing using various techniques to manage the risk of regression, e.g., by designing re-usable testware and by extensive automation of testing at one or more test levels.
regulation testing See compliance testing.
release note A document identifying test items, their configuration, current status and other delivery information delivered by development to testing, and possibly other stakeholders, at the start of a test execution phase [after IEEE 829].
reliability The ability of the software product to perform its required functions under stated conditions for a specified period of time, or for a specified number of operations [ISO 9126].
reliability growth model A model that shows the growth in reliability over time of a component or system as a result of the removal of defects that result in reliability failures.
reliability testing The process of testing to determine the reliability of a software product.
replaceability The capability of the software product to be used in place of another specified software product for the same purpose in the same environment [ISO 9126].

See also portability.

requirement A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document [after IEEE 610].
requirements management tool 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.
requirements phase The period of time in the software life cycle during which the requirements for a software product are defined and documented [IEEE 610].
requirements-based testing An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.
resource utilisation The capability of the software product to use appropriate amounts and types of resources, for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files, when the software performs its function under stated conditions [after ISO 9126]. See also efficiency.
resource utilisation testing The process of testing to determine the resource-utilization of a software product. See also efficiency testing.
result The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports and communication messages sent out. See also actual result, expected result.
resumption criteria The testing activities that must be repeated when testing is re-started after a suspension [after IEEE 829].
resumption requirements The defined set of testing activities that must be repeated when testing is re-started after a suspension. [After IEEE 829]
re-testing See confirmation testing.
retrospective meeting 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.
review An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review, informal review, technical review, inspection, and walkthrough [after IEEE 1028].
review plan A document describing the approach, resources and schedule of intended review activities. It identifies, amongst others: documents and code to be reviewed, review types to be used, participants, as well as entry and exit criteria to be applied in case of formal reviews, and the rationale for their choice. It is a record of the review planning process.
review tool A tool that provides support to the review process. Typical features include review planning and tracking support, communication support, collaborative reviews and a repository for collecting and reporting of metrics.
reviewer The person involved in the review that identifies and describes anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process.
risk A factor that could result in future negative consequences; usually expressed as impact and likelihood.
risk analysis The process of assessing identified project or product risks to determine their level of risk, typically by estimating their impact and probability of occurrence (likelihood)
risk assessment The process of identifying and subsequently analyzing the identified project or product risk to determine its level of risk, typically by assigning likelihood and impact ratings. See also product risk, project risk, risk, risk impact, risk level, risk likelihood.
risk category See risk type.
risk control See risk mitigation.
risk exposure see risk level
risk identification The process of identifying risks using techniques such as brainstorming, checklists and failure history.
risk impact The damage that will be caused if the risk become an actual outcome or event.
risk level The importance of a risk as defined by its characteristics impact and likelihood.

The level of risk can be used to determine the intensity of testing to be performed. A risk level can be expressed either qualitatively (e.g. high, medium, low) or quantitatively.

risk likelihood The estimated probability that a risk will become an actual outcome or event.
risk management Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and controlling risk.
risk mitigation The process through which decisions are reached and protective measures are implemented for reducing risk to, or maintaining risks within, specified levels.
risk type A set of risks grouped by one or more common factors such as a quality attribute, cause, location, or potential effect of risk;. A specific set of product risk types is related to the type of testing that can mitigate (control) that risk type. For example the risk of userinteractions being misunderstood can be mitigated by usability testing.
risk-based testing An approach to testing to reduce the level of product risks and inform stakeholders of their status, starting in the initial stages of a project. It involves the identification of product risks and the use of risk levels to guide the test process.
robustness The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions [IEEE 610]. See also error-tolerance, fault-tolerance.
robustness testing 1. Testing to determine the robustness of the software product. 2. See negative testing.
root cause A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed. [CMMI]
root cause analysis An analysis technique aimed at identifying the root causes of defects. By directing correcting measures at root causes, it is hoped that the likelihood of defect recurrence will be minimized.
RUP Acronym for Rational Unified Process.
S
S.M.A.R.T. goal methodology A methodology whereby objectives are defined very specifically rather than generically. SMART is an acronym derived from the attributes of the objective to be defined: Specific, Measurable, Attainable, Relevant and Timely.
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 [ISO 9126].
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 The process of testing to determine the safety of a software product.
salting A cryptographic technique that adds random data (salt) to the user data prior to hashing.

See also hashing.

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
script kiddie A person who executes security attacks that have been created by other hackers rather than creating one’s own attacks.
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/replay tool).
SCRUM An iterative incremental framework for managing projects commonly used with agile software development. See also agile software development.
security Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data [ISO 9126]. See also functionality.
security attack An attempt to gain unauthorized access to a system or component, resources, information, or an attempt to compromise system integrity. [NIST.IR.7298]
security audit An audit evaluating an organization’s security processes and infrastructure.
security policy A high-level document describing the principles, approach and major objectives of the organization regarding security.
security procedure A set of steps required to implement the security policy and the steps to be taken in response to a security incident.
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 and characteristics and vulnerabilities.
security tool A tool that supports operational security.
security vulnerability A weakness in the system that could allow for a successful security attack.
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 [after IEEE 610].
Shewhart chart See control chart.
short-circuiting A programming language/interpreter technique for evaluating compound conditions in which a condition on one side of a logical operator may not be evaluated if the condition on the other side is sufficient to determine the final outcome.
simulation The representation of selected behavioral characteristics of one physical or abstract system by another system [ISO 2382/1].
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.
SMART Acronym for S.M.A.R.T. goal methodology.
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.
social engineering An attempt to trick someone into revealing information (e.g., a password) that can be used to attack systems or networks. [NIST.IR.7298]
software Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system [IEEE 610].
Software Failure Mode and Effect Analysis See Failure Mode and Effect.

Analysis.

Software Failure Mode, Effects, and Criticality Analysis See Failure Mode,Effects, and Criticality Analysis.
software feature See feature.
software integrity level The degree to which software complies or must comply with a set of stakeholder-selected software and/or software-based system characteristics (e.g., software complexity, risk assessment, safety level, security level, desired performance, reliability, or cost) which are defined to reflect the importance of the software to its stakeholders.
software lifecycle 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 phase 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 product characteristic See quality attribute.
software quality The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126] See also quality.
software quality characteristics See quality attribute.
software test incident See incident.
software test incident report See incident report.
Software Usability Measurement Inventory A questionnaire-based usability test technique for measuring software quality from the end user’s point of view. [Kirakowski93]
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 system or component, and, often, the procedures for determining whether these provisions have been satisfied [after IEEE 610].
specification-based technique See black-box test design technique.
specification-based test design technique See black-box test design technique.
specification-based testing See black-box testing.
specified input An input for which the specification predicts a result.
SPI Acronym for software process improvement.
SQL injection A security attack inserting malicious SQL statements into an entry field for execution.
stability The capability of the software product to avoid unexpected effects from modifications in the software [ISO 9126].

See also maintainability.

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 [CMMI].
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). [After CMMI]
standard software See off-the shelf software.
standard-compliant test strategy A test strategy whereby the test team follows a standard. Standards followed may be valid e.g., for a country (legislation standards), a business domain (domain standards), or internally (organizational standards).
standard-compliant testing Testing that complies to a set of requirements defined by a standard, e.g., an industry testing standard or a standard for testing safety-critical systems. See also process-compliant testing.
standards testing See compliance testing.
state diagram A diagram that depicts the states that a system or component can assume, and shows the events or circumstances that cause and/or result from a change from one state to another [IEEE 610].
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 A (source statement) entity in a programming language which is typically the smallest indivisible unit of execution.
statement coverage The percentage of all 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 development artifacts, e.g. requirements or code, carried out without execution of these software development artifacts. Static analysis is usually carried out by means of a supporting tool.
static analysis tool See static analyzer.
static analyzer A tool that carries out static analysis.
static code analysis Analysis of source code carried out without execution of that software.
static testing Testing of a software development artifact, e.g., requirements, design or code, without execution of these artifacts, e.g., reviews or static 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. See also operational profile testing.
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 [IEEE 610].
STEP Acronym for Systematic Test and Evaluation Process.
storage See resource utilization.
storage testing See resource utilization testing.
stress testing A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified workloads, or with reduced availability of resources such as access to memory or servers. [After IEEE 610] See also performance testing, load testing.
stress testing tool A tool that supports stress testing.
structural coverage Coverage measures based on the internal structure of the component or system.
structural test design technique See white-box test design technique.
structural testing See white-box testing.
structure-based technique See white-box test design technique.
structure-based test design technique See white-box test design technique.
structure-based testing See white-box testing.
structured scripting A scripting technique that builds and utilizes a library of reusable (parts of) scripts.
structured walkthrough See walkthrough.
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 [after IEEE 610].
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 [ISO 9126].

See also functionality.

suitability testing The process of testing to determine the suitability of a software product
SUMI Acronym for Software Usability Measurement Inventory.
summative evaluation A type of quality evaluation designed and used to gather conclusions about the quality of a component or system, especially when a substantial part of it has completed design. See also formative evaluation, testing.
SUS Acronym for System Usability Scale.
suspension criteria The criteria used to (temporarily) stop all or a portion of the testing activities on the test items [after IEEE 829].
SUT Acronym for system under test.
syntax testing A black-box test design technique in which test cases are designed based upon the definition of the input.
system A collection of components organized to accomplish a specific function or set of functions. [IEEE 610]
system hardening The step-by-step process of reducing the security vulnerabilities of a system by applying a security policy and different layers of protection.
system integration testing Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange, Internet).
system of systems Multiple heterogeneous, distributed systems that are embedded in networks at multiple levels and in multiple interconnected domains, addressing large-scale inter-disciplinary common problems and purposes, usually without a common management structure.
system testing The process of testing an integrated system to verify that it meets specified requirements [Hetzel].
system under test See test object.
System Usability Scale A simple, ten-item attitude scale giving a global view of subjective assessments of usability.
Systematic test and Evaluation Process A structured testing methodology, also used as a content-based model for improving the testing process. Systematic Test and Evaluation Process (STEP) does not require that improvements occur in a specific order. See also content-based model.
T
TDD Acronym for test-driven development.
technical review A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. [Gilb and Graham], [IEEE 1028] See also peer review.
test A set or one of more test cases [IEEE 829].
test adaptation layer The layer in a test automation architecture which provides the necessary code to adapt test scripts on an abstract level to the various components, configuration or interfaces of the SUT.
test analysis The process of analyzing the test basis and defining test objectives.
test approach The implementation of the test strategy for a specific project. It typically includes the decisions made that follow the (test) project’s goal and the risk analysis, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed.
test architect (1) A person who provides guidance and strategic direction for a test organization and for its relationship with other disciplines. (2) A person who defines the way testing is structured for a given system, including topics such as test tools and test data management.
test automation The use of software to perform or support test activities, e.g. test management, test design, test execution and results checking.
test automation architecture An instantiation of the generic test automation architecture to define the architecture of a test automation solution, i.e., its layers, components, services and interfaces.
test automation engineer A person who is responsible for the design, implementation and maintenance of a test automation architecture as well as the technical evolution of the resulting test automation solution.
test automation framework A tool that provides an environment for test automation. It usually includes a test harness and test libraries.
test automation manager A person who is responsible for the planning and supervision of the development and evolution of a test automation solution.
test automation solution A realization/implementation of a test automation architecture, i.e., a combination of components implementing a specific test automation assignment. The components may include off-the-shelf test tools, test automation frameworks, as well as test hardware.
test automation strategy A high-level plan to achieve long-term objectives of test automation under given boundary conditions.
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 [after TMap].

test bed See test environment.
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 [after IEEE 610].
test case design technique See test design technique.
test case explosion The disproportionate growth of the number of test cases with growing size of the test basis, when using a certain test design technique. Test case explosion may also happen when applying the test design technique systematically for the first time.
test case result The final verdict on the execution of a test and its outcomes, like pass, fail, or error. The result of error is used for situations where it is not clear whether the problem is in the test object.
test case specification A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item. [After IEEE 829]

See also test specification.

test case suite See test suite.
test charter A statement of test objectives, and possibly test ideas about how to test. Test charters are often used in exploratory testing. See also 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. See also test process.
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 software under test and the expected results for a test case. Test comparison can be performed during test execution (dynamic comparison) or after test execution.
test completion criteria See exit criteria.
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. See also test management.
test coverage See coverage.
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 management The process of analyzing test data requirements, designing test data structures, creating and maintaining test data.
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 definition layer The layer in a generic test automation architecture which supports test implementation by supporting the definition of test suites and/or test cases, e.g., by offering templates or guidelines.
test deliverable Any test (work) product that must be delivered to someone other than the test (work) product’s author. See also deliverable.
test design (1) See test design specification.

(2) The process of transforming general test 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. [After IEEE 829] See also test specification.
test design technique A method used to derive 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, or from specified test conditions held in the tool itself, or from code.
test director A senior manager who manages test managers. See also test manager.
test driver See driver.
test environment An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test [after IEEE 610].
test estimation 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.
test evaluation report A document produced at the end of the test project 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 outcomes to predicted outcomes, the setting up of test preconditions, and other test control and reporting functions.
test execution layer The layer in a generic test automation architecture which supports the execution of test suites and/or test cases.
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 [IEEE 610].
test execution schedule A scheme for the execution of test procedures. Note: 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 manually 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 fail See fail.
test generation layer The layer in a generic test automation architecture which supports manual or automated design of test suites and/or test cases.
test generator See test data preparation tool.
test harness A test environment that comprises of stubs and drivers needed to execute a test.
test hook A customized software interface that enables automated testing of a test object.
test implementation The process of developing and prioritizing test procedures, creating test data and, optionally, preparing test harnesses and writing automated test scripts.
test Improvement plan A plan for achieving organizational test process improvement objectives based on a thorough understanding of the current strengths and weaknesses of the organization’s test processes and test process assets. [After CMMI]
test incident See incident.
test incident report See incident report.
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. See also test object.
test item transmittal report See release note.
test leader See test manager.
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 [after TMap].
test log A chronological record of relevant details about the execution of tests [IEEE 829].
test logging The process of recording information about tests executed into a test log.
test management The planning, estimating, monitoring and control of test activities, typically carried out by a test manager.
test management tool 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.
test manager 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.
Test Maturity Model integration A five level staged framework for test process improvement, related to the Capability Maturity Model Integration (CMMI), that describes the key elements of an effective test process.
test mission The purpose of testing for an organization, often documented as part of the test policy. See also test policy.
test model A model describing testware that is used for testing a component or a system under test.
test monitoring A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned. See also test management.
test object The component or system to be tested. See also test item.
test objective A reason or purpose for designing and executing a test.
test oracle A source to determine expected results to compare with the actual result of the software under test.

Note: An oracle may be the existing system (for a benchmark), a user manual, or an individual’s specialized knowledge, but should not be the code. [After Adrion]

test outcome See result.
test pass See pass.
test performance indicator A high-level metric of effectiveness and/or efficiency used to guide and control progressive test development, e.g. Defect Detection Percentage (DDP).
test phase A distinct set of test activities collected into a manageable phase of a project, e.g. the execution activities of a test level [after Gerrard].
test plan A document describing the scope, approach, resources and schedule of intended test activities.

It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and test measurement techniques to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process [after IEEE 829].

test planning The activity of establishing or updating a test plan.
test point analysis A formula based test estimation method based on function point analysis [TMap].
test policy A high-level document describing the principles, approach and major objectives of the organization regarding testing.
test procedure See test procedure specification.
test procedure specification A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829] See also test specification.
test process The fundamental test process comprises test planning and control, test analysis and design, test implementation and execution, evaluating on exit criteria and reporting, and test closure activities.
Test Process Group A collection of (test) specialists who facilitate the definition, maintenance, and improvement of the test processes used by an organization. [After CMMI]
test process improvement A program of activities designed to improve the performance and maturity of the organization’s test processes and the results of such a program. [After CMMI]
test process Improvement manifesto A statement that echoes the agile manifesto, and

defines values for improving the testing process. The values are:

– flexibility over detailed processes

– best Practices over templates

– deployment orientation over process orientation

peer reviews over quality assurance (departments)

– business driven over model driven. [Veenendaal08]

test process improver A person implementing improvements in the test process based on a test improvement plan.
test progress report A document summarizing testing activities and results, produced at regular intervals, to report progress of testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring a decision to management.
test record See test log.
test recording See test logging.
test report See test summary report.
test reporting Collecting and analyzing data from testing activities and subsequently consolidating the data in a report to inform stakeholders. See also test process.
test reproduceability An attribute of a test indicating whether the same results are produced each time the test is executed.
test requirement See test condition.
test result See result.
test rig See test environment.
test run Execution of a set of test cases on a specific version of the test object.
test run log See test log.
test scenario See test procedure specification.
test schedule A list of activities, tasks or events of the test process, identifying their intended

start and finish dates and/or times, and interdependencies.

test script Commonly used to refer to a test procedure specification, especially an automated one.
test selection criteria The criteria used to guide the generation of test cases or to select test cases in order to limit the size of a test.
test session An uninterrupted period of time spent in executing tests. In exploratory testing, each session is focused on a charter, but testers can also explore new opportunities or issues during this time. The tester creates and executes test cases on the fly and records their progress.

See also exploratory testing.

test set See test suite.
test situation See test condition.
test specification A document that consists of a test design specification, test case specification and/or test procedure specification.
test specification technique See test design technique.
test stage See test level.
test strategy A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).
test suite A set of several test cases for a component or system under test, where the post condition of one test case is often used as the precondition for the next one.
test summary report A document summarizing testing activities and results. It also contains an evaluation of the corresponding test against exit criteria [after IEEE 829].
test target A set of test exit criteria.
test technique See test design technique.
test tool 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 [TMap]. See also CAST.
test type A group of test activities aimed at testing a component or system one or more interrelated quality attributes. A test type is focused on a specific test objective, i.e. reliability test, usability test, regression test etc., and may take place on one or more test levels or test phases [after TMap].
testability The capability of the software product to enable modified software to be tested [ISO 9126]. See also maintainability.
testability review A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process [after TMap].
testable requirement A requirements that is stated in terms that permit establishment of test designs (and subsequently test cases) and execution of tests to determine whether the requirement has been met. [After IEEE 610]
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.
tester A skilled professional who is involved in the testing of a component or system.
testing The process consisting of all life cycle 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.
testware Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected outcomes, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing [after Fewster and Graham].
think aloud usability testing A usability testing technique where test participants share their thoughts with the moderator and observers by thinking aloud while they solve usability test tasks. Think aloud is useful to understand the test participant’s thoughts and vocabulary.
thread testing An approach to component integration testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy.
three-point estimation A test estimation method using estimated values for the “best case”, “worst case”, and “most likely case” of the matter being estimated, to define the degree of certainty associated with the resultant estimate.
time behavior See performance.
TMMi Acronym for Test Maturity Model integration.
top-down testing An incremental approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested. See also integration testing.
Total Quality Management An organization-wide management approach centered on quality, based on the participation of all members of the organization and aiming at longterm success through customer satisfaction, and benefits to all members of the organization and to society. Total Quality Management consists of planning, organizing, directing,

control, and assurance. [After ISO 8402]

TPA Acronym for Test Point Analysis.
TPG Acronym for test process group.
TPI Next A continuous business-driven framework for test process improvement that describes the key elements of an effective and efficient test process.
TQM Acronym for Total Quality Management.
traceability The ability to identify related items in documentation and software, such as requirements with associated tests. See also horizontal traceability, vertical traceability.
traceability matrix A two-dimensional table, which correlates two entities (e.g., requirements and test cases). The table is used to determine and achieve coverage, to trace back and forth from one entity to the other, and to assess the impact of proposed changes.
transactional analysis The analysis of transactions between people and within people’s minds; a transaction is defined as a stimulus plus a response. Transactions take place between people and between the ego states (personality segments) within one person’s mind.
transcendent-based quality A view of quality, wherein quality cannot be precisely defined, but we know it when we see it, or are aware of its absence when it is missing. Quality depends on the perception and affective feelings of an individual or group of individuals towards a product. [After Garvin] See also manufacturing-based quality, product-based quality, user-based quality, value-based quality.
U
understandability 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 [ISO 9126].

See also usability.

unit See component.
unit test framework 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 [Graham].
unit testing See component testing.
unreachable code Code that cannot be reached and therefore is impossible to execute.
usability Extent to which a software product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. [ISO 9241]
usability evaluation A process through which information about the usability of a system is gathered in order to improve the system (known as formative evaluation) or to assess the merit or worth of a system (known as summative evaluation). See also formative evaluation, summative evaluation.
usability requirement A requirement on the usability of a component or system.
usability test participant A representative user who solves typical tasks in a usability test.
usability test script A document specifying a sequence of actions for the execution of a usability test. It is used by the moderator to keep track of briefing and pre-session interview questions, usability test tasks, and post-session interview questions. See also test procedure specification.
usability test session A test session in usability testing in which a usability test participant is executing tests, moderated by a moderator and observed by a number of observers.
usability test task An usability test execution activity that needs to be accomplished within a defined period of time or by a deadline to work towards goals specified by the moderator.
usability testing Testing to evaluate the degree to which the system can be used by specified users with effectiveness, efficiency and satisfaction in a specified context of use.
use case 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.
use case testing A black-box test design technique in which test cases are designed to execute scenarios of use cases.
user acceptance testing Acceptance testing carried out by future users in a (simulated) operational environment focusing on user requirements and needs.
user experience A person’s perceptions and responses resulting from the use or anticipated use of a software product. [ISO 9241-210]
user interface All components of a system that provide information and controls for the user to accomplish specific tasks with the system.
user interface guideline A low-level, specific rule or recommendation for user interface design that leaves little room for interpretation so designers implement it similarly. It is often used to ensure consistency in the appearance and behavior of the user interface of the systems produced by an organization.
user scenario testing See use case testing.
user story A high-level user or business requirement commonly used in agile software development, typically consisting of one or more sentences in the everyday or business language capturing what functionality a user needs, any non-functional criteria, and also includes acceptance criteria. See also agile software development, requirement.
user story testing A black-box test design technique in which test cases are designed based on user stories to verify their correct implementation. See user story.
user survey A usability evaluation whereby a representative sample of users are asked to report subjective evaluation into a questionnaire based on their experience in using a component or system.
user test A test whereby real-life users are involved to evaluate the usability of a component or system.
user-based quality A view of quality, wherein quality is the capacity to satisfy needs, wants and desires of the user(s). A product or service that does not fulfill user needs is unlikely to find any users. This is a context dependent, contingent approach to quality since different business characteristics require different qualities of a product. [after Garvin] See also manufacturing-based quality, product-based quality, transcendent-based quality, valuebased

quality.

V
validation Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled [ISO 9000].
value-based quality A view of quality, wherein quality is defined by price. A quality product or service is one that provides desired performance at an acceptable cost. Quality is determined by means of a decision process with stakeholders on trade-offs between time, effort and cost aspects. [After Garvin] See also manufacturing-based quality, product-based quality, transcendent-based quality, user-based quality.
variable An element of storage in a computer that is accessible by a software program by referring to it by a name.
verification Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled [ISO 9000].
version control See configuration control.
vertical traceability The tracing of requirements through the layers of development documentation to components.
V-model A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.
volume testing Testing where the system is subjected to large volumes of data. See also resource-utilization testing.
vulnerability scanner A static analyzer that is used to detect particular security vulnerabilities in the code.
W
walkthrough A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content [Freedman and Weinberg], [IEEE 1028].

See also peer review.

WAMMI Acronym for Website Analysis and Measurement Inventory.
WBS Acronym for work breakdown structure.
WCAG Acronym for Web Content Accessibility Guidelines.
Web Content Accessibility Guidelines A part of a series of web accessibility guidelines published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), the main international standards organization for the internet. They consist of a set of guidelines for making content accessible, primarily for people with disabilities.
Website Analysis and MeasureMent Inventory A questionnaire-based usability test technique for measuring web site software quality from the end user’s point of view.
white-box techniques See white-box test design techniques.
white-box test design technique Procedure to derive and select test cases based on an analysis of the internal structure of a component or system.
white-box testing Testing based on an analysis of the internal structure of the component or system.
Wideband Delphi An expert-based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.
wild pointer A pointer that references a location that is out of scope for that pointer or that does not exist. See also pointer.
Work Breakdown Structure An arrangement of work elements and their relationship to each other and to the end product. [CMMI]
X
XP Acronym for Extreme Programming.