Auch wenn dies kaum in vielen Projekten geschieht, dass man als Testteam wirklichen Leerlauf hat, so bietet sich trotzdem ein „Notfallplan“ an für den Tag, dass ihr all eure Aufgaben so umgesetzt habt, dass ihr eventuell eben Leerlauf habt. Eigentlich hat man in einem Testteam niemals Leerlauf, denn in der agilen Entwicklung hat man immer eine sehr gute Taktung der Aufgaben.
Konzentriert euch zunächst auf den Gesamtwert der Qualitätssicherung – den Wert, der dem Unternehmen durch die Qualität des Produkts, die Qualität der Tests, die Anzahl der kürzlich gefundenen Fehler, die Anzahl der betroffenen Benutzer usw. entsteht.
Wenn ihr euch auf kurzfristige Aspekte konzentriert, wie z. B. „die Leute sehen untätig aus“, könnt ihr sehr leicht in viele schlechte Praktiken abrutschen, indem ihr die Leistung mit der Anzahl der Stunden gleichsetzt (in einem größeren Maßstab ist das nicht der Fall), Mikromanagement betreiben, die Leute in Angst leben usw. Dies ist nicht gerade förderlich für die Qualität der Arbeit.
Einige Punkte, die man in dieser „freien Zeit“ machen kann:
- Erstellen/Ausführen von Lasttests für neue/frühere Arbeiten (angesichts des Reifegrads Ihrer Testautomatisierung habt ihr dies möglicherweise bereits unter Kontrolle)
- Überprüft die vorhandene Testautomatisierung auf veraltete oder unwirksame Tests (Ihr ahnen nicht, wie sehr ich mir wünsche, diesen Punkt zu erreichen)
- Überprüft und überarbeitet den vorhandenen Testautomatisierungscode. In jeder schnellen Entwicklungsumgebung kann automatisierter Testcode recht schnell veralten.
- Überprüft und aktualisiert ältere Kundendokumentation. Meiner Erfahrung nach kann diese ziemlich schnell veraltet sein, wenn die Entwicklung schnell voranschreitet.
- Überprüft andere Dokumentationen, um sicherzustellen, dass sie auf dem neuesten Stand sind. Dazu können (aber nicht nur) Anwendungsfälle, Geschäftsanforderungen, Datenbankwörterbücher, funktionale Anforderungen, Testdokumentation usw. gehören.
- Arbeitet mit den Produktverantwortlichen zusammen, um die Stories im Backlog zu verfeinern – oder geht einfach hinein und überprüft sie und stellt trotzdem Fragen. Tester haben in der Regel eine einzigartige Kombination aus Breite und Tiefe, mit einem Produkt, mit dem sie vertraut sind, und können oft potenziell problematische Änderungen aufspüren, bevor sie in den Code einfließen.
- Überprüft die User Stories und Defekte im aktuellen Sprint und plant, wie sie getestet werden sollen. Wenn eine Konfiguration erforderlich ist, kann es viel Zeit sparen, so viel wie möglich zu konfigurieren, bevor die Story/das Defect codiert wird.
- Wenn ihr eine Reihe von Regressionstests habt, können die Tester damit beginnen, diese zu automatisieren, wobei sie mit den am einfachsten zu automatisierenden Tests beginnen. Auf diese Weise könnt ihr bei den Regressionstests langfristig viel Zeit sparen. Natürlich erfordert dies einige Programmierkenntnisse, und wenn die Tester nicht über diese verfügen, ist dies der ideale Zeitpunkt, um sie zu erlernen und für die Automatisierung der Tests einzusetzen. Dies ist sowohl für die Tester als auch für das Team eine Win-win-Situation. Die Tester erweitern ihr persönliches Instrumentarium um eine neue Fähigkeit, von der letztendlich auch das Unternehmen profitieren wird.
- Verwendet Kanban anstelle von Scrum (es gibt auch Mischformen von Kanban und Scrum). Mit einem Kanban-System erhaltet ihr kontinuierlich User Stories, die in der Spalte "Ready to Test" eintreffen. Dann können Sie immer noch eine Reihe von Benutzergeschichten in der Spalte "Bereit zur Freigabe" sammeln (d. h. Entwicklung abgeschlossen, Tests abgeschlossen) und daraus eine wöchentliche oder zweiwöchentliche Freigabe erstellen.
Viele dieser Dinge habe ich getan, als ich mich in einer Warteschleife befand.
Neueste Kommentare