Droga do (samo)rozwoju w automatyzacji testów

Automatyzacja jest często wybieranym kierunkiem rozwoju kariery przez osoby zajmujące się zapewnieniem jakości w polskiej branży IT. Prawdopodobnie na pierwszym miejscu jako motywację takiej decyzji możemy postawić wątek ekonomiczny, a zaraz za nim znudzenie swoją dotychczasową pracą i chęć podjęcia nowych wyzwań.

Czy jest to jedyny słuszny kierunek rozwoju, a jeśli tak, to jak zostać inżynierem automatyzacji testów? Jeśli na co dzień zajmujesz się zapewnieniem jakości w projekcie, ale przestaje Ci wystarczać praca, którą wykonujesz i szukasz nowych ścieżek, to ten artykuł może być dla Ciebie.

Różnice między TAE a TDE

Już na wstępie chcielibyśmy zaznaczyć, że artykuł będzie dotyczył właśnie testerów automatyzujących (ang. Test Automation Engineer), a nie developerów testów. Co ważne, nie chcemy absolutnie w ten sposób dyskryminować TDE (ang. Test Development Engineer), którzy również są bardzo potrzebni jako techniczni eksperci z umiejętnościami programowania.

Kim więc, według nas, jest TAE, a kim TDE?

Developer testów, to osoba posiadająca świetne zaplecze narzędziowe i techniczne umiejętności potrzebne do pisania dobrego kodu, jednak ktoś taki nie musi mieć bogatego doświadczenia w samym zapewnieniu jakości.

TAE natomiast, jak sama nazwa wskazuje, przede wszystkim jest testerem, osobą, która w pierwszej kolejności jest skupiona na zapewnieniu i kontroli jakości. Kimś, kto jest w stanie zarówno sprawdzić dany aspekt testowanego systemu ręcznie, napisać do niego dobre przypadki testowe, a potem je zautomatyzować zgodnie z celem i potrzebami projektu. My obaj właśnie taką ścieżkę przeszliśmy – zaczęliśmy od testowania manualnego, by z czasem odkrywać i coraz bardziej angażować się w techniczne aspekty testowania oraz zgłębiać tajniki programowania.

Automatyzacja a inne aspekty zapewnienia jakości

Druga rzecz wymagająca wyjaśnienia to sama automatyzacja. Nie uważamy, żeby była ona Świętym Graalem testowania, który rozwiąże wszystkie problemy z jakością. Jest to precyzyjne narzędzie (a właściwie proces), które służy spełnieniu określonych celów i nie sprawdzi się w każdej organizacji oraz w każdym projekcie. Uważamy, że automatyzacja nie może i nie powinna zastąpić testowania manualnego. Jej celem jest jedynie wspomaganie doświadczonych testerów w zapewnieniu jakości.

Tu dochodzimy więc do pierwszej kwestii. Jeśli chcesz skupić się na testach automatycznych, bo tylko w tym widzisz przyszłość i Twoim zdaniem w QA nie ma innych ścieżek, w które warto inwestować swój czas i wysiłek, to jako automatycy z wieloletnim doświadczeniem niekoniecznie się z tym zgadzamy. W arsenale zapewnienia i kontroli jakości automatyzacja stanowi tylko jedną i wcale nie najważniejszą z technik.

Testowanie eksploracyjne, testy niefunkcjonalne (nie tylko wydajność i bezpieczeństwo), jak również specjalizacje w domenie biznesowej są co najmniej tak samo ważne, więc nie ograniczaj się, szukając pomysłów na swoją karierę tylko do tego jednego obszaru.

Aspekty finansowe i wyzwania na drodze do sukcesu

Kolejną rzeczą, która wymaga poruszenia, jest aspekt finansowy. Czy z ekonomicznego punktu widzenia opłaca się być testerem automatyzującym? Naszym zdaniem, wyjątkowo, odpowiedzią nie będzie „to zależy”. Tak, opłaca się. Ale…

No właśnie, „ale”. Jasną stroną medalu jest na pewno przelew, który co miesiąc wpada na konto i pewnego rodzaju prestiż (na szczęście zmieniło się to na przestrzeni lat, ale kiedy zaczynaliśmy, tester manualny często dostawał łatkę „małpki do klikania”, a nie zaangażowanego w projekt profesjonalisty. W tamtych czasach automatycy byli bardziej doceniani przez programistów jako ludzie, którzy posiedli już pewną wiedzę tajemną).

Z drugiej jednak strony, jest to droga, która wymagała, wymaga i wymagać będzie wiele wysiłku. Technologie zmieniają się bardzo szybko, narzędzia, które dziś są modne i powszechnie używane, jutro odejdą w zapomnienie. Trzeba więc poświęcić czas na początku, żeby wejść do tego świata, ale również, później, dzień po dniu, aby nadążyć za dynamicznymi zmianami.

Zmieniający się krajobraz technologiczny

Dla przykładu: kiedy byliśmy lata temu początkującymi automatykami, choć już się o tym dużo mówiło, na co dzień nikt nie myślał o tym, że sztuczna inteligencja może wejść pod strzechy. Dziś dzieci na porządku dziennym odrabiają lekcje z chatbotami, a testerzy i programiści coraz częściej nie tylko chcą, ale wręcz muszą wspomagać się narzędziami z rodziny AI w codziennej pracy.

Wydaje się, że ta transformacja wciąż trwa i nie wiemy jeszcze, gdzie dokładnie nas zaprowadzi, jednak pokazuje to wyraźnie, jak w ciągu zaledwie kilku lat zmieniła się otaczająca nas rzeczywistość.

Do czego zmierzamy? Ano do tego, że jeśli naprawdę chcesz, to przygotuj się, że zanim comiesięczny przelew zacznie wywoływać uśmiech na Twojej twarzy, trzeba będzie trochę poświęcić – najprawdopodobniej wysiłku w czasie wolnym i za własne pieniądze. Choć to drugie akurat nie jest warunkiem koniecznym. W Internecie jest mnóstwo wartościowej i przystępnie podanej wiedzy, którą community dzieli się za darmo.

Od czego zacząć?

Choć być może od tego powinniśmy ten tekst zacząć, to nie da się jednoznacznie określić ścieżki, jaką powinieneś podążać. Nie znajdziesz tu gotowego przepisu, który poprowadzi Cię krok po kroku, bo naszym zdaniem taki nie istnieje.

Być może automatyzacja będzie naturalnym krokiem w Twoim projekcie i płynnie zaczniesz wchodzi w ten świat. Może jednak będzie to wymagało podjęcia od Ciebie decyzji i aktywności poza codzienną pracą, żeby wreszcie się udało (tak było w naszym przypadku). Wiąże się to z poświęceniem czasu i dołożeniem chęci do tego, żeby poznać narzędzia, z którymi chciałbyś pracować.

Pierwsze kroki w automatyzacji

W kwestii samych narzędzi: czy język ma znaczenie? I tak, i nie.

Obaj zaczynaliśmy od Pythona. Jeden z nas trzyma się go to tej pory (z krótkim romansem z Robotic Process Automation). Drugi zaś przeszedł w tym czasie przez Kotlina, JSa oraz Javę, przy której został na dłużej. Jak widzisz, przeszliśmy różne ścieżki, ucząc się i pracując z językami, które są dedykowane do innych zastosowań, jednak w obu przypadkach jesteśmy w podobnym miejscu.

Co możemy powiedzieć po kilku latach porównując nasze doświadczenia? Z jednej strony, specjalizacje są dobre, a poznawanie zakamarków i tajemnic języka, z którym pracujemy, może się bezpośrednio przełożyć na jakość, czytelność i utrzymywalność kodu, który tworzymy. Poznając jego tajniki, będziemy z czasem potrafili rozwiązywać coraz bardziej skomplikowane problemy w szybszy i bardziej elegancki sposób.

Z drugiej zaś strony, nie ma nic złego w eksperymentowaniu i poszukiwaniu swojego miejsca. Znając kilka języków, również wiele się nauczymy, poznamy różnice pomiędzy nimi, zrozumiemy, do czego sprawdzają się lepiej, a do czego gorzej. Dzięki czemu łatwiej nam będzie dobrać odpowiednie narzędzia do zadania, które przed nami stoi. Będziemy też mieli większy wybór projektów, w których nasze umiejętności się sprawdzą.

Otwartość na nowe

Ważne, abyśmy nie bali się niejako trochę błądzić i odkrywać nowych rzeczy. Skakanie co kilka dni lub tygodni od technologii do technologii, może nie być najlepszym pomysłem. Jednak otwartość na to, co nowe, naszym zdaniem, nie zaszkodzi. Istotne, żeby całe swoje doświadczenie traktować jako jeden zbiór i umieć czerpać z niego, aby rozwiązywać problemy, które przed nami stoją.

Jak wcześniej wspomnieliśmy, wielokrotnie przechodziliśmy przez cykl błędów i ślepych ścieżek, czy to we wspomnianym wcześniej RPA, czy testach wydajnościowych. Poświęcając kilka tygodni lub miesięcy, by nauczyć się narzędzia lub technologii, możemy odnieść wrażenie, że był to czas stracony, szczególnie, gdy później chcemy pójść w innym kierunku. Jednak nie do końca tak jest.

Obaj błądziliśmy, tworząc złe rozwiązania, i uczyliśmy się rzeczy, przy których nie chcieliśmy potem pracować. Jednak ostatecznie one też nas czegoś nauczyły. To są nasze lekcje. Twoje pomyłki, jeśli Cię czegoś nauczyły bądź nauczą, są cenne w Twoim rozwoju. Jeszcze raz, nie bój się popełniać błędów, ale koniecznie wyciągaj z nich lekcje.

Wybór narzędzi i języków programowania

No dobrze, ale co z wyborem języka na początek?

Nie polecimy żadnego konkretnego, bo to bardzo indywidualna sprawa. Zobacz, który z popularnych (tak, popularnych, bo uczenie się Fortrana albo Cobola jako pierwszego języka, może nie być najlepszym pomysłem) dobrze Ci „wchodzi”. Możesz się też zastanowić, czy masz znajomego programistę lub automatyka, który może pomóc Ci z pierwszymi krokami. Wtedy prawdopodobnie język naturalnie przejmiesz od takiej osoby.

Dobrym pomysłem jest też sprawdzenie, jaki język jest używany do pisania automatów lub kodu aplikacji w projekcie, gdzie pracujesz. Bo znowu – otwiera to dostęp do ludzi, którzy mają już na ten temat wiedzę i prawdopodobnie mogą być chętni, żeby się nią podzielić.

A teraz kilka konkretów, które według nas są ważne, jeżeli już uznałeś, że automatyzacja jest dla Ciebie i wybrałeś język, z którym chcesz zacząć.

Znaczenie teorii i praktyki

Po pierwsze, zarówno teoria jak i praktyka są równie istotne. Powinniśmy znać optymalne i polecane metody rozwiązywania problemów, gdyż nie ma sensu wynajdować koła na nowo. Tak samo powinniśmy wiedzieć, jak od strony teoretycznej działają narzędzia, których używamy i dlaczego pewne rzeczy (niemal) zawsze robimy w określony sposób.

Dlaczego? To teraz mały quiz od nas: Zastanów się przez chwilę, czy są jakieś czynności lub zadania, które wykonujesz zawsze w konkretny sposób, bo ktoś Ci pokazał, że tak i już?

Jeśli odpowiedź brzmi „tak”, to być może jest to dobry moment, żeby zastanowić się: „ale właściwie, dlaczego? Czy to na pewno jest najlepsza metoda? A może była jakiś czas temu, ale teraz już nie jest? Czy mogę to zrobić lepiej, albo czy to w ogóle nadal ma sens?”. Oczywiście zdajemy sobie sprawę, że często musimy robić rzeczy, które mogą się wydawać trochę nie na miejscu lub bez sensu, bo ktoś inny podjął taką decyzję.

Jednak tutaj trochę jak w dowcipie:

Czym się różni junior od seniora? Obaj robią źle i niezgodnie z dobrymi praktykami, ale ten drugi przynajmniej rozumie, dlaczego.

Dobrze mieć świadomość, że postępuje się niezgodnie z dobrymi praktykami i wiedzieć, dlaczego wybrało się taką drogę. To jest właśnie moc wiedzy teoretycznej i znajomości dobrych praktyk.

Nic jednak nie zastąpi umiejętności praktycznych, które, jak sama nazwa wskazuje, nabywamy poprzez praktykę (naprawdę dużo, albo i jeszcze więcej), rozwiązywanie problemów, realizację zadań i każdą kolejną linijkę kodu, którą napiszemy i która w końcu zadziała tak, jak powinna.

Naszym zdaniem dopiero „skille” podparte wiedzą o tym, jak i dlaczego, pozwalają nam tworzyć pełne, wydajne i wartościowe rozwiązania, które przynoszą wartość dla biznesu. A przecież tak naprawdę właśnie o to chodzi – żeby nasz użytkownik końcowy dostał produkt spełniający jego oczekiwania.

Wartość języka angielskiego

Po drugie, i tak wiemy, że to będzie banalne – język angielski. Musisz go znać na poziomie komunikatywnym, na tyle, żeby czuć się swobodnie, rozmawiając z innymi osobami. I tutaj mała gwiazdka. Techniczny angielski to nie to samo, co rozmowa o ostatnich wakacjach, a dla TAE jest bardzo ważny. Poświęć chwilkę na to, aby poznać słownictwo techniczne i być w stanie swobodnie je używać.

Wychodzenie ze strefy komfortu

I po kolejne – nie bój się wyjść ze strefy komfortu. Tak, wiemy, że to brzmi jak coaching, więc spróbujemy trochę tę tezę obronić.

Nie ma naszym zdaniem tak naprawdę znaczenia, z czego i w jaki sposób się uczysz. Niezależnie, czy to będą strony internetowe, kursy, szkolenia, konferencje, czy własne projekty, ważne jest to, żeby stawiać przed sobą prawdziwe problemy i uczyć się je rozwiązywać. A kiedy już się uda, robić kolejny krok i kolejny.

Jeśli pracujesz już w projekcie, to pewnie dostarczy Ci rozrywki na kolejne miesiące, a jeśli dopiero się uczysz i nie pracujesz jeszcze z automatyzacją na co dzień, spróbuj napisać testy dla jakiegoś faktycznie istniejącego zagadnienia lub problemu.

Kursy i szkolenia są oczywiście fajne, żeby poznać podstawy i zrozumieć ogólną ideę, ale mają niestety to do siebie, że w większości przypadków podają rozwiązanie lub chociaż wskazówki, na wypadek gdybyś utknął. W rzeczywistym projekcie niestety nie zawsze mamy taki „telefon do przyjaciela”, więc im szybciej zaczniemy kombinować na własną rękę, tym z czasem będzie łatwiej. Dodatkowo, działając samodzielnie, zaczynamy spotykać się z realnymi problemami, a te, gdy je rozwiązujemy, dają nam sporo wiedzy praktycznej na przyszłość.

Jak sobie radzić z błędami poznawczymi?

Pomówmy też teraz chwilę o błędach poznawczych. Zgodnie z efektem Dunninga-Krugera najprawdopodobniej czekać na nas będą dwie pułapki.

• Po pierwsze – po kilku miesiącach w projekcie i pierwszych sukcesach łatwo jest uznać, że cały świat mamy już u stóp oraz że nic nas już nie zaskoczy. To niestety taki moment, w którym musimy mieć świadomość, że IT, obszar zapewnienia jakości, a nawet sama automatyzacja, są zagadnieniami bardzo rozległymi i skomplikowanymi, więc długa droga jeszcze przed nami.

• Płynnie nas to też prowadzi do drugiego błędu poznawczego jakim jest niedocenianie samego siebie, kiedy jakąś wiedzę i umiejętności już posiadamy. Powinniśmy zawsze pamiętać, że nie musimy od razu (czy w ogóle) umieć wszystkiego. Ważne jest to, by cały czas się rozwijać, ale każdy z nas w końcu trafi na projekt, problem lub narzędzie, którego nie będzie się w stanie (w prosty sposób lub w ogóle) nauczyć. To jest zupełnie normalne, więc zawsze pamiętaj: nie musisz umieć wszystkiego, ale powinieneś się uczyć.

Radość, pasja, motywacja

A na koniec, żeby nie było tak pesymistycznie, złota i najważniejsza rada jaką mamy.

Niezależnie od wszystkiego, pilnuj, żeby to co robisz sprawiało Ci frajdę. Jeśli to będzie Twoja motywacja, łatwiej będzie poświęcać własny czas i pieniądze na rozwój, bo będziesz się przy tym dobrze bawił.

Na początku kariery automatyków zdarzało nam się zapomnieć wyjść z pracy (lub położyć się spać), rozwiązując jakieś zagadnienia projektowe lub siedząc nad prywatnymi projektami (nie, pracoholizm nie jest dobry, a work-life balance jest ważny, nie namawiamy tutaj, by na rzecz pracy zaniedbywać inne aspekty życia). Zgodnie uważamy, że niezależnie od technologii, czy ścieżki, zabawa i chęć uczenia się były najważniejszymi aspektami, która przyczyniły się, że od lat zajmujemy się automatyzacją i dobrze nam z tym.

Dzielenie się wiedzą

A co, gdy kilka lat już pracuję, a w projekcie nie mogę robić tego, co sprawia mi frajdę lub dalej się rozwijać, jednak z różnych powodów nie mogę go zmieć (jak choćby kryzysu ekonomiczny, który i do IT w końcu dotarł)?

Możesz się zastanowić, czy jest coś, w czym uważasz, że masz już ugruntowaną wiedzę, którą możesz się podzielić z innymi poza swoim projektem. W myśl zasady, że „jeśli chcesz coś dobrze zrozumieć, zacznij tego uczyć innych”.

Jak to zrobić? Może możesz zostać czyimś mentorem? A może spróbować sił i opowiedzieć o tym, z jakimi problemami się spotkałeś lub jakie rozwiązania udało Ci się stworzyć na jakimś wydarzeniu, meet-up’ie czy konferencji? Możesz się też spróbować zaangażować w pomoc przy tworzeniu takiego eventu.

A jeśli nie masz na to czasu lub ochoty, może po prostu wybrać się i posłuchać innych, wymienić się doświadczeniami przy kawie, poznać moc networkingu? Naszym zdaniem to też rozwija, a wymiana doświadczeń odegrała bardzo dużą rolę na przestrzeni całej naszej kariery. Zachęcamy do tego również Ciebie, gdyż otwartość branży IT i chęć do dzielenia się wiedzą jest według nas czymś, co warto pielęgnować.

 tl;dr

A teraz podsumowanie lub jak zwykło się mówić w branży „tl;dr”:

• ucz się angielskiego,
• nie bój się eksperymentować i szukać „swojej technologii”,
• wychodź ze strefy komfortu, cały czas się rozwijaj i wypatruj nowych wyzwań,
• jeśli chcesz i możesz, dziel się swoją wiedzą z innymi,
• a przede wszystkim zawsze staraj się mieć frajdę z tego, co robisz.

Powodzenia!

***

A jeśli chcesz wiedzieć, co inni nasi eksperci napisali o swoich ścieżkach karier, koniecznie zajrzyj do ich opowieści.