IT-Projekte & technische Due Diligence
Ein grüner Pipeline-Status oder ein Abnahmevermerk sagt nur dann etwas über einen konkreten Softwarestand aus, wenn Testgegenstand, Umgebung, Testdaten, Ergebnis und Release-Bezug nachvollziehbar verbunden sind. Die technische Rekonstruktion stellt diese Kette her und macht Lücken ausdrücklich sichtbar.
Kurzantwort
Test- und Release-Nachweise werden einem konkreten Quell-, Build- und Deploymentstand zugeordnet. Geprüft wird, was tatsächlich ausgeführt wurde, welche Ergebnisse vorlagen, welche Prüfungen fehlten und ob das ausgelieferte Artefakt nachweisbar aus dem geprüften Stand hervorging.
Vom Prüfgegenstand zur dokumentierten technischen Schlussfolgerung
1. Testnachweise als kontextgebundene Evidenz behandeln
Ein Testergebnis bezieht sich auf einen Testfall, eine konkrete Implementierung, Testdaten und eine Umgebung. Ohne diese Zuordnung kann ein „PASS“ nicht belastbar auf einen anderen Build oder eine spätere Produktion übertragen werden.
Automatisierte Tests liefern häufig zusätzliche Metadaten wie Commit-ID, Pipeline-ID, Runner, Zeitstempel oder Artefaktkennung. Diese Informationen sind für die Rekonstruktion wertvoll, sofern ihre Erzeugung und Aufbewahrung nachvollziehbar sind.
2. Testumfang und nicht geprüfte Bereiche sichtbar machen
Eine hohe Zahl bestandener Tests ist kein Beleg für vollständige Prüfung. Entscheidend ist, welche Anforderungen, Risiken und Codepfade durch die Teststrategie abgedeckt werden. Nicht vorhandene Tests und bewusst ausgeschlossene Szenarien gehören deshalb in die technische Befundlage.
Manuelle Explorations- oder Abnahmetests können gleichwertig relevante Evidenz liefern, wenn Testschritte, erwartetes Ergebnis, beobachtetes Ergebnis und untersuchter Stand dokumentiert sind. Fehlt diese Dokumentation, sinkt die Reproduzierbarkeit.
3. QA-Befunde und Freigabeentscheidungen trennen
Qualitätssicherung kann Fehlerlisten, Severity-Einstufungen, Waiver, bekannte Einschränkungen und Freigabeempfehlungen enthalten. Diese Artefakte sollten nicht zu einem einzigen „QA bestanden“ verdichtet werden.
Eine organisatorische Freigabe kann trotz bekannter Restfehler erfolgen. Technisch ist dann relevant, welche Befunde bekannt waren, für welchen Stand sie galten und ob die ausgelieferte Version die vorgesehenen Korrekturen tatsächlich enthielt.
4. Build- und Release-Provenienz prüfen
Zwischen Quellcode und ausgeliefertem Binärartefakt liegen Build-Werkzeuge, Abhängigkeiten, Konfigurationen und Signierungs- oder Packaging-Schritte. Eine belastbare Release-Rekonstruktion dokumentiert diese Kette soweit es der Prüfauftrag erfordert.
Provenienzinformationen wie in SLSA können helfen, Build-Eingaben, Erzeugungsprozess und Artefaktbezug strukturiert zu erfassen. Fehlen entsprechende Nachweise, ist die Aussage zur Herkunft eines Release-Artefakts entsprechend zu begrenzen.
5. Sicherheits- und Qualitätstests angemessen einordnen
Unit-, Integrations-, System-, Performance- und Sicherheitstests beantworten unterschiedliche Fragen. Ein bestandener Unit-Test ersetzt keine Prüfung der produktiven Konfiguration; ein Vulnerability Scan belegt nicht automatisch die Abwesenheit von Schwachstellen.
Für die Begutachtung wird deshalb festgehalten, welche Testart welche technische Behauptung stützt. Die Bewertung vermeidet es, Ergebnisse eines engen Testbereichs auf Eigenschaften zu übertragen, die gar nicht untersucht wurden.
6. Zeitliche Konsistenz der Nachweiskette sichern
Bei schnelllebigen Projekten können Commit, Pipeline, Build und Deployment innerhalb kurzer Zeit wechseln. Zeitstempel allein reichen nicht immer, wenn Zeitzonen, Nachläufe oder manuelle Wiederholungen eine eindeutige Reihenfolge erschweren.
Eine robuste Rekonstruktion kombiniert daher IDs, Hashes, Pipeline-Metadaten und Releaseinformationen. Wird eine Stufe der Kette nachträglich ersetzt oder erneut erzeugt, ist dies als Revisionsanlass zu dokumentieren.
Bei flaky oder nicht deterministischen Tests ist die einfache Zählung bestandener Läufe besonders wenig aussagekräftig. Wiederholungen, Quarantäne-Regeln und bekannte Instabilitäten gehören in die Rekonstruktion. Ein Test, der nur gelegentlich fehlschlägt, kann auf Race Conditions, Umgebungsabhängigkeiten oder ungeklärte Datenzustände hinweisen und sollte nicht durch automatisches Retry unsichtbar werden.
Bei manuellen Release-Schritten wird dokumentiert, an welcher Stelle die automatisierte Nachweiskette endet. Ein lokal neu gebautes Artefakt, ein nachträglich verändertes Konfigurationspaket oder ein manuell ausgetauschtes Secret kann dazu führen, dass ein ursprünglich geprüfter Build nicht mehr dem produktiven Zustand entspricht.
Release Notes und Changelogs werden nur ergänzend verwendet, weil sie häufig redaktionelle Zusammenfassungen darstellen. Für kritische Aussagen sollte die Zuordnung bis auf technische Artefakte, Pull Requests, Commits oder signierte Pakete zurückgeführt werden, soweit diese verfügbar sind. So bleibt die Freigabekette auch dann nachvollziehbar, wenn Beschreibungen verkürzt oder später angepasst wurden.
Bedeutet eine grüne CI/CD-Pipeline, dass der Release technisch fehlerfrei ist?
Nein. Eine Pipeline bestätigt nur die Schritte und Kriterien, die tatsächlich konfiguriert und erfolgreich ausgeführt wurden.
Nicht getestete Anforderungen, ungeprüfte produktive Konfigurationen oder externe Abhängigkeiten können außerhalb dieses Nachweises liegen.
Für die Begutachtung wird daher nicht nur der Status, sondern der Inhalt und der konkrete Bezug der Pipeline untersucht.
Ist die Untersuchung für diesen Themenbereich nachvollziehbar abgegrenzt?
- Ist jeder relevante Testlauf einem konkreten Commit oder Build zugeordnet?
- Sind Testumgebung, Testdaten und wesentliche Konfigurationen dokumentiert?
- Sind nicht ausgeführte, übersprungene oder fehlgeschlagene Tests sichtbar?
- Sind QA-Befunde von organisatorischen Freigabeentscheidungen getrennt?
- Ist das ausgelieferte Artefakt nachvollziehbar aus dem geprüften Build hervorgegangen?
- Sind Sicherheits-, Performance- und Funktionstests ihrem jeweiligen Aussagebereich zugeordnet?
- Werden Lücken in der Nachweiskette als Unsicherheit statt als bestandene Prüfung behandelt?
Konstruiertes Beispiel
Eine Pipeline zeigt für Commit A vollständige grüne Tests. Das Produktionsartefakt lässt sich jedoch nur auf Build B zurückführen, dessen Commit-Bezug nicht dokumentiert ist. Der technische Befund ist deshalb nicht „Tests bestanden“, sondern eine unterbrochene Nachweiskette zwischen geprüftem Quellstand und ausgeliefertem Release.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Internationaler Standard ISO/IEC/IEEE 29119-1:2022 beschreibt allgemeine Konzepte des Softwaretestens. Quelle öffnen.
- NIST-Leitlinie NIST SP 800-218 SSDF Version 1.1 beschreibt sichere Softwareentwicklungspraktiken über den SDLC. Quelle öffnen.
- Technische Spezifikation SLSA v1.2 stellt ein Modell für Software-Lieferketten und Provenienz bereit. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Anforderungen, Soll-Ist und Abnahme rekonstruieren
- Repository, Commit, Branch und Build
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich IT-Projekte & technische Due Diligence
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
IT-Projektgutachten