aiMOOC

Der Agenten-Workflow - Planen Programmieren Testen Verbessern

QR-Code

Einleitung

Du entwickelst in diesem vollständigen aiMOOC eine kleine, rein lokale Messdaten-App in drei kontrollierten Schritten weiter. Im Mittelpunkt steht nicht, möglichst viel Code auf einmal zu erzeugen, sondern nach jeder Änderung einen nachprüfbaren Zwischenstand zu sichern. Die Leitfolge lautet: Planen → Vorabtest zeigen → Programmieren → Testen → Prüfen → Verbessern. Ein Coding-Agent kann Vorschläge machen und Dateien bearbeiten; die fachliche Verantwortung, Rechtevergabe und Abnahme bleiben beim Menschen.

Zielgruppe: Auszubildende im 2. bis 3. Ausbildungsjahr, insbesondere in technischen und IT-nahen Berufen. Voraussetzung: A1 oder Grundlagen in Python, Dateien, Git und einfachen Tests. Die vorhandene Grundlage auf MOOCwiki dient zur kurzen Wiederholung; ihr genauer Inhalt konnte beim Quellenabruf nicht geprüft werden. Lernzeit: ungefähr 4–6 Unterrichtseinheiten plus eigenständige Umsetzung. Lernprodukt: ein Protokoll zu genau drei kleinen App-Erweiterungen mit Testnachweis, Git-Stand, Fehlerbegründung und menschlicher Reviewentscheidung.

Arbeitsregel: Alle CSV-Daten, Personen, Messstellen und Entscheidungen sind erfunden. Es werden keine realen Anlagen angesprochen, keine Maschinen gesteuert und keinerlei Sicherheitsfreigaben erteilt. Der vollständige Kurs ist mit Python-Standardbibliothek und lokalem Git offline und ohne bezahltes KI-Konto lösbar. Ein Agent ist optional: Du kannst seine Rolle mit schriftlichen Vorschlägen selbst simulieren. Dieses unabhängige Bildungsangebot ist weder eine offizielle Liebherr- noch eine IHK-Zertifizierung.

Deine drei überprüfbaren Qualitätskriterien: (1) Ein Vorabtest weist die noch fehlende Funktion nach. (2) Ein Git-Commit bewahrt einen eindeutig benannten Versionsstand. (3) Ein Regressionstest macht sichtbar, wenn eine bereits funktionierende Fähigkeit durch eine neue Änderung beschädigt wurde. Am Ende erklärst du selbst, warum eine Iteration angenommen, zurückgestellt oder überarbeitet wurde.

Den Agenten-Workflow beherrschen

Von Aufgaben zu kleinen Iterationen

Eine Iteration ist ein kurzer Entwicklungsdurchlauf mit einem klaren Ziel und überprüfbarem Ergebnis. Eine Akzeptanzbedingung beschreibt, woran Menschen die Erfüllung erkennen; ein Test prüft einen konkreten Fall. Unter Regression versteht man, dass nach einer Änderung zuvor funktionierendes Verhalten nicht mehr korrekt arbeitet. Ein Review ist die bewusste fachliche Prüfung einer Änderung; ein bestandener Test ersetzt es nicht.

Anstelle von „Verbessere die App vollständig“ beauftragst du zum Beispiel: „Ergänze nur die Prüfung der CSV-Spaltennamen, ändere keine anderen Dateien, zeige zuerst einen scheiternden Test und gib danach die Testergebnisse an.“ Ein begrenzter Auftrag ist überprüfbar und lässt sich bei Problemen leichter zurücknehmen. Ein Agentenlauf ist eine Hypothese über eine Lösung, kein Beweis ihrer Richtigkeit.

Phase	Leitfrage	Nachweis
Planen	Was genau soll sich ändern, was bleibt unverändert?	Akzeptanzbedingung und erlaubte Dateiliste
Vorabtest	Welcher Test schlägt vor der Änderung nachvollziehbar fehl?	dokumentierter Rot-Zustand
Programmieren	Welche kleinste Änderung erfüllt das Ziel?	lesbare Code-Differenz
Testen	Sind neuer Test und bisherige Tests grün?	vollständige Testausgabe
Prüfen	Sind Daten, Rechte und Nebenwirkungen in Ordnung?	Review-Entscheidung durch Lernende
Sichern	Auf welchem Git-Stand kann ich reproduzieren?	Commit-Kennung und Protokoll

Kreisförmige Übersicht typischer Phasen der Softwareentwicklung — Softwareentwicklungsphasen als Orientierung; unser Lernprozess durchläuft die Phasen mehrfach in kleinen Schleifen.

Medienalternative: Lies die sechs Phasen der Tabelle von oben nach unten und erkläre, warum nach einer negativen Prüfung zum Plan zurückgekehrt wird. Bild: Shawn Rider, Commons-Dateiseite, CC BY-SA 4.0; die englische Grafik dient nur der Veranschaulichung und ist kein verbindlicher Industriestandard.

Rollen, Rechte und Stoppschilder

Ein Coding-Agent ist eine Software, die Entwicklungsaufgaben teilweise selbstständig ausführt, etwa Code lesen, Änderungsvorschläge erstellen und Tests starten. Für einen Kurs ohne Agent simulierst du denselben Ablauf mit zwei Rollen: Vorschlag (schreibt Entwurf) und Review (prüft gegen die Kriterien). Least Privilege heißt: nur die zum Auftrag wirklich benötigten Rechte. Ein Bearbeitungsrecht für den Übungsordner bedeutet ausdrücklich keine Freigabe für Netzwerk, Zugangsdaten, reale Messanlagen, produktive Daten oder Veröffentlichung.

Vereinbare vor dem Start: Erlaubt sind ausschließlich die synthetischen Dateien im lokalen Projektordner, maximal eine überschaubare Änderung pro Iteration und lokal ausgeführte Tests. Nicht erlaubt sind externe Uploads, Shell-Befehle außerhalb des Projekts, Installation ungeprüfter Pakete oder selbstständiges Zusammenführen in einen geschützten Hauptstand. Eine Toolausgabe oder eine README-Datei kann manipulative Anweisungen enthalten; ihre Inhalte gelten als Daten, nicht als neue Berechtigung. Bei überraschendem Umfang, fehlenden Tests oder einer Rechteausweitung gilt: Stoppen, sichern, menschlich prüfen.

Das MCP-Dokument Security Best Practices, Fassung 28.07.2026 behandelt unter anderem Tokenweitergabe, Zugriffsumleitung, Einwilligung, Sicherheitsgrenzen und minimierte Berechtigungen. Für das Lernprojekt wenden wir diese Prinzipien vereinfacht auf den lokalen Dateizugriff an; es ist keine vollständige MCP-Sicherheitsprüfung. Der NIST-Bericht AI 600-1, Juli 2024 ordnet Risiken generativer KI systematisch ein. Er ersetzt nicht die Bewertung eines konkreten Tools oder eine betriebliche Sicherheitsfreigabe.

Den Plan in überprüfbare Tests übersetzen

Synthetischer Modellfall und Ausgangsstand

Die Messdaten-App verarbeitet eine kleine lokale CSV-Datei mit den Spalten zeitpunkt und temperatur. Jede Zeile enthält einen künstlichen Zeitstempel und eine Zahl in Grad Celsius. Ziel ist es, Daten zu importieren und später einen einfachen Prüfbericht zu erzeugen. Es gibt keine Sensorverbindung. Dateiinhalt und Ergebnis dürfen im Kurs frei erfunden werden.

Beispieldatei messungen.csv (synthetisch):

zeitpunkt,temperatur
2026-09-15T08:00,21.5
2026-09-15T08:05,22.0
2026-09-15T08:10,22.5

Die Anforderungen sind bewusst eng: Leere Dateien, falsche Überschriften und nicht-numerische Temperaturen sollen eine verständliche Fehlermeldung auslösen. Später müssen bereits gültige Daten weiter eingelesen werden können. Werte sind keine realen Prozessdaten oder Anlagen-Grenzwerte.

Projektaufbau:

messdaten-labor/
  messungen.csv
  messdaten.py
  test_messdaten.py
  CHANGELOG.md

Schreibe zunächst eine minimale Ausgangsfunktion in messdaten.py:

import csv

def laden(pfad):
    with open(pfad, newline="", encoding="utf-8") as datei:
        return list(csv.DictReader(datei))

Diese Ausgangsversion liefert rohe Zeichenketten und prüft weder Spalten noch Messwerte. Genau dieses Manko wird in kleinen Schritten behoben. Nutze für die Tests das in Python eingebaute Modul unittest, sodass keine Zusatzinstallation nötig ist.

Vorabtest: Rot ist eine nützliche Erkenntnis

Ein Vorabtest prüft die neue Anforderung, bevor der passende Code existiert. Die erwartete Fehlermeldung sollte konkret sein. Erzeuge test_messdaten.py für Iteration 1:

import tempfile
import unittest
from pathlib import Path
from messdaten import laden

class ImportTests(unittest.TestCase):
    def test_falsche_spalten(self):
        with tempfile.TemporaryDirectory() as ordner:
            pfad = Path(ordner) / "falsch.csv"
            pfad.write_text("uhrzeit,grad\n08:00,21\n", encoding="utf-8")
            with self.assertRaisesRegex(ValueError, "Spalten"):
                laden(pfad)

    def test_gueltige_werte(self):
        with tempfile.TemporaryDirectory() as ordner:
            pfad = Path(ordner) / "ok.csv"
            pfad.write_text(
                "zeitpunkt,temperatur\n08:00,21.5\n", encoding="utf-8"
            )
            self.assertEqual(laden(pfad)[0]["temperatur"], 21.5)

if __name__ == "__main__":
    unittest.main()

Starte lokal python -m unittest -v. Die Ausgangsfunktion löst im ersten Test keinen ValueError aus und liefert im zweiten Test statt der Zahl 21.5 eine Zeichenkette. Beides sind erwartete rote Tests vor der Erweiterung; protokolliere die tatsächlichen Meldungen. Ein roter Test allein genügt nicht: Er muss aus dem beabsichtigten Grund fehlschlagen und nach der Korrektur grün werden.

Tipp: Im Editor kannst du zunächst nur den ersten Test ausführen. Vertiefung: Prüfe, warum fehlerhafte Testdaten oder ein Tippfehler im Import ebenfalls zu Rot führen können, aber gerade keinen belastbaren Vorabtest darstellen. Offline-Alternative: Markiere in einem Ausdruck die Testbedingung, das erwartete und das tatsächlich beobachtete Verhalten; simuliere die Ausführung Zeile für Zeile.

Versionsstand vor dem Eingriff

Mit Git dokumentierst du Änderungen. Ein Commit ist eine dauerhaft adressierbare Momentaufnahme der versionierten Dateien. Verwende im lokalen Übungsordner beispielsweise:

git init
git add messdaten.py messungen.csv test_messdaten.py
git commit -m "Ausgangsstand und rote Importtests"
git rev-parse --short HEAD
git status --short

Falls auf dem Übungsgerät noch kein Benutzername konfiguriert ist, richte nur für dieses lokale Repository eine fiktive Kennung ein; du brauchst weder GitHub noch Internet. Notiere die ausgegebene Commit-Kennung im Lernprotokoll. Ein Commit beweist nicht, dass der Code richtig ist; er macht lediglich diesen konkreten Stand auffindbar.

Medienalternative: Beschreibe den Weg einer Änderung von der Arbeitsdatei über die Staging-Area in einen Commit. Grafik: Daniel Kinzler, Wikimedia Commons, CC BY 3.0; Beschriftungen teilweise Englisch.

Video und Textalternative: „Git und GitHub Tutorial für Anfänger (Deutsch)“, Kanal „Programmieren lernen“, veröffentlicht 13.09.2025. Nur Git-Grundlagen und lokale Commits werden benötigt, kein Online-Konto. Ohne Video lies die obigen vier Git-Befehle und das freie deutschsprachige Pro-Git-Kapitel. Originalvideo (YouTube-Verfügbarkeit beim Quellenabruf geprüft; künftige Erreichbarkeit nicht garantiert).

Iteration 1: CSV-Importprüfung entwickeln

Kleine, klar abgegrenzte Änderung

Auftrag an einen optionalen Agenten oder dich selbst: „Ändere nur die Funktion laden in messdaten.py. Akzeptiere exakt die Kopfzeile zeitpunkt,temperatur, mindestens eine Datenzeile und eine als Fließkommazahl lesbare Temperatur pro Zeile. Wirf bei fehlerhaften Daten ValueError mit einer verständlichen Nachricht. Zeige vorab die roten Tests, führe danach alle Tests aus und fasse die Änderung zusammen. Keine Dateizugriffe außerhalb des Übungsordners.“

Eine mögliche Lernlösung (nicht die einzige zulässige) lautet:

import csv

def laden(pfad):
    with open(pfad, newline="", encoding="utf-8") as datei:
        leser = csv.DictReader(datei)
        if leser.fieldnames != ["zeitpunkt", "temperatur"]:
            raise ValueError("Spalten: erwartete Kopfzeile fehlt")
        zeilen = []
        for nummer, zeile in enumerate(leser, start=2):
            if not zeile["zeitpunkt"]:
                raise ValueError(f"Zeile {nummer}: Zeitpunkt fehlt")
            try:
                temperatur = float(zeile["temperatur"])
            except (TypeError, ValueError):
                raise ValueError(
                    f"Zeile {nummer}: Temperatur ungueltig"
                ) from None
            zeilen.append({
                "zeitpunkt": zeile["zeitpunkt"],
                "temperatur": temperatur
            })
        if not zeilen:
            raise ValueError("Keine Messwerte vorhanden")
        return zeilen

Wichtig: Dieses didaktische Beispiel ist keine robuste Produktivvalidierung. Beispielsweise werden besondere Fließkommawerte wie NaN noch nicht ausgeschlossen; außerdem ist die Zeitstempel-Syntax hier nicht umfassend geprüft. Halte diese Grenzen fest, statt falsche Sicherheit zu behaupten.

Nachprüfung und Reviewentscheidung

Führe python -m unittest -v aus. Prüfe zusätzlich manuell eine leere CSV und eine ungültige Temperatur wie abc. Vergleiche den Code mit dem Auftrag: Wurde eine andere Datei verändert? Wird der Fehler tatsächlich erkannt? Ist die Rückgabe für gültige Daten weiterhin nutzbar? Dokumentiere „Rot vor Änderung → Grün nach Änderung“, die tatsächliche Testausgabe und die Entscheidung. Danach:

git add messdaten.py test_messdaten.py
git commit -m "Iteration 1 Importpruefung"
git rev-parse --short HEAD

Qualitätsprobe 1: Vorabtest zeigen. Ein Bericht wie „Tests bestanden“ reicht nicht: Nenne mindestens einen konkreten Testnamen, seinen Fehler vor der Änderung und sein Ergebnis nach der Änderung. Qualitätsprobe 2: Versionsstand erhalten. Schreibe die Commit-Kennung auf und zeige, dass der Arbeitsbaum danach unverändert ist.

Iteration 2: Prüfbericht und Regressionstests ergänzen

Neuer Mehrwert ohne Veränderung des Imports

Das zweite kleine Feature erzeugt aus den gültigen importierten Daten einen synthetischen Prüfbericht. Er enthält die Anzahl der Zeilen und den Mittelwert, ohne reale Qualitäts- oder Sicherheitsgrenzen zu behaupten. Definiere zunächst einen neuen Vorabtest, der von einer bislang nicht vorhandenen Funktion bericht abhängt:

from messdaten import bericht

def test_bericht_mittelwert(self):
    daten = [
        {"zeitpunkt": "08:00", "temperatur": 20.0},
        {"zeitpunkt": "08:05", "temperatur": 24.0}
    ]
    self.assertEqual(
        bericht(daten),
        {"anzahl": 2, "mittelwert": 22.0}
    )

Füge die Methode in deine vorhandene unittest-Testklasse ein. Zunächst ist bereits der Import von bericht fehlgeschlagen; nach Implementierung muss die vollständige Testsuite grün sein. Implementiere beispielsweise:

def bericht(daten):
    if not daten:
        raise ValueError("Keine Daten fuer Bericht")
    werte = [eintrag["temperatur"] for eintrag in daten]
    return {
        "anzahl": len(werte),
        "mittelwert": sum(werte) / len(werte)
    }

Füge für den leeren Fall ebenfalls einen Test hinzu. Die Funktion erwartet bereits geprüfte Daten; das trennt die Verantwortung von Import und Bericht. Bei vielen Zahlen oder sehr großen Werten können Rundungs- und Genauigkeitsfragen relevant werden; hier verwenden wir bewusst einfache Beispiele.

Regression gezielt provozieren und erkennen

Ein Regressionstest wiederholt eine Prüfung, die vor der neuen Änderung erfolgreich war. Probiere zur Fehler-Simulation in einer separaten, noch nicht committeten Arbeitskopie folgendes aus: Ersetze im Importcode testweise temperatur = float(zeile["temperatur"]) durch temperatur = zeile["temperatur"]. Der Berichtstest kann dann bei Addition von Zeichenketten scheitern; auch test_gueltige_werte aus Iteration 1 erkennt, dass die Temperatur keine Zahl mehr ist. Das ist ein reproduzierbarer Regressionsfall. Nimm diese absichtliche Fehleränderung danach wieder zurück und führe die gesamte Testsuite erneut aus.

Situation	Erwartung	Schlussfolgerung
Vorabtest für bericht vor Implementierung	rot, weil Funktion fehlt	neue Anforderung noch nicht erfüllt
Bericht implementiert, sämtliche Tests laufen	grün	beobachtete Testfälle bestanden; noch keine vollständige Sicherheit
Import versehentlich zu Strings verändert	bisheriger Importtest rot	Regression erkannt
Fehleränderung rückgängig, gesamte Suite erneut grün	bewahrter Funktionsumfang in getesteten Fällen	Änderung bereit für Review

Qualitätsprobe 3: Regression erkennen. Zeige welcher alte Test durch die gezielt eingesetzte Fehländerung rot wird. Erkläre, warum allein der neue Berichtstest keine ausreichende Absicherung des Imports wäre. Halte die Fehlersimulation nicht im grünen Commit fest. Sichere anschließend Iteration 2 Bericht und Regressionstests mit Git.

Medienalternative: Beschreibe die Folge „Quellcode ändern → Tests ausführen → Fehlermeldung untersuchen → menschliches Review“. Grafik: Grégoire Détrez; spätere Sprachbearbeitung von TAKAHASHI Shuuji, Commons, CC BY-SA 4.0.

Video und Textalternative: „Was ist CI/CD? // deutsch“, the native web GmbH, veröffentlicht 06.06.2021. Die Konzepte häufiges Testen, frühes Feedback und reproduzierbare Schritte werden erklärt. Unsere Übung deployt nichts. Ohne YouTube arbeite die obige Situationstabelle durch und erkläre, warum das Testen nach jedem kleinen Schritt zeitnah Rückmeldung gibt. Videoquelle (Abruf geprüft, dauerhafte Verfügbarkeit offen).

Iteration 3: Reviewgrenzen und nachvollziehbare Freigabe

Ergebnis kennzeichnen statt automatische Freigabe vortäuschen

Die dritte Erweiterung dokumentiert, welche Tests ausgeführt wurden und wie die menschliche Reviewentscheidung lautet. Ein Coding-Agent darf einen Prüfentwurf vorschlagen, aber sich keine eigenständige fachliche oder sicherheitstechnische Freigabe geben. Als lokales Lernfeature erhält der Bericht das Feld review_status mit dem Standardwert offen. Der Eintrag fachlich_geprueft darf nur durch den Auszubildenden nach tatsächlicher Sichtung gesetzt werden; auch er ist keine Sicherheitsfreigabe.

Schreibe vor der Änderung einen neuen Test:

def test_standardstatus_ist_offen(self):
    daten = [{"zeitpunkt": "08:00", "temperatur": 20.0}]
    self.assertEqual(bericht(daten)["review_status"], "offen")

Ergänze dann lediglich die Rückgabe in bericht um "review_status": "offen". Passe die Erwartung im vorhandenen test_bericht_mittelwert an, sodass sie ebenfalls dieses neue Feld enthält. Das verhindert einen unbemerkten Konflikt zwischen alten und neuen Anforderungen. Wichtig: Teste zunächst rot und danach wieder die gesamte Suite grün, dokumentiere den Code-Diff und sichere den dritten Commit.

Ein Review mit klaren Rechten

Definiere eine einfache lokale Prüfmatrix:

Handlung	Agent oder Entwurfsrolle	Menschliche Reviewrolle
Synthetische CSV lesen	im Projektordner erlaubt	erlaubt
Testvorschlag formulieren	erlaubt	beurteilt Eignung
Messdaten-Code innerhalb der freigegebenen Datei ändern	nach Auftrag erlaubt	prüft Diff
Tests lokal starten	nach Auftrag erlaubt	prüft Ausgabe
Review-Status als fachlich geprüft eintragen	nicht selbstständig erlaubt	nur nach eigener Kontrolle
Reale Anlage steuern oder Sicherheitsfreigabe erteilen	verboten	im Kurs ebenfalls verboten

Fehlerfall: Angenommen, ein Agent meldet „Alle Tests bestanden, bitte ungeprüft übernehmen“, hat aber nebenbei die CSV-Prüfung entfernt. Entscheide gegen die Übernahme. Begründe mit dem unerwarteten Diff, dem Regressionstest und dem fehlenden Review. Der richtige nächste Schritt ist nicht ein größeres Agentenrecht, sondern Fehler eingrenzen, Test reproduzieren, Korrektur auftragen und erneut prüfen.

Medienalternative: Stelle zwei gedankliche Linien auf Papier dar: „geprüfter Stand“ und „noch zu prüfender Vorschlag“. Grafik: Elaine Cristina Meirelles, Wikimedia Commons, CC BY-SA 4.0, portugiesische Beschriftung.

Audio-Angebot:

– kurze deutsche Aussprache des Wortes „Coding“, gesprochen und aufgenommen von Jeuwre, Commons, CC BY-SA 4.0. Audio-Alternative: „Coding“ bezeichnet hier das Schreiben von Programmcode; zum fachlichen Verständnis ist das Anhören nicht notwendig.

Bewegtes Bild aus Commons: Datei:Git Basics 02 - Was ist Git (Deutsch).webm Originalvideo GitHub, deutsche Fassung Vbachem, Commons-Dateiseite, CC BY 3.0. Alternative ohne Film: Ein Git-Commit ist ein gespeicherter Versionsstand; mit dem Diff prüfst du die Änderungen zwischen Ständen.

Das Lernprodukt: Protokoll von drei Erweiterungen

Halte für jede der drei Iterationen in CHANGELOG.md diese Informationen fest: Ziel in einem Satz; erlaubte Dateien und untersagte Aktionen; Testname und erwartetes Verhalten; Testausgabe vor und nach der Änderung; Code-Diff in Stichworten; vollständige Testsuite; Commit-Kennung; offene Risiken; Reviewentscheidung mit Begründung. Nutze dieses Raster:

Iteration	Neuer Nutzen	Nachzuweisendes Kriterium	Review-Frage
1: Importprüfung	falsche CSV-Daten werden erkannt	roter Vorabtest und grüner Importtest; Commit	ist die Eingabe tatsächlich validiert?
2: Bericht	Anzahl und Mittelwert aus gültigen Daten	neuer Vorabtest; früherer Importtest entdeckt absichtliche Regression; Commit	funktionieren neue und alte Anforderungen?
3: Statusfeld	Prüfentwurf bleibt standardmäßig offen	roter Status-Vorabtest; volle Testsuite; Commit	kann ein Agent sich selbst fälschlich freigeben?

Anspruchsvolle Vertiefung: Untersuche Grenzfälle wie NaN, leere Zeitstempel oder zusätzliche CSV-Spalten; schreibe vor einer Korrektur jeweils einen Test. Trenne Testabdeckung von Gewissheit: Grüne Tests belegen nur getestete Beispiele, nicht sämtliche denkbaren Fälle. Leite aus der Änderungsliste ab, welche Teile zusätzlich von einem Menschen geprüft werden müssen.

Zukunftsperspektive: Auch leistungsfähigere Agenten ersetzen keine kurzen kontrollierten Iterationen. Gute Entwicklungsprozesse erhalten kleine, überprüfbare Änderungen, nachvollziehbare Entscheidungen und begrenzte Rechte. Bei neuen Werkzeugversionen musst du die dokumentierten Funktionen, Standardrechte und Sicherheitshinweise erneut prüfen.

Interaktive Aufgaben

Quiz: Prüfe dein Wissen

Bearbeite jede Frage und nutze die automatische Rückmeldung. Die Fragen beziehen sich auf die Lernbeispiele; die Lösungen werden nicht separat vorab angezeigt.

Was zeigt ein geeigneter Vorabtest vor der ersten Importerweiterung? (Dass der falsche Spaltenname noch nicht erkannt wird) (!Dass sämtliche denkbaren Dateien schon gültig sind) (!Dass die Änderung bereits produktiv freigegeben ist) (!Dass eine Git Kennung die fachliche Prüfung ersetzt)

Welcher Nachweis hält einen prüfbaren Versionsstand fest? (Ein Git Commit mit dokumentierter Kennung) (!Ein ausschließlich mündliches Versprechen) (!Ein einzelner neuer Dateiname ohne Historie) (!Ein Screenshot ohne Bezug zum Quellcode)

Woran erkennst du eine Regression im Modellfall? (Ein früher grüner Importtest wird nach einer Änderung rot) (!Ein neuer Berichtstest wird vor Implementierung rot) (!Ein Kommentar wird sprachlich verbessert) (!Ein Video zur Versionskontrolle wird geöffnet)

Was ist nach einer grünen Testsuite zusätzlich notwendig? (Ein menschliches Review von Diff Rechten und offenen Risiken) (!Automatische Freigabe aller externen Zugriffe) (!Löschen der Testdateien zur Beschleunigung) (!Unkontrolliertes Erweitern des Agentenauftrags)

Was darf ein Agent im Übungsprojekt nicht eigenständig tun? (Einen fachlich geprüften Status ohne menschliche Sichtung setzen) (!Einen Testvorschlag für synthetische Daten schreiben) (!Die erlaubte lokale Quelldatei lesen) (!Einen lokal genehmigten Testlauf ausführen)

Warum bleiben die Importtests beim zweiten Feature erhalten? (Sie prüfen altes Verhalten auf unbeabsichtigte Änderungen) (!Sie ersetzen alle neuen Berichtstests) (!Sie erlauben Zugriff auf produktive Anlagen) (!Sie machen ein Review grundsätzlich überflüssig)

Welche Aussage über einen roten Test ist korrekt? (Sein konkreter Fehlergrund muss zur neuen Anforderung passen) (!Jeder rote Test beweist automatisch gute Testqualität) (!Ein roter Test ist grundsätzlich zu löschen) (!Rote Tests dürfen nie vor einer Implementierung vorkommen)

Welche Daten sind für die Messdatenübung vorgesehen? (Ausschließlich synthetische lokal gespeicherte Beispieldaten) (!Vertrauliche Kundendaten aus dem Betrieb) (!Live Sensordaten einer produktiven Anlage) (!Passwörter aus einer realen Maschinensteuerung)

Was bedeutet eine minimale Rechtevergabe im Agentenauftrag? (Nur erforderliche Dateien und Aktionen ausdrücklich erlauben) (!Alle Dateien und Netzwerke vorsorglich freigeben) (!Prüfungen von Befehlen vollständig abschalten) (!Dem Agenten die Entscheidung über eigene Rechte überlassen)

Welche Dokumentation gehört zum Lernprodukt? (Drei Iterationen mit Tests Änderungen Commit Kennungen und Review) (!Nur eine Endversion ohne Testverlauf) (!Nur die Liste genutzter Videos) (!Eine unbewertete automatische Freigabe)

Memory: Begriffe und Bedeutung

Iteration	Kurzer vollständiger Entwicklungsdurchlauf mit Rückmeldung
Vorabtest	Prüfung einer neuen Anforderung vor ihrer Umsetzung
Commit	Gesicherte Momentaufnahme im Versionsverlauf
Regression	Verlust einer zuvor funktionierenden Fähigkeit
Review	Bewusste fachliche Prüfung einer Änderung
Rechtebegrenzung	Nur notwendige Aktionen und Dateien zulassen

Drag-and-Drop: Nachweise zuordnen

Ordne die fünf Arbeitsergebnisse den passenden Entwicklungsschritten zu.

Passender Nachweis	Entwicklungsschritt
Akzeptanzbedingung in einem Satz	Planen
Gezielt scheiternder Anforderungstest	Vorabtest
Begrenzter Code-Diff	Programmieren
Gesamte grüne Testsuite	Testen
Begründete menschliche Annahme	Review

Kreuzworträtsel: Werkzeuge und Prinzipien

Iteration	Wie heißt ein kurzer Entwicklungsdurchlauf?
Vorabtest	Welche Prüfung zeigt vor der Implementierung die Lücke?
Commit	Wie heißt eine gespeicherte Git Momentaufnahme?
Regression	Wie heißt das Wiederauftreten eines bereits behobenen Fehlers?
Review	Wie heißt die menschliche Durchsicht einer Änderung?
Import	Wie heißt das Einlesen der CSV Daten in die Anwendung?

LearningApps

Suche passende Übungen zu Agenten-Workflow, Programmierung und Tests; die Suchergebnisse externer Anbieter werden nicht als fachlich geprüft vorausgesetzt.

Alternative ohne LearningApps: Zeichne fünf Karten für Plan, Vorabtest, Code, Gesamttest und Review und ordne ihnen die Nachweise der Drag-and-Drop-Aufgabe zu.

Lückentext: Den Ablauf verstehen

Ein kurzer Entwicklungsdurchlauf heißt

.

Ein Test vor der Umsetzung einer neuen Anforderung heißt

.

Eine gesicherte Momentaufnahme in Git heißt

.

Eine unbeabsichtigte Verschlechterung früheren Verhaltens ist eine

.

Die fachliche Prüfung einer Änderung nennt man

.

Ein Mensch bewertet zusätzlich zur grünen Testsuite den

.

Der Import wird im Modellfall mit einer lokalen

getestet.

Ein ungeprüfter Prüfvorschlag erhält zunächst den Status

.

Die drei Erweiterungen werden im

dokumentiert.

Nur ausdrücklich benötigte Aktionen entsprechen der

.

Offene Aufgaben

Leicht

Vorabtest erkennen: Beschreibe mit eigenen Worten, warum ein Test vor Implementierung von bericht zunächst scheitern soll. Nenne den konkreten Grund.
Versionsstand beschriften: Zeichne drei Kästen für den Ausgangsstand und zwei nachfolgende Commits. Erkläre, welche Informationen eine Commit-Kennung sichert.
Fehlerfälle markieren: Erfinde drei kleine CSV-Dateien mit gültiger Kopfzeile, falscher Kopfzeile und ungültiger Temperatur. Begründe die erwartete Reaktion.
Arbeitszyklus ordnen: Schreibe sechs Prozesskarten und ordne Planen, Vorabtest, Programmieren, Testen, Review und Sichern. Erläutere eine mögliche Rücksprungstelle.

Standard

Importprüfung realisieren: Setze Iteration 1 lokal um, dokumentiere roten und grünen Test und die genaue Git-Kennung.
Bericht validieren: Implementiere Iteration 2 samt Mittelwerttest und zusätzlichem Leere-Daten-Test. Zeige Ergebnisse der gesamten Suite.
Fehler absichtlich einbauen: Provoziere die im Kurs beschriebene String-Regression, sichere die Fehlermeldung und erkläre, welcher alte Test sie entdeckt.
Grenzen prüfen: Untersuche einen fiktiven Agentenvorschlag auf unerlaubte Dateien, unerwartete Änderungen und fehlende Prüfbelege; formuliere eine begründete Reviewentscheidung.

Schwer

Grenzfälle systematisch testen: Entwerfe zusätzliche Tests für NaN, zusätzliche Spalten und leere Werte. Zeige jeweils zuerst den passenden Fehlerfall und entwickle einen engen Korrekturauftrag.
Änderungen vergleichen: Stelle zwei Git-Stände gegenüber, protokolliere betroffene Funktionen und bewerte die Wahrscheinlichkeit einer Regression mit Begründung.
Reviewgrenzen verteidigen: Entwickle eine schriftliche Checkliste gegen ein fiktives Agentenangebot, alle Dateien zu lesen und selbst zu veröffentlichen. Beurteile Rechte, Nachweise und Stoppkriterien.
Transferprojekt planen: Übertrage drei kleine kontrollierte Iterationen auf eine synthetische Inventar-App. Entwirf Vorabtests, Regressionstests und ein überprüfbares Freigabeprotokoll, ohne echte Betriebsdaten zu nutzen.

Lernkontrolle

Nachweiskette rekonstruieren: Belege an einem Beispiel die Schritte von der Anforderung über einen passenden roten Vorabtest bis zum grünen Gesamttest. Warum ist die Reihenfolge wichtig?
Versionshistorie erläutern: Zeige anhand von drei Commit-Kennungen, welche geprüften Zwischenstände erhalten bleiben. Erkläre, warum allein eine Kennung noch keine Qualität garantiert.
Regression diagnostizieren: Analysiere einen Fehlerfall, in dem Iteration 2 den Temperaturtyp versehentlich zurück in eine Zeichenkette verändert. Welcher vorhandene Test muss anschlagen und weshalb?
Rechteentscheidung begründen: Ein fiktiver Agent möchte für einen lokalen CSV-Test Zugriff auf das gesamte Netz und auf reale Betriebsdateien. Weise die Bitte begründet zurück und formuliere eine ausreichend enge Alternative.
Prüfentscheidung dokumentieren: Erkläre mit Testausgabe, Diff und offener Risikoliste, wann Iteration 3 fachlich geprüft werden kann und was weiter ausdrücklich nicht freigegeben ist.
Transfer reflektieren: Plane eine kleine Änderung an einer synthetischen Lager-App. Trenne neue Funktion, alten Funktionsumfang, Vorabtest, Regressionstest und menschliches Review.

Lernnachweis

Pflichtprodukt: Gib ein Protokoll über drei kleine App-Erweiterungen und die lokalen Quelltextdateien ab. Die drei Teile heißen Importprüfung, Prüfbericht mit Regressionstest und Statusfeld für menschliches Review. Für jede Iteration müssen Ziel, begrenzter Auftrag, roter Test vor Implementierung, grüner Test nach Implementierung, Gesamt-Testlauf, Code-Diff, Git-Kennung, Fehlerbehandlung und Reviewentscheidung dokumentiert sein. Mindestens ein absichtlich ausgelöster und danach rückgängig gemachter Regressionsfall muss mit Testname und eigener Erklärung vorliegen.

Bewertungsraster: Vorabtest sinnvoll und tatsächlich vorher gezeigt (25 %); drei nachvollziehbare Commits und unveränderte Zwischenstände (20 %); Regression überzeugend erkannt, behoben und erklärt (25 %); Rechte und menschliche Reviewgrenzen beachtet (20 %); lesbares Protokoll samt selbstständigem Transfer (10 %). Offene Grenzen und Unsicherheit klar benennen. Wer keinen Rechner hat, erstellt die Ausführung als sorgfältig gekennzeichnete Papier-Simulation mit erwarteten statt behaupteten realen Konsolenausgaben; dabei können keine tatsächlich ausgeführten Tests bescheinigt werden.

Selbstcheck: Kannst du die drei Fragen unabhängig beantworten: Welcher Test war vor der Änderung rot? Welche Commit-Kennung bezeichnet den erhaltenen Zwischenstand? Welcher alte Test erkennt die eingeschleuste Regression? Bei einer unklaren Antwort ergänze einen Nachweis. Der Lernnachweis ist eine schulische Übung und keine Betriebsabnahme, Zertifizierung oder Sicherheitsfreigabe.

OER und Wikipedia

Quellenstand: 22.10.2026. Verweise wurden beim Erstellen öffentlich geprüft; Abrufbarkeit und Inhalte können sich danach ändern. Der angegebene NIST-Bericht stammt aus Juli 2024, die referenzierte MCP-Sicherheitsdokumentation aus dem Pfadstand 28.07.2026. Die Eignung für reale Unternehmenssysteme ist nicht geprüft.

Model Context Protocol: Security Best Practices, Version im URL-Pfad 2026-07-28 – englische technische Primärquelle zu Angriffsszenarien und Sicherheitsmaßnahmen.
NIST AI 600-1: Generative AI Profile, Juli 2024 – englische Primärquelle zu generativen KI-Risiken und Risikomanagement, kein Prüfzeugnis für eine App.
pytest-Dokumentation, online eingesehener Stand 22.10.2026 – zusätzliche weiterführende Testtechnik; die Übung selbst verwendet nur Python unittest.
Python: unittest-Dokumentation – Standardbibliothek, auch offline mit installierter Python-Hilfe nutzbar.
Python: csv-Dokumentation – Hinweise zum Lesen tabellarischer Daten.
Pro Git, deutsch: Änderungen nachverfolgen und speichern – frei zugängliches Git-Grundlagenbuch.
Wikipedia: Regressionstest und Wikipedia: Kontinuierliche Integration – ergänzende deutschsprachige Überblicksartikel.
Bestehende MOOCwiki-Grundlage – vom Auftrag vorgegeben; die Erreichbarkeit und der konkrete Text konnten beim Quellenabruf nicht bestätigt werden.

Nachgewiesene Medien und Urheberschaft (Originaldateiseiten):

Medium und Vorschau	Autorenschaft	Lizenz laut Commons-Dateiseite	Ohne externes Medium
File:Software Development Lifecycle Diagram.png	Shawn Rider	CC BY-SA 4.0	sechs Phasen in der ersten Tabelle
File:Git operations.svg	Daniel Kinzler	CC BY 3.0	git add, commit, status ausführen und erklären
File:Continuous Delivery process diagram.svg	Grégoire Détrez; grafische Bearbeitung TAKAHASHI Shuuji	CC BY-SA 4.0	Situationstabelle zum Regressionstest
File:Git branch.png	Elaine Cristina Meirelles	CC BY-SA 4.0	getrennte Versionslinien skizzieren
File:De-Coding.ogg	Jeuwre	CC BY-SA 4.0	Begriff Coding schriftlich erläutert
File:Git Basics 02 - Was ist Git (Deutsch).webm	GitHub Original; Vbachem deutsche Bearbeitung	CC BY 3.0 laut Dateiseite	Git-Definition und Commit-Beispiel im Kurs
Git und GitHub Tutorial für Anfänger	Kanal Programmieren lernen, 13.09.2025	externe Videoeinbettung; keine freie Nachnutzung behauptet	Pro-Git-Anleitung und Befehle
Was ist CI/CD? // deutsch	the native web GmbH, 06.06.2021	externe Videoeinbettung; keine freie Nachnutzung behauptet	Testablauf und Situationstabelle

Lizenzhinweis: Die Angaben gelten für die jeweils verlinkten externen Dateien, nicht pauschal für Inhalte auf YouTube. Grafiken können fremdsprachige Beschriftungen enthalten. Für alle Medien stehen textliche Lernalternativen bereit; die fachlichen Aufgaben sind ohne Medienabruf durchführbar.

Wikipedia zum vertiefenden Lesen:

Alternative ohne eingebettete Seite: Continuous Integration bedeutet, Änderungen regelmäßig zusammenzuführen und automatisiert zu prüfen; unser lokaler Workshop übt besonders den Test- und Reviewteil.

Verknüpfte Lernbereiche

Agentengestützte Softwareentwicklung

Beruflicher Transfer: Die Methoden sind übertragbar auf technische Dokumentation, einfache Datenauswertung und IT-gestützte Lernprojekte. In realen Betrieben gelten zusätzlich deren Datenschutz-, Sicherheits-, Freigabe- und Qualitätssicherungsprozesse; dieser Kurs ersetzt diese Prozesse nicht.