Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Anwendungsentwicklung und Softwarequalität – Softwareänderungen kontrolliert ausliefern

QR-Code

Anwendungsentwicklung und Softwarequalität – Softwareänderungen kontrolliert ausliefern

Zielgruppe: Fachinformatikerinnen und Fachinformatiker für Anwendungsentwicklung

Lernzeit: 90 Minuten

Voraussetzungen: Python ab Version 3.9, Grundkenntnisse der Programmierung

Lernziele: Du kannst Softwareänderungen in einer isolierten Testumgebung prüfen, eine Freigabe begründen, eine fehlerhafte Auslieferung zurücknehmen und einen Release dokumentieren.

Praxisfall: Eine fiktive Fahrradverleih-App bekommt eine Rabattfunktion. Du übernimmst die Rolle einer angehenden Fachkraft für Anwendungsentwicklung.

Sicherheitsregel: Alle Programmbeispiele laufen ausschließlich lokal mit erfundenen Daten. Es werden keine Netzwerkverbindungen, fremden Systeme, Produktivanlagen, Zugangsdaten oder Kundendaten benötigt. Externe Lernvideos sind optionale Zusatzmedien, keine Testumgebungen.

Abbildung: Lebenszyklus einer Softwareveröffentlichung.

Einleitung

Eine Softwareänderung ist erst dann kontrolliert ausgeliefert, wenn ihre Qualität geprüft, ihre Freigabe nachvollziehbar und ihre Rücknahme vorbereitet ist.

Der vereinfachte Ablauf lautet:

ÄNDERUNGSWUNSCH
       |
       v
ENTWICKLUNG
       |
       v
TESTUMGEBUNG
       |
       v
QUALITÄTSPRÜFUNG
       |
       +--- Fehler ---> KORREKTUR
       |
       v
FREIGABE
       |
       v
SIMULIERTE AUSLIEFERUNG
       |
       v
SMOKE-TEST
       |
       +--- Fehler ---> ROLLBACK
       |
       v
RELEASE-DOKUMENTATION

Ein Quality Gate ist eine vorher festgelegte Bedingung für den nächsten Schritt. Ein Rollback stellt in unserem Labor die zuvor aktive Programmversion wieder her.

Lernpfad

Lerneinheit 1: Den Änderungsauftrag verstehen

Dauer: 10 Minuten

Ausbildungsfall: Fahrradverleih

Die App berechnet einen Fahrrad-Mietpreis.

Regel	Beschreibung
Grundpreis	4 Euro
Stundenpreis	2 Euro je Stunde
Neue Rabattregel	Ab 3 Stunden 1 Euro Rabatt auf den Gesamtpreis
Alte Version	1.0 ohne Rabatt
Fehlerhafte Version	1.1 mit falscher Rabattberechnung
Korrigierte Version	1.2 mit richtigem Rabatt

Änderungsauftrag CR-17: Die neue Rabattfunktion soll getestet und nur bei erfolgreicher Prüfung freigegeben werden.

Abbildung: Änderungen können in getrennten Entwicklungszweigen vorbereitet und geprüft werden.

Merke: Versionsverwaltung dokumentiert Codeänderungen. Sie ersetzt weder Softwaretests noch einen Rücknahmeplan.

Mini-Aufgabe: Überlege, warum die neue Rabattfunktion nicht sofort in einem produktiven System ausprobiert werden sollte.

Feedback: Eine fehlerhafte Berechnung kann falsche Preise erzeugen. Eine getrennte Testumgebung reduziert dieses Risiko.

Lerneinheit 2: Testumgebung und Freigabekriterien

Dauer: 10 Minuten

Abbildung: Testpyramide mit Unit-, Integrations- und Ende-zu-Ende-Tests.

Test	Prüft
Unit-Test	Einzelne Berechnungsfunktion
Integrationstest	Zusammenspiel mehrerer Komponenten
Smoke-Test	Wesentliche Grundfunktion nach der Auslieferung
Regressionstest	Ob bisher funktionierende Eigenschaften weiterhin funktionieren

Quality Gate für CR-17: Vier definierte Preisprüfungen müssen bestehen. Ein Fehler verhindert die Freigabe.

Abbildung: Beispiel eines automatisierten Integrations- und Testablaufs. Die Darstellung zeigt einen historischen Wikimedia-Prozess, keine aktuelle Vorgabe für den Ausbildungsfall.

Video: Continuous Integration – IBM Technology

Beobachtungsfrage: Warum liefern automatisierte Tests schnelleres Feedback als ausschließlich manuelle Prüfungen?

Lerneinheit 3: Das isolierte Release-Labor

Dauer: 25 Minuten

Du verwendest jetzt eine lokale Simulation mit Python.

Benötigt: Einen Texteditor, eine lokale Python-Installation und ein Terminal.

Laborgrenzen: Das Programm erstellt mit TemporaryDirectory einen temporären Arbeitsbereich. Dieser enthält ausschließlich fiktive Release-Daten und wird nach dem Durchlauf wieder entfernt.

Abbildung: Continuous Delivery mit aufeinanderfolgenden Prüf- und Auslieferungsschritten.

Codebeispiel: release_lab.py

Speichere diesen vollständigen Programmcode als release_lab.py:

from pathlib import Path
from tempfile import TemporaryDirectory
import json

FAELLE = [(1, 600), (2, 800), (3, 900), (4, 1100)]

def preis(version, stunden):
    if type(stunden) is not int or stunden < 1:
        raise ValueError("Stunden müssen positiv sein")

    basis = 400 + 200 * stunden

    if version == "1.0":
        return basis
    if version == "1.1":
        # Absichtlicher Fehler: 2 statt 1 Euro Rabatt
        return basis - (200 if stunden >= 3 else 0)
    if version == "1.2":
        return basis - (100 if stunden >= 3 else 0)

    raise ValueError("Unbekannte Version")

def pruefen(version):
    return [(stunden, preis(version, stunden) == soll)
            for stunden, soll in FAELLE]

def main():
    print("OFFLINE-RELEASE-LABOR")
    kandidat = input(
        "Kandidat 1.1 oder 1.2 [1.2]: "
    ).strip() or "1.2"

    if kandidat not in ("1.1", "1.2"):
        print("Ungültige Version. Abbruch.")
        return

    with TemporaryDirectory(
        prefix="release_labor_"
    ) as ordner:

        aktiv = "1.0"
        vorher = aktiv

        ergebnisse = pruefen(kandidat)
        bestanden = sum(ok for _, ok in ergebnisse)

        balken = "".join(
            "■" if ok else "□"
            for _, ok in ergebnisse
        )

        print("Staging:", balken,
              f"({bestanden}/4)")

        if bestanden != len(ergebnisse):
            entscheidung = "STOP: Testfehler"

        else:
            aktiv = kandidat
            stoerung = input(
                "Störung simulieren? j/n [n]: "
            ).strip().lower() == "j"

            smoke_ok = (
                preis(aktiv, 1) == 600
                and not stoerung
            )

            if smoke_ok:
                entscheidung = "FREIGEGEBEN"
            else:
                aktiv = vorher
                entscheidung = "ROLLBACK"

        bericht = {
            "Aenderung": "CR-17",
            "Kandidat": kandidat,
            "Umgebung": "lokales Testlabor",
            "Tests": f"{bestanden}/4",
            "Entscheidung": entscheidung,
            "Aktive_Version": aktiv
        }

        datei = Path(ordner) / "releasebericht.json"
        datei.write_text(
            json.dumps(
                bericht,
                ensure_ascii=False,
                indent=2
            ),
            encoding="utf-8"
        )

        print(datei.read_text(encoding="utf-8"))

    print("Temporäre Testdatei gelöscht.")

if __name__ == "__main__":
    main()

Programmstart unter Linux oder macOS:

python3 release_lab.py

Windows mit Python Launcher:

py -3 release_lab.py

Experiment A – Fehler erkennen: Wähle Version 1.1. Zwei der vier Tests schlagen fehl. Die Auslieferung wird gestoppt.

Experiment B – Freigabe: Starte das Programm erneut. Wähle Version 1.2 und beantworte die Störungsfrage mit n. Die Prüfung wird bestanden.

Experiment C – Rücknahme: Starte erneut mit Version 1.2 und simuliere mit j eine Laufzeitstörung. Die Simulation kehrt zur Version 1.0 zurück.

Wichtig: Diese Versionumschaltung ist eine vereinfachte Lernsimulation, kein Deployment-Werkzeug für reale Anwendungen. Der simulierte Störungszustand wird absichtlich erzeugt; keine echte Infrastruktur wird verändert.

Visualisierte Testergebnisse

Mietdauer	Sollwert in Cent	Version 1.1	Version 1.2
1 Stunde	600	600 ✓	600 ✓
2 Stunden	800	800 ✓	800 ✓
3 Stunden	900	800 ✗	900 ✓
4 Stunden	1100	1000 ✗	1100 ✓

BESTANDENE TESTS

Version 1.1  ■■□□  2/4  STOP
Version 1.2  ■■■■  4/4  FREIGABEFÄHIG

Legende:
■ Test bestanden
□ Test fehlgeschlagen

Auswertung: Version 1.1 erfüllt das Quality Gate nicht. Version 1.2 besteht die vier fachlichen Testfälle und kann im Labor weiter geprüft werden.

Transferfrage: Reichen vier bestandene Berechnungstests aus, um eine reale Software produktiv freizugeben?

Feedback: Nein. Für ein reales Release können weitere Prüfungen erforderlich sein, etwa Sicherheit, Integration, Leistung, Datenmigration und Abnahme. Die vier Tests sind nur das bewusst begrenzte Gate dieser Übung.

Gestufte Hilfen für das Release-Labor

Hilfestufe	Unterstützung
Hilfe 1 – Denkhinweis	Berechne zuerst den Preis für drei Stunden ohne Rabatt.
Hilfe 2 – Rechenweg	400 + 3 × 200 = 1000 Cent. Der vereinbarte Rabatt beträgt 100 Cent.
Hilfe 3 – Lösung	Der Sollwert ist 900 Cent. Version 1.1 liefert 800 Cent und muss deshalb beim Gate scheitern.

Arbeite zuerst ohne Hilfe und verwende bei Bedarf schrittweise die nächste Stufe.

Lerneinheit 4: Automatisierte Tests ergänzen

Dauer: 15 Minuten

Erstelle im gleichen Verzeichnis die Datei test_release_lab.py:

import unittest
from release_lab import preis, pruefen

class TestRelease(unittest.TestCase):

    def test_alte_version(self):
        self.assertEqual(preis("1.0", 3), 1000)

    def test_vor_rabattgrenze(self):
        self.assertEqual(preis("1.2", 2), 800)

    def test_rabattgrenze(self):
        self.assertEqual(preis("1.2", 3), 900)

    def test_fehlerhafte_version(self):
        self.assertFalse(
            all(ok for _, ok in pruefen("1.1"))
        )

    def test_ungueltige_stunden(self):
        with self.assertRaises(ValueError):
            preis("1.2", 0)

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

Lokal ausführen:

python3 -m unittest -v test_release_lab.py

Erwartetes Ergebnis:

Ran 5 tests

OK

Die fünf Tests prüfen die Berechnung und die Fehlererkennung. Ein bestandener Test der fehlerhaften Version bestätigt hier ausdrücklich, dass der absichtlich eingebaute Fehler erkannt wird.

Experiment: Ändere ausschließlich in Deiner lokalen Kopie den Rabatt der Version 1.2 von 100 auf 200 Cent. Starte die Tests erneut.

Feedback: Der Test für die Rabattgrenze muss nun scheitern. Das ist erwünscht: Der Test schützt die vereinbarte Fachanforderung.

Video: GitLab – Deine erste CI/CD-Pipeline

Beobachtungsauftrag: Erkenne im Video die Phasen Test, Build und Deployment. Die gezeigte Online-Plattform wird für unser lokales Labor nicht benötigt.

Lerneinheit 5: Softwareänderungen zurücknehmen

Dauer: 10 Minuten

Ein Rollback ist eine geplante Rückkehr zu einem früheren, bekannten Softwarestand.

Abbildung: Blue-Green-Deployment als Beispiel für zwei getrennte Softwareumgebungen.

Situation	Entscheidung	Begründung
Staging-Test fehlgeschlagen	Auslieferung stoppen	Fehler vor Freigabe erkannt
Staging erfolgreich, Smoke-Test erfolgreich	Labor-Release akzeptieren	Definierte Prüfkriterien erfüllt
Staging erfolgreich, Smoke-Test fehlgeschlagen	Rollback auslösen	Laufzeitprüfung nicht bestanden

Rollback ist nicht dasselbe wie Git Revert. Ein Git-Revert erzeugt einen neuen Commit zur Umkehr vorheriger Codeänderungen. Ein Deployment-Rollback wechselt dagegen auf einen vorherigen bereitgestellten Softwarestand.

Achtung: Bei realen Systemen können Datenbankmigrationen, Schnittstellen und geänderte Datenformate eine Rücknahme erschweren. Ein Versionswechsel allein stellt nicht automatisch jeden früheren Datenzustand wieder her.

Abbildung: Continuous Delivery stellt eine auslieferbare Version bereit; Continuous Deployment automatisiert zusätzlich die Bereitstellung in der Zielumgebung.

Mini-Aufgabe: Entscheide, ob nach einem fehlerhaften Smoke-Test sofort eine neue, ungetestete Reparaturversion eingesetzt werden sollte.

Feedback: Normalerweise ist die vorbereitete Rücknahme auf einen überprüften Zustand die risikoärmere erste Maßnahme, sofern sie technisch sicher möglich ist.

Lerneinheit 6: Release-Dokumentation

Dauer: 10 Minuten

Eine gute Release-Dokumentation beantwortet: Was wurde geändert? Was wurde geprüft? Was wurde entschieden? Wie kann die Änderung zurückgenommen werden?

Beispiel: Release-Protokoll CR-17

Feld	Beispiel
Änderungs-ID	CR-17
Produkt	Fahrradverleih-App
Ausgangsversion	1.0
Kandidat	1.2
Änderung	Ein Euro Rabatt ab drei Stunden
Testumgebung	Lokales isoliertes Python-Labor
Testergebnis	Vier von vier fachlichen Prüfungen bestanden
Smoke-Test	Gesondert zu protokollieren
Freigabe	Ausschließlich Übungsfreigabe
Rücknahmeziel	Version 1.0
Verantwortliche Person	Im eigenen Übungsbericht ergänzen
Prüfdatum	Im eigenen Übungsbericht ergänzen

Wichtig: Ein echter Release-Bericht benötigt den tatsächlichen Status. Ein erfolgreiches Staging darf nicht als erfolgreiches Deployment ausgegeben werden. Das lokale Skript erzeugt für jeden Durchlauf ein JSON-Protokoll und zeigt es vor dem automatischen Löschen des temporären Arbeitsbereichs an.

Beispiel: Kurze Release Notes

Release 1.2 – Übung
Änderung: Rabatt ab drei Stunden
Korrektur: Rabattbetrag von 200 auf 100 Cent
Test: 4/4 fachliche Staging-Prüfungen bestanden
Freigabe: nur lokale Simulation
Rollback-Ziel: Version 1.0

Mini-Aufgabe: Ergänze eine begründete Freigabe- oder Rücknahmeentscheidung, das Ergebnis des Smoke-Tests und den tatsächlich simulierten Endzustand.

Feedback: Nachvollziehbare Dokumentation trennt Sollzustand, Testergebnis, Entscheidung und aktive Version. Das erleichtert die Fehleranalyse und Übergabe an andere Teammitglieder.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Warum wird eine Testumgebung eingesetzt? (Um Änderungen getrennt von der produktiven Umgebung zu prüfen) (!Um Tests grundsätzlich zu vermeiden) (!Um Kundendaten unkontrolliert weiterzugeben) (!Um auf eine Versionsverwaltung zu verzichten)

Welche Testdaten verwendet unser Release-Labor? (Fiktive Preiswerte) (!Echte Kundendatensätze) (!Produktive Zahlungsdaten) (!Zugangsdaten fremder Systeme)

Welchen Preis liefert Version 1.1 für drei Stunden? (800 Cent) (!600 Cent) (!900 Cent) (!1100 Cent)

Welcher Preis ist für drei Stunden mit dem korrekten Rabatt vorgesehen? (900 Cent) (!800 Cent) (!1000 Cent) (!1200 Cent)

Was geschieht bei einem nicht bestandenen Quality Gate? (Die Freigabe wird gestoppt) (!Die Version wird ungeprüft veröffentlicht) (!Alle Prüfergebnisse werden gelöscht) (!Der Fehler wird als bestanden bewertet)

Welche Prüfung untersucht eine einzelne Berechnungsfunktion? (Unit-Test) (!Lastverteilung) (!Netzwerkmigration) (!Benutzerverwaltung)

Wann wird im lokalen Labor der Smoke-Test durchgeführt? (Nach der simulierten Auslieferung) (!Vor dem Schreiben des Programmcodes) (!Vor der Festlegung der Anforderungen) (!Nur nach dem Löschen des Testprotokolls)

Was bedeutet Rollback im Ausbildungsfall? (Rückkehr zur zuvor aktiven Version) (!Löschen aller Softwareversionen) (!Deaktivieren der Testumgebung für immer) (!Ersetzen des Testberichts durch eine Vermutung)

Was bewirkt Git Revert? (Es erstellt einen Commit zur Umkehr früherer Änderungen) (!Es garantiert die Wiederherstellung jeder Datenbank) (!Es veröffentlicht automatisch eine neue Anwendung) (!Es ersetzt sämtliche Softwaretests)

Was gehört zu einer nachvollziehbaren Release-Dokumentation? (Versionen Testergebnisse Entscheidung und Rücknahmehinweise) (!Nur der Name der programmierten Funktion) (!Ausschließlich eine Erfolgsmeldung) (!Nur eine Liste verwendeter Programmiersprachen)

Feedback zur Selbstkontrolle: Bei Fehlern in den Fragen zu Testumgebung, Quality Gate oder Rollback wiederholst Du die Lerneinheiten 2 und 5. Bei Fehlern zur Preisberechnung prüfst Du die Sollwerte des Ausbildungsfalls.

Memory

Ordne die Fachbegriffe ihren Bedeutungen zu.

Testumgebung	Isolierter Bereich zur Qualitätsprüfung
Quality Gate	Festgelegte Bedingung für den nächsten Prozessschritt
Smoke-Test	Kurze Grundfunktionsprüfung nach einer Auslieferung
Rollback	Rückkehr zum vorherigen Softwarestand
Release Notes	Hinweise zu den Änderungen einer Veröffentlichung
Changelog	Zeitlich geordnete Übersicht relevanter Änderungen

Drag and Drop

Ordne die Begriffe den passenden Phasen zu.

Ordne die richtigen Begriffe zu.	Phase
Änderungsauftrag	Anforderung
Staging	Testumgebung
Quality Gate	Freigabeentscheidung
Smoke-Test	Kurzprüfung
Rollback	Rücknahme

Kreuzworträtsel

Staging	Wie heißt eine Umgebung zur Prüfung eines Release-Kandidaten?
Rollback	Wie heißt die Rückkehr zum vorherigen Softwarestand?
Smoke	Welches Wort bezeichnet den kurzen Grundfunktionstest nach einer Auslieferung?
Version	Wie nennt man eine bestimmte Fassung einer Software?
Changelog	Wie heißt die fortlaufende Liste relevanter Softwareänderungen?
Regression	Wie heißt die Rückkehr eines bereits behobenen Fehlers?

LearningApps

Optionale Zusatzübungen: Die folgende externe Suche gehört nicht zum isolierten Python-Labor. Öffne externe Angebote nur bewusst und verwende dort keine personenbezogenen oder betrieblichen Daten.

Lückentext

Eine Softwareänderung wird zunächst in einer getrennten

überprüft.

Die Bedingungen für einen nächsten Prozessschritt werden durch ein

festgelegt.

Ein Test für eine einzelne Berechnungsfunktion heißt

.

Die alte Version der Fahrradverleih-App trägt die Nummer

.

Der korrekte Rabatt beträgt ab drei Stunden

Cent.

Die absichtlich fehlerhafte Kandidatenversion heißt

.

Die korrigierte Kandidatenversion heißt

.

Eine kurze Grundfunktionsprüfung nach der Auslieferung heißt

.

Die Rückkehr zu einer vorherigen Softwarefassung nennt man

.

Die Dokumentation einer Veröffentlichung enthält das

.

Eine fortlaufende Änderungshistorie heißt

.

Die Python-Klasse für Testfälle wird häufig aus dem Modul

verwendet.

Offene Aufgaben

Bearbeite die Aufgaben in aufsteigender Schwierigkeit. Die Kategorien Basis, Anwendung und Transfer orientieren sich am Ausbildungsniveau.

Leicht – Basisaufgaben

Testumgebung: Zeichne die Trennung zwischen Entwicklung, Testumgebung und produktiver Umgebung. Kennzeichne, wo im Kurs tatsächlich Programmcode ausgeführt wird.
Softwaretest: Berechne die Sollpreise für eine, zwei, drei und vier Stunden Fahrradverleih.
Quality Gate: Formuliere das Freigabekriterium für die vier Preisprüfungen.
Release Notes: Erstelle eine kurze Änderungsnotiz für die korrigierte Rabattfunktion.

Standard – Anwendungsaufgaben

Unit-Test: Erweitere die lokale Testsuite um einen zusätzlichen gültigen Stundenwert und begründe Deinen Erwartungswert.
Fehleranalyse: Ändere den Rabatt in Deiner lokalen Version 1.2 absichtlich und dokumentiere, welcher Test den Fehler erkennt.
Rollback: Simuliere einen fehlgeschlagenen Smoke-Test. Halte die Reihenfolge von Auslieferung, Prüfung, Rücknahme und Dokumentation fest.
Release Management: Erstelle eine Entscheidungsvorlage, mit der Du Version 1.1 ablehnst und Version 1.2 für die nächste Laborprüfung zulässt.

Schwer – Transferaufgaben

Datenbankmigration: Erkläre an einem erfundenen Datenbankschema, weshalb ein Versions-Rollback nach einer Datenbankänderung scheitern kann. Entwickle einen sicheren Testplan.
Continuous Delivery: Entwerfe für eine fiktive Schulbibliotheks-App eine Pipeline mit mindestens drei Qualitätsprüfungen und einer manuellen Freigabe.
Risikomanagement: Vergleiche Rollback, erneute Fehlerkorrektur und gestufte Auslieferung. Begründe, welche Strategie bei unterschiedlichen Fehlersituationen geeignet ist.
Softwarequalität: Erstelle ein kurzes Erklärvideo oder ein Schaubild, das zeigt, wie Testumgebung, Quality Gate, Smoke-Test und Release-Dokumentation zusammenwirken.

Begründetes Feedback zu den offenen Aufgaben

Vergleiche Deine Ergebnisse nach der Bearbeitung mit diesen Kriterien.

Aufgabe	Erwartetes Ergebnis und Begründung
Basis 1	Test und Produktion sind getrennt. Dadurch können Fehler mit fiktiven Daten untersucht werden.
Basis 2	600, 800, 900 und 1100 Cent. Der Rabatt gilt erst ab der vereinbarten Grenze.
Basis 3	Vier bestandene Prüfungen. Ein eindeutiges Gate verhindert willkürliche Freigabeentscheidungen.
Basis 4	Änderung und Fehlerkorrektur werden genannt. Dadurch ist die neue Version nachvollziehbar.
Anwendung 1	Ein zusätzlicher Test besitzt einen berechneten Sollwert. Nur so kann eine Abweichung erkannt werden.
Anwendung 2	Ein absichtlich erzeugter Fehler führt zu einem fehlgeschlagenen Test. Das zeigt die Wirksamkeit der Prüfung.
Anwendung 3	Die aktive Version und der Rücknahmegrund sind dokumentiert. So ist der Endzustand überprüfbar.
Anwendung 4	Version 1.1 wird wegen des Fehlers gestoppt. Version 1.2 besteht das definierte Staging-Gate.
Transfer 1	Datenänderungen benötigen eine eigene Strategie. Ein Code-Rollback allein setzt Daten nicht zwingend zurück.
Transfer 2	Die Pipeline enthält überprüfbare Gates. Eine manuelle Freigabe trennt Bereitstellung und Veröffentlichung.
Transfer 3	Die Strategie berücksichtigt Auswirkungen und Umkehrbarkeit. Nicht jede Störung lässt sich sicher zurückrollen.
Transfer 4	Das Produkt zeigt Ursachen, Entscheidungen und Folgen. Damit wird Prozessverständnis statt Faktenwiedergabe sichtbar.

Lernkontrolle

Bearbeite diese Aufgaben ohne Zugriff auf die Musterlösungen. Begründe jede Entscheidung.

Softwarequalität: In einer Testumgebung bestehen alle Berechnungstests, nach der simulierten Auslieferung scheitert jedoch die Grundfunktion. Entwickle einen Entscheidungsablauf und begründe ihn.
Teststrategie: Eine App besteht fünf Unit-Tests. Erkläre, welche Risiken weiterhin bestehen und welche zusätzlichen Prüfungen sinnvoll wären.
Rollback: Eine neue Version ändert gleichzeitig Berechnungscode und gespeicherte Daten. Entwirf einen Rücknahmeplan unter Berücksichtigung beider Änderungen.
Release-Dokumentation: Zwei Teammitglieder berichten widersprüchliche Testergebnisse. Zeige, welche Angaben im Release-Protokoll fehlen könnten und wie die Nachvollziehbarkeit verbessert wird.
Continuous Delivery: Eine fehlerhafte Version wurde in der Testumgebung erkannt. Vergleiche die Folgen eines sofortigen Stopps mit denen einer ungeprüften Auslieferung.
Risikobewertung: Für eine fiktive Schulverwaltung wurde eine neue Funktion entwickelt. Entwerfe drei überprüfbare Freigabekriterien und begründe deren Bedeutung.

Bewertungskriterien: Fachlich richtige Zusammenhänge, nachvollziehbare Argumentation, klare Trennung der Umgebungen, geeignete Testfälle, sichere Rücknahme und vollständige Dokumentation.

Lernnachweis

Für einen erfolgreichen Lernnachweis reichst Du ein kurzes, überprüfbares Portfolio ein.

Änderungsauftrag: Die fachliche Anforderung einschließlich Rabattgrenze ist dokumentiert.
Testprotokoll: Die lokalen Testergebnisse der Versionen 1.1 und 1.2 sind nachvollziehbar festgehalten.
Automatisierter Test: Der lokale Testcode enthält mindestens einen selbst ergänzten Testfall.
Freigabeentscheidung: Du begründest anhand der festgelegten Prüfkriterien, warum eine Version gesperrt oder zugelassen wird.
Rücknahme: Du beschreibst und demonstrierst den simulierten Rollback mit Angabe der anschließend aktiven Version.
Release-Bericht: Änderungen, Versionen, Teststatus, Entscheidung, Prüfdatum, Verantwortlichkeit und Rücknahmeziel sind enthalten.
Reflexion: Du erläuterst mindestens zwei Grenzen der Labor-Simulation gegenüber einer realen Softwareauslieferung.

Mindestanforderung: Der Lernnachweis muss zeigen, dass Du nicht nur einen Programmablauf ausführst, sondern Testergebnisse auswertest und technische Entscheidungen begründest.

OERs zum Thema

Der Wikipedia-Artikel zu Continuous Delivery erklärt die Grundlagen wiederholbarer Softwareauslieferung.

Weitere offene Lernressource: Softwaretest auf Wikipedia

Fachlich geprüfte Quellen

ISTQB – Certified Tester Foundation Level: Teststufen, Testprozess und Testmanagement.
Python-Dokumentation – unittest: Automatisierte Softwaretests.
Python-Dokumentation – tempfile: Temporäre Arbeitsbereiche.
Git-Dokumentation – git revert: Umkehr von Änderungen in der Versionsverwaltung.
Google SRE – Canarying Releases: Sichere, gestufte Auslieferung und Risikobegrenzung.
Keep a Changelog: Verständliche Änderungsdokumentation.
OWASP DevSecOps Guideline: Sicherheitsprüfungen im Software-Lebenszyklus.

Hinweis zur Einordnung: Das lokale Python-Labor ist ein didaktisches Modell. Seine Freigabeentscheidungen sind keine Zertifizierung oder vollständige Qualitätssicherung einer realen Software.

Mediennachweise und Nutzungsrechte

Die eingebundenen Bilder wurden anhand ihrer Wikimedia-Commons-Dateiseiten ausgewählt. Die folgenden Angaben nennen die jeweiligen Urheber und Lizenzen.

Medium	Urheber	Lizenz
Software Release Lifecycle	Heyinsun und Tiger66	CC BY 3.0
Basic Git Branching Workflow	TheresNoTime	CC BY-SA 4.0
Testing Pyramid	Abbe98	CC BY-SA 4.0
Wikimedia CI Workflow	Antoine Musso und Wikimedia Foundation	CC BY-SA 3.0
Continuous Delivery Process	Grégoire Détrez, nach Jez Humble	CC BY-SA 4.0
Blue-Green Deployment	Ssweene2	CC BY-SA 4.0
Delivery vs. Deployment	Joe2026	CC0 1.0

Videos: Die eingebundenen YouTube-Videos stammen von IBM Technology und GitLab. Sie werden von ihren jeweiligen Anbietern bereitgestellt. Eine freie Lizenz für Weiterverbreitung wird hier nicht behauptet. Die Wiedergabe kann Verbindungen zur externen Videoplattform auslösen.

Datenschutz: Das Python-Labor arbeitet vollständig offline. Für das Bearbeiten der Programmieraufgaben sind weder YouTube noch LearningApps oder andere externe Dienste erforderlich.