Dlaczego zorganizowaliśmy hackaton dla testerów?

Artykuł ten zainteresuje tych, którzy podobnie jak my stają przed problemem wyboru odpowiedniego specjalisty w dziedzinie testowania.

Co dziwne, wraz ze wzrostem liczby firm IT w naszej republice wzrasta tylko liczba godnych programistów, ale nie testerów. Wiele osób pragnie wykonywać ten zawód, ale niewielu rozumie jego znaczenie.

Nie mogę wypowiadać się w imieniu wszystkich firm IT, ale rolę QA/QC przypisaliśmy naszym specjalistom ds. jakości. Są częścią zespołu programistów i uczestniczą we wszystkich etapach rozwoju, od badań po wydanie nowej wersji.

Tester w zespole już na etapie planowania musi przemyśleć wszystkie wymagania funkcjonalne i pozafunkcjonalne, aby zaakceptować historię użytkownika. Musi rozumieć charakterystykę operacyjną produktu równie dobrze, jak programiści, a nawet lepiej i pomagać zespołowi nie podejmować błędnych decyzji już na etapie planowania. Tester musi dobrze rozumieć, jak będzie działać zaimplementowana funkcjonalność i jakie pułapki mogą się z nią wiązać. Nasi testerzy sami tworzą plany testów i przypadki testowe, a także przygotowują wszystkie niezbędne stanowiska testowe. Testowanie według gotowej specyfikacji, takiej jak małpi kliker, nie jest naszą opcją. Pracując w zespole, musi pomóc wypuścić wartościowy produkt i w porę włączyć alarm, jeśli coś pójdzie nie tak.

Na co trafiliśmy szukając testerów

Na etapie studiowania wielu CV wydawało się, że są dla nas specjaliści z odpowiednim doświadczeniem i nie będzie żadnych problemów z wyborem testera do naszego zespołu. Jednak podczas osobistych spotkań coraz częściej spotykaliśmy kandydatów, którzy rzeczywiście byli dość daleko od świata technologii informatycznych (nie potrafili na przykład powiedzieć zasad interakcji między przeglądarką a serwerem WWW, podstaw bezpieczeństwa, relacyjnych i nie- relacyjnych baz danych, nie mieli pojęcia o wirtualizacji i konteneryzacji), ale jednocześnie ocenili się na poziomie Senior QA. Po przeprowadzeniu kilkudziesięciu wywiadów doszliśmy do wniosku, że liczba odpowiednich dla nas specjalistów w regionie jest znikoma.

Następnie opowiem Wam, jakie kroki podjęliśmy i na jakie błędy natknęliśmy się, aby pozyskać tych długo oczekiwanych zawodników pod względem jakości.

Jak próbowaliśmy naprawić sytuację

Wyczerpawszy się w pozyskiwaniu gotowych specjalistów, zaczęliśmy celować w pobliskie obszary:

1. Staraliśmy się zastosować praktyki oceniania, aby spośród wielu osób „zostawiających to” zidentyfikować tych, z których możemy wykształcić silnych specjalistów.

   Do wykonania zadań poprosiliśmy grupę potencjalnych kandydatów o mniej więcej tym samym poziomie wiedzy. Obserwując ich tok myślenia, staraliśmy się wyłonić najbardziej obiecującego kandydata.

   W szczególności wymyśliliśmy zadania sprawdzające uważność, zrozumienie możliwości technologii i cech wielokulturowości:

   
   

2. Organizowaliśmy spotkania dla testerów, aby poszerzyć granice zrozumienia zawodu wśród istniejącego kontyngentu.

   Opowiem trochę o każdym z nich.

   Ufa Software QA and Testing Meetup #1 to nasza pierwsza próba zgromadzenia osób, którym zależy na zawodzie, a jednocześnie zrozumienia, czy społeczeństwo będzie zainteresowane tym, co chcemy im przekazać. Zasadniczo nasze raporty dotyczyły tego, od czego lepiej zacząć, jeśli zdecydowałeś się zostać testerem. Pomóż początkującym otworzyć oczy i spojrzeć na testowanie jak dorosły. Rozmawialiśmy o krokach, jakie muszą podjąć początkujący testerzy, aby dołączyć do zawodu. O tym, czym jest jakość i jak ją osiągnąć w rzeczywistych warunkach. A także, czym jest testowanie automatyczne i gdzie bardziej odpowiednie jest jego użycie.

   
   
   Następnie w odstępie 1-2 miesięcy odbyliśmy jeszcze dwa spotkania. Uczestników było już dwukrotnie więcej. Podczas spotkania „Ufa Software QA and Testing Meetup #2” zagłębiliśmy się w temat. Rozmawiali o systemach śledzenia błędów, testowaniu UI/UX, poruszyli temat Dockera, Ansible, a także rozmawiali o możliwych konfliktach pomiędzy programistą a testerem i sposobach ich rozwiązywania.

   Nasze trzecie spotkanie „Ufa Software QA and Testing Meetup #3” było pośrednio związane z pracą testerów, ale pomogło w odpowiednim czasie przypomnieć programistom o ich obowiązkach technicznych i organizacyjnych: testowaniu obciążenia, testowaniu e2e, Selenium w autotestach, podatnościach aplikacji webowych .

   Przez cały ten czas uczyliśmy się jak stworzyć normalne światło i dźwięk w transmisjach z naszych wydarzeń:

   → Pierwsze kroki w testowaniu – Ufa Software QA i Testing Meetup #1
   → Testowanie UI/UX – Ufa Software QA i spotkanie testujące #2
   → Testowanie bezpieczeństwa, testowanie obciążenia i autotestowanie – Ufa QA i spotkanie testowe #3

3. W końcu postanowiliśmy spróbować zorganizować hackaton dla testerów

Jak przygotowaliśmy i przeprowadziliśmy hackaton dla testerów

Na początek próbowaliśmy zrozumieć, co to za „bestia” i jak zwykle jest przeprowadzana. Jak się okazało, tego typu wydarzenia nie odbywały się w Federacji Rosyjskiej wiele razy i nie ma skąd zapożyczać pomysłów. Po drugie, nie chciałem od razu inwestować dużych środków w wydarzenie, które na pierwszy rzut oka wydawało się wątpliwe. Dlatego zdecydowaliśmy, że będziemy robić krótkie mini-hackathony, nie dla całego cyklu pracy QA, ale dla poszczególnych etapów.

Naszym głównym problemem jest brak praktyki wśród lokalnych testerów w tworzeniu przejrzystych map testów. Nie poświęcają czasu na badanie historii użytkowników przed wdrożeniem i tworzenie jasnych dla programistów kryteriów akceptacji w zakresie wymagań funkcjonalnych i niefunkcjonalnych, interfejsu użytkownika/UX, bezpieczeństwa, obciążeń i obciążeń szczytowych. Dlatego też postanowiliśmy po raz pierwszy przejść przez najciekawszą i najbardziej kreatywną część ich pracy – analizę i formułowanie wymagań podczas badań przedprojektowych.

Oszacowaliśmy potencjalną liczbę uczestników i uznaliśmy, że potrzebujemy co najmniej 5 backlogów na wydania MVP, 5 produktów i 5 osób, które pełniłyby rolę właścicieli produktów, rozszyfrowywały potrzeby biznesowe i podejmowały decyzje o ograniczeniach.

Oto, co mamy: zaległości w hackatonie.

Główną ideą było zaproponowanie tematów jak najbardziej odległych od codziennej pracy uczestników i danie im pola do twórczego lotu wyobraźni.

Jakie błędy popełniliśmy i co mogliśmy zrobić lepiej?

Stosowanie praktyk oceny, tak popularnych w obszarze zatrudniania sprzedawców i menedżerów niższego szczebla, wymagało ogromnego wysiłku, ale nie pozwalało poświęcić wystarczającej uwagi każdemu uczestnikowi i ocenić jego umiejętności. Ogólnie rzecz biorąc, ta opcja selekcji kreuje negatywny wizerunek firmy, ponieważ sporo osób otrzymuje niewystarczającą informację zwrotną, a następnie tworzy w sobie i innych efekt tyranii pracodawcy (komunikacja w społecznościach IT jest bardzo rozwinięta). W rezultacie pozostaje nam dosłownie dwóch potencjalnych kandydatów z bardzo odległą przyszłością.

Spotkania to dobra rzecz. Tworzy się obszerna baza do opracowań i podnosi się ogólny poziom uczestników. Firma staje się coraz bardziej rozpoznawalna na rynku. Ale pracochłonność takich przedsiębiorstw nie jest mała. Musisz jasno zrozumieć, że organizowanie spotkań będzie wymagało około 700–800 roboczogodzin rocznie.

Jeśli chodzi o hackaton testowy. Tego typu wydarzenia jeszcze się nie znudziły, gdyż w odróżnieniu od hackatonów dla programistów odbywają się one znacznie rzadziej. Zaletą tego pomysłu jest to, że w spokojny sposób można wymienić dużą ilość wiedzy praktycznej i dość dokładnie określić poziom każdego uczestnika.

Po przeanalizowaniu wyników wydarzenia zdaliśmy sobie sprawę, że popełniliśmy wiele błędów:

1. Najbardziej niewybaczalnym błędem było przekonanie, że 4-5 godzin nam wystarczy. W rezultacie samo wprowadzenie i zapoznanie się z backlogami zajęło prawie 2 godziny.
   Praca z właścicielami produktu na początkowym etapie i czas zagłębienia się w temat zajmowały tyle samo czasu. Zatem pozostały czas wyraźnie nie wystarczył na kompleksowe opracowanie map testowych.
2. Nie było wystarczająco dużo czasu i energii na szczegółowe opinie na temat każdej mapy, ponieważ była już noc. Dlatego wyraźnie zawiedliśmy tę część, ale początkowo miała ona być najcenniejsza w hackatonie.
3. Postanowiliśmy ocenić jakość rozwoju poprzez proste głosowanie wszystkich uczestników, przyznając każdemu zespołowi 3 głosy, które mogli oddać za pracę najwyższej jakości. Może lepiej byłoby zorganizować jury.

Co osiągnąłeś?

Częściowo rozwiązaliśmy nasz problem i teraz pracuje dla nas 4 odważnych, przystojnych mężczyzn, obsługujących tyły 4 zespołów programistycznych. Nie zauważono jeszcze znacznej puli potencjalnych silnych kandydatów i wymiernych zmian w poziomie miejskiej społeczności QA. Ale jest pewien postęp i nie można się z tego nie cieszyć.

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