Redakcja
Na początek muszę podkreślić, że choć rola full stack może być interesująca dla pracodawców, to jednak jest ona niezmiernie trudna i osiągalna jedynie dla niewielkiej grupy osób. Jest to zbiór bardzo rozbieżnych i bardzo szerokich kompetencji, których trudno jest się nauczyć, a które pozyskuje się zazwyczaj przez wieloletnie doświadczenie projektowe. Jest to również przeciwieństwo popularnego teraz trendu do poszukiwania niszy i wąskiej specjalizacji.
Szukając definicji full stack testera możemy odwołać się do roli full stack programisty, który łączy w sobie kompetencje tworzenia zarówno części frontendowych, jak i backendowych oprogramowania. Przy przełożeniu tego na umiejętności testerskie możemy powiedzieć tak o osobie, która potrafi testować interfejs graficzny aplikacji i ma duże zrozumienie dla aspektów biznesowych, a z drugiej strony potrafi również zejść do aspektów bardzo technicznych, z testowaniem API oraz automatyzacją testów na wielu poziomach. Są to dwa różne bieguny testowania.
Tester "front-end" potrafi wcielić się w użytkownika i analizować oprogramowanie pod kątem jego potrzeb. Będzie projektował wartościowe testy procesów i funkcji wbudowanych w aplikację i zwracał uwagę na aspekty dostępności i użyteczności interfejsów.
Tester "back-end" to z kolei osoba, która rozmawia z programistą w jego języku i programuje testy od unit testów, poprzez API, aż po automatyzację na GUI. Musi również mieć pełne zrozumienie dla procesów CI / CD.
Full stack tester jest więc jednoosobowym działem testów. Z tą samą gracją weryfikuje poprawność implementacji struktury bazodanowej i architekturę, jak i ocenia poprawność językową komunikatów błędów i dobór kolorystyki w interfejsie.
Tak definiowana rola niesie ze sobą wiele problemów. Do najpoważniejszych należy to, że takich osób praktycznie nie ma. Niby każdy z nas zna przynajmniej jednego takiego testera, ale może to jest jedna (bardzo znana) osoba? Osobiście na palcach jednej ręki mógłbym wskazać ludzi, którzy posługują się efektywnie językiem kodowania i językiem biznesu.
Kolejnym, olbrzymim niebezpieczeństwem jest nieświadomość pracodawców, którzy zbyt często poszukują ludzi, którzy "trochę potestują manualnie i trochę poautomatyzują". Uważajcie, bo to jest pułapka! Pomijając już nakład na sam potencjalny task switching przy tak różnych zadaniach, to niestety historia pod tytułem "50 manual /50 automation" często kończy się na 80/20, a w skrajnym przypadku 100/0. Osoby chcące więc rozwijać się w automatyzacji wpadają w "manualne" testy, gdy ciągle brak czasu na testy automatyczne. Prowadzi to do szybkiego wypalenia się i ucieczki do innego projektu lub firmy.
Full stack może być też próbą przykrycia chęci pracodawców do oszczędności. Skoro kierownik projektu szacuje, że nie mamy pełnego etatu dla testera manualnego, automatyka, testera wydajności, to skleja jeden etat z jednej osoby od wszystkiego. Niestety często takie podejście wynika z braku wiedzy i doszacowania ile zajmują poszczególne testy. Oczywiście jeden tester będzie tańszy, ale z dużą dozą prawdopodobieństwa można powiedzieć, że nie będzie on w stanie wykonać żadnego z wymienionych testów w satysfakcjonującym zakresie. Co więcej, full stack tester się nie skaluje. Wybierając jedną osobę do wszystkiego, w którymś momencie wyczerpią się możliwości godzinowe pracy takiego specjalisty i nie da się na niego przerzucić kolejnego zadania. Co więc wtedy? Zatrudnić kolejnego fullstackowca? Pozbawić obecnie zatrudnionego jednej części jego obowiązków? A przecież może być tak, że jego motywacją do pracy jest działanie zarówno po stronie wizualnej, jak i po stronie technikaliów. Full stack może być wiec drogą bez wyjścia.
Full stack tester to człowiek orkiestra. Z jednej strony rola bardzo trudna, a z drugiej dająca olbrzymią satysfakcję i możliwości pracy w bardzo wielu, bardzo różnych obszarach. Zanim jednak zdecydujecie się na taki kierunek rozwoju, rozważcie wszystkie plusy i minusy.
