Nie traktujmy testów jak bufora w harmonogramie — to właśnie tester jest pierwszym użytkownikiem. Wywiad z Tomaszem Zdanowiczem

– Tester korzysta z tych samych środków wytwórczych, ale w innym kontekście niż developer. Rozwiązuje problemy tej samej klasy. Kompetencyjnie spełnia wszystkie wymagania programisty, czego dowodzi rynek doceniający ewolucję w kierunku od testera do programisty czy developera – uważa Tomasz Zdanowicz, kierownik Działu Jakości i Testów IT w Play. Rozmawiamy z nim o pracy testera i związanych z nią wyzwaniach.

Jesteś ekspertem w dziedzinie testowania — pracujesz w tym zawodzie od lat. Jak oceniłbyś obecną sytuację na polskim rynku pracy testerów?

Wyzwań jest wiele i wiele mitów krąży wokół tego zawodu. Wymienię tylko kilka. Tematy konferencji są podobne do siebie od lat. Sztuczny – moim zdaniem – podział na testerów manualnych i automatyzujących. Cykliczne obwieszczenia, że to już koniec zawodu i teraz to tylko automatyzacja, sztuczna inteligencja czy nowe technologie. Znalezienie w takim otoczeniu zmotywowanego i zdeterminowanego kandydata staje się coraz trudniejsze.

Rzadko na spotkania rekrutacyjne przychodzą kandydaci regularnie czytający blogi lub media społecznościowe poświęcone testom IT. Podobnie wygląda sprawa książek lub artykułów. Niewiele lepiej jest z czytelnictwem na temat szerzej pojętego IT.

Moim zdaniem tester to taki sam specjalista jak programista. Rozwiązuje tak samo złożone problemy. Projektuje i realizuje rozwiązania innego typu. Dzisiaj – w czasach shift-left – musi również pozyskiwać dane testowe, zarządzać środowiskiem testowym, rozumieć procesy technologiczne, godzić interesy biznesu i IT, projektować rozwiązania, skrypty, generatory, MOCKi, zarządzać specyficzną dla obszaru wiedzą oraz nieustannie się szkolić.

To są ogromne wyzwania, szczególnie w złożonych stosach technologicznych. Na pewnym poziomie nie da się dzisiaj być testerem technicznym bez znajomości programowania, technik projektowania rozwiązań IT czy podstawowej umiejętności administrowania systemami.

Dlaczego z twojej perspektywy podział na testerów automatyzujących i manualnych nie ma uzasadnienia?

Programista i tester to dwa pokrewne, ale jednak różne zawody. Poszukują odpowiedzi na dwa różne pytania. To trochę tak jak skrzypek i lutnik. Pierwszy musi rozumieć, jak działa instrument zbudowany przez drugiego. Niekoniecznie musi go sam budować.

Jest to raczej podział natury organicznej – po prostu testerzy o zainteresowaniach programistycznych dostrzegli w takim podejściu swoją szansę. Firmom to odpowiada, bo z pozoru jest to korzystniejsze rozwiązanie – godzina robocza testera jest tańsza niż programisty. 

Czyli krótko mówiąc, tester automatyczny to po prostu inna nazwa programisty?

Programista umie projektować, budować i rozwijać systemy informatyczne. Rozwiązanie automatyzujące testy nie jest niczym innym jak systemem informatycznym z przeznaczeniem do automatycznego uruchamiania testów (w wielu wątkach, w dużej liczbie w wielu formach, itp.). 

Tester automatyzujący – pytania testerskie zastępuje developerskimi: „dlaczego mi to działa źle?”, „jak uniknąć redundancji kodu?”, „jak zagwarantować rozszerzalność i elastyczność?”, „jak poprawić wydajność?”, itp.

Tester korzysta z tych samych środków wytwórczych, ale w innym kontekście niż developer. Rozwiązuje problemy tej samej klasy. Kompetencyjnie spełnia wszystkie wymagania programisty, czego dowodzi rynek doceniający ewolucję w kierunku od testera do programisty czy developera.

Kiedy wchodziłem w testerski rynek pracy, mówiło się, że w NASA testerem może zostać tylko programista z kilkuletnim stażem. Nie wiem, jaka jest prawda. Dzisiaj w pewnych specyficznych obszarach duże firmy technologiczne rezygnują z oddzielnej funkcji testera. Obowiązkiem programistów jest nie tylko programowanie, ale także testowanie. Taki model nie jest możliwy do powszechnego zastosowania. Jestem przekonany, że tam, gdzie technologia nie jest homogeniczna, testerzy są i będą potrzebni.

Pytanie, w jaki sposób wydajnie testować, pociąga za sobą szereg innych trudnych pytań: „jak jest zbudowane i jak działa rozwiązanie?”, „dlaczego muszę wykonać ten test?”, „jak zachować kontrolę pokrycia?”, „jaki będzie bilans automatyzacji?”, „jakich danych potrzebuję?”, „jaki jest wpływ i zakres testowanej zmiany na pozostałe procesy?”, „jak zbudować test i zaprojektować scenariusze?”. Trzeba umieć analizować, syntetyzować i generalizować. Trzeba wiedzieć, jak projektować testy. Skupić się na weryfikacji istotnych szczegółów, funkcjonalności, wymiany i poprawności przetwarzania danych. A wszystko w przewidzianym czasie, aby uniknąć konfliktu z harmonogramem.

Dobry tester bierze pod uwagę nie tylko wymagania, ale widzi szerzej: standardy branżowe, wymagania prawne czy bezpieczeństwo danych. Na tych założeniach konstruuje swoje testy. Analizuje nie tylko jakość, ale i zgodność (jest to szczególnie istotne w regulowanych branżach takich jak bankowość czy telekomunikacja). Wpływa na cały proces wytwarzania oprogramowania.

Często spotykamy się ze stereotypem, że QA to najłatwiejsza droga do wejścia w branżę IT. Czy to prawda?

To chyba zależy od tego, o którym kierunku rozwoju zawodowego mówimy. Dla mnie testy to przede wszystkim testy oprogramowania, testy IT.

„Shift left” wpłynął także na mój obecny zespół. Duży nacisk kładziemy na bliską współpracę z developmentem. Korzystamy z tych samych narzędzi, wszyscy pracujemy na wspólnym środowisku, mówimy w tym samym języku i pracujemy w tym samym procesie.

Duża część naszych zespołów developerskich to moje koleżanki i koledzy, których rekrutowałem do testów. A więc to działa w przypadku ludzi z wykształceniem profilowym.

W przypadku przebranżowienia się sprawa jest już moim zdaniem trudniejsza. Uczenie się testowania bez wiedzy z zakresu technologii i specyfiki rozwiązania przypomina mi trochę czytanie instrukcji „na sucho”. Większość z nas raczej tego nie robi.

Współczesne rozwiązania informatyczne są bardzo skomplikowane: mnogość interfejsów, technik i technologii wytwórczych, metodyk i metod powodują, że nawet najprostsza aplikacja bywa wyzwaniem w testach. Przykładem może być strona internetowa. Jeszcze kilka lat temu była jednym z najprostszych „systemów” do testowania. Dzisiaj to wielki hub danych, czerpiący z wielu źródeł (w tym z naszego zachowania). Często jest to rozwiązanie złożone, wspierane przez sztuczną inteligencję i big data. Wysyła dane do wielu podsystemów. A wszystko jest „opakowane” w wysokiej jakości rozwiązania bezpieczeństwa informatycznego.

W tym kontekście wejście w ten świat osobom z doświadczeniem w innych branżach może być trudniejsze. Z drugiej strony, znakomicie mogą się sprawdzać jako eksperci w domenach biznesowych. Myślę tutaj np. o księgowych, geografach czy chemikach, którzy przychodząc do IT mogą stać się testerami-ekspertami, testując rozwiązania dedykowane ich branży.

Ok, omówiliśmy sobie najważniejsze wyzwania pracy w testingu. Masz może pomysły na to, jakie rozwiązania powinny wdrażać firmy?

Zasadnicze pytanie, które powinna postawić sobie osoba odpowiedzialna za IT to: „do czego potrzebny jest mi proces jakości?”. Odpowiedź powinna być na tyle konkretna, aby dało się ją przełożyć na listę celów. Następnie dobrze jest tę listę weryfikować cyklicznie. Proces jakości powinien ewoluować wraz z całą firmą, jej produktami i potrzebami klientów.

Pomocne może okazać się także zdefiniowanie jakości; co to znaczy dla organizacji. Niekoniecznie musi to być formalny dokument. Ważne, aby firma rozumiała jednoznacznie i konkretnie ten termin.

Najważniejsze, aby testerów traktować jak równorzędnych partnerów; wymagać od nich, ale też słuchać, co mają do powiedzenia. Dyskutować z nimi i „uzgadniać protokół”. Nie traktujmy testów jak bufora w harmonogramie, gry o z góry ustalonym wyniku. Testerzy są pierwszymi użytkownikami. To oni okrywają defekty, niespójności, anomalie. To od ich pracy w dużej części zależy sukces produktu.

Kolejnym niezwykle ważnym elementem jest zintegrowanie testerów z zespołem wytwórczym. Mimo „oczywistej oczywistości” bardzo często spotyka się podział „my-oni”. Wydaje mi się, że tutaj jest więcej przeszkód mentalnych niż racjonalnych. W IT jakość najtaniej jest dostarczać całym procesem, a nie jego wybranymi elementami. 

Mówimy tu głównie o tym, co irytuje w kontekście pracy testerów. A co wskazałbyś jako pozytywną stronę?

Dla mnie ogromnym atutem tego zawodu jest różnorodność. Tester ma możliwość łatwiejszego przechodzenia pomiędzy obszarami technologicznymi. Poznaje bardzo różne potrzeby biznesowe, inne standardy czy procesy i metody. Wymaga to ciągłego rozwoju, uczenia się nie tylko warstwy formalnej, ale także nieformalnej: co jest ważne, a co mniej, na co zwracać uwagę, jak się komunikować z organizacją, itd.

Myślę, że z tych samych powodów jest to doskonałe miejsce na rozpoczęcie kariery w IT. Pozwala doświadczyć całego przekroju technologicznego.

Czy jako tester, czy jako kierownik działu czerpię dużą radość i dumę z tych momentów, kiedy po wielotygodniowym, a czasami wielomiesięcznym projekcie uruchamiamy produkt i działa on od pierwszego „przekręcenia kluczyka”. A duma jest jeszcze większa, kiedy na pytanie: „A czy taki przypadek testowaliście?” możemy odpowiedzieć „Oczywiście!”.

A jak to wygląda w Twojej firmie? Parafrazując słynne pytanie: jak to jest być testerem w Play, czy dobrze? 🙂

Zdecydowanie to jest pytanie do moich koleżanek i kolegów z zespołu. Liczne badania opinii naszych pracowników realizowane przez firmę jednoznacznie wskazują na elementy doceniane.  W obszarze naszego działu na pierwszym miejscu regularnie pojawiają się: współpraca i atmosfera w zespole, wysokie kompetencje techniczne i społeczne kierowników zespołów, autonomia pracy, komunikacja, możliwość godzenia życia zawodowego z prywatnym czy świadomość priorytetów firmowych i dostęp do informacji nt. kondycji i strategii firmy.

Jednak badania socjologiczne to tylko część tego obrazu. Moje spojrzenie jest subiektywne, ale chyba nie odbiegnę od prawdy jeśli powiem, że takim elementem, który spaja wszystkich Playersów jest coś, co nazywamy kulturą Play (mówienie sobie na „ty”, bezpośredni dostęp do kierownictwa pionu czy departamentu, wspólna otwartość, autonomia działania czy otwartość na informację zwrotną). W IT to bardzo cenne „srebra rodowe”. Dla mnie szczególnie cenną cechą jest podejście do rozwiązywania problemów, gdzie premiowane jest czerpanie nauki, a nie wskazywanie winnych.

Uzupełnieniem są tutaj możliwości rozwoju kompetencji technicznych. Nasz stos technologiczny to ciekawy konglomerat technologii klasycznych i najnowszych. Współpracujemy także z różnego rodzaju biznesem od produktów, przez back-office po systemy samoobsługowe czy kooperację z innymi partnerami.

Wspomniana przeze mnie wyżej autonomia to także przestrzeń do dyskusji o pomysłach i problemach. A także możliwość implementacji wypracowanych w ten sposób rozwiązań. W naszym przypadku mamy dwie szerokie domeny: proces i automatyzacja. Dyskutujemy o usprawnieniach, uproszczeniach i optymalizacji. Bardzo często są to ciekawe i bardzo merytoryczne dyskusje dające dużo materiału do rozwoju i przemyśleń.

Innym istotnym elementem jest dla mnie nieustanny proces wymiany wiedzy z zakresu realizowanych zadań. Staramy się także wpływać na procesy i metodyki, a tych w firmie stosujemy szerokie spektrum, więc tester w Play może nabrać doświadczenia w metodykach sekwencyjnych (waterfall) lub iteracyjnych (agile).

Na czym według Ciebie polega praca testera?

Powiedzieć, że tester to jest specjalista od upraszczania złożonych problemów, to jak nic nie powiedzieć. Bardzo dużo zależy od mieszanki kontekstu, w którym pracujemy; środowiska, procesu/produktu, technologii i metod.

Nie wiem, czy wszyscy się zgodzą, ale istota tego zawodu leży w godzeniu perspektywy biznesowej, technicznej oraz szerokiego wachlarza wymogów formalnych (standardy, wymogi prawne, wymogi bezpieczeństwa, regulacje wewnętrzne itd.). Jest to zawód funkcjonujący na pograniczu tych obszarów, a jednocześnie łączący je bardzo mocno przy zachowaniu krytycznego myślenia i empatii dla wszystkich stron. 

Tester, szczególnie w końcowych etapach projektu, kiedy jest silne parcie na sukces, musi umieć myśleć niezależnie. Być odpornym na stres. Często testerów poddaje się dużej presji, żeby pracowali szybciej, ale jednocześnie wiarygodnie. W tej sytuacji poddanie się ciśnieniu prowadzi do patologii – skupieniu się na formalizmach lub odpuszczeniu.

Komunikacja, czyli słuchanie i słyszenie, asertywne prezentowanie swoich racji to są cechy mistrzów w tym zawodzie. Niestety często zdarza się, że opinie i rekomendacje testerów są deprecjonowane lub bagatelizowane. W takich sytuacjach tester musi zachować zimną krew i rzeczowo bronić swoich racji z otwartością na argumenty drugiej strony. Szczególnie w tych pełnych napięciach finiszach projektu.

Z drugiej strony testerzy z całą stanowczością muszą unikać łatek „krytykantów” czy malkontentów. Muszą bardzo ważyć wspomniane opinie i rekomendacje. To są moim zdaniem jedne z największych pułapek i wyzwań w tym zawodzie.

Automatyzacja także niesie trudności. Wszelkie rozwiązania automatyzujące oddzielają i niejako izolują testera od testowanego rozwiązania. Skuteczne testowanie wymaga „wgryzienia” się w testowany system, zrozumienia, jak działa. W biznesie czas na testy ciągle ulega skróceniu. Mając więc do wyboru poznanie testowanego rozwiązania lub automatu, tester naturalnie skupia większą uwagę na tym drugim.

Dlaczego łatwiej będzie testerom po studiach, z pełnym przeszkoleniem, niż osobom, które przebranżowiły się z zupełnie innego sektora, i tylko ukończyły kurs/bootcamp? 

Ludzie z wykształceniem o szeroko rozumianym profilu informatycznym czy telekomunikacyjnym są przygotowywani do zawodu w trakcie studiów. Wiedzą, jak się buduje oprogramowanie, jak działa komunikacja między poszczególnymi elementami. Jaka jest zależność od sprzętu czy maszyn wirtualnych. Rozumieją, co to są struktury danych, interfejsy czy chociażby, że czas to nie tylko sekundy, minuty czy godziny. Wiedzą jak działają bazy danych, systemy operacyjne czy protokoły teleinformatyczne.

Osoby z wykształceniem technicznym nieinformatycznym charakteryzują się rozwiniętą zdolnością dekompozycji problemów i systematyzowania poznanych faktów. Mają wyćwiczone logiczne i krytyczne myślenie w bardzo określony — inżynierski sposób. Ułatwia im to etap wchodzenia w organizację, kiedy trzeba poznać i nauczyć się wielu rozwiązań, które mogą się wydawać dziwne, niezrozumiałe lub wręcz nielogiczne w porównaniu do poprzedniego doświadczenia. Wydaje mi się, że tę umiejętność kształtują i rozwijają nauki ścisłe.

Dla osób z wrodzonymi zdolnościami tego typu, ale bez wykształcenia w omawianym kierunku ogromnym wyzwaniem jest nie tylko zrozumienia języka, podstawowych pojęć i metod. Równie ważne jest pokonanie lęku, który pojawia się w miarę poznawania „potwora”. Wielość procesów, integracji, technik czy narzędzi może zniechęcić nawet najodważniejszego.

Kursy czy bootcampy moim zdaniem są drogą trudniejszą. Wymagają kompletnej zmiany nawyków, zmiany perspektywy użytkownika na perspektywę technika. Nie spotkałem programów szkoleń, gdzie proponowano by zajęcia z kreatywności lub logicznego czy krytycznego myślenia. Często na spotkaniach rekrutacyjnych pytam kandydatów przebranżawiających się: „co to jest API i do czego służy”. Ku mojemu zaskoczeniu bardzo niewielu udziela poprawnych odpowiedzi.

Jestem jednak zdania, że dobrym kompromisem są dedykowane, mocno sprofilowane kursy lub programy reskillingowe. Poprzez to, że są mocno osadzone w kontekście technologicznym firmy, a z drugiej adresowane są do jej pracowników chcących wejść w ten świat, uzyskuje się synergię. 

Czy w Twojej firmie działają tego typu programy?

Tak, stworzyliśmy w Play własny program reskillingowy dla pracowników. Proponujemy w nim ścieżkę biznesowo-analityczną oraz ścieżkę IT. Program powstał w oparciu o nasze potrzeby. Daje możliwość rozwoju umiejętności testowania oraz krytycznego i logicznego myślenia. Oferuje zestaw podstawowej wiedzy na temat naszych narzędzi i systemów, a także podstaw programowania. Weryfikując potencjał i motywację uczestników programu, jesteśmy w stanie zadbać o jak najlepsze dopasowanie oczekiwań do przyszłych zadań. 

Program w dużej mierze oparty jest o pracę własną (zadania domowe), więc niezbędne jest zaangażowanie i chęć pozyskiwania nowej wiedzy. W efekcie uczestnik zdobywa konkretne umiejętności, z których może korzystać w obecnym lub przyszłym miejscu pracy. Poznaje podstawy działania systemów operacyjnych i informatycznych. Nabywa umiejętności obsługi podstawowych narzędzi funkcjonujących w firmie. Dzięki temu pion IT ma szansę uzyskać przeszkolonego pracownika, którego wdrożenie do pracy na nowym stanowisku jest bardziej efektywne.

Jak zachęciłbyś innych do tego, by zostali testerami oprogramowania?

Ciekawy świata inżynier ma szansę pracować w całym spektrum technologii: od chmury, mikroserwisów i API REST-owych po klasyczne rozwiązania trójwarstwowe czy rozwiązania „z pudełka”. Z drugiej strony testujemy przeróżne domeny biznesowe i technologiczne, integracje z siecią telekomunikacyjną, procesy sprzedaży i obsługi, procesy wsparcia pracownika, procesy księgowe i finansowe czy aplikacje mobilne i samoobsługowe, migracje danych lub systemów oraz wiele, wiele innych. Taki krajobraz daje ogromną szansę poznania i znalezienia niszy dla siebie, bez względu na to czy docelowo ktoś ma aspiracje testera (mam nadzieję), developera, administratora, specjalisty od cyberbezpieczeństwa czy systemów chmurowych.

A kiedy już pracownik wybierze niszę testerską, to nawet w obszarach swojej specjalności będzie nieustannie natrafiał na nowe technologie, metody czy chociażby style projektowania i tworzenia rozwiązań. Dla mnie jest to najciekawszy zawód świata i nadal potrafię odnajdować radość zawodową, dumę z osiągniętego sukcesu czy pokorę w obliczu porażki, którą wiem, że ostatecznie przekujemy w sukces.

---

Tomasz Zdanowicz. Kierownik Działu Jakości i Testów IT w Play.

Zdjęcie główne pochodzi z Envato Elements.