ISTQB Glossar, Deutsches Vokabular der ISTQB Wortdefinitionen für ISTQB Test Analyst, Test Manager, ISTQB Technical Test Analyst und Foundation Level – ISTQB Begriffsdefinitionen
| Begriff | Definition | |
|---|---|---|
| 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 | Eine Art des Komponentenintegrationstests, bei der 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.). | |
| Abnahme | Siehe Abnahmetest. | |
| Abnahmekriterien | Diejenigen Kriterien, die ein System oder eine Komponente erfüllen muss, um eine Abnahme durch den Benutzer, Kunden oder eine bevollmächtigte Instanz erfolgreich abschließen zu können. [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 des Testabschlussberichtes. 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-Review | Siehe informelles Review. | |
| 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 - funktionierende Software ist wichtiger als umfassende Dokumentation - Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen - Reagieren auf Veränderungen ist wichtiger als die Befolgung eines Plans. | |
| 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. | |
| Akzeptanztest | Siehe Abnahmetest. | |
| Algorithmustest | Siehe Zweigtest. [TMap] | |
| 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. | |
| 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 Services 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 Test, 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 Benutzbarkeit untersuchen. | |
| Anforderungsmanagementwer kzeug | 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. | |
| Angriff | Gezielter Versuch, um die Qualität eines Testobjekts, insbesondere die Zuverlässigkeit, zu bewerten, indem versucht wird, spezifische Fehlerwirkungen zu provozieren. Siehe auch Negativtest. | |
| angriffsbasiertes Testen | Ein erfahrungsbasiertes Testverfahren, das Softwareangriffe nutzt, um Fehlerwirkungen, insbesondere solche im Bereich der Zugangssicherheit, zu erzeugen. Siehe auch Angriff. | |
| 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] | |
| 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. | |
| 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-Test | Test des Codes, der die Kommunikation zwischen Prozessen, Programmen und/oder Systemen ermöglicht. Der API-Test beinhaltet oft Negativtests, d.h. das Testen der Robustheit und der Fehlerbehandlung. Siehe auch Schnittstellentest. | |
| Ä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überdeckun g | 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. | |
| Art des Risikos | Siehe Risikotyp. | |
| 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 Benutzbarkeit. | |
| 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. | |
| 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. | |
| ausgegliedertes Testen | Siehe Outsourcing des Testens. | |
| 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. | |
| 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 | 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. [IEEE 610] |
| 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. | |
| 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. | |
| Bedingungskombinationsteste n | Siehe Mehrfachbedingungstest. | |
| Bedingungskombinationsüberd eckung | 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 (atomaren) Teilbedingungen, die durch eine Gruppe von Testfällen ausgeführt worden sind. 100% (einfache) Bedingungsüberdeckung bedeutet, dass jede (atomare) Teilbedingung in jeder Entscheidung mindestens einmal mit den Werten True und False ausgeführt wurde. Zweigbedingungsüberdeckung. | |
| 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] | |
| Benutzbarkeit | Die Fähigkeit eines Softwareprodukts, unter spezifizierten Bedingungen für einen Benutzer verständlich, erlernbar, anwendbar und attraktiv zu sein. [ISO 9126] | |
| Benutzbarkeitstest | Testen, um zu bestimmen, inwieweit ein Softwareprodukt unter spezifizierten Bedingungen für einen Benutzer verständlich, leicht erlernbar, leicht anwendbar und attraktiv ist. [Nach ISO 9126] | |
| Benutzer-Abnahmetest | Siehe Abnahmetest. | |
| 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. | |
| Benutzertest | Test, bei dem reale Benutzer die Benutzbarkeit einer Komponente oder eines Systems bewerten. | |
| 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). | |
| 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. Anmerkung: 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] | |
| Bewertung | Siehe Testen. | |
| 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. | |
| 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. | |
| 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. Siehe auch Testautomatisierung. | |
| Change Control Board | Siehe Konfigurationskontrollboard. | |
| Charta | Siehe Test-Charta. | |
| Checklisten-basiertes Testen | Eine erfahrungsbasierte Testdesigntechnik, bei der 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. [Chow] | |
| Clear-Box-Test | Siehe White-Box-Test. | |
| CMMI | Abkürzung von 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] | |
| COTS | Abkürzung für commercial off the shelf software. Siehe Standardsoftware. | |
| 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 | Abkürzung von 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. | |
| Datenflussanomalie | Unbeabsichtigte oder nicht erwartete Folge von Operationen mit einer Variablen. Anmerkung: Folgende Datenflussanomalien werden unterschieden: ur-Anomalie (undefined referencing): Referenzierung einer undefinierten Variablen, dd-Anomalie (defined defined): zweimal aufeinanderfolgendes Schreiben auf eine Variable ohne zwischenzeitliche Referenzierung, du-Anomalie (defined undefined): Schreiben (definieren) einer Variablen mit späterer Zurücksetzung, ohne dass die Variable zwischendurch referenziert wird. | |
| Datenflussanomalieanalyse | (1) Statisches Analyseverfahren zur Aufdeckung von fehlerhaften Zugriffssequenzen auf die Variablen des Testobjekts. (2) Analyse, ob Datenvariablen richtig verwendet werden oder nicht. | |
| 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. | |
| Datenintegritätstest | Siehe Datenbankintegritätstest. | |
| Datenqualität | Eine Dateneigenschaft, welche die Richtigkeit bezüglich vorgegebener Kriterien angibt, z.B. Geschäftserwartungen, Anforderungen an Datenintegrität oder Datenkonsistenz. | |
| 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 | Siehe Fehlerzustand. | |
| Defektdichte | Siehe Fehlerdichte. | |
| 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. | |
| Dokumentationstest | Testen der Qualität der Dokumentation, z.B. des Benutzer- oder Installationshandbuchs. | |
| 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 | Die Fähigkeit, ein beabsichtigtes Ergebnis zu erzielen. Siehe auch Effizienz. |
| Effizienz | (1) Die Fähigkeit eines Softwareprodukts, unter festgelegten Bedingungen eine angemessene Leistung zu erbringen, bezogen auf den Umfang der eingesetzten Betriebsmittel. [ISO 9126] (2) Die Fähigkeit eines Prozesses die angedachte Leistung zu erbringen, bezogen auf den Umfang der eingesetzten Betriebsmittel. | |
| Effizienztest | Ein Test, mit dem die Effizienz eines Softwareprodukts ermittelt wird. | |
| EFQM 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). | |
| 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. | |
| Eingegliedertes Tessten | Siehe Insourcing des Testens. | |
| 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] | |
| 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. | |
| 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. [Nach Gilb und Graham] Anmerkung: Endekriterien werden in Berichten referenziert und zur Planung der Beendigung des Testens verwendet. | |
| 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. [Veenendaal04] 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 Testentwurfsverfahren, 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. | |
| Erlernbarkeit | Die Fähigkeit eines Softwareprodukts, einem Benutzer das Erlernen der Anwendung leicht zu machen. [ISO 9126] Siehe auch Benutzbarkeit. | |
| erschöpfender Test | Testvorgehensweise, bei der 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. | |
| 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 (XP) | 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, Benutzbarkeit 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 alle Ereignisse auflistet, die während des Testens aufgetreten sind und untersucht werden müssen. [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 Abweichungsmanagementwer kzeug | 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 | Siehe Angriff. | |
| 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 (FBA) | 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. | |
| 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. Siehe auch 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 (FMEA) | Eine systematische Vorgehensweise für die Risikoidentifikation und für die Analyse möglicher Fehler(aus)wirkungen und für ihre Vermeidung. Siehe auch Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse (FMECA). | |
| Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse (FMECA) | 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 (FMEA). | |
| 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. Siehe auch Regressionstest. | |
| Fehlerpriorität | Festlegung der Dringlichkeit von Korrekturmaßnahmen unter Berücksichtigung der Schweregrades, des erforderlichen Korrekturaufwands und der Auswirkungen auf den gesamten Entwicklungs- und Testprozess. | |
| 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. | |
| Fischgrätendiagramm | Siehe Ursache-Wirkungs-Diagramm. | |
| formales Review | Eine Reviewtechnik, die durch ein dokumentiertes Vorgehen und Anforderungen charakterisiert ist, z.B. eine Inspektion. | |
| Freigabemitteilung | Siehe Release Note. | |
| 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 | Eine Vorgehensweise zur Integration, bei der 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] Untermerkmale der Funktionalität nach ISO 9126 sind: Angemessenheit, Richtigkeit, Interoperabilität, Sicherheit und Konformität. | |
| Funktionalitätstest | Testen, um die Funktionalität eines Softwareprodukts zu bestimmen. | |
| Funktionspunktanalyse (FPA) | 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. | |
| G | 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. |
| geschäftsprozessbasierter Test | Ein Testverfahren, 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 Verfahren zur Messung von Software, das ein dreistufiges Modell verwendet: Die konzeptionelle Ebene (Goal), die operationelle Ebene (Question) und die quantitative Ebene (Metric). | |
| GQM | Abkürzung von Goal Question Metric. | |
| 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. | |
| Grenzwerttest | Siehe Grenzwertanalyse. | |
| 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. | |
| 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 | Hardware-Software Integrationstest | Testen mit der Absicht, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen Hardware- und Softwarekomponenten aufzudecken. |
| 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. | |
| heuristische Evaluation | Spezifische Form eines Reviews auf Benutzbarkeit, wobei die Gutachter die Benutzerschnittstelle 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. | |
| Hyperlink Werkzeug | Ein Werkzeug zur Prüfung von Webseiten auf ungültige Hyperlinks hin. | |
| 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. | |
| 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. | |
| 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] | |
| 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. | |
| Integrationstest ("im Großen") | Siehe Systemintegrationstest. | |
| Integrationstest ("im Kleinen") | Siehe Komponentenintegrationstest. | |
| 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. | |
| J | Janusangriff | Siehe Man-in-the-middle-Angriff |
| 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 Klassifikationsbaum, 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 Konfigurationselemente 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 Konfigurationselementen 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 Konfigurationselements, zur Überwachung und Protokollierung von Änderungen solcher Merkmale, zum Verfolgen des Änderungsprozesses, Umsetzungsstatus und zur Verifizierung der Übereinstimmung mit spezifizierten Anforderungen. [IEEE 610] | |
| Konfigurationsmanagementwer kzeug | 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. | |
| Konsistenz | Der Grad der Einheitlichkeit, Standardisierung und Widerspruchsfreiheit zwischen den Dokumenten und Teilen eines Systems oder einer Komponente. [IEEE 610] | |
| 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 abstrakte Repräsentation von allen möglichen Reihenfolgen 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 | 1. Eine abstrakte Repräsentation von allen möglichen Sequenzen von Ereignissen (Pfaden) der Ausführung in einer Komponente oder einem System. 2. Graphische Repräsentation des Kontrollflusses (bestehend aus Knoten und Kanten). Siehe auch Kontrollfluss. | |
| 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 Entscheidungstesten, Bedingungstesten, Pfadtesten | |
| 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. | |
| LCSAJ | LCSAJ (Linear Code Sequence and Jump) enthält drei Bestandteile (identifiziert durch eine Zeilennummer im Quellcode): - den Start einer linearen Folge von ausführbaren Anweisungen, - das Ende der linearen Folge von Anweisungen - und das Sprungziel, zu dem der Kontrollfluss am Ende der linearen Folge von Anweisungen verzweigt. | |
| LCSAJ Überdeckung | Der Anteil der LCSAJs einer Komponente, die durch eine Testsuite ausgeführt wurden. 100% LCSAJ Überdeckung schließt 100% Entscheidungsüberdeckung ein. | |
| LCSAJ Testverfahren | Ein White-Box-Testentwurfsverfahren, bei dem die Testfälle unter Berücksichtigung der LCSAJ des Testobjekts hergeleitet werden. | |
| 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. | |
| Linktest | Siehe Komponentenintegrationstest. | |
| logik-getriebener Test | Siehe White-Box-Test. | |
| Logik-Überdeckungstest | Siehe White-Box-Test. [Myers] | |
| 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] |
| Mangel | Nichterfüllung einer Anforderung in Bezug auf einen beabsichtigten oder festgelegten Gebrauch. [ISO 9000:2000] | |
| 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. | |
| 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überdeck ung | 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. | |
| memory leak | Siehe Speicherleck. | |
| 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] | |
| 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. | |
| 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. | |
| modellbasiertes Testen | Testen, das auf einem Modell der zu testenden Komponente oder des zu testenden Systems basiert, z.B. Zuverlässigkeitswachstumsmodelle, Nutzungsmodelle wie Nutzungsprofile oder Verhaltensmodelle wie Entscheidungstabellen oder Zustandsübergangsdiagramme. | |
| Modellierungswerkzeug | Ein Werkzeug, das die Erstellung, Pflege und Verifizierung von Modellen einer Software oder eines Systems unterstützt. [Graham] | |
| Moderator | Leiter und Hauptverantwortlicher einer Inspektion oder eines technischen Reviews. | |
| 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. | |
| Monitor | Ein Softwarewerkzeug oder eine Hardwareeinheit, die parallel zu dem zu testenden System/der Komponente arbeitet und den Betrieb überwacht, aufzeichnet und/oder analysiert oder verifiziert. [Nach IEEE 610] | |
| MTBF | Abkürzung von Mean Time Between Failures. | |
| MTTR | Abkürzung von Mean Time To Repair. | |
| Multisystem | Siehe System von Systemen. | |
| 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 | Siehe Back-to-Back-Test. | |
| Myers-Briggs-Typindikator (MBTI) | 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 eine bestimmte Testvorgehensweise oder ein bestimmtes Testentwurfsverfahren, wie etwa das Testen mit ungültigen Eingabewerten oder Ausnahmen. [Nach Beizer] | |
| 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, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit. Siehe auch Qualitätsziel. | |
| nicht-funktionaler Test | Testen der Eigenschaften eines System, die nicht direkt mit der Funktionalität in Verbindung stehen, z.B. Zuverlässigkeit, Effizienz, Benutzbarkeit, Ä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] | |
| 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] | |
| O | Objektübergabebericht | Siehe Release Note. |
| 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 Benutzbarkeit. | |
| 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 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. | |
| 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. | |
| 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. 100% Pfadüberdeckung schließt 100% LCSAJ-Überdeckung ein. | |
| 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. | |
| 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ät | Siehe Übertragbarkeit. | |
| 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. | |
| Problem | Siehe Fehlerzustand. | |
| Problemmanagement | Siehe Fehlermanagement. | |
| Problemmeldung | Siehe Fehler- und Abweichungsbericht. | |
| 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 mit zugehörigen Datenbeständen (inkl. Betriebssysteme, Datenbankmanagementsysteme und andere Applikationen enthalten. | |
| Produktrisiko | Ein Risiko, das direkt auf ein Testobjekt bezogen ist. Siehe auch Risiko. | |
| Programmieren in Paaren | Eine Vorgehensweise zur Softwareentwicklung, bei der 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 | Eine Sitzung am Ende eines Projekts, in der die Teilnehmer das Projekt bewerten und Erfahrungen austauschen, mit dem Ziel diese im nächsten Projekt umzusetzen. | |
| 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] | |
| Projekttestkonzept | Siehe Mastertestkonzept. | |
| 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] | |
| prozesskonformes Testen | Testen, welches definierten Prozessen folgt, die z.B. von einer externen Organisation wie einem Standardisierungs-Gremium definiert werden. Siehe auch standardkonformes Testen. | |
| Prozess-Modell | Ein Rahmenwerk zur Klassifizierung von Prozessen des gleichen Typs in einem übergeordneten Modell z.B. ein Testprozessverbesserungsmodell. | |
| 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 | Abkürzung von 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. Auftritthä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 | 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ä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, Benutzbarkeit, 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] | |
| Qualitätsziel | Etwas bezüglich Qualität Angestrebtes oder zu Erreichendes. [ISO 9000:2000] | |
| 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. | |
| Quellcodeanalysator | Siehe statischer Codeanalysator. | |
| 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. | |
| 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. | |
| 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 Modell 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 das Konzept, 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. | |
| Richtigkeit | 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ätstest. | |
| Richtigkeitstest | Der Prozess des Testens, um die Richtigkeit eines Softwareprodukts zu bestimmen. | |
| 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 | In der Risikoanalyse werden identifizierte Risiken nach ihrer Auftrittswahrscheinlichkeit und ihrem potenziellen Schadensausmaß bewertet. | |
| Risikobeherrschung | Siehe Risikoüberwachung. | |
| Risikobewertung | Der Prozess der Bewertung eines gegebenen Projekt- oder Produktrisikos, um die Risikostufe festzustellen, typischerweise durch die Bewertung von Eintrittswahrscheinlichkeit und Schadensausmaß, und anschließende Aggregation zu einer gesamten Risikopriorität. Siehe auch Produktrisiko, Projektrisiko, Risiko, Risikoauswirkung, Risikostufe, Risikowahrscheinlichkeit. | |
| 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 | Eine Vorgehensweise beim 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 Benutzbarkeitstests verringert werden. | |
| Risikoüberwachung | Die Risikoüberwachung unterstützt die Entscheidungen und Maßnahmen im laufenden Projekt zur Reduktion und Begrenzung von Risiken. | |
| 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 horizontale Rückverfolgbarkeit, vertikale Rückverfolgbarkeit. | |
| RUP | Abkürzung von 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. | |
| Sanity-Test | Siehe Smoke-Test. | |
| Schadensausmaß des Risikos | Der Schaden, der entsteht, wenn ein Risiko eintritt. | |
| 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. | |
| 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. | |
| 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. | |
| 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 | Eine Vorgehensweise beim Testen, bei der die Testaktivitäten - insbesondere Testdesign 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. | |
| Skriptsprache | Eine Programmiersprache zur Erstellung ausführbarer Skripte, die dann durch ein Testausführungswerkzeug (z.B. Capture/Replay- Werkzeug) verwendet werden. | |
| 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. Anmerkung: 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. | |
| Softwareangriff | Siehe Angriff. | |
| Softwarebenutzbarkeits- Messinventar | Ein Testverfahren zur Bewertung der Benutzbarkeit der Software aus Endbenutzersicht, das auf einem Fragenkatalog basiert. [Veenendaal04] Abkürzung: SUMI (Software Usability Measurement Inventory). | |
| Softwareelement | Siehe Konfigurationselement. | |
| Softwarefeature | Siehe Feature. | |
| Softwarefehlerbaum-Analyse (SFBA) | Siehe Fehlerbaum-Analyse (FBA). | |
| Softwarefehler-Möglichkeits- und Einfluss-Analyse (SFMEA) | Siehe Fehler-Möglichkeits- und Einfluss-Analyse (FMEA). | |
| Softwarefehler-Möglichkeits-, Einfluss- und Kritikalitäts- Analyse (SFMECA) | Siehe Fehler-Möglichkeits-, Einfluss- und Kritikalitäts-Analyse (FMECA). | |
| 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. | |
| 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] | |
| spezifikationsbasierter Test | Siehe Black-Box-Test. | |
| spezifikationsbasiertes Testentwurfsverfahren | Siehe spezifikationsorientiertes Testentwurfsverfahren. | |
| spezifikationsorientierter Test | Siehe Black-Box-Test. | |
| spezifikationsorientiertes Testentwurfsverfahren | Siehe Black-Box-Testentwurfsverfahren. | |
| spezifizierte Eingabe | Eine Eingabe, für die die Spezifikation ein Ergebnis vorgibt. | |
| spezifkationsbasiertes Verfahren | Siehe Black-Box-Testentwurfsverfahren. | |
| spezifkationsorientiertes Verfahren | Siehe Black-Box-Testentwurfsverfahren. | |
| SPI | Abkürzung für Software-Prozessverbesserung (engl. Software Process Improvement). | |
| 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] | |
| 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 Quelltextes ohne Ausführung der Software. | |
| statischer Analysator | Ein Werkzeug, das eine statische Analyse durchführt. | |
| statischer Codeanalysator | Ein Werkzeug, welche eine statische Codeanalyse durchführt. Das Werkzeug prüft den Quellcode auf bestimmte Eigenschaften wie z.B. Konformität mit Programmierkonventionen, Qualitätsmetriken oder Datenflussanomalien. | |
| 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 | Abkürzung von Systematic Test and Evaluation Process. | |
| 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. | |
| strukturbasierte Testentwurfsverfahren | Siehe White-Box-Testentwurfsverfahren. | |
| strukturbasierter Test | Siehe White-Box-Testentwurfsverfahren. | |
| 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. | |
| strukturierter Walkthrough | Siehe Walkthrough. | |
| Stub | Siehe Platzhalter. | |
| 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 | Abkürzung von Software Usability Measurement Inventory (Softwarebenutzbarkeits-Messinventar). | |
| Syntaxtest | Ein Black-Box-Testentwurfsverfahren, bei dem Testfälle auf Basis der Definition der Eingangsdaten erstellt werden. | |
| System | (1) Eine Zusammenstellung von Komponenten, um eine spezifische Funktion oder eine Menge von Funktionen zu erfüllen. [IEEE 610] (2) Satz von in Wechselbeziehungen oder Wechselwirkungen stehenden Elementen. [ISO 9000:2000] | |
| 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 Bewertungsprozess | Eine strukturierte Testmethode, die auch als inhaltsbasiertes Modell für die Testprozessverbesserung genutzt wird. Sie fordert keine bestimmte Reihenfolge für die Verbesserungsmaßnahmen. Abkürzung: STEP (Systematic Test and Evaluation Process) Siehe auch inhaltsbasiertes Modell. | |
| 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 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. | |
| 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, Benutzbarkeitstest. Die Testart kann sich auch auf eine oder mehrere Teststufen oder -phasen beziehen. [Nach TMap®] | |
| Testaufzeichnung | Siehe Testprotokollierung. | |
| Testausführung | Siehe Testdurchführung. | |
| 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ührungswerkzeug | Ein Testwerkzeug, das mit einem automatisierten Testskript eine andere Software steuern kann, z.B. ein Capture/Replay-Werkzeug. [Fewster und Graham] | |
| Testausgang | Siehe Ergebnis. | |
| Testautomatisierung | Einsatz von Softwarewerkzeugen zur Durchführung oder Unterstützung von Testaktivitäten, z.B. Testmanagement, Testentwurf, Testausführung und Soll/Ist-Vergleich. | |
| 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. | |
| 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 explorativem 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. | |
| Testdesign | Siehe Testentwurf. | |
| 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-Test, 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 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 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. | |
| 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. | |
| testgetriebene Entwicklung | Bei einer testgetriebenen Entwicklung erfolgt die Entwicklung und oft auch die Automatisierung der Testfälle vor der Entwicklung der Software. | |
| Testhandbuch | Siehe Teststrategie. | |
| 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] | |
| Testkriterien | Die Kriterien, die ein System oder eine Komponente für das Bestehen eines Tests erfüllen muss. [IEEE 610.12] Siehe auch Endekriterien, bestanden/nicht bestanden-Kriterien. | |
| 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. | |
| 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] | |
| Testmonitor | Siehe Monitor. | |
| 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. | |
| Testprozessverbesserungsma nifest | 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 (TPA) | Eine formelbasierte Schätzmethode für das Testen auf Grundlage der Funktionspunktanalyse. [Nach 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, Vorgehensweisen und 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. | |
| Testtyp | Siehe Testart. | |
| 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 | Eine Kombination von Tätigkeiten zum systematischen Erzeugen eines Testproduktes. Testverfahren sind unter Anderem verfügbar für: Testschätzung, Fehlermanagement, Produktrisikoanalyse, Testentwurf, Testdurchführung und Reviews. | |
| 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. | |
| Testvorgehensspezifikation | Siehe Testablaufspezifikation. | |
| 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. | |
| Testware | Siehe Testmittel. | |
| 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 | Abkürzung von Test Maturity Model Integration. | |
| Toleranz gegen Fehleingaben | Die Fähigkeit eines Systems oder einer Komponente, das spezifizierte Leistungsniveau trotz Fehleingaben beizubehalten. [Nach IEEE 610] Siehe auch Robustheit. | |
| Top-Down-Integrationstest | Eine inkrementelle Vorgehensweise für den Integrationstest, bei der die Komponenten Komponente an der Spitze der Komponentenhierarchie zuerst getestet werden wird 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 beruhende Managementmethode einer Organisation, die 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. | |
| TPG | Abkürzung von Testprozessgruppe. | |
| TPI Next® | Ein durchgängiges Rahmenwerk für die Testprozessverbesserung, das die Schlüsselelemente eines effektiven und effizienten Testprozesses beschreibt. | |
| TQM | Abkürzung von 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. | |
| Überdeckungsmessungswerkz eug | 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 | Die Analyse von Fehlerzuständen mit dem Zweck, ihre Grundursachen zu bestimmen. [CMMI] | |
| 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. | |
| 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. | |
| Vergleichswerkzeug | Siehe Testkomparator. | |
| Verhalten | Die Reaktion einer Komponente oder eines Systems auf eine Menge von Eingaben unter Berücksichtigung bestimmter Vorbedingungen. | |
| Verifikation | Siehe Verifizierung. | |
| 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. | |
| 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 Benutzbarkeit. | |
| 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. | |
| 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] Siehe auch Peer Review. |
| WAMMI | Abkürzung von Website Analysis and MeasureMent Inventory (Webseitenanalyse und Messung). | |
| 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. | |
| Website Analysis and MeasureMent Inventory (WAMMI) | Eine fragebogenbasiertes Benutzbarkeitstestverfahren 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. | |
| XYZ | 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. | |
| Zugänglichkeitstest | Testen, um festzustellen, inwieweit Benutzer mit besonderen Bedürfnissen in der Lage sind, eine Komponente oder ein System zu benutzen. [Gerrard] | |
| 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. | |
| Zustandsübergangstest | Siehe zustandsbasierter Test. | |
| 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ässigkeitswachstumsmo dell | 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. | |
| Zweigbedingungskombinations testen | 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. |
Quelle: ISTQB / German Testing Board (GTB Glossar) – Version 2.2 vom 19 April 2013
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!