Testy manualne to przeszłość?
Poprosiliśmy developera aplikacji mobilnych o szczerą historię jego kariery, w której przeszedł od testera do developera w jednej korporacji. Pierwszą część wywiadu przeczytasz tutaj.
Czy przy przejściu z testera na developera zmieniałeś szefa?
Karol: Nie, nie. Zostając oficjalnie programistą nie zmieniałem szefa ani zespołu. Wpisało się to raczej w zmianę “kierunku” i specjalizacji naszego całego zespołu. Gdy zaczynałem, byliśmy grupą ok. 25 testerów / inżynierów QA, którzy byli “wypożyczani” do projektów prowadzonych przez inne działy. Ze względu na charakter projektów, które wymagały dużo wiedzy biznesowej na temat działania testowanego przez nas oprogramowania, była to ścieżka, w której po kilku latach z początkującego testera zaznajamiającego się z produktem, zostawało się specjalistą QA, który całościowo odpowiadał za jakość ostatecznie dostarczanego produktu i często posiadał większą wiedzę odnośnie np. wymagań niż programiści.
Teraz podejście w firmie jest raczej takie, że to developerzy sami powinni w jak największym stopniu odpowiadać za jakość i sami testować swój kod. Jak najwięcej prostych testów chcemy automatyzować, minimalizować żmudne klikanie i przenosić odpowiedzialność za jakość na cały zespół. W wyniku tego, w ostatnich latach nie został u nas w dziale zatrudniony żaden tester stricte manualny przy czym wcześniej większość ludzi była zatrudniana właśnie na tym stanowisku. Cały nasz dział zaczął zatrudniać głównie programistów, i przez to z działu zajmującego się QA dla wielu projektów zewnętrznych, stał się działem prowadzącym w całości swoje projekty developerskie, w którym na ok. 30 osób mamy tylko 3-4 QA i kilku specjalistów od testów automatycznych.
Myślisz, że to jest szersze zjawisko?
Karol: Wydaje mi się że tak. Odejście od testów manualnych na rzecz automatycznych to popularny ostatnio kierunek. Ale czy to zawsze jest uzasadnione? To jest szeroki temat i na pewno zależy od charakteru aplikacji i sposobu jej wytwarzania. Wiadomo, że nie wszystko przetestujesz za pomocą testów automatycznych. Gdy teraz tworzymy naszą aplikację mobilną, to czasami żałuję, że nie mamy w projekcie takiego “młodego mnie” jak siebie pamiętam z początku kariery. Kogoś kto przyszedł do roboty tylko po to, żeby znaleźć w danej aplikacji wszystko co nie działa. Jeśli takiej osoby nie ma, to pewne rzeczy po prostu umykają. To jest zupełnie inny mindset – jest ogromna różnica między efektami pracy osoby skoncentrowanej przede wszystkim na znajdowaniu błędów a tej skupionej na dostarczaniu nowych funkcjonalności. W idealnym świecie programista powinien móc wyjść ze swojej roli “autora”, w której zależy mu na tym żeby działało, i wejść dobrze w rolę dociekliwego poszukiwacza tego, co nie działa, ale w rzeczywistości jest to trudne.
Jak blisko współpracowaliście jako testerzy z developerami?
Karol: Chyba nie da rady opisać tego ogólnie. Mieliśmy projekty, w których testerzy pracowali bardzo blisko z developerami, w jednym zespole scrumowym, który razem robi planning – developerzy, QA i osoba odpowiadająca za testy automatyczne będące integralną częścią zespołu.
Ale były też takie, w których testowaliśmy produkt będąc zupełnie oddzieleni od developerów i ich kodu, uruchamiając testy end-to-end na gotowym systemie, bez znajomości szczegółów implementacji, sprawdzając czy efekt końcowy spełnia wymagania klienta. Więc ogólnie to zależy od projektu. Ten drugi rodzaj współpracy występuje często w outsourcingu – gdzie końcowe testy (user acceptance testing) zleca się zupełnie niezależnym jednostkom czy firmom, i tak było też w naszym przypadku.
Jak porównujesz swoje doświadczenia pracy w testach automatycznych i w developmencie? Co sprawia, że aktualna ścieżka jest dla Ciebie satysfakcjonująca?
Karol: Jestem zadowolony ze zmiany, ale na pewno chcę też powiedzieć że ta ścieżka testerska /testów automatycznych może być bardzo ciekawa, wymagająca i satysfakcjonująca. To wszystko zależy od charakteru i skali projektu. Istnieją projekty testerskie do bardzo złożonych systemów, które też są wymagające koncepcyjnie i technicznie. Z tego co się orientuję, testy automatyczne w walidacji w Intelu są przykładem takiego dużego i wymagającego projektu. W przypadku złożonych testów automatycznych to rozróżnienie na testerów i developerów w praktyce się zaciera, czasami ma to nawet odzwierciedlenie w nazwie stanowiska (jak Software Developer in Test). Poza tym, dla ludzi niekoniecznie chcących programować, ścieżka QA jako specjalisty od produktu, takiego rozumiejącego na wylot co się dzieje w całym systemie, może też być bardzo satysfakcjonująca i wiązać się z ciekawą karierą.
W moim przypadku przejście na developera było dobrą decyzją, przede wszystkim ze względu na to, że widzę teraz bardzo bezpośrednio wyniki mojej pracy, to że ma ona wpływ na setki tysięcy osób, i że mogę uruchomić ją na własnym telefonie i mieć ten namacalny efekt.
Tutaj nasuwa się staropolskie słowo “Impact”.
Karol: Tak, za Janem Kochanowskim “Mam większy impact”. Co bywa lepsze lub gorsze w zależności od tego czy w danym momencie impaktowani są zadowoleni z tego jak są zaimpaktowani, czy nie…
Chcesz wiedzieć jak Karol przeszedł od testera do developera aplikacji mobilnych w jednej firmie? Przeczytaj pierwszą część wywiadu tutaj.