Das Formular lässt sich ausfüllen, ein Klick erzeugt eine grüne Meldung, die Präsentation ist gelungen. Trotzdem kann die Anwendung im Alltag scheitern: Der Vorgang wurde nicht gespeichert, eine zuständige Person sieht ihn nicht oder das nachgelagerte System hat ihn nie erhalten. Wer Software beurteilen soll, braucht deshalb mehr als einen überzeugenden Bildschirm.
Eine fachliche Prüfung folgt dem Arbeitsvorgang vom Auslöser bis zum verwertbaren Ergebnis. Sie macht sichtbar, was auf welchem Stand tatsächlich funktioniert und welche Fragen offenbleiben. Das hilft bereits bei Zwischenlieferungen; bis zum Projektende damit zu warten, macht Korrekturen unnötig spät.
Aus einer Anforderung wird ein prüfbarer Ablauf
„Anträge digital bearbeiten“ beschreibt ein Ziel, noch keinen Nachweis. Konkret wird es mit einer Rolle, passenden Ausgangsdaten, einzelnen Schritten und einem erwarteten Endzustand. Beispielsweise: Eine Sachbearbeiterin prüft einen eingegangenen Antrag, fordert eine fehlende Anlage an und setzt die Bearbeitung nach deren Eingang fort.
Zum Prüffall gehören die verwendete Version und Umgebung. Ein erfolgreich geprüfter Entwicklungsstand ist keine Aussage darüber, was bereits beim Kunden installiert wurde. Ebenso sollten Testdaten realistische Eigenschaften besitzen, ohne unnötig personenbezogene Daten zu verwenden.
Ein fiktives Beispiel: Vom Antrag zur freigegebenen Bearbeitung
Ein Unternehmen lässt ein Portal für Wartungsanfragen entwickeln. Ein Standort meldet einen Defekt, die Zentrale prüft die Anfrage und gibt einen Auftrag frei. In einer vollständigen Prüfung reichen Anmeldung und Absenden nicht aus. Der Standort muss eine eindeutige Vorgangsnummer erhalten. Die Zentrale muss genau diesen Vorgang mit den richtigen Angaben sehen. Nach der Freigabe muss der vereinbarte Folgeschritt ausgelöst werden.
Anschließend wird der Vorgang erneut geöffnet. Status, Freigabe und Zuordnung müssen weiterhin stimmen. Eine Person eines anderen Standorts darf die Anfrage nicht sehen. Falls ein Fremdsystem beteiligt ist, wird auch dessen Übernahme geprüft oder ausdrücklich als noch offen gekennzeichnet.
Damit stehen drei Beobachtungen nebeneinander: Was meldet die Oberfläche? Was kann die nächste Rolle tun? Welcher Zustand ist dauerhaft gespeichert? Stimmen diese drei Dinge nicht überein, ist der Ablauf noch nicht überzeugend nachgewiesen.
Die wichtigen Ausnahmen gezielt auswählen
Es ist weder sinnvoll, nur den glatten Vorführfall zu prüfen, noch jede theoretische Kombination gleich intensiv zu behandeln. Die Auswahl sollte sich an fachlichen Folgen orientieren: Was könnte Daten verlieren, falsche Freigaben erzeugen, fremde Informationen offenlegen oder die Bearbeitung blockieren?
- Fehlende Angaben: Kann die Person den Fehler verstehen und ohne Datenverlust korrigieren?
- Unterbrechung: Was passiert, wenn eine Verbindung während des Speicherns abbricht?
- Wiederholung: Entsteht beim erneuten Absenden ein zweiter Vorgang?
- Gleichzeitige Bearbeitung: Werden Änderungen zweier Personen kontrolliert zusammengeführt oder verständlich zurückgewiesen?
- Fehlende Berechtigung: Bleiben nicht erlaubte Daten und Aktionen auch bei direktem Aufruf geschützt?
Nicht jede Dimension ist in jedem Projekt relevant. Ein rein lesender Bericht braucht beispielsweise andere Fälle als eine zahlungsauslösende Freigabe. Dokumentieren Sie die begründete Auswahl. Ein hoher Testzähler allein sagt wenig über die entscheidenden Risiken aus.
Sieben zusammenhängende Prüffälle finden Sie im fiktiven Entwicklungsbeispiel für ein Freigabeportal – von der Einreichung bis zur Übernahme durch den Einkauf, einschließlich Rechteprüfung, Wiederholung und Verbindungsabbruch.
So sieht ein nützlicher Prüfnachweis aus
Ein vorhandenes Ticket oder eine kleine Abnahmematrix kann je Fall folgende Angaben aufnehmen: Rolle und Voraussetzungen, Schritte, erwartetes Ergebnis, beobachtetes Ergebnis, Versionsstand sowie offene Abweichung mit nächster Handlung. Ein Screenshot kann das Ergebnis unterstützen, ersetzt aber nicht den Nachweis des gespeicherten Zustands oder einer tatsächlichen Übernahme.
Trennen Sie technische Eigenprüfung des Dienstleisters und fachliche Prüfung des Auftraggebers. Der Kunde soll beurteilen können, ob die vereinbarte Arbeit richtig unterstützt wird. Er sollte nicht erst grundlegende Programmfehler finden müssen. Umgekehrt kann der Dienstleister eine fachliche Entscheidung über einen unklaren Sonderfall nicht durch zusätzliche technische Tests ersetzen.
Fehlende Zugänge oder nicht verfügbare Zielsysteme führen zu einem offenen Prüffall. Benennen Sie, was konkret fehlt, wer es bereitstellt und welche Aussage deshalb noch nicht möglich ist. „Lokal geprüft“ und „im Zielsystem bestätigt“ sind zwei unterschiedliche Ergebnisse.
Was Sie bei der nächsten Lieferung verlangen können
Bitten Sie um einen vollständigen typischen Vorgang, einen wichtigen Fehlerfall und die Liste noch offener Nachweise. Fragen Sie anschließend: Welche fachliche Arbeit kann damit tatsächlich erledigt werden? Was bleibt bis zur nächsten Lieferung eingeschränkt? Die formale Abnahme richtet sich nach Ihrer Vereinbarung; der hier beschriebene Prüfnachweis schafft die fachliche Grundlage dafür.
Den konkreten Fall einer Fehlermeldung nach dem Absenden behandeln wir separat. Für die Projektsteuerung gehören diese Ergebnisse neben die Restaufwandsprognose. Und vor einer Übernahme durch ein anderes Team folgt eine eigene Prüfung: ob sich die Anwendung anhand der technischen Übergabe reproduzieren lässt.
Was wir dafür aus unserer Praxis nutzen
In unserer Projektarbeit gibt es dokumentierte Fehlerprüfungen, bei denen zunächst der gemeldete Bedienweg reproduziert und nach der Korrektur derselbe Weg erneut geprüft wurde. In einem anderen laufenden Projekt wird positives Feedback aus einem Kundenteiltest getrennt von der noch folgenden Fachprüfung behandelt. Der hilfreiche Grundsatz dahinter: Ein bestandener Teiltest darf nicht stillschweigend zur Aussage über die ganze Anwendung werden.
Die Reihe: Softwareprojekte verlässlich beauftragen
- Budget und Restkosten
- Vollständige Abnahme – dieser Artikel
- Technische Übergabe
- Ansprechpartner und Vertretung
- Betrieb und Verantwortung
Zur Übersicht der fünf Projektrisiken und Entscheidungshilfen