aiMOOC

Projekt Ersatzteilshop und Werkstattdaten – Einen Shopprozess automatisiert testen

QR-Code

Einleitung

Projekt Ersatzteilshop und Werkstattdaten – Einen Shopprozess automatisiert testen

Zielgruppe: Ausbildung in Fachinformatik, IT-Systemmanagement, Handel und Werkstattorganisation. Dauer: etwa 4 Unterrichtsstunden. Ergebnis: ein eigenes, begründetes Projektdossier.

Du prüfst in einer lokalen Simulation, ob Bestellung → Rückmeldung → Rücknahme korrekt funktionieren. Du lernst Testfälle, Testautomatisierung und den Soll-Ist-Vergleich kennen.

Einstieg: Welche Werkstattdaten braucht ein Ersatzteilauftrag – und welche Daten gehören nicht in einen Test?

Sicherheitsgrenze: Nutze ausschließlich einen lokalen oder ausdrücklich autorisierten Testaufbau und frei erfundene Daten. Keine fremden Netze, Produktivsysteme, echten Zugangsdaten oder Kundendaten testen, auslesen oder übertragen. Die folgenden Programme benötigen keine Netzwerkverbindung.

Ausbildungsfall und Projektdossier

Fall: Die fiktive Werkstatt Nordstern benötigt für den fiktiven Auftrag WA-17 einen Innenraumfilter IF-210. Der simulierte Shop hat anfangs 3 Stück. Eine gültige Bestellung umfasst 1 Stück. Die Shop-Rückmeldung meldet B-104: bestätigt. Später wird der Artikel zurückgenommen: R-104. Nur ein als intakt geprüftes Teil geht zurück in den verkaufsfähigen Bestand.

Vorgang	Soll-Status	Shopbestand
Start	bereit	3
Bestellung B-104	bestätigt	2
Rückmeldung zu WA-17	bestätigt	2
Rücknahme R-104, intakt	rückgenommen	3
Rücknahme R-104, beschädigt, in eigenem Testlauf	rückgenommen	2

Dein fortlaufendes Dossier: eine Prozessskizze, eine Tabelle mit Prüf- und Erwartungsdaten, die lokale Simulation, echte Testlauf-Ergebnisse, Fehleranalyse sowie eine eigene begründete Freigabe- oder Nachbesserungsentscheidung. Dokumentiere zu jeder Etappe Datum, Version und Deine Änderung.

Merke: Tabellenwerte hier sind Sollwerte, keine behaupteten Messergebnisse.

Kurze Lerneinheiten

Einheit 1: Systemgrenze festlegen (10 Minuten)

Beobachte: Welche Informationen einer Werkstatt wären sensibel? Im Übungsfall genügen Artikelkennung, Menge und eine fiktive Auftragsnummer.

Dossier 1: Zeichne einen Rahmen um den lokalen Shop. Markiere als Ein- und Ausgaben Artikel, Menge, WA-17, Status, Bestand. Trage außen ein: „Kein Zugriff auf echte Systeme“.

Stufenhilfe: Start: Zeichne zwei Kästen „Werkstatt“ und „Shop“. Weiter: Verbinde sie mit Pfeilen. Profi: Ergänze, welche Daten Du bewusst weglässt.

Einheit 2: Prozess als Skizze verstehen (15 Minuten)

Das Bild zeigt die Grundidee eines Flussdiagramms; zeichne für den Fall einen eigenen Ablauf.

WA-17 → IF-210 bestellen → B-104 bestätigt
                          ↓
                   Rücknahme prüfen
                 ↙                 ↘
               intakt          beschädigt
          Bestand + 1        kein Zugang

Dossier 2: Zeichne einen alternativen Pfad für Menge 0: Bestellung ablehnen, Bestand unverändert.

Feedback: Eine gute Skizze zeigt Entscheidungen und Folgen, weil nur dann auch Fehlerpfade testbar werden.

Einheit 3: Prüfdaten und Rückmeldung (15 Minuten)

Ein Barcodescanner veranschaulicht die eindeutige Artikelidentifikation – nicht die Nutzung realer Werkstattdaten.

Test-ID	Eingabe und Vorbedingung	Erwartetes Ergebnis
T1	Neuer Shop; IF-210, 1, WA-17	B-104 bestätigt; Bestand 2
T2	Neuer Shop; T1, dann Rücknahme „intakt“	R-104; Bestand 3
T3	Neuer Shop; T1, dann Rücknahme „beschädigt“	R-104; Bestand 2
T4	Neuer Shop; IF-210, 0, WA-17	abgelehnt; Bestand 3
T5	Neuer Shop; T1, zweimal Rücknahme „intakt“	zweite abgelehnt; Bestand 3

Dossier 3: Ergänze zu jeder Test-ID später Istwert, bestanden/nicht bestanden, Beleg und Begründung. Beginne jeden Test mit einem neuen Shopzustand.

Feedback: Prüfe immer Status und Bestand, weil eine korrekte Meldung allein einen falschen Lagerwert verdecken kann.

Einheit 4: Lokal simulieren und automatisiert prüfen (35 Minuten)

Die Abbildung skizziert Phasen des Softwaretestens. Hier werden Planung, Ausführung und Auswertung in einer kleinen Übung verbunden.

Voraussetzung: eine lokal installierte, schulisch freigegebene Node.js-Umgebung ab Version 20. Kein Shopkonto und keine externe API. Erstelle zwei Textdateien im gleichen lokalen Ordner.

Datei „shop.mjs“ – vollständig fiktiver Simulator:

export class Shop {
  constructor() {
    this.bestand = 3;
    this.vorgang = null;
  }
  bestellen(artikel, menge, auftrag) {
    if (artikel !== 'IF-210' || menge !== 1 ||
        auftrag !== 'WA-17' || this.vorgang) {
      return { ok: false, status: 'abgelehnt' };
    }
    this.bestand--;
    this.vorgang = {
      bestellnummer: 'B-104', status: 'bestaetigt',
      werkstattauftrag: auftrag
    };
    return { ok: true };
  }
  rueckmelden() {
    return this.vorgang ? { ...this.vorgang } : null;
  }
  ruecknehmen(nummer, zustand) {
    if (!this.vorgang || nummer !== 'B-104' ||
        this.vorgang.status === 'rueckgenommen' ||
        !['intakt', 'beschaedigt'].includes(zustand)) {
      return { ok: false, status: 'abgelehnt' };
    }
    this.vorgang.status = 'rueckgenommen';
    if (zustand === 'intakt') this.bestand++;
    return { ok: true, retourennummer: 'R-104' };
  }
}

Datei „shop.test.mjs“ – automatisierte Prüfungen:

import test from 'node:test';
import assert from 'node:assert/strict';
import { Shop } from './shop.mjs';

test('T1 Bestellung und Rückmeldung', () => {
  const s = new Shop();
  assert.equal(s.bestellen('IF-210', 1, 'WA-17').ok, true);
  assert.deepEqual(s.rueckmelden(), {
    bestellnummer: 'B-104', status: 'bestaetigt',
    werkstattauftrag: 'WA-17'
  });
  assert.equal(s.bestand, 2);
});

test('T2 und T5 intakte Rücknahme nur einmal', () => {
  const s = new Shop();
  s.bestellen('IF-210', 1, 'WA-17');
  assert.equal(s.ruecknehmen('B-104', 'intakt').ok, true);
  assert.equal(s.rueckmelden().status, 'rueckgenommen');
  assert.equal(s.bestand, 3);
  assert.equal(s.ruecknehmen('B-104', 'intakt').ok, false);
  assert.equal(s.bestand, 3);
});

test('T3 beschädigtes Teil nicht einbuchen', () => {
  const s = new Shop();
  s.bestellen('IF-210', 1, 'WA-17');
  assert.equal(s.ruecknehmen('B-104', 'beschaedigt').ok, true);
  assert.equal(s.bestand, 2);
});

test('T4 ungültige Menge ohne Folge', () => {
  const s = new Shop();
  assert.equal(s.bestellen('IF-210', 0, 'WA-17').ok, false);
  assert.equal(s.rueckmelden(), null);
  assert.equal(s.bestand, 3);
});

Lokal ausführen: Öffne ein Terminal in diesem Ordner und gib node --test shop.test.mjs ein. Halte die Ausgabe als Text oder Screenshot im Dossier fest. Nur ein tatsächlich selbst ausgeführter Lauf zählt als Istwert.

Stufenhilfe: Start: Kopiere beide Dateien exakt. Weiter: Vergleiche T1 mit den Prüfdaten. Profi: Ändere testweise nur im lokalen Simulator die Rückbuchung von this.bestand++ zu this.bestand += 2, beobachte den fehlschlagenden Test und stelle den korrekten Code wieder her.

Feedback: Ein roter Test nach der absichtlichen lokalen Änderung ist ein nützlicher Fehlernachweis, weil er zeigt, dass eine Regel tatsächlich geprüft wird.

Einheit 5: Rücknahme bewerten (15 Minuten)

Bildimpuls: Verpackungsschaden ist ein Anlass zur Prüfung, nicht automatisch ein Nachweis für den Zustand des Artikels.

Rücksendungen müssen im Prozess nachvollziehbar dokumentiert werden – hier ausschließlich mit fiktiven Kennungen.

Dossier 5: Erkläre den Unterschied: „Rücknahme akzeptiert“ bedeutet nicht zwingend „wieder verkaufsfähig“. Begründe mit T2 und T3, warum der Bestand unterschiedlich ausfällt.

Feedback: Der beschädigte Artikel darf im Modell nicht als verkaufsfähig eingebucht werden, weil sonst ein falsches Verfügbarkeitsversprechen entstehen kann.

Einheit 6: Testbericht und Transfer (20 Minuten)

Fehlerbericht-Muster: Test-ID · Ausgangslage · Schritte · Soll · Ist · Bedeutung · Korrekturvorschlag · Wiederholungstest.

Dossier 6: Entscheide schriftlich: „Für diesen begrenzten Übungsprozess freigeben“ oder „Nachbesserung nötig“. Belege die Entscheidung mit Deinen tatsächlichen Testergebnissen und einem verbleibenden Risiko. Vier erfolgreiche Prüfungen beweisen nicht die Fehlerfreiheit einer vollständigen Shopsoftware.

Erweiterung: Existiert zusätzlich eine ausdrücklich freigegebene lokale Weboberfläche, kannst Du die gleichen Fachregeln als Browser-End-to-End-Tests mit Playwright formulieren. Das ist hier ein Ausblick, kein Zugriff auf einen fremden Onlineshop.

Microsoft Developer: Playwright in der Testautomatisierung. Schau auf die Zuordnung von Benutzeraktion, Erwartung und Testnachweis.

Joe Colantonio: Regressionstests. Notiere, warum ein Test nach einer Änderung erneut laufen muss.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Wo dürfen die Übungen ausgeführt werden? (In einer lokalen oder ausdrücklich autorisierten Testumgebung) (!In jedem frei erreichbaren Onlineshop) (!In einer fremden Produktionsdatenbank) (!Mit echten Kundenzugängen)

Welche Kennung bezeichnet den fiktiven Werkstattauftrag? (WA-17) (!R-104) (!IF-210) (!B-104)

Wie groß ist der Bestand direkt nach einer gültigen Bestellung? (Zwei Stück) (!Drei Stück) (!Vier Stück) (!Null Stück)

Welche Rückmeldung zeigt die erfolgreiche Bestellung? (B-104 bestätigt) (!R-104 beschädigt) (!IF-210 gelöscht) (!WA-17 gesperrt)

Was ist ein Sollwert im Test? (Ein vorab festgelegtes erwartetes Ergebnis) (!Ein automatisch gemessener Zeitwert) (!Ein beliebiger Beobachtungswert) (!Ein geheimes Kennwort)

Was geschieht mit einem beschädigten Rückläufer im Simulator? (Er erhöht den verkaufsfähigen Bestand nicht) (!Er wird zweimal eingebucht) (!Er löscht den Werkstattauftrag) (!Er erhöht den Bestand immer)

Was muss die zweite Rücknahme derselben Bestellung bewirken? (Ablehnung ohne Bestandsänderung) (!Zweite Gutschrift im Bestand) (!Neue Bestellung) (!Löschen aller Prüfdaten)

Warum beginnt jeder Test mit einem neuen Shop? (Damit Testfälle voneinander unabhängig sind) (!Damit echte Nutzerkonten entstehen) (!Damit das Netz belastet wird) (!Damit keine Ergebnisse verglichen werden)

Was zeigt ein Regressionstest? (Ob eine Änderung bestehende Funktionen beeinträchtigt) (!Ob ein Paket schön aussieht) (!Ob ein Artikel beliebt ist) (!Ob ein Produktivserver erreichbar ist)

Was gehört zur begründeten Projektabgabe? (Testbelege und eine nachvollziehbare Entscheidung) (!Nur eine Behauptung ohne Testlauf) (!Echte Kundendaten) (!Zugangsdaten zum Shop)

Memory

Bestellnummer	B-104
Retourennummer	R-104
Artikelkennung	IF-210
Werkstattauftrag	WA-17
Sollwert	Erwartetes Ergebnis
Istwert	Beobachtetes Ergebnis
Regressionstest	Wiederholung nach Änderung

Drag and Drop

Ordne die richtigen Begriffe zu.	Shopprozess
Bestellung	Auftrag im Shop anlegen
Rückmeldung	Bestellstatus zurückgeben
Rücknahme	Rücksendung abschließen
Prüfdaten	Erwartete Ergebnisse festlegen
Testprotokoll	Beobachtete Ergebnisse belegen

Kreuzworträtsel

Retoure	Wie heißt eine Rücksendung im Handel?
Bestand	Wie heißt die verfügbare Lagermenge?
Testfall	Wie heißt eine einzelne definierte Prüfung?
Status	Wie heißt die Zustandsmeldung einer Bestellung?
Fehler	Was wird bei einer Soll-Ist-Abweichung gesucht?
Dossier	Wie heißt die fortlaufende Sammlung der Projektnachweise?

LearningApps

Suchseite für weitere Übungen; einzelne Treffer sind nicht als passend oder frei lizenziert geprüft.

Lückentext

Für den Ausbildungsfall verwenden wir ausschließlich

Daten.

Die Artikelkennung lautet

.

Der Werkstattauftrag heißt

.

Die gültige Bestellung erzeugt die Nummer

.

Nach der Bestellung beträgt der Shopbestand

Stück.

Die erste Rückmeldung lautet

.

Ein intakter Rückläufer erhöht den

.

Ein beschädigter Rückläufer wird nicht als

eingebucht.

Ein wiederholter Test nach einer Änderung heißt

.

Die abschließende Entscheidung belegst Du im

.

Offene Aufgaben

Leicht – Basis

Datenminimierung: Unterstreiche im Fall nur die nötigen Daten. Feedback: Wenige fiktive Felder genügen, weil Testziele keine realen Kundeninformationen brauchen.
Flussdiagramm: Skizziere Bestellung, Rückmeldung und Rücknahme. Feedback: Verzweigungen machen Fehlerrisiken sichtbar.
Testfall: Schreibe T1 mit Vorbedingung, Eingabe und Sollwert ab und erkläre jede Spalte. Feedback: Ein klares Soll ermöglicht einen objektiven Vergleich.
Lagerbestand: Begründe die Bestände 3, 2 und 3 für die intakte Rücknahme. Feedback: Jede Buchung muss rechnerisch nachvollziehbar sein.

Standard – Anwendung

Testautomatisierung: Führe die lokalen Tests aus und protokolliere Deine echten Ergebnisse. Feedback: Nur beobachtete Werte sind Belege für einen Testlauf.
Fehleranalyse: Baue die angegebene lokale Rückbuchungsabweichung ein und dokumentiere den Fehler. Feedback: Die entdeckte Abweichung belegt die Wirksamkeit Deiner Prüfung.
Rücksendung: Vergleiche intakten und beschädigten Rückläufer im eigenen Diagramm. Feedback: Zustand und Verfügbarkeit müssen getrennt bewertet werden.
Testdokumentation: Erstelle für T4 einen Fehlerbericht mit Soll, Ist und Entscheidung. Feedback: Ein wiederholbarer Bericht beschleunigt die Korrektur.

Schwer – Transfer

Grenzwertanalyse: Entwickle zwei neue ungültige Eingaben und begründe erwartete Reaktionen. Feedback: Grenzfälle decken andere Risiken ab als Normalfälle.
Regressionstest: Entwirf einen Test für eine spätere Änderung der Rücknahmeregeln. Feedback: Neue Regeln dürfen bestehende Schutzprüfungen nicht unbemerkt aushebeln.
Datenschutz: Gestalte ein Poster mit Regeln für zulässige und unzulässige Testumgebungen. Feedback: Eine dokumentierte Systemgrenze schützt Dritte und den Ausbildungsbetrieb.
Qualitätssicherung: Präsentiere Deine Freigabeentscheidung mit Tests, Restgefahren und Gegenargument. Feedback: Eine begründete Entscheidung unterscheidet Nachweise von Annahmen.

Lernkontrolle

Prozessanalyse: Weshalb reicht eine grüne Bestellmeldung nicht aus, um den gesamten Vorgang als korrekt zu bewerten?
Lagerverwaltung: Erkläre an einem Beispiel, welche Folge eine doppelte Rückbuchung für die Werkstatt hätte.
Fehleranalyse: Ein Test für beschädigte Ware schlägt fehl, ein Normaltest besteht. Welche Entscheidung triffst Du und warum?
Teststrategie: Entwerfe eine andere sinnvolle Prüfreihenfolge und erkläre ihre Vor- und Nachteile.
Datenschutz: Beurteile den Vorschlag, Testdaten aus echten Werkstattaufträgen zu kopieren. Begründe eine sichere Alternative.
Softwarequalität: Erläutere, weshalb vier bestandene Tests keine generelle Fehlerfreiheit beweisen.

Lernnachweis

Für Deinen eigenen, begründeten Lernnachweis reichst Du ein fortlaufendes Projektdossier ein:

Eine beschriftete Prozess- und Systemgrenzenskizze.
Eine eigene Testtabelle mit mindestens fünf Fachfällen und Sollwerten.
Den lokal verwendeten Simulator und Deine Testdatei beziehungsweise die nachvollziehbaren Dateiinhalte.
Ein datiertes Protokoll mit tatsächlichen Testausgaben, Istwerten und Abweichungen.
Eine dokumentierte Fehlerkorrektur mit erneutem Testlauf.
Eine begründete Freigabe- oder Nachbesserungsentscheidung samt Restrisiko.
Ein kurzes Quellen- und Medienrechteverzeichnis.

Bewertung (je 20 %): Prozessverständnis, Prüfdaten, Wiederholbarkeit, Auswertung/Begründung, verantwortlicher Daten- und Medieneinsatz. Eigenleistung und nachvollziehbare Belege zählen mehr als ein bloß grünes Testergebnis.

OERs zum Thema

Grundlagenartikel zum übergeordneten Fachthema Softwaretest:

Geprüfte Fachquellen:

Node.js: Test Runner und Assertions – Grundlage der lokalen Beispiele.
Playwright: Best Practices und Assertions – für den optionalen Browsertransfer.
Testfall und Testautomatisierung – Fachbegriffe.
Microsoft Learn: Einstieg in Playwright – ergänzendes Lernvideo.

Medienrechte und Quellenbelege: Die eingebundenen Bilder stammen aus Wikimedia Commons. Vor Weiterverwendung beachte jeweils die Dateiseite mit Urheber und Lizenz. YouTube-Einbettung bedeutet nicht automatisch freie Nachnutzbarkeit des Videoinhalts.

Bild-Dateiseite	Urheber	Lizenz
Werkstatt	Stephany5757	CC BY-SA 4.0
Werkstattwerkzeuge	ProjectManhattan	CC BY-SA 3.0
Flussdiagramm	Erik Streb	CC BY-SA 3.0
Barcodescanner	Raimond Spekking	CC BY-SA 4.0
Testprozess	Perfect Happiness	CC BY-SA 4.0
Beschädigtes Paket	Meanwell Packaging	CC BY 2.0
Paketetikett	Meanwell Packaging	CC BY 2.0