ISTQB Foundation (CTFL v4.0) Probeprüfung #14 — 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.
Warum ist Testen in einem Softwareprojekt notwendig?
Es reduziert das Risiko von Fehlerwirkungen im Betrieb
Richtig — ein Kernziel des Testens ist die Senkung des Restrisikos vor der Freigabe.
Es beweist, dass die Software keine Fehlerzustände enthält
Falsch — Testen kann die Abwesenheit von Fehlern nicht beweisen (Testprinzip).
Es ersetzt die Notwendigkeit von Anforderungsreviews
Falsch — dynamisches Testen ergänzt Reviews, ersetzt sie aber nicht.
Es garantiert, dass die Software jeden Nutzer zufriedenstellt
Falsch — kein Testumfang kann universelle Zufriedenheit garantieren.
Testen reduziert das Risiko von Fehlerwirkungen im Betrieb; es kann kein fehlerfreies Produkt garantieren.
Welche der folgenden Punkte sind Ziele des Testens? (Wählen Sie ZWEI.)
Fehlerzustände und Fehlerwirkungen finden
Richtig — das Aufdecken von Fehlern ist ein Hauptziel.
Vertrauen in das Qualitätsniveau schaffen
Richtig — Vertrauen aufzubauen ist ein genanntes Ziel.
Die gefundenen Fehlerzustände beheben
Falsch — Fehler zu beheben ist Debugging/Entwicklung, nicht Testen.
Beweisen, dass keine Fehler mehr vorhanden sind
Falsch — unmöglich; Testen kann Fehlerfreiheit nicht beweisen.
Testen bewertet Qualität, findet Fehlerzustände und schafft Vertrauen in das Qualitätsniveau. Fehlerbehebung ist Debugging; Fehlerfreiheit zu beweisen ist unmöglich.
Ein Testteam führt jede Nacht dieselbe automatisierte Regressionssuite aus. Mit der Zeit findet sie immer weniger neue Fehlerzustände. Welches Testprinzip erklärt das?
Das Pestizid-Paradoxon
Richtig — identische Tests decken keine neuen Fehler mehr auf; variieren und aktualisieren.
Fehlerhäufung (Defect Clustering)
Falsch — Häufung betrifft die Konzentration von Fehlern in wenigen Modulen.
Testen ist kontextabhängig
Falsch — dieses Prinzip betrifft die Anpassung an den Kontext.
Trugschluss der Fehlerabwesenheit
Falsch — dieser Trugschluss betrifft Qualität vs. Nutzerbedürfnisse.
Das Pestizid-Paradoxon: Wiederholt gleiche Tests finden irgendwann keine neuen Fehler mehr; Tests müssen überprüft und angepasst werden.
Ein Entwickler vertippt sich in einer Formel. Das Programm zeigt später eine falsche Summe auf dem Bildschirm. Was ist die falsche Summe im ISTQB-Sinn?
Eine Fehlerwirkung
Richtig — eine beobachtbare Abweichung vom erwarteten Ergebnis ist eine Fehlerwirkung.
Eine Fehlhandlung
Falsch — die Fehlhandlung ist der menschliche Irrtum (Vertippen).
Ein Fehlerzustand
Falsch — der Fehlerzustand ist die falsche Formel im Code.
Eine Grundursache
Falsch — die Grundursache ist der tiefere Ursprung der Fehlhandlung.
Fehlhandlung → Fehlerzustand (im Code) → Fehlerwirkung (beobachtbares falsches Verhalten). Die falsche Ausgabe ist eine Fehlerwirkung.
Welche Aussage unterscheidet Testen korrekt vom Debugging?
Testen kann Fehlerwirkungen zeigen; Debugging findet, analysiert und beseitigt deren Ursachen
Richtig — dies ist die Standardunterscheidung der ISTQB.
Testen und Debugging sind zwei Namen für dieselbe Aktivität
Falsch — es sind verschiedene Aktivitäten mit unterschiedlichen Zielen.
Debugging wird nur von Testern durchgeführt
Falsch — Debugging wird typischerweise von Entwicklern durchgeführt.
Testen beseitigt Fehler; Debugging meldet sie nur
Falsch — das vertauscht die Rollen; Testen beseitigt keine Fehler.
Testen kann Fehlerwirkungen auslösen; Debugging ist die Entwicklungsaktivität, die Fehlerzustände findet, analysiert und behebt.
Ein Produkt hat sehr wenige Fehler, wird aber von Nutzern abgelehnt, weil es ihre tatsächlichen Bedürfnisse nicht erfüllt. Welches Testprinzip zeigt das?
Der Trugschluss der Fehlerabwesenheit
Richtig — wenige Fehler garantieren kein bedarfsgerechtes System.
Frühes Testen spart Zeit und Geld
Falsch — dieses Prinzip betrifft frühes Testen, nicht Nutzerbedürfnisse.
Tests zeigen die Anwesenheit von Fehlern
Falsch — dieses Prinzip betrifft, was Testen beweisen kann.
Vollständiges Testen ist unmöglich
Falsch — dieses Prinzip betrifft die Unmöglichkeit, alles zu testen.
Trugschluss der Fehlerabwesenheit: Fehler zu finden und zu beheben hilft nicht, wenn das System die Nutzerbedürfnisse nicht erfüllt.
In welcher Testaktivität werden Testbedingungen und Überdeckungselemente aus der Testbasis abgeleitet?
Testanalyse
Richtig — die Testanalyse leitet Testbedingungen und Überdeckungselemente ab.
Testentwurf
Falsch — der Testentwurf macht aus Testbedingungen konkrete Testfälle.
Testrealisierung
Falsch — die Testrealisierung bereitet Testmittel für die Ausführung vor.
Testabschluss
Falsch — der Testabschluss archiviert Testmittel und berichtet am Ende.
Die Testanalyse identifiziert testbare Merkmale und definiert Testbedingungen aus der Testbasis ("was"). Der Testentwurf definiert Testfälle ("wie").
Ein Team verwaltet seine Testfälle, automatisierten Skripte und Testdaten im gleichen Versionsverwaltungssystem wie den Code, den sie prüfen. Was ist der wesentliche Nutzen, Testmittel auf diese Weise dem Konfigurationsmanagement zu unterstellen?
Änderungen an den Testmitteln sind nachvollziehbar, und jede Version kann reproduziert und der zugehörigen Version des Testobjekts zugeordnet werden.
Richtig — genau deshalb müssen Testmittel dem Konfigurationsmanagement unterliegen: identifizierbar, versioniert und konsistent zum Testobjekt.
Es garantiert, dass die Tests alle verbleibenden Fehlerzustände im Testobjekt aufdecken.
Das kann keine Praktik garantieren. Testen kann die Anwesenheit von Fehlerzuständen zeigen, deren Abwesenheit aber nie beweisen — unabhängig von den Werkzeugen.
Es macht die Pflege der Testmittel bei Änderungen am Testobjekt entbehrlich.
Konfigurationsmanagement erfasst und lenkt Änderungen, führt sie aber nicht durch. Testmittel müssen weiterhin angepasst werden, wenn sich das Testobjekt ändert.
Es macht das Testobjekt unabhängig von der Testumgebung, in der es läuft.
Die Versionierung der Testmittel sagt nichts über Umgebungsabhängigkeiten. Unterschiede der Umgebung bleiben eine bekannte Ursache für Fehlerwirkungen, die nur in der Produktion auftreten.
Konfigurationsmanagement der Testmittel macht Änderungen nachvollziehbar und erlaubt es, jede Version der Testmittel zu reproduzieren und der Version des Testobjekts zuzuordnen, für die sie erstellt wurde — unentbehrlich für Regressions- und Wartungstests.
Wann sollten in einem sequenziellen (V-Modell) Lebenszyklus Testplanung und Testentwurf für die Systemteststufe idealerweise beginnen?
Sobald die Systemanforderungen vorliegen
Richtig — frühe Einbindung erlaubt Testentwurf gegen die Anforderungen und frühes Fehlerfinden.
Nachdem der gesamte Code geschrieben wurde
Falsch — Warten bis nach der Codierung verzögert das Fehlerfinden und erhöht Kosten.
Erst nachdem der Komponententest bestanden ist
Falsch — die Planung kann viel früher parallel zur Entwicklungsphase beginnen.
Während der Abnahmetestphase
Falsch — das ist für die Systemteststufe viel zu spät.
Shift-Left: Testaktivitäten einer Stufe sollten beginnen, sobald die zugehörige Basis (z. B. Systemanforderungen) vorliegt, nicht erst nach der Codierung.
Welche Teststufe prüft vorrangig die Schnittstellen und Interaktionen zwischen integrierten Komponenten oder Systemen?
Integrationstest
Richtig — er zielt auf Schnittstellen und Interaktionen zwischen integrierten Elementen.
Komponententest
Falsch — der Komponententest prüft einzelne Komponenten isoliert.
Abnahmetest
Falsch — der Abnahmetest prüft die Einsatzbereitschaft gegen Nutzerbedürfnisse.
Systemtest
Falsch — der Systemtest bewertet das Verhalten des Gesamtsystems.
Der Integrationstest konzentriert sich auf Schnittstellen und Interaktionen zwischen Komponenten oder Systemen.
Welche der folgenden sind Beispiele für nicht-funktionale Tests? (Wählen Sie ZWEI.)
Antwortzeit unter Spitzenlast messen
Richtig — Performanz ist ein nicht-funktionales Qualitätsmerkmal.
Bewerten, wie leicht neue Nutzer eine Aufgabe erledigen
Richtig — Gebrauchstauglichkeit ist ein nicht-funktionales Merkmal.
Prüfen, dass ein Rabatt korrekt berechnet wird
Falsch — eine Berechnung gegen eine Regel zu prüfen ist funktionaler Test.
Prüfen, dass ein Login gültige Zugangsdaten akzeptiert
Falsch — erwartetes funktionales Verhalten zu prüfen ist funktionaler Test.
Nicht-funktionale Tests bewerten das Wie — Performanz, Gebrauchstauglichkeit, Zuverlässigkeit, Sicherheit. Ein Rechenergebnis oder eine Geschäftsregel zu prüfen ist funktional.
Nachdem ein Fehler im Zahlungsmodul behoben wurde, führt das Team genau die zuvor fehlgeschlagenen Tests erneut aus, um die Korrektur zu bestätigen. Wie heißt das?
Fehlernachtest (Bestätigungstest)
Richtig — er bestätigt, dass der ursprüngliche Fehler behoben wurde.
Regressionstest
Falsch — der Regressionstest sucht unbeabsichtigte Nebenwirkungen anderswo.
Smoke-Test
Falsch — ein Smoke-Test prüft breit und flach, ob ein Build testbar ist.
Wartungstest
Falsch — der Wartungstest ist eine breitere Aktivität bei Änderungen im Betrieb.
Das erneute Ausführen der zuvor fehlgeschlagenen Tests ist Fehlernachtest (Bestätigungstest). Regressionstest prüft, ob die Änderung anderes nicht beschädigt hat.
Was charakterisiert den 'Shift-Left'-Ansatz beim Testen am besten?
Testaktivitäten früher im Lebenszyklus durchführen
Richtig — Shift-Left zieht das Testen nach vorn, um Fehler früh zu erkennen.
Alles Testen bis kurz vor die Freigabe verschieben
Falsch — das ist das Gegenteil von Shift-Left.
Nur in Produktion mit echten Nutzern testen
Falsch — das beschreibt Tests in Produktion, nicht Shift-Left.
Das Testen vollständig dem Betriebsteam übergeben
Falsch — Shift-Left betrifft den Zeitpunkt, nicht die Zuständigkeit.
Shift-Left bedeutet, Testaktivitäten früher im Lebenszyklus durchzuführen (z. B. Anforderungsreviews, Tests vor dem Code), um Fehler früher zu finden.
Eine Bank ändert ihr Kernsystem, damit es auf einer neuen Betriebssystemversion läuft, ohne die Funktionen zu ändern. Welche Art von Wartung löst diesen Test aus?
Adaptive Wartung
Richtig — Anpassung an eine neue Umgebung ohne Funktionsänderung ist adaptive Wartung.
Korrektive Wartung
Falsch — korrektive Wartung behebt im Betrieb gefundene Fehler.
Perfektionierende Wartung
Falsch — perfektionierende Wartung verbessert oder ergänzt Funktionen.
Notfallwartung
Falsch — Notfallwartung ist eine dringende Korrektur, keine Umgebungsanpassung.
Die Anpassung an eine geänderte/neue Umgebung (z. B. neues OS) ist adaptive Wartung; der Test dafür ist Wartungstest.
Warum kann statisches Testen (z. B. das Review eines Anforderungsdokuments) für bestimmte Fehler kostengünstiger sein als dynamisches Testen?
Es findet Fehler in Arbeitsergebnissen früh, bevor sie in den Code gelangen
Richtig — frühe Fehlererkennung vermeidet teure spätere Nacharbeit.
Es führt den Code schneller aus als dynamisches Testen
Falsch — statisches Testen führt den Code gar nicht aus.
Es garantiert die Beseitigung aller Fehler
Falsch — keine Technik garantiert die Beseitigung aller Fehler.
Es macht jeglichen dynamischen Test überflüssig
Falsch — statisch und dynamisch ergänzen sich, ersetzen sich nicht.
Statisches Testen findet Fehler direkt in Arbeitsergebnissen, bevor Code existiert — früh und günstig — und deckt Fehler (z. B. Mehrdeutigkeiten) auf, die dynamisch schwer zu finden sind.
Welche Aktivitäten gehören zum Review-Prozess laut Lehrplan? (Wählen Sie ZWEI.)
Individuelles Review (individuelle Vorbereitung)
Richtig — Reviewer prüfen das Arbeitsergebnis einzeln und notieren Befunde.
Kommunikation und Analyse der Befunde
Richtig — Befunde werden besprochen und ihr Status/Verantwortlicher festgelegt.
Ausführen der Testfälle
Falsch — Testausführung ist dynamisches Testen, kein Teil des Reviews.
Debugging des Quellcodes
Falsch — Debugging ist eine Entwicklungsaktivität, kein Review.
Der Review-Prozess umfasst Planung, Initiierung, individuelles Review, Kommunikation & Analyse sowie Beheben & Berichten. Testausführung und Debugging gehören nicht dazu.
Ein Team benötigt ein formales, dokumentiertes Review unter Leitung eines geschulten Moderators, mit definierten Rollen, Eingangs-/Ausgangskriterien und Metriken. Welcher Review-Typ passt am besten?
Inspektion
Richtig — das formalste Review mit geschultem Moderator, Rollen, Kriterien und Metriken.
Informelles Review
Falsch — ein informelles Review hat keinen definierten Prozess oder Rollen.
Walkthrough
Falsch — ein Walkthrough wird vom Autor geleitet und ist weniger formal.
Technisches Review
Falsch — ein technisches Review ist formal, fokussiert aber technische Entscheidungen und ist meist peer-geführt.
Eine Inspektion ist der formalste Review-Typ: geleitet von einem geschulten Moderator, mit definierten Rollen, Kriterien und Metriken.
Im Review-Prozess dient eine Aktivität dazu, die von den Reviewern gemeldeten Anomalien zu besprechen, jeder von ihnen einen Status und einen Schweregrad zuzuweisen und zu entscheiden, wer sie bearbeitet. Welche Aktivität ist das?
Kommunikation und Analyse der Befunde
Richtig — in dieser Aktivität werden Anomalien besprochen, nach Status und Schweregrad klassifiziert und zur Bearbeitung zugewiesen.
Individuelles Review
Im individuellen Review prüft jeder Reviewer das Arbeitsergebnis allein und notiert mögliche Anomalien. Diese werden noch nicht besprochen, klassifiziert oder zugewiesen.
Review-Initiierung
In der Review-Initiierung werden das Arbeitsergebnis und begleitende Unterlagen an die Teilnehmer verteilt und deren Fragen zum Auftrag beantwortet, bevor mit dem Prüfen begonnen wird.
Beheben und Berichten
Beim Beheben und Berichten korrigiert der Autor die akzeptierten Anomalien, und das Review-Ergebnis wird berichtet, einschließlich der Erfüllung der Endekriterien.
In der Aktivität Kommunikation und Analyse der Befunde werden die gemeldeten Anomalien besprochen, Status und Schweregrad festgelegt, Zuständigkeiten zugewiesen und die Qualitätseigenschaften des Arbeitsergebnisses bewertet.
Ein Tester mit tiefem Fachwissen antizipiert, wo Fehlerzustände wahrscheinlich sind (z. B. leere Felder, Sonderzeichen, große Werte), und entwirft Tests rund um diese Vermutungen. Welche Technik wird genutzt?
Intuitive Testfallermittlung (Error Guessing).
Richtig — Tests aus antizipierten wahrscheinlichen Fehlerzuständen zu entwerfen ist Error Guessing.
Äquivalenzklassenbildung.
Die ÄKB ist eine systematische Black-Box-Technik auf Basis von Eingabeklassen, nicht von Intuition.
Entscheidungstabellentest.
Entscheidungstabellen behandeln Bedingungskombinationen, keine vermuteten Fehlerzustände.
Anweisungstest.
Der Anweisungstest ist eine White-Box-Überdeckungstechnik.
Die intuitive Testfallermittlung (Error Guessing) nutzt Erfahrung und Wissen über wahrscheinliche Fehler zum Testentwurf; sie kann durch Fehler-/Defektlisten unterstützt werden.
Ein Feld 'Alter' akzeptiert ganze Zahlen von 18 bis 65 einschließlich. Die Preise unterscheiden sich für drei Gruppen: 18–25, 26–59, 60–65. Wie viele Testfälle sind mit Äquivalenzklassenbildung MINDESTENS nötig, um alle gültigen und ungültigen Klassen genau einmal abzudecken?
5
Richtig — 3 gültige + 2 ungültige Klassen = 5 Testfälle.
3
Falsch — dies zählt nur die gültigen Klassen ohne die zwei ungültigen.
4
Falsch — eine Klasse fehlt; es gibt 3 gültige und 2 ungültige.
6
Falsch — zu viele; es gibt hier nur 5 verschiedene Klassen.
Gültige Klassen: 18–25, 26–59, 60–65 (3). Ungültige Klassen: unter 18 und über 65 (2). Insgesamt 5 Klassen → 5 Testfälle.
Ein Rabatt gilt nur, wenn die Bestellsumme zwischen 100 und 500 einschließlich liegt. Welche Wertemenge prüft mit dem 2-Wert-Grenzwertverfahren die Grenzen des gültigen Bereichs?
99, 100, 500, 501
Richtig — jede Grenze (100, 500) plus der unmittelbare Nachbar außerhalb.
100, 300, 500
Falsch — 300 liegt mittig; die Nachbarn knapp außerhalb fehlen.
99, 101, 499, 501
Falsch — nutzt innere Nachbarn statt der Grenzen 100 und 500 selbst.
0, 100, 500, 1000
Falsch — 0 und 1000 sind weit von den Grenzen entfernt.
Die 2-Wert-BVA prüft jede Grenze und ihren nächsten Nachbarn auf der anderen Seite. Für [100,500]: 99, 100, 500, 501.
Für denselben gültigen Bereich 100 bis 500 einschließlich: Wie viele verschiedene Werte benötigt das 3-Wert-Grenzwertverfahren, um BEIDE Grenzen abzudecken?
6
Richtig — 3 Werte pro Grenze × 2 Grenzen = 6 Werte.
4
Falsch — 4 ist das Ergebnis des 2-Wert-Verfahrens.
3
Falsch — 3 deckt nur eine Grenze ab; beide sind gefordert.
8
Falsch — zu viele; nur 6 Werte sind nötig.
Die 3-Wert-BVA prüft je Grenze die Grenze und beide Nachbarn. Unten: 99,100,101; oben: 499,500,501 → 6 Werte.
Welche Aussagen zur Äquivalenzklassenbildung sind korrekt? (Wählen Sie ZWEI.)
Ein Vertreterwert je Klasse genügt normalerweise
Richtig — alle Werte einer Klasse werden gleich behandelt angenommen.
Sowohl gültige als auch ungültige Klassen sollten identifiziert werden
Richtig — EP deckt gültige und ungültige Eingabeklassen ab.
Klassen dürfen sich überlappen, um die Überdeckung zu erhöhen
Falsch — Klassen müssen disjunkt (nicht überlappend) sein.
Jeder Wert einer Klasse muss einzeln getestet werden
Falsch — das widerspricht dem Zweck; ein Vertreter genügt.
Bei der Äquivalenzklassenbildung werden Werte einer Klasse gleich behandelt; ein Vertreter je Klasse genügt. Klassen dürfen sich nicht überlappen; gültige und ungültige Klassen werden identifiziert.
Verwenden Sie die Entscheidungstabelle für Parkgebühren unten. Ein Club-MITGLIED parkt an einem WERKTAG (kein Wochenende) und bleibt 4 Stunden. Welche Regel gilt und welche Gebühr wird berechnet?
R6 → 15 $
Richtig — Member=Y, Weekend=N, Stay>3h=Y ist genau Spalte R6, Gebühr 15 $.
R2 → 20 $
Falsch — R2 ist ein Nicht-Mitglied (Member=N); hier ist der Fahrer Mitglied.
R5 → 7,50 $
Falsch — R5 ist ein Mitglied mit KURZEM Werktagsaufenthalt (Stay>3h=N); hier 4 Stunden.
R8 → 12 $
Falsch — R8 ist ein Mitglied am WOCHENENDE; hier ist Werktag.
Member=Y, Weekend=N, Stay>3h=Y entspricht R6 und ergibt eine Gebühr von 15 $.
Die Parkhaus-Entscheidungstabelle hat drei boolesche Bedingungen (Member?, Weekend?, Stay > 3 hours?) und jede Kombination ergibt eine andere Gebühr. Wie viele Testfälle sind für vollständige Entscheidungstabellenüberdeckung nötig (jede Regel/Spalte einmal)?
8
Richtig — 2^3 = 8 Regeln, keine zusammenfassbar, da jede eine eigene Aktion hat.
4
Falsch — 4 setzt voraus, dass die Hälfte zusammenfällt; alle 8 Aktionen unterscheiden sich.
6
Falsch — kein Grund für 6; es sind 8 verschiedene Regeln.
3
Falsch — 3 ist die Anzahl der Bedingungen, nicht der Regeln/Testfälle.
Bei 3 unabhängigen booleschen Bedingungen gibt es 2^3 = 8 Kombinationen. Da jede Kombination eine andere Aktion ergibt, lässt sich keine Spalte zusammenfassen → 8 Testfälle.
Der Media-Player-Zustandsautomat unten startet im Zustand Stopped. Welche der folgenden Ereignisfolgen ist ein GÜLTIGER Pfad (jedes Ereignis löst einen definierten Übergang aus)?
play, pause, play, stop
Richtig — Stopped→Playing→Paused→Playing→Stopped; alle vier Übergänge existieren.
pause, play, stop
Falsch — 'pause' ist im Startzustand Stopped nicht definiert.
play, stop, pause
Falsch — nach stop ist der Player Stopped, wo 'pause' keinen Übergang hat.
stop, play, pause
Falsch — 'stop' ist im Startzustand Stopped nicht definiert.
Von Stopped: play→Playing, pause→Paused, play→Playing, stop→Stopped. Jedes Ereignis hat einen definierten Übergang; die Folge ist gültig.
Wie viele Testfälle sind für denselben Media-Player-Automaten nötig, um 0-Switch-Überdeckung zu erreichen (alle gültigen Einzelübergänge einmal abgedeckt)?
5
Richtig — es gibt 5 gültige Übergänge; 0-Switch deckt jeden einmal ab.
3
Falsch — 3 ist die Anzahl der Zustände, nicht der Übergänge.
6
Falsch — im Diagramm gibt es nur 5 definierte Übergänge.
9
Falsch — 9 entspricht allen Zustand×Ereignis-Paaren (auch ungültigen), nicht 0-Switch.
0-Switch-Überdeckung erfordert jeden gültigen Übergang einmal. Übergänge: Stopped→Playing (play), Playing→Paused (pause), Playing→Stopped (stop), Paused→Playing (play), Paused→Stopped (stop) = 5.
Ein erfahrener Tester nutzt sein Wissen darüber, wo in ähnlichen Systemen Fehler auftraten, um Tests für wahrscheinlich fehleranfällige Bereiche zu entwerfen — ohne formales Modell. Welche Technik wird verwendet?
Intuitive Testfallermittlung (Error Guessing)
Richtig — eine erfahrungsbasierte Technik auf Basis erwarteter Fehler.
Grenzwertanalyse
Falsch — BVA ist eine systematische Black-Box-Technik auf Basis von Grenzen.
Anweisungstest
Falsch — der Anweisungstest ist eine White-Box-Technik auf Codebasis.
Entscheidungstabellentest
Falsch — der Entscheidungstabellentest nutzt ein formales Modell.
Erfahrung und Intuition über wahrscheinliche Fehler ohne systematisches Modell zu nutzen ist intuitive Testfallermittlung (Error Guessing) — eine erfahrungsbasierte Technik.
Wann werden in einem kollaborationsbasierten Testansatz wie Acceptance Test-Driven Development (ATDD) die Abnahmetests typischerweise erstellt?
Gemeinsam, bevor die Entwicklung der entsprechenden Funktionalität beginnt
Richtig: bei ATDD definieren Fachbereich, Entwicklung und Test die Abnahmetests vorab aus User Stories.
Erst nachdem das Feature vollständig implementiert und ausgeliefert ist
Falsch: das widerspricht dem 'driven'-Charakter von ATDD, bei dem Tests zuerst kommen.
Vom Betriebsteam während des Produktionsmonitorings
Falsch: Abnahmetests werden vom cross-funktionalen Team definiert, nicht vom Betrieb in Produktion.
Automatisch von der Build-Pipeline ohne menschliches Zutun generiert
Falsch: ATDD ist eine kollaborative menschliche Praxis, keine automatische Generierung.
Wie wird bei risikobasiertem Testen die Höhe eines Produktrisikos typischerweise bestimmt?
Durch Kombination von Eintrittswahrscheinlichkeit und Auswirkung
Richtig — Risikohöhe = Wahrscheinlichkeit × Auswirkung.
Durch Zählen der Anzahl der Anforderungen
Falsch — die Anzahl der Anforderungen bestimmt die Risikohöhe nicht.
Durch die Größe des Testteams
Falsch — die Teamgröße hat nichts mit der Risikohöhe zu tun.
Durch die Anzahl der bereits geschriebenen Testfälle
Falsch — die Anzahl der Tests ist ein Ergebnis, keine Risikobestimmung.
Die Risikohöhe ergibt sich aus der Eintrittswahrscheinlichkeit und dem Schadensausmaß (Auswirkung).
Welches der folgenden ist ein Beispiel für ein ENDEKRITERIUM (Definition of Done) einer Teststufe?
Die geplante Überdeckung ist erreicht und keine hochprioren Fehler sind offen
Richtig — ein typisches Endekriterium zum Beenden des Testens.
Die Testumgebung ist installiert und verfügbar
Falsch — eine verfügbare Umgebung ist ein Eingangskriterium.
Die Testdaten wurden vorbereitet
Falsch — vorbereitete Testdaten sind ein Eingangskriterium.
Die Tester wurden dem Projekt zugewiesen
Falsch — Ressourcenzuweisung ist eine Vorbedingung (Eingang).
Endekriterien legen fest, wann das Testen enden kann, z. B. erreichte Überdeckung und keine offenen hochprioren Fehler. Eine verfügbare Testumgebung ist ein Eingangskriterium.
Welche der folgenden Informationen sollte ein guter Fehlerbericht enthalten? (Wählen Sie ZWEI.)
Schritte zur Reproduktion der Fehlerwirkung
Richtig — Reproduktionsschritte ermöglichen die Untersuchung des Fehlers.
Erwartetes und tatsächliches Ergebnis
Richtig — die Abweichung zwischen Soll und Ist ist zentral.
Das Monatsgehalt des Testers
Falsch — irrelevant für die Fehlerbehebung.
Der Marketingplan des Produkts
Falsch — kein Bestandteil eines Fehlerberichts.
Ein Fehlerbericht sollte Kennung/Zusammenfassung, Reproduktionsschritte, Soll-/Ist-Ergebnis, Schweregrad/Priorität enthalten. Gehalt oder Marketingplan sind irrelevant.
Mit der Drei-Punkt-Schätzung wird eine Aufgabe geschätzt: optimistisch = 4 Tage, wahrscheinlich = 10 Tage, pessimistisch = 22 Tage. Wie lautet die Schätzung mit der Formel (a + 4m + b) / 6?
11 Tage
Richtig — 66 / 6 = 11 Tage.
12 Tage
Falsch — das ist der einfache Mittelwert (4+10+22)/3 = 12, nicht PERT.
10 Tage
Falsch — 10 ist der wahrscheinlichste Wert, nicht die gewichtete Schätzung.
13 Tage
Falsch — passt nicht zur Formel; korrekt sind 11 Tage.
(4 + 4×10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 Tage.
Was ist der Hauptzweck der Testüberwachung (Test Monitoring)?
Informationen zum Testfortschritt sammeln und mit dem Plan vergleichen
Richtig — die Überwachung schafft Sichtbarkeit für Steuerungsentscheidungen.
Die beim Testen gefundenen Fehler beheben
Falsch — Fehler beheben ist Debugging, keine Überwachung.
Die Testfälle entwerfen
Falsch — Testentwurf ist keine Überwachung.
Die Testrichtlinie der Organisation schreiben
Falsch — die Testrichtlinie ist ein übergeordnetes Dokument.
Die Testüberwachung sammelt Informationen zum Testfortschritt und vergleicht Ist mit Plan, damit Steuerungsmaßnahmen ergriffen werden können.
Welches der folgenden ist ein Produktrisiko und kein Projektrisiko?
Die Software könnte Zinsen falsch berechnen
Richtig — ein Mangel im gelieferten Produkt ist ein Produktrisiko.
Ein wichtiger Tester könnte vor Projektende ausscheiden
Falsch — Personalverfügbarkeit ist ein Projektrisiko.
Die Testumgebung könnte verspätet geliefert werden
Falsch — Termin/Logistik der Umgebung ist ein Projektrisiko.
Das Testbudget könnte gekürzt werden
Falsch — Budget/Ressourcen sind Projektrisiken.
Ein Produktrisiko betrifft einen möglichen Mangel im Produkt selbst (z. B. Rechenfehler). Ein Projektrisiko betrifft Management/Termin/Ressourcen (z. B. verspätete Lieferung, Personalmangel).
Teststeuerung bedeutet, Korrekturmaßnahmen zu ergreifen, wenn die Überwachung eine Planabweichung zeigt. Welche der folgenden sind Beispiele für Steuerungsmaßnahmen? (Wählen Sie ZWEI.)
Tests neu priorisieren, wenn sich ein Risiko ändert
Richtig — Neupriorisierung ist eine Steuerungsmaßnahme.
Den Testzeitplan anpassen, wenn sich eine Abhängigkeit verzögert
Richtig — Umplanung als Reaktion auf eine Abweichung ist Steuerung.
Die ursprünglichen Systemanforderungen schreiben
Falsch — das ist eine Anforderungsaktivität, keine Teststeuerung.
Eine neue Produktfunktion programmieren
Falsch — die Entwicklung von Funktionen ist keine Teststeuerung.
Steuerungsmaßnahmen umfassen das Neupriorisieren von Tests bei geändertem Risiko und das Anpassen des Testzeitplans. Anforderungen schreiben oder Code entwickeln gehören nicht dazu.
Was sind mögliche Vorteile unabhängigen Testens (durch Personen, die nicht die Autoren des Codes sind)? (Wählen Sie ZWEI.)
Unabhängige Tester sehen oft andere und zusätzliche Fehler
Richtig — eine frische Sicht deckt Fehler auf, die der Autor übersieht.
Sie sind weniger von den Annahmen des Autors beeinflusst
Richtig — Unabhängigkeit verringert den Bestätigungsfehler.
Es macht jegliche Entwicklertests überflüssig
Falsch — Entwickler-(Komponenten-)Tests bleiben wertvoll und notwendig.
Es garantiert, dass alle Fehler gefunden werden
Falsch — kein Ansatz garantiert das Finden aller Fehler.
Unabhängige Tester erkennen oft andere Arten von Fehlerwirkungen und unterliegen weniger den Annahmen des Autors. Unabhängigkeit ersetzt weder Entwicklertests noch garantiert sie das Finden aller Fehler.
Welches ist das BESTE Beispiel für eine geeignete Risikominderungsmaßnahme des Testens bei einem identifizierten Produktrisiko?
Zusätzliche, strengere Tests für die hochriskante Funktion entwerfen.
Richtig — gezieltes Testen mindert das Risiko.
Mehr Entwickler für das nächste Projekt einstellen.
Eine allgemeine Personalmaßnahme.
Das Risiko ignorieren, weil der Termin knapp ist.
Ignorieren ist keine Minderung.
Das Testen der hochriskanten Funktion kürzen.
Das erhöht das Risiko.
Das Testen mindert Produktrisiken durch gezielte Tests und strengere Techniken bei hohem Risiko.
Ein Team führt bei jedem Build eine große Suite stabiler, sich wiederholender Regressionstests aus. Was ist ein zentraler Vorteil der Automatisierung dieser Tests?
Weniger wiederkehrender manueller Aufwand und schnelleres, konsistentes Feedback
Richtig — Automatisierung wiederholt stabile Tests effizient und meldet konsistent.
Es garantiert, dass die Software fehlerfrei ist
Falsch — Automatisierung führt Tests aus, garantiert aber keine Fehlerfreiheit.
Es macht jeglichen Testentwurf überflüssig
Falsch — Tests müssen weiterhin entworfen werden; Automatisierung führt sie nur aus.
Sie ist kurzfristig immer billiger als manuelles Testen
Falsch — Automatisierung hat erhebliche Anfangs- und Wartungskosten.
Automatisierung eignet sich für wiederholbare, stabile Tests: Sie reduziert wiederkehrenden manuellen Aufwand und liefert schnelles, konsistentes Feedback.
Welche der folgenden sind echte RISIKEN oder Herausforderungen bei der Einführung eines Testautomatisierungswerkzeugs? (Wählen Sie ZWEI.)
Den Aufwand für die Wartung der automatisierten Tests unterschätzen
Richtig — die Wartung automatisierter Tests ist ein bekanntes, oft unterschätztes Risiko.
Unrealistische Erwartungen an die Möglichkeiten des Werkzeugs
Richtig — überzogene Erwartungen und Überverlass sind anerkannte Risiken.
Das Werkzeug definiert automatisch die Teststrategie
Falsch — ein Werkzeug definiert keine Strategie; das bleibt menschliche Aufgabe.
Der Kauf eines Werkzeugs verbessert die Produktqualität immer von allein
Falsch — Qualität entsteht durch gute Testpraxis, nicht durch den Besitz eines Werkzeugs.
Echte Risiken sind das Unterschätzen des Aufwands für Einführung und Wartung sowie überzogene Erwartungen an das Werkzeug. Ein Werkzeug ersetzt keine Teststrategie und verbessert die Produktqualität nicht von allein.