Agil Bewährte Methoden Verwaltung
11 min lesen
Oktober 12, 2022

Zeiteinschätzung in der QS: Bewährte Praktiken von 5 verschiedenen Senior-Testern

Albert Einstein war in vielerlei Hinsicht seiner Zeit voraus, als er verkündete, dass Zeit relativ ist. Bei der Produktentwicklung (einschließlich Qualitätssicherung) kann eine Stunde eher zwei oder drei Stunden bedeuten. Wir haben 5 erfahrene Tester gefragt, wie sie realistische Schätzungen vornehmen, damit auch Sie dies machen können.

photo
Tania Zhydkova

Techniken zur Schätzung der QS-Zeit

Die nachstehende Liste von Techniken gilt sowohl für QS-Spezialisten als auch für ihre Kollegen aus der Softwareentwicklung. Diese Modelle zur Schätzung von Softwaretests funktionieren sogar noch besser, wenn das gesamte Team sie anwendet.

Verwenden Sie die Pokerplanung

Die Pokerplanung ist eine erstaunliche Technik, um die Angst des Einzelnen vor hohen Schätzungen zu überwinden. Zu Beginn der Planungssitzung erhält jeder ein Dutzend Karten, auf denen die Anzahl der Stunden steht, die für die Erledigung der Aufgabe benötigt werden. Wenn der Projektleiter ein Ticket vorliest, teilt jeder seine Gedanken dazu mit, wie es angegangen werden sollte. Der allgemeine Arbeitsablauf, die Anzahl der beteiligten Spezialisten und mögliche Blockaden sind nur einige der Aspekte, die Sie ansprechen sollten.

Nach der Diskussion zeigt jeder im Team eine Karte, auf der er die seiner Meinung nach erforderliche Stundenzahl eingetragen hat. Einige Leute würden in der Regel höhere Schätzungen abgeben als andere, aber das ist ja der Sinn der Übung. Führen Sie eine weitere Diskussionsrunde durch, in der die Personen mit den höheren/niedrigeren Karten ihre Mitspieler davon überzeugen, ihre Meinung zu ändern. Letztendlich werden Sie zu einem Konsens kommen und mit der nächsten Story weitermachen, um die gleichen Schritte zu durchlaufen.

Linda Hoff, Test- und Freigabeverwaltung bei Qlik, weist auf wichtige Voraussetzungen für eine sukzessive Pokerplanung hin:

photo
Linda Hoff, Test- und Freigabeverwaltung, Qlik

„Ich mag Pokerplanung, FALLS man jemanden im Team hat, der mutig genug ist, hoch zu schätzen. Diese Person war ich schon einige Male. Es ist hart, aber wir haben viel realistischere Schätzungen.“

Ein weiterer großer Vorteil der Pokerplanung besteht darin, dass jeder im Team eine Stimme hat. Dies ist eine wesentliche Voraussetzung für die Anwendung und Einhaltung der Scrum-Methodik beim Softwaretest. Wenn an einer Aufgabe mehrere Mitarbeiter in verschiedenen Stadien beteiligt sind, sollten Sie zumindest den Pessimisten anhören.

Alternativ können Sie auch die Drei-Punkte-Schätzung verwenden. Obwohl diese Technik weitaus weniger ansprechend ist, deckt sie eine Reihe von möglichen Lösungen ab. Sie starten einfach Ihr Problemverfolgungssystem und sehen sich an, wie viele Stunden Sie tatsächlich für die Erledigung der Aufgabe gebraucht haben

Weitermachen von Stunden

Die Schätzung der QS-Testzeit ist auf mehreren Ebenen schwierig. Dieselbe Aufgabe kann selbst bei zwei QS-Spezialisten mit gleichem Dienstalter unterschiedlich viele Stunden in Anspruch nehmen. In diesem Sinne wird eine straffe Sprintplanung ziemlich schnell durcheinander gebracht. Es geht um , wann, nicht um , ob Sie beginnen, Fristen für bestimmte Aufgaben zu versäumen. 

Prioritäten helfen Ihnen zu erkennen, bei welchen Aufgaben es Sie Ihnen am wenigsten bedauern, spät dran zu sein. Der Blick auf die festgelegte Stundenzahl kann jedoch Ihr Verständnis trüben. Hier ist ein toller Ratschlag, den wir in unserer Linkedin Softwaretest-Community von Testingenieurin und YouTube-Autorin Karen Todd. erhalten haben.

photo
Karen Todd, Test Engineer and creator of Karen Tests Stuff

„Mir gefällt die Idee der „Aufwandsabschätzung“ im Gegensatz zur Zeitabschätzung. Zeit ist ein schwieriges Thema, denn was für den einen Mitarbeiter eine Stunde dauert, kann für einen anderen fast den ganzen Nachmittag in Anspruch nehmen. Aber was für den einen weniger Aufwand bedeutet, kann für den anderen mehr Aufwand bedeuten. Es ist kompliziert.

Ich mag die T-Shirt-Größe als Anhaltspunkt. Überlegen Sie gemeinsam im Team, wie viele Systeme dieser Punkt berühren wird, wie viele Personen daran beteiligt sein werden, wie komplex er ist, welches Risiko mit seiner Umsetzung verbunden ist... und ordnen Sie die vorgeschlagenen Funktionen/Aufgaben in Gruppen nach „Hemdgröße“ ein (klein, mittel, groß usw.)“

Eine weitere Alternative zu den numerischen Stunden ist Story Points. Sie stellen die relative Komplexität einer User Story im Vergleich zu dem dar, was sich sonst im Backlog befindet. Story Points sind besonders nützlich für Teams mit gemischten Senioritätsstufen. Die Schätzungen der Tests werden durch die Wahl der QS-Spezialisten beeinflusst; die relative Komplexität, ausgedrückt durch Story Points, bleibt gleich.

„Wir sind Agile, also verwenden wir Story Points für die Schätzung. Die Zeit für die Qualitätssicherung wird nicht direkt geschätzt, aber ich erkenne, wenn eine Geschichte viel Potenzial für das Hin und Her mit den Entwicklern hat. Wenn das passiert, ermutige ich sie, ihre Schätzungen höher anzusetzen und ausreichend Zeit für Tests/Nachprüfungen einzuplanen. Das funktioniert gut für mein Team.“

chicagodetroit, ein /r/QualityAssurance-Benutzer,

Verwenden Sie Stunden, Story Points oder eine beliebige Zeitreferenz für die Freigabe ausgefeilter Software

Testen Sie aqua ALM kostenlos

Verfolgen Sie einen termingerechten Ansatz

Während das Testen einen Anfang hat, ist das Ende nicht so klar (es sei denn, es handelt sich um eine Schätzung der Testautomatisierung). Es gibt immer Raum für mehr QS, auch wenn es letztendlich immer länger dauert, die kleinsten Probleme zu finden. Hier erfahren Sie, wie Sie den Spieß umdrehen können:

„In der Regel frage ich: ‚Wie viel Zeit steht mir zur Verfügung?‘, und ich versuche festzustellen, ob ich in der mir zur Verfügung stehenden Zeit eine angemessene Abdeckung erreichen kann. Wenn meine Abdeckung schlecht ist oder ich beim Testen viele Fehler finde, versuche ich, das Risiko abzuschätzen und es den Beteiligten mitzuteilen. Ich lasse sie entscheiden, ob sie mir mehr Zeit geben wollen oder nicht. Das bewahrt mich davor, dass ich mich in Versprechen verstricke, die ich nicht halten kann. Meiner Erfahrung nach kommt das Testen in der Regel zu kurz, wenn es um den Projektplan geht.“

acrobaticOccasion, ein /r/QualityAssurance-Benutzer,

Während die Freigabetermine relativ stabil sind, weiß ein Tester nicht unbedingt, wie tief der Graben einer neuen Funktion ist. Wie kann man die Dinge für den QS-Spezialisten berechenbarer machen? Einfach: führt Unit-Tests durch, um konzeptionelle Fehler zu finden, bevor Ihre Tester den neuen Code überhaupt zu Gesicht bekommen. Mit ein wenig zusätzlicher Arbeit für Ihre Entwickler wird die Aufwandsschätzung für Softwaretests viel einfacher.

Bewerten Sie Ihre Schätzungen neu

Eine Möglichkeit, Enttäuschungen im Leben zu vermeiden, besteht darin, seine Erwartungen anzupassen. Manche Leute glauben, dass man das auch in der Qualitätssicherung machen kann. Schließlich können Sie keine genaue Schätzung verpassen, wenn Sie grobe Schätzungen in Ihre Testmanagement-Software eingeben. 

„Wenn wir eine große Aufgabe bekommen, versuchen wir, sie in testbare Teile zu zerlegen und diese abzuschätzen. Sobald die Entwickler mit der Arbeit beginnen, können sie auf Komplikationen stoßen, die zu einer Ausweitung des Umfangs führen oder einfach nur länger als geplant dauern. Falls wir in eine solche Situation geraten, treffen sich die Entwickler und diskutieren und schätzen die verbleibende Arbeit neu ein. Auch das funktioniert gut: lernen, umstellen und noch mehr lernen.“

chicagodetroit, ein /r/QualityAssurance-Benutzer,

Dies ist eine gute Taktik, um die Qualitätssicherung mit der fließenden Art der Entwicklung in Einklang zu bringen. Alle potenziellen Hindernisse, die eine User Story auf den nächsten Sprint verschieben, bedeuten, dass Ihre Tester nicht daran arbeiten werden. Sie hätten etwas mehr Zeit damit verbringen können, anderen Funktionen den letzten Schliff zu geben, oder sich auf die wilde Fahrt der Erkundungstests begeben können. Die Planung der Entwicklung in kleineren Abschnitten würde in der Tat auch weniger Unterbrechungen im Kalender der Tester bedeuten.

Nehmen Sie keine Schätzungen vor

Zeitschätzungen sind für die Planung unerlässlich, insbesondere wenn Sie einen ganzen Sprint planen müssen. Aber was ist, wenn ich Ihnen sage, dass Sie überhaupt keine Schätzungen brauchen? Was auch immer Ihre Reaktion war, ich bin es nicht, der Ihnen das sagen wird.

photo
Lara Hawrey Ali, Testerin, aqua ALM

„Wir arbeiten nach dem Kanban-Prinzip, es gibt also ein großes Backlog mit priorisierten Aufgaben anstelle von 2-Wochen-Sprints. Die Entwickler schätzen ihren Aufwand in Story Points ein, aber unser QS-Team tut das nicht. Wenn ein Entwickler eine Funktion einführt, teste ich sie sofort. Wenn mehrere Funktionen auf die QS warten, richten wir uns nach denselben Prioritäten, die die Entwickler für sich selbst setzen.“ Ja, es gibt überhaupt keine „storyspezifischen“ Schätzungen für QA.“

Das gilt nicht nur für uns: Auch das Engineering-Team von Qlik hat keine Freude an knappen Fristen, auch wenn sie nicht so radikal sind.

photo
Linda Hoff, Test- und Freigabeverwaltung, Qlik

„Sobald es ein Datum gibt, an dem etwas getan werden soll, ist es sehr schwierig, eine Schätzung vorzunehmen, die nicht von diesem Datum beeinflusst wird. Daher ziehe ich einen Wertefluss ohne angestrebte Freigabetermine gegenüber Freigabeplänen und festen Terminen vor. Wir haben diesen konstanten Fluss für die meisten unserer Features und es ist fantastisch zu sehen, welchen Unterschied das macht.“ Wir haben auch wöchentliche Freigaben, was sehr hilfreich ist. Falls Sie für diese Freigabe noch nicht bereit sind, haben Sie nächste Woche eine neue Chance. Früher hatten wir monatliche Freigaben, und das war schwieriger.“

Dieser Ansatz kann auch erfordern, dass Ihr Produktteam bei den Freigabeterminen flexibel ist. Die Verkürzung von Sprints oder die Abkehr von festen Releases gibt Ihnen jedoch die Freiheit, schneller zu innovieren und neue Dinge so schnell wie möglich zu liefern. Wie gut es bei aqua gelaufen ist und welche weiteren traditionellen Scrum-Tipps es gibt, können Sie in unserem Blog-Artikel nachlesen.

Schlussfolgerung

Schätzungsmethode für Softwaretests sind ein sehr interessantes Thema. Man kann so tun, als gäbe es die Zeit nicht, so arbeiten, als sei die Zeit nicht konstant (was sie in der Softwareentwicklung nicht ist), oder sie sogar ganz ablehnen. Unabhängig davon, welche Technik zur Schätzung von Softwaretests Sie verwenden, ist es von großem Vorteil, den Testern mehr Handlungsspielraum zu geben und andere Beteiligte einzubeziehen. 

Holen Sie sich das perfekte workflow-orientierte ALM für kollaboratives Arbeiten

Testen Sie aqua ALM kostenlos
On this page:
See more
Beschleunigen Sie Ihre Releases x2 mit aqua ALM
Gratis starten
closed icon