Arbeiten mit Fehlern
Wenn Sie Tests ausführen, um die Anforderungen zu überprüfen, müssen Sie Fehler suchen. Verwenden Sie die Fehlerarbeitsaufgabe, um für jeden gefundenen Fehler den Status zu beschreiben und nachzuverfolgen. Weitere Informationen zum Erstellen von Fehlerarbeitsaufgaben finden Sie unter Senden von Fehlern. Wenn Fehler gefunden werden, befolgen Sie den Prozess in diesem Thema, um sie zu priorisieren und sicherzustellen, dass sie korrigiert und die entsprechenden Arbeiten und Entscheidungen aufgezeichnet werden.
Im Arbeitsaufgabenformular für einen Fehler werden Daten in den Feldern und auf den Registerkarten gespeichert, die in den folgenden Abbildungen dargestellt werden:
In diesem Thema
Selektieren von Fehlern
Korrigieren eines Fehlers
Schließen eines Fehlers
Selektieren von Fehlern
Selektierungsbesprechungen sollten in festgelegten Intervallen abgehalten werden, nachdem die Entwicklung und Tests für das Projekt gestartet wurden. Die Häufigkeit der Besprechungen und ihre Dauer hängen von der Situation ab.
In der Regel werden Fehlerselektierungsbesprechungen von einem Projektmanager ausgeführt, und an ihnen nehmen Teamleiter und eventuell Business Analysten sowie Projektbeteiligte bei, die sich zu bestimmten Projektrisiken äußern können. Der Projektmanager kann die Abfrage Aktive Fehler für neue und neu geöffnete Fehler verwenden, um eine Liste zu selektierender Fehler zu generieren.
Legen Sie vor Beginn der Selektierung einen Satz von Kriterien fest, um zu bestimmen, welche Fehler mit welcher Priorität behoben werden sollen. Die Kriterien identifizieren i. d. R. den Schweregrad von Fehlern und Fehler, die wichtigen Funktionen mit erheblichem Wert (oder erheblichen Opportunitätskosten) zugeordnet sind, oder andere Projektrisiken.
Die Selektierungskriterien sollten im Ordner Dokumente des Teamprojekts gespeichert werden. Im Zeitverlauf wird das Dokument aktualisiert. Es wird davon ausgegangen, dass die Versionskontrolle für das Projekt aktiviert ist und dass die spezifischen Kriterien, die zu einem beliebigen Zeitpunkt für das Projekt verwendet werden, zu Überwachungszwecken und zum Erfassen von Nachweisen für die Bewertung abgerufen werden können.
Sie entscheiden sich wahrscheinlich zu einem frühen Zeitpunkt des Projekts für die Korrektur der meisten Fehler, die Sie selektiert haben. Jedoch wird möglicherweise im Projektverlauf die Schwelle der Selektierungskriterien erhöht, um die Anzahl der zu korrigierenden Fehler zu verringern.
Die Schwelle für die Selektierungskriterien zu erhöhen und zuzulassen, dass gemeldete Fehler nicht korrigiert werden, ist ein Kompromiss. Der Kompromiss bedeutet, dass die Korrektur der Fehler weniger wichtig als das Einhalten von Umfang, Budget und Zeitplan des Projekts.
Verwenden Sie Ihre Kriterien, um zu bestimmen, welche Fehler korrigiert werden, und wie die entsprechenden Felder Zustand, Priorität, Schweregrad usw. festgelegt werden. Standardmäßig stellt die Vorlage vier Prioritäten bereit: 1 für "muss behoben werden" bis 4 für "unwichtig". Wenn Sie die Definitionen in der Prozessvorlage ändern, müssen Sie die Anweisung, den Hilfetext und sämtliche Kriteriendokumente entsprechend aktualisieren.
Weitere Informationen zum Ausfüllen der Fehlerarbeitsaufgabe finden Sie unter Fehler (CMMI).
Korrigieren von Fehlern
Nachdem die Selektierung für einen Fehler ausgeführt und dieser priorisiert wurde, sollte er dem Entwickler für eine zusätzliche Untersuchung zugewiesen werden.
Die Fehlerarbeitsaufgabe verfügt über die Registerkarte Reproduktionsschritte, die bereitstellt, was Sie zum Reproduzieren des Fehlers benötigen. Sie können jedoch auch IntelliTrace verwenden, um schwierige Fehler zu reproduzieren. Weitere Informationen über IntelliTrace finden Sie unter Einbeziehen diagnostischer Ablaufverfolgungsdaten mit Fehlern, die schwer zu reproduzieren sind und Debuggen mit IntelliTrace.
Nachdem sich der Entwickler für eine Vorgehensweise entschieden hat, sollte er seine Entscheidungen in der Fehlerarbeitsaufgabe dokumentieren.
Entscheiden über die Korrektur
Der Entwickler kann gemeinsam mit anderen Teammitgliedern eine Korrektur empfehlen, die sich auf andere Abschnitte des Codes auswirkt und eventuell erhebliche Regressionstests erfordert. Alle Gespräche, die sich auf die Bewertung des Risikos einer solchen Korrektur beziehen, sollten im Fehlerarbeitsaufgaben-Verlauf aufgezeichnet werden, da in diesem nützliche Nachweise für Entscheidungsanalyse und Risikomanagement dokumentiert werden, die in einer Überwachung oder SCAMPI (Standard CMMI Appraisal Method for Process Improvement)-Bewertung verwendet werden können. Weitere Informationen über CMMI finden Sie unter Hintergrundinformationen zu CMMI.
Aktualisieren und Ausführen von Komponententests für die Fehlerkorrektur
Durch Komponententests wird die korrekte Implementierung einer Codeeinheit überprüft. Durch das Schreiben und Ausführen von Komponententests werden Fehler vor Beginn des Tests erkannt, wodurch die Kosten der Qualitätskontrolle sinken. Entwickler müssen Komponententests für den gesamten Code schreiben, der als Teil der Implementierung einer Entwicklungsaufgabe oder einer Fehlerkorrektur geschrieben wird. Weitere Informationen finden Sie unter Überprüfen von Code mithilfe von Komponententests.
Möglicherweise möchten Sie in einer Entwicklungsstrategie, in der zuerst Tests ausgeführt werden, lieber den Komponententest schreiben, bevor Sie Codekorrekturen durchführen. Dieser Strategietyp wird bei der agilen Softwareentwicklung bevorzugt. CMMI erfordert nicht, dass Komponententests in einer bestimmten Reihenfolge geschrieben werden, sondern nur, dass die Funktionalität effektiv überprüft wird.
Für eine CMMI-Bewertung muss nachgewiesen werden, dass Komponententests geschrieben und ausgeführt wurden. Verknüpfen Sie die Tests mit den Arbeitsaufgaben für eine Aufgabe der Codekorrektur, und verknüpfen Sie diese Aufgaben mit der Fehlerarbeitsaufgabe. Dies ermöglicht die Nachverfolgbarkeit von Nachweisen, auf die ein leitender SCAMPI-Bewerter achtet.
Überprüfen und Umgestalten des Codes für die Codekorrektur
Mit einer Codeüberprüfung wird sichergestellt, dass neuer oder geänderter Code vorgegebenen Qualitätsmaßstäben entspricht, bevor er in den täglichen Build integriert wird. Qualitätsüberlegungen beziehen sich auf Codierungsstandards und die Übereinstimmung mit Architektur und Entwurf, Leistung, Lesbarkeit und Sicherheit. Durch Codeüberprüfungen erhalten Sie außerdem Einblick in die Erfahrungen von anderen Entwicklern beim Schreiben von Code. Weitere Informationen zum Überprüfen und Umgestalten von Code finden Sie unter Implementieren von Entwicklungsaufgaben.
Schließen von Fehlern
Nachdem ein Fehler korrigiert wurde, sollte er einem Tester zugewiesen werden, um vor dem Schließen der Fehlerarbeitsaufgabe zu überprüfen, ob das Problem gelöst ist.
Überprüfen einer Korrektur
Zum Überprüfen einer Korrektur sollte der Tester versuchen, den Fehler zu reproduzieren, nach weiterem unerwartetem Verhalten suchen und den Fehler ggf. erneut aktivieren.
Wenn Sie eine Fehlerlösung überprüfen, stellen Sie möglicherweise fest, dass der Fehler nicht vollständig behoben wurde, oder Sie sind möglicherweise nicht mit der Auflösung einverstanden. In diesem Fall besprechen Sie den Fehler mit der Person, die ihn aufgelöst hat, erzielen Sie eine Übereinkunft, und aktivieren möglicherweise den Fehler erneut. Wenn Sie einen Fehler erneut aktivieren, stellen Sie sicher, dass Sie die Gründe zum erneuten Aktivieren des Fehlers in die Fehlerbeschreibung einschließen, damit Informationen erhalten bleiben.
Schließen der Fehlerarbeitsaufgabe
Ein Fehler wird aus vielen Gründen geschlossen. In einem einfachen Fall wurde der Fehler als korrigiert bestätigt, und er kann geschlossen werden. Ein Fehler kann jedoch in die nächste Version des Produkts verschoben werden, sich als nicht reproduzierbar erweisen oder als Duplikat bestätigt werden. Jeder dieser Gründe muss dokumentiert werden, und der Fehler muss ordnungsgemäß geschlossen werden, um sicherzustellen, dass der Grund für das Schließen eindeutig ersichtlich ist.
Siehe auch
Konzepte
Weitere Ressourcen
Einbeziehen diagnostischer Ablaufverfolgungsdaten mit Fehlern, die schwer zu reproduzieren sind