Schließen Sie Tests in die ursprüngliche Schätzung ein?

Der Kostenvoranschlag für einen Artikel sollte abdecken, wie lange es dauern wird, bis er fertig ist. Angenommen, was Sie als erledigt definieren, umfasst sowohl Tests als auch Entwicklung, dann sollte es in der ursprünglichen Schätzung enthalten sein.

Der beste Weg, um sicherzustellen, dass alles, was abgedeckt werden muss, um erledigt zu werden, in die Schätzung einfließt, besteht darin, sicherzustellen, dass alle Beteiligten (z. B. die Tester) zum Sprint-Planungsmeeting eingeladen werden.

Eine schnelle Gegenfrage kann dies wahrscheinlich beantworten. "Würden Sie nach 4 Stunden Dev an den Kunden liefern?"

Da Sie nach der Entwicklungsarbeit nicht liefern können, muss die QA-Schätzung in die ursprünglichen Schätzungen aufgenommen werden.

Wie @David vorgeschlagen hat, sollten Sie sich für die Definition of Done entscheiden, die alle Aktivitäten umfasst, die erforderlich sind, um den Job von der Initiierung bis zur Lieferung abzuschließen.

Ein paar Dinge zu beachten:

Wenn die QA einen Fehler findet, müssen die Entwickler ihn beheben. Dann ist es wahrscheinlich, dass die QA erneut testen muss, um zu bestätigen, dass der Fehler behoben ist. Einfach zu sagen, dass die QAs 2 Stunden brauchen, kann ziemlich irreführend sein. Das Testen wirkt sich sowohl auf die Entwickler als auch auf die QAs aus.

Wenn Ihre QA-Ressource begrenzt ist und Sie in Zeiteinheiten schätzen möchten, müssen Sie die QAs nicht über- oder unterbelasten. Wenn Sie beispielsweise sagen, dass Sie 100 Stunden Entwicklungsarbeit und 100 Stunden QA-Arbeit haben, funktioniert dies nur, wenn Sie die gleiche Anzahl von Entwicklern wie QAs haben.

Diese Komplikationen sind der Grund, warum viele Leute es vorziehen, Story Points zu verwenden. Story Points sind eine Schätzung der relativen Komplexität der Geschichte und nicht die Zeit, die Sie für jede Disziplin erwarten (was sehr schwer richtig zu erraten ist).

QA-Schätzungen müssen in den ursprünglichen Schätzungen enthalten sein, da QA-Aktivitäten ebenfalls Zeit in Anspruch nehmen und sich auf den Projektabschluss-Meilenstein auswirken.

Entwicklungsschätzungen gelten für das Entwicklungsteam und QA-Schätzungen für das SQA-Team. Wir berücksichtigen sowohl die Entwicklungs- als auch die Testzeit in den Schätzungen, jedoch separat.

Wenn wir sie zusammenführen - - Wir können die Schätzungen für Entwicklung und QA nicht separat identifizieren. - Wir können die Schätzungen nicht mit der tatsächlichen Zeit vergleichen, die für Entwicklung und QA separat benötigt wird. - Wir können die Meilensteinentwicklung nicht abgeschlossen und die QA abgeschlossen haben. - Wir können Entwicklung und SQA-Fortschritt nicht separat verfolgen.

Entwicklung und QA werden (meistens) von getrennten Teams durchgeführt, daher ist es besser, sie zu trennen.

Die Schätzung des Entwicklungsteams sollte die Zeit für die Durchführung automatisierter Tests beinhalten. Außerdem sollte die Zeit für eine Release-QA-Periode geschätzt werden. Zusätzliche Ressourcen sollten in der Release-QA-Periode zum Testen der Benutzererfahrung berücksichtigt werden.

Mein Team hat dies in mehreren Projekten als sehr hilfreich empfunden. Das automatisierte Testen, das im Allgemeinen durch testgetriebene Entwicklung abgeschlossen wird, erfasst Probleme während des normalen Entwicklungszyklus. Unser User Experience Specialist führt Release-Tests mit Testbenutzern während des Release-QA-Zeitraums durch, um alles zu entdecken, was nicht in den automatisierten Tests erfasst wurde.

Festgelegte Veröffentlichungszeiträume für Benutzererfahrungstests geben dem Entwicklungsteam auch die Möglichkeit, die Anwendung zu verfeinern und Erkenntnisse aus den Benutzertests zu integrieren, die im Rahmen des Umfangs liegen.

Die einfache Antwort ist, dass der Umfang der Aufgaben deutlich gemacht werden sollte, z. B. Code, Komponententest, Test, QA usw. Dann wissen Sie, wo Sie Tests und alle anderen Anstrengungen in Ihre Schätzungen einbeziehen müssen - und ob die Codierung voraussichtlich enthalten ist ein Element des Testens durch den Programmierer, dann muss dies in seine Schätzungen einbezogen werden

Wir beziehen Tests, die von unseren Entwicklern durchgeführt werden, in unsere Schätzung ein (z. B. das Schreiben von Tests für TDD, das Schreiben zusätzlicher Unit-Tests oder Feature-Tests für unsere nächtlichen Regressionstests).

Wir besprechen auch die Art der Tests, die vom QA-Team durchgeführt werden, und die Wahrscheinlichkeit, dass sie Probleme finden, die wir beheben müssen (die mit verschiedenen Arten von Komplexität oder Kosmetika verfolgt werden). Wir schätzen die Menge an zusätzlicher Entwicklungszeit, die für die Unterstützung oder Iteration mit den QA-Leuten erforderlich sein wird, und beziehen dies in unsere Schätzung ein.

Es ist oft nützlich, die Dinge aus der Sicht der Tester zu diskutieren, da wir dadurch möglicherweise erkennen, dass es eine zusätzliche Komplexität gibt, und unsere ursprüngliche Entwicklerschätzung revidieren.

Bei der normalen Sprintplanung spielt es eigentlich keine Rolle, solange Sie konsistent sind, dh das gestrige Wetter (dh die Geschwindigkeit) zum Planen verwenden, oder wenn Sie stattdessen eine Art traditionelle Kapazitätsplanung durchführen, dann würden Sie die verfügbare Testkapazität ausschließen, wenn Sie dies tun schließen Sie auch den Test aus der Schätzung aus.

Wenn Sie ein Angebot für ein Zeit- und Materialprojekt oder ähnliches machen, möchten Sie wahrscheinlich den Testaufwand einbeziehen, es sei denn, Sie wissen, dass die Testkosten durch Puffer oder ähnliches abgedeckt werden.

Meiner Meinung nach liegt der Schlüssel darin, sich auf die „Definition of Done“ zu konzentrieren, hauptsächlich aus der Perspektive des Product Owners. Jetzt hat das Team (genauer gesagt das funktionsübergreifende Team) möglicherweise einige (oder viele) Fragen, die zwischen dem Team (denken Sie daran, dass ich nicht Entwickler oder Tester sage) und dem PO geklärt werden müssen, damit sie es haben eine gemeinsame 'Definition of Done'. Hier kommen die Fähigkeiten eines erfahrenen Scrum Masters ins Spiel. Er/Sie kann die Diskussion wirklich so orchestrieren, dass beide eine gemeinsame Basis finden. Übrigens, der geeignete Ort für eine solche Diskussion ist das Sprint-Planungsmeeting.

Schnelle Antwort: JA

Berücksichtigen Sie immer den GESAMTEN Aufwand, den Ihr Team für eine Geschichte oder Arbeit aufwenden muss, unabhängig von der verwendeten Schätztechnik. Wie Sie Tests usw. durchführen, sollte Teil Ihrer Definition of Done sein, und Ihre Schätzungen sollten diese Arbeit widerspiegeln.

Entschuldigung für Grammatik/Rechtschreibung, ich bin auf dem Handy -