Wielka przygoda w nieznane. Czyli QA mapa do odkrycia świata IT.

Rynek pracy dla ludzi, którzy dopiero zaczynają przygodę z testowaniem, staje się coraz bardziej niedostępny. Mimo to spora część osób nadal obiera tę właśnie drogę, myśląc, że to praca dla nich. Część uważa, że od zawsze lubiła „psuć” oprogramowanie, część chce wejść w świat IT, ale boi się programowania i technicznych aspektów tej pracy. Zdecydowana większość tych osób na podstawie krótkiego researchu postrzega pracę testera jako prostszą od pracy programisty, nie mając przy tym pojęcia, że IT to nie tylko programiści i testerzy, a praca testera (czy obecnie Quality Engineera) to już o wiele wiele więcej niż tylko wykonywanie test case’ów i raportowanie bugów.

Zacząłem myśleć o zawodzie testera. Wydaje się to wycelowane w punkt, w to, co chciałbym robić w przyszłości, ale kompletnie nie wiem, jak się za to zabrać”.
To fragment pierwszego wpisu, jaki znalazlem na grupie facebookowej Tester oprogramowania – wsparcie na starcie. Obserwuje tę społeczność od jakiegoś czasu i w większości pytania i prośby jej członków są bardzo podobne. Podzielmy je na potrzeby mojego rozważania na dwie grupy: na pytania PRZED i PO.
Pytania PRZED: gdy już podjęliśmy decyzję o tym, że to jest zawód dla nas. Uważamy, że mamy odpowiednie cechy, np. cierpliwość, dokładność, komunikatywność, lubimy uczyć się nowych rzeczy, a wyjaśnianie nieoczywistych problemów przychodzi nam łatwo. Stawiamy sobie wtedy pytania o to, jak zacząć, w jaki kurs zainwestować, czy trzeba umieć programować, czy znajomość języka angielskiego jest wymagana.
Pytania PO: gdy jesteśmy już po kursie z podstaw testowania, może nawet stworzyliśmy pierwszy automatyczny test w Selenium i zdaliśmy certyfikat ISTQB. Wysyłamy CV i nikt się nie odzywa. Czyli pierwsze frustracje związane z poszukiwaniem pracy i pytania o to, jak innym się to udało i czy mamy dać sobie spokój, skoro od pół roku nie możemy dostać pracy.

Na większość tych pytania postaram się odpowiedzieć w artykule, natomiast na początku trzeba zadać sobie pierwsze, podstawowe pytanie:

Na czym polega praca testera?

Najkrócej można by powiedzieć, że praca testera to niekończący się proces udoskonalania produktu IT. Gdy zaczynałem 14 lat temu, praca ta była o wiele prostsza, a pułap wejścia w zawód o wiele niższy. Jednak wraz z ciągłym udoskonalaniem produktu tester zaczął ulepszać, przejmować i dodawać kolejne aktywności do swojej pracy. Pamiętam, że na mojej pierwszej rozmowie rekrutacyjnej podstawowa wiedza z testowania oprogramowania okazala się wystarczajaca, żebym dostał prace. Przez podstawową rozumiem zaprojektowanie prostego testu (step + validation) oraz wskazanie, co i jak należy sprawdzić – tutaj podstawowa wiedza o Boundary Values Testing, czyli testowaniu wartości granicznych, okazała się bardzo pomocna. Do rozmowy przygotowywałem się zaledwie kilka dni i naprawdę nie miałem pojęcia, czym tak naprawdę zajmuje się Quality Assurance Engineer. Pomimo słabego angielskiego i tylko podstawowej wiedzy, jakimś cudem dostałem pracę. Najpierw szkolenie, a raczej krótka prezentacja pt. „Czym różni się QA od Testera” a potem krótkie wprowadzenie do HP Quality Center- oprogramowania do zarządzania jakością i procesem testowym. Dowiedziałem się, że QA miał skupiać się nie tylko na tym, czy tworzone oprogramowanie jest zgodne z wymaganiami, ale również zwracać uwagę na to, w jaki sposób oprogramowanie jest wytwarzane. Z pracy QA pozostała raczej tylko nazwa, bo tak naprawdę przez przynajmniej kilka pierwszych miesięcy zajmowałem się głównie tworzeniem instrukcji/przypadków testowych (test case), w których krok po kroku było opisane, co mam zrobić.
Test case’y były okropnie nudne, można je było wykonywać w zasadzie nie wiedząc, do czego służy aplikacja, a każda niezgodność była raportowana jako bug. Quality Center w pewnym sensie było czymś tak istotnym dla projektu, jak obecnie Jira. Pamiętam, że każdy na to narzędzie narzekał, a alternatywą był Excel. Wówczas testy tworzyło się na zasadzie step i validation, czyli tworzono takie minitutoriale, w których każdy krok trzeba było zwalidować (sprawdzić/potwierdzić). Po kilku miesiącach zakres moich obowiązki sie zwiększył – w końcu sam mogłem tworzyć test case’y. To było coś! Z czasem mogłem nawet stworzyć swój pierwszy test plan, czyli dokument, który zawierał wszystkie potrzebne informacje odnośnie oprogramowania oraz wytyczne na temat tego, jak zgłaszać błędy, z kim się kontaktować, gdzie są wymagania, jakie są terminy wykonania testów, ich zakres, itd.
Piszę o tym dlatego, że wiele osób wciąż myśli, że zawód testera czy też QA nadal wygląda właśnie tak. Muszę przyznać, że sam myślałem, iż jest to praca dla każdego, kto umie czytać.Tak było przez pierwszy rok mojej pracy, ale z czasem zacząłem dostawać dodatkowe zadania i obowiązki. Testowanie oprogramowania składa się z wielu różnych aspektów i warto je poznać, zanim zainwestujemy czas i pieniądze. W testowaniu nie chodzi tylko o znajdowanie błędów. Testowanie można rozpocząć już na etapie wymagań. Myślenie o tym, co powinien robić produkt, gdzie może być ryzyko i jak użytkownik/klient nawiguje po produkcie, jest częścią testowania.

Czy zatem warto zacząć od kursu?

Tak i nie – na kursie dla początkujących na pewno można dowiedzieć się czegoś więcej o zawodzie, lecz może się okazać, że te kilka tysięcy wydane na kurs będzie kwotą, którą trzeba zapłacić tylko po to, aby usłyszeć, że zawód testera jest jednak nie dla Was. To prawda, że bez wcześniejszego doświadczenia w IT czy wykształcenia technicznego można zostać testerem, ale można też zostać programistą, analitykiem biznesowym czy Scrum Masterem. Warto dokładniej przyjrzeć się tym wszystkim zawodom, bo mogą się okazać bardziej dopasowane do Was. Na wielu szkoleniach, które kosztują niemałe pieniądze, uczycie się głównie tego, jak zaprojektować przypadek testowy, wykonywać testy, czytać wymagania dotyczące procesu czy określać zakres testów. Ta wiedza jest oczywiście ważna, natomiast trzeba pamiętać, że zawód testera na przestrzeni ostatnich lat przeszedł wielką transformację i wymagania są o wiele, wiele wyższe.

Dobrze jest zacząć od próby zdobycia wiedzy samemu, a dopiero później uzupełniać ją kursem. Mozecie od razu próbować zajrzeć na portale jak Testerzy.pl Guru99.com, ww.ministryoftesting.com itd. Wiedzy, która jest dostępna za darmo, naprawdę nie brakuje. Skoro jednak w przyszłości będziecie musieli starać się o pracę jako juniorzy, sugeruję przejrzeć najpierw oferty pracy na tym poziomie. Bo bez względu na to, czego dowiecie się na kursie, właśnie wymagania na juniora będziecie musieli spełnić i wyróżnić się na tle wielu innych osób, które aplikują na to samo stanowisko. Obecnie, jeśli ktoś, kto pracuje jako tester np. przez rok lub dwa, z perspektywy pracodawcy wciąż będzie juniorem i z takimi osobami będziecie „walczyć” o to samo stanowisko. Na tym etapie naprawdę warto poszukać ofert na całym świecie, nie tylko w Waszym mieście czy kraju. Podejrzewam, że pierwsze, co może wydać się niezrozumiałe, to nazwy stanowisk, które – pomimo tego, że się od siebie różnią – mają te same lub podobne wymagania: Test Analyst, Software Test Engineer, QA Engineer, QA Specialist, QA Tester, Manual Tester, Exploratory Tester, Automation Tester, SDTE.

Jest to bałagan w nazewnictwie związany właśnie z transformacją tego zawodu. I choć pewnie wciąż można znaleźć różne definicje tych stanowisk, to tak naprawdę każda z tych nazw oznacza obecnie tę samą rolę – przynajmniej z perspektywy wymagań pracodawcy. Obecnie, biorąc pod uwagę rynek pracy, testing możemy podzielić wciąż na dwie grupy: testerów manualnych i automatycznych, czyli tych, którzy nie potrafią programować i automatyzować testów, oraz tych, którzy w pewnych aspektach swojej pracy pełnią rolę programistów od testów. Tak czy inaczej: nawet, jeśli zaczniecie pierwsze lata swojej kariery jako testerzy manualni, to żeby się rozwijać w tym zawodzie, prędzej czy później musicie nauczyć się programować. Dodatkowo będziecie musieli zdobyć wiedzę nie tylko z zakresu testowania, ale również metod wytwarzania oprogramowania, a w zależności od specyfiki projektu – wielu technologii. Uważam, że najlepiej podstaw uczyć się samemu i dopiero później ewentualnie uzupełniać wiedzę na kursie tak, aby sobie ją poukładać i zweryfikować. Musicie jednak wiedzieć, że to dopiero początek. Wciąż macie sporo do nauki, aby z powodzeniem ubiegać się o stanowisko testera.

Po opanowaniu podstaw warto zainwestować w wiedzę specjalistyczną – Agile, Jenkins, GIT, Android Studio, Selenium WebDriver, automatyzację i języki programowania. W tym przypadku kurs może okazać się całkiem niezłym rozwiązaniem. Tutaj również przypomnę: ta wiedza dostępna jest za darmo. Najważniejsza jest wasza determinacja i motywacja. Na początku wiele tematów może wydawać się totalnie niezrozumiałych, ale wraz z upływem czasu, który poświęcicie na naukę, wszystko zacznie się rozjaśniać.

Jak wytwarzamy oprogramowanie?

Zanim skupimy się na pracy testera, istotne jest, by zrozumieć, jak pracuje obecnie większość zespołów wytwarzających oprogramowanie. Jak już wspominałem wcześniej, nie tylko tester i programista biorą udział w tym procesie i bardzo istotne jest wiedzieć, z kim i jak należy pracować. Praca przy wytwarzaniu oprogramowania ma określone zasady, praktyki, procesy, ceremonie, artefakty, dzięki którym każdy wie, co i kiedy ma robić i jak możemy sobie pomagać.

Pewnie jeszcze istnieją gdzieś firmy tworzące oprogramowanie w oparciu o model kaskadowy (Waterfall), jednak jest ich już naprawdę mało i prędzej niż później będą musiały przejść na model agile. Wraz z nadejściem ery ogólnodostępnego internetu firmy musiały dostosować model wytwarzania oprogramowania do nowych warunków i większość z nich zaczęła wdrażać agile. W modelu waterfall praca rożnych dyscyplin następowała po sobie: najpierw tworzona była dokumentacja i wymagania, później do pracy zabrali się deweloperzy, a dopiero po nich testerzy sprawdzali dostarczoną wersję programu. W kolejnych krokach zgłaszano błędy, uaktualnioną dokumentację, która – wraz z błędami do poprawki – trafiała do deweloperów, którzy kolejny raz dostarczali poprawioną wersję do testów. Testerzy wówczas zaczynali wykonywać zaplanowane test case’y, potwierdzali (lub raczej sprawdzali), czy błędy zostały poprawione. Mogłoby się wydawać, że na tym koniec – niestety, nic bardziej mylnego. Często okazywało się, że zmieniono dokumentację lub dochodziła jakaś nowa funkcjonalność, która mogła zawierać kolejne błędy, które trzeba było zweryfikować, a kolejne poprawki często psuły coś innego. Dlatego cykl się powtarzał, czasami wielokrotnie. Nie mając innego wyjścia, manualnie sprawdzano wszystko raz za razem. Z czasem zaczęto projektować testy regresji w oparciu o różne metody, żeby w miarę bezpiecznie zawęzić zakres testów. Miało to głównie przyspieszyć prace, bo niejednokrotnie wykonanie stu, pięciuset lub tysiąca testów trwało zbyt długo. Obecnie ilość testów nie ma już takiego znaczenia, jeśli są one dobrze zautomatyzowane.

Zaczęto też analizować ryzyko wystąpienia błędów przy kolejnych iteracjach, a wszystko po to, żeby ułatwić decyzję o zakończeniu testów i wypuszczeniu wersji do klienta. W czasach wcale nie tak odległych, kiedy to oprogramowanie trafiało do nas na płytach CD, a jeszcze wcześniej na dyskietkach, błąd na produkcji był o wiele trudniejszy do naprawy. Wyobraźcie sobie, że macie kilka tysięcy klientów i teraz należy do każdego z nich wysłać CD z poprawką lub kogoś z supportu, żeby naprawił problem już na miejscu. Wraz z nadejściem internetu nowa wersja stała się kwestią szybkiego uaktualnienia, które często wykonuje się w tle aplikacji bez wiedzy użytkownika. Kiedyś na nową wersję czekaliśmy bardzo długo, obecnie w przypadku niektórych aplikacji uaktualnienia mamy nawet codziennie. Nie dostarcza się tak wielkich porcji oprogramowania za jednym razem, a zmianom nie ulega już całe oprogramowanie, tylko pewna jego część. W takich warunkach wielkie zespoły programistów i testerów nie były już potrzebne, natomiast ich pracę należało zorganizować na nowo. Z pomocą przyszły metodyki zwinne (Agile) oraz szczupłe (Lean) i są one obecnie najpopularniejszymi metodami budowania oprogramowania lub zarządzania różnymi projektami. Podejście to jest używane obecnie w wielu dziedzinach, również tych, które z oprogramowaniem związane nie są. Według mnie Agile Tester ma większy wpływ na to, co i jak wytwarzamy. Agile poprawia produktywności zespołu, który jest bardziej świadomy tego, co i dla kogo robi. Procesy i błędy są bardziej widoczne, dzięki czemu prościej jest się uczyć i reagować na zmiany założonego planu. Uważam, że inwestycja w wiedzę z zagadnień typu Agile, Scrum, Kanban czy obsługę narzędzia JIRA może przydać się każdemu, bez względu na to, czy zostanie testerem, czy programistą. Kto wie, może po lepszym zrozumieniu tych tematów zawód Scrum Mastera lub Agile Leada okaże się bardziej interesujący. Zastosowanie Agile pomoże Wam w lepszym zorganizowaniu dalszej nauki. Do poukładania sobie kolejnych celów i podzielenia ich na zadania możecie spróbować wykorzystać JIRA lub Trello, które służą do śledzenia postępów prac, wykrywania błędów oraz zarządzania projektami. Choć te narzędzia nie zostały stworzone do planowania i zarządzania nauką, takie podejście pozwoli Wam wykorzystać w praktyce wiedzę.

Kogo szukają pracodawcy?

Rosnąca liczba powstających aplikacji, ich złożoność i ciągle zwiększająca się liczba danych wymagają coraz więcej pracy testerów. Dlatego też zapotrzebowanie na testerów oprogramowania nie maleje. Jak już wspomniałem, zawód testera przeszedł wielką transformację. Zespoły są mniejsze, testerzy i deweloperzy pracują w małych teamach, ciągle ze sobą współpracując. Oprogramowanie musi działać już nie na jednym komputerze, często dostęp do aplikacji mamy przecież również przez różne przeglądarki czy urządzenia mobilne. W zależności od urządzenia, wersji systemu czy przeglądarki możemy spodziewać się różnych błędów. Zmiany i usprawnienia dostarczane są o wiele szybciej i nie ma już czasu na kilkudniowe wykonywanie testów regresji. Wiele aktywności testera może zostać (lub już zostało) zautomatyzowanych.
W tych warunkach nawet doświadczeni testerzy nie są w stanie wpasować się we wszystkie wymagania. Pandemia przyspieszyła proces transformacji cyfrowej i obecnie automatyzacja zostaje wymuszona nawet w firmach, które rozważały jej wprowadzanie dopiero w przyszłości. Chcą one przy pomocy nowych technologii zwiększyć stabilność i konkurencyjność swoich produktów. Dziś już nawet mało który startup działa ad hoc, dlatego naturalnie rośnie rola testerów oprogramowania. Tych z dużym doświadczeniem jest mało i nie zapowiada się na to, aby to się miało zmienić.

Na pojedynczych uczelniach pojawiają się kierunki związane z testowaniem, jednak większość uczelni ukierunkowana jest na kształcenie przyszłych programistów lub szeroko pojętych informatyków. Z kolei testerzy manualni słusznie zaobserwowali, że jako testerzy automatyczni mogą zarobić więcej, dlatego większość z nich uczy się przynajmniej podstaw programowania i automatyzacji testów, chcąc się przekwalifikować. Niestety, skutkuje to sytuacją, w której eksploracyjnego i manualnego testowania wielu z nich nie chce już robić, ale jednak nie wszystko da się zautomatyzować i takie testy wciąż są potrzebne. Z drugiej strony na rynku mamy sporo początkujących testerów automatyzujących na poziomie junior, brakuje natomiast specjalistów, którzy wiedzą, jak stworzyć automation framework, którzy zajmą się konfiguracją narzędzi, będą w stanie zaproponować zmiany, które przyspieszą release. Architektura frameworku testowego dla oprogramowania webowego wygląda inaczej niż dla aplikacji natywnych – używamy innych narzędzi przy testowaniu backendu aplikacji, a innych przy frontendzie.

Co to oznacza dla Was ?

Na rynku pracy jest jeszcze niewielu testerów, potrafiących dobrze programować. Zdecydowana większość pracowników IT to programiści, Dlatego przeważająca liczba ogłoszeń o pracę dotyczy stanowiska testera automatyzującego. Zapotrzebowanie jest więc duże, a liczba specjalistów bardzo mała. Konkurencję w zdobyciu pracy stanowić będą testerzy, którzy mają już doświadczenie w testowaniu manualnym, ale od strony automatyzacji najczęściej znają podstawy Selenium, Java i WebDriver, czyli technologii najczęściej używanych do testowania frontu aplikacji webowych. Jak już wspominałem: nie wszystko da się zautomatyzować, a od testera coraz częściej oczekuje się pokrycia wszystkich aktywności jakościowych, związanych z wybranych kawałkiem oprogramowania. Junior w automatyzacji najczęściej wspiera innych automatycznych testerów, wypełnia luki w procesie związanym z manualnym eksploracyjnym testowaniem. Dlatego wiedza z teorii testowania i chęć uczestniczenia w testach manualnych może okazać się czymś pożądanym dla pracodawcy, musicie jednak uzupełnić ją o tworzenia testów automatycznych w języku Java przy użyciu Selenium WebDriver. Oczywiście, można wybrać inny język programowania, jednak na rynku Java jest najbardziej popularna. Obecnie dostępnych jest trochę narzędzi, które wspomagają testowanie poprzez nagrywanie akcji użytkownika, a następnie ich odtwarzanie. Nie twierdzę, że są one niepotrzebne, ale na początku sugeruję je pominąć. Jeśli jednak macie już jakieś doświadczenie, niekoniecznie związane z IT, ale np. z bankowością, może to być dużą zaletą dla firmy, która zajmuje się właśnie oprogramowaniem z tego obszaru.

Jak zwiększyć swoje szanse?

Możecie dodać dodatkową pozycję w swoim CV, w której opiszecie swoje zadania zwiazane z nauka testowania.
• Jeśli już udało Wam się zacząć z automatyzacją testów, stwórzcie koniecznie konto na https://github. com i podajcie linka do projektów, które już zrobiliście.
• Dostosujcie swoje CV pod konkretną firmę. Na początku będziecie wysyłać ich bardzo dużo, warto więc je dopasowywać do konkretnych wymagań.
• Codziennie sprawdzajcie oferty pracy na rożnych portalach i aplikujcie.
• Jeśli w jakimś ogłoszeniu znajdziecie pozycję, której nie rozumiecie – zainwestujcie trochę czasu, żeby uzupełnić tę wiedzę.
• Uczcie się używać narzędzi wspierających testowanie, jak: Postman, Screenpresso (lub innych do robienia screenshotów), a także Firebug, Charles Debugger, narzędzi deweloperskich w przeglądarce, Fidler itd.
• Jeśli macie możliwość aplikowania na staż lub praktyki, w firmie w której zatrudnia się też testerów – próbujcie! Czasem prościej jest przejść na stanowisko testera wewnątrz firmy.
• Wykorzystajcie swoje hobby, pasję i doświadczenie branżowe w firmach, które tworzą oprogramowanie – wiedza domenowa może okazać się spora zaletą.
• Jeśli nie czujecie się dobrze z językiem angielskim, koniecznie to zmieńcie. To bardzo przydatny język w świecie IT. Jeszcze lepiej, jeśli znacie jakiś dodatkowy, będzie to dużą zaletą dla firm z innych rynków.

Podsumowując: nie poddawajcie się! Droga do pierwszej pracy testera może okazać się długa i trudna, ale naprawdę warto.
Pracowałem już w wielu firmach z różnych krańców świata przy aplikacjach, które m.in. odzyskiwały dane, wspomagały prawników, wyszukiwały oszustów grających w pokera online czy zarządzały klientami. Zmiana miejsca zamieszkania nigdy nie była problemem, a firmy chętnie wspierają relokację dobrych specjalistów. Ja też zaczynałem jako junior i miesiącami czekałem na swoje pierwsze interview.
Praca testera to ciągły rozwój i nauka, nie ma gotowych przepisów na wiele problemów, z którymi spotykamy się każdego dnia, ale to właśnie dzięki temu ta praca jest ciekawa. Każdy znajdzie tu coś dla siebie: możemy specjalizować się w automatyzacji, security, performance, accessibility, penetration testach i wielu innych. Limitem jest jedynie wasza motywacja i determinacja!