Testing-Terminologie: 100+ essenzielle QA-Begriffe und Definitionen
Schweregrad und Priorität erscheinen oft nebeneinander in einem Bug-Report, beantworten jedoch unterschiedliche Fragen. Wenn Ihre Teammitglieder solche Begriffe unterschiedlich verwenden, verzögern Missverständnisse die Arbeit. Zum Beispiel bitten Sie um einen Regressionslauf, ein Entwickler versteht "Retest", und der Fix wird nach einem bestandenen Testfall ausgeliefert. Neue Teammitglieder haben ebenfalls Schwierigkeiten, da sich ISTQB-Definitionen und die Gewohnheiten Ihres Teams unterscheiden können. Mit gemeinsamer QA-Terminologie verbinden Ihre Teammitglieder dieselbe Bedeutung mit jedem Begriff und vermeiden diese Verwechslungen. Unten finden Sie 100+ Begriffe in 12 Kategorien, jeweils mit einer kurzen Definition und einem praktischen Hinweis.
QA-Terminologie ist ein gemeinsames QA-Vokabular, das hauptsächlich auf dem ISTQB-Glossar basiert. Präzise Begriffe halten QA-Engineers und Entwickler während Fehler-Triage und Release-Entscheidungen auf einer Linie.
Der Leitfaden umfasst 100+ Begriffe in 12 Kategorien. Darunter sind Testdesign-Techniken wie Grenzwertanalyse und Automatisierungskonzepte wie instabile Tests.
Verifikation und Validierung werden oft verwechselt, ebenso wie Smoke- und Sanity-Testing. Da sich die Definitionen von Smoke und Sanity zwischen Unternehmen unterscheiden, sollten Sie früh die Bedeutung für Ihr Team festlegen.
Agile und DevOps haben Shift-Left-Testing und Continuous Testing zum Vokabular hinzugefügt. Dadurch beginnt QA-Arbeit jetzt bei der Anforderungsüberprüfung und setzt sich bis zur Produktionsüberwachung fort.
Metriken wie Defect Removal Efficiency und Code Coverage zeigen, wie effektiv Ihr Testing ist. Dennoch zeigt Ihnen der Trend über mehrere Releases, ob sich Ihr Testing verbessert.
Was ist QA-Terminologie?
QA-Terminologie ist die Gesamtheit der Standardbegriffe, die QA-Engineers verwenden, um Testaktivitäten und ihre Ergebnisse zu beschreiben. Die meisten dieser Begriffe stammen aus dem Glossar des ISTQB (International Software Testing Qualifications Board), das auch seinen Zertifizierungsprüfungen zugrunde liegt.
In der Praxis beeinflusst dieses Vokabular drei Momente in der täglichen Arbeit Ihres Teams:
Defect-Triage: Ihr Team verwendet Schweregrad- und Prioritäts-Labels, um zu entscheiden, welche Fixes in das aktuelle Release gehen.
Testplanung: Mit einer klaren Trennung zwischen Testszenarien und Testfällen wissen Ihre Teammitglieder, wie viel Detail sie vor der Ausführung schreiben müssen.
Release-Entscheidungen: Begriffe wie „Exit-Kriterien“ und „Escaped Defects“ geben Produktmanagern messbare Grundlagen für eine Go- oder No-Go-Entscheidung.
Ein ISTQB-Zertifikat ist optional für die Verwendung dieser Begriffe. Dennoch ist das vollständige ISTQB-Glossar kostenlos online verfügbar, sodass Sie jeden Begriff überprüfen können, den dieser Leitfaden nicht abdeckt.
Ein gemeinsames Glossar hilft nur, wenn Ihr gesamtes Team es auf dieselbe Weise anwendet. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Plattform, gibt Ihren Testfällen und Fehlerberichten eine gemeinsame Struktur. Anpassbare Workflows enthalten Ihre eigenen Definitionen von Schweregrad und Priorität, sodass Ihre Teammitglieder dasselbe Label auf dasselbe Problem anwenden. Zusätzlich schreibt aquas domain-trainierte KI, die durch RAG in Ihren Anforderungen und Glossaren verankert ist, Testfälle in der Sprache Ihres Projekts. Bidirektionale Jira-Synchronisation hält Defekt-Status in beiden Tools identisch, während Confluence-Links Testdokumentation mit Ihren Spezifikationen verbinden. Darüber hinaus bringen JMeter und SoapUI Performance- und API-Testergebnisse in aqua, und Capture zeichnet Testläufe mit Video und Screenshots auf.
Steigern Sie Ihre Software-Test-Effizienz um 80%, ohne die Qualität zu beeinträchtigen
Einige der häufigsten QA-Begriffe kommen in Paaren mit ähnlichen Namen, wie QA und QC. Aus diesem Grund weisen die Definitionen unten darauf hin, wo sich jedes Paar unterscheidet.
Software-Testing: Der Prozess, ein System unter kontrollierten Bedingungen auszuführen und sein tatsächliches Verhalten mit erwarteten Ergebnissen zu vergleichen.
Quality Assurance (QA): Prozessfokussierte Arbeit, die Fehler während des gesamten Entwicklungslebenszyklus verhindert. Anforderungsüberprüfungen und Coding-Standards zählen beide als QA-Arbeit.
Quality Control (QC): Produktfokussierte Arbeit, die Fehler in abgeschlossenen Arbeitsprodukten findet. Testing ist die Haupt-QC-Aktivität, und Code-Inspektionen gehören ebenfalls hierher.
Verifikation: Eine Überprüfung, ob das Produkt seine dokumentierten Anforderungen und Spezifikationen erfüllt. Die dahinterstehende Frage lautet „Haben wir das Produkt richtig gebaut?“
Validierung: Eine Überprüfung, ob das Produkt echte Benutzerbedürfnisse in seiner vorgesehenen Umgebung erfüllt. Hier lautet die Frage „Haben wir das richtige Produkt gebaut?“, sodass ein Feature die Verifikation bestehen und dennoch bei der Validierung scheitern kann.
Test-Artefakt: Jedes Arbeitsprodukt, das während des Testens erstellt wird, wie Testpläne oder Fehlerberichte.
Erwartetes Ergebnis: Das in den Anforderungen oder einer anderen Testbasis definierte Verhalten für eine gegebene Eingabe. Ein Test erhält seinen Pass- oder Fail-Status durch Vergleich mit diesem Ergebnis.
Tatsächliches Ergebnis: Das Verhalten, das das System während der Testausführung zeigt. Wenn es vom erwarteten Ergebnis abweicht, protokollieren Sie einen Fehler.
Software Testing Life Cycle Terminologie
KI-generiertes Bild.
Der Software Testing Life Cycle (STLC) ist die Abfolge von Phasen, die das Testing durchläuft, von der Planung bis zum Abschluss. Jede Phase hat ihre eigenen Outputs, wie den Testplan nach der Planung oder den Test-Summary-Report nach dem Abschluss.
Testplanung: Ihr Team definiert den Testumfang und Zeitplan. Für Releases mit mehreren Modulen umfasst dies den Workflow-Integrationstests für Software, also die Reihenfolge, in der Module kombiniert und getestet werden.
Testanalyse: QA-Engineers überprüfen Anforderungen und Akzeptanzkriterien, um testbare Bedingungen zu finden. Mehrdeutige Anforderungen werden hier geklärt, bevor sie Fehler produzieren.
Testdesign: Für jede Testbedingung schreiben QA-Engineers Testszenarien und detaillierte Testfälle mit Eingaben und erwarteten Ergebnissen. Techniken aus dem Abschnitt Funktionstest unten, wie Grenzwertanalyse, werden in dieser Phase angewendet.
Test-Umgebungs-Setup: Ihr Team bereitet die Infrastruktur und Testdaten vor, die für die Ausführung benötigt werden. Wenn Tests von bestimmten Benutzerrollen oder Datenbankzuständen abhängen, werden sie in dieser Phase konfiguriert.
Testausführung: Tester führen Testfälle aus und zeichnen tatsächliche Ergebnisse auf. Abweichungen gehen in Fehlerberichte, und jeder Test erhält einen Status wie bestanden oder blockiert.
Test-Closure: Ihr Team vergleicht Ergebnisse mit Exit-Kriterien und archiviert die Artefakte. Der Test-Summary-Report und Lessons Learned werden dann in der Planung des nächsten Zyklus verwendet.
Zwei weitere Begriffe markieren, wo jede Phase beginnt und endet:
Entry-Kriterien: Bedingungen, die erfüllt sein müssen, bevor eine Phase startet, wie ein stabiler Build und bereite Testdaten.
Exit-Kriterien: Bedingungen, die erfüllt sein müssen, bevor eine Phase endet, wie ein Pass-Rate-Ziel oder null offene High-Severity-Defekte. Sie geben Ihrem Team eine messbare Basis für eine Release-Entscheidung.
In Agile-Sprints überlappen sich die Phasen, sodass Testdesign und Ausführung oft in derselben Woche stattfinden. Selbst dann helfen Phasennamen Ihnen, Stakeholdern zu zeigen, wo das Testing steht.
Niemand verwendet dieselben Begriffe auf dieselbe Weise. Ich habe einfach aufgehört, sie zu verwenden. Ich verwende einfach allgemeinere Begriffe. Anstatt also zu sagen, ich mache einen Smoke-Test, sage ich einfach, ich mache eine schnelle High-Level-Überprüfung der Dinge. Oder so etwas.
Ein einzelner Test gehört gleichzeitig zu einem Typ und einer Methode. Sein Typ sagt, was Sie testen, wie Funktionalität oder Performance. Die Methode wiederum sagt, wie Sie testen, zum Beispiel manuell oder mit automatisierten Skripten.
Nach Fokus
Funktionstest: Tests von Features und Geschäftslogik gegen spezifizierte Anforderungen, wie Steuerberechnung in einem Warenkorb.
Nicht-funktionaler Test: Tests von Qualitätsmerkmalen wie Performance und Sicherheit.
Nach Ausführung
Manuelles Testing: Testausführung durch eine Person ohne Skripte. Manuelle Arbeit eignet sich für explorative und Usability-Überprüfungen, bei denen menschliches Urteilsvermögen am wichtigsten ist.
Automatisiertes Testing: Testausführung durch Skripte und Tools. Regressionssuiten und CI/CD-Pipelines sind ihre Haupt-Anwendungsfälle.
Nach Code-Ausführung
Statisches Testing: Reviews und Analysen von Code oder Dokumenten ohne Ausführung der Software. Code-Reviews und Linter sind typische Beispiele.
Dynamisches Testing: Testing mit laufender Anwendung und beobachtetem Verhalten. Die meisten Testausführungen, von UI-Klicks bis API-Aufrufen, fallen in diese Gruppe.
Nach Code-Sichtbarkeit
Black-Box-Testing: Testing von außen, basierend nur auf Anforderungen und ohne Kenntnis des Codes. Sie testen aus der Sicht des Benutzers.
White-Box-Testing: Tests, die aus der internen Codestruktur entworfen werden. Entwickler verwenden diese Methode, um spezifische Branches und Statements abzudecken.
Gray-Box-Testing: Eine Mischung aus beiden, mit teilweisem internem Wissen wie Datenbankschemata oder API-Dokumentation. Tester verwenden dieses Wissen, um Integrationspunkte direkt anzuvisieren.
Testing-Level-Terminologie
KI-generiertes Bild.
Jede Testing-Ebene deckt einen größeren Teil des Systems ab als die Ebene darunter, von einzelnen Funktionen bis zur vollständigen Anwendung. Entwickler besitzen oft die unteren Ebenen, während QA-Engineers und Business-User System- und Akzeptanztests durchführen.
Unit-Testing: Tests einzelner Funktionen oder Klassen isoliert, normalerweise von Entwicklern geschrieben. Mocks und Stubs ersetzen Abhängigkeiten, sodass jede Unit eigenständig läuft.
Integrationstest: Tests, wie Komponenten oder Services über ihre Schnittstellen zusammenarbeiten. Ein typischer Workflow-Integrationstest beginnt mit Unit-getesteten Modulen und kombiniert sie Schritt für Schritt.
Systemtest: Tests der vollständigen Anwendung gegen ihre Anforderungen in einer produktionsähnlichen Umgebung. Sowohl funktionale als auch nicht-funktionale Prüfungen finden auf dieser Ebene statt.
Akzeptanztest: Testing, bei dem Business-Stakeholder bestätigen, dass das System ihre Bedürfnisse vor dem Release erfüllt. Beim User Acceptance Testing (UAT) führen echte User die Tests durch, oft in einem dedizierten UAT-Tool.
Alpha-Testing: Akzeptanztest durch internes Personal am Standort des Entwicklers, bevor ein externer User das Produkt sieht.
Beta-Testing: Akzeptanztest durch eine begrenzte Gruppe externer User in deren eigenen Umgebungen. Feedback von Beta-Usern zeigt, wie sich das Produkt auf echten Geräten und Daten verhält.
Smoke-Testing: Ein kurzer Testlauf, der die Hauptfunktionen eines neuen Builds abdeckt. Wenn der Smoke-Test fehlschlägt, geht der Build normalerweise zurück zu den Entwicklern, bevor tiefere Tests beginnen.
Sanity-Testing: Eine enge Überprüfung eines Bug-Fixes oder einer kleinen Änderung und der Funktionen drumherum. Im Vergleich zu einem vollständigen Regressionslauf ist Sanity-Testing weniger formal und enger im Umfang.
Regressionstest: Wiederholte Ausführung zuvor bestandener Tests nach einer Codeänderung, um neu defekte Features zu finden. Regressionssuiten wachsen mit jedem Release, was sie zu starken Automatisierungskandidaten macht.
Definitionen von Smoke- und Sanity-Testing unterscheiden sich zwischen Unternehmen. Einige verwenden „Smoke“ für Build-Checks und „Sanity“ für Post-Fix-Checks, während andere die Bedeutungen vertauschen, also schreiben Sie die Definitionen Ihres Teams in die Teststrategie.
Funktionstest-Terminologie
Zum Entwerfen von Funktionstests verlassen sich QA-Engineers auf Testdesign-Techniken. Der ISTQB Foundation Level Syllabus v4.0 nennt vier Black-Box-Techniken, und alle erscheinen unten, zusammen mit Error Guessing aus seiner erfahrungsbasierten Gruppe.
Positives Testing: Tests mit gültigen Eingaben und erwarteten User-Flows, wie eine Formularübermittlung mit korrekten Daten.
Negatives Testing: Überprüfungen mit ungültigen Eingaben oder unerwarteten Aktionen, wie eine negative Bestellmenge. Sie bestätigen, dass das System die Eingabe mit einer klaren Fehlermeldung ablehnt.
Grenzwertanalyse (BVA): Testdesign um die Ränder gültiger Eingabebereiche. Sie testen die minimalen und maximalen gültigen Werte plus die nächstliegenden ungültigen Werte, da Off-by-One-Fehler sich an den Grenzen häufen.
Äquivalenzklassenbildung: Aufteilung von Eingaben in Gruppen, die das System gleich behandeln sollte, mit einem Testwert pro Gruppe. Diese Technik reduziert die Anzahl der Testfälle und deckt trotzdem jede Eingabeklasse ab.
Entscheidungstabellen-Testing: Testdesign basierend auf Kombinationen von Bedingungen und resultierenden Aktionen. Geschäftsregeln mit mehreren Eingaben, wie Versandkosten basierend auf Gewicht und Ziel, sind der typische Anwendungsfall.
Zustandsübergangs-Testing: Tests, wie ein System nach Ereignissen zwischen definierten Zuständen wechselt. Bestellstatus wie „ausstehend“ und „versandt“ sind ein typisches Objekt, da jeder Status unterschiedliche Aktionen erlaubt.
Use-Case-Testing: Testszenarien, die aus Use Cases oder User Stories abgeleitet werden. Diese Tests folgen einem vollständigen User-Ziel, wie einem Checkout vom Warenkorb bis zur Zahlung.
Error Guessing: Testdesign basierend auf der Erfahrung des Testers mit typischen Fehlern. Erfahrene Tester zielen auf bekannte Schwachstellen ab, wie leere Felder und Datumsformate.
Nicht-funktionale Testing-Terminologie
Nicht-funktionale Tests messen Qualitätsmerkmale wie Antwortzeit und Sicherheit. Der ISO/IEC 25010-Standard definiert diese Merkmale in seinem Produktqualitätsmodell, und die meisten Begriffe unten ordnen sich einem davon zu.
Performance-Testing: Tests von Antwortzeit und Stabilität unter Last. Drei Subtypen sind üblich:
Load-Testing: Läuft unter der erwarteten Spitzenzahl von Usern. Tools wie Apache JMeter simulieren Tausende gleichzeitiger User für diese Läufe.
Stress-Testing: Testing über normale Kapazität hinaus, um den Bruchpunkt zu finden und zu sehen, wie sich das System erholt.
Skalierbarkeits-Testing: Messung, wie sich der Durchsatz ändert, wenn Ihr Team Server oder andere Ressourcen hinzufügt.
Security-Testing: Überprüfungen von Zugriffskontrolle und Datenschutz gegen Angriffe wie SQL-Injection. Die OWASP Top 10 listet die kritischsten Webanwendungs-Sicherheitsrisiken und gibt Ihrem Team einen ersten Satz von Testbereichen.
Usability-Testing: Beobachtung echter User, während sie Aufgaben im Interface erledigen. Ihr Team notiert, wo User zögern oder Fehler machen.
Kompatibilitäts-Testing: Tests über Browser und Geräte hinweg, wie Chrome und Safari auf Desktop und Mobile.
Zuverlässigkeits-Testing: Lange Testläufe, die messen, wie konsistent das System über die Zeit funktioniert. Memory Leaks und intermittierende Fehler erscheinen oft erst nach Stunden Betrieb.
Accessibility-Testing: Bewertung, ob Menschen mit Behinderungen das Produkt nutzen können, normalerweise gemessen an den WCAG-Richtlinien. In der EU machte der European Accessibility Act Accessibility für viele digitale Services im Juni 2025 obligatorisch.
Test-Dokumentations-Begriffe
Ihr Team schreibt die ersten Dokumente unten, bevor das Testing startet, wie den Testplan und die Teststrategie. Die letzten, wie der Test-Summary-Report, kommen nach der Ausführung und zeichnen die Ergebnisse auf.
Testplan: Ein Projekt- oder Release-Dokument mit dem Umfang und Zeitplan des Testens. Risikobewertung und Ressourcenplanung sind ebenfalls Teil davon.
Teststrategie: Ein High-Level-Dokument mit Testing-Prinzipien und Standards über mehrere Projekte hinweg. Für Systeme mit vielen Schnittstellen kann es ein Workflow-Diagramm für Integrationstests mit der Reihenfolge der Modulintegration enthalten.
Testszenario: Eine einzeilige Beschreibung, was zu testen ist, wie „Passwort-Reset für registrierte User verifizieren.“ Da Szenarien keine Schritte auflisten, funktionieren sie gut für frühe Planung und explorative Sessions.
Testfall: Eine Spezifikation mit nummerierten Schritten und erwarteten Ergebnissen für eine Testbedingung.
Test-Suite: Eine Gruppe verwandter Testfälle, die zusammen ausgeführt werden, wie eine Smoke-Suite oder eine nächtliche Regressionssuite.
Testdaten: Die Eingaben und Datensätze, die Tests benötigen, wie Benutzerkonten und Datenbankeinträge. Getrennt von Testfällen gespeichert, können Testdaten sich ändern, ohne dass Testschritte neu geschrieben werden.
Testskript: Ein automatisierter Test in Code geschrieben, oft mit Selenium oder Playwright. Jedes Skript wiederholt die Schritte eines manuellen Testfalls in ausführbarer Form.
Traceability-Matrix: Ein Mapping von Anforderungen zu Testfällen und Fehlern. Damit können Sie sehen, welche Anforderungen noch keine Tests haben. Moderne Requirements-Management-Software kann diese Matrix aus Links zwischen Anforderungen und Tests erstellen.
Test-Summary-Report: Ein Abschlussdokument mit Ausführungsergebnissen und Fehlerstatistiken. Stakeholder nutzen es, um Release-Bereitschaft und offene Risiken zu beurteilen.
In der Praxis führt eine Anforderung zu einem Testszenario, das dann einen oder mehrere Testfälle erhält. Wenn das tatsächliche Ergebnis vom erwarteten abweicht, protokollieren Sie einen Fehler und verlinken ihn mit diesem Testfall. Mit gutem Test-Case-Management bleibt diese Kette verbunden, sodass eine Anforderungsänderung Ihnen zeigt, welche Testfälle ein Update benötigen.
Fehler- und Bug-Tracking-Terminologie
Ein Entwickler, der einen Fehlerbericht aufnimmt, muss wissen, was schiefgelaufen ist und wie bald zu fixen ist. Die ersten beiden Gruppen unten folgen dieser Reihenfolge, und die dritte deckt ab, wie Fehler geschlossen werden.
Woher Fehler kommen
Error: Ein menschlicher Fehler, wie eine falsch gelesene Anforderung, der einen Defekt einführt.
Defekt (Bug): Ein Fehler in Code oder Dokumentation, der falsches Verhalten verursachen kann. Viele Unternehmen verwenden „Defekt“ im formalen Tracking und „Bug“ im Gespräch, mit derselben Bedeutung.
Failure: Das sichtbare Ergebnis eines Defekts zur Laufzeit, wie ein Checkout-Button, der nicht reagiert. User melden Failures, und Ihr Team sucht dann nach dem Defekt dahinter.
Root Cause: Der zugrunde liegende Grund, warum ein Defekt auftrat, wie ein fehlender Review-Schritt. Ein Fix auf Root-Cause-Ebene kann ähnliche Defekte in späteren Releases verhindern.
Wie dringend sie sind
Schweregrad: Die technische Auswirkung eines Defekts, von kritisch, wie Datenverlust, bis gering, wie ein Tippfehler. QA-Engineers setzen normalerweise den Schweregrad, wenn sie den Defekt protokollieren.
Priorität: Die geschäftliche Dringlichkeit eines Fixes, normalerweise von Product Ownern basierend auf Release-Plänen und User-Impact gesetzt. Deshalb kann ein kosmetischer Defekt auf der Homepage hohe Priorität bei niedrigem Schweregrad erhalten.
Defekt-Triage: Ein regelmäßiges Meeting, bei dem Ihr Team neue Defekte überprüft und jedem Priorität und einen Owner zuweist.
Wie sie geschlossen werden
Defekt-Life-Cycle: Die Status, die ein Defekt durchläuft, typischerweise von Neu bis Geschlossen, mit Schritten wie Zugewiesen und Gefixt dazwischen. Ihr Team kann Status wie Wiedereröffnet hinzufügen, um seinen Workflow anzupassen.
Retesting (Bestätigungstest): Wiederholte Ausführung des fehlgeschlagenen Tests nach einem Fix, um zu bestätigen, dass der Defekt behoben ist. Nach erfolgreichem Retest führt Ihr Team normalerweise die Regressionssuite um den geänderten Code herum aus.
Regressions-Defekt: Ein Defekt in einem Feature, das vor einer kürzlichen Änderung funktionierte.
Test-Automatisierungs-Terminologie
Automatisierte Tests werden in einem Framework geschrieben und dann in einer CI/CD-Pipeline nach jedem Commit ausgeführt. Die drei Gruppen unten folgen dieser Reihenfolge, mit Teststabilität als letzter Gruppe.
Frameworks und Skript-Design
Test-Automatisierungs-Framework: Die Libraries und Konventionen hinter Ihren automatisierten Tests. Selenium und Playwright sind gängige Wahl für Browser-Tests, und viele QA-Engineers verwenden REST Assured oder Postman für API-Tests.
Assertion: Eine Aussage in einem Testskript, die einen tatsächlichen Wert mit dem erwarteten vergleicht. Ohne Assertions führt ein Skript Schritte aus, beweist aber nichts.
Page Object Model (POM): Ein Designmuster, das Page-Locators und Aktionen in separaten Klassen hält. Wenn sich die UI ändert, aktualisieren Sie eine Klasse, und der Testcode bleibt gleich.
Data-Driven Testing: Ein Testskript, das mit vielen Eingabesets aus einer Datei oder Datenbank ausgeführt wird. Ihr Team fügt neue Cases hinzu, indem es Datenzeilen hinzufügt, ohne neuen Code.
Mocking und Stubbing: Ersatz echter Abhängigkeiten durch kontrollierte Substitute. Stubs geben feste Antworten zurück, während Mocks auch verifizieren, wie der Code unter Test sie aufgerufen hat.
CI/CD-Pipelines
Continuous Integration (CI): Die Praxis, Code automatisch nach jedem Commit zu bauen und zu testen. Jenkins und GitHub Actions sind weit verbreitete CI-Server.
Continuous Testing: Automatisierte Tests in jeder Phase der Delivery-Pipeline, vom Commit bis zum Deployment.
Headless-Testing: Browser-Tests ohne sichtbares User-Interface. Headless-Läufe sind schneller und passen zu CI-Servern, die kein Display haben.
Teststabilität
Flaky Test: Ein automatisierter Test, der beim selben Code besteht und fehlschlägt. Timing-Probleme und instabile Testdaten sind die üblichen Ursachen, und Playwright Trace Viewer hilft Ihnen, sie durch Screenshots und Network-Logs zu verfolgen.
Test-Data-Management: Erstellung und Bereinigung isolierter Daten für automatisierte Tests.
Ja, das Ding bei Software-QA ist, dass es keine konkrete standardisierte Terminologie gibt. Ich glaube, ISTQB ist eine Lösung, aber nicht jeder kann diesen Syllabus nehmen oder ihm sogar zustimmen.
Integrationstests zielen auf die Schnittstellen zwischen Komponenten, und in Webanwendungen sind diese Schnittstellen normalerweise HTTP-APIs. Deshalb erscheinen API-Begriffe und Integrationsbegriffe zusammen in diesem Abschnitt.
API (Application Programming Interface): Ein Vertrag, der definiert, wie Software-Komponenten Daten austauschen, normalerweise durch HTTP-Endpoints. REST-APIs verwenden typischerweise JSON-Payloads, und GraphQL-APIs verwenden Queries und Mutations.
API-Testing: Tests von API-Antworten und Fehlerbehandlung, einschließlich Zugriffsregeln. Weil API-Tests schneller laufen als UI-Tests, erhalten Entwickler früher Feedback.
System-Integrationstest (SIT): Tests der Interaktion zwischen vollständigen Systemen, wie einem CRM und einer Abrechnungsplattform. Ein Workflow für System-Integrationstests beginnt normalerweise mit Interface-Checks zwischen Systempaaren und endet mit vollständigen Geschäftstransaktionen.
Endpoint: Eine spezifische URL, die eine API-Operation bereitstellt, wie POST /orders, um eine Bestellung zu erstellen. Die Endpoint-Liste in Ihrer API-Dokumentation ist eine gute Basis für API-Test-Coverage.
Request Payload: Die an eine API gesendeten Daten, normalerweise in JSON oder XML. Payload-Tests umfassen fehlende Felder und falsche Datentypen.
Response Payload: Die Daten, die eine API zurückgibt, zusammen mit Statuscode und Headers. Sie vergleichen deren Inhalt mit den erwarteten Werten und dem Schema.
Statuscode: Ein HTTP-Code, der das Ergebnis einer Anfrage zeigt, wie 200 für Erfolg oder 401 für fehlende Autorisierung. Ein falscher Statuscode kann die Client-Fehlerbehandlung brechen, selbst wenn die Daten korrekt aussehen.
Schema-Validierung: Eine Überprüfung, dass Antworten der vereinbarten Struktur für Feldnamen und Datentypen folgen.
Contract Testing: Verifikation, dass ein API-Consumer und Provider sich auf Request- und Response-Formate einigen. Tools wie Pact lassen Sie diese Tests ohne vollständige End-to-End-Umgebung ausführen.
Workflow-Integrationstests: Tests eines vollständigen Geschäftsprozesses über mehrere Services hinweg, wie eine Bestellung, die Zahlung und Lageraktualisierungen auslöst. Ihr Team überprüft, ob Daten bei jeder Übergabe konsistent bleiben.
Wenn mehrere Services an einem Geschäftsprozess teilnehmen, zeichnen Sie ein Workflow-Diagramm für Software-Integrationstests, bevor Ihr Team die Tests schreibt. Mit allen Schnittstellen und ihrer Reihenfolge auf einer Seite können Sie mit den risikoreichsten Übergaben beginnen, wie Zahlung und Authentifizierung.
Agile- und DevOps-Testing-Terminologie
In Scrum dauert ein Sprint einen Monat oder weniger, sodass Testing im selben kurzen Zyklus wie Entwicklung stattfindet. DevOps fügt dann Deployment und Produktionsüberwachung zu diesem Zyklus hinzu, und mehrere Begriffe unten kommen daher.
Sprint-Testing: Testing neuer Stories und Fixes innerhalb desselben Sprints. Tester entwerfen oft Tests, während Entwickler noch den Code schreiben.
Shift-Left-Testing: Frühere Einbindung von Testing im Lifecycle, wie Anforderungsüberprüfungen und Unit-Tests während des Codings.
Shift-Right-Testing: Testing in Produktion durch Monitoring und echtes User-Feedback. Feature Flags und synthetisches Monitoring halten das Risiko dieser Tests niedrig.
Test-Driven Development (TDD): Eine Praxis, bei der Entwickler einen fehlschlagenden Unit-Test vor dem Produktionscode schreiben. Danach schreiben sie Code, bis der Test besteht, und refactoren ihn.
Behavior-Driven Development (BDD): Anforderungen geschrieben als Given-When-Then-Szenarien in einfacher Sprache. Tools wie Cucumber oder SpecFlow führen diese Szenarien als automatisierte Tests aus, sodass Business-Stakeholder die Test-Suite lesen können.
Definition of Done (DoD): Die Checkliste, die eine User Story bestehen muss, bevor Ihr Team sie als vollständig bezeichnet. Typische Punkte sind Code-Review und bestandene automatisierte Tests.
Akzeptanzkriterien: Testbare Bedingungen, die eine Story erfüllen muss, wie „User erhält eine Bestätigungsmail innerhalb von 2 Minuten nach der Bestellung.“ Klare Kriterien geben Testern die erwarteten Ergebnisse für ihre Testfälle.
Exploratives Testing: Testdesign und Ausführung gleichzeitig, ohne vordefiniertes Skript. Erfahrene Tester verwenden es, um Edge Cases zu finden, die geskriptete Tests nicht abdecken.
Continuous Deployment (CD): Automatisches Release in Produktion von Code-Änderungen, die alle Pipeline-Tests bestehen. Für CD benötigt Ihr Team eine zuverlässige automatisierte Suite und ein schnelles Rollback, da ein Defekt bald nach dem Commit User erreichen kann.
Feature Flag (Feature Toggle): Ein Runtime-Schalter, der ein Feature ohne neues Deployment ein- oder ausschaltet. Feature Flags unterstützen schrittweise Rollouts und schnelles Rollback, wenn ein Problem auftritt.
Test-Metriken und QA-Terminologie
Metriken geben Ihren Stakeholdern Zahlen für Release-Entscheidungen. Da ein einzelner Wert allein wenig aussagt, vergleichen Sie jede Metrik über mehrere Releases hinweg.
Coverage-Metriken
Test Coverage: Der Anteil der Anforderungen oder Funktionen, die durch Tests ausgeführt werden. Niedrige Coverage signalisiert Risiko, während hohe Coverage noch kein fehlerfreies Produkt garantiert.
Code Coverage: Der Prozentsatz des durch automatisierte Tests ausgeführten Codes. Statement Coverage zählt ausgeführte Zeilen, und Branch Coverage zählt genommene Entscheidungspfade.
Test-Automatisierungs-Coverage: Der Anteil der Testfälle, die automatisch laufen. Diese Zahl zeigt, wie viel Ihres Regressionstests ohne manuellen Aufwand laufen kann.
Defekt-Metriken
Defekt-Density: Die Anzahl der Defekte pro Größeneinheit, oft pro tausend Zeilen Code.
Defect Removal Efficiency (DRE): Der Anteil der vor dem Release gefundenen Defekte. Sie berechnen ihn als im Testing gefundene Defekte dividiert durch die Summe aus Testing- und Produktions-Defekten.
Escaped Defects: Defekte, die nach dem Release in Produktion gefunden werden.
Geschwindigkeits- und Fortschritts-Metriken
Test-Ausführungs-Rate: Die Anzahl der pro Tag oder Sprint ausgeführten Testfälle. Mit dieser Rate können Sie schätzen, wie lange der verbleibende Testzyklus dauern wird.
Pass/Fail-Rate: Der Anteil bestandener Tests unter allen ausgeführten Tests. Eine fallende Pass-Rate über Builds hinweg signalisiert wachsende Instabilität.
Mean Time to Detect (MTTD): Die durchschnittliche Zeit zwischen der Einführung eines Defekts und seiner Entdeckung.
Mean Time to Repair (MTTR): Die durchschnittliche Zeit zwischen Defekt-Entdeckung und einem funktionierenden Fix.
Ein Ziel von 100% Code Coverage kann zu oberflächlichen Tests führen, die für die Zahl geschrieben wurden, also verwenden Sie diese Metriken, um Testing-Prioritäten zu setzen. Test-Management-Plattformen wie aqua cloud zeigen sie auf Dashboards, wo Sie Werte über Releases hinweg vergleichen können.
Klare Begriffe helfen am meisten, wenn die Artefakte dahinter an einem Ort bleiben. aqua cloud, eine KI-gesteuerte Test- und Anforderungsmanagement-Lösung, hält Testpläne und Testfälle zusammen, mit Traceability von Anforderungen bis Defekten. Dadurch sieht Ihr Team, zu welcher Anforderung ein Regressions-Defekt gehört, ohne Suche über Tools hinweg. aquas KI, durch RAG in Ihrer Projektdokumentation verankert, generiert Testfälle mit Ihren etablierten Begriffen in Sekunden. Für Ihre Pipelines verbinden Jenkins und Azure DevOps aqua mit Builds und Work Items. aqua bietet auch 12+ native Automatisierungs-Integrationen, wie Ranorex und UnixShell. Die REST-API und MSSQL- oder Oracle-Datenbank-Unterstützung verbinden dann den Rest Ihrer Toolchain. Capture-Integration wird ebenfalls unterstützt.
Zentralisieren Sie Ihr QA-Vokabular und sparen Sie bis zu 97% Ihrer Test-Dokumentationszeit
QA-Terminologie ist am wichtigsten, wo Ihr Team Entscheidungen trifft, wie Defekt-Triage und Release-Reviews. Beginnen Sie mit den Paaren, die in Ihrem Team Verwirrung stiften, wie Smoke- versus Sanity-Testing oder Retesting versus Regressionstest. Danach schreiben Sie die vereinbarten Definitionen in Ihre Teststrategie, damit neue Teammitglieder sie an einem Ort nachschlagen können.
Was sind die häufigsten Begriffe im Software-Testing?
Die meistverwendete QA-Terminologie deckt Testdesign und Defekt-Tracking ab. In der täglichen QA-Arbeit hören Sie Begriffe wie Testfall und Regressionstest am häufigsten, während Defekt-Triage Schweregrad und Priorität hinzufügt.
Was ist der Unterschied zwischen QA und QC im Software-Testing?
In der QA-Terminologie ist QA prozessfokussiert und verhindert Defekte durch Standards und Reviews. QC ist produktfokussiert und findet Defekte in fertiger Arbeit, hauptsächlich durch Testing und Inspektionen.
Was ist der Unterschied zwischen einem Testfall und einem Testszenario?
Ein Testszenario beschreibt in einer Zeile, was zu testen ist, wie Passwort-Reset für registrierte User. Im Gegensatz dazu fügt ein Testfall die genauen Schritte und erwarteten Ergebnisse hinzu, die zur Ausführung dieser Überprüfung benötigt werden.
Was ist der Unterschied zwischen Schweregrad und Priorität im Testing?
Schweregrad beschreibt die technische Auswirkung eines Defekts, und QA-Engineers setzen ihn normalerweise. Priorität beschreibt, wie dringend das Business einen Fix braucht, sodass ein Low-Severity-Tippfehler auf einer Checkout-Seite dennoch hohe Priorität erhalten kann.
Was ist der Unterschied zwischen Retesting und Regressionstest?
Beim Retesting führen Sie den fehlgeschlagenen Test nach einem Fix erneut aus, um zu bestätigen, dass ein Defekt behoben ist. Mit Regressionstest führt Ihr Team einen breiteren Satz bestandener Tests erneut aus, um Seiteneffekte der Änderung zu finden.
Die Verbesserung des aqua-Produkts ist Martins Hauptaufgabe und größte Mission. Sein Fachwissen umfasst ITIL-Prozessberatung, Änderungsmanagement, Qualitätssicherung, Qualitätsmanagement und Anforderungsmanagement. Martin arbeitet seit mehr als 18 Jahren in der Qualitätssicherung für regulierte Branchen und ist eine unersetzliche Führungskraft bei der andagon Group.
Nurlan, ein QA-Koordinator, ist stolz darauf, nahtlose QA-Operationen zu orchestrieren. Seine Expertise in der Koordination von QA-zentrierten Projekten und der Integration von QA-Lösungen hat konsequent höchste Kundenzufriedenheit erzielt. Neben seiner Vollzeittätigkeit als QA-Koordinator beinhaltet Nurlans Rolle das Erstellen von überzeugenden Inhalten, die Nutzer über die…
Pavel ist Quality-Assurance-Berater und Autor mit tiefem Fachwissen in der Lösung komplexer Testherausforderungen. Sein Hintergrund in der Softwareentwicklung hat Organisationen dabei geholfen, ihre QA-Praktiken von reaktiv zu proaktiv zu entwickeln. Neben der Beratung entwickelt Pavel Best-Practice-Leitfäden und Fallstudien für aqua cloud, die praxisnahe QA-Lösungen demonstrieren…
Beginnen Sie Ihre Arbeit nicht mit gewöhnlichen E-Mails: Fügen Sie eine gesunde Dosis an aufschlussreichen Softwaretest-Tipps von unseren QS-Experten hinzu.
Home » Testautomatisierung » Testing-Terminologie: 100+ essenzielle QA-Begriffe und Definitionen
Lieben Sie das Testen genauso wie wir?
Werden Sie Teil unserer Community von begeisterten Experten! Erhalten Sie neue Beiträge aus dem aqua-Blog direkt in Ihre Inbox. QS-Trends, Übersichten über Diskussionen in der Community, aufschlussreiche Tipps — Sie werden es lieben!
Wir sind dem Schutz Ihrer Privatsphäre verpflichtet. Aqua verwendet die von Ihnen zur Verfügung gestellten Informationen, um Sie über unsere relevanten Inhalte, Produkte und Dienstleistungen zu informieren. Diese Mitteilungen können Sie jederzeit wieder abbestellen. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie.
X
🤖 Neue spannende Updates sind jetzt für die aqua-Intelligenz verfügbar! 🎉
