Czym zajmuje się tester oprogramowania?

Należałoby raczej zapytać czym nie. Jest to oczywiście uzależnione od wielu czynników, takich jak branża czy projekt do którego trafimy. Niemniej jednak spektrum zadań dla testera w zespole może być naprawdę szerokie. Do głównych zaliczymy oczywiście przeprowadzanie testów i zgłaszanie wykrytych błędów. Nie jest to jednak ani początek, ani nawet koniec naszej pracy jako tester oprogramowania. Wcześniej trzeba przeanalizować dokumentację i wymagania. Zaplanować nasze testy. Następnie przejść do projektowania poszczególnych przypadków testowych.

Jeśli mówimy o testach automatycznych, to również zaimplementować wspomniane przypadki. Musimy także przygotować środowisko testowe. Gdy już wszystko będzie zaprojektowane i skonfigurowane, przechodzimy wreszcie do wykonania testów, z czego później sporządzamy raport. Jeżeli wykryliśmy jakieś błędy, musimy je zgłosić. Zgłoszenia takie natomiast powinniśmy nadzorować, by doprowadzić do ich rozwiązania w określonym czasie. Gdy pojawi się poprawka dla któregoś z błędów, konieczne jest jej sprawdzenie i zaraportowanie wyników.

Trochę się tego zebrało, ale oczywiście nie wszędzie będziemy mieli do czynienia ze wszystkimi powyższymi zadaniami.

Czym różni się testowanie manualne od automatycznego?

Wbrew pozorom sam proces wygląda w obu przypadkach podobnie, zwłaszcza na początku i na końcu. Najpierw musimy przeanalizować określone dokumenty, na przykład wymagania funkcjonalne. Następnie na ich podstawie projektujemy przypadki testowe. Tuż po tym momencie pojawia się pierwsza rozbieżność. Zakładając, że środowisko testowe mamy skonfigurowane, manualny tester oprogramowania jest już gotowy, by zacząć wykonywać swoje testy. Tester automatyzujący musi je najpierw zaimplementować. Jeśli natomiast chodzi o owe wykonywanie, tester manualny rozsiada się wygodnie przed oprogramowaniem i… tak sobie siedzi i klika. W tym czasie tester automatyzujący uruchamia swój zestaw testów, upewnia się, że wystartował prawidłowo i przeważnie nie musi go dalej nadzorować, więc może zająć się innymi zadaniami. Znalezione błędy wszyscy testerzy muszą zgłosić ręcznie, ale raport z wykonania przygotowuje w ten sposób już raczej tylko tester manualny. Automatyk ma go zazwyczaj wygenerowanego przez stosowane narzędzie.
Tak to się mniej więcej prezentuje z punktu widzenia pracownika, ale warto pamiętać również jak to wygląda z perspektywy projektu czy firmy. Testy manualne jesteśmy w stanie wdrożyć szybciej i mniejszym kosztem początkowym. Przeważnie wystarczą nam też do tego mniej techniczni testerzy, a już na pewno tacy bez umiejętności programowania. Automaty z kolei są dużo szybsze i tańsze w dłuższej perspektywie. Nie są także wrażliwe na błędy ludzkie, wynikające z ciągłego powtarzania tych samych czynności.

Kto może zostać testerem oprogramowania?

By zostać testerem potrzebne są przede wszystkim umiejętności logicznego myślenia przyczynowo-skutkowego oraz łączenia faktów. Ważna jest również skrupulatność, dzięki której dokładnie zaplanujemy i przeprowadzimy testy oraz wyłapiemy różne błędy czy nieścisłości. Ciekawość i dociekliwość okażą się nieocenione przy poszukiwaniu źródła danego problemu. Krytyczne są również cierpliwość i niezłomność przy przebijaniu kolejnych ścian. Dobre umiejętności interpersonalne przydadzą się w zespole, w którym najczęściej przyjdzie nam pracować. Jeśli natomiast przyjmiemy ciągłe powtarzanie jakiejś czynności w nadziei, że coś się zmieni, jako definicję szaleństwa, to i jego odrobina nie zaszkodzi.
Krótko mówiąc, jeśli masz analityczny umysł, lubisz łamigłówki i nie odstrasza cię częste zmaganie z problemami czy powtarzanie w kółko tego samego, to ścieżka idealna dla Ciebie.

Czy tester oprogramowania musi umieć programować?

Stwierdzenie, że musi, byłoby niewątpliwie kłamstwem. Można dobrze się znać na fachu testerskim i nie umieć programować. Tak naprawdę trzeba by się jednak mocno postarać, by będąc obecnym zawodowo w świecie IT i stając się dobrym testerem nie nauczyć się przy okazji choćby podstaw programowania. Co więcej, nie ma najmniejszych podstaw, by tego nie robić. Posiadanie takich umiejętności pomaga lepiej zrozumieć testowane zagadnienie, a co za tym idzie dokładniej je przetestować. Łatwiej jest nam wejść w dyskusję z programistami.

Nasz wkład w projektowanie systemu jest bardziej wartościowy. Możemy sami sobie ułatwić i usprawnić naszą pracę, wprowadzając różne skrypty przygotowujące środowisko czy testy automatyczne. Ponadto pod samym programowaniem kryje się tak naprawdę myślenie algorytmiczne, ścisłe, od którego w testowaniu nie ma ucieczki.

Czy tester oprogramowania może zostać programistą?

Jak najbardziej. Wiele osób podąża właśnie taką ścieżką kariery. Powiedziałbym nawet, że jest to łatwiejsze niż odwrotny scenariusz, w którym to deweloper chce zostać testerem. Dla pracodawcy takie wewnętrzne przejście jest o tyle lepsze, że po pierwsze zna już wartość swojego pracownika, a po drugie nie musi go przyuczać do zasad panujących w firmie i do wytwarzanego produktu. Pamiętajmy jednak, że wciąż musimy się w pierwszej kolejności wykazać umiejętnościami programistycznymi na odpowiednim poziomie.

To jest główne kryterium i dopiero po jego spełnieniu pracodawca będzie mógł rozważyć zmianę naszego stanowiska. Nie nastąpi ona też zapewne od razu. W większości przypadków konieczne będzie przedtem znalezienie i przeszkolenie naszego zastępstwa.

Jakie są ścieżki rozwoju testera?

Mamy sporo różnych możliwości. Po pierwsze oczywiście możemy zostać testerem manualnym i w tym się doskonalić. Przykładowo wyspecjalizować w jakiejś konkretnej działce testowania, jak choćby testy bezpieczeństwa. Po drugie możemy obrać ścieżkę analityka testów. Skupimy się tu bardziej na teoretycznej części testerskiego fachu, czyli analizie i projektowaniu, a wykonywanie pozostawimy innym. Kolejną oczywistą opcją jest zostanie testerem automatyzującym. Tutaj też możemy pokusić się o specjalizację.
Idąc dalej, możemy przeskoczyć na dewelopera. Nie traktujmy tego jednak jako następny poziom i cel każdego testera. Jest to tylko jedna z równoległych ścieżek, niekoniecznie najbardziej pożądana. Oprócz tego jest wiele innych takich poziomych przeskoków wewnątrz struktury firmy. Możemy pójść w stronę sysopsa, zarządzającego środowiskami, czy devopsa, będącego czymś pośrednim między deweloperem i administratorem środowiska. Możemy zostać pracownikiem wsparcia klienta. Kojarzy się to zapewne raczej z pracownikiem call center i taka oferta nie brzmi ani kusząco, ani opłacalnie. Nie o takim wsparciu jednak myślę. W niektórych, wyspecjalizowanych branżach może to być naprawdę ciekawe oraz dobrze płatne zajęcie.
Wreszcie otworem stoją przed nami wszelkie stanowiska kierownicze, takie jak Product Owner czy Project Manager. Często wywodzą się oni właśnie spośród testerów, ze względu na naszą ogólną wiedzę o całym projekcie oraz znajomość potrzeb klienta i bliższym z kontakt z nim.

Ile czasu trzeba poświęcić, żeby zostać testerem manualnym, a ile żeby zostać testerem automatyzującym?

Do zdobycia podstawowej wiedzy i umiejętności wystarczy jeden z wielu oferowanych przez nas kursów. Zazwyczaj jest to około 3-4 miesięcy intensywnej pracy na zajęciach oraz samodzielnie w domu “po godzinach”. Nie jest to jednak koniec. Porządne poznanie dobrych praktyk czy stosowanych narzędzi to proces długotrwały i wymagający praktyki. Myślę, że tak naprawdę dopiero po roku pracy zawodowej odnajdziemy się w pełni w roli testera. Proces nauki natomiast nie kończy się nigdy, co wiąże się z szybkim rozwojem całej branży IT.
Co do różnicy między testerem manualnym a automatyzującym, to nie jest ona łatwa do określenia. Co prawda ten drugi musi nauczyć się określonego języka programowania i poznać powiązane z nim narzędzia, ale również nie użyje wielu innych narzędzi, które być może znajdą się w arsenale testera manualnego. Powiedziałbym więc, że przeważnie zostanie testerem automatyzującym wymaga trochę więcej czasu, ale nie zawsze jest to regułą.

Czy testerzy są nadal potrzebni?

Powiedziałbym, że nie nadal, a coraz bardziej. Świadomość firm w kwestii zapewnienia jakości stale się zwiększa, przez co znacznie chętniej wprowadzają odpowiednie procesy do swoich projektów. Co rusz pojawiają się także nowe regulacje i standardy, wymuszające na firmach spełnianie określonych wymogów jakościowych. Dodatkowy nacisk wywierają również konsumenci, którzy mając spory wybór często skłaniają się ku produktom lepszym jakościowo. Z tego względu pracodawcy potrzebują wykwalifikowanych specjalistów, którzy będą w stanie zapewnić odpowiednie wdrożenie wspomnianych procesów. I tu wchodzimy my, cali na biało.

Ile zarabiają testerzy?

Zarobki mogą zależeć od wielu czynników. Pierwszym z nich jest oczywiście to o jakim testerze mówimy. Zgodnie z danymi zebranymi w 2019 roku przez portal testerzy.pl, średnia dla testera manualnego wynosi około 5 tysięcy złotych netto, natomiast dla testera automatyzującego około 8,3 tysiąca. Kolejnym jest doświadczenie rzeczonego testera. Początkujący mogą liczyć średnio na 3,7 tysiąca na rękę, natomiast tacy z doświadczeniem dostaną już średnio 6,3 tysiąca. Innym ważnym czynnikiem jest lokalizacja. Oczywiście im większy i ważniejszy (z punktu widzenia IT) ośrodek, tym większe zarobki.
Jest jeszcze kilka innych czynników, np. portfolio testera. Zachęcam do zapozna się z nimi oraz z dokładniejszą analizą wymienionych powyżej w Internecie. Ja wspomnę jeszcze tylko o jednej, wartej uwagi rzeczy. Na który czynnik byśmy nie patrzyli, porównując dane z tymi z wcześniejszych lat, zaobserwować możemy raczej wzrostowy trend.

Gdzie szukać informacji/wiedzy potrzebnej do zostania testerem?

Można oczywiście posiłkować się różnymi książkami czy kursami internetowymi o danej tematyce. Dzieła te jednak charakteryzują się różnym poziomem jakości, zarówno merytorycznej, jak i wykonania. Trzeba więc ostrożnie je dobierać i nigdy nie poprzestawać na jednym, ponieważ nawet nie będziemy świadomi, że coś było nie tak. Ponadto celowo użyłem tu zwrotu “posiłkować”. Według mnie najlepszym i podstawowym źródłem wiedzy jest przeważnie oficjalny dokument twórców – dokumentacja danego języka, specyfikacja protokołu czy, w przypadku testowania, sylabus ISTQB.
To jednak tylko teoria, wytłumaczona raz lepiej, raz gorzej. Osobom obytym w świecie IT powinna wystarczyć, ale dla początkujących może być niewystarczająca. Są również tacy, którzy po prostu wolą posłuchać o danym zagadnieniu, móc wejść w interakcję z prowadzącym czy solidnie coś przećwiczyć od strony praktycznej. Bez względu na powód, wszystkich chciałbym serdecznie zaprosić do wzięcia udziału w kursach organizowanych przez firmę SDA. Przedstawiamy na nich teorię prosto z sylabusa, podaną w zrozumiałej formie i okraszoną solidną porcją praktyki. Wszystko to pod profesjonalnym okiem naszych trenerów, którzy na co dzień stosują tę wiedzę w życiu zawodowym.

Co różni testera od programisty?

Programista większość czasu spędza na pisaniu kodu i analizowaniu dokumentów. W przypadku testera może to być bardziej zdywersyfikowane. Przykładowo poza testowaniem i analizą dokumentów częściej (niż deweloper) zajmuje się stawianiem środowisk – a te mogą być najróżniejsze i składać się z samego oprogramowania, specjalistycznego sprzętu lub być zwirtualizowane. Oprócz tego w swojej pracy używa przeważnie więcej różnorakich programów wspomagających.

To również testerzy częściej mają kontakt z klientem bądź działem wsparcia klienta. Mogą pomagać w tworzeniu materiałów na targi branżowe czy prezentacje przed klientem albo nawet bezpośrednio brać udział w tego typu wydarzeniach. Poza tym w wielu przypadkach wiedza o produkcie u dewelopera jest ograniczona do komponentów, którymi się zajmuje. Tester oprogramowania zajmujący się całym programem, będzie musiał znać wszystkie poszczególne komponenty oraz gotowy produkt.

Testowanie obejmuje nie tylko projektowanie, implementację i wykonanie testów, ale również zarządzanie i planowanie cyklu testowego, tworzenie i analizowanie raportów, tworzenie zgłoszeń błędów oraz kilka innych czynności.
Oczywiście wszystko to jedynie generalizowanie i w poszczególnych projektach role mogą być poniekąd odwrócone. Mimo wszystko jednak, uśredniając praca testera zazwyczaj jest bardziej różnorodna oraz nastawiona na pracę z większą grupą ludzi.

Co to jest ISTQB i czy warto mieć certyfikat?

ISTQB to organizacja non-profit zarejestrowana w Belgii. Została ufundowana w 2002 roku w celu wprowadzenia standaryzacji do świata testów. Wcześniej niestety brakowało nam takich ogólnie przyjętych standardów, przez co częściej dochodziło do przepuszczania na produkcję poważnych błędów. Wraz ze standardami, organizacja wprowadziła także szereg certyfikatów, które oficjalnie potwierdzają umiejętności testera w danym zakresie. Wyróżniamy trzy główne ścieżki certyfikacji. Agile skupia się na zastosowaniu w testowaniu popularnych w świecie IT metodyk zwinnych. Core rozwija podstawowe umiejętności testerskie na różnych poziomach zaawansowania. Specialist natomiast umożliwia nam zdobycie certyfikatu w konkretnych, wyspecjalizowanych dziedzinach testowania, na przykład testowaniu aplikacji mobilnych czy w testach bezpieczeństwa.

Nas najbardziej interesuje na razie ISTQB Foundation Level, będący punktem startowym dla wszystkich wymienionych ścieżek. Potwierdza on posiadanie przez testera elementarnej wiedzy w zakresie testowania. Dzięki niej między innymi rozumiemy podstawowe mechanizmy, znamy ustandaryzowane techniki i podziały, a także posługujemy się odpowiednim nazewnictwem. Certyfikat ten jest na tyle powszechny i uznawany, że obecnie często nie pojawia się już w ogłoszeniach jako “dodatkowa” czy “opcjonalna” umiejętność, a raczej jako pozycja wymagana od kandydata.

Jakie narzędzia powinien znać manualny tester oprogramowania, a jakie automatyzujący?

Tester, bez względu na to jaki, używa w swojej pracy wiele różnych typów narzędzi. Część z nich jest ściśle uzależniona od zadań testera czy specyfiki projektu i branży, ale wyróżniamy również kilka uniwersalnych, powszechnie spotykanych grup narzędzi. Proszę zwrócić uwagę, że mówię tutaj o grupach, a nie konkretnych programach, ponieważ są one zazwyczaj nam z góry narzucane przez firmę.

Zacznijmy od narzędzi do zarządzania błędami. Pozwalają nam one na tworzenie zgłoszeń błędów i wszelkie późniejsze operacje związane z obsługą i śledzeniem błędu. Do tej grupy należą między innymi Jira i Mantis.

Następną grupę stanowią narzędzia do zarządzania przypadkami testowymi. Umożliwiają nam między innymi tworzenie przypadków i cykli testowych oraz dokumentowanie ich wykonywania. Zaliczamy do nich Testlink czy Zephyr.

Kolejne są narzędzia do tworzenia dokumentacji projektu i wymiany wiedzy między członkami zespołu. Mogą to być zarówno specjalnie do tego przeznaczone programy, np. Confluence, jak i zwykłe pakiety biurowe, przykładowo od Googla czy Microsoftu. T

esterzy automatyzujący muszą do tego dołożyć oczywiście oprogramowanie do automatyzacji testów. W zależności od tego, co będą testowali, może to być Selenium Webdriver, Robot Framework, Ranorex i wiele innych. Prawdopodobnie warto będzie poznać także jakieś środowisko programistyczne, takie jak Visual Studio czy IntelliJ.

Oprócz tego przydatne może okazać się oprogramowanie ciągłej integracji (CI) i tutaj koronnym przykładem jest Jenkins.

Nie zapominajmy również o repozytorium kodu. Najczęściej będzie to GIT, a zatem wypadałoby znać GitLaba, GitHuba lub podobne usługi. Kolejne przykłady można mnożyć i mnożyć, jest to jednak temat na dłuższe szkolenie.

Czy można pracować zdalnie?

Zdecydowanie istnieje taka opcja, zwłaszcza w IT. Przeważnie jest to jedynie kwestia dogadania się z pracodawcą. Z tym różnie bywa, ale na szczęście coraz częściej zaczynają przychylniej patrzeć na pracę zdalną. Jeszcze bardziej zmienia się to pod wpływem pandemii – dla nas, testerów praca zdalna to nie jest żaden problem.

Jak zdobyć pierwsze doświadczenie jako tester oprogramowania?

Nie ma co się oszukiwać, wejście na rynek nie jest łatwe. Firmy zazwyczaj szukają kogoś z chociaż rokiem czy dwoma doświadczenia. Oczywiście trzeba próbować, próbować i jeszcze raz próbować. Samemu reagować na ogłoszenia, rozsyłać wszędzie CV, wybierać się na dni otwarte i imprezy branżowe. Ale to nie wszystko, co możemy zrobić.
W zależności od jaką ilością czasu dysponujemy, możemy rozejrzeć się za lokalnymi programami stażowymi czy tzw. patronatami. Niektóre firmy organizują krótkie projekty, do których biorą właśnie takich juniorów bez doświadczenia. W trakcie projektu przydzielają im opiekunów, którzy udzielają pomocy, ale także oceniają postępy. Na koniec firma zatrudnia najlepszych uczestników. Nawet jeśli się jednak nie załapiemy, to mamy już gotową pozycję do CV.
Kolejną opcją jest crowdtesting. Istnieje wiele platform oferujących to rozwiązanie, jedna z popularniejszych to utest.com. Wygląda to w ten sposób, że rejestrujemy się na którejś z platform jako niezależny tester. Jednocześnie zgłaszają się do niej różne firmy z ofertami testów określonego oprogramowania. My dostajemy odpowiednie przydziały i testujemy. Im bardziej będziemy aktywni i skuteczni, tym lepsze przydziały z czasem dostaniemy. Część jest pro bono, za część dostaniemy wynagrodzenie. Tak czy inaczej zyskujemy kolejną pozycję do CV.

Jak wygląda dzień w pracy testera?

Na to zdecydowanie nie ma jednej odpowiedzi. Jest zbyt dużo czynników dywersyfikujących, czasami nawet w ramach tego samego stanowiska. Ale odnieśmy się może do jakiegoś bardzo konkretnego przypadku, powiedzmy testera automatyzującego, pracującego w branży automotive.
Taki tester przyjdzie rozpocznie pracę o bliżej nieokreślonej godzinie. Zależy, o której wstanie. Uruchomi swój sprzęt i pójdzie po herbatę lub kawę. Gdy wróci do stanowiska, ma chwilę, by “wejść w dzień”, ogarnąć swoje zadania, sprawdzić maile i komunikatory, itd. O określonej godzinie połączy się z resztą zespołu. Opowie nad czym pracuje, co jeszcze przed nim i czy coś go obecnie blokuje. Posłucha co u współpracowników, a także ogólnie w projekcie. Być może wpadną jakieś nowe zadania. Po spotkaniu przystąpi do wykonywania swoich zadań, a te mogą być najróżniejsze. W trakcie cyklu testowego będzie oczywiście wykonywał testy automatyczne, analizował raporty czy szukał przyczyn testów zakończonych niepowodzeniem. W razie wykrycia błędów, wyśle odpowiednie zgłoszenia. Oprócz tego, bez względu czy trwa cykl, czy nie, zajmie się analizowaniem wymagań funkcjonalnych w zgłoszeniach nowych funkcjonalności bądź błędów. Po przeanalizowaniu, zajmie się projektowaniem nowych lub usprawnieniem istniejących przypadków testowych, by później je zaimplementować i wykonać. Czasami może pojawi się jakiś problem ze sprzętem i trzeba będzie w nim podłubać. Ewentualnie przyjdą części do zmontowania nowego środowiska. Albo pojawi się potrzeba zdzwonienia z deweloperem w celu omówienia któregoś zgłoszenia. A może… chyba już dawno skończył nam się dzień. No cóż, będzie kolejny.