Kapitel 4 handelt von der Suite, die Sie in einem halben Jahr noch ändern können: Page Object Model, Trennung von Testdaten und Testlogik, unabhängige und lesbare Tests, Ursachen von Flakiness sowie Logging und Reporting. A4Q veranschlagt hier 150 Unterrichtsminuten.
Das ist das Kapitel, das Leute, die etwas automatisiert haben, von Leuten unterscheidet, die das Automatisierte auch gepflegt haben. Die Fragen zielen weniger auf Syntax als auf Folgen: ein Szenario wird beschrieben, und Sie sagen, was später wehtut.
Wo Punkte verloren gehen:
Was eine Page-Object-Methode zurückgibt. Eine Methode, die eine Navigation abschließt, gibt das Page Object der Zielseite zurück — ein login(), das auf dem Dashboard endet, liefert eine DashboardPage, nicht void und keinen Boolean.
Zusicherungen gehören nicht ins Page Object. Ein Page Object stellt Zustand und Aktionen bereit; was richtig ist, entscheidet der Test. Die Vermischung ist die häufigste falsche Option in diesem Bereich.
Locator mehrfach über die Tests verstreut. Ein Selektor gehört an genau eine Stelle. Ändert sich die Seite, wollen Sie eine Änderung vornehmen und nicht die Suite durchsuchen.
Tests, die voneinander abhängen. Wenn Test B den Datensatz aus Test A braucht, läuft die Suite nicht parallel, nicht teilweise, und fällt in einer Kaskade aus, die die eigentliche Ursache verdeckt.
Nicht jede Flakiness ist ein Timing-Fehler im eigenen Code. Ein Test, der lokal läuft und auf einem ausgelasteten geteilten CI-Agenten fällt, deutet auf die Umgebung — und die Lösung ist ein richtiger expliziter Wait, kein längeres Sleep und kein Retry.
Reporting ist Teil der Wartbarkeit. Ein Fehlschlag, der nur „assertion failed“ sagt, kostet eine Stunde Suche; eine Logzeile und ein Screenshot im Moment des Fehlschlags kosten nichts.
Dieses Kapitel wird am stärksten abgedeckt (13 Fragen) in A4Q Selenium Tester — Probeprüfung 6 (Waits, Synchronisation & Teststabilität)