Connect with us

Entwicklung & Code

Drei Fragen und Antworten: Welche Testmanagement-Tools lohnen sich?


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.


Waldemar Klassen

Waldemar Klassen

Waldemar Klassen ist Analyst bei der techconsult GmbH, einem Unternehmen der Heise Group, und beschäftigt sich mit den Themenfeldern IoT, Big Data, digitale Nachhaltigkeit (CSR/ESG) und SAP S/4HANA.

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)



Source link

Entwicklung & Code

Bestie statt for-Schleife: KI entwickelt Programmiersprache im Gen-Z-Slang


Damn, das ist cringe: Der Australier Geoffrey Huntley hat die Programmier-KI Claude Code von Anthropic drei Monate in Dauerschleife laufen lassen, um eine eigene Programmiersprache im Stile der verbreiteten Umgangssprache der Generation Z zu entwerfen. Und warum? Nun, weil er es kann, wie er in einem Blogpost darlegt.


WTF

WTF

Das Internet ist voll von heißen IT-News und abgestandenem Pr0n. Dazwischen finden sich auch immer wieder Perlen, die zu schade sind für /dev/null.

Tatsächlich habe ihn einfach die Möglichkeit gereizt, dass mithilfe generativer KI der Traum vom eigenen Compiler Gestalt annehmen kann, schreibt er. Das Ganze sei dann auch ein Lernexperiment gewesen. Der KI sei es dabei selbst überlassen worden, die Sprache jeweils weiter zu verbessern. Das Ergebnis hat er sogar auf einer eigenen Website zum Download bereitgestellt. Der Name der Programmiersprache: Cursed (auf deutsch: verflucht).

Der Compiler verfügt über zwei Modi. Er kann als Interpreter oder als Compiler eingesetzt werden und Binärdateien für macOS, Linux und Windows erstellen. Zudem gebe es halbfertige Erweiterungen für die Editoren VSCode, Emacs und Vim. Wer sich den Entstehungsprozess anschauen möchte, findet dazu entsprechende Videos bei YouTube.

Sprachlich darf man sich das so vorstellen, dass an die Stelle von bekannten Begriffen wie for oder case Wörter treten, die in der GenZ gerne benutzt werden, wie etwa bestie oder mood. Eine Roadmap zur Weiterentwicklung gebe es nicht, darüber soll die Community entscheiden.

Der ursprüngliche Prompt lautete: „Hey, kannst du mir eine Programmiersprache wie Golang erstellen, bei der jedoch alle lexikalischen Schlüsselwörter ausgetauscht sind, sodass sie dem Slang der Generation Z entsprechen?“

Wer dem Beispiel von Huntley folgen möchte, sollte allerdings das nötige Kleingeld bereithalten. Der eigene Compiler koste einen etwa 5000 US-Dollar, schreibt er in einem Post auf X. Tatsächlich habe er mit 14.000 US-Dollar fast das Dreifache investieren müssen, da Cursed zunächst in C, dann in Rust und jetzt in Zig entwickelt wurde. Aber so gebe es jetzt eben auch drei Editionen des Compilers. Und am Ende sei das nur ein Vierzehntel des Gehalts eines Entwicklers in San Francisco, scherzt er.


(mki)



Source link

Weiterlesen

Entwicklung & Code

MCP Registry gestartet: Katalog für MCP-Server


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Das Entwicklungsteam hinter dem Model Context Protocol (MCP) hat die MCP Registry als Preview eingeführt – einen offenen Katalog und eine API, um öffentlich verfügbare MCP-Server ausfindig zu machen und zu verwenden. Bei MCP handelt es sich um ein offenes Protokoll für den Zugriff von Large Language Models (LLMs) auf externe Datenquellen.

Bereits vor einigen Monaten teilte das MCP-Team auf GitHub mit, an einem zentralen Register für das MCP-Ökosystem zu arbeiten. Die nun veröffentlichte, quelloffene MCP Registry soll das Verfahren standardisieren, wie MCP-Server verteilt und entdeckt werden. Sie bietet Server-Maintainern die Möglichkeit, ihre Server hinzuzufügen, und Client-Maintainern, auf Serverdaten zuzugreifen.

Um der Registry einen Server hinzuzufügen, muss dieser auf einer Package Registry wie npm, PyPI oder DockerHub veröffentlicht sein. Eine detaillierte Anleitung findet sich auf GitHub. Dort erfahren Developer, wie sie eine server.json-Datei für ihren Server erstellen, Authentifizierung mit der Registry erreichen, ihren Server veröffentlichen und die Veröffentlichung verifizieren können.

Wie das MCP-Team betont, soll das zentrale Register als hauptsächliche Source of Truth für öffentlich verfügbare MCP-Server dienen, jedoch den bereits bestehenden Registries von Community und Unternehmen nicht im Weg stehen. Diese können in der MCP Registry öffentliche oder private Sub-Registries anlegen, wie das MCP-Team auf GitHub beschreibt.

Bereits existierende Sammlungen sind etwa eine lange, gepflegte Liste auf GitHub und ein Docker-Verzeichnis für MCP-Quellen.

Da es sich bei der MCP Registry derzeit um eine Preview handelt, gibt es keine Garantie für die Beständigkeit der darin enthaltenen Daten. Auch sind Breaking Changes möglich, bevor die Registry die allgemeine Verfügbarkeit erreicht.

Weitere Informationen sind auf dem MCP-Blog zu finden.


(mai)



Source link

Weiterlesen

Entwicklung & Code

KI-Überblick 4: Deep Learning – warum Tiefe den Unterschied macht


Die bisherigen Beiträge dieser Serie haben gezeigt, dass neuronale Netze aus einfachen Bausteinen bestehen. Erst die Kombination vieler dieser Bausteine in mehreren Schichten ermöglicht jedoch die Durchbrüche, die moderne KI-Systeme prägen. Genau hier setzt das Konzept „Deep Learning“ an: Es beschreibt maschinelles Lernen mit tiefen, also mehrschichtigen, neuronalen Netzen.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Deser Beitrag klärt, was „tief“ im Kontext neuronaler Netze bedeutet, warum zusätzliche Schichten die Leistungsfähigkeit erhöhen und welche typischen Architekturen in der Praxis verwendet werden.

Von Deep Learning spricht man, wenn ein neuronales Netz mehrere verborgene Schichten enthält – in der Regel deutlich mehr als zwei oder drei. Jede Schicht abstrahiert die Ausgaben der vorherigen Schicht und ermöglicht so, komplexe Funktionen zu modellieren. Während einfache Netze vor allem lineare und leicht nichtlineare Zusammenhänge erfassen, können tiefe Netze hochdimensionale Strukturen und Muster erkennen.

Die Entwicklung hin zu tieferen Netzen wurde erst durch drei Faktoren möglich:

  1. Stärkere Rechenleistung – insbesondere durch Grafikkarten (GPUs) und später spezialisierte Hardware wie TPUs.
  2. Größere Datenmengen, die zum Training genutzt werden können.
  3. Verbesserte Trainingsverfahren, darunter die Initialisierung von Gewichten, Regularisierungstechniken und optimierte Aktivierungsfunktionen.

Ein Kernprinzip des Deep Learning ist die hierarchische Merkmalsextraktion. Jede Schicht eines tiefen Netzes lernt, auf einer höheren Abstraktionsebene zu arbeiten:

  • Frühe Schichten erkennen einfache Strukturen, zum Beispiel Kanten in einem Bild.
  • Mittlere Schichten kombinieren diese zu komplexeren Mustern, etwa Ecken oder Kurven.
  • Späte Schichten identifizieren daraus ganze Objekte wie Gesichter, Autos oder Schriftzeichen.

Diese Hierarchiebildung entsteht automatisch aus den Trainingsdaten und macht Deep Learning besonders mächtig: Systeme können relevante Merkmale selbst entdecken, ohne dass Menschen sie mühsam vordefinieren müssen.

Im Deep Learning haben sich verschiedene Architekturen etabliert, die für bestimmte Datenarten optimiert sind.

Convolutional Neural Networks (CNNs) sind spezialisiert auf Bild- und Videodaten. Sie verwenden Faltungsschichten („Convolutional Layers“), die lokale Bildbereiche analysieren und so translationinvariante Merkmale lernen. Ein CNN erkennt beispielsweise, dass ein Auge im Bild ein Auge bleibt, egal wo es sich befindet. CNNs sind der Standard in der Bildklassifikation und Objekterkennung.

Recurrent Neural Networks (RNNs) wurden entwickelt, um Sequenzen wie Text, Sprache oder Zeitreihen zu verarbeiten. Sie besitzen Rückkopplungen, durch die Informationen aus früheren Schritten in spätere einfließen. Damit können sie Zusammenhänge über mehrere Zeitschritte hinweg modellieren. Varianten wie LSTMs (Long Short-Term Memory) und GRUs (Gated Recurrent Units) beheben typische Probleme wie das Vergessen relevanter Informationen.

Autoencoder sind Netze, die Eingaben komprimieren und anschließend wieder rekonstruieren. Sie lernen dabei implizit eine verdichtete Repräsentation der Daten und werden etwa für Anomalieerkennung oder zur Vorverarbeitung genutzt. Erweiterte Varianten wie Variational Autoencoders (VAE) erlauben auch generative Anwendungen.

Diese Architekturen bilden die Grundlage vieler moderner KI-Anwendungen. Sie sind jedoch noch nicht der Endpunkt: In den letzten Jahren haben Transformer klassische RNNs in vielen Bereichen abgelöst, insbesondere in der Sprachverarbeitung. Darum wird es in einer späteren Folge dieser Serie gehen.

Tiefe Netze sind leistungsfähig, bringen aber neue Herausforderungen mit sich:

  • Großer Datenhunger: Ohne ausreichend Trainingsdaten tendieren tiefe Modelle zum Überfitting.
  • Rechenintensiv: Training und Inferenz erfordern spezialisierte Hardware und hohe Energieaufwände.
  • Schwer erklärbar: Mit wachsender Tiefe nimmt die Nachvollziehbarkeit weiter ab, was für viele Anwendungsbereiche problematisch ist.

Trotzdem hat sich Deep Learning als Schlüsseltechnologie für die meisten aktuellen KI-Durchbrüche etabliert.

Die nächste Folge widmet sich den Transformern – der Architektur, die Large Language Models und viele andere moderne Systeme ermöglicht. Sie erläutert, warum klassische RNNs an ihre Grenzen stießen und wie Self-Attention die Verarbeitung von Sprache revolutionierte.


(rme)



Source link

Weiterlesen

Beliebt