Testsequenzen

Was ist das?

Eine Testsequenz bündelt die Testfälle, die an einem Prüfling nacheinander oder parallel durchlaufen werden — inklusive Zeitplan, Zuordnung zu Prüfständen und Abhängigkeiten zwischen den Testfällen. Jede Sequenz gehört zu einem Projekt und optional zu einem Prüfling.

Der Startzeitpunkt einer Sequenz muss entweder manuell fixiert werden oder sich aus mindestens einer Abhängigkeit zu einer anderen Sequenz ergeben — eines von beiden ist Pflicht, sonst lässt sich die Sequenz nicht anlegen. Den Endzeitpunkt bestimmt immer die Sequenz selbst — er ergibt sich aus Dauer und Zeitplanung der eingeplanten Testfälle und lässt sich nicht mehr manuell überschreiben.

Wiederverwendbare Sequenz-Vorlagen (isTemplate: true) verwaltet man unter „Sequenzen und Testfälle" im Reiter „Templates Sequenzen" — daneben liegt „Templates Testfälle" für die einzelnen Testfall-Definitionen. Beide Reiter zeigen bewusst nur Vorlagen; Suche und Blättern laufen serverseitig über die URL (?q=&page=&tab=). Eine tatsächlich laufende Sequenz eines Projekts steht immer auf der jeweiligen Projektseite.

So benutzt man es

Neue Sequenz anlegen: Auf der Projektseite, Button „Neue Sequenz". Gibt es bereits Sequenz-Vorlagen, öffnet der Button ein Dropdown mit zwei Wegen: „Leere Sequenz anlegen" (nur Name, danach Testfälle einzeln hinzufügen) oder „Aus Template erstellen" (Vorlage und zugehörigen Prüfling wählen — die Sequenz entsteht direkt mit dem vollständigen, in der Vorlage definierten Satz an Testfällen). Ohne vorhandene Vorlagen fehlt das Dropdown und der Button legt direkt eine leere Sequenz an.
Beim Anlegen direkt mitgeben, nicht erst nachträglich pflegen: Sowohl „Leere Sequenz anlegen" als auch „Aus Template erstellen" fragen im selben Dialog Startzeitpunkt (oder Abhängigkeit zu einer anderen Sequenz), Abhängigkeiten zu bereits vorhandenen Sequenzen des Projekts und — im Template-Dialog — die Prüfstandszuordnung je Testfall ab. Die Prüfstandszuordnung ist dort automatisch vorgeschlagen (siehe „Automatischer Prüfstand-Vorschlag" unten) und lässt sich pro Testfall direkt beim Klonen überschreiben, ohne danach jede Zeile einzeln auf der Sequenzseite anzufassen.
Sequenz-Vorlage anlegen: Unter „Sequenzen und Testfälle" → Reiter „Templates Sequenzen", Button „Neues Template". Eine Vorlage lässt sich anschließend wie eine normale Sequenz mit Testfällen befüllen und dann per „Aus Template erstellen" beliebig oft in Projekte übernehmen.
Testfälle einplanen: Auf der Sequenzseite zeigt eine Tabelle alle Testfälle der Sequenz mit Status, Prüfstand, Start, Ende, Dauer und Abhängigkeiten — Prüfstand, Start und Abhängigkeiten lassen sich direkt in der Zeile ändern. „Testfall hinzufügen" öffnet ein seitliches Formular (unabhängig von anderen offenen Dialogen bedienbar, z. B. um dabei gleich einen neuen Prüfstand anzulegen).
Arbeitszeitmodus je Testfall überschreiben: Jeder Testfall hat beim Anlegen/Bearbeiten die Checkbox „Läuft unbeaufsichtigt weiter". Ist sie angehakt, zählt die Dauer kalendarisch durch — Wochenende und Feierabend spielen keine Rolle (Klimakammer-, Vibrations- oder andere Dauerläufe). Ist sie abgewählt, wird der Testfall nur innerhalb der unter Einstellungen → Kalender festgelegten Laborarbeitszeit verplant und über Feierabend/ Wochenende gestreckt (z. B. eine 6-Stunden-Handmessung). Das gilt nur, wenn die Organisation dort auf „Nur Arbeitszeit" gestellt ist — bei „Durchgehend (24/7)" (Standard) rechnet ohnehin jeder Testfall kalendarisch, die Checkbox hat dann keine sichtbare Wirkung. Details zum Org-weiten Modus: kalender.
Mehrere Testfälle auf einmal bearbeiten: Zeilen in der Tabelle auswählen (Kopfzeile für alle) — eine Leiste am unteren Bildschirmrand erlaubt dann, Status zu setzen oder allen ausgewählten Testfällen gemeinsam eine zuständige Person zuzuweisen.
Testfall aus einem Template bearbeiten: Der Stift an einem Testfall im Template (Dialog „ — Testfälle" bzw. Template-Detailseite) öffnet dasselbe vollständige Formular wie unter „Templates Testfälle" — mit allen Feldern, erwarteten Messgrößen, Qualifikationen und erlaubten Prüfständen, vorbelegt mit dem aktuellen Stand. Zusätzlich lässt sich dort die Abhängigkeit im Template ändern. Gespeichert wird immer der komplette Testfall; nicht geänderte Messgrößen und Zuordnungen bleiben erhalten. Die Änderung erzeugt eine neue Version des Testfalls und gilt in allen Templates und Sequenzen, in denen er noch nicht abgeschlossen ist.
Testsequenzen eines Projekts: Auf der Projektseite listet eine Tabelle alle Sequenzen mit Status, Anzahl Testfälle, Start, Ende, Dauer und zugeordnetem Prüfling; Bearbeiten, Löschen und Abhängigkeiten sitzen als Aktionen am Zeilenende.
Doppelbelegungen an einem Prüfstand: Überschneiden sich die Zeitpläne mehrerer Sequenzen an einem Prüfstand, lässt sich das direkt auf der Prüfstand-Detailseite auflösen — durch Verlegen auf einen anderen Prüfstand oder zeitliches Verschieben. Details unter pruefstaende.
Zeitplan-Spalten: Der Zeitplan zeigt links neben dem Diagramm feste Spalten für Start, Ende, Dauer und Status — sowohl je Sequenz als auch, aufgeklappt, je Testfall. Auf schmalen Bildschirmen klappen Dauer und Status zuerst ein, Name/Start/Ende bleiben sichtbar.
Entwurfs-Testfälle sofort im Zeitplan: Ein gerade im Editor hinzugefügter, aber noch nicht gespeicherter Testfall erscheint sofort als gestrichelte, gelb markierte Zeile im Zeitplan („ungespeichert") — noch bevor gespeichert wird. So lässt sich die Auswirkung auf den Zeitplan schon vor dem Speichern beurteilen.
Warnung bei ungespeicherten Änderungen: Solange der Testfall-Editor ungespeicherte Änderungen enthält, fragt die App vor dem Verlassen der Seite nach — egal ob über einen Link innerhalb der App oder beim Schließen des Tabs/Neuladen. Erst nach „Verlassen" gehen die Änderungen verloren.
Revisionsverlauf: Jede Speicherung einer Sequenz — egal ob am Sequenzformular oder an den Testfällen selbst — legt automatisch eine neue Revision an. Der Revisionsverlauf erscheint erst, sobald mindestens eine Revision existiert. Jede Revision zeigt, wer sie erzeugt hat und wann; bei Revisionen aus der Zeit vor dieser Funktion steht dort „—". Eine Notiz zur Revision kann beim Speichern mitgegeben werden; nachträglich ändern lässt sie sich nicht mehr — Notizen sind ein unveränderliches Protokoll.
Revision wiederherstellen: Über „Wiederherstellen" bei einer Revision im Verlauf lässt sich der damalige Stand zurückholen — Name, Zeitplan, Testfälle, Prüfstand-Zuordnung und Abhängigkeiten. Bereits erfasste Ergebnisse und Status werden dabei nie zurückgesetzt: Testfälle, die nach der gewählten Revision hinzukamen und schon eine Durchführung, ein Ergebnis oder Messwerte haben, bleiben erhalten — die Wiederherstellung meldet das als Hinweis. Fehlende Testfälle aus der Revision werden neu angelegt. Ältere Revisionen ohne vollständigen Snapshot stellen nur Name und Beschreibung wieder her; das zeigt der Bestätigungsdialog vorher an.
Revisionsverlauf für Sequenz-Vorlagen: Auch Vorlagen führen einen eigenen Revisionsverlauf — jede Änderung an Name, Beschreibung oder den enthaltenen Testfällen legt eine neue Revision an, sichtbar unten auf der Template-Detailseite. „Bearbeiten" oben auf der Seite öffnet den Dialog für Name/Beschreibung samt optionaler Revisionsnotiz. Da Vorlagen keinen Zeitplan haben, stellt „Wiederherstellen" hier nur Name, Beschreibung, Testfälle und Abhängigkeiten zurück; bereits aus der Vorlage erstellte Sequenzen sind davon nicht betroffen — sie wurden beim Erstellen komplett kopiert und sind seither unabhängig von der Vorlage (siehe „Sequenz-Vorlage anlegen" oben).
CSV-/Excel-Import und -Export der Testfall-Vorlagen: Im Reiter „Templates Testfälle" liefert „Exportieren" alle Testfall-Definitionen als CSV oder Excel (.xlsx). „Importieren" liest dieselbe Struktur wieder ein — anders als bei Prüflingen, Prüfständen und Geräten legt ein Import hier immer neue Testfall-Definitionen an, auch wenn die ID-Spalte gefüllt ist: Testfall-Definitionen sind versioniert, ein Update über den Import würde entweder vorhandene Messgrößen löschen oder bei jedem Re-Import eine neue Revision erzeugen. Vorhandene Testfälle pflegt man über „Bearbeiten". Zeilen ohne Namen werden übersprungen. Nach der Dateiauswahl öffnet sich zunächst eine Vorschau — es wird noch nichts gespeichert. Sie zeigt je Zeile, ob ein neuer Testfall angelegt oder die Zeile übersprungen wird. Erst ein Klick auf „Einträge importieren" schreibt die Daten; „Abbrechen" verwirft die Datei ohne Änderungen.
Bilder zur Testfall-Beschreibung: Ein oder mehrere Bilder lassen sich z. B. für Schaltpläne oder Diagramme zur Erläuterung hinterlegen — entweder direkt im Formular „Neuer Testfall" (Bilder werden dort erst nach dem Anlegen hochgeladen) oder nachträglich auf der Testfall-Detailseite (Reiter „Templates Testfälle" → Testfall anklicken) unter „Bilder". Format PNG oder JPG, maximal 5 MB je Bild, bis zu 10 Bilder je Testfall; Titel ist Pflicht, eine Beschreibung optional. Die Bilder gehören zur Bibliotheksdefinition selbst, nicht zu einer einzelnen Durchführung — sie erscheinen also bei jeder Sequenz, die diesen Testfall verwendet.

Der Statusfluss eines Testfalls

Ein Testfall-Status folgt einem festen Ablauf. Sie können nicht jeden Status von jedem aus wählen — der Status ist Ihr Qualitätsnachweis und soll den Ablauf belegen, nicht ersetzen.

Ausstehend ──▶ In Bearbeitung ──▶ (Durchführung) ──▶ Bestanden / Fehlgeschlagen
     │               │                                          │
     └──▶ Übersprungen / Abgebrochen                            │
                  │                                             │
                  └──▶ Ausstehend                In Bearbeitung ◀┘  (Nachprüfung)

Über das Statusmenü (Badge auf der Detailseite, Board, Gantt, Liste) setzen Sie nur Prozess-Schritte: starten, überspringen, abbrechen, wieder aufnehmen. Das Menü zeigt Ihnen jeweils nur, was von hier aus möglich ist.
„Bestanden" und „Fehlgeschlagen" stehen nicht im Statusmenü. Ein Prüfergebnis entsteht ausschließlich über „Testfall wurde durchgeführt", weil dort Prüfer, Zeitraum, Ist-Ergebnis und Messwerte dazugehören. Ein Ergebnis ohne diesen Beleg wäre kein Nachweis.
Nachprüfung: Ein bewerteter Testfall geht zurück auf „In Bearbeitung", nicht auf „Ausstehend" — die bereits dokumentierte Durchführung bleibt erhalten.
Übersprungen/Abgebrochen heißt „nicht geprüft". Wollen Sie einen solchen Testfall doch prüfen, nehmen Sie ihn zuerst wieder auf („Ausstehend"); erst dann ist eine Durchführung möglich. So bleibt die Umkehr im Verlauf sichtbar.
Es gibt kein „Pausiert" mehr. Der Zustand hatte keine Konsequenz: er blockierte nichts und verlangte keine Begründung. Ein Testfall, der gerade stockt, bleibt „In Bearbeitung" — schreiben Sie eine Notiz dazu, warum. Damit entfällt auch das Pausieren von Projekten und Sequenzen.
Massenänderung: Über die Auswahl mehrerer Testfälle sind nur Prozess-Schritte setzbar. Enthält die Auswahl Testfälle, für die der gewählte Wechsel nicht möglich ist, werden die übrigen geändert und die Zahl der unveränderten gemeldet.

Durchführung und Abweichung erfassen

Durchführung erfassen: Über „Testfall wurde durchgeführt" auf der Testfall-Detailseite werden Prüfergebnis (bestanden/fehlgeschlagen), tatsächliches Ergebnis, tatsächlicher Zeitraum, wer durchgeführt hat und alle Ist-Werte der am Testfall definierten Messgrößen in einem Schritt erfasst. Alle diese Felder sind Pflicht — eine Durchführung ohne vollständigen Beleg lässt sich nicht speichern. Das Prüfergebnis ist dabei nie vorausgewählt: es muss bei jeder Erstfassung bewusst angeklickt werden, damit „Bestanden" nicht aus Versehen als übernommener Standardwert durchgeht. Ausserdem muss das tatsächliche Ende auf oder nach dem tatsächlichen Anfang liegen — sonst erscheint ein Hinweis und der Dialog lässt sich nicht speichern.
Zuständigkeit wechselt zur ausführenden Person: Mit der Erstfassung wird die im Dialog gewählte Person automatisch zur zuständigen Person des Testfalls — der Abschnitt, der vor der Durchführung „Zuständig" heisst, zeigt ab dann „Ausgeführt von" und lässt sich weiterhin manuell ändern.
Abweichung gleich mit erfassen: Im selben Dialog lässt sich unabhängig vom Prüfergebnis „Abweichung dazu erfassen" anhaken — auch bei „Bestanden", etwa für eine Beobachtung, die das Ergebnis nicht kippt. Damit entsteht eine Abweichungsnotiz mit Bezug auf genau diesen Prüfschritt — sie erscheint auf der Testfall-Detailseite und später im Testbericht direkt bei diesem Testfall. Nachträglich geht das ebenso über den Abschnitt „Abweichungen" auf der Testfall-Detailseite, und dort lassen sich auch mehrere Notizen zum selben Testfall erfassen.
Ein fehlgeschlagener Testfall ohne Abweichung wird angezeigt. Der Abschnitt „Abweichungen" weist darauf hin, solange keine erfasst ist.
Anpassung nach der Erstfassung: Sobald eine Durchführung einmal erfasst wurde, öffnet derselbe Button („Ergebnisse anpassen") stattdessen die „Anpassung der erfassten Ergebnisse". Wer ursprünglich durchgeführt hat, bleibt dabei unverändert sichtbar; erfasst wird zusätzlich, wer die Korrektur vorgenommen hat und wann.
Prüfbedingungen und externer Anbieter (optional): Im selben Dialog gibt es zwei freiwillige Felder für den Prüfbericht nach ISO/IEC 17025: „Prüfbedingungen (z. B. Temperatur, Feuchte)" — etwa „23 °C, 45 % r. F." — und „Extern durchgeführt von (Anbieter)", falls das Ergebnis nicht aus dem eigenen Labor stammt. Beide erscheinen auf der Testfall-Detailseite unter dem tatsächlichen Ergebnis und werden bei „Ergebnisse anpassen" mit dem bisherigen Wert vorbelegt; ein geleertes Feld wird dabei entfernt.
Fotos zur Durchführung: Im Abschnitt „Fotos" auf der Testfall-Detailseite lassen sich beliebig viele Fotos hochladen (PNG oder JPG, je maximal 5 MB). „Foto auswählen" öffnet einen Dialog mit Titel (Pflicht), optionaler Beschreibung und Dateiauswahl — hochgeladen wird erst beim Bestätigen im Dialog, nicht schon bei der Dateiauswahl. Das geht unabhängig vom Testfall-Status und auch nachträglich, jederzeit nach der Durchführung. Im Bericht erscheinen diese Fotos je nach Einstellung direkt bei der Testfallseite oder gesammelt in einem Anhang (siehe berichte).

Benötigte Qualifikationen

Am Testfall festlegen: Im Testfall-Formular (Testfall-Bibliothek) wählen Sie unter „Benötigte Qualifikationen" beliebig viele Einträge aus dem Qualifikationskatalog der Organisation (siehe mitarbeiter). Ohne Auswahl darf jeder mit der nötigen Rolle den Testfall durchführen, wie bisher.
Bei der Zuweisung: Fehlt der zugewiesenen Person eine benötigte Qualifikation, erscheint standardmässig nur ein Hinweis — die Zuweisung bleibt möglich, etwa um für die kommende Woche zu planen, wenn die Nachschulung noch aussteht. Unter Mitarbeiter → Qualifikationen lässt sich per Einstellung „Qualifikationsprüfung bei Zuweisung hart" umschalten, dass die Zuweisung in diesem Fall stattdessen blockiert wird.
Bei der Durchführung: immer hart. Wer im Dialog „Testfall wurde durchgeführt" als ausführende Person ausgewählt wird, muss zu diesem Zeitpunkt alle benötigten Qualifikationen gültig besitzen — unabhängig von der Einstellung zur Zuweisung. Fehlt eine, lässt sich die Durchführung nicht speichern. Owner und Admin sehen stattdessen ein Begründungsfeld und können bewusst übersteuern; das wird im Audit-Log gesondert festgehalten.
Rückverfolgbarkeit: Welche Qualifikationen zum Ausführungszeitpunkt verlangt waren, wird beim Abschluss des Prüfschritts eingefroren — eine spätere Änderung am Testfall ändert nicht rückwirkend, wogegen tatsächlich geprüft wurde (wie bei den erwarteten Messgrößen).

Automatischer Prüfstand-Vorschlag

Am Testfall festlegen: Im Testfall-Formular (Testfall-Bibliothek) lässt sich unter „Erlaubte Prüfstände" eine Auswahl konkreter Prüfstände treffen und unter „Erlaubte Prüfstandsgruppen" eine Auswahl von Prüfstandstypen (siehe pruefstaende) — jeder Prüfstand des gewählten Typs kommt dann zusätzlich in Frage. Beide Felder sind optional und lassen sich kombinieren; bleibt beides leer, gilt der Testfall wie bisher als uneingeschränkt — jeder Prüfstand kommt in Frage.
Wo der Vorschlag erscheint: Im Dialog „Sequenz aus Template erstellen" (Abschnitt „Prüfstandszuordnung") wird für jeden Testfall aus der Vorlage automatisch ein Prüfstand vorbelegt, sobald Template, Startzeitpunkt bzw. Abhängigkeiten gewählt sind — statt wie zuvor grundsätzlich mit „Kein Prüfstand" zu starten. Das ist ein reiner Vorschlag: jede Zeile lässt sich weiterhin frei überschreiben, auch auf einen nicht erlaubten Prüfstand.
Wie der Vorschlag zustande kommt: Für jeden Testfall wird anhand seiner geschätzten Dauer und Reihenfolge in der Vorlage ein voraussichtlicher Zeitraum berechnet (dieselbe Terminlogik wie bei einer bereits angelegten Sequenz). Vorgeschlagen wird der erste erlaubte, einsatzbereite Prüfstand (nicht in Wartung/außer Betrieb), der in diesem Zeitraum laut Prüfstandskalender vollständig frei ist — bestehende Sequenzen ebenso wie Reservierungen zählen dabei als Belegung. Zwei sich zeitlich überlappende Testfälle derselben neuen Sequenz bekommen nicht denselben Prüfstand vorgeschlagen.
Wann kein Vorschlag erscheint: Ist kein erlaubter Prüfstand im voraussichtlichen Zeitraum vollständig frei, bleibt die Zeile auf „Kein Prüfstand" — der Vorschlag verzichtet bewusst darauf, eine unsichere Doppelbelegung anzubieten. Die Zuordnung erfolgt dann manuell wie bisher.

Erwartete Messgrößen und automatische Auswertung

Erwartete Messgrößen definieren: Im Testfall-Formular (Testfall-Bibliothek oder „Testfall hinzufügen" innerhalb einer Sequenz) legen Sie je Testfall beliebig viele erwartete Messgrößen an: Kanalname, Einheit, Sollwert und optionale Grenzwerte (Min/Max). Der Kanalname ist der Schlüssel — er muss zu dem Namen passen, unter dem der Prüfstand die Messwerte liefert, und darf pro Testfall nur einmal vorkommen. Grenzwerte leer lassen heißt „nach dieser Seite offen"; ein umgedrehtes Band (Min > Max) lässt sich nicht speichern. Die Grenzwerte hängen bewusst am Testfall und nicht am Prüfstand — derselbe Prüfstand kann für verschiedene Testfälle denselben physischen Kanal mit unterschiedlichen Sollbändern liefern.
Messunsicherheit U (k=2): Je Messgröße lässt sich optional die erweiterte Messunsicherheit in der Einheit der Messgröße angeben (Spalte „U (k=2)", nicht negativ). Sie steht im Prüfbericht neben dem Ergebnis und wirkt bei der Bewertung, wenn das Projekt die Entscheidungsregel „Schutzband w = U" verwendet: dann gilt ein Messwert nur als bestanden, wenn er mindestens U innerhalb der Grenzen liegt (siehe projekte, Abschnitt „Angaben für den Prüfbericht"). Die Sofort-Anzeige „im Bereich/außerhalb" im Durchführungsdialog rechnet bereits mit dieser Regel. Wie die Grenzwerte wird U beim Abschluss des Testfalls eingefroren.
Prüfverfahren / Norm: Das Feld „Prüfverfahren / Norm (inkl. Ausgabestand)" im Testfall-Formular nimmt die angewandte Norm oder Hausmethode auf, z. B. „DIN EN 60068-2-14:2010-04" oder „PV-012 Rev. 3" (höchstens 200 Zeichen). Es erscheint auf der Testfall-Seite, in der Definition jedes Prüfschritts und im Prüfbericht; wie alle Felder wird es in der Revision und beim Abschluss eingefroren.
Weg 1 — Einzelwert von Hand: Im Dialog „Testfall wurde durchgeführt" tragen Sie zu jeder erwarteten Messgröße einen Ist-Wert ein (z. B. eine zu einem bestimmten Zeitpunkt abgelesene Messung). Das ist der richtige Weg, wenn nicht kontinuierlich gemessen wird.
Weg 2 — automatisch gegen abgelegte Messdaten: Der Button „Aus Messdaten auswerten" auf der Testfall-Detailseite prüft die zum Testfall abgelegten Messwerte je Kanal (Min/Max/Durchschnitt) gegen die erwarteten Messgrößen und legt daraus automatisch bestanden/fehlgeschlagen fest. Diese Messwerte kommen entweder automatisch per Stream an (REST-Push oder MQTT, siehe messdaten und mqtt-anbindung) oder werden manuell als CSV-Datei hochgeladen — Abschnitt „Messdaten" im Dialog „Testfall wurde durchgeführt", Spalten timestamp,channelName,value,unit und optional quality. Beide Wege landen in derselben Ablage, die Auswertung unterscheidet nicht danach.
Wann die automatische Auswertung nicht funktioniert: Es müssen bereits Messwerte zum Testfall vorliegen; enthält ein Kanal Werte mit Qualitätskennzahl unter 80 oder uneinheitlichen Einheiten, bricht die Auswertung mit einer entsprechenden Meldung ab, statt ein unsicheres Ergebnis zu erzeugen. Fehlt für einen gemessenen Kanal eine erwartete Messgröße mit Grenzwerten am Testfall, wird das ebenfalls gemeldet, statt den Kanal stillschweigend zu ignorieren.

Typische Probleme

„Ein Messwert liegt innerhalb der Grenzen, trotzdem steht ‚außerhalb'." Das Projekt verwendet die Entscheidungsregel „Schutzband w = U" und für die Messgröße ist eine Messunsicherheit hinterlegt: bestanden ist dann nur, was mindestens U von beiden Grenzen entfernt liegt. Welche Regel galt, steht über der Messergebnis-Tabelle des Prüfschritts. Ist U größer als das halbe Toleranzband, kann kein Wert mehr bestehen — dann U oder Grenzwerte prüfen.
„Die Messunsicherheit lässt sich nicht speichern." Sie darf nicht negativ sein; leer lassen heißt „nicht angegeben".
„‚Sequenz erstellen' bleibt inaktiv, obwohl Template und Prüfling gewählt sind." Es fehlt noch der Startzeitpunkt oder eine Abhängigkeit zu einer anderen Sequenz — eines von beiden ist Pflicht. Entweder „Manuell festlegen" anhaken und einen Zeitpunkt wählen, oder mindestens eine Abhängigkeit ankreuzen.
„Ich kann den Endzeitpunkt nicht mehr manuell setzen." Das ist beabsichtigt: das Ende einer Sequenz ergibt sich aus den eingeplanten Testfällen, damit Zeitplan und tatsächlicher Testumfang nicht auseinanderlaufen. Nur der Startzeitpunkt lässt sich fixieren.
„Nach dem Wiederherstellen fehlt ein Testfall, den ich erwartet hätte." Vermutlich existiert der zugehörige Testfall in der Bibliothek nicht mehr (gelöscht). Solche Testfälle werden beim Wiederherstellen übersprungen und als Hinweis gemeldet.
„Ein Testfall, den die Revision eigentlich nicht mehr enthält, ist nach dem Wiederherstellen trotzdem noch da." Das Item hat bereits Ausführungsdaten (Status, Ergebnis oder Messwerte) — solche Items werden nie automatisch gelöscht, damit keine Prüfhistorie verloren geht. Sie können es bei Bedarf manuell entfernen.
„Ich möchte eine Revisionsnotiz nachträglich ändern." Notizen sind unveränderlich, sobald die Revision gespeichert ist — sie sind ein Protokoll, keine Freitext-Ablage. Eine neue Notiz entsteht bei der nächsten Speicherung.
„Speichern-Button beim Durchführung-Erfassen bleibt inaktiv." Es fehlt noch mindestens eines der Pflichtfelder: Prüfergebnis (bestanden/ fehlgeschlagen — nie vorausgewählt, muss angeklickt werden), „Durchgeführt von", tatsächliches Ergebnis, Beginn, Ende oder ein Ist-Wert zu einer der definierten Messgrößen. Liegt das Ende vor dem Anfang, erscheint zusätzlich ein Hinweis dazu, und der Button bleibt ebenfalls inaktiv.
„Im Statusmenü fehlen ‚Bestanden' und ‚Fehlgeschlagen'." Das ist beabsichtigt. Ein Prüfergebnis erfassen Sie über „Testfall wurde durchgeführt"; nur dort sind Prüfer, Zeitraum und Ist-Werte dabei.
„Im Statusmenü fehlt der Status, den ich setzen will." Das Menü zeigt nur, was aus dem aktuellen Status möglich ist (siehe „Der Statusfluss eines Testfalls"). Beispiel: von „Bestanden" führt der Weg über „In Bearbeitung", nicht direkt auf „Ausstehend".
„Im Board lässt sich die Karte nicht in jede Spalte ziehen." Spalten, die der Statusfluss nicht zulässt, sind während des Ziehens abgeblendet.
„‚Testfall wurde durchgeführt' ist nicht anklickbar." Der Testfall ist übersprungen oder abgebrochen. Nehmen Sie ihn erst wieder auf, dann können Sie eine Durchführung erfassen.
„Die Durchführung wurde gespeichert, die Abweichung nicht." Das wird als Fehlermeldung angezeigt und heißt genau das: die Durchführung steht, die Abweichung müssen Sie über den Abschnitt „Abweichungen" auf der Testfall-Detailseite nachtragen.
„Mein beaufsichtigter Testfall endet trotzdem über Nacht oder am Wochenende." Zwei mögliche Ursachen: (1) Die Organisation steht unter Einstellungen → Kalender auf „Durchgehend (24/7)" — dann gilt das für alle Testfälle unabhängig von der Checkbox. (2) Der Testfall selbst hat „Läuft unbeaufsichtigt weiter" angehakt, obwohl er beaufsichtigt werden soll — in der Testfall-Bearbeitung korrigieren.
„Nur gültige PNG- und JPEG-Dateien werden unterstützt." beim Foto-Upload. Ein anderes Dateiformat (z. B. PDF, HEIC) wurde ausgewählt — als PNG oder JPG exportieren und erneut hochladen.