Software Testing & Qualität - Testautomatisierung, KI & Agilität

Hundert End-to-End-Tests auf ein neues Gerät bringen, ohne einen einzigen anzufassen: Dafür hat Max Stahlschmidt das Open-Source-Python-Test-Framework Balder gebaut. Mit ihm spreche ich darüber, warum bewährte Frameworks bei Produktvarianten an ihre Grenzen stoßen, wie Balder die abstrakte Testlogik in Szenarien von der Implementierung in Setups trennt und warum er es nicht auf Pytest aufgesetzt hat. Sein Beispiel: ein Herzfrequenz-Brustgurt und eine Pulsuhr, die optisch statt elektrisch misst, und trotzdem reichten zwei getauschte Features. Dazu BalderHub-Pakete für Web-Tests, JUnit-Reporting per Plugin und die Suche nach Mitentwicklern, weil der Kern bis heute Handarbeit ist.

DAST landet bei Daniel Schmuck auf dem Tisch, weil die DORA-Verordnung Banken und Versicherungen zu Sicherheitstests verpflichtet. Mit ihm spreche ich darüber, wie ZAP als Proxy zwischen Regressionstest und Anwendung sitzt: Erst lernt es aus Playwright- oder Selenium-Läufen den normalen Verkehr kennen, dann fährt es selbst Angriffe wie SQL-Injection und Cross-Site-Scripting. Wir reden über Jenkins-Pipelines, Prüfregeln als Plug-ins mit Updates alle zwei Wochen und darüber, was der erste Report gezeigt hat. Am Ende geht es um die Frage, wie Meldungen aus Pentest, DAST und Infrastrukturscan zusammenkommen, ohne dass Entwickler dieselbe Ursache dreimal gemeldet bekommen.

Ein Lasttest ohne Frage dahinter ist verschwendete Lebenszeit, sagt Stephan Schwarz, und genau darüber spreche ich mit ihm: Lasttests in Kubernetes-Umgebungen, die eine Risikofrage beantworten und eine Entscheidung vorbereiten. Stephan erklärt, warum Dev, Ops und QA dafür an einen Tisch müssen: Kein Team allein weiß, wie sich die Software unter Last verhält. Wir reden über Laborsetups, in denen Autoscaling und Load Balancing erst mal zurückgefahren werden, über Lastgeneratoren wie k6 oder Locust und über seinen ersten Test 2018, bei dem der limitierende Faktor sein eigenes Notebook war. Und darüber, dass jedes System ein Bottleneck hat, auch wenn es noch keiner gefunden hat.

Ob ein Kernel auf jeder CPU-Generation läuft, zeigt erst die echte Hardware. Genau dafür hat Markus Napierkowski mit seinem Team ein Hardware-in-the-Loop-Framework gebaut, das seit zwei Monaten Open Source auf GitHub liegt, und darüber spreche ich mit ihm auf der TACON in Leipzig. Entwickler und CI reservieren sich dieselben Testmaschinen über eine REST API, sauber initialisiert, als stünden sie neben dem Schreibtisch. An jeder Maschine hängt ein Raspberry Pi für USB, HDMI und serielle Konsole, eine neue Hardware ist auf der Softwareseite fünf Zeilen Code im Nix-Repository. Mich hat vor allem gefreut, dass hier jemand ein über Jahre gewachsenes Werkzeug zurück an die Community gibt.

Was taugen Tests, die 100 Prozent Coverage liefern, aber keine einzige Assertion enthalten? Mit Julius Mischok spreche ich über Mutation Testing: Ein Tool baut absichtlich Fehler in den Produktionscode ein, dreht Bedingungen um oder setzt Rückgabewerte auf Standardwerte und prüft dann, ob die Tests anschlagen. Bleiben sie grün, hat die Mutation überlebt und der Test ist wenig wert. Julius erklärt, warum diese alte Idee gerade jetzt zurückkommt, wo Agenten massenhaft Tests schreiben, die kaum jemand wirklich in der Tiefe liest.