O pracy „architekta testów” i konferencji TestDive, rozmowa z Ewą Marchewka

Już 21 października startuje konferencja TestDive organizowana przez firmę Nokia. W tym roku wydarzenie to odbędzie się w całości online, a udział w nim jest zupełnie darmowy. Wystarczy się tylko zarejestrować. Co ciekawego czeka na uczestników? Przede wszystkim masa wiedzy z zakresu testowania oprogramowania, świetni prelegenci i niezapomniana atmosfera.

Warto więc dołączyć, bo będzie się naprawdę dużo działo!

Tegoroczny TestDive rozpocznie się od prezentacji Ewy Marchewki pod tytułem „From tester to manager – all the unexpected things that happen along the way” (Stream A) i Macieja Michnej, który będzie mówił na temat: „Automation of rail vehicle movement based on the example of the first “autonomous” tram in Poland” (Stream B). Przedsmak tego co będzie się działo macie już teraz! Nie przedłużając zapraszam do lektury mojej rozmowy z Ewą Marchewka, architektem testów w Nokii. Poczytacie o pracy managera zarządzającego zespołem ponad 100 osób (!), pracy i ścieżce kariery testera oprogramowania oraz oczywiście uchylimy nieco rąbka tajemnicy o planowanej prezentacji otwierającej konferencje TestDive :)

Łukasz Dudziński, StrefaKodera.pl: Cześć, czy możesz się przedstawić czytelnikom? Na jakim stanowisku obecnie pracujesz, co robisz? 

Ewa Marchewka, Nokia: Cześć, nazywam się Ewa Marchewka. Obecnie jestem Kierownikiem Zespołu Testów Oprogramowania Stacji Bazowych. Kieruję grupą około stu testerów (siedem zespołów) zajmujących się technologią 4G i 5G.

Czyli stanowisko typowo managerskie… jak sobie radzisz z tak dużą grupą „podwładnych”?

Mam doświadczonych kierowników liniowych, którzy robią naprawdę dobrą robotę. Oczywiście pozostaje koordynacja między zespołami i rozwiązywanie problemów na poziomie całej grupy – ale to jest właśnie to co lubię robić.

Jak rozpoczęła się Twoja kariera w branży IT? Skąd takie zainteresowania?

Od dziecka lubiłam matematykę, próbowałam też trochę programować -Turbo Pascal i te sprawy. Po liceum chciałam studiować informatykę na AGH, niestety zabrakło mi kilku punktów na egzaminie wstępnym, w wyniku czego przeniosłam się na Elektronikę i Telekomunikację. Tam zainteresowałam się ogólnie pojętą radiówką, czyli sieciami komórkowymi i radiokomunikacją. A potem dostałam pracę w Motoroli jako tester oprogramowania. W tamtych czasach było to spełnienie moich marzeń – praca z systemami telefonii komórkowej CDMA, GSM i UMTS.

Czyli już przed studiami miałaś plan awaryjny. Dużo osób chcących rozwijać karierę w branży IT po nieudanej rekrutacji rezygnuje….

Moim zdaniem to jest błąd. Nie należy porzucać tego co się lubi robić tylko dlatego, że nie udało się za pierwszym razem. 

Co radzisz młodym osobom, absolwentom studiów informatycznych lub chcących rozpocząć swoją karierę programistyczną, testerską? 

Nie bójcie się pytać! Nikt się nie spodziewa, że będziecie wiedzieć wszystko po rozpoczęciu pracy (chociaż oczekujemy, że coś będziecie umieć). Z mojego punktu widzenia najwięcej uczymy się podczas tzw. „on the job training”, czyli sytuacji, w której patrzymy na to, co robi bardziej doświadczony kolega.

No właśnie, wspomniałaś, że coś trzeba wiedzieć. Czy da się określić mniej więcej jakiś poziom, od którego można starać się aplikować na staż lub pierwszą pracę? 

Dobrze jest mieć podstawy – trochę Perla/Pythona, do pisania testów automatycznych, podstawy sieci i bazową wiedzę o telefonii komórkowej. Chętnie przyjmujemy praktykantów podczas okresu wakacyjnego. Praktykanci – jeśli tego chcą – zazwyczaj zostają z nami jako tzw. Pracujący Studenci czyli Working Students. Zawsze można też skorzystać z Nokia Academy – bezpłatnego cyklu szkoleń prowadzonych przez specjalistów z naszej firmy. Kolejna edycja jest właśnie w trakcie, ale jestem pewna, że w przyszłym roku będą następne (nokiakrakow.pl/ruszaja-zapisy-na-nokia-academy).

Czy możesz polecić jakieś biblioteki i inne rozwiązania, których warto się uczyć, aby zostać testerem? Co się sprawdza w takiej pracy przy projektach komercyjnych?

Tak jak wspomniałam dobrze jest znać podstawy języków programowania, najlepiej Perl/Python, ale nie dyskryminujemy C i C++. Dodatkowym atutem będzie znajomość Robot Framework. Dobrze jest się orientować w modelu ISO/OSI, znać podstawy modulacji, metody wielodostępu do łącza radiowego, podstawy Unixa. Jeśli kandydat orientuje się w metodologiach testowania, to już duży plus. Zazwyczaj osoby rekrutowane mają całkiem dobrą wiedzę techniczną, natomiast rzadko się zdarza student z wiedzą stricte testerską.

Co sądzisz o różnych certyfikatach na przykład certyfikacie ISTQB FL? Warto inwestować w jego zdobycie czy może raczej uczyć się bardziej praktycznych rzeczy? 

Dla mnie osobiście certyfikaty ISTQB są dowodem, że osoba je posiadająca zna teorię testowania. Moim zdaniem przejście przez kurs bardzo porządkuje wiedzę i daje świadomość uniwersalnych mechanizmów rządzących testowaniem. Chodzi mi o podstawowe „złote zasady”, np. „nigdy nie znajdziesz wszystkich błędów”, czy „im później w cyklu testowania znaleziony został błąd tym jego naprawienie jest droższe”. Jeśli myślimy o rozwoju w stronę Test Managera lub Architekta Testów, jak najbardziej polecam.

A są jakieś inne certyfikaty lub szkolenia, które polecasz? 

Mam certyfikat SAFe4 Agilist, ale dużo bardziej przydatne w mojej obecnej roli były szkolenia z umiejętności miękkich – bycia Liderem, Mentorem albo „Business presenting and public speaking” czy „Train the Trainers”.

Na czym polega praca architekta testów? 

Architekt testów zajmuje się tworzeniem strategii testów umożliwiających dostarczenie produktu klientowi. Musi wychwycić potencjalne interakcje pomiędzy poszczególnymi funkcjonalnościami (dop. red. feature interaction), zaplanować jaki rodzaj sprzętu i w jakiej ilości będzie potrzebny, zadbać o licencje do oprogramowania, telefony testowe. Zajmuje się też szacowaniem czasu potrzebnego na przetestowanie danej funkcjonalności i optymalizacją listy testów potrzebnych do prawidłowego przetestowania produktów. W razie potrzeby pomaga w bardziej skomplikowanych scenariuszach testowych i inwestygacjach problemów.

Jak to wygląda z tym sprzętem do testowania? Ja akurat zawodowo zajmuję się programowaniem aplikacji mobilnych z pracą testerką mam niewiele do czynienia, ale na zdrowy rozum, to nie da się przetestować aplikacji na każdym telefonie.

Sprzęt, który miałam na myśli to hardware produkowany przez Nokię – do prawidłowego przetestowania produktu potrzeba różnych linii testowych – stacji bazowych, skonfigurowanych w taki sposób w jaki używa ich klient. Staramy się też sprawdzić czy dostępne na rynku telefony działają z naszym sprzętem.

Jak testuje się rozwiązania telekomunikacyjne?

Tak jak każde inne. Oprogramowanie przechodzi cały cykl od Unit Testów, przez Integration Testy do System Testów i Acceptance Testów. Jedynym utrudnieniem jest fakt, że trzeba testować na docelowym sprzęcie, często z wykorzystaniem tak zwanych „third party HW”, czyli urządzeń innych firm np. telefonów. Duży nacisk trzeba też położyć na testy wydajnościowe i testy w środowisku klienckim – konieczne jest wtedy skonfigurowanie produktu w dokładnie taki sam sposób jak będzie używany. W moim zespole zajmujemy się głównie testami Integracyjnymi i Systemowymi

Czy możesz coś więcej powiedzieć o tym cyklu testowania?

Przez „cykl testowania” rozumiem przejście przez wszystkie fazy od unit testów, robionych głównie przez R&D, zazwyczaj white-box, przez testy integracyjne, na prawdziwym sprzęcie, ale z użyciem symulatorów zastępujących części sieci lub telefon, aż do testów systemowych i E2E testów przeprowadzanych w środowisku klienta, które są w 100% black-box testami.

Która z tych faz jest najważniejsza z punktu widzenia testera, a która najtrudniejsza do przetestowania?

Wszystkie fazy są bardzo ważne i każda faza ma swoje wyzwania. Dla mnie osobiście najbardziej wymagającą fazą jest integracja, kiedy trzeba poskładać wszystko razem. Największym wyzwaniem jest testowanie, kiedy wszystko jest nowe – sprzęt, oprogramowanie i telefon – wtedy w przypadku błędu czasem ciężko stwierdzić co tak naprawdę nie działa.

I jak sobie z tym radzisz? 

Metodą prób i błędów. Sprawdzamy logi, wymieniamy sprzęt, wymieniamy telefon i tak aż zadziała. Oczywiście nie robimy tego w ciemno tylko we współpracy z doświadczonymi deweloperami i architektami.

Jaki był najciekawszy błąd jaki miałaś okazję znaleźć podczas swojej kariery zawodowej? 

Niebezpieczny SMS. Podczas testów eksploracyjnych próbowałam wysyłać różne rodzaje wiadomości – długie, ze znakami specjalnymi itp. Jednym z nich udało mi się zresetować centralę telefoniczną – oczywiście testową, nie u klienta! Było to bardzo dawno temu, jeszcze zanim LTE i 5G weszły do użytku.

Dużo się słyszy o takich właśnie SMSach, które resetują iPhone i inne telefony. To był przypadek, że trafiłaś na taką kombinację czy zamierzone działanie? Macie jakieś scenariusze wedle których przeprowadza się takie testy?

Jak wspomniałam to był tak zwany „Exploratory test”, czyli w dużym uproszczeniu zabawa na linii testowej obliczona na jej zepsucie. Test, który znalazł błąd staramy się zawsze udokumentować i stworzyć procedurę, którą dodajemy do testów regresyjnych wykonywanych potem na następnych wersjach kodu. 

Nowe scenariusze testowe planujemy na podstawie wymagań dostarczonych przez architektów i use-case’ów klienckich.

Obecnie nie zajmujesz się już stricte inżynierią oprogramowania, testowaniem – ciężko było „porzucić” testowanie na rzecz stanowisk managerskich? Dla dużej ilości osób to „ciężkie” przeżycie…

W moim przypadku przejście było dosyć łagodne. Na początku zajmowałam trochę zarządzaniem projektem, potem planowaniem produktu, a potem już poszło. Okazało się, że jestem dobra w planowaniu i zarządzaniu i że sprawia mi to dużo satysfakcji. Niestety teraz dosyć często brakuje mi możliwości dogłębnego zaangażowania się w techniczne aspekty projektu. Z braku czasu moja wiedza jest dosyć powierzchowna w niektórych zakresach. Dlatego wszystkim, którzy myślą nad wyborem ścieżki kariery polecam solidnie się zastanowić, co tak naprawdę lubią robić.

A jakie są plusy takiej pracy bardziej managerskiej? 

Dla mnie – możliwość zobaczenia tak zwanego „big picture” i zrozumienia procesów rządzących dużą firmą. Bardzo lubię też planowanie i rozwiązywanie problemów pojawiających się w trakcie pracy nad produktem, wymaga to dosyć dużych umiejętności analitycznych i nieszablonowego myślenia. 

Na czym polega rola „planera produktu”?

Planowanie produktu to trochę kalka z języka angielskiego – Product Planning. W tej roli byłam odpowiedzialna za zaplanowanie jakie funkcjonalności będzie można dodać do produktu przed kolejnym wdrożeniem u klienta. Pod uwagę musiałam wziąć moce przerobowe zespołów, dostępny sprzęt i priorytety poszczególnych funkcjonalności. Najtrudniejsze w tej roli było radzenie sobie z ciągłymi zmianami – raz stworzony plan musiał być dosyć często modyfikowany w wyniku np. nowych informacji od klienta.

Ze ścieżki edukacyjno-testerskiej przejdźmy do tematu telekomunikacji. Czy 5G faktycznie jest tak niebezpieczne jak można poczytać w mediach mainstreamu?

Bezpieczeństwo pracowników i produktów znajduje się na samej górze listy priorytetów Nokii. Dopuszczalne wartości promieniowania elektromagnetycznego zostały zdefiniowane przez WHO (World Health Organization), a opracowane normy są ściśle przestrzegane.

Zgodnie z opinią autorytetów naukowych nie istnieją dowody, że używanie telefonów komórkowych lub praca/przebywanie w pobliżu stacji bazowych działających w ramach limitów określonych prawem, może stanowić zagrożenie dla zdrowia.

To jeszcze na koniec, gdzie widzisz siebie za 5 lat?

Zajmującą pozycję CEO Nokii oczywiście. A na poważnie, chciałabym spróbować swoich sił w zarządzaniu większym zespołem. Podoba mi się to, co robię, mam możliwość rozwoju i uczenia się nowych rzeczy, ale wiadomo, że apetyt rośnie w miarę jedzenia. Problemem jest Work-Life Balance, ale pracuję nad tym i nie jest najgorzej. Więc za 5-10 lat, kto wie?

Jeszcze większym zespołem? To jaki jest największy team w Nokii? 

Największy team w Nokii to cała Nokia. Doprecyzowując – chciałabym zarządzać grupą takich 100-150-osobowych zespołów, czyli np. wszystkimi testerami danego produktu.

Już za nieco ponad miesiąc będziesz miała okazję wygłosić swoją prezentację na konferencji TestDive. Czy możesz zdradzić jakiś ciekawy wątek, który poruszysz? 

Będę mówić między innymi o obieraniu cebuli i gotowaniu oceanu. Kiedy zaczyna się pracę w firmie IT, jedną z rzeczy utrudniających nam życie jest żargon korporacyjny. Jesteśmy atakowani przez masę słów, zwrotów i zdań, które na pierwszy rzut oka nie mają sensu. Przykładowo, kiedy zaczynałam pracę w Motoroli 15 lat temu, jednym z pierwszych spotkań, na które zostałam zaproszona było tzw. Postmortem. Dosłownie znaczy to „sekcja zwłok” albo „po śmierci”. Na spotkaniu okazało się, że omawiamy dobre i złe decyzje, jakie były podejmowane podczas poprzedniego projektu. Notowaliśmy też „lessons learned” czyli rzeczy, które można poprawić następnym razem. Kiedy indziej kolega przekonywał mnie – „let’s not boil the ocean on this one” (nie gotujmy oceanu). W wolnym tłumaczeniu oznacza to– nie próbujmy spędzić więcej czasu i zasobów nad tym projektem niż ma to sens.

Co robić, jeśli trafimy w sam środek korporacji, w której wszyscy posługują się żargonem? Koledzy i koleżanki z firmy w pewnym momencie przestają zauważać, że stosowane przez nich powiedzonka są „korpomową”. Nie zdają sobie sprawy, że wyrażają się niezrozumiale dla nowoprzybyłych. Nie ma więc nic złego w prośbie o wytłumaczenie konkretnego zwrotu. Ani się obejrzymy, a sami zaczniemy w ten sposób mówić i czasem ciężko nam będzie przekazywać informacje bez używania niektórych słów-kluczy.

A o co chodzi z obieraniem cebuli? Jeśli jesteście zainteresowani, zapraszam na moją prezentację 21 października na Test Dive. Będę podczas niej mówić także o wielu innych rzeczach, np. czemu time-to-market jest ważny dla testera i co to jest business acumen.

Brzmi ciekawie, a jak długo trwa przygotowanie takiego wystąpienia? 

Kilka miesięcy. Nie znaczy to oczywiście, że pracuję nad wystąpieniem non-stop. Najpierw przychodzi pomysł, potem potrzebuję trochę czasu na poukładanie moich wiadomości dotyczących danego tematu i czytanie artykułów/opracowań/książek, żeby pogłębić wiedzę teoretyczną. Sam koniec, to porządkowanie wiadomości i tworzenie prezentacji. W swoim portfolio mam prezentacje techniczne (np. o Testach Korytarzowych), soft-skillowo-techniczne (Inteligencja Kolektywna w zespołach Testerskich i Scrumowych) oraz typowo soft-skillowe (Syndrom Oszusta).

Co jest w tym najtrudniejsze?

Przygotowanie prezentacji tak, aby mieściła się w zadanym czasie i zawierała te informacje, o których chcę powiedzieć słuchaczom. Zwięzłe i konkretne przekazanie clou tematu wymaga całkiem sporo pracy.

Czy chciałabyś coś dodać od siebie? 

Przyjdźcie na TestDive! To już czwarta edycja, a poziom coraz wyższy.

Dzięki za rozmowę.

Ja również dziękuję.

Swoją drogą mogę jeszcze dodać, że tegoroczna edycja konferencji TestDive tak samo jak zeszłoroczna, została objęta patronatem medialnym przez bloga StrefaKodera.pl.

5G, Acceptance Test, Agile, Architekt testów, Cykl testowania, feature interaction, Integration Testy, ISTQB, Korpomowa, Nokia, Patronat medialny, Programowanie, Robot Framework, SAFe4 Agilist, telekomunikacja, Test manager, TestDive, Testowanie, Testy systemowe, Unit Testy, Zarządzanie, Zarządzanie zespołem