Wie viel Zeit sollte für Tests und Bug Fixing zugeteilt werden [geschlossen]
Jedes Mal, wenn ich die Zeit für ein Projekt abschätzen muss (oder die Schätzung einer anderen Person überprüfen muss), wird Zeit für Tests / Fehlerbehebungen zwischen den Alpha-Releases und den Produktionsfreigaben eingeräumt. Ich weiß sehr gut, dass das Schätzen in die Zukunft hinsichtlich einer Problemmenge unbekannter Größe kein gutes Rezept für eine erfolgreiche Schätzung ist. Aus einer Vielzahl von Gründen wird diesem Arbeitsabschnitt jedoch zu Beginn eine bestimmte Anzahl von Stunden zugewiesen. Und je weiter diese anfängliche Schätzung von dem realen, endgültigen Wert entfernt ist, desto mehr Leid müssen die mit dem Debugging befaßten Personen später nehmen, wenn sie "über" die Schätzung gehen.
Meine Frage ist also: Was ist die beste Strategie, die Sie in Bezug auf solche Schätzungen gesehen haben? Ein flacher Prozentsatz der gesamten Dev-Schätzung? Stellen Sie die Anzahl der Stunden ein (mit der Erwartung, dass sie steigen wird)? Etwas anderes?
Noch etwas zu beachten: Wie würden Sie das anders beantworten, wenn der Client für das Testen verantwortlich ist (im Gegensatz zur internen QA) und Sie ihm eine gewisse Zeit zuweisen müssen, um auf die Fehler zu reagieren, die sie finden oder nicht finden können ( also müssen Sie Zeitschätzungen für die Fehlerbehebung, aber nicht zum Testen herausfinden)
5 Antworten
Es hängt wirklich von vielen Faktoren ab. Um nur einige zu nennen: die Entwicklungsmethodik, die Sie verwenden, die Anzahl der zu testenden Ressourcen, die Anzahl der Entwickler, die zu diesem Zeitpunkt im Projekt verfügbar sind (viele Projektmanager werden die Leute am Ende auf etwas Neues bringen).
>Wie Rob Rolnick sagt, 1: 1 ist eine gute Faustregel - aber in Fällen, in denen eine Spezifikation schlecht ist, kann der Client auf "Bugs" drängen, die eigentlich schlecht spezifizierte Features sind. Ich war kürzlich an einem Projekt beteiligt, das viele Releases verwendete, aber aufgrund der schrecklichen Spezifikation wurde mehr Zeit für die Fehlerbehebung als für die eigentliche Entwicklung aufgewendet.
Stellen Sie eine gute Spezifikation / ein gutes Design sicher, und Ihre Test- / Fehlerbehebungszeit wird reduziert, da es für Tester einfacher ist, zu sehen, was und wie getestet wird und ob Clients weniger Spielraum für zusätzliche Funktionen haben.
Vielleicht schreibe ich nur fehlerhaften Code, aber ich mag es, ein Verhältnis von 1: 1 zwischen Devs und Tests zu haben. Ich warte nicht bis Alpha zu testen, sondern tun es während des gesamten Projekts. Die Logik? Je nach Release-Zeitplan kann zwischen dem Start der Entwicklung und dem Zeitpunkt Ihrer Alpha, Beta und Ship-Daten viel Zeit liegen. Außerdem, je früher Sie Fehler finden, desto einfacher (und billiger) sind sie zu beheben.
Ein guter Tester, der bald nach jedem Check-In Fehler findet, ist von unschätzbarem Wert. (Oder, noch besser, vor einem Check-in von einer PR oder DPK) Einfach gesagt, ich bin immer noch sehr vertraut mit meinem Code, so dass die meisten Fehlerbehebungen sehr einfach werden. Mit diesem Ansatz tendiere ich dazu, etwa 15% meiner Entwicklungszeit für Fehlerbehebungen zu verwenden. Zumindest wenn ich Schätzungen mache. Also würde ich in einem 16-wöchigen Lauf ungefähr 2-3 Wochen gehen.
Nur eine gute Menge an gesammelten Statistiken aus früheren Projekten kann Ihnen helfen, genaue Schätzungen zu geben. Wenn Sie eine klar definierte Menge von Anforderungen haben, können Sie grob berechnen, wie viele Anwendungsfälle Sie haben. Wie gesagt, Sie brauchen Statistiken für Ihr Team. Sie müssen durchschnittliche Bugs pro Loknummer kennen, um die Gesamtzahl der Bugs zu schätzen. Wenn Sie solche Nummern für Ihr Team nicht haben, können Sie durchschnittliche Branchenzahlen verwenden . Nachdem Sie LOC (Anzahl der Anwendungsfälle * NLOC) und durchschnittliche Fehler pro Zeile geschätzt haben, können Sie mehr oder weniger genaue Schätzungen über die für die Freigabe des Projekts erforderliche Zeit geben.
Aus meiner praktischen Erfahrung ist die Zeit, die für die Fehlerbehebung aufgewendet wurde, gleich oder mehr (in 99% der Fälle :)) als die für die ursprüngliche Implementierung aufgewendete Zeit.
Verwenden Sie eine Sprache mit Design-by-Contract oder "Code-contracts" (Vorbedingungen, Check Assertions, Post-Bedingungen, Klassen-Invarianten, etc.), um "Tests" so nah wie möglich an Ihren Klassen- und Klassen-Features (Methoden und Eigenschaften) wie möglich. Dann verwenden Sie TDD, um Ihren Code mit seinen Verträgen zu testen.
Verwenden Sie so viel selbstgebaute Code-Generierung wie Sie können. Generierter Code ist bewiesen, vorhersehbar, einfacher zu debuggen und einfacher / schneller zu reparieren als all-hand-codierter Code. Warum schreibst du was du generieren kannst? Verwenden Sie jedoch keine OPG (Generatoren anderer Völker)! Code, den Sie generieren, ist Code, den Sie kontrollieren und kennen.
Sie können erwarten, dass Sie im Laufe Ihres Projekts eine Umkehrung des Verhältnisses ausgeben - das heißt - Sie werden am Anfang (1: 1) Ihres Projekts viel Hand-Code und Verträge schreiben. Wenn Sie Muster sehen, lehren Sie einen Code-Generator, den Sie SCHREIBEN, um den Code für Sie zu generieren und ihn wiederzuverwenden. Je mehr Sie generieren, desto weniger entwerfen, schreiben, debuggen und testen Sie. Am Ende des Projekts werden Sie feststellen, dass Ihre Gleichung invertiert ist: Sie schreiben weniger von Ihrem Kern-Code, und Ihr Fokus verschiebt sich auf Ihren "Blatt-Code" (letzte Meile) oder spezialisiert (gegenüber generalisierten und generierten ) Code.
Endlich - holen Sie sich einen Code-Analysator. Ein gutes, automatisiertes Codeanalyse-Regelsystem und eine Engine sparen Ihnen eine Menge Zeit, um "dumme Fehler" zu finden, denn es gibt wohlbekannte Fehler, wie Menschen Code in bestimmten Sprachen schreiben. In Eiffel haben wir jetzt Eiffel Inspector, wo wir nicht nur die 90+ Regeln verwenden, sondern auch eigene Regeln für unsere eigenen "Gotchas" schreiben. Solche Analysatoren ersparen Ihnen nicht nur Fehler, sondern verbessern auch Ihr Design - sogar GRÜNE Programmierer "verstehen" es ziemlich schnell und hören auf, Anfängerfehler früher zu machen und schneller zu lernen!
Die Faustregel für das Umschreiben vorhandener Systeme lautet wie folgt: "Wenn es zehn Jahre dauerte, um zu schreiben, wird es 10 Jahre dauern, um neu zu schreiben." In unserem Fall haben wir mit Eiffel, Design-by-Contract, Code-Analyse und Code-Generierung ein 14-Jahres-System in 4 Jahren neu geschrieben und werden in 4 1/2 vollständig liefern. Das neue System ist etwa 4x bis 5x komplexer als das alte System, das sagt also viel!
Tags und Links project-management estimation