Hallo zusammen! Ich bin Julia und ich teste Software. Letztes Jahr habe ich euch von Bug-Bash erzählt – einer Veranstaltung, die wir in unserem Unternehmen organisieren, um den Bug-Backlog zu bereinigen. Dies ist eine durchaus praktikable Möglichkeit, ihn (in verschiedenen Teams zwischen 10 und 50%) an einem einzigen Tag deutlich zu reduzieren.

Heute möchte ich euch von unserem Frühlingsformat des Bug-Bashs – BUgHunting (BUH) berichten. Diesmal haben wir keine alten Bugs behoben, sondern nach neuen gesucht und Ideen für Features angeboten. Im Folgenden findet ihr viele Details zur Organisation solcher Veranstaltungen, unsere Ergebnisse und das Feedback der Teilnehmer.

Nachdem wir die Regeln durchdacht und verfasst hatten, haben wir in allen Kanälen unseres Unternehmens-Slack eine Einladung verschickt, in der es keine Einschränkungen gab:

Am Ende haben sich etwa 30 Personen angemeldet – sowohl Entwickler als auch Nicht-Techniker. Für die Veranstaltung wurde ein ganzer Arbeitstag eingeplant, ein großer Konferenzraum reserviert und das Mittagessen in der Bürokantine organisiert.

Warum?

Es scheint, als würde jedes Team seine Funktionalität testen. Nutzer berichten uns von Bugs. Warum sollte man so eine Veranstaltung überhaupt durchführen?

Wir hatten mehrere Ziele.

1. Die Kollegen mit verwandten Projekten/Produkten bekannt machen..
   Aktuell arbeiten bei uns alle in separaten Teams – Units. Es handelt sich um Projektgruppen, die ihre eigenen Funktionalitäten entwickeln und nicht immer genau wissen, was in anderen Projekten passiert.
2. Die Kollegen einfach untereinander bekannt machen..
   Wir haben fast 800 Mitarbeiter im Moskauer Büro, und nicht alle Kollegen kennen sich persönlich.
3. Die Fähigkeit der Entwickler, Bugs in ihren Produkten zu finden, verbessern..
   Derzeit fördern wir Agile Testing und schulen die Kollegen in diesem Bereich.
4. Das Testen nicht nur technischen Spezialisten zugänglich machen..
   Neben der technischen Abteilung gibt es viele Kollegen aus anderen Fachrichtungen, die mehr über Testing erfahren möchten, insbesondere darüber, wie man Bugs richtig reportet, damit wir weniger Nachrichten im Format ‚Aaaa… nichts funktioniert‘ bekommen.
5. Und natürlich geheime und weniger offensichtliche Bugs finden..
   Wir wollten den Teams helfen, neue Features zu testen und ihnen die Möglichkeit geben, die implementierte Funktionalität aus einem anderen Blickwinkel zu betrachten.

Implementierung

Unser Tag bestand aus mehreren Blöcken:

• Briefing;
• eine kurze Lektion zu den Grundlagen des Testens, in der wir nur die wichtigsten Punkte (Ziele und Prinzipien des Testens usw.) angesprochen haben;
• ein Abschnitt über die 'guten Manieren' beim Erstellen von Bugs (hier die Prinzipien sind gut beschrieben);
• vier Testsessions zu Projekten mit hochrangig beschriebenen Szenarien; vor jeder Sitzung gab es eine kurze Einführung in das Projekt und die Aufteilung in Teams;
• eine kurze Umfrage zur Veranstaltung;
• eine Zusammenfassung.

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

Hauptregeln

• Eine individuelle Registrierung für Veranstaltungen, was das Problem des inkrementellen Ausscheidens der ganzen Gruppe löst, wenn eine Person nicht teilnehmen möchte.
• Jede Sitzung wechselt die Teilnehmerteams. Dadurch können Teilnehmer jederzeit kommen und gehen, und man hat die Möglichkeit, viele Menschen kennenzulernen.
• Befehle zwei Personen werden vor jeder Sitzung zufällig ausgewählt, was das Ganze dynamischer und schneller macht.
• Für registrierte Bugs werden Punkte (von 3 bis 10) je nach Kritikalität vergeben..
• Für Duplikate werden keine Punkte vergeben.
• Bugs müssen von einem Teammitglied gemäß allen internen Standards eingetragen werden.
• Feature-Requests werden in separaten Aufgaben erfasst und nehmen an einer eigenen Nominierung teil.
• Die Einhaltung aller Regeln wird von einem Audit-Team überwacht.

Weitere Details

• Ursprünglich sollte es eine 'fortgeschrittene' Testveranstaltung werden, aber da sich viele Teilnehmer aus nicht-produktbezogenen Teams (SMM, Juristen, PR) angemeldet hatten, mussten wir den Inhalt stark vereinfachen und komplexe/profilspezifische Fälle entfernen.
• Aufgrund der Arbeit der Einheiten in Jira in verschiedenen Projekten und ihren eigenen Abläufen haben wir absichtlich ein separates Projekt eingerichtet, in dem wir eine Vorlage für die Fehlererfassung konfiguriert haben.
• Wir hatten geplant, ein Leaderboard für die Punkteauswertung zu verwenden, das über Webhooks aktualisiert wird, aber irgendetwas lief schief, und letztendlich mussten wir die Auswertung manuell durchführen.

Jeder, der Veranstaltungen organisiert, stößt auf Hürden. Um es Ihnen etwas einfacher zu machen, beschreibe ich unsere Probleme, die Sie vermeiden können.

Einer der Referenten wurde plötzlich krank, und wir mussten einen neuen suchen..
Ich hatte riesiges Glück, dass ich um 9 Uhr morgens einen Ersatz aus demselben Team gefunden habe). Aber es ist besser, sich nicht auf Glück zu verlassen und einen Plan B zu haben. Oder selbst bereit zu sein, den erforderlichen Vortrag zu halten.

Wir konnten die Funktionalität nicht rechtzeitig bereitstellen und mussten die Blöcke umstellen..
Um nicht den ganzen Block wegzuwerfen, ist es besser, einen Notfallplan zu haben.

Einige Testnutzer sind abgesprungen, ich musste schnell neue erstellen..
Überprüfen Sie die Testnutzer im Voraus oder stellen Sie sicher, dass Sie sie schnell erstellen können.

Fast niemand von den Leuten, für die wir das Format vereinfacht haben, ist gekommen..
Man sollte niemanden zwingen. Akzeptieren Sie es.
Es gibt die Möglichkeit, das Veranstaltungsformat klar zu definieren: "Hobbyist" / "Fortgeschritten", oder gleich zwei Varianten vorzubereiten und dann zu entscheiden, welche durchgeführt wird.

Nützliche organisatorische Punkte:

• Buchen Sie den Besprechungsraum im Voraus;
• Stellen Sie die Tische auf, vergessen Sie nicht Verlängerungskabel und Netzfilter (für das Aufladen von Laptops/Handys reicht die Energie möglicherweise nicht für den ganzen Tag);
• Automatisieren Sie den Punktzählprozess;
• Bereiten Sie die Ranglisten vor;
• Erstellen Sie Papiervorlagen mit Anmeldedaten und Passwörtern der Testnutzer sowie Anleitungen zur Arbeit mit Jira und Skripten;
• Vergessen Sie nicht eine Woche vor der Veranstaltung Erinnerungen zu versenden und zusätzlich anzugeben, was Sie mitbringen müssen (Laptops/Geräte);
• Sprechen Sie mit Kollegen über die Veranstaltung beim Demo, beim Mittagessen, über eine Tasse Kaffee;
• Vereinbaren Sie mit den DevOps, an diesem Tag nichts zu aktualisieren oder auszurollen;
• Bereiten Sie die Vortragenden vor;
• Koordinieren Sie sich mit den Feature-Eigentümern und erstellen Sie mehr Test-Szenarien;
• Bestellen Sie Snacks (Kekse/Süßigkeiten) für die Pausen;
• Vergessen Sie nicht, über die Ergebnisse der Veranstaltung zu berichten.

Ergebnisse

Im Laufe des Tages konnten die Jungs 4 Projekte testen und 192 Bugs erfassen (davon 134 einzigartig) sowie 7 Aufgaben mit Feature-Anfragen. Natürlich waren den Projektbesitzern einige dieser Bugs bereits bekannt. Aber es gab auch unerwartete Funde.

Alle Teilnehmer erhielten süße Belohnungen.

Die Gewinner — Thermobecher, Buttons, Sweatshirts.

Was interessant war:

• Der Format der intensiven Sessions überraschte die Teilnehmer, da die Zeit begrenzt war und nicht viel Zeit zum Nachdenken blieb;
• Es gelang, die Desktop-Version, die mobile Version und die Apps zu testen;
• Wir haben sofort viele Projekte angesehen, es gab keine Zeit zum Langeweilen;
• Wir haben verschiedene Kollegen kennengelernt und ihre Ansätze zur Fehlerverfolgung betrachtet;
• Wir haben den gesamten Schmerz der Tester gespürt.

Was verbessert werden kann:

• Weniger Projekte durchführen und die Sitzungszeit auf 1,5 Stunden verlängern;
• Geschenke/Souvenirs lange im Voraus vorbereiten (manchmal kann die Abstimmung/Zahlung einen Monat in Anspruch nehmen);
• Sich entspannen und akzeptieren, dass nicht alles nach Plan läuft und es unvorhergesehene Ereignisse geben wird.

Bewertungen

Anna Bystrikova, Systemadministratorin: „Das Bug-Testing war für mich sehr lehrreich. Ich habe den Testprozess kennengelernt und die gesamte 'Schmerz' der Tester nachvollziehen können.
Anfangs testet man als typischer Benutzer die grundlegenden Punkte: Funktioniert der Button, wechselt die Seite, ist das Layout nicht verschoben? Aber später versteht man, dass man kreativer denken sollte und versucht, die Anwendung 'zu brechen'. Tester haben eine anspruchsvolle Aufgabe – es reicht nicht, durch die gesamte Benutzeroberfläche zu klicken; man muss unkonventionell denken und äußerst aufmerksam sein.
Die Eindrücke waren durchweg positiv. Selbst jetzt, einige Zeit nach der Veranstaltung, sehe ich, wie an den von mir gefundenen Bugs gearbeitet wird. Es ist großartig, sich an der Verbesserung des Produkts beteiligt zu fühlen ^_^.

Dmitry Seleznev, Frontend-Entwickler: „Das Testen im Wettbewerbsmodus motiviert stark dazu, mehr Fehler zu finden. Ich denke, jeder sollte die Möglichkeit in Betracht ziehen, am Bug Hunting teilzunehmen. Exploratives Testen ermöglicht es, die Fälle zu entdecken, die im Testplan nicht beschrieben sind. Außerdem können unbefangene Menschen, die das Projekt nicht kennen, Feedback zur Benutzerfreundlichkeit des Services geben.“

Antonina Tatychuk, leitende Redakteurin: „Ich fand es spannend, in die Rolle des Testers zu schlüpfen. Das ist eine ganz andere Arbeitsweise. Man versucht, das System zu brechen, anstatt sich mit ihm anzufreunden. Wir hatten immer die Möglichkeit, Kollegen Fragen zum Testen zu stellen. Ich habe mehr über die Priorisierung von Fehlern gelernt (zum Beispiel bin ich es gewohnt, grammatikalische Fehler in Texten zu suchen, aber das Gewicht eines solchen Fehlers ist sehr gering; umgekehrt stellte sich etwas, das mir nicht sehr wichtig erschien, letztendlich als kritischer Fehler heraus, der sofort behoben wurde).
Bei der Veranstaltung gaben die Kollegen eine Zusammenfassung der Testtheorie. Das war hilfreich für nicht-technische Spezialisten. Und einige Tage später fiel mir auf, dass ich den Support einer anderen Seite 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 aufpeppen, einen frischen Blick auf die Funktionalität werfen und ein Mini-Event organisieren möchten, „Eat your own dog food“, dann können Sie so ein Event ausprobieren, und danach können wir es gemeinsam besprechen.

Allen alles Gute und weniger Bugs!

Quelle: habr.com