Cześć wszystkim! Nazywam się Julia i jestem testerem. W zeszłym roku opowiadałam Wam o Bagodzielni — wydarzeniu organizowanym w naszej firmie w celu przeczyszczenia backlogu błędów. To całkiem realna opcja, aby znacznie go zmniejszyć (w różnych zespołach od 10 do 50%) w ciągu jednego dnia.

Dziś chcę opowiedzieć Wam o naszej wiosennej edycji Bagodzielni — BUgHunting (BUH). Tym razem nie naprawialiśmy starych błędów, ale szukaliśmy nowych i proponowaliśmy pomysły na funkcje. Poniżej znajdziecie wiele szczegółów na temat organizacji takich wydarzeń, naszych wyników i opinii uczestników.

Po przemyśleniu i opisaniu regulaminu, wysłaliśmy zaproszenie we wszystkie kanały w firmowym Slacku, w którym nie było żadnych ograniczeń:

Ostatecznie zapisało się około 30 osób — zarówno programiści, jak i specjaliści nietechniczni. Na wydarzenie przeznaczono cały dzień roboczy, zarezerwowano dużą salę konferencyjną, a obiady zorganizowano w stołówce biurowej.

Dlaczego?

Mogłoby się wydawać, że każdy zespół testuje swoją funkcjonalność. Użytkownicy zgłaszają nam błędy. Po co w ogóle organizować takie wydarzenie?

Mieliśmy kilka celów.

1. Przybliżyć chłopaków do pokrewnych projektów/produktów.
   Obecnie w naszej firmie wszyscy pracują w osobnych zespołach — jednostkach. To grupy projektowe, które pracują nad swoją częścią funkcjonalności i nie zawsze są w pełni świadome, co dzieje się w innych projektach.
2. Po prostu zapoznać kolegów ze sobą.
   Mamy prawie 800 pracowników w biurze w Moskwie, nie wszyscy koledzy znają się osobiście.
3. Podnieść umiejętności w poszukiwaniu błędów przez programistów w swoich produktach.
   Obecnie promujemy Agile Testing i rozwijamy naszych pracowników w tym kierunku.
4. Zaangażować w testowanie nie tylko specjalistów technicznych.
   Oprócz działu technicznego mamy wielu kolegów z innych specjalności, którym chciałoby się więcej powiedzieć o testowaniu, o tym jak poprawnie zgłaszać błędy, abyśmy otrzymywali mniej wiadomości w formacie „Aaaa... nic nie działa”.
5. No i oczywiście, znaleźć podstępne i nieoczywiste błędy.
   Chcieliśmy pomóc zespołom w testowaniu nowych funkcji i dać im możliwość zobaczenia zrealizowanej funkcjonalności z innej perspektywy.

Realizacja

Nasz dzień składał się z kilku bloków:

• briefing;
• krótkie wykłady na temat testowania, na których poruszyliśmy tylko podstawowe zagadnienia (cele i zasady testowania itp.);
• sekcja dotycząca "zasad dobrego tonu" przy zgłaszaniu błędów (tutaj dobrze opisane zasady);
• cztery sesje testowania z projektami o wysokopoziomowo opisanych scenariuszach; przed każdą sesją odbywał się krótki wstęp do projektu i podział na zespoły;
• krótkie badanie dotyczące wydarzenia;
• podsumowanie.

(Nie zapomnieliśmy również o przerwach między sesjami i obiadem).

Podstawowe zasady

• Rejestracja na wydarzenia jest indywidualna, co rozwiązuje problem przepływu całego zespołu, jeśli jedna osoba zdecyduje się nie przyjść.
• Podczas każdej sesji uczestnicy zmieniają zespół. To pozwala uczestnikom przychodzić i odchodzić w dowolnym momencie, a także poznawać większą liczbę osób.
• Polecenia po dwa osoby przed każdą sesją są losowo dobierane, co sprawia, że jest to bardziej dynamiczne i szybsze.
• Za zgłoszone błędy przyznawane są punkty (od 3 do 10) w zależności od krytyczności.
• Za duplikaty punkty nie są przyznawane.
• Błędy powinny być zgłaszane przez członka zespołu zgodnie z wszystkimi wewnętrznymi standardami.
• Prośby o funkcje zgłaszane są w osobnym zadaniu i uczestniczą w oddzielnej nominacji.
• Czuwają nad przestrzeganiem wszystkich zasad zespół audytowy.

Inne szczegóły

• Początkowo chcieliśmy zorganizować "zaawansowane" wydarzenie dotyczące testowania, ale ponieważ zgłosiło się dość dużo osób z zespołów nieproduktywnych (SMM, prawnicy, PR), musieliśmy znacznie uprościć treść i usunąć skomplikowane/profilowe przypadki.
• Ze względu na pracę jednostek w Jira w różnych projektach zgodnie ze swoimi przepływami, specjalnie stworzyliśmy osobny projekt, w którym skonfigurowaliśmy szablon do zgłaszania błędów.
• Do obliczania punktów planowaliśmy użyć tabeli liderów, która była aktualizowana za pomocą webhooków, ale coś poszło nie tak i ostatecznie obliczenia musieliśmy robić ręcznie.

Każdy przy organizacji wydarzeń napotyka na pułapki i aby było wam trochę łatwiej, opiszę nasze problemy, których będziecie mogli uniknąć.

Jeden z prelegentów nagle zachorował i musieliśmy szukać nowego.
Miałem ogromne szczęście, że znalazłem zastępstwo z tej samej drużyny o 9 rano). Ale lepiej nie polegać na szczęściu i mieć podstawowego. Lub być gotowym samemu na wygłoszenie potrzebnego wykładu.

Nie zdążyliśmy wprowadzić funkcjonalności, więc musieliśmy zamieniać miejsca blokami..
Aby nie marnować całego bloku, lepiej mieć plan awaryjny.

Część testowych użytkowników odpadła, musieliśmy szybko tworzyć nowych..
Sprawdźcie testowych użytkowników z wyprzedzeniem lub miejcie możliwość szybkie ich stworzenia.

Prawie nikt z chłopaków, dla których uprościliśmy format, nie przyszedł..
Nie trzeba nikogo na siłę ciągnąć. Pogódźcie się z tym.
Jest opcja, aby ściśle określić format wydarzenia: «amatorski»/«zaawansowany», lub przygotować od razu dwa warianty i już po fakcie zdecydować, który przeprowadzić.

Przydatne punkty organizacyjne:

• zarezerwujcie salę konferencyjną z wyprzedzeniem;
• ustawcie stoły, nie zapomnijcie o przedłużaczach i filtrach sieciowych (ładowania laptopów/telefonów na cały dzień może nie wystarczyć);
• zautomatyzujcie proces liczenia punktów;
• przygotujcie tabele rankingowe;
• zróbcie papierowe materiały z loginami i hasłami testowych użytkowników, instrukcją obsługi Jira, scenariuszami;
• nie zapomnijcie na tydzień przed wydarzeniem wysłać przypomnienia, dodatkowo określcie, co należy ze sobą zabrać (laptopy/urządzenia);
• opowiadajcie kolegom o wydarzeniu na demówkach, podczas obiadów, przy filiżance kawy;
• uzgodnijcie z devopsami, aby nic nie aktualizować i nie wdrażać w tym dniu;
• przygotujcie prelegentów;
• uzgodnijcie z właścicielami funkcji i zapiszcie jak najwięcej scenariuszy do testowania;
• zamówcie smakołyki (ciasteczka/cukierki) na przekąski;
• nie zapomnijcie opowiedzieć o wynikach wydarzenia.

Wyniki

W ciągu całego dnia uczestnicy zdążyli przetestować 4 projekty i zgłosić 192 błędy (z czego 134 unikalnych) oraz 7 zadań z funkcjami. Oczywiście, część tych błędów właściciele projektów już znali. Ale były też nieoczekiwane odkrycia.

Wszyscy uczestnicy otrzymali słodkie nagrody.

A zwycięzcy — termosy, przypinki, bluzy.

Co się okazało ciekawe:

• dla uczestników format rygorystycznych sesji, kiedy czas jest ograniczony i nie można tracić dużo czasu na zastanawianie się, był zaskoczeniem;
• udało się przetestować wersję desktopową, mobilną i aplikacje;
• zobaczyliśmy od razu wiele projektów, nie było czasu na nudę;
• poznaliśmy różnych kolegów, zobaczyliśmy ich podejścia do zgłaszania błędów;
• odczuliśmy cały ból testerów.

Co można poprawić:

• robić mniej projektów i zwiększyć czas sesji do 1,5 godziny;
• przygotować prezenty / pamiątki z wyprzedzeniem (czasami zatwierdzenie / płatność przeciąga się na miesiąc);
• zrelaksować się i pogodzić z tym, że coś pójdzie nie tak i wystąpią siły wyższe.

Opinie

Anna Bystrikova, administrator systemów: „Bugownia jest dla mnie bardzo pouczająca. Dowiedziałam się o procesie testowania, poczułam całą „bolączkę” testerów.
Na początku, testując, jako przykładny użytkownik, sprawdzasz podstawowe rzeczy: czy przycisk działa, czy strona się ładowała, czy układ się nie rozsypał. Ale później rozumiesz, że trzeba myśleć bardziej niekonwencjonalnie i próbować „złamać” aplikację. Praca testerów nie jest łatwa, nie wystarczy „klikać” po całym interfejsie, trzeba starać się myśleć nieszablonowo i być niezwykle uważnym.
Wrażenia pozostały tylko pozytywne, nawet teraz, po pewnym czasie od wydarzenia, widzę, jak praca nad zgłoszonymi przeze mnie błędami jest kontynuowana. Fajnie jest czuć się częścią poprawy produktu ^_^”.

Dmitrij Sieliezniow, programista frontendowy: „Testowanie w trybie rywalizacyjnym bardzo motywuje do znalezienia większej liczby błędów). Uważam, że każdy powinien spróbować wziąć udział w Bug Hunt. Testowanie eksploracyjne pozwala na odkrycie tych przypadków, które nie zostały ujęte w planie testowania. Poza tym osoby, które nie znają projektu, mogą dać opinię na temat użyteczności usługi.”

Antonina Tatuś, starszy redaktor: „Bardzo podobało mi się spróbować swoich sił jako tester. To zupełnie inny styl pracy. Starasz się złamać system, a nie zaprzyjaźnić się z nim. Zawsze mieliśmy możliwość zadawania pytań kolegom na temat testowania. Dowiedziałam się więcej o priorytetyzacji błędów (na przykład przyzwyczaiłam się do wyłapywania błędów gramatycznych w tekstach, ale „waga” takiego błędu jest bardzo mała; i odwrotnie, coś, co wydawało mi się mało ważne, okazało się ostatecznie krytycznym błędem, który od razu naprawiono).
Na wydarzeniu chłopaki przedstawili streszczenie teorii testowania. To było przydatne dla nietechnicznych specjalistów. A ja kilka dni później zdałam sobie sprawę, że piszę do wsparcia innej strony korzystając z formuły „co-gdzie-kiedy” i szczegółowo opisuję swoje oczekiwania wobec strony i rzeczywistości.”

Podsumowanie

Jeśli chcesz urozmaicić życie zespołu, spojrzeć świeżym okiem na funkcjonalność, zorganizować mini «Jedz swoje własne jedzenie dla psów», to możesz spróbować zorganizować takie wydarzenie, a potem możemy je wspólnie omówić.

Wszystkiego dobrego i mniej błędów!

Źródło: habr.com