Software Abnahme Checkliste: So prüfst du ohne IT-Kenntnisse

Mit einer Software Abnahme Checkliste prüfst du, ob die gelieferte Anwendung die schriftlich vereinbarten Aufgaben erfüllt. Dafür brauchst du keine Programmierkenntnisse, sondern konkrete Testfälle mit erwarteten Ergebnissen. Spiele die Arbeitsabläufe selbst durch und halte fest, wo das Ergebnis abweicht.

Kurz gesagt: Prüfe vollständige Aufgaben mit vorbereiteten Testdaten. Dokumentiere für jeden Test das erwartete und das tatsächliche Ergebnis. Eine Vorführung ersetzt weder eigene Tests noch technische Nachweise.

Stand: Oktober 2026. Dieser Ratgeber erklärt die praktische Ergebnisprüfung und ersetzt keine Rechtsberatung. Welche rechtlichen Folgen eine Abnahmeerklärung für dein Projekt hat, klärst du bei Unsicherheit mit einem Anwalt.

Was kannst du ohne IT-Kenntnisse selbst prüfen?

Du kannst prüfen, ob du mit der Software die vereinbarten Aufgaben erledigen kannst. Ob der Programmcode sicher und gut wartbar ist, lässt sich durch Ausprobieren allein nicht feststellen.

Angenommen, du erstellst Angebote bisher in Excel. Die neue Anwendung soll Kundendaten übernehmen, Leistungen zusammenrechnen und ein Angebotsdokument erzeugen. Dann teste den gesamten Weg: vom Auswählen des Kunden bis zum erneuten Öffnen des gespeicherten Angebots.

Vielleicht zeigt die Eingabemaske alle Positionen korrekt an, im PDF fehlt aber die letzte Zeile. Oder die Bildschirmansicht enthält bereits eine geänderte Summe, während das Dokument noch den alten Betrag zeigt. Solche Fehler erkennst du erst beim Durchspielen der zusammenhängenden Arbeitsschritte.

Prüfe vollständige Aufgaben statt einzelner Schaltflächen. Lass dabei jemanden testen, der später täglich mit der Anwendung arbeitet. Wer bisher Angebote erstellt, weiß etwa, wann Positionen nachträglich ergänzt werden müssen.

Was gehört in eine Software Abnahme Checkliste?

Eine Software Abnahme Checkliste ordnet jeder vereinbarten Anforderung eine nachvollziehbare Prüfung zu. Dafür hältst du Ausgangsdaten, Handlungsschritte und das erwartete Ergebnis fest.

Ein Testfall beschreibt eine bestimmte Situation und das gewünschte Verhalten der Software. Die Bitkom-Praxishilfe zu ausgewogenen Vertragskonzepten sieht für ein Abnahmekonzept unter anderem Testfälle, Testdaten, erwartete Ergebnisse und Kriterien vor. Damit lässt sich später erklären, warum ein Test bestanden wurde oder nicht.

Beginne mit dem Anforderungsdokument, also der schriftlichen Beschreibung dessen, was gebaut werden sollte. Fehlen dort eindeutige Erwartungen, kläre sie vor dem Test. Wie du prüfbare Anforderungen formulierst, zeigt der Ratgeber zum Lastenheft für eine App.

Aus „Angebote erstellen“ wird beispielsweise: „Eine Mitarbeiterin legt ein Angebot mit mehreren Leistungspositionen an, speichert es und öffnet es erneut.“ Erwartet wird, dass alle Positionen erhalten bleiben und die Summe der vorbereiteten Kontrollrechnung entspricht.

Für das angenommene Angebotssystem könnte deine Checkliste so beginnen:

Die Erwartungen müssen zur Vereinbarung passen. Darf ein Entwurf ausdrücklich unvollständig gespeichert werden, wäre das beim Pflichtfeld-Test kein Fehler. Entscheidet solche Fragen vorab, statt während der Prüfung darüber zu streiten.

Wie bereitest du Testdaten und Zugänge vor?

Für die Prüfung brauchst du eine eindeutig benannte Softwareversion, passende Nutzerkonten und bekannte Ausgangsdaten. Kläre außerdem, ob deine Tests echte Nachrichten oder Buchungen auslösen können.

Lass dir möglichst eine Testumgebung geben. Das ist eine getrennte Installation, in der du arbeiten kannst, ohne den laufenden Betrieb zu verändern. Muss die Prüfung im bereits genutzten System stattfinden, vereinbart vorher, welche Aktionen erlaubt sind.

Eine Angebotssoftware darf beim Probieren nicht versehentlich echte Kunden anschreiben. Frage, ob E-Mails an ein Testpostfach gehen oder gar nicht versendet werden. Kläre dasselbe für angebundene Systeme, etwa die Buchhaltung.

Verwende fiktive Kundendaten und vorbereitete Angebote. Berechne die erwarteten Summen unabhängig von der neuen Software. Wenn du deren angezeigte Summe ungeprüft als richtig übernimmst, fehlt dir ein Vergleichswert.

Vor dem Start sollten diese Fragen beantwortet sein:

• Welche Version wird geprüft, und wo ist sie erreichbar?
• Welche Geräte und Browser gehören zum vereinbarten Einsatz?
• Welche Konten brauchst du für die verschiedenen Zugriffsrechte?
• Wie lassen sich Testdaten wieder auf den Ausgangsstand bringen?
• Werden verbundene Dienste tatsächlich angesprochen oder im Test nachgebildet?
• Wer beantwortet Fragen, und wo sammelst du Fehlerberichte?

Während eines Testdurchlaufs sollte die Version unverändert bleiben. Wird eine Korrektur eingespielt, halte den Versionswechsel fest. Sonst weiß später niemand sicher, welches Ergebnis zu welchem Stand gehört.

Welche Fehlerfälle solltest du ausprobieren?

Teste neben dem vorgesehenen Ablauf auch typische Eingabefehler und Unterbrechungen. Prüfe dabei jeweils, ob die Anwendung so reagiert, wie es vereinbart wurde.

Fehlende oder ungewöhnliche Eingaben

Lass ein Pflichtfeld leer oder gib einen langen Firmennamen ein. Prüfe, ob der Text vollständig im PDF erscheint und Fehlermeldungen das betroffene Feld nennen.

Eine Meldung wie „Fehler aufgetreten“ hilft beim Ausfüllen kaum weiter. „Bitte eine Rechnungsadresse ergänzen“ sagt dagegen, was zu tun ist. Halte unklare Meldungen als eigenen Punkt fest.

Doppelte Klicks und Unterbrechungen

Klicke beim Speichern erneut, gehe zurück und lade die Ansicht neu. Entsteht dabei ein doppeltes Angebot? Bleiben bereits gespeicherte Änderungen erhalten?

Noch nicht gespeicherte Eingaben sind ein eigener Fall. Kläre vorher, ob die Anwendung sie nach einem Neuladen wiederherstellen soll. Nicht jede unerwartete Reaktion widerspricht automatisch der Vereinbarung.

Ist Arbeiten ohne Internet vorgesehen, gehört ein Verbindungsabbruch in den Test. Führe solche Versuche in der dafür vorgesehenen Testumgebung durch.

Konten mit unterschiedlichen Rechten

Zugriffsrechte bestimmen, welche Daten und Funktionen ein Nutzer verwenden darf. Prüfe mit getrennten Konten für die vorgesehenen Rollen, etwa Geschäftsführung und Sachbearbeitung.

Ein Administratorkonto mit Zugriff auf alles bildet den späteren Arbeitsalltag nicht ab. Prüfe bei eingeschränkten Konten auch Direktlinks auf gesperrte Ansichten. Ein ausgeblendeter Menüpunkt allein beweist keine wirksame Zugriffssperre; eine umfassende Sicherheitsprüfung ersetzt dieser Versuch allerdings nicht.

Datenübergabe an andere Systeme

Eine Schnittstelle ist eine technische Verbindung, über die Programme Daten austauschen. Soll ein Angebot an ein anderes System übertragen werden, kontrolliere den angekommenen Datensatz dort.

Die Meldung „Erfolgreich übertragen“ reicht als Nachweis nicht aus. Stimmen Kunde und Angebotspositionen im Zielsystem? Lass dir außerdem zeigen, woran du eine fehlgeschlagene Übertragung erkennst und wie sie erneut gestartet wird.

Wie meldest du Fehler nachvollziehbar?

Ein brauchbarer Fehlerbericht beschreibt, wie das Problem entsteht und was stattdessen passieren sollte. Mit „Speichern geht nicht“ kann das Entwicklungsteam oft wenig anfangen.

Notiere die Schritte direkt beim Test. Ergänze die Softwareversion und den Testzeitpunkt, bei Darstellungsfehlern außerdem Gerät und Browser. Ein Screenshot zeigt das sichtbare Problem; eine kurze Bildschirmaufnahme kann die Reihenfolge deiner Aktionen erklären.

Ein fiktiver Fehlerbericht für das Angebotssystem könnte so aussehen:

Testfall: Angebotsentwurf ändern. Konto: Sachbearbeitung. Schritte: Gespeicherten Entwurf öffnen, eine Leistungsposition ändern, speichern und das PDF neu erzeugen. Erwartet: Das neue PDF enthält die geänderte Position. Tatsächlich: Die Bildschirmansicht ist aktuell, das neu erzeugte PDF zeigt den alten Inhalt.

Beschreibe die Auswirkung auf deine Arbeit. Kann kein Angebot mehr verschickt werden, oder betrifft der Fehler nur einen bestimmten Entwurf? Diese Information hilft, die Reihenfolge der Korrekturen festzulegen.

Trenne Fehler von offenen Fragen und neuen Wünschen. Eine falsch berechnete Angebotssumme ist etwas anderes als der nachträgliche Wunsch nach einer Rabattfunktion. Ist die Erwartung bisher nicht eindeutig beschrieben, klärt zuerst die Anforderung.

Was gehört in das Abnahmeprotokoll?

Das Abnahmeprotokoll hält fest, welche Version geprüft wurde und welche Ergebnisse vorliegen. Auch blockierte und noch nicht ausgeführte Tests gehören hinein.

Verwende klare Statusangaben: „bestanden“, „nicht bestanden“, „blockiert“ und „nicht geprüft“. Ein Test ist beispielsweise blockiert, wenn das benötigte Nutzerkonto fehlt. Nicht geprüft bedeutet nicht bestanden im Sinne einer erfolgreichen Prüfung.

Zum Protokoll gehören:

• Anwendung, Version und Testumgebung
• Datum und beteiligte Personen
• Testfälle mit erwartetem und tatsächlichem Ergebnis sowie Status
• Verknüpfte Fehlerberichte und Aufnahmen
• Offene Fragen und getrennt erfasste Änderungswünsche
• Zuständige Personen und vereinbarte Termine für Korrekturen und erneute Tests

Lass dir behobene Fehler nicht bloß bestätigen. Wiederhole den betroffenen Testfall selbst. Nach einer Korrektur an der Angebotsberechnung solltest du beispielsweise auch das Speichern und die PDF-Ausgabe erneut prüfen.

Ein Regressionstest prüft, ob eine Änderung bisher funktionierende Abläufe beeinträchtigt hat. Frage das Entwicklungsteam, welche Bereiche von der Korrektur betroffen sein können. Daraus ergibt sich, welche weiteren Tests wiederholt werden sollten.

Bei mawu erfolgt die Prüfung gegen das schriftliche Anforderungsdokument. Wie dieser Schritt in die Zusammenarbeit eingebunden ist, steht auf der Seite zu unserem Vorgehen.

Eine rechtliche Abnahmeerklärung ist von der bloßen Dokumentation deiner Tests zu unterscheiden. Welche Erklärung du unterschreibst und wie offene Punkte behandelt werden, solltest du bei Unsicherheit anwaltlich klären.

Wann brauchst du eine technische Prüfung zusätzlich?

Eine technische Prüfung brauchst du für Eigenschaften, die du im normalen Gebrauch nicht zuverlässig beurteilen kannst. Dazu gehören etwa die Absicherung gespeicherter Daten oder das Verhalten bei vielen gleichzeitigen Zugriffen.

Ein schneller Seitenaufruf auf deinem Laptop beweist nicht, dass die Anwendung unter hoher Last funktioniert. Ebenso beweist eine vorhandene Datensicherung noch nicht, dass sich das System daraus wiederherstellen lässt. Bitte für vereinbarte technische Anforderungen um passende Prüfberichte oder eine dokumentierte Wiederherstellung in einer Testumgebung.

Fehlen technische Nachweise, kann eine unabhängige Fachprüfung sinnvoll sein. Welche Prüffelder über das Ausprobieren hinausgehen, erläutert der Ratgeber zum(/ratgeber/ki-generierten-code-pruefen). Diese Prüffelder sind auch für anders entwickelte Software relevant.

Nimm jetzt den wichtigsten Arbeitsablauf aus deinem Anforderungsdokument und schreibe dafür einen vollständigen Testfall. Vereinbare anschließend die nötigen Testzugänge und einen gemeinsamen Ablageort für die Ergebnisse.