Schätzung des Testaufwands als Prozentsatz der Entwicklungszeit

Nicht jemand, verwenden Sie eine Faustregel die Grundlage zur Schätzung der Aufwand zum testen als Prozentsatz der Aufwand für die Entwicklung? Und wenn ja, welcher Prozentsatz verwenden Sie?

InformationsquelleAutor der Frage Martin Duys | 2009-10-20

  1. 8

    Wenn Sie die Schätzung der Tests, die Sie benötigen, zu identifizieren, den Umfang der Prüfung - sprechen wir unit-Tests, Funktions -, UAT -, Schnittstellen -, Sicherheits -, performance -, stress-und Lautstärke?

    Wenn Sie auf einem Wasserfall-Projekt, haben Sie wahrscheinlich einige overhead-Aufgaben, die ziemlich konstant. Lassen Sie die Zeit für die Herstellung von Planungsunterlagen, Terminpläne und Berichte.

    Für einen funktionalen test-phase (ich bin ein "system-tester" das also ist mein Haupt-Bezugspunkt) nicht vergessen mit der Planung! Ein Testfall muss oft mindestens genauso viel Aufwand zum extrahieren von Anforderungen /Spezifikationen /user stories als es dauert, um Sie auszuführen. Darüber hinaus benötigen Sie einige Zeit für den Mangel erhöhen /erneut testen. Für ein größeres team müssen Sie Faktor in test management - Planung, reporting, Sitzungen.

    In der Regel meine Schätzungen basieren auf der Komplexität der features, die geliefert wird, eher als ein Prozentsatz des dev Aufwand. Dies gilt jedoch verlangen, Zugriff auf mindestens einen high-level-Gruppe von Anweisungen. Jahre der Test ermöglicht es mir herauszufinden, dass eine Prüfung einer bestimmten Komplexität wird x Stunden Aufwand für Vorbereitung und Durchführung. Einige tests erfordern zusätzlichen Aufwand für die Daten-setup. Einige tests können beinhalten, Verhandlungen mit externen Systemen und haben eine Laufzeit von weit über den erforderlichen Aufwand.

    In das Ende, obwohl, müssen Sie überprüfen, es in den Kontext des gesamten Projekts. Wenn Ihre Schätzung ist weit über, dass für BA oder Entwicklung, dann kann es etwas falsch mit Ihrer zugrunde liegenden Annahmen.

    Ich weiß, das ist ein altes Thema, aber es ist etwas, ich bin ein Wiederaufgreifen im moment und ist von mehrjährigen Interesse der Projektleiter.

    InformationsquelleAutor der Antwort user2171986

  2. 11

    Dem Google Testing Blog über dieses problem vor kurzem:

    So eine naive Antwort ist, dass das schreiben von test führt eine 10% Steuer. Aber, wir zahlen Steuern, um etwas im Gegenzug erhalten.

    (snip)

    Diese Vorteile zu übersetzen, um realen Wert, heute wie morgen. Ich Schreibe tests, da die zusätzlichen Vorteile, die ich mehr bekommen, als Ausgleich der zusätzlichen Kosten von 10%. Auch wenn ich nicht den langfristigen nutzen, den Wert, den ich vom test heute sind es Wert. Ich bin schneller in die Entwicklung von code mit test. Wie viel, nun, das hängt von der Komplexität des Codes. Je komplexer die Sache, die Sie versuchen zu bauen ist (mehr ifs/loops/Abhängigkeiten) desto größer ist der nutzen des tests sind.

    InformationsquelleAutor der Antwort Robert Munteanu

  3. 10

    Aus meiner Erfahrung, 25% Aufwand auf Analyse; 50% für Design, Entwicklung und Unit-Test; die restlichen 25% für die Prüfung. Die meisten Projekte passt innerhalb einer +/-10% Abweichung von dieser Faustregel je nach Art des Projektes, know-how, Ressourcen, Qualität des inputs & Ausgänge, etc. Man kann hinzufügen eines Projekt management-overhead innerhalb dieser Prozentsätze oder als overhead oben auf, innerhalb einer 10-15% - Bereich.

    InformationsquelleAutor der Antwort user2193162

  4. 3

    Vor einigen Jahren in einem sicherheitskritischen Bereich, ich habe gehört, so etwas wie einen Tag für unit-Tests zehn Zeilen code.

    Habe ich auch beobachtet, 50% Aufwand für Entwicklung und 50% für die Prüfung (nicht nur unit-Tests).

    InformationsquelleAutor der Antwort mouviciel

  5. 3

    Redest du von automatisierten unit - /integration-tests oder manuelle tests?

    Für das ehemalige, meine Faustregel (basierend auf Messungen) 40-50% Hinzugefügt, um die Entwicklung Zeit, d.h. wenn die Entwicklung eines use-case-dauert 10 Tage (vor einer QA und ernst bugfixing passiert), das schreiben von tests dauert weitere 4 bis 5 Tagen - aber das sollte am besten geschehen, bevor und während der Entwicklung nicht hinterher.

    InformationsquelleAutor der Antwort Michael Borgwardt

  6. 3

    Testzeit ist wohl eher eine enge Korrelation zu den feature-Bereich als für die Entwicklung Zeit. Ich würde auch argumentieren (vielleicht kontrovers), die Zeit der Prüfungen korreliert, um die Fähigkeiten des Entwicklerteams.

    Für ein 6-auf-9-Monats-Entwicklung-Anstrengung, ich fordere ein absolutes minimum von 2 Wochen Test-Zeit, durchgeführt von der tatsächlichen Tester (nicht die team-Entwicklung), die gut versiert in der software, die Sie testen (d.h., 2 Wochen nicht zählen ramp-up-Zeit). Dies ist für ein Projekt, das ~5-Entwickler.

    InformationsquelleAutor der Antwort David Koelle

  7. 3

    Wenn Sie sprechen von tests, Sie könnte bedeuten, Wasserfall oder agile Entwicklung von Tests. In einem agilen Umfeld, sollten Entwickler verbringen 50% Ihrer Zeit die Entwicklung und Wartung von tests.

    Aber, dass 50% extra wird speichern Sie Zeit bei der re-factoring und die manuelle überprüfung Zeit kommt.

    InformationsquelleAutor der Antwort Alex Waddell

  8. 3

    Gartner im Oktober 2006 besagt, dass die Tests in der Regel verbraucht zwischen 10% und 35% der Arbeit auf ein system-integration-Projekt. Ich nehme an, es gilt für die Wasserfall-Methode. Das ist ein ganz breites Spektrum, aber es gibt viele Abhängigkeiten, die auf der Menge der Anpassungen an ein standard-Produkt und der Anzahl der zu integrierenden Systeme.

    InformationsquelleAutor der Antwort Gary

  9. 1

    Das einzige mal, dass ich Faktor in zusätzliche Zeit für das testen ist, wenn ich bin nicht vertraut mit der Test-Technik, die ich verwenden werde (z.B. mit Selenium tests für die erste Zeit). Dann habe ich den Faktor in vielleicht 10-20% bekommen Sie bis zu Geschwindigkeit auf die Werkzeuge und die test-Infrastruktur.

    Sonst testen, ist einfach ein angeborener Teil der Entwicklung und nicht die Gewähr für eine zusätzliche Schätzung. In der Tat, würde ich wahrscheinlich erhöhen Sie die Schätzung für code gemacht ohne tests.

    EDIT: Beachten Sie, dass ich bin in der Regel schreiben von code, der test-first. Wenn ich nach der Tatsache und schreiben Sie tests für bestehenden code, die gehen, um die Dinge verlangsamen. Ich finde nicht, dass die test-first-Entwicklung verlangsamt mich nach unten, außer sehr neugierig (gelesen: Wegwerf -) Codierung.

    InformationsquelleAutor der Antwort Avdi

  10. 1

    Richter durch das gestrige Wetter. Wie lange dauerte es das Letzte mal? Sind Sie trending länger oder kürzer? Jeder shop ist anders.

    Meisten agilen Geschäfte brauchen viel weniger Zeit, haben drastisch weniger Fehler und eine schnellere Zeit, Sie zu lösen, weil der TDD. Auch so, die meisten agilen Geschäfte haben einige messbare Zeit mit testen/QC.

    Ist dies der erste Testlauf für diese Anwendung, dann ist die Antwort "mal sehen", gefolgt von einem Versuch. Es hängt davon ab, wie schnell Sie bekommen kann, Fragen beantwortet,
    - wie überprüfbar ist,
    - wie viele features/Funktionen
    - wie viele Mängel entdeckt werden, sind,
    - wie schnell Probleme gelöst sind,
    - wie oft der code-Zyklen
    durch Tests, und
    - wie viele Male testen ist blockiert
    bugs.
    Es gibt keine Möglichkeit zu sagen. Man könnte es nennen 50% oder 175% oder mehr, und nicht falsch sein. Warum nicht machen Sie eine grobe Schätzung und multipliziert mit Pi? Es wird nicht viel schlimmer als jede andere Antwort, die man machen kann.

    Sollten Sie (muss) wissen, wie lange dauert es nun und ob es schneller oder langsamer, und ob sich die Berichterstattung zu-oder abnimmt. Mit diesen drei bits von Informationen, Sie sollten in der Lage sein, zu erraten, ganz gut.

    InformationsquelleAutor der Antwort Tim Ottinger

Schreibe einen Kommentar