Die richtige Antwort steht vor dem Code fest.
Eine Rechnung kann ohne Fehlermeldung laufen und trotzdem die falsche Frage beantworten. In unserem Beispiel zur Softwareproduktivität benötigt eine abgenommene Änderung 190 Personenminuten. Ein verworfener Versuch kostet weitere 95. Die Zahlen sind erfunden. Der Code, der sie zusammenrechnet, gehört zu unserem veröffentlichten Beispiel.[S1]
Die fachliche Regel lautet: Auch verworfene Arbeit kostet Zeit, zählt aber nicht als abgenommenes Ergebnis. Richtig sind daher 285 Personenminuten für eine abgenommene Änderung. Wer durch zwei Versuche teilt, erhält 142,5. Die Zahl sieht plausibel aus, beantwortet aber eine andere Frage.
Wir haben die Rechnung der Seite getestet und zusätzlich eine Fassung mit genau diesem falschen Nenner erstellt. Der gezielte Test hat sie zurückgewiesen. Für die Codeprüfung ergibt sich daraus eine konkrete Frage: Würde unsere Prüfung den Fehler bemerken, der für die spätere Nutzung entscheidend ist?[S1]
Erwartete Ergebnisse müssen nachprüfbar sein.
Schreiben Sie vor einer kleinen Änderung gemeinsam mit der fachlich verantwortlichen Person auf, welche Eingaben zu welchen Ergebnissen führen sollen. Rechnen Sie die Erwartung getrennt vom vorgeschlagenen Code aus. Für unseren Fall ergeben sich die folgenden Prüfungen. Sie zeigen einen begrenzten Prüfumfang, keine allgemeingültige Zahl nötiger Tests.
| Erfundene Eingabe | Erwartetes Ergebnis | Gesuchter Fehler |
|---|---|---|
| Ein abgenommener Versuch: 190 Minuten; ein verworfener Versuch: 95 Minuten | 285 Minuten insgesamt, ein abgenommenes Ergebnis, 285 Minuten je abgenommenem Ergebnis | Versuche als Ergebnisse zählen oder verworfenen Aufwand auslassen |
| Nur der verworfene Versuch mit 95 Minuten | 95 Minuten, kein abgenommenes Ergebnis; der Quotient ist nicht definiert | Null Aufwand je Ergebnis melden, obwohl kein Ergebnis abgenommen wurde |
| Keine Versuche | Null Gesamtminuten und null Ergebnisse; der Quotient bleibt nicht definiert | Eine leere Stichprobe als effiziente Arbeit darstellen |
| Fehlender, negativer oder nicht numerischer Aufwand | Eingabe zurückweisen und die Beobachtung offenlassen | Einen unbekannten Wert stillschweigend als null behandeln |
Die richtige Umsetzung bestand vier gezielte Tests. Anschließend bauten wir zwei Fehler getrennt ein: alle Versuche als abgenommen zählen und bei einem nicht definierten Quotienten null zurückgeben. Beide fehlerhaften Fassungen scheiterten. Damit ist belegt, dass die jeweiligen Testbedingungen diese Fehler erkennen. Daraus folgen weder eine Fehlerquote noch der Nachweis, dass die Tests jeden Fehler finden.[S1]
Wählen Sie für Ihre Änderung einen Fehler aus der tatsächlichen Aufgabe. Eine bereits bezahlte Rechnung in der Liste überfälliger Rechnungen ist ein solcher Fehler. Ein Test, der nur das Vorhandensein einer Liste prüft, würde ihn übersehen.
Die funktionierende Rechnung ersetzt keine Codeprüfung.
Lassen Sie eine qualifizierte Entwicklerin oder einen Entwickler prüfen, was geändert wurde und wie es mit der Anwendung zusammenarbeitet. Entspricht die Umsetzung der vereinbarten Regel? Liest oder verändert sie Daten, greift sie in Berechtigungen ein, ergänzt sie eine Abhängigkeit oder ermöglicht sie eine neue Aktion? Davon hängen die zusätzlichen Prüfungen für Integration und Sicherheit ab.
GitHub beschreibt in seiner aktuellen Dokumentation, dass die Prüfung durch Copilot Probleme übersehen, nicht vorhandene Probleme melden und falschen oder unsicheren Code vorschlagen kann. Der Anbieter empfiehlt sorgfältige Prüfung und Tests. Eine weitere KI-Prüfung liefert Hinweise; ihre Zustimmung belegt keine Einsatzreife.[S2]
Bewahren Sie die geprüfte Codeversion, die Eingaben, die tatsächlichen Ergebnisse und offene Befunde zusammen auf. Ändert sich der Code danach, müssen die betroffenen Teile erneut geprüft werden. Unsere Anleitung zur Agenten-Abnahme behandelt die gesonderte Frage, ob ein vollständiger Agent mit dem vorgesehenen Modell, den Daten und Berechtigungen funktioniert.
Die Freigabe gilt für eine konkrete Version.
Die Person, die das fachliche Ergebnis beurteilt, und die Person mit Freigaberecht brauchen eine ausdrückliche Entscheidung. Halten Sie fest, was bestanden wurde, was ungeprüft bleibt und ob das verbleibende Risiko für diesen Einsatz vertretbar ist. Eine fertig programmierte Änderung ist noch keine Produktionsfreigabe.
Vereinbaren Sie, was bei einem Fehler in der vorgesehenen Umgebung geschieht. Prüfen Sie die Fassung, die wiederhergestellt werden soll, und ob Daten oder Abhängigkeiten ebenfalls betroffen wären. Die älteste verfügbare Version ist nicht automatisch ein vertretbarer Rückweg. Unser vorgeschlagenes Prüfprotokoll hält diese Unterschiede sichtbar.
| Vor der Freigabe | Festhalten |
|---|---|
| Benötigtes Verhalten | Fachlich verantwortliche Person, Beispiele und erwartete Ergebnisse |
| Technische Prüfung | Tatsächliche prüfende Person, genaue Version und offene Befunde |
| Ausgeführte Prüfungen | Eingaben, Ergebnisse und vorgesehene Umgebung; geplante und ausgeführte Tests unterscheiden |
| Freigabe und Fehlerfall | Wer diese Version freigeben darf, welche Grenzen gelten und welche Reaktion im Fehlerfall geprüft wurde |
Das ist eine konkrete Aufgabe in der hybriden Organisation: Menschen und Agenten teilen sich Arbeit, während die Freigabe ausdrücklich bleibt. Nehmen Sie eine kleine Änderung, die fachlich verantwortliche Person und einen qualifizierten Entwickler zusammen. Legen Sie eine Tabelle der erwarteten Ergebnisse fest und lassen Sie einen relevanten absichtlichen Fehler im Test nachweislich scheitern, bevor Sie über die Freigabe entscheiden.
