Bartosz Więcek na początku swojej drogi w IT pasjonował się testowaniem oprogramowania. Trafił do zespołu, w którym mógł także pracować przy tworzeniu kodu, a nie tylko przy jego testowaniu. W ten sposób zainteresował się pracą developera i zrozumiał, iż chce zostać programistą.
Jak przeprowadził i z sukcesem zrealizował proces przebranżowienia od testera do developera? Tego dowiecie się z poniższej rozmowy.
Dlaczego zostałeś testerem?
Moja przygoda z testowaniem zaczęła się zaraz po studiach, gdzie pracowałem jako tester dla firmy ubezpieczeniowej. Była to świetna okazja, aby wejść do świata IT i rozwinąć pasję, jaką stało się wytwarzanie oprogramowania.
Testerowi łatwiej wejść do IT? Jakie wówczas posiadałeś umiejętności, doświadczenie?
Studiowałem informatykę, więc na tamtym etapie miałem wyłącznie czysto akademicką wiedzę. Poszukiwano osób, które mają wykształcenie, chcą się uczyć i potrafią komunikować się w języku angielskim.
Jeśli chodzi o zakres wiedzy i umiejętności, to moim zdaniem od testera na starcie wymaga się mniej. Niższy próg wejścia oznacza również większą liczbę chętnych na dane stanowisko. Trudno zatem jednoznacznie wskazać, czy jest to łatwiejsza ścieżka, aby wejść do świata IT.
Na rynku wciąż istnieje zapotrzebowanie, aby testować interfejs użytkownika, ponieważ nie wszystko da się zautomatyzować, a także przez lata przybyło nam urządzeń, na których konsumujemy treści. Finalnie chcemy uzyskać responsywny system pozbawiony błędów, ale także intuicyjny, bezpieczny, dostępny na różnych urządzeniach i często dostosowany do potrzeb osób niepełnosprawnych. Dobry tester jest w stanie zadbać o te wszystkie aspekty podczas weryfikacji działania systemu.
Pracowałem pewnego razu w zespole, gdzie wraz z innym testerem działaliśmy w tandemie – on weryfikował system od strony frontendu, a ja skupiałem się na backendzie i tworzeniu narzędzi do automatyzacji. Działało to znakomicie, bo łączyliśmy podejście białoskrzynkowe i czarnoskrzynkowe.
A jeżeli w zespole developerskim jest jeden tester, to jest to Twoim zdaniem dobre rozwiązanie?
Z mojego doświadczenia wynika, iż jeden tester w niewielkim zespole developerskim (do 5 osób) wystarcza. Jest czas zarówno na bieżące testowanie funkcjonalności, a także budowanie narzędzi, które automatyzują pracę. W przypadku większych zespołów dobrym rozwiązaniem jest dodanie kolejnego testera, aby osoby mogły się wspierać, wzajemnie przeglądać kod czy skupić się na różnych dziedzinach testowania.
Warto pamiętać, iż za jakość systemu odpowiada cały zespół developerski, a tester zwyczajnie kładzie na to największy nacisk. Oznacza to w praktyce, iż każdy może i powinien od czasu do czasu testować, by poczuć się jak użytkownik i nabrać innej perspektywy. Wymaga to nieco odwagi, bo może się okazać, iż drobna zmiana układu na naszej stronie będzie dla użytkownika istotniejsza niż refaktoring kodu, nad którym pracowaliśmy przez ostatni tydzień.
Co w tej pracy sprawiało Ci największą satysfakcję?
Ogromną satysfakcję sprawiało mi poznawanie systemu od zera podczas testów czarnoskrzynkowych oraz testów eksploracyjnych. Dostałem system, znałem jedynie założenia i starałem się go popsuć. Im dziwniejszy błąd, tym większa satysfakcja.
Ponadto brak perspektywy i przywiązania do systemu pozwalał mi na kwestionowanie nie tylko tego, jak działa system, ale także, dlaczego działa w określony sposób. Później zrozumiałem, iż jest to znane rozróżnienie w branży na walidację i weryfikację.
Zainteresował mnie ten brak przywiązania do systemu. Rozumiem, iż łatwiej testuje się produkt, z którym nie ma się emocjonalnego związku?
Zdecydowanie! Będąc programistą, zastanawiam się jak stworzyć program, następnie go piszę, testuję, dopieszczam i mam nadzieję, iż będzie działał zgodnie z założeniami. Tym samym przywiązuję się do tego fragmentu systemu i mogę łatwo stracić perspektywę działania całego programu.
Z punktu widzenia testera, nowo powstałą funkcjonalność traktuję jako wyzwanie. Znam dobrze istniejący system i teraz muszę zadbać, aby ten nowy kod dobrze wpisał się w całość. Naturalnie podchodzę do niego nieufnie, oglądam ze wszystkich stron i stawiam sobie za cel, aby go popsuć!
Programista myśli, jak coś stworzyć, a tester jak coś popsuć, a jednak obu chodzi o to samo – aby dostarczyć dobrą funkcjonalność produkcję.
Kiedy zacząłeś odczuwać, iż praca testera to nie do końca praca dla Ciebie?
Stosunkowo gwałtownie zrozumiałem, iż chciałbym robić coś więcej niż tylko testować interfejs użytkownika. System poznałem w ciągu pierwszych kilku tygodni, a kolejne funkcjonalności, które się pojawiały, pociągały za sobą konieczność wykonywania również testów regresji. euforia z odkrywania systemu i znajdowania błędów przerodziła się w wyklikiwanie tych samych scenariuszy testowych. Praca stała się monotonna.
Zatrzymajmy się na tym momencie, w którym zrozumiałeś, iż praca stała się monotonna. Jakie kroki podjąłeś, by znaleźć rozwiązanie tych problemów?
Czytałem, w jaki sposób mogę się rozwinąć jako tester oprogramowania. Wtedy zrozumiałem, iż pracowałem do tej pory jako tzw. “klikacz” i jest to dopiero początek drogi, aby zostać Inżynierem Testów. Zacząłem więc czytać na temat szeroko rozumianego zapewnienia jakości, gdzie tester jest częścią zespołu developerskiego. Zadaniem testera jest stałe podnoszenie jakości systemu na wszystkich fazach tworzenia oprogramowania.
Podszkoliłem się wówczas z testów API, automatyzacji oraz testów wydajności i niedługo trafiłem do zespołu developerskiego, gdzie byłem jedynym testerem. Wiązało się to z dużą odpowiedzialnością i dużym wyzwaniem. Odtąd mogłem stosować dowolne techniki, które finalnie sprawiały, iż dostarczaliśmy produkt lepszej jakości.
Jak zostałeś zatem developerem?
Będąc już inżynierem testów, dużo pracowałem z kodem, tworzyłem narzędzia do automatyzacji, brałem udział w “code review”, a także czasami pisałem funkcjonalności. Wyznawaliśmy w zespole zasadę, iż wszyscy jesteśmy inżynierami systemu i powinniśmy od czasu do czasu wejść w czyjeś buty, aby nabrać innej perspektywy. Tym sposobem koledzy mieli okazję spróbować testowania, a ja wejścia w buty developera. To uświadomiło mi, iż znacznie więcej satysfakcji dostarcza mi tworzenie funkcjonalności niż ich testowanie. Gdy zobaczyłem swoją pierwszą funkcjonalność na produkcji, zakiełkowała mi w głowie myśl: a może by tak się przekwalifikować?
Od myśli do realizacji minęły dwa lata. W tym czasie podnosiłem swoje umiejętności z Javy i wykorzystywanych frameworków. Jednocześnie stałem się starszym inżynierem jakości. Podczas rozmów rekrutacyjnych niestety wielokrotnie byłem odrzucany, ponieważ firmy interesowało, ile konkretnie mam doświadczenia jako developer, a nie ogólnie staż w wytwarzaniu oprogramowania. Pojawiło się zatem wyzwanie – jak się przekwalifikować, aby znowu nie zaczynać od pozycji juniora.
W końcu natrafiłem na firmę, z którą zawarłem niepisaną umowę na etapie rekrutacji. Polegała ona na tym, iż swoim doświadczeniem zadbam i poprawię proces jakości w firmie. W zamian otrzymam możliwość nauki i pracy jako developer. Tym sposobem przekwalifikowałem się na developera i do tej pory kontynuuję swoją przygodę jako programista.
Postanowiłeś więc na własną rękę podnosić kompetencje programisty. Jak od środka wygląda taka nauka?
Pracując w IT, ta nauka w zasadzie nigdy się nie kończy. Na początek zacząłem od kursów wideo na popularnej platformie. Jednocześnie tworzyłem małe projekty na własny użytek. Przeczytałem polecane przez innych programistów książki dot. czystości kodu, mikroserwisów i architektury. Na koniec wróciłem do podstaw, czyli informatyki teoretycznej i algorytmów.
Jednocześnie w firmie brałem aktywny udział w code review, a także w miarę możliwości podejmowałem zadania developerskie.
Gdy poczułem się nieco pewniej, zacząłem uczestniczyć w rozmowach rekrutacyjnych. Niekoniecznie zależało mi na tym, aby dostać się do danej firmy, ale aby zrozumieć, gdzie jestem i wyłapać braki kompetencyjne. Na początku wypadałem słabo i było to mało przyjemne doświadczenie dla ego, ale niezwykle pouczające i podnoszące motywację do dalszej nauki.
Możliwość przebranżowienia, ale od stanowiska juniora, to problem, z którym boryka się wiele osób. Opowiedz o swojej perspektywie. Gdybyś nie znalazł takiej pracy, byłbyś gotów wrócić do stanowiska juniora?
Powrót do stanowiska juniora zostawiałem jako ostateczność, chcąc wypróbować inne sposoby.
Jednym z nich jest rozmowa w obecnej firmie z przełożonym i przedstawienie gotowości do przebranżowienia na developera. Warto wspólnie opracować plan, jak taka tranzycja miałaby wyglądać, godząc potrzeby rozwoju pracownika z potrzebami firmy. Ta droga wydaje mi się naturalna i najczęściej spotykana w branży. (Pracowałem kiedyś w firmie, która ciągle poszukiwała testerów, bo gwałtownie okazywało się, iż każdy z dotychczasowych zdążył się już przekwalifikować).
Innym sposobem jest dogadanie się bezpośrednio w zespole i zasygnalizowanie członkom, iż chcesz się rozwijać w kierunku programowania. Będąc testerem możesz przeglądać kod pozostałych, podejmować zadania developerskie, uczestniczyć w rozmowach na temat architektury czy tworzyć narzędzia do automatyzacji testów. Po jakimś czasie może się okazać, iż granica pomiędzy testerem a developerem zostanie zatarta i zostaniesz “inżynierem oprogramowania”. Stąd droga do zmiany stanowiska wydaje się znacznie prostsza.
Ostatnią drogą jest poszukiwanie firm, które docenią kompetencje testera, a jednocześnie zaoferują stanowisko programisty. jeżeli potrafisz automatyzować testy, to przykładem mogą być firmy oferujące testowanie w chmurze (testing as a service) bądź tworzące narzędzia sczytujące strony internetowe.
Metod jest wiele i wierzę, iż jeżeli ktoś jest zdecydowany, to znajdzie odpowiedni sposób, aby się przekwalifikować.
Bartosz Więcek. Programista z zawodu, QA z pochodzenia. W swojej pracy duży nacisk kładzie na jakość i zorientowanie na końcowego użytkownika. Przez 9 lat w IT swoje doświadczenie zdobywał m.in. w Allegro, Cognizant i EY.
