Jeden tester, trzy projekty — jak nie zwariować i nie zgubić bugów

Poniedziałek rano. Tester zaczyna od projektu A — e-commerce, React, staging na AWS. O 10:30 przeskakuje na projekt B — aplikacja mobilna, Flutter, inne środowisko testowe. Po lunchu — projekt C, legacy system w Angularze, gdzie sama konfiguracja zajmuje 15 minut. Trzy projekty, trzy Jiry (albo Jira + Linear + Trello), trzy zestawy credentiali, trzy różne definicje „gotowe do testowania". To codzienność testera w software house'ie z 10-50 osobami.

Realia QA w software house'ach — jeden tester, wiele projektów

Raport „State of Testing" (PractiTest, 2023) wskazuje, że 44% testerów pracuje jednocześnie nad więcej niż jednym projektem. W małych i średnich software house'ach ta liczba jest wyższa — bo zatrudnienie dedykowanego testera na projekt jest luksusem, na który firmy z 10-30 osobami zwyczajnie nie stać.

To nie jest problem organizacyjny, który da się rozwiązać lepszym planowaniem. To jest ograniczenie budżetowe: software house zarabia na developerach, nie na testerach. Tester jest „kosztem wspólnym" dzielonym między projekty, tak jak biurko czy licencja na Jirę. Efekt jest taki, że tester musi być efektywny na trzech frontach jednocześnie — a to jest fizycznie niemożliwe bez strat.

Ile kosztuje przełączanie się między projektami

Dr Gloria Mark z UC Irvine (badania opublikowane w „Attention Span", 2023) udowodniła, że po każdym przerwaniu — a zmiana projektu to przerwanie — człowiek potrzebuje średnio ponad 23 minuty na powrót do pełnej koncentracji. Ale w pracy testera wieloprojektowego takie przerwania zdarzają się 4-6 razy dziennie.

To nie jest tylko kwestia „wczytania się" w projekt. Każdy projekt ma swój kontekst: inne repozytorium, inne środowisko, inny zestaw test case'ów, inny flow użytkownika, innych developerów. Tester musi mentalnie „przeładować" cały kontekst — a to kosztuje czas i energię, która mogłaby iść na faktyczne testowanie.

Przy 3-4 przełączeniach dziennie to 1-2,5 godziny zmarnowane na sam context switching. W skali miesiąca: 20-50 godzin. American Psychological Association w meta-analizie badań nad multitaskingiem (Rubinstein, Meyer, Evans, 2001) wykazała, że przełączanie między zadaniami może pochłonąć nawet 40% produktywnego czasu — szczególnie gdy zadania są złożone, a praca testera zdecydowanie taka jest.

Które bugi giną, gdy tester jest rozciągnięty

Giną te, które wymagają skupienia. Testy eksploracyjne — gdzie tester nie idzie po skrypcie, ale szuka nieoczywistych scenariuszy — są najbardziej skuteczne w wykrywaniu krytycznych bugów. Ale wymagają pełnej uwagi i mentalnego zaangażowania. Przy ciągłym multitaskingu tester wraca do skryptów, bo skrypt można wykonać mechanicznie. Eksploracja wymaga flow — a flow nie istnieje, gdy co 2 godziny zmienia się projekt.

Druga kategoria bugów, które giną, to te „zauważone, ale niezaraportowane". Tester testując projekt A widzi dziwne zachowanie. Zanim otworzy Jirę i napisze raport (10-15 minut), musi iść na daily projektu B. Po daily wraca do projektu A, ale kontekst zniknął — nie pamięta dokładnych kroków reprodukcji, nie zrobił screenshota, nie zapisał URL. Bug przechodzi dalej.

Co to oznacza dla Twojego software house'u

Nie zmienisz tego, że jeden tester obsługuje kilka projektów. W software house'ie z 10-30 osobami to jest realność ekonomiczna. Możesz natomiast zmienić to, jak dużo czasu tester traci na samo raportowanie — bo to jest jedyny parametr, który da się drastycznie zredukować bez dodatkowych kosztów personalnych.

Jeśli raportowanie buga trwa 10-15 minut, tester wieloprojektowy fizycznie nie zdąży zaraportować wszystkiego. Jeśli trwa poniżej minuty — zdąży. Nie dlatego, że pracuje szybciej, ale dlatego, że raportowanie nie wymaga zmiany kontekstu. Tester zostaje w testowanej aplikacji, klika, mówi co widzi — i wraca do testowania.

Voice2Bug działa dokładnie w ten sposób. Tester klika ikonę w przeglądarce — niezależnie od tego, który projekt testuje. Mówi głosem co widzi, robi screena lub nagrywa video. Poniżej minuty. Raport automatycznie trafia do właściwego projektu w Jirze, z danymi technicznymi i kontekstem. Bez otwierania Jiry, bez szukania właściwego sprintu, bez przełączania między trackerami. Jeden klik, jeden raport, jeden projekt — nawet gdy tester obsługuje trzy.