Cześć wszystkim! Mam na imię Julia i jestem testerką. W zeszłym roku ci o tym mówiłem bagodelny - wydarzenie organizowane w naszej firmie mające na celu uporządkowanie zaległości w zakresie błędów. Jest to całkowicie realna opcja, aby znacznie go zmniejszyć (od 10 do 50% w różnych zespołach) w ciągu zaledwie jednego dnia.

Dziś chcę Wam opowiedzieć o naszym wiosennym formacie Bagodelny – BUgHunting (BUH). Tym razem nie naprawiliśmy starych błędów, ale szukaliśmy nowych i proponowaliśmy pomysły na funkcje. Pod krojem znajduje się wiele szczegółów dotyczących organizacji tego typu wydarzeń, naszych wyników oraz informacji zwrotnych od uczestników.

Po przemyśleniu i spisaniu regulaminu wysłaliśmy zaproszenie do wszystkich kanałów w korporacyjnym Slacku, które nie zawierało żadnych ograniczeń:

W rezultacie zapisało się około 30 osób – zarówno programistów, jak i specjalistów nietechnicznych. Na wydarzenie przeznaczyliśmy cały dzień roboczy, zarezerwowaliśmy dużą salę konferencyjną i zorganizowaliśmy lunche w stołówce biurowej.

Dlaczego?

Wydawać by się mogło, że każdy zespół testuje jego funkcjonalność. Użytkownicy zgłaszają nam błędy. Po co w ogóle organizować takie wydarzenie?

Mieliśmy kilka celów.

1. Przedstaw chłopakom bliżej powiązane projekty/produkty.
   Teraz w naszej firmie wszyscy pracują w oddzielnych zespołach - jednostkach. Są to zespoły projektowe, które pracują nad własną częścią funkcjonalności i nie zawsze są w pełni świadome tego, co dzieje się w innych projektach.
2. Wystarczy przedstawić sobie nawzajem swoich kolegów.
   W naszym moskiewskim biurze zatrudniamy prawie 800 pracowników, nie wszyscy koledzy znają się z widzenia.
3. Popraw zdolność programistów do znajdowania błędów w swoich produktach.
   Teraz promujemy Agile Testing i szkolimy ludzi w tym kierunku.
4. Zaangażuj w testowanie nie tylko specjalistów technicznych.
   Oprócz działu technicznego mamy wielu kolegów z innych specjalności, którzy chcieli porozmawiać więcej o testowaniu, o tym, jak prawidłowo zgłosić błąd, abyśmy otrzymywali mniej komunikatów typu „Ahhh… nic nie działa”.
5. I oczywiście znajdź podstępne i nieoczywiste błędy.
   Chciałem pomóc zespołom testować nowe funkcje i dać im możliwość spojrzenia na zaimplementowaną funkcjonalność z innej perspektywy.

realizacja

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

• odprawa;
• krótki wykład na temat testowania, w którym poruszyliśmy jedynie główne punkty (cele i zasady testowania itp.);
• rozdział poświęcony „zasadom dobrych manier” przy wprowadzaniu błędów (tutaj zasady są dobrze opisane);
• cztery sesje testowe dla projektów z szczegółowo opisanymi scenariuszami; przed każdą sesją odbywał się krótki wykład wprowadzający na temat projektu i podziału na zespoły;
• krótka ankieta na temat wydarzenia;
• zreasumowanie.

(Nie zapomnieliśmy także o przerwach pomiędzy sesjami i lunchem).

Podstawowe zasady

• Rejestracja na wydarzenia jest indywidualna, co rozwiązuje problem drenażu całego zespołu na skutek bezwładności, jeśli jedna osoba zdecyduje się nie jechać.
• Uczestnicy zmieniają zespoły w każdej sesji. Dzięki temu uczestnicy mogą przychodzić i wychodzić w dowolnym momencie, a także można poznać więcej osób.
• Polecenia dwie osoby przed każdą sesją powstają losowodzięki temu jest bardziej dynamiczny i szybszy.
• Za wprowadzone błędy zostajesz nagrodzony punkty (od 3 do 10) w zależności od krytyczności.
• Za duplikaty nie przyznaje się punktów.
• Błędy muszą być zgłaszane przez członka zespołu zgodnie ze wszystkimi wewnętrznymi standardami.
• Prośby o funkcje są tworzone w osobnym zadaniu i uczestniczą w osobnej nominacji.
• Zespół audytowy monitoruje przestrzeganie wszystkich zasad.

Inne szczegóły

• Początkowo chciałem przeprowadzić „zaawansowane” wydarzenie testowe, ale… Zarejestrowało się sporo osób z zespołów nieproduktowych (SMM, prawnicy, PR), musieliśmy znacznie uprościć treść i usunąć złożone/profilowe przypadki.
• Ze względu na pracę jednostek w Jira w różnych projektach, zgodnie z naszym flow, specjalnie stworzyliśmy osobny projekt, w którym ustaliliśmy szablon do wprowadzania błędów.
• Do obliczenia punktów planowano użyć tabeli liderów aktualizowanej za pomocą webhooków, ale coś poszło nie tak i ostatecznie obliczenia trzeba było wykonać ręcznie.

Każdy napotyka problemy przy organizacji wydarzeń, a żeby Ci to trochę ułatwić, opiszę nasze problemy, których możesz uniknąć.

Jeden z prelegentów nagle zachorował i musiał szukać nowego.
Miałem ogromne szczęście, że o 9 rano znalazłem zastępcę z tego samego zespołu). Ale lepiej nie liczyć na szczęście i mieć zapas. Możesz też przygotować się na samodzielne złożenie niezbędnego raportu.

Nie mieliśmy czasu na wdrożenie funkcjonalności, musieliśmy zamienić bloki.
Aby uniknąć wyrzucenia całego bloku, lepiej mieć plan zapasowy.

Niektórzy użytkownicy testowi odpadli, musieliśmy szybko utworzyć nowych.
Sprawdź użytkowników z wyprzedzeniem lub wykonaj je szybko.

Prawie żaden z chłopaków, dla których uproszczono format, nie przyszedł.
Nie ma potrzeby ciągnięcia nikogo na siłę. Uniż się.
Istnieje możliwość ścisłego określenia formatu wydarzenia: „amatorski”/„zaawansowany” lub przygotowania dwóch opcji na raz i dopiero po fakcie podjęcia decyzji, którą wybrać.

Przydatne punkty organizacyjne:

• zarezerwuj spotkanie z wyprzedzeniem;
• aranżuj stoły, nie zapomnij o przedłużaczach i listwach przeciwprzepięciowych (ładowanie laptopów/telefonów może nie wystarczyć na cały dzień);
• zautomatyzować proces scoringu;
• przygotować tabele rankingowe;
• sporządzać ulotki papierowe z loginami i hasłami użytkowników testowych, instrukcjami pracy z Jirą, skryptami;
• Nie zapomnij wysłać przypomnień na tydzień przed wydarzeniem, a także wskazać, co musisz ze sobą zabrać (laptopy/urządzenia);
• opowiedz o wydarzeniu swoim współpracownikom na pokazie, podczas lunchu, przy filiżance kawy;
• uzgodnij z deweloperami, że tego dnia nie będą aktualizować ani wprowadzać niczego;
• przygotować głośniki;
• negocjuj z właścicielami funkcji i napisz więcej scenariuszy do testów;
• zamówić smakołyki (ciasteczka/cukierki) jako przekąskę;
• nie zapomnij poinformować nas o wynikach wydarzenia.

wyniki

Przez cały dzień chłopakom udało się przetestować 4 projekty i stworzyć 192 błędy (w tym 134 unikalne) oraz 7 problemów z prośbami o nowe funkcje. Oczywiście właściciele projektu wiedzieli już o niektórych z tych błędów. Ale były też nieoczekiwane znaleziska.

Wszyscy uczestnicy otrzymali słodkie nagrody.

A zwycięzcami są termosy, przypinki, bluzy.

Co okazało się interesujące:

• uczestnicy uznali format trudnych sesji za nieoczekiwany, gdy czas jest ograniczony i nie można spędzić dużo czasu na myśleniu;
• udało się przetestować wersję desktopową, mobilną i aplikacje;
• oglądaliśmy wiele projektów na raz, nie było czasu na nudę;
• spotkałem różnych kolegów, przyjrzałem się ich podejściu do wprowadzania błędów;
• czuł cały ból testerów.

Co można poprawić:

• rób mniej projektów i zwiększ czas sesji do 1,5 godziny;
• przygotowuj prezenty/pamiątki ze znacznym wyprzedzeniem (czasami zatwierdzenie/płatność zajmuje miesiąc);
• zrelaksuj się i zaakceptuj fakt, że coś nie pójdzie zgodnie z planem i wystąpi siła wyższa.

Opinie

Anna Bystrikova, administrator systemu: „Dom przytułku jest dla mnie bardzo pouczający. Nauczyłem się procesu testowania i czułem cały „ból” testerów.
Na początku podczas procesu testowania jako wzorowy użytkownik sprawdzasz główne punkty: czy przycisk kliknie, czy przejdzie na stronę, czy układ się przesunął. Ale później zdajesz sobie sprawę, że musisz myśleć nieszablonowo i spróbować „złamać” aplikację. Testerzy mają trudną pracę; nie wystarczy „szperać” po całym interfejsie; trzeba spróbować myśleć nieszablonowo i być niezwykle uważnym.
Wrażenia były same pozytywne, nawet teraz, jakiś czas po wydarzeniu, widzę, jak trwają prace nad znalezionymi błędami. Wspaniale jest czuć się zaangażowanym w ulepszanie produktu ^_^.”

Dmitrij Seleznev, programista front-end: „Testowanie w trybie rywalizacji bardzo motywuje nas do znajdowania większej liczby błędów). Wydaje mi się, że każdy powinien spróbować wziąć udział w Baghuntingu. Testowanie eksploracyjne pozwala znaleźć przypadki, które nie są opisane w planie testów. Dodatkowo osoby nieznające projektu mogą wyrazić swoją opinię na temat wygody korzystania z usługi.”

Antonina Tatchuk, redaktor naczelny: „Lubiłem próbować swoich sił jako tester. To zupełnie inny styl pracy. Próbujesz złamać system, a nie zaprzyjaźnić się z nim. Zawsze mieliśmy okazję zapytać naszych kolegów o testowanie. Dowiedziałem się więcej o ustalaniu priorytetów błędów (na przykład jestem przyzwyczajony do szukania 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 istotne, okazało się krytyczny błąd, który został natychmiast naprawiony).
Na imprezie chłopaki przedstawili podsumowanie teorii testowania. Było to przydatne dla osób nietechnicznych. A kilka dni później przyłapałam się na myśleniu, że piszę na poparcie innej witryny, stosując formułę „co-gdzie-kiedy” i szczegółowo opisując moje oczekiwania wobec serwisu i rzeczywistości”.

wniosek

Jeśli chcesz urozmaicić życie swojemu zespołowi, spojrzeć na funkcjonalność na nowo, zaaranżować mini „Zjedz własną karmę dla psa”, możesz spróbować zorganizować takie wydarzenie i wtedy możemy je wspólnie omówić.

Wszystkiego najlepszego i mniej błędów!

Źródło: www.habr.com