Testerzy oprogramowania są tak samo pożądani na rynku jak programiści

Kiedyś ganiał w garniaku, interesowały go duże deale i „trzydzieste piętro w biurowcu szklanych drzwi”. Dziś zajmuje się jakością oprogramowania w TestArmy Group S.A., która została sklasyfikowana na 9 miejscu najszybciej rozwijających się przedsiębiorstw IT wg. raportu Computerworld TOP200. Kim jest idealny tester? Jakie umiejętności musi posiadać? Na czym polega testowanie oprogramowania? Na te i inne pytania odpowiada Adam Dziuba.

Czym dokładnie zajmowałeś się wcześniej, zanim zdecydowałeś się na zmiany w swoim życiu zawodowym?

Kilkanaście lat pracowałem w sprzedaży, w spółkach technologicznych. Sprzedawałem usługi i rozwiązania telekomunikacyjne, telematykę oraz systemy teleinformatyczne. Zaczynałem od korpo. Do Plusa trafiłem zaraz po studiach, jak gsm miał kilka miesięcy i raczkował. Telekomunikacja i świat dużego biznesu pochłonęły mnie bez reszty. To było jedno z najnowocześniejszych przedsiębiorstw w kraju. Właściwie ta firma ukształtowała mnie zawodowo i tam najwięcej też się nauczyłem. Kolejni pracodawcy to już mniejsze organizacje, ale bardzo dynamiczne, same gazele biznesu. Los chciał, że stale trafiałem do firm w rozwoju, które dopiero planowały wejście na swój biznesowy Everest. Znowu więc kolejne wyzwania, uczenie się nowych rzeczy, ale to właśnie lubię najbardziej.

Kiedy pierwszy raz usłyszałeś o testowaniu oprogramowania? Co myślałeś wtedy o zawodzie testera?

Ta profesja wtedy nie leżała w kręgu mojego zainteresowania. W tamtym czasie ganiałem w garniaku, interesowały mnie duże deale i „trzydzieste piętro w biurowcu szklanych drzwi”. Niewiele wiedziałem o testowaniu i raczej sądziłem, że to robota dla studentów lub młodziaków zaraz po studiach.

Na zdjęciu: Adam Dziuba podczas testowania oprogramowania

Dlaczego postanowiłeś spróbować swoich sił właśnie w testowaniu?

Może nie będę zbyt oryginalny jeśli powiem, że usługi związane z zapewnieniem jakości oprogramowania to świetny biznes. Wraz ze stałym wzrostem rynku oprogramowania, dynamicznie rośnie też rynek usług testerskich. Poza tym testowanie to branża z ogromną przyszłością i jedna z bardziej dostępnych ścieżek, by przejść na drugą stronę lustra w IT i rozpocząć swoją przygodę z wytwarzaniem oprogramowania. Świadomość, że produkty nad którymi pracujesz służą później innym ludziom daje duże poczucie satysfakcji.

W jaki sposób uczyłeś się testowania?

Zacząłem od teorii (książki, artykuły, tutoriale), następnie zrobiłem certyfikat ISTQB i zamierzałem w końcu sprawdzić zdobytą wiedzę w praktyce. Trafiłem do TestArmy (wówczas jeszcze Cloud Testing) i to od razu na głęboką wodę. Miałem zastąpić kolegę w projekcie podczas jego urlopu, ale produkcja złapała zadyszkę, więc dostałem swój pierwszy długoterminowy projekt, którym była platforma do tworzenia szkoleń interaktywnych, certyfikacji oraz zarządzania nimi. Później poszło już z górki. Pomogło wcześniejsze doświadczenie zawodowe i wiedza dziedzinowa z kilku branż.

Jak często zmienia się praca testera programisty? Jak dużo czasu musi poświęcać na poznawanie nowinek technologicznych?

Z tym bywa różnie. Zdarzają się projekty krótkoterminowe, gdy aplikacja jest już gotowa, lub wprowadzana jest kolejna jej wersja i testy są zakontraktowane na kilka, czy kilkanaście godzin. W przypadku projektów długoterminowych są to już miesiące i budując aplikację od początku, często trzeba zapoznać się z nowymi technologiami. Częste zmiany są niewątpliwie czynnikiem wzbogacającym doświadczenie.

Jednak jeśli chcesz być na topie i rzeczywiście płynąć z nurtem, nie tylko krajowym, lecz ogólnoświatowym to stale trzeba się dokształcać, uczestniczyć w meetupach, warsztatach, szkoleniach oraz konferencjach.

Co jest najciekawszego w pracy testera i za co ją lubisz?

Podoba mi się sama idea, testowanie ma prowadzić do tego, aby klient otrzymał produkt jak najwyższej jakości, a tym samym uchronić go od ewentualnych przykrych konsekwencji. To bardzo odpowiedzialne i etyczne zadanie. Poza tym bardzo lubię pracę zespołową, stałą komunikację z innymi członkami zespołu (czasami znajdującymi się na drugiej półkuli), aby realizować wspólny cel, cenię sobie możliwość kontaktu z najnowocześniejszymi technologiami oraz dużą elastyczność, pozwalającą pracować niemal z każdego miejsca na świecie, gdzie jest dostęp do internetu.

Co sprawia, że zawód testera oprogramowania jest przyszłościowy i stanowi dużą gwarancję znalezienia pracy?

Oprogramowanie rozwija się w zawrotnym tempie i nic nie wskazuje, aby w najbliższej przyszłości miało się to zmienić. Coraz więcej urządzeń, ma zaimplementowaną zaawansowaną elektronikę oraz oprogramowanie. Z czasem software będzie wzbogacał funkcjonalność większości urządzeń codziennego użytku. Ktoś przecież musi to testować.

Czy myślisz nad spróbowaniem swoich sił w programowaniu?

To chyba jeszcze nie ten etap. Oczywiście chcę rozwijać umiejętność programowania, lecz aktualnie w zakresie, jaki potrzebny jest mi do automatyzacji testowania. Bardzo ciekawym wyzwaniem są też testy bezpieczeństwa, ale to również wyższa szkoła jazdy. Mnie z kolei ciągnie w stronę analizy biznesowej i systemowej.

Na zdjęciu: zespół TestArmy

Czy bałeś się swojej pierwszej rozmowy kwalifikacyjnej i tego jak będzie odebrany Twój wiek? Czy spotkały Cię z tego powodu jakieś nieprzyjemności?

Absolutnie nie. To właśnie jest piękne w tej branży, że wiek nie ma większego znaczenia, a kurze łapki można przykryć kompetencjami. Poza tym nie przesadzajmy, czwórka z przodu to jeszcze nie ten wiek, kiedy trzeba się już trzymać trawy 😉

Czy uważasz, że każdy może nauczyć się pracy testera i przebranżowić się? Czy rekomendowałbyś to swoim znajomym?

Zależy o jakim poziomie umiejętności mówimy. Mimo obiegowych stereotypów, testowanie oprogramowania nie jest pracą, w której każdy się sprawdzi i będzie się realizował zawodowo. Wielu kompetencji związanych z testowaniem można się nauczyć, ale znacznie trudniej jest zmienić siebie, swoje cechy charakteru, które cię predestynują by być testerem lub przekreślają twoje szanse na sukces w tym zawodzie.

Przejdźmy do samego tematu testowania oprogramowania. Ponoć nie ma oprogramowania bez wad.

Słowo „ponoć” byłoby już nadużyciem. Zgodnie z aksjomatami testowania, nie da się przetestować oprogramowania całkowicie, jak również testowanie nie stanowi dowodu na to, że aplikacja jest wolna od błędów. Człowiek jest istotą omylną i błędy pojawiają się już w fazie kontaktów z klientem, kompletowania wymagań i tworzenia dokumentacji projektu, a ich przyczyny mogą dotyczyć np. problemów komunikacyjnych jednej lub drugiej strony, niewystarczających kompetencji wykonawcy, nieznajomości podobnych rozwiązań istniejących już na rynku lub braku zarządzania ryzykiem. Dlatego bardzo ważne jest rozpoczęcie testowania wraz z początkiem cyklu życia projektu, stosując techniki statyczne, zanim błąd przybierze fizyczną postać usterki, a w efekcie ujawni się w postaci awarii.

Takie podejście znacznie oszczędza czas i pieniądze, gdyż wymaga tylko poprawek w dokumentacji, zanim na jej podstawie powstanie gotowy produkt lub jego część, a podczas demo (metodyki zwinne) klient stwierdzi, że nastąpiło chyba jakieś nieporozumienie i nie tego oczekiwał.

Jakiego rodzaju błędy najczęściej udaje się znaleźć testerowi? Możesz podać typowe przykłady?

Rodzaj wykrywanych błędów zależy od fazy projektu, rodzaju oprogramowania, rodzaju przeprowadzonych testów itd. Inne błędy wykrywają np. testy bezpieczeństwa, a inne testy funkcjonalne frontendu. Te drugie chyba są najbliższe wyobrażeniom przeciętnego człowieka o testowaniu. Weźmy, więc pod uwagę jeden z powszechnie znanych rodzajów aplikacji – sklep internetowy. Zgodnie z moją praktyką, tego typu software często “choruje” na:

• problemy z autoryzacją użytkowników (zapamiętywanie i zmienianie haseł),
• błędy związane z nawigacją (nieaktywne przekierowania),
• błędy związane z walidacją formularzy np. brak ograniczenia ilości znaków w polach,
• błędy w wyszukiwaniu danych (często spotykane w sklepach gdzie zaimplementowano skomplikowane filtry, wyszukiwanie i sortowanie),
• braki w kontencie,
• błędy rachunkowe w prezentacji danych,
• błędy związane z uprawnieniami,
• błędy API (komunikacja z aplikacjami zewnętrznymi: banki, dostawcy, social media),
• jak również błędy związane z użytecznością oraz błędy GUI.

Jak wygląda sam proces testowania oprogramowania?

Oprócz fizycznego wykonania testów na proces testowy składają się również czynności związane z analizą, planowaniem, nadzorem, oceną i raportowaniem oraz szereg czynności zamykających. Tak przynajmniej wygląda to w teorii. W rzeczywistości, czynności te często występują jednocześnie lub niektóre z nich występują w bardzo okrojonej formie. W każdym razie zawsze należy ustalić najpierw co trzeba przetestować, jaki jest zakres testów, jakie są ryzyka i ograniczenia, czy aplikacja jest gotowa, czy dopiero zaczęły powstawać pierwsze linijki kodu. Kiedy wszystko zostanie wnikliwie przeanalizowane, wówczas dopiero można zająć się strategią testowania, przygotowaniem danych testowych, określeniem środowisk, potrzebnych narzędzi oraz przygotowaniem samych przypadków testowych. Te następnie układane są zgodnie z przyjętymi priorytetami. Teraz dopiero można powiedzieć aplikacji “sprawdzam”.

W zależności od rodzaju projektu i przyjętej strategii testów mogą być one wykonane manualnie lub z użyciem narzędzi do automatyzacji. Wszystkie odchylenia w działaniu i wyglądzie aplikacji, które nie zgadzają się z przyjętymi kryteriami akceptacji lub designem muszą być odpowiednio zgłoszone (najczęściej z użyciem jakiegoś bugtrackera) i udokumentowane (screenshoty, video, logi). Kiedy wszystkie rodzaje testów zostaną już zakończone, często, choć nie zawsze przygotowywany jest raport końcowy, zaś testalia są porządkowane i archiwizowane, aby mogły być wykorzystane ponownie, a sama aplikacja trafia w ręce klienta. Można więc zapytać, kiedy kończy się testowanie, skoro nie da się znaleźć wszystkich błędów. Właściwie to nie kończy się nigdy i w przypadku szanujących się brandów trwa ono, aż do końca życia produktu.

Oferty pracy z

Jak oznacza się błędy w oprogramowaniu?

W zależności od projektu i ustaleń zespołu, zgłoszenia błędów mogą być labelowane w kilku miejscach, co ma za zadanie przyśpieszyć zidentyfikowanie miejsca ich występowania, a także ułatwić zarządzanie nimi. Dość częstą praktyką jest zaznaczanie w temacie błędu czy dotyczy on frontendu [F], czy backendu [B]. Dodatkowo można też spotkać się z podawaniem nazwy modułu, w którym błąd występuje. Ponadto bagtrackery w formularzach zgłoszeniowych zazwyczaj zawierają specjalne pola, aby w nich wpisać lub wybrać z rozwijanego dropdowna: wersję build’a, środowisko, rodzaj błędu i jego priorytet, a także móc przypisać zadanie rozwiązania problemu właściwej osobie.

Na zdjęciu: Adam Dziuba

Tester powinien zadbać, żeby zgłoszony błąd był precyzyjnie opisany i udokumentowany, aby jego zreprodukowanie nie wymagało dodatkowych wyjaśnień i konsultacji. W zależności od rodzaju testów lub doświadczenia testera, zgłoszenie może także wskazywać na miejsce błędu w kodzie oraz sugerować sposób jego usunięcia. Zgłoszony błąd powinien być również monitorowany, aż do momentu usunięcia go i potwierdzenia retestami, a po uzyskaniu pozytywnych rezultatów odpowiednio oznaczony i zarchiwizowany.

Czy tester oprogramowania musi znać się na programowaniu?

Jeśli zamierza się wspomagać narzędziami do automatyzacji testów, to owszem tak. Musi umieć pisać kod, który będzie testował kod aplikacji, ale nawet w przypadku testerów manualnych znajomość choć jednego języka programowania jest dobrze postrzegana, bo usprawnia i przyśpiesza testowanie. Nie musi to być znajomość funkcjonalna, ale dobrze jeśli tester rozumie kod. Aktualnie większość aplikacji ma charakter webowy, więc warto również znać przynajmniej podstawy HTMLa, kaskadowe arkusze stylów (CSS) oraz SQLa. W ten sposób tester może ułatwić pracę sobie i developerom, a także podnieść swoją wartość na rynku pracy.

Czym różni się testowanie aplikacji webowej od aplikacji mobilnej?

Patrząc choćby na fakt, że w przypadku aplikacji webowej użytkownik ma do niej dostęp tylko na zasadzie interfejsu, którym jest jego przeglądarka internetowa, to w przypadku aplikacji mobilnej trzeba ją pobrać z właściwego sklepu lub innego źródła i zainstalować np. social media. Oczywiście można uparcie korzystać z tych aplikacji przez przeglądarkę telefonu, ale z jakiego powodu się tak męczyć skoro są wersje mobilne ułatwiające nawigację, przeglądanie kontentu i realizowanie określonych swoich potrzeb? Tak, więc samo to już wpływa na konieczność zaprojektowania testów sprawdzających, jak aplikacja się instaluje oraz współpracuje z różnymi urządzeniami i systemami operacyjnymi.

Weźmy więc pod uwagę samą mobilność. Jeśli aplikacja potrzebuje stałego dostępu do internetu to musi być przygotowana na zmieniającą się jakość transmisji danych w sieciach GSM, a to kolejne testy. Niektóre aplikacje muszą współpracować z innymi aplikacjami zainstalowanymi w telefonie (np. kalendarzami, nawigacją czy listą kontaktów) lub aplikacjami zewnętrznymi, zatem te interfejsy również muszą być przetestowane. Jeszcze inne aplikacje mogą bezpośrednio korzystać z fizycznych komponentów smartfona, takich jak GPS, akcelerometr, żyroskop, kamery lub czytnik linii papilarnych. Dodatkowe testy będą również dotyczyć zachowania w przypadku rozładowania baterii, przychodzenia wiadomości tekstowych (SMS, MMS, komunikatory), połączeń głosowych (GSM, VOIP) oraz powiadomień z innych aplikacji. Powstaje spora ilość różnego rodzaju testów, wymagających od testera dużej kreatywności, ale też wiedzy, aby poradzić sobie z tak dużą ich ilością.

Praca testera wymaga kreatywności i pomysłowości. Co to znaczy?

Tester jest trochę jak aktor, wchodzi w różne role, często improwizując. W przypadku aplikacji tworzonych na potrzeby danej firmy wchodzi w rolę użytkowników, aby w testach uwzględnić ich zachowania. Jeśli aplikacja jest skierowana do szerszej grupy odbiorców i dystrybuowana przez sklepy, wówczas ilość niestandardowych zachowań znacznie rośnie, a tester musi tym razem wczuć się w rolę różnych userów, aby wymyślić testy, które będą sprawdzały nawet najdziwniejsze zachowania, a niektórzy użytkownicy rzeczywiście potrafią nieraz kroczyć krętą ścieżką poza wszelką logiką i zanim coś zrozumieją, to wcześniej zdążą to zepsuć. Aby tak się nie stało, tester również musi wykreować takie absurdalne zachowania i zaprojektować pod nie testy, aby się nie okazało, że jakieś przypadkowe i banalne działanie crashuje aplikację. Z kolei w testach bezpieczeństwa tester wciela się w rolę hakera, jednocześnie starając się myśleć jak twórca aplikacji, aby odnaleźć miejsca szczególnie podatne na działania hakerskie.

W opisie pracy testera dużo piszecie o umiejętnościach miękkich. Dlaczego są one tak ważne przy testowaniu oprogramowania, które jest zadaniem technicznym?

Dobrze, że o to pytasz, bo poza komunikowaniem się z maszynami, bardzo duża część pracy testerskiej to komunikacja z członkami zespołu developerskiego i testerskiego, z projekt menedżerami, analitykami oraz klientami. Jeśli tester pracuje w kilku projektach jednocześnie to zazwyczaj musi się komunikować z zespołami na kilku, a nawet kilkunastu kanałach komunikatora. Każdego dnia powstają dziesiątki stron tekstu. Dlatego umiejętność budowania krótkich i precyzyjnych komunikatów oraz wielozadaniowość jest bardzo istotna.

W metodykach zwinnych, tester często bywa też prezenterem, jako osoba znająca aplikację całościowo, jej mocne i słabe strony. Innym razem musi być całkiem niezłym negocjatorem, aby np. potrafić przekonać zespół do zmian designerskich lub UXowych, dlatego, że standardy tego wymagają.

Z umiejętnościami miękkimi związane są pewne cechy osobowe, takie jak koncentracja, analityczny umysł, nieszablonowość, asertywność, obiektywizm i dokładność. Tester musi być szczególarzem, bo w tej robocie w nich właśnie diabeł tkwi. Jak widać trzeba łączyć wiele kompetencji, żeby być dobrym cerberem jakości, aby np. teraz nie zawiodła nas aplikacja, dzięki której rozmawiamy.

Jak określiłbyś idealnego testera oprogramowania?

Idealny Tester to osoba, która potrafi patrzeć na cały proces produkcji oraz na samą aplikację zarówno oczami fachowca od jakości, developera, klienta i użytkownika końcowego. Świetnie zorganizowany, pomocny, chętnie dzielący się wiedzą i mocno zorientowany na wspólne osiąganie celów.

Doświadczony tester potrafi również wspierać zarządzanie zespołem wdrażając dobre praktyki, których skuteczność sprawdził w poprzednich projektach. Ponadto jeśli posiada dużą wiedzę techniczną i dziedzinową związaną z branżą klienta i czynnie angażuje się w proces produkcyjny, poszukując rozwiązań oszczędzających czas i pieniądze, będzie z pewnością mile widziany w każdym zespole. Z kolei, jeśli czyjeś testerskie credo wyraża się w stwierdzeniu – “znalazłem mnóstwo błędów i swoje zrobiłem, a teraz niech się devy z nimi męczą” to nie ma czego szukać w tym zawodzie.

Co zrobić, gdy nie stać nas na zatrudnienie firmy do przetestowania stworzonego przez nas oprogramowania?

Wszystko zależy od rodzaju oprogramowania, grupy do jakiej jest kierowane i poziomu ryzyka, gdyby w aplikacji wystąpiły poważne błędy. Niemniej, brak finansów nie powinien implikować pytania – testować, czy nie testować, bo może się to źle skończyć. W takim przypadku, żeby nie ponosić ryzyka najlepiej byłoby przed rozpoczęciem projektu dodać koszty testów i zoptymalizować wówczas projekt jako całość, aby te koszty się zmieściły. Pozorna oszczędność na testowaniu może doprowadzić producenta oprogramowania do katastrofy finansowej.

Innym rozwiązaniem może być crowd testing, który powinien obniżyć koszty testowania, lecz ma on również swoje wady. Na rynku istnieją też test freelancerzy, którzy mogą wykonać testy dużo taniej, a jeśli potrafią jeszcze korzystać z narzędzi wspierających testowanie np. aplikacji do automatyzacji lub z farm urządzeń to może się okazać, że czas, dokładność oraz cena będą na przyzwoitym poziomie. Ostatecznie można też zatrudnić do swojej organizacji testera, ale to wiąże się z potrzebą utrzymania etatu, wraz ze wszystkimi tego konsekwencjami, a trzeba przecież pamiętać też o rozwoju pracownika.

Dlatego zlecenie testów zewnętrznej firmie w ostatecznym rozrachunku okazuje się jednak tańsze i wygodniejsze, ponieważ można skorzystać z usług w okresie wzmożonej potrzeby testów lub tylko przez pewien czas, cyklicznie.

Adam Dziuba. Pasjonat nowych technologii, wcześniej zajmował się sprzedażą i wdrażaniem rozwiązań biznesowych wchodzących na polski rynek. Przez kilkanaście lat związany z branżą telekomunikacyjną i teleinformatyczną. Aktualnie współpracuje z TestArmy Group S.A., zajmując się zapewnieniem jakości oprogramowania w międzynarodowych projektach. Ostatnio realizuje się również jako współorganizator największej testerskiej konferencji w kraju – Testwarez. Biznesowa przeszłość sprawia, że stale myśli o własnym start-upie, tym razem w branży IT.