Staram się automatyzować tak nisko, jak tylko się da. Automatyzacja okiem doświadczonego QA Managera

– Mam poczucie (ale może to po prostu pech tego na jakie wątki trafiam w internecie), że jest bardzo dużo głupiej automatyzacji. Dużo roboty, niestabilne testy, mało wnoszonej wartości – powiedział nam Jakub Rosiński, QA Manager at Migo, Speaker, Trainer, QA Daddy & Testing Prophet. Rozmawialiśmy z nim o tym, jak wygląda branża QA z perspektywy Managera z 15-letnim doświadczeniem.

Pracowałeś w ponad dziesięciu firmach – wydaje się, że to sporo. Z jakiegoś konkretnie powodu zmieniałeś pracodawców?

Nie pracowałem w tylu firmach, chociaż faktycznie może się tak wydawać – czasami zmieniłem stanowisko, albo formę zatrudnienia, czasami projekt. Dodatkowo równolegle do normalnej etatowej pracy, zajmuję się szkoleniami i wykładam na uczelni – to też wygląda jak dodatkowe miejsca pracy. Na początku kariery faktycznie częściej zmieniałem pracę, żeby nabrać różnorodnego doświadczenia. Później trochę pracowałem w prawdziwym konsultingu, w którym pojawiały się krótsze projekty.

Te doświadczenia przyniosły Ci konkretną listę elementów, cech, bez których nie dasz się przekonać do pracy w danej firmie? Co znajduje się na takiej liście?

Staram się patrzeć na firmy z kilku perspektyw: nie mogę się nie zgadzać z tym, co robi firma – czyli np. nie chciałbym już pracować w takiej, która rozsyła spam. Szukam ciekawych projektów, technologii, rozwiązań albo sytuacji projektowej będącej wyzwaniem. Zdecydowanie chcę pracować w firmie, która bardziej interesuje się efektem, a nie siedzeniem przy biurku w konkretnych godzinach – więc ta elastyczność jest dla mnie bardzo ważna. Na koniec ludzie, z którymi będę pracował… no i za ile.

Jakie wady, a jakie zalety ma praca w kilku firmach w porównaniu z pracą w tej samej przez wiele lat?

Częsta zmiana pracy uczy zmian kontekstu i daje gigantyczna różnorodność. Różne podejścia projektowe i do samego zapewniania jakości, inna ilość dokumentacji, inaczej położony nacisk. Widziałem więc bardzo różne projekty i mam trochę różnorodnych doświadczeń. Nie wyobrażam sobie pracy przy utrzymaniu jednego projektu przez 5 lat – nawet w ramach jednego pracodawcy – lubię różnorodność projektów.

W jaki sposób podnosisz swoje kompetencje? Co zazwyczaj jest powodem tego, że poprawiasz akurat tę, a nie inną umiejętność?

Teraz głównie czytając w internecie, a potem próbując samemu, ale też czerpiąc z doświadczeń innych – czy to na konferencjach, czy z tego co są skłonni pokazać online. Lubię też warsztaty. I wbrew obiegowej opinii, że współczesne projekty nie mają dokumentacji – bardzo często jest to najlepsze źródło wiedzy. Powody nauki są dwa: albo potrzeba, albo ciekawość i zainteresowanie.

Z jakich narzędzi korzystasz na co dzień?

Głównie z maila, slacka i narzędzia do zarządzania zadaniami. Stety albo nie tak przesuwa się “ciężar” pracy wraz z przejściem bardziej do zarządzania. W kwestii narzędzi do przeprowadzania testów to Postman i IntelliJ.

Jak z Twojej perspektywy zmieniła się branża IT, a szczególnie rynek testerski i QA?

Jest bardzo dużo automatyzacji. Mam poczucie (ale może to po prostu pech tego na jakie wątki trafiam w internecie), że jest bardzo dużo głupiej automatyzacji. Dużo roboty, niestabilne testy, mało wnoszonej wartości. Wszyscy też chcą od razu automatyzować. Z jednej strony to fajnie, ale jak to mówi Dorothy Graham “Automated chaos is just chaos done faster”. Mam też poczucie, że część osób przenosi fragmentarycznie wiedzę z kursów, czy przykładów ze stacka zupełnie bez zrozumienia, co dany kod robi.

Jak zatem warto podejść do automatyzacji? Jak podjąłbyś/podejmujesz decyzję o tym, by zautomatyzować dany proces?

Robić to, co przyniesie wartość i będzie dostosowane do danego projektu i firmy. Jest na rynku dużo automatyzacji frontendu, wiele osób “umie selenium”, w związku z czym właśnie w taki sposób stara się testować wszystko. W systemach, w których 70% testów można opykać na poziomie API, szybszymi i bardziej stabilnymi testami, jest to co najmniej karkołomne podejście.

“Jeśli jedyne narzędzie jakie masz to młotek, to wszystko wygląda jak gwóźdź” jest dziś bardziej opisem sytuacji, a nie przestrogą. Dlatego też staram się automatyzować tak nisko, jak tylko się da i starając się, żeby był to wspólny proces, w którym część testów piszą deweloperzy, a część testerzy.

Oferty pracy z

Porozmawiajmy o błędach. Jakie – z Twojej 15-letniej perspektywy – są najczęściej popełniane błędy przez firmy z branży IT? Myślą o testowaniu na zbyt późnym etapie? Niedoszacowują czasu potrzebnego na testy?

Jeśli chodzi o testy, to pewnie trochę tego będzie: późne włączanie testerów do projektów, wiara w to, że sama automatyzacja wystarczy, żeby wykrywać wszystkie defekty, oczekiwanie, że raz napisanych testów automatycznych nigdy nie trzeba poprawiać. Wydaje mi się, że w przypadku kodu produkcyjnego nie ma takich oczekiwań. Jeszcze przyszło mi do głowy traktowanie “testowania” osobno od unit i integration testów pisanych przez deweloperów – czemu? To może być fajny proces, w którym jedne testy wynikają z poprzednich.

Jak wyobrażasz sobie idealny proces powstawania oprogramowania? Z jakich etapów powinien się składać?

Jedyna odpowiedź jakiej mogę tu udzielić to #toZależy. Tak jak budujemy różne mosty w różnych miejscach, tak samo różnie wytwarzamy oprogramowanie. Zupełnie inaczej będziemy więc testować stabilny i wolno ewoluujący bankowy backend, a inaczej aplikację “rozrywkową”, która często się zmienia. Idealny proces testowy jest dostosowany do szeroko pojętego kontekstu projektu.

QA powinien potrafić programować? Najlepszy QA mają za sobą wieloletnie doświadczenie pracy na stanowiskach związanych z wytwarzaniem oprogramowania?

I tak, i nie. Jestem jednocześnie osobą, która z całą stanowczością mówi, że dobry tester NIE MUSI umieć programować. ale gdyby umiał to prawdopodobnie dałoby to mu jeszcze z +5 punktów expa! Znowu #toZależy – jeśli jest jedynym testerem w zespole zwinnym, dobrze byłoby testować i regresję automatami, i bieżące zmiany… to bez programowania będzie bardzo trudno. Im większa liczba zaangażowanych testerów, tym łatwiej podzielić między nimi obowiązki.

No i na koniec, często bywa tak, że umiejący choć podstawowo programować tester jednak trochę lepiej dogada się z deweloperami.

Co dało największego boosta w Twojej ścieżce kariery?

Zdecydowanie się, że jednak chcę zarządzać projektami i zespołami testowymi. Uwielbiam łączenie pracy organizacyjnej z techniczną i to, że rozumiem o czym mówią zarówno deweloperzy, Site Reliability Engineers i testerzy. Dodatkowo szkolenie innych daje mi gigantyczną ilość funu i motywacji.

Co Twoim zdaniem sprawia, że zawód testera oprogramowania jest przyszłościowy?

A jest? Widziałem gdzieś ostatnio fajnego tweeta, parafrazując: “roboty nie zastąpią programistów, tak długo, jak klienci sami nie będą wiedzieli czego chcą”. W takim razie, skoro tester jest z jednej strony wsparciem programisty, a z drugiej często reprezentantem punktu widzenia klienta w zespole… to też raczej nieprędko przestanie być potrzebny. Natomiast, żeby była jasność, myślę, że ta rola będzie ewoluowała i za 20 lat tester może być osobą z zupełnie innym zestawem umiejętności, niż dzisiaj.

Jakub Rosiński. QA Manager z doświadczeniem technicznym. Testuje od 2007 roku, manualnie i automatyzując testy mobilne, webowe (z frontem i bez) i nawet desktopowe. Duży zwolennik zespołów zwinnych i bliskiej współpracy testerów z innymi rolami projektowymi. Występuje na meetupach, konferencjach, szkoli i wykłada. Ostatnio najbardziej publicznie na swoim kanale youtube TestITka, na którym zaproszeni goście „na żywo” przeprowadzają testy eksploracyjne niespodziewanej aplikacji.