Gibt es eine Schätztechnik, die uns helfen kann, die Anzahl der benötigten Testfälle in traditionellen Softwareprojekten abzuschätzen? Wir haben zum Beispiel eine Software Requirements Specification (SRS) mit 200 Anwendungsfällen; kann ich als grobe Schätzung sagen "wir brauchen 200 * 10 = 2000 Testfälle"?
Wir benötigen diese Schätzung, um einen Testplan für den Projektmanager zu schreiben. Manchmal verstehen wir die Anwendung aus dem SRS nicht vollständig, weil wir zu wenig Zeit mit der Testplanung verbracht haben.
Es gibt keine einheitliche Formel, um zu bestimmen, wie viele Tests ein Satz von Spezifikationen erfordert. Sie können jedoch den Aufwand schätzen und Qualitätsziele auf der Grundlage Ihrer Testpläne festlegen, vorausgesetzt, die Personen, die die Schätzungen vornehmen, sind diejenigen, die die eigentliche Arbeit erledigen.
Es gibt keine allgemeingültige Formel dafür, wie viele Tests Sie für jede Spezifikation benötigen. Dies hängt vom Produkt, den von Ihnen verwendeten Frameworks, der Komplexität der Spezifikationen und der Wichtigkeit jeder Funktionseinheit ab. Sie können jedoch vernünftige Schätzungen erhalten, indem Sie die eigentlichen Ausführenden der Aufgabe (z. B. die Entwickler und Tester, die die Arbeit erledigen werden) bitten, den Testaufwand zu schätzen, den sie für jeden Arbeitsblock im Projektplan erwarten.
Im Allgemeinen sollten Sie damit rechnen, dass ein agiler Shop viele Unit-Tests und sehr wenige manuelle Tests hat. Zum Beispiel:
Es gibt viele Variationen der Testpyramide , und die Einzelheiten darüber, was in jede Schicht gehört, können je nach Produkt, Branche und Prozess variieren. Erfahrene Entwickler und Tester, die eingeladen werden, mit Ihnen bei der Planung und Schätzung des Projekts zusammenzuarbeiten, können jedoch oft ziemlich genaue Schätzungen zum Aufwand für jede Phase oder Komponente des Testens abgeben und Ihnen helfen, die notwendigen Kompromisse zu machen. Abgänge zwischen:
Diese Faktoren, die oft komplementäre oder gegensätzliche Schieberegler sind, wirken sich auf die Kosten, den Zeitplan und die Qualität Ihres Projekts aus. Es wird sich auch stark auf Ihre technischen Schulden- und Fehlerquoten auswirken, je nachdem, was das Team und die Organisation vereinbaren.
Ihre Definition of Done sollte immer vereinbarte Ziele für die Testabdeckung enthalten. Der Rest der Testdetails ist wahrscheinlich eher eine Verhandlung und eine Reihe von Richtlinien als ein fester Prozentsatz.
Thomas Owens
Majd Kassem
Thomas Owens