Gibt es eine Schätzmethode zur Schätzung von Endbenutzertests?

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.

Was meinst du mit "Endbenutzertests"? Meiner Erfahrung nach bezieht sich dies auf die Validierung. Der Endbenutzer hat eine Reihe von Bedürfnissen oder Erwartungen, die einem Entwicklungsteam geäußert wurden, und "Endbenutzertests" oder -validierung werden vollständig vom Endbenutzer geleitet, um zu bestätigen, dass das tatsächlich gebaute Ding seinen Anforderungen entspricht. Wie lange müssen sie ihre Tests durchführen, um sich darauf verlassen zu können, dass das gelieferte System ihre Anforderungen erfüllt?
Ich meine mit "Endbenutzertests", dass die Software vom Testteam getestet wird, um bestätigt zu werden und bereit ist, auf dem Benutzer-PC veröffentlicht zu werden
Das stimmt mit keiner Definition von "Endbenutzertests" überein, die ich jemals gehört habe, insbesondere da Ihr Testteam nicht der Endbenutzer des Systems ist. Was Sie beschreiben, ist eine Form der Überprüfung.

Antworten (1)

TL;DR

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.

Die Testpyramide und ihre Auswirkungen auf das „Eiserne Dreieck“

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:

Traditionelles vs. agiles Testen

Schieberegler und Kompromisse

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:

  1. Prozentsatz der Testabdeckung
  2. Geschwindigkeit der Testentwicklung
  3. Geschwindigkeit der Testausführung
  4. Geschwindigkeit der Entwicklung
  5. Geschwindigkeit des Regressionstests
  6. Geschwindigkeit der Fehlerreproduktion/-isolierung

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.

Integrieren Sie Testmetriken in die Definition of Done

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.

Siehe auch