Diejenigen Kriterien, die ein System oder eine Komponente erfüllen muss, um durch den Benutzer, Kunden oder eine bevollmächtigte Instanz abgenommen zu werden.
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.
Während des Abschlusses der Testaktivitäten werden die gesammelten Daten aus den abgeschlossenen Aktivitäten verwendet, um die Erfahrungen, und Testmittel, Fakten und Zahlen zu konsolidieren. Der Abschluss der Testaktivitäten umfasst die Konsolidierung und Archivierung der Testmittel und die Bewertung des Testprozesses einschließlich eines Testbewertungsberichtes.
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.
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.
Ein Werkzeug, das eine statische Analyse durchführt.
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.
Ein Ansatz zum Testen, der auf den Anforderungen basiert. Aus ihnen werden die Testziele und Testbedingungen abgeleitet. Dazu gehören Tests, die einzelne Funktionen tätigen oder solche, die nicht funktionalen Eigenschaften wie Zuverlässigkeit oder Gebrauchstauglichkeit untersuchen.
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.
Syntaktisch definierte Einheit einer Programmiersprache (z.B. Zuweisung an eine Variable), die typischerweise die kleinste, unteilbare ausführbare Einheit darstellt.
Eine Folge von Vorgängen in einem Dialog zwischen einem Akteur und einer Komponente oder einem System, die zu einem konkreten Ergebnis führen. Ein Akteur kann dabei ein Benutzer sein, oder irgendetwas, was Informationen mit dem System austauschen kann.
Eine Menge von Risiken, die einen oder mehrere gemeinsame Aspekte aufweisen, wie Qualitätsmerkmal, Ursache, Ort oder mögliche Auswirkung des Risikos. Bestimmte Risikotypen können durch eine bestimmte Testart reduziert (kontrolliert) werden. Zum Beispiel kann das Riskio missverstandener Bedienerinteraktionen durch Gebrauchstauglichkeitstests verringert werden.
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.
Eine Variable, die durch eine Komponente geschrieben wird (und innerhalb oder außerhalb einer Komponente gespeichert wird).
Die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden. Endekriterien für eine Aktivität verhindern es, dass die Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind. Endekriterien werden in Berichten referenziert und zur Planung der Beendigung des Testens verwendet.
Testen durch Personen, die nicht an einem gemeinsamen Ort mit dem Projektteam arbeiten und nicht Mitarbeiter im Unternehmen des Projektteams sind.
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.
Der Grad, zu dem ein Produkt oder System von einer in Bezug auf ihre Fähigkeiten möglichst weit gefassten Gruppe von Menschen gebraucht werden kann, um ein gegebenes Ziel in einem gegebenen Nutzungskontext zu erreichen.
Die Fähigkeit eines Softwareprodukts, unter spezifizierten Bedingungen für einen Benutzer verständlich, erlernbar, anwendbar und attraktiv zu sein.
Testen mit dem Ziel herauszufinden inwieweit das System durch spezifizierte Benutzer in einem bestimmten Kontext mit Effektivität, Effizienz und Zufriedenheit genutzt werden kann.
Wahrnehmungen und Reaktionen einer Person, die aus der tatsächlichen und/oder der erwarteten Benutzung eines Softwareproduktes resultieren.
Alle Bestandteile eines Systems, die Informationen und Steuerelemente zur Verfügung stellen, die für den Benutzer notwendig sind, um eine bestimmte Arbeitsaufgabe mit dem System zu erledigen.
Alle Bestandteile eines Systems, die Informationen und Steuerelemente zur Verfügung stellen, die für den Benutzer notwendig sind, um eine bestimmte Arbeitsaufgabe mit dem System zu erledigen.
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.
Der Status eines Tests, bei dem erwartetes Ergebnis und Istergebnis übereinstimmen.
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.
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.
Ein expertenbasiertes Verfahren zur Testschätzung, mit dem Ziel, durch Einbeziehung von Teammitgliedern zu einer möglichst genauen Schätzung zu kommen.
Eine Menge von automatisierten Tests, welche die Integrität jedes neuen Builds validieren, und ihre Kernfunktionalität, Stabilität und Testbarkeit verifizieren.
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.
Eine Anweisung von Testzielen und möglichen Testideen wie getestet werden soll. Test-Chartas werden oft im explorativen Testen verwendet.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
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.
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.
Tätigkeit des Lokalisierens/Identifizierens, Analysierens und Entfernens der Ursachen von Fehlerwirkungen in der Software.
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.
Eine systematische Liste von Fehlerarten mit ihrer hierarchischen Gliederung in Fehlerkategorien. Sie dient der Klassifikation von Fehlerzuständen.
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.
Die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden. Endekriterien für eine Aktivität verhindern es, dass die Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind. Endekriterien werden in Berichten referenziert und zur Planung der Beendigung des Testens verwendet.
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.
Prüfung des Testobjekts durch Ausführung auf einem Rechner.
(1) Die Fähigkeit, ein beabsichtigtes Ergebnis zu erzielen. (2) Der Umfang in welchem richtige und vollständige Ziele erreicht werden.
(1) Die Fähigkeit eines Softwareproduktes, in Relation zu den eingesetzten Mitteln und festgelegten Bedingungen, angemessene Performanz zu erzielen. (2) Die Fähigkeit eines Prozesses, in Relation zu den eingesetzten Mitteln, ein beabsichtigtes Ergebnis zu erbringen. (3) Eingesetzte Mittel im Verhältnis zu dem Ausmaß, in dem Benutzer spezifische Ziele erreichen.
Eine Variable, die durch eine Komponente eingelesen wird (unabhängig davon, ob sie innerhalb oder außerhalb der Komponente gespeichert wird).
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.
Testen durch Personen, die am selben Ort wie das Projektteam tätig sind, aber nicht Mitarbeiter des gleichen Unternehmens sind.
Die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden. Endekriterien für eine Aktivität verhindern es, dass die Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind. Endekriterien werden in Berichten referenziert und zur Planung der Beendigung des Testens verwendet.
Ein Fehlerzustand, der in einer früheren Teststufe nicht entdeckt wurde, obwohl jene Teststufe solche Fehler aufdecken sollte.
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.
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.
Testen, das auf der Erfahrung, dem Wissen und der Intuition des Testers basiert.
Der Status eines Tests, bei dem erwartetes Ergebnis und Istergebnis übereinstimmen.
Das Verhalten eines Systems oder einer Komponente unter festgelegten Bedingungen, das durch die Spezifikation oder durch eine andere Quelle festgelegt ist.
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.
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.
Ein Ergebnis, das einen Fehlerzustand nicht anzeigt, obwohl der Fehlerzustand im Testobjekt enthalten ist.
Ein Testergebnis, das einen Fehlerzustand anzeigt, obwohl der Fehlerzustand nicht im Testobjekt enthalten ist.
Ein kennzeichnendes Merkmal einer Komponente oder eines Systems.
Ein systematischer Ansatz zur Risikoidentifikation sowie zur Analyse möglicher Fehler(aus)wirkungen und zu ihrer Vermeidung.
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.
Ein Testentwurfsverfahren, bei dem die Testfälle im Hinblick auf die Aufdeckung von bestimmten Fehlerarten entworfen werden, ausgehend von Kenntnissen über diese Fehlerarten.
Ein Testentwurfsverfahren, bei dem die Testfälle im Hinblick auf die Aufdeckung von bestimmten Fehlerarten entworfen werden, ausgehend von Kenntnissen über diese Fehlerarten.
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.
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.
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.
Der Anteil der Fehlerzustände, die in derselben Phase des Softwareprozesses behoben werden, in welcher diese verursacht wurden.
Prozess der Erkennung, der Analyse, der Bearbeitung und des Abschlusses eines aufgedeckten Fehlerzustands. Er umfasst Aufzeichnung, Klassifizierung und die Identifikation der Auswirkungen.
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.
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.
Der Grad der Auswirkungen, den ein Fehlerzustand auf Entwicklung oder Betrieb einer Komponente oder eines Systems hat.
Eine systematische Liste von Fehlerarten mit ihrer hierarchischen Gliederung in Fehlerkategorien. Sie dient der Klassifikation von Fehlerzuständen.
Abweichung einer Komponente/eines Systems von der erwarteten Lieferung, Leistung oder dem Ergebnis.
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.
Die menschliche Handlung, die zu einem falschen Ergebnis führt.
Eine Reviewtechnik, die durch ein dokumentiertes Vorgehen und Anforderungen charakterisiert ist, z.B. eine Inspektion.
Anforderung, die ein funktionales Verhalten spezifiziert, die ein System oder eine Systemkomponente ausführen können muss.
Die Fähigkeit eines Softwareprodukts beim Einsatz unter spezifizierten Bedingungen Funktionen zu liefern, die festgelegte und vorausgesetzte Erfordernisse erfüllen.
Eine Anforderung an die Gebrauchstauglichkeit einer Komponente oder eines Systems.
Testen mit dem Ziel herauszufinden inwieweit das System durch spezifizierte Benutzer in einem bestimmten Kontext mit Effektivität, Effizienz und Zufriedenheit genutzt werden kann.
Ein Verfahren zur Beschreibung der Risikobestandteile. Entsprechend dem Ergebnis der Gefährlichkeitsanalyse sind für das System geeignete Entwicklungs- und Testverfahren einzusetzen.
Die Fähigkeit eines Softwareprodukts, die richtigen oder vereinbarten Ergebnisse oder Wirkungen mit dem benötigten Grad an Genauigkeit zu liefern.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
Die Ursache eines Fehlerzustands. Wenn man sie behebt, dann wird das Vorkommen der Fehlerart reduziert oder eliminiert.
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.
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.
Testen mit der Absicht, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen Hardware- und Softwarekomponenten aufzudecken.
Eine allgemein anerkannte Faustregel, die dabei hilft, ein Ziel zu erreichen.
Das Verfolgen von Anforderungen einer Teststufe über die Ebenen der Testdokumentation (z.B. Testkonzept, Testentwurfsspezifikation, Testfallspezifikation, Testablaufspezifikation oder Testskripte).
Das Verfolgen von Anforderungen einer Teststufe über die Ebenen der Testdokumentation (z.B. Testkonzept, Testentwurfsspezifikation, Testfallspezifikation, Testablaufspezifikation oder Testskripte).
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.
Review ohne festgelegten formalen (dokumentierten) Ablauf.
Testen durch Personen, die am selben Ort wie das Projektteam tätig sind, aber nicht Mitarbeiter des gleichen Unternehmens sind.
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.
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.
Der Prozess der Verknüpfung von Komponenten zu größeren Gruppen.
Testen mit dem Ziel, Fehlerzustände in den Schnittstellen und im Zusammenspiel zwischen integrierten Komponenten aufzudecken.
Die Fähigkeit eines Softwareprodukts, mit einer oder mehreren spezifizierten Komponenten zusammenzuwirken.
Testen zur Bestimmung der Interoperabilität eines Softwareprodukts.
Im Test beobachtetes/erzeugtes Verhalten einer Komponente oder eines Systems unter festgelegten Bedingungen.
Die Durchführung von Tests, um die Sicherheit (im Sinne von Zugriffsschutz) eines Softwareprodukts zu bestimmen.
Schwierigkeitsgrad, mit dem der Entwurf und/oder die interne Struktur einer Komponente oder eines Systems zu verstehen, zu warten und zu prüfen ist.
(1) Kleinste Softwareeinheit, die für sich getestet werden kann.
(2) Kleinste Softwareeinheit, für die eine separate Spezifikation verfügbar ist.
Testen wird durchgeführt mit dem Ziel, Fehlerzustände in den Schnittstellen und dem Zusammenwirken der integrierten Komponenten aufzudecken.
Testen einer (einzelnen) Komponente.
Die Anordnung eines Computersystems bzw. einer Komponente oder eines Systems, wie sie durch Anzahl, Beschaffenheit und Verbindungen seiner Bestandteile definiert ist.
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.
Die Fähigkeit eines Softwareprodukts, anwendungsspezifische Normen oder Vereinbarungen oder gesetzliche Bestimmungen und ähnliche Vorschriften zu erfüllen.
Ein Testfall mit konkreten Werten für Eingaben und vorausgesagte Ergebnisse. Logische Operanden der abstrakten Testfälle werden durch konkrete Werte ersetzt.
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.
Ein erfahrener Manager, der die Testmanager leitet.
(1) Der Leiter oder die Hauptperson, die für eine Inspektion oder einen Reviewprozess verantwortlich ist. (2) Eine neutrale Person, die eine Gebrauchstauglichkeitstestsitzung leitet.
Testen wird durchgeführt mit dem Ziel, Fehlerzustände in den Schnittstellen und dem Zusammenwirken der integrierten Komponenten aufzudecken.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
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.
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.
Ein Testkonzept, das sich typischerweise auf mehrere Teststufen bezieht.
Die Zahl oder Kategorie, die einem Attribut einer Einheit durch die Durchführung einer Messung zugeordnet wird.
Ein Software-Werkzeug, welches speziell für eine Gruppe von Nutzern oder Kunden entwickelt wurde.
Die durchschnittliche Zeitspanne zwischen Fehlerwirkungen einer Komponente oder eines Systems.
Markiert einen Zeitpunkt im Projekt(-prozess), zu dem ein bestimmtes Arbeitsergebnis oder definiertes Zwischenergebnis fertig gestellt sein soll.
Der Prozess, eine Zahl oder Kategorie einer Einheit zuzuweisen, um ein Attribut dieser Einheit zu beschreiben.
Die Mess-Skala und das genutzte Verfahren einer Messung.
(1) Der Leiter oder die Hauptperson, die für eine Inspektion oder einen Reviewprozess verantwortlich ist. (2) Eine neutrale Person, die eine Gebrauchstauglichkeitstestsitzung leitet.
(1) Kleinste Softwareeinheit, die für sich getestet werden kann.
(2) Kleinste Softwareeinheit, für die eine separate Spezifikation verfügbar ist.
Testen einer (einzelnen) Komponente.
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.
Testen der Eigenschaften eines System, die nicht direkt mit der Funktionalität in Verbindung stehen, z.B. Zuverlässigkeit, Effizienz, Gebrauchstauglichkeit, Änderbarkeit und Übertragbarkeit.
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.
Der Prozess der Entwicklung und Implementierung eines Nutzungsprofiles.
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 verteilen.
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.
Ein Dokument, das auf hohem Abstraktionsniveau die Prinzipien, den Ansatz und die wichtigsten Ziele einer Organisation in Bezug auf das Testen zusammenfasst.
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.
Testen durch Personen, die nicht an einem gemeinsamen Ort mit dem Projektteam arbeiten und nicht Mitarbeiter im Unternehmen des Projektteams sind.
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.
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.
Der Grad, in dem ein System oder eine Komponente seine vorgesehenen Funktionen innerhalb vorgegebener Bedingungen (z.B. konstanter Last) hinsichtlich Verarbeitungszeit und Durchsatzleistung erbringt.
Testen zur Bestimmung der Performanz eines Softwareprodukts.
Eine Aufteilung der Lebensdauer eines Produktes oder Projektes in Phasen.
Die Aktivitäten, die in jeder Stufe der Softwareentwicklung durchgeführt werden, sowie ihre logischen und zeitlichen Verknüpfungen miteinander.
Die Stufe der Wichtigkeit, die einem Objekt (z.B. Fehlerzustand) zugeordnet worden ist.
Ein systematischer Ansatz zum risikobasierten Test welche von der Identifikation und Analyse der Produktrisiken ausgeht, um eine Produktrisikomatrix mit Eintrittswahrscheinlichkeit und Schadensausmaß zu erstellen.
Die Bezeichnung ist von Product RISk MAnagement abgeleitet.
Ein Risiko, das direkt auf ein Testobjekt bezogen ist.
Ein Standard, welcher die erforderlichen Eigenschaften eines Designs oder einer Designbeschreibung von Daten oder Programmkomponenten beschreibt.
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.
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.
Die strukturierte Erfassung der gesammelten Erfahrungen und Aufstellung eines Maßnahmenplans von Verbesserungen für die nächsten Projekte oder Projektphasen.
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.
Anordnung von Arbeitselementen und ihre Beziehungen untereinander und zum Endprodukt.
Ein Satz von in Wechselbeziehungen stehenden Aktivitäten und Ressourcen, die Eingaben in Ergebnisse umgestalten.
Eine systematische Bewertung der Softwareprozesse in einer Organisation unter Verwendung eines Referenz-Modells.
Ein Rahmenwerk zur Klassifizierung von Prozessen des gleichen Typs in einem übergeordneten Modell.
Ein Prozessmodell, das ein Grundgerüst an Best Practices, zusammen mit einem Verfahren zur schrittweisen Verbesserung, aufstellt.
Ein Maßnahmenprogramm zum Zweck der Verbesserung der Leistungsfähigkeit und Reife der Prozesse eines Unternehmens, und das Ergebnis eines solchen Programms.
Nachweisverfahren der Fähigkeit, bestimmte Anforderungen zu erfüllen.
Bemerkung: Der Begriff "qualifiziert" bezeichnet den entsprechenden Status.
Der Grad, in dem ein System, eine Komponente oder ein Prozess die Kundenerwartungen und -bedürfnisse erfüllt.
Fähigkeit oder Eigenschaft, welche die Qualität einer Einheit beeinflusst.
Eine moderiertes Workshop-Verfahren, welches dabei hilft, kritische Eigenschaften bei der Produktentwicklung zu bestimmen.
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.
Fähigkeit oder Eigenschaft, welche die Qualität einer Einheit beeinflusst.
Ein Risiko bezüglich eines Qualitätsmerkmals.
Teil des Qualitätsmanagements, das darauf gerichtet ist, Vertrauen in die Erfüllung der Qualitätsanforderungen zu erzeugen.
Syntaktisch definierte Einheit einer Programmiersprache (z.B. Zuweisung an eine Variable), die typischerweise die kleinste, unteilbare ausführbare Einheit darstellt.
Ein proprietäres anpassbares iteratives Rahmenwerk für Software Entwicklungsprozesse, bestehend aus vier Projektphasen: Konzeptionsphase, Entwurfsphase, Konstruktionsphase, Übergabephase.
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.
Eine Teststrategie, bei der das Testteam verschiedene Verfahren für das Management des Risikos von Regression verwendet, z.B. durch funktionale und/oder nicht-funktionale Regressionstestautomatisierung auf einer oder mehreren Teststufen.
(1) Das Ausmaß, in welchem eine Organisation ihre Prozesse (Abläufe) effizient und effektiv gestaltet hat.
Grad der Prozessverbesserung in einem vordefinierten Satz von Prozessgebieten, in dem alle spezifischen und generischen Ziele erreicht werden.
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.
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.
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.
(1) Der Leiter oder die Hauptperson, die für eine Inspektion oder einen Reviewprozess verantwortlich ist. (2) Eine neutrale Person, die eine Gebrauchstauglichkeitstestsitzung leitet.
Ein Dokument, welches den Ansatz, die Ressourcen und den Zeitplan für die beabsichtigten Reviewaktivitäten beschreibt. Es beschreibt unter anderem folgendes: zu prüfende Dokumente und Code, zu verwendende Reviewarten, Teilnehmer, Eingangs- und Endekriterien für formale Reviews und Begründung für deren Auswahl. Der Reviewplan ist ein Ergebnis des Reviewplanungsprozesses.
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.
Die Fähigkeit eines Softwareprodukts, die richtigen oder vereinbarten Ergebnisse oder Wirkungen mit dem benötigten Grad an Genauigkeit zu liefern.
Ein Faktor, der zu negativen Konsequenzen in der Zukunft führen könnte, gewöhnlich ausgedrückt durch das Schadensausmaß und die Eintrittswahrscheinlichkeit.
Bewertung von identifizierten Projektrisiken oder Produktrisiken um ihre Risikostufe zu bestimmen, typischerweise durch die Bewertung von Schadensausmaß und Eintrittswahrscheinlichkeit.
Der Prozess der Identifizierung und der anschließenden Analyse des identifizierten Projektrisikos oder Produktrisikos, um die Risikostufe festzustellen, typischerweise durch die Bewertung von Eintrittswahrscheinlichkeit und Schadensausmaß.
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.
Der Prozess der Identifikation von Risiken mit Verfahren wie Brainstorming, Checklisten und Fehlerhistorie.
Eine Menge von Risiken, die einen oder mehrere gemeinsame Aspekte aufweisen, wie Qualitätsmerkmal, Ursache, Ort oder mögliche Auswirkung des Risikos. Bestimmte Risikotypen können durch eine bestimmte Testart reduziert (kontrolliert) werden. Zum Beispiel kann das Riskio missverstandener Bedienerinteraktionen durch Gebrauchstauglichkeitstests verringert werden.
Systematische Anwendung von Praktiken für die Aufgaben der Risikoidentifizierung, Risikoanalyse, Risikopriorisierung und Risikoüberwachung.
Ein Ansatz zum Testen, um Produktrisiken zu reduzieren und die Stakeholder hinsichtlich der Produktrisiken zu informieren, beginnend in den frühen Phasen des Projekts. Risikoorientiertes Testen beinhaltet die Identifizierung der Produktrisiken und die Verwendung von Risikostufen zur Steuerung des Testprozesses.
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.
Eine Menge von Risiken, die einen oder mehrere gemeinsame Aspekte aufweisen, wie Qualitätsmerkmal, Ursache, Ort oder mögliche Auswirkung des Risikos. Bestimmte Risikotypen können durch eine bestimmte Testart reduziert (kontrolliert) werden. Zum Beispiel kann das Riskio missverstandener Bedienerinteraktionen durch Gebrauchstauglichkeitstests verringert werden.
Die Fähigkeit, zusammengehörige Teile von Dokumentation und Software zu identifizieren, insbesondere die Anforderungen mit den dazu gehörigen Testfällen.
Eine zweidimensionale Tabelle, die die gegenseitigen Beziehungen zweier Entitäten wie z.B. Anforderungen und Testfälle darstellt. Die Tabelle wird zur Bestimmung und Erreichung der Überdeckung verwendet, um von einer Entität zur anderen und zurück zu verfolgen, und um die Auswirkung von Änderungsvorschlägen zu bewerten.
Ein iterativ inkrementelles Vorgehensmodell für das Projektmanagement, das im Allgemeinen bei agiler Softwareentwicklung verwendet wird.
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.
Die Fähigkeit bis zu dem eine Komponente oder ein System veränderten Lastbedingungen angepasst werden kann.
Programme, Prozeduren und möglicherweise zugeordnete Dokumentation und Daten für die betreffende Verarbeitung auf einem Computersystem.
Eine Reihe von Tätigkeiten zur Verbesserung der Leistung und Reife der Software-Prozesse einer Organisation sowie die Ergebnisse einer solchen Aktivität.
Die Aktivitäten, die in jeder Stufe der Softwareentwicklung durchgeführt werden, sowie ihre logischen und zeitlichen Verknüpfungen miteinander.
Ein kennzeichnendes Merkmal einer Komponente oder eines Systems.
Ein systematischer Ansatz zur Risikoidentifikation sowie zur Analyse möglicher Fehler(aus)wirkungen und zu ihrer Vermeidung.
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.
Fähigkeit oder Eigenschaft, welche die Qualität einer Einheit beeinflusst.
Das Verhalten eines Systems oder einer Komponente unter festgelegten Bedingungen, das durch die Spezifikation oder durch eine andere Quelle festgelegt ist.
Dokumentation, welche die detaillierte Beschreibung einer Komponente oder eines Systems zum Zweck der Implementierung und des Tests bereitstellt.
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).
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.
Die Analyse des Quellcodes ohne Ausführung der Software.
Ein Werkzeug, das eine statische Analyse durchführt.
Testen von Software-Entwicklungsartefakten, z.B. Anforderungen oder Quelltext, ohne diese auszuführen, z.B. durch Reviews oder statische Analyse.
Ein Werkzeug, das eine statische Analyse durchführt.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
Überdeckung, die auf Basis der internen Struktur von Komponenten oder eines Systems gemessen wird.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
Eine schrittweise Präsentation eines Dokuments durch den Autor, um Informationen zu sammeln und ein gemeinsames Verständnis des Inhalts aufzubauen.
Ein Testkonzept, das typischerweise für genau eine Teststufe gilt.
(1) Eine Zusammenstellung von Komponenten, um eine spezifische Funktion oder eine Menge von Funktionen zu erfüllen.
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.
Testen der Integration von Systemen und Paketen, Testen der Schnittstellen zu einer externen Organisation (z.B. Electronic Data Interchange oder Internet).
Testen eines integrierten Systems, um sicherzustellen, dass es spezifizierte Anforderungen erfüllt.
Im Test beobachtetes/erzeugtes Verhalten einer Komponente oder eines Systems unter festgelegten Bedingungen.
Eine Diskussion in einer Gruppe gleichgestellter qualifizierter Mitarbeiter, die sich darauf konzentriert, eine Übereinstimmung über technische Vorgehensweisen zu erreichen.
Eine Menge von einem oder mehreren Testfällen.
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.
Eine Anweisung von Testzielen und möglichen Testideen wie getestet werden soll. Test-Chartas werden oft im explorativen Testen verwendet.
Eine Folge von Testfällen in der Reihenfolge ihrer Durchführung, mit allen erforderlichen Aktionen zur Herstellung der Vorbedingungen und zum Aufräumen nach der Durchführung.
Ein Dokument, das eine Folge von Schritten zur Testausführung festlegt. Auch bekannt als Testskript oder Testdrehbuch.
Ein Dokument, das die Testaktivitäten und -ergebnisse zusammenfasst. Es enthält eine Bewertung der durchgeführten Tests gegen definierte Endekriterien.
Der Vorgang, die Testbasis zu analysieren und Testziele zu definieren.
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.
Eine Gruppe von Testaktivitäten, mit der Absicht, eine Komponente oder ein System auf einige zusammenhängende Qualitätsmerkmale zu prüfen. Eine Testart ist auf ein bestimmtes Testziel fokussiert, wie z.B. Zuverlässigkeitstest, Regressionstest, Gebrauchstauglichkeitstest. Die Testart kann sich auch auf eine oder mehrere Teststufen oder -phasen beziehen.
Der Prozess der Aufzeichnung von Informationen über durchgeführte Tests in einem Testprotokoll.
Der Prozess der Ausführung eines Tests für eine Komponente oder ein System, der Istergebnisse erzeugt.
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.
Einsatz von Softwarewerkzeugen zur Durchführung oder Unterstützung von Testaktivitäten, z.B. Testmanagement, Testentwurf, Testausführung und Soll/Ist-Vergleich.
Die Fähigkeit eines Softwareprodukts für einen Test nach einer Änderung.
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.
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.
Sammlung und Analyse der Daten über Testaktivitäten und ihre anschließende Konsolidierung in einem Bericht, um die Stakeholder zu informieren.
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.
(1) Siehe Testentwurfsspezifikation.
(2) Der Vorgang, allgemeine Testziele in handfeste Testbedingungen und Testfälle zu überführen.
Der Prozess der Ausführung eines Tests für eine Komponente oder ein System, der Istergebnisse erzeugt.
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.
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.
Das einzelne Element, das getestet wird. Gewöhnlich existieren ein Testobjekt und viele Testelemente.
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.
Die Menge der abgestimmten generischen und spezifischen Bedingungen, die von allen Beteiligten für den Abschluss eines Prozesses akzeptiert wurden. Endekriterien für eine Aktivität verhindern es, dass die Aktivität als abgeschlossen betrachtet wird, obwohl Teile noch nicht fertig sind. Endekriterien werden in Berichten referenziert und zur Planung der Beendigung des Testens verwendet.
(1) Siehe Testentwurfsspezifikation.
(2) Der Vorgang, allgemeine Testziele in handfeste Testbedingungen und Testfälle zu überführen.
Ein Ergebnisdokument, das die Testbedingungen für ein Testobjekt, die detaillierte Testvorgehensweise und die zugeordneten abstrakten Testfälle identifiziert.
Eine Vorgehensweise, nach der Testfälle abgeleitet oder ausgewählt werden.
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.
Eine sachkundige Fachperson, die am Testen einer Komponente oder eines Systems beteiligt ist.
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).
Eine Vorgehensweise, nach der Testfälle abgeleitet oder ausgewählt werden.
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.
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.
Ein Entwicklungsvorgehen bei dem die Entwicklung der Testfälle und oft auch ihre Automatisierung vor der Entwicklung der Software erfolgen.
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.
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.
Eine chronologische Aufzeichnung von Einzelheiten der Testausführung.
Der Zweck des Testens für eine Organisation, oft als Teil der Testrichtlinie dokumentiert.
Die Person, die in großen Projekten dem Testmanager berichtet, und für das Projektmanagement einer bestimmten Teststufe oder für eine bestimmte Menge an Testaktivitäten verantwortlich ist.
Planung, Aufwandsschätzung, Überwachung und Kontrolle von Testaktivitäten, die üblicherweise durch einen Testmanager erfolgen.
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.
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.
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.
Die Komponente oder das System, welches getestet wird.
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.
Eine Aktivität im Testprozess zur Erstellung und Fortschreibung des Testkonzepts.
Eine chronologische Aufzeichnung von Einzelheiten der Testausführung.
Der Prozess der Aufzeichnung von Informationen über durchgeführte Tests in einem Testprotokoll.
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.
Prozess der Entwicklung und Priorisierung von (konkreten) Testfällen, Erstellung von Testdaten und, optional, Vorbereitung von Testrahmen und Schreiben von automatisierten Testskripten.
Ein Dokument, das auf hohem Abstraktionsniveau die Prinzipien, den Ansatz und die wichtigsten Ziele einer Organisation in Bezug auf das Testen zusammenfasst.
Ermittelter Näherungswert zu einem Aspekt des Testens (z.B. Aufwand, Endzeitpunkt, erforderliche Kosten, Anzahl der Testfälle usw.), der auch dann brauchbar ist, wenn die zugrundeliegenden Daten unvollständig, unsicher oder gestört sind.
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.
Ein ununterbrochener Zeitraum, der mit Testdurchführung verbracht wird.
Bezeichnet üblicherweise eine Testablaufspezifikation, insbesondere eine automatisierte.
Ein Dokument, das aus der Testentwurfspezifikation, der Testfallspezifikation und/oder der Testablaufspezifikation besteht.
Eine Vorgehensweise, nach der Testfälle abgeleitet oder ausgewählt werden.
Die Managementaufgabe zur Entwicklung und Anwendung von Korrekturmaßnahmen, um in einem Testprojekt eine Abweichung vom geplanten Vorgehen zu beherrschen.
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.
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.
Ein Dokument, das eine Folge von Schritten zur Testausführung festlegt. Auch bekannt als Testskript oder Testdrehbuch.
Eine Gruppe von Testaktivitäten, mit der Absicht, eine Komponente oder ein System auf einige zusammenhängende Qualitätsmerkmale zu prüfen. Eine Testart ist auf ein bestimmtes Testziel fokussiert, wie z.B. Zuverlässigkeitstest, Regressionstest, Gebrauchstauglichkeitstest. Die Testart kann sich auch auf eine oder mehrere Teststufen oder -phasen beziehen.
Eine Umgebung, die benötigt wird, um Tests auszuführen. Sie umfasst Hardware, Instrumentierung, Simulatoren, Softwarewerkzeuge und andere unterstützende Hilfsmittel.
Ein Dokument, das eine Folge von Schritten zur Testausführung festlegt. Auch bekannt als Testskript oder Testdrehbuch.
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).
Eine Umgebung, die benötigt wird, um Tests auszuführen. Sie umfasst Hardware, Instrumentierung, Simulatoren, Softwarewerkzeuge und andere unterstützende Hilfsmittel.
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.
Ein Werkzeug, das eine oder mehrere Testaktivitäten, wie Planung und Steuerung, Spezifikation, Erstellung von Testdaten, Testdurchführung und Bewertung, unterstützt.
Ein Grund oder Zweck für den Entwurf und die Ausführung von Tests.
Eine Testprozess-Instanz für eine bestimmte Version eines Testobjekts.
Der Grad, ausgedrückt in Prozent, zu dem ein spezifiziertes Überdeckungselement (z.B. Zweig) durch eine Testsuite ausgeführt wurde.
Eine Testmanagementaufgabe, die sich auf die periodische Überwachung des Testfortschritts bezieht. In der Testabschlussberichterstattung wird die tatsächliche Situation mit dem Plan verglichen.
Ein durchgängiges Rahmenwerk für die Testprozessverbesserung, das die Schlüsselelemente eines effektiven und effizienten Testprozesses beschreibt.
Das Trennen der Verantwortungen von Analyse/Entwicklung und Test, um unvoreingenommenes Testen zu fördern.
(1) Kleinste Softwareeinheit, die für sich getestet werden kann.
(2) Kleinste Softwareeinheit, für die eine separate Spezifikation verfügbar ist.
Testen einer (einzelnen) Komponente.
Ein Black-Box-Testverfahren, bei dem die Testfälle unter Nutzung von Ursache-Wirkungs-Graphen entworfen werden.
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.
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.
Ein Black-Box-Testverfahren, bei dem die Testfälle unter Nutzung von Ursache-Wirkungs-Graphen entworfen werden.
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.
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.
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.
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.
Ein Speicherelement in einem Computer, das innerhalb eines Softwareprogramms über seinen Namen angesprochen werden kann.
Eine zweidimensionale Tabelle, die die gegenseitigen Beziehungen zweier Entitäten wie z.B. Anforderungen und Testfälle darstellt. Die Tabelle wird zur Bestimmung und Erreichung der Überdeckung verwendet, um von einer Entität zur anderen und zurück zu verfolgen, und um die Auswirkung von Änderungsvorschlägen zu bewerten.
Der Grad, zu dem eine Komponente oder ein System im operativen Betrieb bzw. für die Nutzung zur Verfügung steht.
Bestätigung durch Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind.
Bestätigung durch Bereitstellung eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind.
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.
Das Verhalten eines Systems oder einer Komponente unter festgelegten Bedingungen, das durch die Spezifikation oder durch eine andere Quelle festgelegt ist.
Eine schrittweise Präsentation eines Dokuments durch den Autor, um Informationen zu sammeln und ein gemeinsames Verständnis des Inhalts aufzubauen.
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.
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.
Testen der Änderungen an einem laufenden System oder der Auswirkungen einer geänderten Umgebung auf ein laufendes System.
Ein Test, der auf der Analyse der internen Struktur einer Komponente oder eines Systems basiert.
Der Prozess der Bestätigung, dass Komponenten, Systeme oder Personen die für sie spezifizierten Anforderungen erfüllen.
Die Durchführung von Tests, um die Sicherheit (im Sinne von Zugriffsschutz) eines Softwareprodukts zu bestimmen.
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.
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.
(1) Ein strukturierter Ansatz, Personen, Teams und Organisationen vom aktuellen Zustand in einen gewünschten zukünftigen Zustand zu bringen.
(2) Ein kontrollierter Weg, um eine (vorgeschlagene) Veränderung eines Produktes oder Dienstes umzusetzen.
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.
Der Grad, ausgedrückt in Prozent, zu dem ein spezifiziertes Überdeckungselement (z.B. Zweig) durch eine Testsuite ausgeführt wurde.