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:
„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.
„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.“
Holen Sie sich eine Vorlage für eine Teststrategie, die es uns ermöglicht, Software 2 Mal so schnell zu veröffentlichen
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.“
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.“
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.
„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.
„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.
Wenn Sie den Anteil der unvorhersehbaren Arbeiten reduzieren, können Sie auch das Problem der Schätzungen verringern. Dazu gehört auch die manuelle Testerstellung, da Sie nicht genau wissen, wie viele Tests Sie benötigen, um eine Anforderung vollständig abzudecken. Auch die Zeit für die Erstellung eines Tests kann je nach Komplexität sehr unterschiedlich sein.
Die Lösung besteht darin, künstliche Intelligenz einzubinden. Der KI-Copilot von aqua kann aus einer Beschreibung ganze Testfälle erstellen. Denken Sie einfach an die wichtigsten Tests zur Abdeckung einer Anforderung, und aqua erstellt sie für Sie.
KI-Tests verfehlen keine Schätzungen
