Testen [Technik]

6 Übungsfragen mit Lösung und Erklärung.

☝️ SingleWas beschreibt die Testpyramide?
❌Eine Reihenfolge, in der Tests innerhalb eines Sprints geschrieben werden
✅Viele schnelle Unit-Tests als Basis, weniger Integrationstests darüber, wenige langsame End-to-End-Tests an der Spitze
❌Die Aufteilung der Testarbeit auf Junior- und Senior-Entwickler
❌Ein Modell zur Priorisierung von Fehlern nach Schweregrad
Die umgekehrte Form – viele langsame Oberflächentests, wenige Unit-Tests – heißt Eiswaffel (Ice Cream Cone) und gilt als Anti-Pattern: Die Rückmeldung kommt spät und die Tests sind unzuverlässig.
☝️ SingleWelche Reihenfolge beschreibt Test-Driven Development (TDD)?
❌Implementieren – Testen – Dokumentieren
❌Refactor – Red – Green
❌Analysieren – Entwerfen – Programmieren – Testen
✅Red – Green – Refactor: erst einen fehlschlagenden Test schreiben, dann die einfachste Lösung, dann aufräumen
Der dritte Schritt wird am häufigsten weggelassen und ist der wichtigste: Ohne das Refactoring entsteht funktionierender, aber schwer wartbarer Code.
☝️ SingleWas unterscheidet Acceptance Test-Driven Development (ATDD) von klassischem TDD?
❌Die Verfahren sind gleichbedeutend
❌ATDD wird erst nach der Implementierung durchgeführt
❌ATDD verzichtet vollständig auf Automatisierung
✅ATDD setzt an den fachlichen Akzeptanzkriterien an und wird gemeinsam mit Product Owner und Fachseite formuliert, TDD arbeitet auf technischer Einheitenebene
Der eigentliche Gewinn von ATDD liegt im Gespräch vor der Umsetzung: Wer ein Akzeptanzkriterium als Beispiel ausformulieren muss, entdeckt Unklarheiten, die in der Beschreibung unsichtbar bleiben.
✌️ MultiWelche Aussagen zu automatisierten Tests im Scrum-Kontext treffen zu? (Mehrere richtig)
✅Ihre Erstellung gehört zur Arbeit am Backlog-Eintrag, nicht in ein separates Testprojekt.
✅Sie ermöglichen risikoarmes Refactoring, weil Regressionen sofort auffallen.
✅Sie sind die Voraussetzung dafür, in jedem Sprint ein potenziell nutzbares Increment zu liefern.
❌Sie ersetzen manuelles exploratives Testen vollständig.
Automatisierte Tests prüfen, was jemand vorher bedacht hat. Exploratives Testen findet genau das, was niemand bedacht hat – beides deckt unterschiedliche Fehlerklassen ab.
☝️ SingleWas ist ein "flaky test" und warum ist er gefährlich?
❌Ein Test, der zu lange läuft und deshalb übersprungen wird
❌Ein Test, der von einem Junior-Entwickler geschrieben wurde
❌Ein Test ohne Zuordnung zu einem Akzeptanzkriterium
✅Ein Test, der bei unverändertem Code mal fehlschlägt und mal durchläuft – er zerstört das Vertrauen in die gesamte Testsuite
Die eigentliche Gefahr ist die Gewöhnung: Sobald ein Team rote Tests als "vermutlich wieder das Flackern" abtut, übersieht es auch die echten Fehlschläge.
✍️ OffenEin Team hat kaum automatisierte Tests und eine gewachsene Codebasis. Beschreiben Sie ein realistisches Vorgehen zum Aufbau einer Testabdeckung.
Musterantwort: Der Versuch, die bestehende Codebasis flächendeckend nachträglich mit Tests zu versehen, scheitert in der Regel an Aufwand und Motivation. Realistisch ist ein risikoorientiertes, schrittweises Vorgehen. Zunächst wird ermittelt, wo Fehler tatsächlich auftreten und wo Änderungen am häufigsten stattfinden; die Schnittmenge aus beidem ist der Bereich mit dem höchsten Nutzen je investierter Stunde. Dort beginnt der Aufbau. Als Zweites gilt die Regel, dass jede neue oder geänderte Funktionalität ab sofort mit Tests entsteht. Damit wächst die Abdeckung genau dort, wo gearbeitet wird, ohne dass ein separates Testprojekt nötig wäre. Diese Regel gehört in die Definition of Done, sonst weicht sie unter Termindruck auf. Als Drittes werden vor größeren Umbauten zunächst sogenannte Charakterisierungstests geschrieben, die das heutige Verhalten festhalten, auch wenn es nicht das gewünschte ist; sie sind die Voraussetzung für risikoarmes Refactoring. Als Viertes wird auf die richtige Ebene geachtet: Viele schnelle Tests auf Einheitenebene, wenige auf der Oberfläche, weil langsame und instabile Tests die Akzeptanz zerstören. Parallel dazu muss der Build zuverlässig und schnell sein, sonst werden Tests umgangen. Wichtig ist schließlich die Erwartungssteuerung gegenüber dem Product Owner: Der Aufbau verlangsamt das Team anfangs sichtbar und zahlt sich erst nach mehreren Sprints aus. Ohne diese Vereinbarung wird das Vorhaben beim ersten Termindruck abgebrochen.
← Alle ThemenIm Quiz üben