Erst die Software entwickeln und das Ergebnis testen – das funktioniert nicht mehr. Die Qualitätssicherung beginnt heute frühzeitig im Entwicklungsprozess und benötigt gute Testmanagement-Tools. Aber wo trennt sich die Spreu vom Weizen? Wie findet man die Tools, die nicht bremsen, sondern unterstützen? Unser Titelautor Waldemar Klassen erklärt, wie sich der Markt entwickelt hat und worauf es ankommt.

Was sollte ein zeitgemäßes Testmanagement-Tool mitbringen?

Die Grundanforderungen haben sich nicht stark verändert. Testfälle verwalten, Ergebnisse dokumentieren, Anforderungsbezug sicherstellen. Was sich aber verändert hat, ist das Umfeld. Teams arbeiten heute iterativ, oft verteilt und mit vielen Tools parallel. Ein Testmanagement-Tool muss deshalb anschlussfähig sein, quasi ein Integrationshub. Das heißt einerseits technisch über Schnittstellen und andererseits organisatorisch den Prozess abdecken. Denn was ich beobachte, ist, dass die Tool-Landschaft fragmentierter wird. An sich kein Problem, wenn die Testprozesse ebenfalls hybrid werden und das Testmanagement-Tool andockfähig ist.

Wenn ich es jetzt in einem Satz beantworten soll: In DevOps-Umgebungen kommt es auf Echtzeit-Transparenz, offene Schnittstellen und eine stabile API an. Und gute Tools denken den gesamten Dev-Prozess mit, nicht nur das Testen.

Wie haben sich DevSecOps-Ansätze, die Security im Entwicklungsprozess von Anfang an mitdenken, auf Testabläufe und die Tools dafür ausgewirkt?

Security ist vom Rand in den Kern gerückt. Tests für Sicherheitsanforderungen, Compliance-Vorgaben oder Audits sind keine nachgelagerten Aktivitäten mehr, sondern integraler Bestandteil von Release-Zyklen. Testmanagement-Tools müssen also in der Lage sein, auch Security-Scans, statische Codeanalysen oder Schwachstellenprüfungen zu erfassen und nachvollziehbar zu dokumentieren. Wer heute DevSecOps ernst meint, braucht auch ein Testmanagement, das klassische Funktionstests mit Security-Anforderungen zusammenbringt. Einige Anbieter gehen inzwischen weiter und verknüpfen Findings aus SAST- oder DAST-Tools direkt mit dem Teststatus. Das funktioniert technisch aber nur wenn der Integrationsgedanke gelebt wird und kein Reibungskampf zwischen den Security- und Dev-Tools vorherrscht.

Gefühlt wird künstliche Intelligenz derzeit in so ziemlich jede Software integriert – welche Rolle spielt sie in diesem Bereich?

Noch eine zu starke Nebenrolle, wie ich finde, aber mit viel Potenzial. Testfälle automatisch vorzuschlagen, Logs zu analysieren oder Priorisierungen vorzunehmen – das erleichtert die Arbeit und steigert die Effizienz. Das funktioniert auch in vielen Pilotprojekten bereits, skaliert aber noch nicht flächendeckend. Die Anbieter sind da unterschiedlich weit. Viele arbeiten an KI-Funktionen, aber eher im Hintergrund. Die Dev-Teams sind zwar offen dafür, haben jedoch auch immer Sorgen, dass sie nicht mehr benötigt werden.

Ich finde, KI ohne Mensch dahinter funktioniert nicht und ist ein Werkzeug zur Unterstützung. „Nicht ersetzen, sondern entlasten“, ist meine Einstellung dazu, wie in der Marktübersicht auch gezeigt. Dazu zählt etwa das Auffinden redundanter Tests oder die Auswertung von Ergebnissen. Die Umsetzung und das Qualitätsmanagement bleiben beim Entwickler.

Herr Klassen, vielen Dank für die Antworten! Interessierte Leser finden im Titel der neuen iX alles zum Testmanagement: Wir beleuchten, was gutes Testmanagement ausmacht, zeigen in einer umfangreichen Marktübersicht, welche Software fürs Testmanagement es gibt, und erklären anhand des Open-Source-Tools TestLink, wie modernes Testmanagement funktioniert. Das August-Heft ist ab sofort im heise shop und am Kiosk erhältlich.

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(fo)

Wer den Sourcecode-Editor Zed verwendet, kann künftig mit einer Einstellung alle KI-Funktionen ausschalten. Damit reagieren die Projektverantwortlichen auf Wünsche aus der Community.

Das Team hinter dem Open-Source-Editor hatte im Mai 2025 in einem Blogbeitrag Zed zum schnellsten KI-Code-Editor erklärt. Zed ist von Grund auf in Rust geschrieben und seit Januar 2024 als Open-Source-Projekt unter GPL-Lizenz verfügbar. Seine Anfänge lagen auf macOS, im Juli 2024 folgte Linux und eine offizielle Windows-Version ist ebenfalls in Planung.

KI-Editor ohne KI

Auch wenn die oft nützlichen KI-Hilfen inzwischen für viele zum Alltag der Softwareentwicklung gehören, gibt es berechtigte Bedenken bezüglich der Codequalität und potenziell generierter Schwachstellen oder wegen der Daten und des Sourcecodes, die beim Einsatz der KI-Tools das Unternehmen verlassen.

Im GitHub-Repository des Editors finden sich bereits seit 2024 Diskussionen und Issues, die einen Ausschalter für KI-Funktionen wünschen.

Nun haben die Projektverantwortlichen reagiert und in der aktuellen Preview eine Einstellung in der settings.json-Datei eingeführt, die sämtliche KI-Funktionen deaktiviert:

{
  "disable_ai": true
}

In Kürze ist zusätzlich ein Switch in den KI-Einstellungen innerhalb der UI des Editors geplant, der ebenfalls alle KI-Funktionen abschaltet.

Datenschutz trotz KI

Der Blogbeitrag zum Deaktivieren der KI-Funktionen betont, dass diejenigen, die vor allem Bedenken bezüglich des Datenschutzes haben, die KI-Funktionen nicht unbedingt deaktivieren müssen.

Zed lässt bei der Auswahl des KI-Anbieters freie Wahl und ermöglicht auch den Einsatz lokaler KI-Modelle mittels Ollama, damit der Code und die Daten den Rechner nicht verlassen.

Weitere Details zu den Hintergründen lassen sich dem Zed-Blog entnehmen.

(rme)

Events sind die Grundlage von Event-getriebener Architektur (Event-Driven Architecture, kurz EDA). Sie dokumentieren, was passiert ist, und sind damit die zentrale Wahrheit eines Systems. Doch gerade weil sie so zentral sind, ist es entscheidend, sie richtig zu gestalten und zu verarbeiten.

In diesem Teil werfen wir einen Blick auf Eigenschaften guter Events, häufige Stolperfallen – und auf technische Fragen, die zwar oft diskutiert werden, aber selten kritisch sind.

Zustandsübergänge statt Snapshots

Ein Event ist kein Snapshot. Es beschreibt nicht, wie etwas aussieht, sondern was passiert ist. Das ist ein fundamentaler Unterschied.

Beispiel: Nicht „Buch hat Status ‚verliehen'“, sondern „Buch wurde verliehen“. Der Unterschied mag subtil erscheinen, hat aber weitreichende Folgen:

• Ein Snapshot ist immer nur ein Bild des Jetzt, ein Event beschreibt den Weg dorthin.
• Snapshots überschreiben, Events bauen aufeinander auf.
• Snapshots verlieren Kontext, Events bewahren Historie.

Wer den Zustand eines Systems nur über Snapshots betrachtet, kann später nicht mehr nachvollziehen, wie dieser Zustand entstanden ist – und verliert so viel von dem, was Event-getriebene Systeme eigentlich auszeichnet.

Reihenfolge ist selten kritisch – aber Kontext schon

Ein häufiges Missverständnis: Die Reihenfolge von Events sei absolut entscheidend. In der Realität ist das meistens nicht der Fall.

Wenn man einen konkreten Zustand berechnen möchte („Wie ist der heutige Kontostand?“), braucht man die Events in der richtigen Reihenfolge, zumindest innerhalb des betroffenen Kontos. Aber bei reinen Reaktionen auf Events – etwa beim Erzeugen von Projections oder beim Triggern von Folgeaktionen – ist es oft egal, wann das Event eintrifft. Entscheidend ist, ob es überhaupt ankommt und ob es korrekt verarbeitet wird.

Das heißt nicht, dass Reihenfolge nie eine Rolle spielt. Aber wer sich zu sehr darauf versteift, macht Systeme unnötig fragil. Robuste Event-getriebene Systeme setzen auf:

• Idempotenz: Mehrfache Verarbeitung darf keinen Schaden anrichten.
• Vollständigkeit: Alle relevanten Events müssen verarbeitet werden.
• Korrekte Kontextgrenzen: Innerhalb eines Event-Streams kann Reihenfolge wichtig sein – darüber hinaus meist nicht.

Konsistenz ist eine Frage der Perspektive

In klassischen Systemen ist Konsistenz eine binäre Eigenschaft: Entweder ist das System konsistent oder nicht. In Event-getriebenen Systemen ist das differenzierter.

Statt globaler Transaktionen (Atomicity, Consistency, Isolation, Durability – ACID) gibt es lokale Konsistenz innerhalb von Aggregaten. Übergreifend wird mit schlussendlicher Konsistenz (Eventual Consistency) gearbeitet: Zustände dürfen kurzfristig auseinanderlaufen, solange sie sich mittelfristig wieder angleichen.

Das erfordert ein Umdenken, aber es bringt auch Vorteile:

• Systeme werden entkoppelt und robuster gegenüber Teilausfällen.
• Skalierung wird einfacher, weil nicht alles synchronisiert werden muss.
• Fachlich lässt sich oft gut begründen, warum leichte Verzögerungen akzeptabel sind.

Beispiel: Ein Benutzer hat ein Buch zurückgegeben. Die Rückgabe wird sofort im Ausleihsystem vermerkt. Dass die Mahngebühr erst fünf Sekunden später als „storniert“ markiert wird, ist in den allermeisten Fällen tolerierbar.

Was Events leisten müssen – und was nicht

Ein gutes Event

• ist eindeutig benannt, fachlich korrekt und stabil,
• dokumentiert eine Tatsache, keinen Wunsch oder Zwischenzustand,
• trägt nur die Information, die für die Reaktion nötig ist, und nicht den gesamten Systemzustand, und
• wird gespeichert, veröffentlicht und verarbeitet, aber nie geändert.

Was es nicht leisten muss:

• Es muss nicht alle Informationen enthalten, oft reicht stattdessen ein Verweis (zum Beispiel die ID).
• Es muss nicht für jede Zielgruppe perfekt sein, da Projections Informationen aufbereiten können.
• Es muss nicht „alles auf einmal“ ermöglichen – lieber kleine, gezielte Events als große, unübersichtliche Payloads.

Was kommt als Nächstes?

Im nächsten Teil steigen wir in ein praktisches Beispiel ein: eine Stadtbibliothek. Wir schauen uns an, wie man mit Events denkt, Abläufe modelliert und ein System Stück für Stück aufbaut – ohne sich in technischen Details zu verlieren.

(mai)