Udostępnij:
Dlaczego testowanie? Co zachęciło Cię do tej pracy?
Szukałam jakiegoś pomysłu na siebie; czegoś, co mogłabym robić, a co nie miałoby wysokiego progu wejścia. Testowanie oprogramowania doskonale spełnia te warunki — żadne studia informatyczne czy kierunkowe wykształcenie nie jest wymagane, aby zacząć. Jasne, dobrze wygląda w CV, ale jego brak, przynajmniej dla mnie, nie był nigdy żadną przeszkodą. Liczą się chęci i zapał, szczególnie, jeżeli chwytamy się czegoś, o czym nie mamy zielonego pojęcia i trzeba przyznać, że na początek ta perspektywa może być trochę przerażająca. Szczególnie gdy zaczynając od hydrogeologa, poprzez konsultanta do spraw kredytów gotówkowych, ostatecznie lądujemy na pozycji Quality Assurance Engineera — są dni, kiedy sama w to nie wierzę 😉
Opowiedz proszę jak wygląda przeciętny dzień testera manualnego
Z mojego doświadczenia wiem, że wynika to od specyfiki projektu, w którym aktualnie się pracuje. W większości przypadków jednak zaczynam dzień od sprawdzenia, co jest do zrobienia na ten moment, ustalenia priorytetów i rozmów z innymi członkami zespołu.
Są jednak dni, kiedy większość czasu spędzamy na spotkaniach albo użeraniu się z konfiguracją lokalnego środowiska do testów i niekoniecznie akurat coś testujemy.
Sporo czasu, szczególnie, kiedy pracuje się zdalnie dla danego klienta (a członkowie zespołu potrafią być rozsiani nie tylko po całej Polsce, ale i świecie) zajmują rozmowy o tym, co mamy aktualnie robić, co na tę chwilę jest najbardziej istotne i jak mamy działać, aby wykonać naszą pracę jak najlepiej i, oczywiście, najszybciej.
Powiedziałaś nam już kilka słów o codziennej pracy testera. A czy ten zawód to zawsze dobry pomysł? Niektórzy twierdzą, że jest to praca dla każdego — a jak jest naprawdę?
Moim zdaniem tak nie jest. Wiem, że dużo słyszy się i czyta o tym, że to praca dla każdego, bo wspomniany przeze mnie próg wejścia jest niski: nie trzeba uczyć się programowania, wystarczy poklikać, pokazać, że nie działa i to wszystko. W rzeczywistości nie wygląda to już tak prosto.
Z mojej perspektywy wiem, że dużo daje posiadanie bardziej ścisłego niż humanistycznego umysłu i technicznego zacięcia. Ja zawsze byłam za pan brat z technologią, grzebanie w komputerach stanowiło dla mnie ciekawe zajęcie a zrozumienie procesów, odpowiadających za tworzenie oprogramowania nigdy nie było większym problemem, dlatego dość szybko odnalazłam się w nowej, testerskiej rzeczywistości.
Ale nie tylko techniczne umiejętności są tutaj istotne — dociekliwość, sumienność, odpowiedzialność, zdolność do samodzielnego organizowania dnia pracy (szczególnie, gdy pracuje się w dwóch czy trzech projektach jednocześnie) i spora doza cierpliwości — to pewnie tylko ułamek umiejętności miękkich, które potrafią naprawdę dużo pomóc.
Nie wspominając o znajomości języka angielskiego — większość klientów, dla których pracowałam, była z zagranicy, podobnie jak programiści, z którymi miałam przyjemność współpracować. Wiele programów, z których korzystam, są w tym języku, nie wspominając o technicznej dokumentacji. Pewnie, słownik czy translator jest bardzo pomocny, ale umiejętność w miarę swobodnej komunikacji pozwala nawiązać dobre stosunki z innymi, zagranicznymi członkami zespołu, co też wpływa pozytywnie na jakość pracy testera.
Załóżmy, że posiadam wymienione przez Ciebie cechy i chcę podążać tą ścieżką. Jak więc zostać testerem manualnym?
Nie ma jednej, utartej ścieżki, dlatego po prostu opowiem, jak ja nim zostałam — może moja historia zainspiruje kogoś do skorzystania z podobnych rozwiązań.
Pracując w poprzedniej firmie, zaczęłam rozglądać się za możliwością rozwoju w testowaniu oprogramowania i natrafiłam na szkolenie Akademia Testowania, które Testuj.pl organizuje dla takich ludzi jak ja — chcących zacząć. Szkolenie obejmowało naukę w celu uzyskania certyfikatu ISTQB Foundation Level, egzamin oraz cztery tygodnie praktyk w siedzibie firmy TestArmy, gdzie ja oraz inne osoby biorące udział w szkoleniu mieliśmy nauczyć się, jak wygląda praca testera manualnego, robiąc testowe zadania czy uczestnicząc w istniejących projektach, pod nadzorem bardziej doświadczonych testerów.
Przyznam, że było to dla mnie bardzo stresujące doświadczenie — nowe miejsce, nowi ludzie oraz ja, zaczynająca od zera i starająca się zrozumieć, o co w tym wszystkim chodzi (czasem też pytająca siebie „Co ja tu robię?” i „Czy to na pewno był dobry pomysł?”).
Po zakończeniu praktyk zapytano mnie, czy chciałabym zostać, bo widzą we mnie potencjał… i oto jestem 😉
Opowiedziałaś już jak zacząć. Następne pytanie brzmi: co dalej? Jakie możliwości rozwoju daje praca testera manualnego?
Dla mnie podstawową z nich było i wciąż jest uczucie, że robi się coś, co ma sens. Jako tester regularnie widzisz efekty swojej pracy, od czasu do czasu ktoś poklepie Cię po ramieniu i powie „Dobra robota”. Świadomość tego, że jest się ważnym członkiem zespołu i wnosi się do niego jakąś wartość, daje wiele satysfakcji.
Ale oprócz psychicznej satysfakcji i faktu, że umysł średnio kiedy przestaje pracować w trakcie rozgryzania danego projektu czy problemu, mamy też sporo możliwości rozwoju. To, którą z nich wybierzemy, zależy już od osobistych preferencji. Możemy zostać automatykiem, czyli pisać testy i rozwijać się w kierunku nauki programowania; testerem bezpieczeństwa, jeżeli interesują nas zagadnienia związane z tym tematem; czy osobą odpowiedzialną za testy wydajnościowe.
Istnieją jednak ścieżki rozwoju nie tylko techniczne. Niejeden czuje się zdecydowanie lepiej jako Test Manager czy Leader — woli kierować zespołem, ustalać priorytety, rozmawiać z klientem i to jest coś, co go interesuje.
Możliwości jest naprawdę wiele. Uważam, że warto robić to, co nas interesuje. Dzięki temu praca jest czymś, do czego podchodzimy z uśmiechem i zapałem, a nie czymś, co uważamy za przykry obowiązek i tylko czekamy, aż kolejny dzień dobiegnie końca — stąd też wynikło moje poszukiwanie dla siebie miejsca w branży IT.
A czy powtarzane przez wielu słowa, że aby rozwijać się w zawodzie testera trzeba wcześniej czy później przejść na automatyzację to prawda, czy tylko stereotyp?
Nawiązując do odpowiedzi na poprzednie pytanie — nie. Przejście z manuala na automatyka jest ścieżką, tak mi się przynajmniej wydaje, najbardziej popularną oraz reklamowaną. Bardzo dużo mówi się o automatyzacji testów oraz o płynących z niej benefitach, z czym oczywiście się zgadzam — w niejednym projekcie, w którym byłam, obecność testów automatycznych ujawniła nam paskudną regresję. Ale czy zostanie testerem automatyzującym to konieczna ścieżka? Nie sądzę.
Warto uczyć się programować, spróbować zrozumieć czym jest ten koncept, wybrać język, od którego chcielibyśmy zacząć, ponieważ sama umiejętność rozumienia jak jest tworzone i jak działa oprogramowanie, pomoże lepiej zrozumieć produkt, który testujemy oraz polepszy samą jakość i dokładność testów. Nie znaczy to jednak, że jako testerzy manualni musimy od razu zostać automatykami i nie istnieją dla nas inne, równie ciekawe sposoby na rozwój.
Z moich osobistych obserwacji wynika, że warto najpierw dobrze nauczyć się testowania manualnego, poznać różne sposoby, haki oraz koncepty, by później móc, np. przenieść to doświadczenie na dobrze zaprojektowane testy automatyczne.
To jeszcze jedno pytanie: czy tester manualny jest skazany na gorsze zarobki niż ten umiejący automatyzować?
Ciężko jest mi odpowiedzieć jednoznacznie na to pytanie, gdyż nie śledzę aktualnej sytuacji na rynku pracy, ale z dotychczasowych obserwacji oraz rozmów z różnymi osobami na różnych stanowiskach (testerami, programistami) mogę wywnioskować, że nie jest to takie czarno-białe.
Dobry tester manualny, który ma sporo doświadczenia w różnych projektach, zna wiele przydatnych narzędzi i naprawdę zna się na swojej robocie, może być równie dobrze opłacany i doceniany co automatyk.
Jasne, tester automatyzujący potrafi programować, zna różne frameworki wykorzystywane do pisania czy uruchamiania testów i jego umiejętności są dużo bardziej specyficzne i ukierunkowane, ale nie raz słyszałam głosy mówiące, że dobry tester manualny jest tak samo ważny, jak dobry automatyk i może być równie dobrze wynagradzany za swoją pracę — i wcale nie tak łatwo jest takiego znaleźć.
Zmieńmy odrobinę temat. Najciekawszy bug w Twojej kolekcji to…? 🙂
To pytanie, na którym zwykle się wykładam. Długo zastanawiałam się nad odpowiedzią, która mogłaby wgnieść kogoś w fotel. W ostatnim projekcie, w którym pracowałam, zaobserwowałam ciekawy błąd — użytkownik nie był w stanie zapisać zmian w pliku, w którym aktualnie pracował, kiedy do grafu utworzonego na podstawie danych z tabeli, zostały dodane etykiety. Niby nie brzmi to, jak nic wielkiego, ale po długich poszukiwaniach udało mi się ustalić, że dotyczyło to tylko jednego rodzaju grafu z sześciu dostępnych, oraz, że użytkownik nie był w stanie zapisać dokonanych zmian, utworzony plik stawał się przy próbie zapisu nie do użytku i pozostawało go tylko usunąć. Nie wspominając o tym, że aplikacja sypała błędem, który bardziej przypominał coś typowego dla programistycznej konsoli niż coś, co zwykły użytkownik jest w stanie zrozumieć. Sam program należało zrestartować, aby móc ponownie z niego korzystać. Na zakończenie dodam, że tworzenie grafów oraz ich edycja stanowiły jedną z największych funkcjonalności systemu, tym samym blokując każdego, korzystającego z tej aplikacji. Takie krytyczne bugi lubię najbardziej. 😉
A najciekawszy projekt?
Nad tym akurat nie muszę długo się zastanawiać. Był to projekt, nad którym pracowałam najdłuższej w całej mojej dotychczasowej karierze testerki i który rozpoczęłam ledwo kilka miesięcy po tym, jak nią zostałam. Wspominam go najcieplej, bo była to prawdziwa szkoła życia nie tylko pod kątem technicznym, ale i organizacyjnym.
Pracowaliśmy z klientem z USA, gdzie częściowo wytwarzano oprogramowanie, ale mieliśmy też w zespole kilku testerów z Indii, więc sporo wysiłków włożyliśmy w samą organizację pracy i pogodzenie jej z różnicami w strefach czasowych. Byłam nie tylko testerem, ale i team leaderem oraz managerem. Prowadziłam spotkania z klientami, by zaprezentować wyniki naszych testów oraz ocenić jakość wytworzonego software’u, pilnowałam programistów, aby dobrze opisywali taski w Jirze i przenosili je do odpowiednich kolumn. Przez bardzo długi czas robiłam to wszystko sama — cały zespół deweloperski tworzyłam tylko ja i dziewięciu programistów. Było to kolosalnym wyzwaniem ze względu na skomplikowanie architektoniczne projektu i fakt, że weszłam do niego w momencie, kiedy trwał już od około roku — próg wejścia i ilość rzeczy do ogarnięcia była gigantyczna.
To tam nauczyłam się jak pracować z ludźmi, jak zarządzać projektem od strony jakości, jak rozmawiać z klientami, jak priorytetyzować zadania… Zdałam sobie też sprawę, że nie zawsze jesteśmy w stanie wszystko dokładnie sprawdzić i przyznanie się do tego faktu otwarcie jest jak najbardziej w porządku.
Nawet jeżeli było ciężko, miałam szczęście współpracować ze świetnymi osobami i chociaż przez jakiś czas byłam jedyną osobą pracującą zdalnie w zespole, czułam się jego integralną częścią i wiedziałam, że moja pomoc jest nieoceniona. Było to dla mnie bardzo ważne i rozwijające doświadczenie — każdemu testerowi życzę takich jak najwięcej!
