Moritz Weinmann
743476f64a
Beide Module wurden aus einem anderen Kundenprojekt kopiert und bereinigt: Knowledgecenter: - Bild-Cache (1.985 Dateien) geleert, Ordnerstruktur mit .gitkeep behalten - Files-Gallery-Lizenzschlüssel entfernt (config.php) - Kundenspezifische Kategorien gelöscht: Teil I/II/III QM-Struktur, nummerierte QM-Kapitel, Gremien (Präsidium/Finanzausschuss/Landesausschuss), Sitzungsservice-Serie, Protokoll-Abteilungen, Testeinträge - 56 generische Kategorien bleiben (Downloads, Onboarding, Personalthemen …) Tasks: - Alle Betriebsdaten gelöscht (114 Tasks, 914 Submissions, 579 Assignments) - Task-Definitionen und Verlinkungen geleert - Kategoriestruktur bleibt (Allgemein, IT, Personal, Buchhaltung …) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
5.2 KiB
5.2 KiB
Task-Cert: Test-Cases (V1)
Diese Tabelle ist als schnelle Abnahme- und Regression-Checkliste gedacht.
| # | Praxisfall (kurz) | Typ | Konfiguration (Beispiel) | Testschritte | Erwartetes Ergebnis |
|---|---|---|---|---|---|
| 1 | Erstunterweisung Arbeitssicherheit | Einmalig | Startdatum 2026-03-01, Fristregel Zyklusende, Zertifikat aus |
Aufgabe anlegen, Zuweisung materialisieren | Genau eine Zuweisung mit cycle_key=once, Status open, kein Zertifikat |
| 2 | Einmaliger Pflicht-Read mit Frist | Einmalig | Startdatum 2026-03-01, Fristregel X Tage nach Startdatum, 5 Tage, Zertifikat aus |
Aufgabe anlegen, Zuweisung prüfen | due_at = 2026-03-06 23:59:59 (tagesgenau je Implementierung), Status nicht completed |
| 3 | Monatliche Hygiene-Schulung | Wiederkehrend (kalenderbasiert) | monthly, Intervall 1, Startdatum 2026-01-01, Frist +5 Tage, Zertifikat Zyklus |
Aufgabe anlegen, Abschluss im Januar durchführen, nächste Periode prüfen | Februar-Periode startet kalenderbasiert, neue Frist wieder +5 Tage; Zertifikat Januar gültig bis Ende Januar-Zyklus |
| 4 | Wöchentliche Team-Checkliste | Wiederkehrend (kalenderbasiert) | weekly, Intervall 1, Startdatum 2026-03-02 (Montag), Fristregel Wochentag=5 (Freitag) |
Aufgabe anlegen, aktuelle Woche prüfen | due_at liegt auf Freitag derselben Zykluswoche |
| 5 | Geräteeinweisung mit individuellem Rhythmus | Wiederkehrend (erledigungsbasiert) | monthly, Basis completion, Startdatum 2026-01-01, Frist +5 Tage |
Periode 1 früh am 2026-01-10 abschließen |
Nächster Start wird nicht vorgezogen; Start bleibt mindestens beim geplanten Intervallstart |
| 6 | Verspätete Nachschulung | Wiederkehrend (erledigungsbasiert) | monthly, Basis completion, Startdatum 2026-01-01, Frist +5 Tage |
Periode 1 spät am 2026-02-20 abschließen |
Nächste Periode startet ab Abschlussanker (2026-02-20), also nach hinten verschoben |
| 7 | Blockierende Periode ohne Abschluss | Wiederkehrend (erledigungsbasiert) | wie Fall 5 | Periode 1 nicht abschließen, Materialisierung erneut ausführen | Keine neue Periode wird angelegt, solange letzte Periode nicht completed ist |
| 8 | Zertifikat 30 Tage gültig | Zertifikat (tagebasiert) | Zertifikat an, Validität days=30 |
Aufgabe abschließen, Zertifikat prüfen | Zertifikat wird ausgestellt und valid_until liegt 30 Tage nach Ausstellung |
| 9 | Dauerzertifikat bei Wiederholung | Zertifikat (dauerhaft) | Zertifikat an, Validität permanent, wiederkehrende Aufgabe |
Zwei Perioden nacheinander abschließen | Älteres Zertifikat bleibt gültig (valid_until leer/NULL), neues Zertifikat kommt zusätzlich dazu |
| 10 | Einzelfall korrigieren im Admin | Admin Einzel-Reset (Erledigt-Tab) | Abgeschlossene Zuweisung mit Einreichung + Zertifikat vorhanden | In Erledigt Aktion Zurücksetzen ausführen |
Für diese Assignment-ID: Einreichungen gelöscht, Zertifikat widerrufen, Zuweisung wieder open, Erfolgsmeldung im Tab |
| 11 | Aufgabe erst ab Startdatum sichtbar | Sichtbarkeit/Startdatum | Startdatum in Zukunft, z. B. 2026-08-01 |
Vor und am Startdatum im User-View prüfen | Vor Startdatum keine sichtbare offene Zuweisung; ab Startdatum sichtbar |
| 12 | Mitarbeiter wechselt Abteilung | Zielgruppen-Sync | Zielregel z. B. Abteilung A; Nutzer wechselt von A nach B | Zuweisungsregeln anwenden (dry-run + apply) |
Nutzer ohne Match wird entfernt, neue Treffer werden angelegt; Include-Override bleibt erhalten |
| 13 | Reminder ab Tag 0 | Eskalation/Reminder | first_escalation_days=0, step_days=7, Reminder aktiv |
Überfällige Assignment neu berechnen | Erste Eskalationsstufe greift sofort bei Überfälligkeit (ohne 1 Tag Wartezeit) |
| 14 | Manuelle Freigabe mit Ablehnung | Freigabeprozess | Methode manual_approval, Submission offen |
Im Freigaben-Tab zuerst Ablehnen, danach erneut einreichen und Freigeben |
Statuswechsel korrekt: awaiting_approval -> rejected -> approved/completed, Zertifikat erst nach finaler Freigabe |
| 15 | Zykluswechsel mit altem Key | Admin-Monitoring (kalenderbasiert) | Aufgabe mit >24 historischen Zyklen, URL enthält gültigen alten cycle_key |
view?id=<task_id>&cycle_key=<alter_key> aufrufen |
Angeforderter Zyklus bleibt selektiert, KPIs/Tabellen laden Daten genau dieses Zyklus |
| 16 | Antworten exportieren (Zyklus) | Admin-Monitoring Export | Kalenderbasierte Aufgabe mit Einreichungen im gewählten Zyklus | In view Zyklus wählen, Button Antworten exportieren klicken |
Download startet als CSV (;, UTF-8 BOM), eine Zeile pro Einreichung inkl. cycle_key, Kontakt, Methode, Status, Zeit, Punkte, answer_summary, answer_detail_json |
| 17 | Antworten exportieren (Snapshot) | Admin-Monitoring Export | Erledigungsbasierte Aufgabe (recurrence_basis=completion) mit aktuellen Einreichungen |
In view Button Antworten exportieren klicken |
Download startet als Snapshot-CSV (latest-Stand), ohne Zyklus-Dropdown, aber mit Antworten der aktuellen Latest-Zuweisungen |
Hinweise zur Durchführung
- Vor jedem Testfall mit festen Startwerten arbeiten (eigene Testaufgabe je Fall).
- Bei wiederkehrenden Fällen Materialisierung und Eskalations-Recalc gezielt auslösen.
- Für reproduzierbare Ergebnisse mit festen Datumswerten testen (keine relativen Angaben wie "heute").