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

Testpyramide - ein kritischer Blick - Ronald Brill

Listen Later
Warum die Pyramide oft nicht passt

📌 Konferenz-Tipp: TACON 2026 in Leipzig (16.–17. September). Ich war letztes Jahr als Keynote dort und fand den Austausch richtig gut 👉 https://swt.fm/tacon

„Unit-Tests haben so einen gewissen Suchtfaktor." - Ronald Brill

Die Testpyramide kennen alle, jeder hat sofort ihr Bild vor Augen. Mal hat sie drei Stockwerke, manchmal vier. Doch es ist eine Überlegung wert, ob sie nicht langsam ausgedient hat. Z.B. ist es sinnvoll, den Fokus bei Tests von Microservice-Architekturen anders zu legen. Braucht man immer viele Unittests? Vielleicht nicht! Und: Unittests machen süchtig! Ronald erzählt uns seine Sichtweise auf dieses "Pauschal-Angebot" der Testpyramide.

Ronald Brill entwirft, implementiert und testet seit über 30 Jahren Software. Parallel zu seiner Arbeit als Principal bei der GEBIT Solutions GmbH beschäftigt er sich seit mehr als 10 Jahren mit dem Testen von Web-Anwendungen und hat mit Wetator und BingoBongoTesting Testwerkzeuge entwickelt. Er ist Maintainer von HtmlUnit und Committer bei verschiedenen weiteren Open Source Projekten.

Highlights:

  • Die Testpyramide wurde nicht erfunden, um möglichst viele Unit-Tests zu fordern, sondern um Testschichten so aufzubauen, dass sie sich gegenseitig ergänzen und keine Anforderung doppelt abgedeckt wird.
  • Wer Unit-Tests auf Basis falscher Abstraktionen schreibt, muss beim Refactoring nicht nur den Produktionscode, sondern auch die gesamte Testsuite anpassen, was den vermeintlichen Effizienzgewinn zunichtemacht.
  • In Microservice-Architekturen sind viele Tests, die mit JUnit geschrieben werden, faktisch Integrationstests, weil sie Controller und Service-Schichten gemeinsam prüfen, nicht einzelne Units.
  • Hohe Code-Coverage ist kein Qualitätsbeweis: Fehler entstehen oft im Zusammenspiel der Komponenten, nicht innerhalb einer einzelnen Unit, die ein Test isoliert abdeckt.
  • Architekturentscheidungen werden zu oft im testfreien Raum getroffen; eine vollständige Architekturbegründung sollte immer auch erklären, wie das System testbar bleibt.

    • Danke an die Community-Partner des Podcasts:Alliance for Qualification | ASQF | Austrian Testing Board | dpunkt.verlag | German Testing Board | German Testing Day | GI Fachgruppe TAV | Heise | HANSER Verlag | ISTQB | iSQI GmbH | oop | QS-TAG | SIGS-DATACOM | skillsclub | Swiss Testing Board | TACON Credits: Sound | Grafik

    ...more
    View all episodesView all episodes
    Download on the App Store
    Software Testing & Qualität - Testautomatisierung, KI & AgilitätBy Richard Seidl - Experte für Software-Entwicklung und Testautomatisierung