ISTQB Foundation (CTFL v4.0) Probeprüfung #15 — Fragen & Antworten
Alle Fragen dieser Probeprüfung, mit markierter richtiger Antwort und einer schriftlichen Begründung zu jeder Option unten — zum Lesen und Wiederholen, kein zeitlich begrenzter Durchlauf.
Welches der folgenden ist ein typisches Testziel?
Arbeitsergebnisse bewerten und Fehlerzustände finden
Fehlerzustände zu finden und Qualität zu bewerten ist ein Kernziel des Testens.
Beweisen, dass die Software keine Fehlerzustände enthält
Ein vollständiger Beweis der Fehlerfreiheit ist unmöglich; Testen kann nur das Vorhandensein von Fehlerzuständen zeigen.
Die bei der Ausführung gefundenen Fehlerzustände beheben
Fehler zu beheben ist Debugging, eine Entwicklungstätigkeit, kein Testziel.
Garantieren, dass das System für jede mögliche Nutzung geeignet ist
Testen senkt das Risiko, kann aber keine Eignung für alle Nutzungen garantieren.
Testen verfolgt mehrere Ziele, u. a. Fehlerzustände zu finden, Vertrauen in das Qualitätsniveau aufzubauen und Informationen für Entscheidungen zu liefern. Die Abwesenheit von Fehlerzuständen kann nicht bewiesen werden.
Ein Team führt monatelang dieselbe automatisierte Regressionssuite unverändert aus und findet fast keine neuen Fehlerzustände. Welches Testprinzip erklärt dies am besten?
Das Pestizid-Paradoxon
Wiederholte identische Tests verlieren mit der Zeit die Fähigkeit, neue Fehlerzustände zu finden.
Testen zeigt das Vorhandensein, nicht die Abwesenheit von Fehlerzuständen
Als Prinzip korrekt, erklärt aber nicht, warum Wiederholung keine Fehler mehr findet.
Fehlerzustände treten gehäuft auf
Fehlerhäufung betrifft die Verteilung von Fehlern, nicht die Wirkung wiederholter Tests.
Frühes Testen spart Zeit und Geld
Dieses Prinzip betrifft den Testzeitpunkt, nicht den Wirkungsverlust wiederholter Tests.
Das Pestizid-Paradoxon besagt, dass wiederholte gleiche Tests keine neuen Fehlerzustände mehr finden; Tests müssen überprüft und angepasst werden.
Ein Entwickler vertippt sich bei einer Formel in einer Tabelle. Die falsche Formel bleibt im Code, und bei der Berichtserstellung wird eine falsche Summe angezeigt. Ordnen Sie Fehlhandlung, Fehlerzustand und Fehlerwirkung.
Vertippen = Fehlhandlung; falsche Formel im Code = Fehlerzustand; falsche Summe = Fehlerwirkung
Dies ist die korrekte Ursachenkette: Fehlhandlung → Fehlerzustand → Fehlerwirkung.
Vertippen = Fehlerzustand; falsche Formel = Fehlerwirkung; falsche Summe = Fehlhandlung
Die Reihenfolge ist falsch; die menschliche Handlung ist eine Fehlhandlung, kein Fehlerzustand.
Vertippen = Fehlerwirkung; falsche Formel = Fehlhandlung; falsche Summe = Fehlerzustand
Falsch; die beobachtbare falsche Ausgabe ist die Fehlerwirkung, nicht die Fehlhandlung.
Alle drei sind dasselbe, nur anders beschrieben
Fehlhandlung, Fehlerzustand und Fehlerwirkung sind verschiedene Konzepte mit Ursachenbeziehung.
Eine menschliche Fehlhandlung führt zu einem Fehlerzustand im Code, der bei Ausführung eine Fehlerwirkung (beobachtbares Fehlverhalten) erzeugt.
Welche Aussage über den Unterschied zwischen Testen und Debugging ist korrekt?
Testen kann Fehlerwirkungen auslösen; Debugging findet und behebt die zugrunde liegenden Fehlerzustände
Dies trennt die beiden Tätigkeiten korrekt.
Testen und Debugging sind zwei Namen für dieselbe Tätigkeit
Es sind verschiedene Tätigkeiten mit unterschiedlichen Zielen.
Debugging geht immer dem Testen voraus
Testen deckt in der Regel zuerst Fehlerwirkungen auf; Debugging folgt zur Behebung.
Nur Tester debuggen, niemals Entwickler
Debugging wird üblicherweise von Entwicklern durchgeführt, nicht von Testern.
Testen kann Fehlerwirkungen auslösen, die durch Fehlerzustände verursacht werden; Debugging ist die Entwicklungstätigkeit, diese Fehlerzustände zu finden, zu analysieren und zu beheben.
Bei einem Review der Anforderungen prüft das Team gemäß Spezifikation: „Bauen wir das Produkt richtig?“. Welche Tätigkeit ist das?
Verifizierung
Die Prüfung der Konformität mit der Spezifikation ist Verifizierung.
Validierung
Validierung fragt, ob das richtige Produkt für reale Bedürfnisse gebaut wird, nicht nach Spezifikationstreue.
Debugging
Debugging ist das Beheben von Fehlerzuständen, ohne Bezug zu dieser Prüfung.
Fehlernachtest
Der Fehlernachtest bestätigt eine Korrektur; es geht nicht um Spezifikationstreue.
Verifizierung prüft, ob ein Arbeitsergebnis seine Spezifikation erfüllt; Validierung prüft, ob es die tatsächlichen Bedürfnisse der Nutzer erfüllt.
Warum ist die Ursachenanalyse von Fehlerzuständen wertvoll?
Sie unterstützt Prozessverbesserungen, um ähnliche Fehlerzustände zu vermeiden
Das Erkennen der Quelle ermöglicht Präventivmaßnahmen und reduziert künftige Fehler.
Sie garantiert, dass der aktuelle Fehler nie wieder auftritt
Die Analyse senkt das Wiederholungsrisiko, kann es aber nicht garantieren.
Sie ersetzt die Notwendigkeit der Testdurchführung
Ursachenanalyse ergänzt die Testdurchführung, ersetzt sie nicht.
Sie weist dem verantwortlichen Entwickler die Schuld zu
Ziel ist Verbesserung, nicht Schuldzuweisung.
Die Analyse der zugrunde liegenden Ursache unterstützt Prozessverbesserungen, um ähnliche Fehlerzustände künftig zu vermeiden.
Welche ZWEI sind Beispiele für Denkweise und Fähigkeiten, die ein guter Tester haben sollte?
Neugier und Sorgfalt
Diese helfen Testern, Anomalien zu bemerken und gründliche Tests zu entwerfen.
Gute Kommunikation und kritisches Denken
Tester müssen Befunde klar berichten und Annahmen hinterfragen.
Befugnis, Projektbudgets zu genehmigen
Budgetgenehmigung ist eine Managementaufgabe, keine Testfähigkeit.
Stets den zu testenden Produktionscode schreiben
Produktionscode zu schreiben ist eine Entwicklungsaufgabe, keine Testfähigkeit.
Tester profitieren von Neugier, Sorgfalt, guter Kommunikation und kritischem Denken. Produktionscode schreiben und Budgets genehmigen sind keine Testfähigkeiten.
Der ISTQB-Testprozess wird als Menge von Aktivitäten beschrieben, doch in der Praxis werden diese nicht streng nacheinander durchgeführt. Welche ZWEI Aussagen beschreiben ihr Verhältnis in der Praxis korrekt? (Wählen Sie zwei.)
Aktivitäten können sich überlappen, parallel laufen oder wiederholt werden — etwa der Testentwurf für spätere Funktionen, während frühere Tests bereits durchgeführt werden.
Richtig — der Prozess ist nicht streng sequenziell; Iteration und Überlappung sind normal, besonders in iterativ-inkrementellen Lebenszyklen.
Die Testüberwachung und -steuerung begleitet die anderen Aktivitäten kontinuierlich, statt einen festen Platz zwischen zwei von ihnen einzunehmen.
Richtig — Überwachung und Steuerung laufen während des gesamten Testaufwands, liefern Rückmeldung und passen die anderen Aktivitäten bei Bedarf an.
Die Testplanung wird einmal am Projektbeginn durchgeführt und danach nie mehr angepasst.
Pläne werden aktualisiert, wenn Überwachung und Steuerung Abweichungen zeigen oder sich Risiken und Prioritäten ändern; die Planung wird im Projektverlauf wieder aufgegriffen.
Die Testanalyse muss für das gesamte System vollständig abgeschlossen sein, bevor der Testentwurf beginnen darf.
Das beschreibt eine starre Reihenfolge, die der Lehrplan nicht fordert. Analyse und Entwurf laufen üblicherweise Funktion für Funktion; der Entwurf beginnt, sobald die betreffenden Testbedingungen vorliegen.
Die Testaktivitäten können sich überlappen, parallel laufen und iterativ wiederholt werden; die Testüberwachung und -steuerung ist eine kontinuierliche Aktivität, die den gesamten Testaufwand begleitet, statt einen einzelnen Platz in einer Reihenfolge einzunehmen.
Wann sollte in einem sequenziellen (V-Modell-)Lebenszyklus die Testanalyse und -entwurf für die Systemteststufe idealerweise beginnen?
Sobald die Systemanforderungen vorliegen
Der Testentwurf kann anhand der Anforderungen parallel zur Entwicklung beginnen.
Erst nachdem der gesamte Code geschrieben wurde
Bis zur Codefertigstellung zu warten widerspricht dem Prinzip des frühen Testens.
Erst nachdem der Komponententest vollständig bestanden ist
Der Systemtestentwurf muss nicht auf den Abschluss des Komponententests warten.
Während der Wartungsphase
Das ist viel zu spät; der Entwurf sollte zur Anforderungsphase passen.
Im V-Modell beginnen die Testaktivitäten jeder Stufe, sobald die zugehörige Basis (z. B. Systemanforderungen) vorliegt, parallel zur Entwicklung — eine Anwendung des frühen Testens.
Ein Team führt statische Analyse und Unit-Tests während der Codierung ein und reviewt Anforderungen vor Entwicklungsbeginn. Welchen Ansatz wenden sie an?
Ein Shift-Left-Ansatz
Testaktivitäten nach vorne zu verlagern ist genau die Shift-Left-Idee.
Ein Shift-Right-Ansatz
Shift-Right betont das Testen im Betrieb, nicht frühere Aktivitäten.
Big-Bang-Integration
Das ist eine Integrationsstrategie, ohne Bezug zum Zeitpunkt der Testaktivitäten.
Exploratives Testen
Exploratives Testen ist eine erfahrungsbasierte Technik, keine zeitliche Einordnung.
„Shift Left“ bedeutet, Testaktivitäten früher im Lebenszyklus durchzuführen, etwa Anforderungsreviews und Testen während der Codierung.
Es werden Tests durchgeführt, um zu prüfen, ob Schnittstellen und Interaktionen zwischen integrierten Modulen korrekt funktionieren, bevor das Gesamtsystem getestet wird. Welche Teststufe ist das?
Integrationstest
Er zielt gezielt auf Schnittstellen und Interaktionen zwischen Modulen.
Komponententest
Der Komponententest prüft Module isoliert, nicht ihre Interaktionen.
Abnahmetest
Der Abnahmetest validiert die Einsatzbereitschaft, meist durch Nutzer, später im Prozess.
Regressionstest
Der Regressionstest ist eine nach Änderungen wiederholte Testart, keine Stufe für Schnittstellen.
Der Integrationstest fokussiert auf Interaktionen zwischen Komponenten oder Systemen; er liegt zwischen Komponenten- und Systemtest.
Ein Tester misst die Antwortzeit unter Last und prüft, ob das System innerhalb eines vereinbarten Schwellenwerts bleibt. Welche Testart ist das?
Nichtfunktionales Testen
Performanz/Antwortzeit ist ein nichtfunktionales Qualitätsmerkmal.
Funktionales Testen
Funktionales Testen prüft, was das System tut, nicht wie gut es performt.
White-Box-Testen
White-Box-Testen leitet Tests aus der internen Struktur ab, nicht anhand eines Performanz-Schwellenwerts.
Fehlernachtest
Der Fehlernachtest wiederholt einen Test nach einer Korrektur; es geht nicht um Performanz.
Nichtfunktionales Testen bewertet Merkmale wie Performanz, Benutzbarkeit und Zuverlässigkeit. Antwortzeit unter Last ist Performanz (nichtfunktional).
Eine Bank spielt einen Sicherheitspatch in ein seit Jahren produktives Zahlungssystem ein. Welche Art von Test wird primär ausgelöst?
Wartungstest
Änderungen an einem produktiven System lösen Wartungstests mit Auswirkungsanalyse aus.
Komponententest
Der Komponententest zielt auf neue Module isoliert, nicht auf Änderungen an einem Livesystem.
Nur Abnahmetest
Eine Abnahme kann erfolgen, auslösend ist hier aber die Änderung am produktiven System.
Für einen Patch ist kein Test nötig
Patches an Livesystemen erfordern Tests zur Beherrschung des Regressionsrisikos.
Wartungstests werden durch Änderungen an einem im Betrieb befindlichen System ausgelöst, etwa Patches, Upgrades oder Migrationen, und umfassen Auswirkungsanalyse und Regressionstest.
Nach einer Fehlerkorrektur will das Team (a) bestätigen, dass die Korrektur wirkt, und (b) sicherstellen, dass nichts anderes zerbrochen ist. Welche ZWEI Aussagen beschreiben Fehlernachtest und Regressionstest korrekt?
Der Fehlernachtest wiederholt nach der Korrektur den zuvor fehlgeschlagenen Test
Der Fehlernachtest prüft, ob der konkrete Fehlerzustand behoben ist.
Der Regressionstest prüft, dass unveränderte Teile nach der Änderung weiter funktionieren
Der Regressionstest erkennt unbeabsichtigte Nebenwirkungen von Änderungen.
Der Fehlernachtest misst die Performanz unter Spitzenlast
Das beschreibt Performanztest, nicht den Fehlernachtest.
Der Regressionstest wird ausschließlich manuell durchgeführt
Der Regressionstest eignet sich stark für Automatisierung und ist nicht rein manuell.
Der Fehlernachtest wiederholt den fehlgeschlagenen Test nach der Korrektur; der Regressionstest prüft, dass unveränderte Bereiche nach der Änderung weiter funktionieren.
Was ist ein wesentlicher Vorteil des statischen Testens gegenüber dem dynamischen Testen?
Fehlerzustände können früher gefunden werden, bevor Code ausgeführt wird
Statisches Testen findet Fehler in frühen Arbeitsergebnissen und senkt spätere Kosten.
Es misst die tatsächliche Laufzeit-Performanz
Laufzeitverhalten erfordert dynamisches Testen, nicht statisches.
Es macht jedes dynamische Testen überflüssig
Statisches und dynamisches Testen ergänzen sich, sie ersetzen sich nicht.
Es kann nur auf Quellcode angewendet werden
Statisches Testen gilt für viele Arbeitsergebnisse, u. a. Anforderungen und Entwürfe.
Statisches Testen untersucht Arbeitsergebnisse ohne Codeausführung und kann Fehlerzustände (z. B. in Anforderungen) früher und günstiger finden als dynamisches Testen.
Ein formales Review wird von einem geschulten Moderator geleitet, nutzt definierte Rollen und Ein-/Ausgangskriterien, erfasst Metriken und folgt einem dokumentierten Prozess. Welcher Reviewtyp ist das?
Inspektion
Die Inspektion ist der formalste Reviewtyp mit Moderator, Rollen und Metriken.
Informelles Review
Ein informelles Review hat keinen definierten Prozess, keine Rollen und keine Metriken.
Walkthrough
Ein Walkthrough wird vom Autor geleitet und ist weniger formal als eine Inspektion.
Ad-hoc-Paarreview
Das ist informell und hat nicht die definierten Rollen und Metriken einer Inspektion.
Die Inspektion ist der formalste Reviewtyp: geleitet von einem geschulten Moderator, mit definierten Rollen, Regeln, Checklisten, Metriken und formalen Ausgangskriterien.
Wer ist in einem formalen Review primär für das zu überprüfende Arbeitsergebnis und für das Beheben der gefundenen Fehlerzustände verantwortlich?
Der Autor
Der Autor verantwortet das Arbeitsergebnis und behebt die gefundenen Fehlerzustände.
Der Moderator
Der Moderator leitet den Reviewprozess; er verantwortet oder korrigiert das Arbeitsergebnis nicht.
Der Protokollant
Der Protokollant dokumentiert Befunde, ist aber nicht für das Arbeitsergebnis verantwortlich.
Der Managementvertreter
Das Management kann das Review fördern, ist aber nicht für die Korrektur verantwortlich.
Der Autor ist für das zu überprüfende Arbeitsergebnis und die Behebung der gefundenen Fehlerzustände verantwortlich.
Eine sehr umfangreiche Anforderungsspezifikation wird wiederholt geprüft, doch die Reviews finden wenig und die Reviewer klagen über Ermüdung und fehlende Vorbereitungszeit. Welche ZWEI Maßnahmen adressieren anerkannte Erfolgsfaktoren für Reviews? (Wählen Sie zwei.)
Die Spezifikation in kleine Abschnitte aufteilen, damit die Reviewer im individuellen Review ihre Konzentration nicht verlieren.
Richtig — kleine Prüfabschnitte sind ein ausdrücklicher Erfolgsfaktor, denn die Wirksamkeit der Reviewer sinkt stark, sobald die Konzentration nachlässt.
Das Management ausreichend Zeit im Plan für Vorbereitung und Nacharbeit des Reviews einplanen lassen.
Richtig — die Unterstützung durch das Management, einschließlich ausreichender Zeit für Vorbereitung und Nacharbeit, ist einer der organisatorischen Erfolgsfaktoren für Reviews.
Die Anzahl der in jedem Dokument gefundenen Anomalien in die Leistungsbeurteilung des Autors aufnehmen.
Damit wird das Review zur Personenbewertung und das notwendige Vertrauen zerstört. Anomalien sind sachlich zum Arbeitsergebnis zu benennen und nie zur Beurteilung des Verfassers zu verwenden.
Die Reviews entfallen lassen und stattdessen auf zusätzliche dynamische Tests des fertigen Produkts setzen.
Dynamische Tests können ein Anforderungsdokument gar nicht prüfen; Probleme wie Mehrdeutigkeiten oder Widersprüche zeigten sich viel später und wären deutlich teurer zu beheben.
Anerkannte Erfolgsfaktoren sind das Aufteilen großer Arbeitsergebnisse in kleine Abschnitte, damit die Reviewer ihre Konzentration behalten, sowie die Unterstützung durch das Management, das ausreichend Zeit für Vorbereitung und Nacharbeit im Plan vorsieht. Reviews müssen zudem sachlich bleiben und dürfen nie zur Bewertung von Personen dienen.
Welche Aussage beschreibt die Äquivalenzklassenbildung (EP) am besten?
Daten werden in Gruppen geteilt, die gleich behandelt werden sollen; pro Gruppe wird ein Wert getestet
Das ist die Definition der Äquivalenzklassenbildung.
Jeder mögliche Eingabewert muss einzeln getestet werden
Das ist vollständiges Testen, das EP gerade vermeidet.
Nur Werte an den Rändern von Bereichen werden getestet
Randwerte zu testen ist Grenzwertanalyse, nicht Äquivalenzklassenbildung.
Tests werden aus dem Kontrollfluss des Codes abgeleitet
Die Ableitung aus dem Kontrollfluss ist eine White-Box-Technik, nicht EP.
EP teilt Eingabe- (oder Ausgabe-)daten in Klassen, die voraussichtlich gleich behandelt werden; ein Wert pro Klasse ist repräsentativ und reduziert die Anzahl der Testfälle.
Ein Feld „Alter“ akzeptiert ganze Zahlen. Regeln: 0–17 = „minderjährig“, 18–64 = „erwachsen“, 65 und mehr = „Senior“, jeder Wert unter 0 ist ungültig. Wie viele Testfälle sind mit Äquivalenzklassenbildung MINIMAL nötig, um jede Klasse genau einmal abzudecken?
4
Vier Klassen (ungültig, minderjährig, erwachsen, Senior) erfordern vier Testfälle.
3
Das übersieht die ungültige Klasse (<0).
6
Es gibt nur vier Klassen, nicht sechs.
8
Acht ist zu viel; EP braucht einen Wert je Klasse.
Klassen: ungültig (<0), minderjährig (0–17), erwachsen (18–64), Senior (≥65). Das sind 4 Klassen, also mindestens 4 Testfälle, einer je Klasse.
Eine numerische Eingabe akzeptiert Werte von 1 bis 100 einschließlich. Welche Wertemenge testet mit 2-Wert-Grenzwertanalyse die Grenzen des gültigen Bereichs?
0, 1, 100, 101
Das sind die beiden Grenzwertpaare für den Bereich 1..100 in der 2-Wert-GWA.
1, 50, 100
50 ist ein Klassenmittelwert, kein Grenzwert; die Nachbarn 0 und 101 fehlen.
0, 1, 2, 99, 100, 101
Das mischt 3-Wert-Nachbarn (2 und 99) hinzu, die für die 2-Wert-GWA nicht nötig sind.
1, 100
Das lässt die benachbarten ungültigen Werte 0 und 101 aus, die die 2-Wert-GWA braucht.
Die 2-Wert-Grenzwertanalyse nutzt den Grenzwert und seinen nächsten Nachbarn auf der anderen Seite. Für 1..100 sind das {0,1} an der Untergrenze und {100,101} an der Obergrenze.
Ein Temperaturfeld akzeptiert 10 bis 30 einschließlich. Wie viele verschiedene Grenzwerte werden mit 3-Wert-Grenzwertanalyse über die untere und obere Grenze hinweg getestet?
6
Unten {9,10,11} und oben {29,30,31} ergeben sechs verschiedene Werte.
4
Vier Werte entsprechen der 2-Wert-GWA, nicht der 3-Wert-GWA.
3
Drei deckt nur eine Grenze ab; beide Grenzen werden benötigt.
8
Acht ist zu viel; jede Grenze liefert drei Werte, insgesamt sechs.
Die 3-Wert-GWA testet jeden Grenzwert plus den Wert auf jeder Seite. Unten: 9,10,11. Oben: 29,30,31. Das sind 6 verschiedene Werte.
R5 — 25 %
Mitglied=N, Dienstag=J, Senior=J entspricht R5 mit 25 %.
R1 — 40 %
R1 verlangt, dass der Kunde auch Treuemitglied ist (Mitglied=J).
R6 — 20 %
R6 verlangt Senior=N; hier ist der Kunde Senior.
R7 — 10 %
R7 verlangt Dienstag=N; hier ist die Vorstellung an einem Dienstag.
Mitglied = N, Dienstag = J, Senior = J. Diese Kombination ist Regel R5 mit 25 % Rabatt.
Die Kino-Entscheidungstabelle hat drei unabhängige binäre Bedingungen (Mitglied?, Dienstag?, Senior?) und keine Kombination ist unzulässig. Wie viele Regelspalten sind für die vollständige Entscheidungstabellenüberdeckung nötig?
8
2^3 = 8 Kombinationen dreier binärer Bedingungen.
6
Sechs ist zu wenig; drei binäre Bedingungen ergeben acht Kombinationen.
3
Drei ist die Anzahl der Bedingungen, nicht der Regeln.
16
16 = 2^4 würde vier Bedingungen erfordern, nicht drei.
Bei drei unabhängigen binären Bedingungen und keinen unzulässigen Kombinationen braucht die vollständige Überdeckung 2^3 = 8 Regeln, entsprechend R1–R8.
start → pause → resume → submit → grade
Jeder Übergang dieser Folge existiert im Automaten.
start → grade → submit
grade ist nur aus Submitted gültig und kann nicht direkt auf start folgen.
pause → start → submit
pause ist aus NotStarted nicht gültig; die Sitzung muss zuerst starten.
start → submit → resume
resume ist nur aus Paused gültig, nicht aus Submitted.
Gültige Übergänge: start (NotStarted→InProgress), pause (InProgress→Paused), resume (Paused→InProgress), submit (InProgress→Submitted), grade (Submitted→Graded). Die Folge start, pause, resume, submit, grade folgt allen.
5
Es gibt genau fünf gültige Übergänge, je einmal abzudecken.
4
Vier übersieht einen Übergang; es sind fünf insgesamt.
6
Es gibt nur fünf gültige Übergänge, nicht sechs.
5 Zustände bedeuten 5, aber mit ungültigen Übergängen mehr
Die 0-Switch-Überdeckung zählt nur gültige Übergänge, also fünf.
Die 0-Switch-Überdeckung (einzelner Übergang) verlangt, jeden gültigen Übergang einmal auszuführen. Der Automat hat 5 Übergänge (start, pause, resume, submit, grade), also 5 Testfälle.
Welche Technik leitet Testfälle aus Interaktionsfolgen zwischen einem Akteur und dem System ab, um End-to-End-Geschäftsabläufe zu testen?
Anwendungsfalltest
Er leitet Tests aus Interaktionsfolgen zwischen Akteur und System ab.
Anweisungstest
Der Anweisungstest ist eine codebasierte White-Box-Technik, nicht interaktionsbasiert.
Grenzwertanalyse
Die GWA zielt auf Bereichsgrenzen einzelner Eingaben, nicht auf Interaktionsabläufe.
Entscheidungstabellentest
Entscheidungstabellen modellieren Bedingungskombinationen, keine Akteur-Interaktionsfolgen.
Der Anwendungsfalltest leitet Tests aus Use Cases ab, die Interaktionen zwischen Akteuren und System beschreiben, und eignet sich für End-to-End- und Integrationsszenarien.
Welche ZWEI der folgenden sind erfahrungsbasierte Testverfahren?
Fehlererraten
Fehlererraten nutzt die Erfahrung des Testers über wahrscheinliche Fehlerzustände.
Exploratives Testen
Exploratives Testen beruht darauf, dass der Tester gleichzeitig lernt und Tests entwirft.
Äquivalenzklassenbildung
EP ist ein spezifikationsbasiertes Black-Box-Verfahren, nicht erfahrungsbasiert.
Entscheidungstabellentest
Der Entscheidungstabellentest ist spezifikationsbasiert, abgeleitet aus Bedingungskombinationen.
Erfahrungsbasierte Verfahren stützen sich auf Wissen und Intuition des Testers. Fehlererraten und exploratives Testen sind erfahrungsbasiert; Äquivalenzklassenbildung und Entscheidungstabellentest sind Black-Box (spezifikationsbasiert).
Welche ZWEI der folgenden sind Black-Box-(spezifikationsbasierte) Testtechniken? (Wählen Sie ZWEI.)
Grenzwertanalyse.
Richtig — BVA ist eine spezifikationsbasierte (Black-Box-)Technik.
Zustandsübergangstest.
Richtig — die Tests werden aus einer Verhaltensspezifikation (Zustandsmodell) abgeleitet.
Anweisungstest.
Der Anweisungstest ist eine White-Box-Technik auf Codebasis.
Zweigtest.
Der Zweigtest ist eine White-Box-Technik auf Basis des Kontrollflusses.
Fehlererwartung.
Fehlererwartung ist eine erfahrungsbasierte, keine spezifikationsbasierte Technik.
Black-Box-Techniken sind u. a. Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellentest und Zustandsübergangstest. Anweisungs- und Zweigtest sind White-Box; Fehlererwartung ist erfahrungsbasiert.
Ein Tester schätzt eine Aufgabe mit der Dreipunkt- (PERT-)Schätzung: optimistisch = 5 Tage, wahrscheinlichster Wert = 8 Tage, pessimistisch = 17 Tage. Wie hoch ist der geschätzte Aufwand mit der Formel (a + 4m + b) / 6?
9 Tage
(5 + 32 + 17)/6 = 54/6 = 9.
10 Tage
10 ignoriert die 4-fache Gewichtung des wahrscheinlichsten Werts.
8 Tage
8 ist nur der wahrscheinlichste Wert, nicht der gewichtete PERT-Mittelwert.
11 Tage
11 ist ein Rechenfehler; der korrekte PERT-Wert ist 9.
(5 + 4×8 + 17) / 6 = (5 + 32 + 17) / 6 = 54 / 6 = 9 Tage.
Welche zwei Faktoren bestimmen die Höhe eines Produktrisikos?
Die Eintrittswahrscheinlichkeit und die Auswirkung bei Eintritt
Risikohöhe = Wahrscheinlichkeit × Auswirkung.
Die Anzahl der Tester und das Testbudget
Das sind Ressourcenfaktoren, nicht die Definition der Risikohöhe.
Die Programmiersprache und die verwendete IDE
Werkzeugentscheidungen definieren die Produktrisikohöhe nicht.
Die Anzahl der Testfälle und ihre Länge
Die Anzahl der Testfälle bestimmt die Risikohöhe nicht.
Die Risikohöhe wird durch die Eintrittswahrscheinlichkeit und die Auswirkung (Schaden) bei Eintritt bestimmt.
Welche der folgenden ist eine übliche Testfortschrittsmetrik im Testmonitoring?
Prozentsatz der durchgeführten geplanten Testfälle
Das ist eine Standard-Testfortschrittsmetrik.
Die Anzahl der Kommentarzeilen im Code
Die Kommentaranzahl ist keine Testfortschrittsmetrik.
Das Gehalt des Testteams
Das Gehalt ist keine Fortschrittsmetrik.
Die Bürotemperatur während des Testens
Das ist für den Testfortschritt irrelevant.
Testmonitoring nutzt Metriken wie den Prozentsatz durchgeführter geplanter Testfälle, Bestanden/Fehlgeschlagen-Raten und Trends zu Fehlerfund/-behebung, um den Fortschritt gegen den Plan zu verfolgen.
Ein Team legt eine Regel fest, dass der Systemtest erst beginnen darf, wenn der Build in der Testumgebung bereitgestellt ist und alle kritischen Komponentenfehler behoben sind. Wofür ist das ein Beispiel?
Eingangskriterien
Das sind Vorbedingungen, die vor Testbeginn erfüllt sein müssen.
Ausgangskriterien
Ausgangskriterien legen fest, wann das Testen enden kann, nicht wann es beginnen darf.
Ein Test-Charter
Ein Test-Charter leitet eine explorative Session, keine Eingangsvorbedingungen.
Ein Fehlerbericht
Ein Fehlerbericht dokumentiert eine konkrete Fehlerwirkung, keine Vorbedingungen.
Eingangskriterien (Definition of Ready) sind die Vorbedingungen, die erfüllt sein müssen, bevor eine Testaktivität beginnen kann.
Welche ZWEI Elemente werden typischerweise in einem Testplan dokumentiert?
Testumfang und -ziele
Umfang und Ziele sind Kerninhalt eines Testplans.
Ein- und Ausgangskriterien
Ein-/Ausgangskriterien sind Standardelemente eines Testplans.
Der vollständige Quellcode der Anwendung
Quellcode wird nicht im Testplan dokumentiert.
Der genaue Code-Diff jeder Fehlerkorrektur
Code-Diffs gehören in die Versionsverwaltung, nicht in den Testplan.
Ein Testplan dokumentiert typischerweise Umfang/Ziele, Vorgehen, Zeitplan, Ressourcen sowie Ein-/Ausgangskriterien. Quellcode und einzelne Fehlerkorrekturen gehören nicht zum Testplan.
Was ist der Hauptzweck des Konfigurationsmanagements im Testkontext?
Versionen von Testware und Softwareelementen zu identifizieren und zu steuern, damit Tests reproduzierbar sind
Genau das leistet das Konfigurationsmanagement.
Den Produktionsquellcode zu schreiben
Code zu schreiben ist eine Entwicklungsaufgabe, kein Konfigurationsmanagement.
Risiken nach Wahrscheinlichkeit und Auswirkung zu priorisieren
Das ist Risikoanalyse, eine andere Managementtätigkeit.
Null Fehlerzustände im Release zu garantieren
Keine Tätigkeit kann null Fehlerzustände garantieren.
Das Konfigurationsmanagement stellt die Integrität von Arbeitsergebnissen (Testfälle, Testware, Softwareelemente) her und erhält sie durch eindeutige Identifikation und Versionskontrolle, sodass Tests nachvollziehbar und reproduzierbar sind.
Welche ZWEI Informationen sollte ein gut geschriebener Fehlerbericht enthalten?
Schritte zur Reproduktion der Fehlerwirkung
Reproduktionsschritte helfen Entwicklern, den Fehlerzustand zu bestätigen und zu lokalisieren.
Erwartetes Ergebnis versus tatsächliches Ergebnis
Der Vergleich verdeutlicht, warum das Verhalten ein Fehlerzustand ist.
Der Name des schuldigen Entwicklers
Fehlerberichte sollten objektiv sein und keine Schuld zuweisen.
Eine verbindliche Frist, bis zu der die Korrektur zu liefern ist
Die Terminierung von Korrekturen ist eine Managemententscheidung, nicht Teil des Fehlerberichts.
Ein guter Fehlerbericht enthält Schritte zur Reproduktion, erwartetes vs. tatsächliches Ergebnis, Schweregrad/Priorität und Umgebung. Er sollte keine Schuldzuweisung oder vorgeschriebene Behebungszeit enthalten.
Ein Testmanager schätzt den Aufwand durch Analyse gemessener Daten früherer ähnlicher Projekte (z. B. historische Fehler- und Produktivitätszahlen). Welcher Schätzansatz ist das?
Metrikbasierte Schätzung
Sie nutzt gemessene Daten aus früheren Projekten.
Expertenbasierte Schätzung
Die expertenbasierte Schätzung beruht auf Urteil, nicht auf gemessenen historischen Daten.
Grenzwertanalyse
Die GWA ist ein Testentwurfsverfahren, kein Schätzansatz.
Explorative Schätzung
Das ist kein anerkanntes Schätzverfahren im Lehrplan.
Die metrikbasierte Schätzung nutzt Daten aus vergangenen Projekten; die expertenbasierte Schätzung beruht auf dem Urteil erfahrener Personen.
Was beschreibt die Rolle des Konfigurationsmanagements zur Unterstützung des Testens am BESTEN?
Es identifiziert und versioniert Testobjekte und Testmittel.
Richtig — KM stützt reproduzierbares Testen.
Es entwirft die Testfälle automatisch.
KM entwirft keine Testfälle.
Es garantiert, dass die Software keine Fehler hat.
KM garantiert das nicht.
Es genehmigt das Projektbudget.
Eine Managementfunktion.
Das KM stellt sicher, dass Testobjekte und Testmittel identifiziert und versioniert werden, sodass das Testen reproduzierbar ist.
Ein Team nutzt ein Werkzeug, das Benutzerinteraktionen aufzeichnet und wiedergibt und tatsächliche mit erwarteten Ergebnissen automatisch vergleicht. Welche Kategorie von Testwerkzeug ist das?
Testausführungswerkzeug (Capture/Playback)
Es automatisiert die Testdurchführung und den Ergebnisvergleich.
Statisches Analysewerkzeug
Statische Analyse untersucht Code ohne Ausführung, anders als dieses Werkzeug.
Anforderungsmanagement-Werkzeug
Das verwaltet Anforderungen, nicht die automatisierte Testdurchführung.
Performanztestwerkzeug
Performanzwerkzeuge erzeugen Last und messen Zeiten, nicht Capture/Replay von UI-Interaktionen mit Ergebnisvergleich.
Testausführungswerkzeuge (inkl. Capture/Playback) führen Tests automatisch aus und vergleichen tatsächliche mit erwarteten Ergebnissen, was Regressionstests unterstützt.
Welche ZWEI sind potenzielle Risiken oder Kosten der Einführung von Testautomatisierung?
Laufender Wartungsaufwand, wenn sich die Anwendung ändert
Automatisierte Skripte müssen bei Änderungen am Testobjekt aktualisiert werden.
Anfangsinvestition in Werkzeuge und Kompetenzen
Werkzeuge, Einrichtung und Schulung sind erhebliche Anfangskosten.
Sie garantiert, dass alle Fehlerzustände gefunden werden
Kein Ansatz kann das Finden aller Fehlerzustände garantieren.
Sie beseitigt die Notwendigkeit, Testfälle zu entwerfen
Automatisierung führt Tests aus; sie ersetzt nicht Testanalyse und -entwurf.
Automatisierung bringt Wartungsaufwand für Testskripte und erfordert Anfangsinvestition/Kompetenzen. Sie beseitigt weder den Bedarf an Testentwurf noch garantiert sie das Finden aller Fehlerzustände.