Die altbekannte Methode Debug.Assert() bietet eine kleine Verbesserung in .NET 9.0: Beim Fehlschlagen der übergebenen Bedingung sehen Entwicklerinnen und Entwickler in der Ausgabe die komplette fehlgeschlagene Bedingung.

So kam beispielsweise bei

var x = 42;
var y = 42;
…
Debug.Assert(x > 0 && y < 0);

vor .NET 9.0 diese Nachricht:

Assertion failed.
at Program.SomeMethod(Int32 a, Int32 b)

Nun sehen Entwicklerinnen und Entwickler seit .NET 9.0 eine ausführlichere Information:

Assertion failed.
x > 0 && y < 0
at Program.SomeMethod(Int32 a, Int32 b)

Damit dies funktioniert, gibt es eine neue Überladung der Methode Debug.Assert() mit der Annotation [CallerArgumentExpression] vor dem zweiten Parameter:

public static void Assert([DoesNotReturnIf(false)] bool condition, 
  [CallerArgumentExpression("condition")] string? message = null);

Vor .NET 9.0 konnte man dies nur erreichen, indem man die Bedingung noch einmal explizit als Zeichenkette angab:

Debug.Assert(x > 0 && y < 0, "x > 0 && y < 0");

(rme)

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)