Neuigkeiten
und Wissenswertes von Grüner IT

Wie ein Testfall entsteht, hängt stark davon ab, welches Verfahren dahintersteht. Im ersten Teil unserer Serie „KI im Software-Testing“ wurden Verfahren wie BDD, TDD, DDT usw. nur kurz und ausschließlich im KI-Kontext gestreift. Dieser Beitrag geht unabhängig davon in die Tiefe: Er stellt die gängigsten Verfahren zur systematischen Ableitung von Testfällen vor, jeweils mit kurzer Erklärung, einem Beispiel, typischen Einsatzmöglichkeiten sowie Vor- und Nachteilen und Grenzen.

Im letzten Beitrag dieser Serie haben wir angekündigt, die systematische Fehleranalyse vertieft zu behandeln, von der Kategorisierung nach Ursache bis zu konkreten Methoden wie Root-Cause-Analyse. Genau darum geht es in diesem Beitrag. Ein fehlgeschlagener Test zeigt zunächst nur, dass etwas nicht wie erwartet funktioniert hat, nicht, warum. Dieser Beitrag beschreibt vier Bausteine, die diese Frage auf unterschiedlichem Maßstab beantworten: die Root-Cause-Analyse als Grundpri

Die Entscheidung für ein neues System war fachlich nachvollziehbar. Die Projektleitung hatte sich intensiv mit Alternativen beschäftigt, Vor- und Nachteile abgewogen und sich für die aus ihrer Sicht beste Lösung entschieden. Nur eine Gruppe wurde dabei nicht gefragt: die Menschen, die täglich damit arbeiten sollen. Die Entscheidung selbst mag richtig gewesen sein. Trotzdem beginnt das Projekt bereits mit einem Problem, das mit der Qualität der Entscheidung nichts zu tun hat.

Vor dem Go-Live gab es eine ausführliche Schulung. Jede Funktion wurde gezeigt, jede Frage im Raum beantwortet, ein Handbuch verteilt. Aus Sicht der Projektleitung war das Team bestens vorbereitet. Zwei Monate später zeigt sich: Ein Teil des Teams nutzt weiterhin nur die absolute Grundfunktion und weicht bei allem anderen auf Umwege aus. Die Schulung war gut. Trotzdem hat sie nicht ausgereicht. Schulung beantwortet, wie etwas geht. Nicht, warum. Eine Schulung vermittelt Bedie

Das neue System ist in jeder messbaren Hinsicht besser als das alte: schneller, übersichtlicher, mit weniger manuellen Schritten. Trotzdem sträubt sich ein Teil des Teams dagegen, es wirklich zu nutzen. Nicht offen, aber spürbar zögerlich. Aus Sicht der Projektleitung ist das schwer nachzuvollziehen. Die Fakten sprechen doch eindeutig für das neue System. Genau dieser Gedanke ist der erste Fehler. Eine bessere Lösung ist kein Argument, das für sich allein wirkt Menschen bewer

Coverage, Flaky-Rate, Laufzeit: In mehreren unserer bisherigen Artikel tauchen Testmetriken als Randthema auf, etwa als Kennzahl im Sprint-Dashboard oder als Symptom für instabile Testdaten. Dieser Beitrag behandelt das Thema eigenständig und vertiefend: Welche Kennzahlen gibt es, was sagen sie tatsächlich aus, und wie lässt sich daraus ein Reporting bauen, das im Team auch wirklich genutzt wird? Wie schon bei den Testfall-Generierungsverfahren gilt: Keine einzelne Kennzahl l

Ein neues System geht live. Die Server laufen stabil, die Schnittstellen funktionieren, die Tests waren grün. Aus technischer Sicht ist das Projekt ein Erfolg. Drei Monate später arbeiten die Hälfte der Nutzer*innen immer noch mit der alten Excel-Liste nebenbei, weil sie dem neuen System nicht ganz trauen. Aus Sicht der Menschen, die damit arbeiten sollen, ist genau dasselbe Projekt gescheitert. Beide Einschätzungen beziehen sich auf dasselbe System. Der Unterschied liegt nic

In den bisherigen Beiträgen dieser Serie ging es um Teststrategien im Sprint-Zyklus, um Testdaten und Testumgebungen als Grundlage jeder Automatisierung sowie um den Einsatz von KI im Software-Testing. Dieser Beitrag schließt daran an, allerdings unabhängig von KI: Testautomatisierung scheitert in der Praxis selten an der Wahl des falschen Tools. Häufiger sind es wiederkehrende Fehler, die sich über den gesamten Lebenszyklus einer Testsuite ziehen, von der ersten Konfiguratio

Es gibt ein Bild von Projektmanagement, das sich hartnäckig hält: Wer führt, muss präsent sein, Druck aufbauen, Dinge vorantreiben und notfalls auch lauter werden, damit sich etwas bewegt. Klingt nach Tatkraft. Ist aber oft das Gegenteil von guter Führung. Klarheit hat mit Lautstärke nichts zu tun. Man kann sehr laut sein und trotzdem nichts klären und man kann sehr ruhig sein und trotzdem genau sagen, woran es hakt. Klarheit ist nicht dasselbe wie Härte Klar zu sein bedeutet

In den ersten beiden Teilen dieser Serie ging es um Künstliche Intelligenz im Software-Testing im Allgemeinen: In Teil 1 („KI im Software-Testing: Wo sie heute schon wirkt“) um die Einsatzfelder, in denen KI heute nachweislich produktiv genutzt wird, von der Prüfung von Akzeptanzkriterien bis zur Fehleranalyse. In Teil 2 („KI im Software-Testing: Grenzen, Rollen und die richtige Tool-Wahl“) um die Grenzen dieses Einsatzes, neue Anforderungen an Testengineers und die Frage nac

Testmanagement hat in vielen Projekten einen festen Platz: kurz vor dem Go-live, als letzte Kontrolle, bevor etwas produktiv geht. Diese Reihenfolge wirkt naheliegend. Am Ende soll ja alles funktionieren. Genau darin liegt aber das Risiko. Testmanagement, das erst am Ende beginnt, kann nur noch eines: bestätigen oder ablehnen, was längst gebaut ist. Alles, was zu diesem Zeitpunkt schiefläuft, lässt sich kaum mehr beheben, ohne Termine, Budget oder Umfang zu opfern. Tests zeig

KI kann heute nachweislich bei der Prüfung von Akzeptanzkriterien, bei Testdaten, Testfällen und Fehleranalyse unterstützen. Das haben wir im Beitrag „KI im Software-Testing: Wo sie heute schon wirkt“ anhand konkreter Einsatzfelder gezeigt. Genauso wichtig wie die Frage, was KI kann, ist aber die Frage, wo sie an ihre Grenzen stößt. Dieser Beitrag zeigt, wo die Risiken des KI-Einsatzes im Software-Testing liegen und wie sich Unterstützung sinnvoll von Automatismus abgrenzen l