Hallo zusammen! Ich heiße Julia und bin Tester. Letztes Jahr habe ich euch von Bugodelnia erzählt — eine Veranstaltung, die wir in unserem Unternehmen durchführen, um das Bug-Backlog zu bereinigen. Es ist eine durchaus machbare Möglichkeit, es (in verschiedenen Teams von 10 bis 50 %) an nur einem Tag erheblich zu reduzieren.

Heute möchte ich euch von unserem Frühlingsformat der Bugodelnia – BUgHunting (BUH) – erzählen. Diesmal haben wir nicht an alten Bugs gearbeitet, sondern neue gesucht und Ideen für Features vorgeschlagen. Unter dem Cut gibt es viele Details zur Organisation solcher Veranstaltungen, unseren Ergebnissen und den Rückmeldungen der Teilnehmer.

Nachdem wir die Regeln durchdacht und ausgearbeitet hatten, haben wir in allen Kanälen in unserem Unternehmens-Slack eine Einladung verschickt, die keinerlei Einschränkungen enthielt:

Am Ende haben sich etwa 30 Personen angemeldet – sowohl Entwickler als auch nicht-technische Spezialisten. Für die Veranstaltung wurde ein ganzer Arbeitstag reserviert, wir haben einen großen Besprechungsraum gebucht, und die Mittagessen wurden in der Bürokanteen organisiert.

Warum?

Es schien, als ob jedes Team seine Funktionalität testet. Benutzer berichten uns von Bugs. Warum sollten wir solch eine Veranstaltung überhaupt durchführen?

Wir hatten mehrere Ziele.

1. Die Leute näher mit angrenzenden Projekten/Produkten bekannt machen.
   Zurzeit arbeitet jeder in unserem Unternehmen in separaten Teams – Einheiten. Das sind Projektgruppen, die ihren Teil der Funktionalitäten entwickeln und nicht immer vollständig darüber informiert sind, was in anderen Projekten passiert.
2. Einfach die Kollegen untereinander bekannt machen.
   Wir haben fast 800 Mitarbeiter im Moskauer Büro, nicht alle Kollegen kennen sich persönlich.
3. Die Fähigkeit zur Bugsuche bei Entwicklern in ihren Produkten verbessern.
   Momentan fördern wir Agile Testing und schulen die Kollegen in diesem Bereich weiter.
4. Nicht nur technische Spezialisten für das Testen gewinnen.
   Neben der technischen Abteilung haben wir viele Kollegen aus anderen Fachbereichen, denen wir mehr über das Testen erzählen wollten, wie man Bugberichte richtig verfasst, damit wir weniger Meldungen im Format "Aaaa... nichts funktioniert" erhalten.
5. Und natürlich, hinterlistige und nicht offensichtliche Bugs finden.
   Es wäre schön, den Teams beim Testen neuer Features zu helfen und ihnen die Möglichkeit zu geben, die implementierte Funktionalität aus einer anderen Perspektive zu betrachten.

Implementierung

Unser Tag bestand aus mehreren Blöcken:

• Briefing;
• eine kurze Vorlesung über das Testen, in der wir nur die grundlegenden Punkte (Ziele und Prinzipien des Testens usw.) angesprochen haben;
• ein Abschnitt über "gute Manieren" beim Erstellen von Bugs (hier die Prinzipien sind gut beschrieben);
• vier Testsitzungen zu Projekten mit grob beschriebenen Szenarien; vor jeder Sitzung gab es eine kurze Einführung in das Projekt und die Teamverteilung;
• eine kurze Umfrage zu der Veranstaltung;
• Zusammenfassung.

(Wir haben auch an die Pausen zwischen den Sitzungen und das Mittagessen gedacht).

Grundlegende Regeln

• Die Anmeldung zu den Veranstaltungen erfolgt individuell, was das Problem der Trennung des gesamten Teams löst, wenn eine Person nicht kommen möchte.
• Bei jeder Sitzung wechseln die Teilnehmer das Team. Das ermöglicht es den Teilnehmern, jederzeit zu kommen und zu gehen, und außerdem kann man viele verschiedene Menschen kennenlernen.
• Befehle zwei Personen werden vor jeder Sitzung zufällig ausgewählt, das macht es dynamischer und schneller.
• Für eingereichte Bugs werden Punkte (von 3 bis 10) je nach Kritikalität vergeben.
• Für Duplikate gibt es keine Punkte.
• Bugs müssen von einem Teammitglied gemäß allen internen Standards eingereicht werden.
• Feature-Anfragen werden in separaten Aufgaben eingereicht und nehmen an einer separaten Nominierung teil.
• Das Audit-Team überwacht die Einhaltung aller Regeln.

Weitere Details

• Ursprünglich wollten wir eine "fortgeschrittene" Veranstaltung zum Testen machen, aber da sich genügend Leute aus nicht-produktiven Teams (SMM, Juristen, PR) angemeldet haben, mussten wir den Inhalt stark vereinfachen und komplizierte/professionelle Fälle entfernen.
• Aufgrund der Arbeit der Einheiten in Jira in verschiedenen Projekten mit ihren eigenen Workflows haben wir ein separates Projekt erstellt, in dem wir eine Vorlage zum Erstellen von Bugs eingerichtet haben.
• Um die Punkte zu zählen, hatten wir geplant, ein Leaderboard zu verwenden, das über Webhooks aktualisiert wird, aber etwas lief schief und am Ende mussten wir die Zählung manuell durchführen.

Jeder, der Veranstaltungen organisiert, stößt auf Schwierigkeiten, und um es Ihnen etwas einfacher zu machen, werde ich unsere Probleme beschreiben, die Sie vermeiden können.

Einer der Redner wurde plötzlich krank, und es musste ein neuer gesucht werden.
Ich hatte das große Glück, dass ich um 9 Uhr einen Ersatz aus dem gleichen Team gefunden habe). Aber man sollte sich nicht auf Glück verlassen und einen Ersatz bereit haben. Oder selbst bereit sein, den benötigten Vortrag zu halten.

Wir haben es nicht geschafft, die Funktionalität bereitzustellen, daher mussten die Blöcke getauscht werden..
Um keinen ganzen Block wegzuwerfen, ist es besser, einen Backup-Plan zu haben.

Ein Teil der Testbenutzer ist abgesprungen, wir mussten schnell neue erstellen..
Überprüfen Sie die Testbenutzer im Voraus oder haben Sie die Möglichkeit, sie schnell zu erstellen.

So gut wie keiner der Leute, wegen denen wir das Format vereinfacht haben, ist gekommen..
Man muss niemanden mit Gewalt zwingen. Akzeptieren Sie das.
Es gibt die Möglichkeit, das Format der Veranstaltung klar festzulegen: „Amateur“/„Fortgeschritten“, oder gleich zwei Varianten vorzubereiten und dann je nach Situation zu entscheiden, welche durchgeführt wird.

Nützliche organisatorische Punkte:

• Buchen Sie den Besprechungsraum im Voraus;
• Stellen Sie die Tische auf, vergessen Sie nicht die Verlängerungskabel und Steckdosenleiste (Laptops/Handys auf einen ganzen Tag können nicht ausreichen);
• Automatisieren Sie den Prozess der Punktezählung;
• Bereiten Sie Ranglisten vor;
• Machen Sie Papieraushänge mit Benutzernamen und Passwörtern der Testbenutzer, Anweisungen zur Arbeit mit Jira, Skripten;
• Vergessen Sie nicht, eine Woche vor der Veranstaltung Erinnerungen zu versenden, geben Sie zusätzlich an, was mitgebracht werden muss (Laptops/Devices);
• Sprechen Sie mit Kollegen über die Veranstaltung bei der Demo, beim Mittagessen, bei einer Tasse Kaffee;
• Vereinbaren Sie mit den DevOps, dass an diesem Tag nichts aktualisiert oder ausgerollt wird;
• Bereiten Sie die Referenten vor;
• Vereinbaren Sie mit den Feature-Eigentümern und schreiben Sie mehr Test-Skripte vor;
• Bestellen Sie Snacks (Kekse/Bonbons) für Zwischendurch;
• Vergessen Sie nicht, über die Ergebnisse der Veranstaltung zu berichten.

Ergebnisse

Am ganzen Tag haben die Leute 4 Projekte getestet und 192 Bugs (davon 134 einzigartige) und 7 Aufgaben mit Feature-Anfragen erstellt. Natürlich wussten die Projektinhaber bereits von einigen dieser Bugs. Aber es gab auch unerwartete Entdeckungen.

Alle Teilnehmer erhielten süße Preise.

Die Gewinner - Thermobecher, Abzeichen, Sweatshirts.

Zu interessant war Folgendes:

• Für die Teilnehmer war das Format der strengen Sitzungen überraschend, bei dem die Zeit begrenzt ist und man nicht viel Zeit mit Überlegungen verbringen kann;
• Es gelang, Desktop, mobile Version und Apps zu testen;
• Wir haben viele Projekte auf einmal angesehen, es gab keine Zeit sich zu langweilen;
• Wir haben verschiedene Kollegen kennengelernt und ihre Ansätze beim Verwalten von Bugs angesehen;
• Wir konnten den ganzen Schmerz der Tester nachempfinden.

Was verbessert werden kann:

• Weniger Projekte machen und die Zeit der Sitzung auf 1,5 Stunden erhöhen;
• Geschenke/Souvenirs lange im Voraus vorbereiten (manchmal zieht sich die Abstimmung/Zahlung über einen Monat hin);
• sich entspannen und akzeptieren, dass etwas nicht nach Plan verläuft und es unerwartete Ereignisse geben wird.

Feedback

Anna Bystrikova, Systemadministratorin: „Das Bug-Bounty-Programm war für mich sehr lehrreich. Ich habe den Testprozess kennengelernt und die gesamte "Schmerz" der Tester miterlebt.
Zunächst testest du im Prozess, wie ein typischer Benutzer, die grundlegenden Punkte: drückt der Knopf, wird zur Seite gewechselt, hat sich das Layout verschoben. Aber später verstehst du, dass du kreativer denken und versuchen musst, die Anwendung zu „brechen“. Tester haben keinen einfachen Job, es reicht nicht aus, nur das gesamte Interface abzuklopfen; man muss sich bemühen, unkonventionell zu denken und äußerst aufmerksam zu sein.
Die Eindrücke waren durchweg positiv, selbst jetzt, einige Zeit nach der Veranstaltung, sehe ich, wie an den von mir gefundenen Fehlern gearbeitet wird. Es ist großartig, sich an der Verbesserung des Produkts beteiligt zu fühlen ^_^“.

Dmitri Seleznyov, Frontend-Entwickler: „Das Testen im Wettbewerbsmodus motiviert stark, mehr Bugs zu finden). Ich denke, jeder sollte mal an einem Bug-Hunting teilnehmen. Exploratives Testen ermöglicht es, die Fälle zu finden, die im Testplan nicht beschrieben sind. Außerdem können Menschen, die das Projekt nicht kennen, Feedback zur Benutzerfreundlichkeit des Dienstes geben.

Antonina Tatchuk, leitende Redakteurin: „Ich fand es interessant, als Testerin zu arbeiten. Es ist ein ganz anderer Arbeitsstil. Man versucht, das System zu brechen, anstatt sich mit ihm anzufreunden. Wir hatten immer die Möglichkeit, Fragen zu testen, und ich habe mehr über die Priorisierung von Bugs erfahren (zum Beispiel war ich es gewöhnt, grammatische Fehler in Texten zu suchen, aber das „Gewicht“ eines solchen Bugs ist sehr gering; und umgekehrt stellte sich heraus, dass etwas, das mir nicht sehr wichtig erschien, am Ende ein kritischer Bug war, der sofort behoben wurde).
Auf der Veranstaltung gaben die Kollegen eine Zusammenfassung der Testtheorie. Das war hilfreich für nicht-technische Spezialisten. Einige Tage später bemerkte ich, dass ich den Support einer anderen Website mit der Formel „was-wo-wann“ kontaktierte und ausführlich meine Erwartungen an die Website und die Realität beschrieb.

Fazit

Wenn Sie das Leben des Teams diversifizieren, einen frischen Blick auf die Funktionalität werfen und ein Mini «Iss deine eigene Hundeleckerei», dann kannst du versuchen, eine solche Veranstaltung durchzuführen, und danach können wir sie gemeinsam besprechen.

Allen alles Gute und weniger Bugs!

Quelle: habr.com