Übungsaufgaben zu Teststrategie und Qualitätssicherung

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Teststrategie und
Qualitätssicherung“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/teststrategie
- https://oer-informatik.de/blackboxtests
- https://oer-informatik.de/codecoverage
- Stilbeispiel: https://oer-informatik.de/teststrategie-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Qualitätssicherung
- Teststrategie
- Blackbox-Test
- Whitebox-Test
- Review
- V-Modell
- Regressionstest
- Testkonzept
- Testdaten

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Je Maßnahme 2 Punkte (1 Punkt Maßnahme, 1 Punkt Beschreibung der Wirkung). Konstruktive Maßnahmen vermeiden Fehler; analytische Maßnahmen (Tests, Reviews) zählen hier nicht. Zum Beispiel:

• Prüfbare Anforderungen: Die Altersregeln werden als User Stories mit eindeutigen Akzeptanzkriterien festgehalten („Personen unter 18 sehen keine Aktivität mit Mindestalter 18“). So wissen Entwicklung und Test genau, was gilt.

• Festgelegtes Vorgehensmodell: Das Team arbeitet z. B. nach Scrum mit einer Definition of Done (Code reviewt, Tests grün, Dokumentation aktualisiert). Qualitätsprüfungen sind damit fester Teil jedes Sprints und werden nicht „am Ende“ vergessen.

• Programmier- und Dokumentationsrichtlinien: Einheitliche Benennung, Formatierung und Kommentierung (z. B. Javadoc für jede öffentliche Methode) machen den Code lesbar; Fehler fallen leichter auf und neue Teammitglieder finden sich schneller ein.

• Bewährte Werkzeuge: Versionsverwaltung mit Merge-Requests, eine CI/CD-Pipeline, die bei jeder Änderung baut und prüft, sowie etablierte Bibliotheken (z. B. Spring Security) verhindern ganze Fehlerklassen.

• Zentrale Umsetzung fachlicher Regeln / Architektur: Die Altersprüfung wird an genau einer Stelle (z. B. einer Methode istAltersgerecht() in der Fachlogik) umgesetzt und überall wiederverwendet, statt sie in jeder Abfrage neu zu programmieren.

• Qualifizierung: Schulung der Entwickelnden in Testmethoden (z. B. Zertifikat „Certified Tester“) und in Spring Boot.

• Privacy by Design: Datenschutzvorgaben (Schutzvoreinstellungen für Minderjährige) werden mit der Datenschutzbeauftragten von Anfang an in den Entwurf aufgenommen.

Je richtiger Zeile 0,5 Punkte.

Je Vorteil 2 Punkte (Vorteil 1 Punkt, Erläuterung 1 Punkt), z. B.:

• Frühe und günstige Fehlerbeseitigung: Ein Review braucht keinen lauffähigen Code. Fehler in den Anforderungen (z. B. vergessene Regel „Chat für Minderjährige nur mit Teilnehmenden gemeinsamer Aktivitäten“) werden gefunden, bevor sie programmiert und getestet sind; die Korrektur kostet nur eine Textänderung statt Umbau, Test und neues Release.

• Fehlerarten, die ein Test nicht findet: Ein Test prüft gegen die Anforderungen – sind diese selbst widersprüchlich, unvollständig oder rechtlich falsch, „besteht“ der Test trotzdem. Die Fachfrau für Datenschutz erkennt solche Lücken direkt.

• Gemeinsames Verständnis und Wissenstransfer: Entwicklung, UX und Datenschutz verstehen die Regeln gleich; spätere Missverständnisse und Diskussionen entfallen.

• Ursache statt Symptom: Ein Review zeigt direkt die fehlerhafte Stelle im Dokument, ein fehlgeschlagener Test nur die Wirkung.

Je Reviewart 2 Punkte:

• Walkthrough: Die Autorin bzw. der Autor führt eine kleine Gruppe durch das Arbeitsergebnis (z. B. Schritt für Schritt durch den Code) und erklärt es; die Teilnehmenden stellen Fragen und geben Hinweise. Der Ablauf ist wenig formal, Ziel sind vor allem Verständnis und Wissensaustausch.

• Inspektion: Die formalste Reviewart mit festem Ablauf (Planung, individuelle Vorbereitung mit Checklisten, Sitzung, Nacharbeit, Nachprüfung) und festen Rollen (Moderation, Gutachtende, Protokoll; die Autorin moderiert nicht). Gefundene Fehler werden protokolliert und ihre Behebung kontrolliert; oft werden Kennzahlen erhoben. Ziel ist, möglichst viele Fehler zu finden – geeignet für kritische Teile wie die Altersverifizierung.

Je Argument 2 Punkte (1 Punkt für das, was zutrifft, 1 Punkt für den Denkfehler):

• Argument 1 (Fachwissen der Geschäftsführerin): Richtig ist, dass Clara Neumann die fachlichen Regeln und die Erwartungen der Nutzenden gut kennt; ihre Abnahme klärt, ob die App für ihren Zweck taugt (Validierung). Der Denkfehler: Eine Stunde freies Durchklicken ist kein systematischer Test. Sie sieht nur die Fälle, die ihr gerade einfallen, meist mit ihrem eigenen, volljährigen Konto. Grenzfälle wie ein Konto, das morgen 18 wird, eine Aktivität ab 18 mit voller Warteliste oder das Nachrücken von der Warteliste erreicht sie so kaum – genau in diesem Bereich lag der Fehler im Altsystem.

• Argument 2 (doppelte Arbeit): Richtig ist, dass beide Teststufen das Gesamtsystem von außen betrachten. Der Denkfehler: Sie prüfen gegen verschiedene Grundlagen mit verschiedenen Zielen. Der Systemtest klärt durch das Team, ob alle Anforderungen des Pflichtenhefts vollständig umgesetzt sind (Verifikation), einschließlich nicht-funktionaler Anforderungen wie Last, Sicherheit und Datenschutz, die beim Durchklicken gar nicht sichtbar werden. Die Abnahme setzt einen bestandenen Systemtest voraus – sonst wird sie zur Fehlersuche.

2 Punkte Gegenvorschlag, 1 Punkt Risiko. Zum Beispiel:

Gegenvorschlag: Das Team führt zuerst einen Systemtest auf dem Testserver durch – mit vorbereiteten Testfällen aus dem Pflichtenheft, synthetischen Konten aller Altersgruppen (16, 17 und 18 Jahre, Geburtstag am Testtag) sowie Last- und Sicherheitstests. Erst wenn keine kritischen Fehler mehr offen sind, prüft Clara Neumann zusammen mit einigen Testnutzenden in einer Vorabversion der App anhand der vereinbarten Akzeptanzkriterien, ob die App ihren Zweck erfüllt. Ihr Fachwissen fließt schon vorher ein: Sie sieht die Testfälle zum Jugendschutz durch, bevor der Systemtest startet.

Risiko (eines genügt):

• Ein Fehler beim Jugendschutz gelangt unbemerkt in die Produktion; Minderjährige bekommen wieder Aktivitäten ab 18 angezeigt – mit Schaden für den Ruf der App, Beschwerden von Eltern, möglichem Ärger mit Aufsichtsbehörden und teuren Notfall-Korrekturen.

• Die Abnahme wird zur Fehlersuche, das Release verzögert sich, und die Geschäftsführung verliert viel Zeit mit technischen Fehlern.

Je Teststufe 1 Punkt für die richtige Bezeichnung an der richtigen Stelle, 0,5 Punkte für den richtigen Pfeil „prüft gegen“, 0,5 Punkte für ein passendes Beispiel.

Je Inhalt 2 Punkte (1 Punkt Inhalt mit Beschreibung, 1 Punkt passender Bezug), z. B.:

• Testobjekte, Testziele und Teststrategie: Backend-Version 1.0 mit REST-API und Datenbank; besonders wichtig sind Schutz Minderjähriger, Datenschutz und Verfügbarkeit. Festgelegt wird, welche Teststufen und Verfahren eingesetzt werden: Unit-Tests mit mindestens 80 % Zweigüberdeckung für die Fachlogik, Blackbox-Testfälle aus den Akzeptanzkriterien für die Altersregeln, automatisierte Integrationstests der REST-API, manueller Systemtest vor jedem Release.

• Testumgebung: eigener Testserver mit MariaDB im Docker-Container in derselben Version wie in der Produktion, Test-Apps auf aktuellen Android- und iOS-Geräten sowie im Browser, Werkzeuge (JUnit, Coverage-Werkzeug, Lasttest-Werkzeug).

• Testdaten: synthetische Konten aller Altersgruppen (16, 17, 18, älter) und Aktivitäten mit Mindestalter 16 und 18; keine Echtdaten (siehe g).

• Rollen und Testplan: Wer testet was wann? Entwickelnde schreiben Unit-Tests im Sprint; Jonas Weber und Du pflegen die Integrationstests; Anh Nguyen testet die Barrierefreiheit mit Testnutzenden; Clara Neumann nimmt jedes Release ab. Zeitplan passend zu den Sprints und zum Starttermin.

• Ein- und Endekriterien: Systemtest beginnt erst, wenn alle Unit- und Integrationstests grün sind; Freigabe nur ohne offene kritische Fehler und wenn alle Testfälle zum Jugendschutz bestanden sind.

• Fehlermanagement: Fehler werden im Ticketsystem mit Schweregrad erfasst; Fehler beim Jugendschutz gelten immer als kritisch und blockieren die Freigabe.

• Testdokumentation und Auswertung: Vorlagen für Testfälle und Testprotokolle; Testbericht je Release an Yusuf Demir und Clara Neumann mit Kennzahlen (bestandene/fehlgeschlagene Testfälle, offene Fehler, Testabdeckung).

• Aufwand und Kosten: Schätzung des Testaufwands (z. B. Anteil je Sprint, Kosten für Testgeräte), Aktualisierung im Projektverlauf.

2 Punkte Erläuterung, 2 Punkte Vorgehen.

Erläuterung: Die Datenbank enthält personenbezogene Daten (Namen, Geburtsdaten, Kontakte, Standorte, Teilnahmen), teils von Minderjährigen. Nach der DSGVO dürfen sie nur für den Zweck verarbeitet werden, für den sie erhoben wurden (Zweckbindung, Datenminimierung). Testsysteme sind meist schlechter geschützt und für mehr Personen zugänglich als die Produktion; eine Kopie erhöht das Risiko einer Datenpanne.

Vorgehen (zwei Möglichkeiten genügen):

• Synthetische Testdaten gezielt erzeugen, die alle Äquivalenzklassen und Grenzwerte abdecken (z. B. Konto genau 16 Jahre, 17 Jahre und 364 Tage, 18 Jahre; Aktivitäten ab 16 und ab 18; volle Aktivität mit Warteliste).

• Anonymisierte Daten: Kopie nur nach vollständiger Anonymisierung (Namen, E-Mail-Adressen, Telefonnummern ersetzen, Geburtsdaten verschieben, Standorte vergröbern), sodass kein Personenbezug mehr herstellbar ist.

• Testdatengeneratoren oder Skripte, die realistische Mengen erzeugen (für Lasttests), und standardisierte Testdatensätze, die bei jedem Testlauf identisch geladen werden (Reproduzierbarkeit).

• Problemfälle des Altbestands (z. B. doppelte Konten, ungültige E-Mail-Adressen) nachbilden, statt die Originale zu verwenden.

2 Punkte für zwei zutreffende Merkmale, z. B.: Der Quelltext ist den Testenden nicht bekannt bzw. wird nicht beachtet; das Testobjekt wird nur über seine Schnittstelle von außen betrachtet. Die Testfälle (Eingaben und erwartete Ergebnisse) werden aus der Spezifikation bzw. den Anforderungen abgeleitet, z. B. mit Äquivalenzklassen und Grenzwerten. Die Testfälle können schon vor der Implementierung erstellt werden; ihre Aussagekraft hängt von der Auswahl der Testdaten ab.

2 Punkte für zwei zutreffende Merkmale, z. B.: Der Quelltext ist bekannt. Die Testfälle werden so gewählt, dass bestimmte Anweisungen, Zweige oder Pfade durchlaufen werden; der Erfolg wird als Testabdeckung (Anweisungs-, Zweig-, Pfadüberdeckung) gemessen. Durchgeführt wird er meist von den Entwickelnden, häufig als automatisierter Unit-Test. Das erwartete Ergebnis stammt weiterhin aus der Spezifikation.

• Die Methode enthält eine Sonderregel, die nicht in der Spezifikation steht (Pauschale von 250 Cent ab mehr als 15 km). Jonas hat seine Testfälle aus der Spezifikation abgeleitet und kannte den Code nicht, also wusste er von dieser Grenze nichts. (1 Punkt)

• Alle seine gültigen Testfälle liegen bei höchstens 13 km; die Bedingung entfernungKm > 15 ist dabei nie wahr, der Zweig mit der Pauschale wird nie durchlaufen. (1 Punkt)

• Der Fehler zeigt sich nur, wenn die Entfernung über 15 km liegt und der Wunschbeitrag über dem richtigen Höchstbetrag liegt. Die Qualität eines Blackbox-Tests hängt von der Auswahl der Testdaten ab; Entfernungen über 13 km wie die 19,4 km ab Bad Salzuflen kamen in den Testfällen gar nicht vor. (1 Punkt)

1 Punkt für geeignete Eingaben (Entfernung über 15 km, Wunschbeitrag über 10 Cent je km), 1 Punkt für richtiges erwartetes und tatsächliches Ergebnis. Zum Beispiel:

Ein Testfall wie 19,4 km mit 150 Cent findet den Fehler nicht (erwartet und tatsächlich 150). Über 25 km wirkt der Fehler umgekehrt: Bei 30 km und 300 Cent liefert die Methode 250 statt 300 Cent.

2 Punkte für Auswahl und Widerlegung, 1 Punkt für einen weiteren Vorteil.

Die Methode hat drei if-Anweisungen, also sechs Zweige (jeweils wahr und falsch). Drei Testfälle genügen:

Widerlegung: Mit T1 bis T5 allein wird entfernungKm > 15 nie wahr; nur fünf von sechs Zweigen (rund 83 %) werden durchlaufen, ein Coverage-Bericht markiert hoechstCent = 250; als nie ausgeführt. Das Kriterium Zweigüberdeckung hätte Jonas also gezwungen, eine Entfernung über 15 km zu testen – und dabei wäre ihm die Sonderregel aufgefallen, die in der Spezifikation fehlt. Mit seinen fünf Testfällen wäre der Whitebox-Test gar nicht abgeschlossen gewesen.

Weiterer Vorteil (einer genügt): Die fest eingetragenen Werte 15 und 250 fallen beim Lesen auf und lassen sich durch benannte Konstanten ersetzen oder ganz entfernen; schlägt ein Testfall fehl, ist sofort klar, über welchen Zweig er gelaufen ist.

Begründung (2 Punkte): Der Abnahmetest prüft, ob die App die Anforderungen der Auftraggebenden erfüllt (Validierung). Dafür braucht Thomas Becker nur die Anforderungen und die Oberfläche der App, keine Programmierkenntnisse; er prüft aus Sicht der Nutzenden, z. B. ob ein Angebot über 0,10 € je km abgelehnt wird. Außerdem findet er dabei fehlende Funktionen, die ein Whitebox-Test nicht findet.

Nachteil Whitebox (1 Punkt), z. B.: setzt Kenntnis und Analyse des Quelltextes voraus; findet keine fehlenden Funktionen; bei großen Programmen sehr aufwendig.

Je richtig benannter Testart 1 Punkt, 3 Punkte für die Begründung mit Bezug:

• Oksanas Vorschlag ist ein Fehlernachtest (Bestätigungstest): Der Testfall, an dem der Fehler sichtbar wurde (19,4 km, 250 Cent), läuft erneut und liefert jetzt 194. Damit ist belegt, dass genau dieser eine Fehler beseitigt ist – mehr nicht.

• Der Vorschlag von Jonas Wolff ist ein Regressionstest: Tests, die vor der Änderung schon bestanden wurden, laufen noch einmal. Gesucht werden ungewollte Seiteneffekte der Änderung an Stellen, die selbst gar nicht angefasst wurden.

• Begründung: Auch eine Korrektur ist eine Änderung am Code und kann neue Fehler einschleppen oder bisher verdeckte sichtbar machen. Das zeigt sich oft nicht in der geänderten Methode, sondern dort, wo ihr Ergebnis weiterverarbeitet wird. Beispiel: Hat jemand in der Buchung oder in der Monitoranzeige die 2,50 € aus der Pilotphase als feste Obergrenze nachgebaut, passt diese Stelle nach der Korrektur nicht mehr zur Methode – Mitfahrende sähen auf dem Flurmonitor einen anderen Betrag als bei der Buchung. Das entdeckt nur ein Test der Buchung bzw. Anzeige, nicht der wiederholte Testfall aus bb. Da die Tests bereits automatisiert vorliegen, kostet die Wiederholung kaum Zeit.

Je beschriebener Maßnahme 2 Punkte, z. B.:

• Automatisieren: Testfälle als Unit- und Integrationstests (z. B. JUnit) schreiben, die die CI-Pipeline des Repositorys bei jedem Merge-Request automatisch ausführt; schlägt ein Test fehl, wird die Änderung nicht übernommen. Der Aufwand je Durchlauf ist danach fast null.

• Gefundene Fehler als Test festhalten: Der neue Testfall T6 bleibt dauerhaft in der Testsammlung, damit die Pauschale nicht unbemerkt zurückkehrt.

• Risikobasiert auswählen: Bei jeder Änderung die Tests der betroffenen und der geschäftskritischen Funktionen (Kostenbeitrag, Einwilligung Minderjähriger, Buchung) ausführen, die vollständige Sammlung nächtlich bzw. vor jedem Release.

• Manuelle Tests begrenzen: Für die Oberfläche eine kurze Checkliste der wichtigsten Abläufe (anmelden, Angebot einstellen, Mitfahrt anfragen) und diese schrittweise automatisieren.

Je Maßnahme 1 Punkt, z. B.:

• Code-Review jeder Änderung im Merge-Request (eine zweite Person hätte die Pauschale gegen die Spezifikation geprüft)

• Whitebox-Test mit vorgegebener Mindestabdeckung (z. B. 100 % Zweigüberdeckung für die Preisregeln) und Coverage-Bericht in der Pipeline

• Grenzwertanalyse bei den Blackbox-Testfällen über den gesamten Wertebereich (Entfernungen bis 20 km und mehr)

• statische Codeanalyse (z. B. Hinweis auf „magische Zahlen“ wie 250 und 15)

• Programmierrichtlinie: keine fest eingetragenen Sonderregeln, Werte als benannte Konstanten bzw. Konfiguration

• Testkonzept mit Endekriterium, verbindlicher Definition of Done

• Abnahmetest mit realistischen Fahrten aus dem Einzugsgebiet

• Im User Acceptance Test (Benutzerakzeptanztest) prüfen künftige Nutzende – hier die Beschäftigten aus Kundenservice, Lager, Werkstatt und Buchhaltung – die fertige Anwendung unter möglichst realen Bedingungen. Sie prüfen, ob sie ihre Arbeit damit erledigen können, ob das Portal verständlich und bedienbar ist und ob die vereinbarten Akzeptanzkriterien erfüllt sind (2 Punkte).

• Der Systemtest wird dagegen von einem Test- bzw. Entwicklungsteam durchgeführt und prüft, ob das System die Anforderungen des Pflichtenhefts erfüllt („Haben wir das Produkt richtig gebaut?“). Der UAT fragt, ob es das richtige Produkt für den Zweck der Nutzenden ist (Validierung), und ist oft die Grundlage für die Abnahme (2 Punkte).

Je Voraussetzung 3 Punkte (Nennung 1 Punkt, Erläuterung 2 Punkte), z. B.:

• Die Anwendung ist funktional vollständig. Solange noch an der Anbindung der Werkstatt-Tablets entwickelt wird, ändert sich das Verhalten des Portals nach jeder Änderung. Ergebnisse aus dem UAT wären dann schnell veraltet, und die Werkstatt könnte ihren Teil des Ablaufs gar nicht prüfen.

• Systemtest und Regressionstests sind abgeschlossen, schwere Fehler sind behoben. Der UAT soll die Eignung für die Arbeit prüfen, nicht technische Fehler suchen. Stoßen die Beschäftigten ständig auf Abstürze, sinkt die Akzeptanz, und ihre Zeit wird verschwendet. Offen sein dürfen höchstens kosmetische Mängel.

• Eine realitätsnahe UAT-Umgebung steht bereit: Portal, MDE-Geräte im Lager, Werkstatt-Tablets und Buchhaltungsanbindung wie im späteren Betrieb, mit realistischen, aber datenschutzgerechten Testdaten (keine echten Kundendaten). Unter Laborbedingungen wären die Ergebnisse nicht aussagekräftig.

• Akzeptanzkriterien, Testszenarien und Testpersonen sind vorbereitet: z. B. „Eine Widerrufsretoure wird vom Eintreffen bis zur Gutschrift ohne Papier bearbeitet“; die Beschäftigten sind eingewiesen, haben Zeit eingeplant und wissen, wie sie Fehler melden.

Folgerung: Der UAT sollte erst nach Abschluss von Entwicklung und Systemtest starten.

Je Fehlerart 3 Punkte (Beschreibung 2 Punkte, Fundstelle 1 Punkt):

• Syntaxfehler: Der Quelltext verstößt gegen die Grammatik (Schreibregeln) der Programmiersprache; der Interpreter bzw. Compiler kann ihn nicht übersetzen, das Programm startet nicht. Im Skript fehlt in Zeile 2 der Doppelpunkt nach if ist_widerruf (richtig: if ist_widerruf:). Python meldet einen SyntaxError.

• Semantikfehler (Logikfehler): Das Programm ist syntaktisch korrekt und läuft, liefert aber ein falsches Ergebnis, weil es nicht das Beabsichtigte tut. Im Skript wird der Wertersatz in der letzten Zeile addiert statt abgezogen (richtig: return betrag - abzug). Beispiel: Widerruf, Preis 100,00 €, Versand 5,90 €, 10 % Wertersatz → richtig 95,90 €, das Skript liefert 115,90 €. Einen solchen Fehler findet nur ein Test mit erwartetem Ergebnis oder ein Review.

• Abbruch in Zeile 6 (abzug = preis * wertersatz_prozent / 100): Python versucht, den Text "49,90" mit dem Text "" zu multiplizieren, und meldet TypeError: can't multiply sequence by non-int of type 'str' (1 Punkt).

• Zeile 3 läuft durch, weil + für zwei Zeichenketten erlaubt ist: "49,90" + "4,95" ergibt die Zeichenkette "49,904,95". Es entsteht kein Fehler, aber ein unsinniger Wert – ein Laufzeitfehler kann also erst einige Zeilen später sichtbar werden als seine Ursache (1 Punkt).

Je 1 Punkt für: Umwandlung mit Dezimalkomma in float, leerer Wertersatz wird zu 0, try/except mit verständlicher Meldung, Testlauf läuft nach einer unbrauchbaren Testretoure weiter. Zum Beispiel:

def als_zahl(wert, feld, leer_ist_null=False):
    text = "" if wert is None else str(wert).strip()
    if text == "" and leer_ist_null:
        return 0.0
    try:
        return float(text.replace(",", "."))
    except ValueError:
        raise ValueError(f"{feld}: '{wert}' ist keine gültige Zahl") from None

def erstattung(preis, versandkosten, ist_widerruf, wertersatz_prozent):
    preis = als_zahl(preis, "Preis")
    versandkosten = als_zahl(versandkosten, "Versandkosten")
    wertersatz_prozent = als_zahl(wertersatz_prozent, "Wertersatz", leer_ist_null=True)
    if ist_widerruf:
        betrag = preis + versandkosten
    else:
        betrag = preis
    abzug = preis * wertersatz_prozent / 100
    return round(betrag - abzug, 2)

testretouren = [("49,90", "4,95", True, ""), ("ca. 50", "4,95", False, "")]
for retoure in testretouren:
    try:
        print(erstattung(*retoure))
    except ValueError as fehler:
        print("Testretoure übersprungen:", fehler)

Ausgabe: 54.85 für die erste Testretoure, danach Testretoure übersprungen: Preis: 'ca. 50' ist keine gültige Zahl. Ungültige Eingaben wie "ca. 50" gehören zusätzlich als eigene Testfälle in die Testsammlung.