Nikodem: Twoim… Jest bardzo bliski mojemu serduszkowi. Nie martw się przyszły Nikodemie, nie martw się przyszła Aniko, która będziesz tego słuchała, na pewno ci się będzie to fajnie sklejać.
Cześć! Z tej strony Nikodem. Witam w kolejnym odcinku podcastu DEVision. Dzisiaj w studio jest ze mną Szymon Butkiewicz, cześć!
Szymon: Hej!
To jest w naszym zwyczaju, zawsze pytamy naszych gości, żeby powiedzieli kilka słów o sobie, więc Szymonie, słuchamy.
Jestem testerem od ośmiu albo dziewięciu nawet lat już teraz, głównie zajmowałem się testami manualnymi i miałem epizody automatyczne można tak powiedzieć. Na chwilę obecną pracuję w firmie White Hat Gaming i testuję gry online.
W końcu pojawił się temat, który bardzo lubię, a mianowicie testowanie. Ale to też nie jest tak, że zawsze lubiłem testowanie. Pamiętam swoją pierwszą pracę, kiedy pisanie testów było dla mnie bardzo męczące i wtedy zawsze się zastanawiałem, po co. Teraz kieruję to pytanie do ciebie, po co testować?
Testujemy po to głównie, żeby zminimalizować ryzyko, że klient dostanie niesprawną aplikację, tudzież jakąś z defektami. To ryzyko nigdy nie będzie równe zeru, ale jako testerzy, QA czy jak zwał tak zwał, staramy się właśnie zminimalizować, żeby szansa, że finalny produkt będzie w jakiś sposób z błędami, będzie niewystarczająco dobry dla klienta była jak najmniejsza.
Dobrze, ale po co w takim razie jest jeszcze twoja rola jako QA, skoro ja jako programista napisałem swój program i przecież mógłbym go przetestować sam?
No więc w przypadku programistów, jak w przypadku wszystkich innych producentów czegokolwiek, istnieje ryzyko stronniczości, jako że twórca jest pewnie pozytywnie nastawiony do swojego produktu, i powinien przyjść ktoś, kto ma bardziej obiektywne nastawienie do tego i jakby widzi to nie jako coś, co zajęło wiele godzin, tylko coś jako obiektywną rzecz powiedzmy i jest większa szansa, że wykryje błędy, o których nie pomyślał właśnie twórca.
Zgodzę się z tym. Pamiętam właśnie tak jak wspomniałem swoje pierwszą rolę, te testy często wyglądały po mojej stronie tak, że testowałem tylko powiedzmy szczęśliwą ścieżkę, mianowicie głównie się testowało, czy to faktycznie działa tak, jak powinno, a rzadziej się sprawdzało, co się stanie, jeżeli jednak wprowadzimy błędne dane. To prawda.
No i jeszcze tu pozwolę sobie dodać właśnie i testerzy wraz z nabywanym doświadczeniem zgromadzą jakby taki zestaw sztuczek, które wykorzystują do testowania, na przykład pól tekstowych. Co tam można wpisać, liczbę znaków, którą można tam wklepać, przeklejanie i tak dalej, i tak dalej, to jest taki przykład. A programiści mogą o tym po prostu nie pomyśleć i to jest w porządku, to nie jest jakby ich rola, żeby przewidywali wszystkie scenariusze, ale testerów już tak. I właśnie oni od tego są, żeby sprawdzić, czy to wszystko będzie działało.
Czy możesz opisać nam jak wygląda twoja codzienna praca jako QA?
Codzienną pracę zaczynam od spotkania zwanego stand-up’em, jest to jedna z ceremonii scrumowych, podczas której omawiamy co będziemy robić danego dnia na podstawie tego, co mamy w backlogu czy na tablicy w Jira, omawiamy też ewentualne problemy, na które natrafiliśmy i potem zabieramy się po tym spotkaniu, jak już wszyscy wiemy, kto w zespole co robi, zabieramy się do pracy. U nas są w mojej obecnej firmie są dwa źródła zadań, które dostajemy. Jedne są związane z zadaniami ogólnie całego teamu, które doszły do nas od strony product menadżerów albo są to błędy do naprawienia, albo wprowadzenie nowych funkcjonalności, tudzież produktów do naszego sklepu i druga pula tych zadań, tasków, które dostajemy, pochodzi z helpdesku, który zbiera zgłoszenia od użytkowników, którzy się skarżą, że coś tam nie działa w naszych produktach. Pierwsza grupa to są nasze takie priorytetowe zadania. Je omawiamy wcześniej na planingach i refinementach, czyli kolejnych ceremoniach scrumowych i potem zabieramy się właśnie do pracy i zaczynamy właśnie od tych zadań i to zwykle polega na tym, że albo są jakieś zmiany w naszym sklepie, w sensie w budowie naszych sklepów czy tam funkcjonalności, albo pojawiają się nowe produkty i my musimy przetestować czy to wszystko działa razem jako testerzy.
Czy możesz nam powiedzieć coś więcej na temat tych zadań, które otrzymujecie z pierwszego źródła, mianowicie z tego co zrozumiałem od programistów? Pewnie dokończyli jakiś feature albo coś przygotowali dla ciebie, jak to później wygląda w twojej pracy?
Najpierw sprawdzamy to na środowiskach testowych i potem jeszcze na produkcji, jak to już zostanie zdeployowane na produkcję, to sprawdzamy tam, tam już są bardziej pobieżne te testy, bo na środowisku testowym mamy większe pole do popisu. Możemy nasze tam gry z naszego sklepu, możemy je modyfikować trochę, możemy sobie dodawać punkty, zabierać i tak dalej, co jest niemożliwe na produkcji oczywiście, bo to by zaburzyło równowagę, jaka istnieje właśnie w tym środowisku produkcyjnym i gracze mogliby odczuć to na swojej skórze, a tego nie chcemy. Można powiedzieć, że to są smoke testy takie na tej produkcji.
A co z drugim źródłem zadań, mianowicie tutaj z tego, co rozumiem, dostajecie jakieś zgłoszenia już od użytkowników końcowych, tak?
Tak i często jest tak, że osoby z helpdesku sprawdzają to jeszcze, czasem zdarza się, że jednak nie, ale tak czy owak niezależnie od tego my to jako testerzy sprawdzamy, próbujemy odtworzyć sytuację, w której doszło do wystąpienia błędu.
Czy możesz podać jakiś konkretny scenariusz, jak to wygląda?
Jasne, na przykład użytkownik z Tanzanii pisze, że gra na telefonie i w grze Abecadło, powiedzmy, dostaje za mało punktów w stosunku do tego, co jest opisane w instrukcji. No i wtedy za pomocą VNP-u łączymy się właśnie z Tanzanią i przez Tanzanię próbujemy wejść do naszego sklepu, uruchomić tą samą grę i odtworzyć sytuację, w której doszło do tego błędu po prostu i jeśli to się udaje, to sprawdzamy, najczęściej to sprawdzamy jeszcze w konsoli jakieś tam, czy wychodzą tam jakieś błędy w naszej aplikacji takiej administracyjnej dodatkowo i z tym zestawem danych, czasem też ze screenshotami, tudzież z nagraniem tej całej sytuacji, w sensie nagrywamy to, co się dzieje w okienku przeglądarki, zakładamy ticket na Jirze i potem dajemy to product ownerom czy product menadżerom, którzy rozdzielają to zadanie, przydzielają danemu programiście, żeby to naprawił.
A na jakich środowiskach sprawdzacie błędy?
Na produkcji. Produkcja i środowisko testowe są troszeczkę inaczej skonfigurowane, bo środowisko testowe siłą rzeczy, one są cały czas w ciągłej zmianie można powiedzieć, tam cały czas dogrywane są nowe rzeczy, jest wiele teamów, które korzysta z tego samego środowiska, więc tam to jest wszystko bardzo płynne. A produkcja jest o wiele bardziej stabilna, plus dokładnie odwzorowuje sytuację, jeśli chodzi o wszystkie ustawienia, która miała miejsce w momencie wystąpienia tego błędu, który został do nas przesłany. Przede wszystkim właśnie sprawdzamy tam, potem jeszcze czasem na środowisku testowym też, żeby się upewnić czy właśnie ten błąd nie został w międzyczasie na przykład naprawiony na środowisku testowym albo czy tam są jakieś inne ustawienia, które mogły wpłynąć po prostu na wystąpienie tego błędu.
Z jakich technologii korzystasz na co dzień, jakich aplikacji używasz, które ułatwiają ci pracę?
Ja już pracuję 8 lat jako tester, więc tych aplikacji było dużo różnych, ale niektóre się powtarzają. Opowiem właśnie o tych takich, które najczęściej przewijały się w czasie mojej kariery testera. Więc podstawowym narzędziem jest Jira. Jest to webowa aplikacja, która pomaga nie tylko zarządzać całą pracą zespołu, ale też pozwala właśnie tworzyć tickety dla błędów, które znajdujemy, czy właśnie tworzyć zadania dla zespołu i tak dalej, i tak dalej. Tam też można zarządzać testami automatycznymi, w jednej z poprzednich firm to robiliśmy i wbijać też scenariusze testowe. Tego akurat tutaj nie stosuję, ale jest taka możliwość, więc generalnie Jira ma wielkie możliwości i polecam. Świadomość Jiry to jest jedna z podstawowych rzeczy dla testerów. Jakieś narzędzie do obsługi bazy danych, obecnie korzystam z SQL, tudzież po polsku SQL DBeaver’a, ale to może być tam dowolne inne, po prostu żeby można było odczytać, co się dzieje w bazie danych, a jeśli produkt tego wymaga, ewentualnie tam edytować co się dzieje. Poza tym korzystamy jeszcze z Postman’a, który służy nam do wstrzykiwania danych, na przykład do tworzenia użytkowników, do szybkiej edycji użytkowników, takiej masowej edycji gier na naszej platformie za pomocą calli rozmaitych w JavaScripcie pisanych.
A czy piszesz też jakieś testy automatyczne?
W mojej obecnej firmie używany jest Cypress z JavaScriptem. Ja z tym narzędziem nie miałem jeszcze do czynienia, więc uczę się tego. Zrobiłem jeden kurs na Udemy, ale parę lat temu u jednego pracodawcy byłem jednoosobowym właśnie zespołem testerskim i tam miałem wolną rękę, jak miałem wolny czas mogłem sobie robić, co chciałem, więc nauczyłem się trochę Pythona i właśnie pisałem testy w Selenium z Pythonem. Tam jeden programista pomagał mi podłączyć to pod Continuous Integration, czyli te testy były puszczane automatycznie i jakoś to szło, moim zdaniem całkiem spoko. Podobało mi się.
Tak, bo to jest całkiem satysfakcjonująca praca, zwłaszcza, jak widzisz, że przechodzi.
Tak, absolutnie, ale jak nie przechodzi, bardzo lubię też dłubać w kodzie. Może jak kiedyś znajdę czas i energię, żeby się nauczyć właśnie programowania to może pójdę bardziej w tę stronę, na razie nie mam takich możliwości, kto wie, zobaczymy.
Polecam. Czy na co dzień bardzo ściśle współpracujecie z zespołem programistów?
Praktycznie cały czas. Jest bardzo dużo interakcji i dlatego jedną z podstawowych takich umiejętności testerskich, jeśli chodzi o umiejętności miękkie, to jest zdolność komunikacji. Już nie chodzi tylko o, przede wszystkim chodzi o komunikowanie tych błędów. Nie można powiedzieć “Ej, stary, co tu odwaliłeś, kurczę, to jest takie no, bez brzydkich wyrazów, ale to jest tragedia co tu zrobiłeś”, tylko mówimy “O, patrz, tutaj wymagania są takie i takie, a to nie działa”. Błędy komunikujemy też za pomocą komunikatora czy na callach, zarówno tak samo, jak na Jirze na przykład w ticketach w komentarzach. Plus programiści często pomagają nam ustawić jakieś rzeczy w aplikacji na środowisku testowym, których sami nie jesteśmy w stanie, czy z racji braku pozwoleń czy umiejętności, więc ta współpraca jest codziennością po prostu.
Czy miałeś kiedyś taką historię, że widziałeś coś, co zostało błędnie zaimplementowane, a programista nie chciał się z tobą zgodzić, mówi “Gościu, ty się nie znasz, jak to przetestowałeś”?
Tak, o kurczę, i to ile razy. Wtedy pierwsza instancja, do której się odwołuję, to wymagania. Zależnie od firmy one są w różnych miejscach, w sensie albo w dokumentacji, w jakich dokumentach, albo w Jirze w ticketach, tam acceptance criteria. No i jeśli tam jest to na tyle jasno opisane, to po prostu pokazuję, patrz, tu jest napisane, że ten przycisk ma mnie przenosić do tego okienka. Tak się nie dzieje, więc to jest źle. Plus pokazuję, jeśli pracujemy tak, jak teraz pracuję zdalnie, to wiadomo, no to mogę przesłać jeszcze screenshot, mogę nagrać filmik albo zrobić calla z tą osobą i udowodnić, że jest źle. Jeśli jednak na przykład wymaganie nie są wystarczająco jasne, to wtedy odwołuję się zwykle do instancji wyższej pod tytułem product menadżer, product owner i wtedy proszę tę osobę, żeby rozsądziła w takiej sytuacji i zwykle ja mam rację.
Faktycznie, czasami się zdarza tak, że ja zrozumiem inaczej niż chciał product owner albo w ogóle zrozumiał też tester, także to różnie bywa.
Jasne, to nie jest kwestia złej woli czy że ktoś jest bucem, absolutnie, chociaż zdarza się, owszem, zdarza się, ale no najczęściej to jest właśnie kwestia różnego zrozumienia danego wymagania.
Czy lubisz swoją pracę?
Tak, bardzo lubię swoją pracę, szczególnie teraz, jak pracuję przy grach online, bo ja bardzo lubię gry. Podobno w tej branży mogą pracować tylko ludzie, którzy właśnie mają jakieś doświadczenie albo sympatię po prostu do tego medium.
To prawda, mieliśmy ostatnio okazję rozmawiać z osobą, przedstawicielem GameDev’u i właśnie wspominał o tym, że żeby pracować w tej branży trzeba lubić gry.
Tak, to są trochę inne gry niż te, w które gram na co dzień, ale no to jest po prostu, to są ciągle gry, polega na tym, żeby wciągnąć gracza i żeby były interaktywne i coś tam ciekawego się działo, prawda. Czasem zdarza się tak, że nawet jak mam przetestowane to, co chciałem zrobić, to zostaję trochę dłużej, bo chcę zobaczyć na przykład jak działa jakaś mechanika albo co się dalej wydarzy, bo lubię właśnie, tak jak mówiłem, lubię bardzo to medium.
Czy zdarza ci się tak, że musisz jeden scenariusz konkretny, albo jedną jakąś misję przechodzić wiele razy?
Teraz już mniej, bo ja głównie zajmuję się od strony tego sklepu naszego z grami. W poprzedniej firmie zajmowałem się tworzeniem tych gier i wtedy tak, wtedy musiałem rozmaite scenariusze powtarzać, w różnych jakby ustawieniach zewnętrznych, czy tam, dajmy na to, na różnych, znaczy teraz też muszę na różnych urządzeniach to przetestować, ale przy różnych ustawieniach po prostu tam tej przeglądarki.
To nie było nudne?
Nie, to jest fajne, ja lubię to bardzo. Wiadomo, jest skończona ilość razy, ilość tych podejść, zanim zacznie to być nudne, ale tak kilka to nie ma problemu dla mnie.
Prawdziwy gracz z krwi kości. Wiadomo. Cenię.
Dziękuję. Plus wyszukiwanie błędów jest spoko, no bo też to przypomina grę w tą, nie wiem jaka jest jakby oficjalna nazwa tego rodzaju gier, ale wyszukiwanie tych różnych ukrytych przedmiotów, że masz na przykład kurczę szafę pełną ciuchów i masz listę rzeczy, które musisz wykryć i musisz to klikać. To testowanie trochę na tym polega. Plus, nie wiem, nawiązanie do klasyki gier jest trochę jak incredible machine, że tam próbuje się różnych połączeń, żeby zobaczyć czy to się nie zepsuje, na przykład sprawdzanie, to już wspominałem o tym, że użytkownik z Tanzanii, czy użytkownik z Tanzanii ma dostęp do tych samych gier co użytkownik z Anglii na przykład i to jest ciekawe dla mnie.
Gdybym teraz chciał zostać testerem, co byś mi doradził, czego powinienem się nauczyć? Zakładając, że nie jestem jeszcze programistą, w sensie skończyłem dopiero studia, szukam swojej pierwszej pracy.
Tak, tak, więc zacząłbym od języka angielskiego, język angielski to jest absolutna podstawa pracy w IT chyba generalnie, myślę, że bez tego, na trochę wyższym poziomie niż komunikatywny, żeby można było rozumieć to, czego się od nas chce i przekazać jakieś swoje myśli, to to jest absolutna podstawa. Bez tego nie ma co próbować w ogóle szukać szczęścia na rynku pracy IT. Dobrze jest poznać trochę teorii testów na temat rodzajów, na temat workflow testerskiego, plus metodologie zwinne, które są bardzo często używane, czyli Scrum. Scrum jest też najczęściej spotykaną metodologią, przynajmniej w moim życiu, zwykle nie w czystej postaci, ale jednak, więc warto znać, jakie tam są ceremonie, jaki jest workflow i jak to działa. Poza tym SQL to jest ważna rzecz. Bardzo często, praktycznie w każdej pracy sprawdzam coś na bazie danych, często też musiałem coś tam zmieniać, więc to. Jira jest bardzo prosta w obsłudze, więc można też jakiś szybki tutorial obejrzeć. I to są podstawowe rzeczy.
A coś takiego jak ISTQB?
Powiem tak, dla mnie ISTQB jest dość kontrowersyjnym tematem, bo jakkolwiek wiedza, która tam jest, jest bardzo użyteczna, przedstawia właśnie nie tylko rodzaje i teorie testowania, ale podane jest to w sposób bardzo zawiły i bardzo taki, kojarzy mi się z jakimiś teoretykami kultury, typu, nie wiem, Derridą, na przykład, który bardzo proste koncepty omawia bezsensownie dużą ilością słów i to sprawia, że zamiast się uczyć tego, musimy wklepać to na pamięć, żeby zdać ten egzamin. To jest dla mnie bez sensu, jakby nie wiem czemu ma to służyć. Podobno to zostało w ostatnich latach trochę poprawione w nowych wydaniach tych testów, ale kiedy ja zdawałem to trzeba było wykuć definicję na pamięć i dopiero przystąpić do tego testu, a potem okazuje się, że to wszystko można było przedstawić o wiele prościej więc spoko, ale z gwiazdką.
A ten certyfikat był wymagany od ciebie?
Tak, w niektórych sytuacjach, kiedy ubiegałem się o pracę ten certyfikat właśnie sprawił, że rekruterzy przychylniej patrzyli na mnie, a także skracało proces rekrutacyjny. No bo to jest dowód na to, że mam jakiś tam zakres danych, ale ja go robiłem z inicjatywy pracodawcy, bo pracowałem w kontraktorni, która chciała mnie sprzedać do klienta, żebym tam u niego pracował i to był taki żeton przetargowy, że tak powiem, czyli o, patrzcie, tu mamy gościa z certyfikatem, więc dawajcie nam więcej pieniędzy. To było generalnie w tamtym momencie to było dla mojego pracodawcy, dla tej kontraktorni, a teraz trochę ułatwia życie w sytuacji rekrutacyjnej. Osoba, która ma dłuższe doświadczenie, parę lat, to i tak ma tę wiedzę siłą rzeczy po prostu poprzez praktykę, więc moim zdaniem to nie jest super niezbędne, ale no świadczy o czymś tam.
Twoim zdaniem, jakie cechy powinien mieć dobry tester?
Dobry tester powinien mieć tak zwane oko do detali, że powinien zauważać jakieś tam drobne zmiany, że dajmy na to kursor podskakuje po najechaniu na jakieś pole albo że ikona się przebarwia na zły kolor. To po pierwsze. Po drugie musi być w stanie się skupić przy czytaniu dokumentacji. To było dla mnie bardzo trudne i dużo czasu mi zajęło, aż tę umiejętność posiadłem, żeby właśnie skupić się na dokumentacji, wyczaić co jest tam najbardziej istotne i właśnie, i potem do tego się odnosić w swojej pracy. Po trzecie zdolność do komunikacji. To już wspominałem, że ciągle współpracuje się z programistami i trzeba umieć im przekazywać swoje uwagi do funkcjonowania aplikacji czy programów, cierpliwość oczywiście, bo niektóre rzeczy wymagają wielokrotnych testów, więc trzeba być cierpliwym co do tego, a także odwagi, bo przydaje się to w testach eksploracyjnych, kiedy nie robimy czegoś wedle scenariusza testowego, ale po prostu wpadamy na pomysł “A co by było, jeśli otworzymy 10 okienek naraz” albo “Co, jeśli w tym polu, gdzie wpiszemy imię i nazwisko, wpiszemy same liczby, albo próbujemy wkleić obrazek, co się stanie”. I to jest bardzo przydatne, bo pozwala właśnie znaleźć błędy, których nikt się nie spodziewał, a to jest bardzo istotne dla jakości produktu.
Co jest najbardziej satysfakcjonujące w twojej pracy?
Zależy od miejsca, w którym się pracuje. Czasami są po prostu sytuacje, że produkuje się coś dla na przykład, była sytuacja, przez niecały rok pracowałem w banku i robiłem aplikację, której używali potem finansiści gdzieś tam w Stanach, i oni nie pisali mi po tym maili “Ej, super sprawa, fajnie, że to przetestowałeś, to działa, ekstra, wysoka piątka” ale wcześniej pracowałem w sklepie sprzedającym e-booki, audiobooki i ten sklep miał swoją aplikację na Google Play i App Store i tam było widać oceny użytkowników. No i użytkownicy, jeśli coś im się nie podobało, że na przykład coś nie działało, że kupowali e-booka, ale potem im nie przechodził, albo dostawali inny, no to wiadomo, mieli pretensje i wystawiali niższe oceny. I właśnie obserwowanie jak ta ocena rośnie na przykład wraz z jakością aplikacji, to było super satysfakcjonujące. Więc pozytywny feedback, najchętniej od klientów końcowych, to jest super rzecz. To myślę, że to jest dla mnie największy motywator i w pracach, kiedy nie miałem tego, to bardzo mi brakowało, bo nie czułem właśnie takiego, nie miałem tego poczucia zakończenia czegoś czy właśnie progresu, czy czegokolwiek. Właśnie takiego feedbacku po prostu do swojej pracy i cieszy mnie, jak znajdę taki nieoczywisty błąd właśnie, bo jeśli tam coś prostego się wykrzaczy, to jest błąd, okej, spoko, ale jak znajdę coś, o czym nikt nie pomyślał. W tej samej pracy, czyli w tym sklepie z e-bookami znalazłem zupełnie przez przypadek taką rzecz, że tam była promocja, która przy zakupie książki dawała ci zniżkę ileś tam procent i za każdą książkę ta zniżka się kumulowała i zauważyłem, że nie trzeba kupować tej książki, trzeba ją wsadzić do koszyka i przejść jeden krok i ta zniżka już się naliczała i akumulowała. I to tak nie powinno być oczywiście, więc z tego byłem dumny, tu muszę powiedzieć, byłem dumny.
Właśnie tak chciałem zaproponować, że co się stanie, jak wrzucisz coś do koszyka, wyrzucisz, wrzucisz, wyrzucisz, wrzucisz, wyrzucisz i właśnie takie testy mnie najbardziej rozwalają, kiedy przychodzi do mnie QA i mówi “Słuchaj, dodałem coś pięć razy, usunąłem pięć razy, zmieniłem nazwę, usunąłem, poprawiłem, nie działa”.
No a tak jest.
Taki scenariusz istnieje.
Jasne, że właśnie to jest super, bo właśnie tego typu testy, bo umówmy się, ludzie nie są racjonalni, to jest podejście, ludzie nie są maszyną, która kurcze o, muszę kupić tam, nie wiem, mydło w sklepie online, no to wchodzę, szukam mydło, wybieram pierwsze z brzegu. Tylko wchodzą, sprawdzają kilka, wrzucą do koszyka, potem zobaczą, że coś jest w mniejszej cenie albo to mydło jest o lepszym zapachu i to wyrzucą, zmienią i tak dalej, kupią parę dla rodziny, a potem się rozmyślą i tak dalej.
Zostawią coś w koszyku na jeden dzień, wrócą jutro.
Tak, a w międzyczasie prąd im wyłączą i kurcze nie wiadomo, co się wydarzy. I nie wiadomo jak aplikacja na to zareaguje.
Bardzo ciekawe. Dobrze, a w takim razie powiedz mi czy uważasz, że twoja praca jest stresująca albo jak reagujesz na sytuację, kiedy coś przeszło przez twoje ręce, przetestowałeś, dałeś zielone światło, mówisz, uważasz, że działa, ale jednak później okazuje się na powiedzmy wyższym środowisku, albo później wraca właśnie do ciebie coś z informacją, że o, jednak się coś zepsuło?
Znaczy to jest dla mnie stresujące tylko w sytuacji, jeśli ja popełnię błąd na tej zasadzie, że zignoruję coś, i pominę przy testowaniu, że to będzie “A, to działało tam miesiąc temu, teraz na pewno będzie dobrze”, to to jest mój błąd i to jest dla mnie źródło stresu, bo to znaczy, że ja zaniedbałem po prostu swoje obowiązki, ale jeśli się okaże, że coś, że wszystko, coś, co przetestowałem potem się wywali, wywala u klientów, no to nie mam do siebie pretensji, bo ja to sprawdzałem, u mnie działało.
Jest, pojawiło się to. 😆
Musi. No po prostu tak wyszło. Może coś tam, ustawienia u klientów są inne czy w międzyczasie coś się innego jeszcze zmieniło w całym systemie i tak dalej, i tak dalej no i wtedy, wiadomo, no lipa, że kurczę trzeba to łatać, ten produkt, nad którym pracowaliśmy jakiś tam czas, ale to nie jest źródło stresów. W ogóle, jeśli chodzi o temat stresu to z wiekiem, w sensie z doświadczeniem, nie tyle z wiekiem, przestałem się tym męczyć, bo to jest po prostu praca, nie. Jak okazuje się, że mamy za dużo pracy, a czasu za mało, to nie jest zwykle wina testerów czy programistów, czy kogokolwiek, tylko kwestia złego zarządzania. Nie będę się przejmował, że ktoś coś źle zaplanował, trudno.
Dojrzałe podejście.
Staram się, staram się.
Czy spotkałeś się kiedyś z taką opinią, że testy to nie jest żadna wartość dodatnia dla klienta?
Tylko w jakichś artykułach w Internecie, które mówią “Ej, słuchajcie, testowanie jest istotne, niektórzy myślą, że nie”, ale w praktyce, w życiu takim zawodowym codziennym, to od kiedy pamiętam nigdy nie było takiej kwestii, okej, czasem brakło czasu na testowanie, ale to nie było wynikiem jakiegoś lekceważącego stosunku do właśnie naszej pracy, tylko po prostu złym planowaniem i też drugi taki połączony z tym stereotyp jest to że programiści mają jakąś wielką kosę z testerami, że się nienawidzimy.
Pewnie, że tak. 😆
Aha, to nie wiedziałem, to my przynajmniej nie mamy z wami.
Tak naprawdę ja uwielbiam swój zespół QA-owy, pozdrawiam bardzo serdecznie, mam nadzieję, że mnie oglądają, bardzo mi się dobrze współpracuje z QA, bo faktycznie to jest tak, jak już wspominałeś tutaj wielokrotnie, mamy sytuację, kiedy ja myślę tylko o pozytywnym scenariuszu, nie przebadam po prostu wszystkiego, a mój zespół wszystko wybada, wszystko znajdzie, także wspaniała współpraca.
No, no, tak samo to nie jest tak, że testerzy nienawidzą programistów, “A, kurcze, znajdziemy, dorwiemy tego typa, kurcze na pewno gdzieś się walnął”.
Przeklikam ci wszystko, bo gdzieś musiałeś popełnić błąd.
Będziesz siedział w weekend. Cały zespół, nie tylko programiści i testerzy, jeśli chodzi o zespół IT, mamy jeden cel, może nie w życiu, ale w pracy i jest to wysoka jakość produktu, więc po co, więc jakieś tam konflikty są bez sensu zupełnie.
Czy uważasz, że zawód testera jest dla każdego? Każdy by się w tym sprawdził?
Nie, absolutnie nie. Osoby, które mają problemy z komunikowaniem, z komunikacją i nie potrafią w taki bezkonfliktowy sposób przekazywać swoje uwagi czy wiedzę to zupełnie się nie nadają, osoby, które mają lęk przed komputerami, a są takie i dla nich po prostu takie eksplorowanie w ogóle aplikacji czy próbowanie jakichś tam nowych opcji, których nie stosowali to jest prawie że traumatyczne doświadczenie, to nie ma szans i osoby które właśnie nie są cierpliwe, nie są gotowe kilka razy robić tego samego, czy nawet kilkanaście razy, też się nie nadają do tego, bo albo się znudzą, albo po prostu będą nieszczęśliwe w tej pracy.
Czy na swoim stanowisku rozwijasz się, masz jakieś opcje rozwoju?
Tak, takie dwie, które przychodzą mi do głowy to takie główne, wybierane przez większość testerów, to jest albo zmiana roli trochę, głównie na menadżerską, albo na rolę analityka biznesowego, to są najczęstsze przypadki z mojego doświadczenia, albo pójście w stronę bardziej techniczną, czyli zwykle to są testy automatyczne, albo zostanie programistą i w moim przypadku, nie wiem, czy to kogoś interesuje, ale…
Pewnie, że tak.
Ale ja osobiście chciałbym zostać testerem automatycznym, bo testerem manualnym jestem już jakieś 8 lat i dalej sprawia mi to przyjemność, ale chciałbym właśnie trochę pobawić się automatami, w mojej obecnej pracy to byłby Cypress z JavaScriptem. Tak jak wspominałem wcześniej, tak samodzielnie tworzyłem testy automatyczne w jednej pracy, ale chciałbym to robić bardziej w strukturach wielkiej firmy, żeby poprzez współpracę z innymi testerami automatycznymi, poznać te wszystkie dobre praktyki. Bodajże przez Nokia albo Microsoft, nie pamiętam, darmowa konferencja, podczas której można nie tylko spotkać ludzi, ale też oczywiście nauczyć się różnych rzeczy, posłuchać ciekawych prelegentów, są konferencje płatne w całej Europie.
Czy z racji tego, że bardzo dużo testujesz, zdarza ci się czasami otworzyć obcy produkt i szukać tam błędów?
Tak, tak, też ja to u siebie widzę najczęściej w grach wideo i próbuję robić różne rzeczy, na przykład przechodzić różnymi ścieżkami, albo próbować wejść w ścianę i zobaczyć, czy przejdę przez nią, więc tak, w takich aplikacjach codziennych też próbuję tam przeciągać różne rzeczy, próbuję bawić się też devtoolsami, czyli tym takim narzędziem, który jest wbudowany w przeglądarki i właśnie i tam zmieniać różne rzeczy, szczególnie, jak są jakieś paywalla albo coś takiego, czasem się uda wyłączyć, więc takie to jest też powiązane, bo trochę używamy właśnie devtoolsów do wyszukiwania błędów w konsoli najczęściej i jakieś tam tego typu sytuacje, więc tak, tak, wykorzystuję sobie testerskie supermoce na co dzień.
Dziękujemy Szymonie, fajnie, że zgodziłeś się nas odwiedzić i opowiedzieć tutaj o roli testera manualnego. Tak jak wspominałem na początku, testowanie to jest bardzo mi bliski temat, także fajnie było poznać tą twoją perspektywę.
Dziękuję bardzo za zaproszenie, było mi bardzo miło.
Dziękuję też wam, że byliście z nami. Mam nadzieję, że odcinek wam się podobał, jak zwykle zachęcam do pozostawienia subskrypcji, lajków, komentarzy i widzimy się już za dwa tygodnie!
________________________________________________________
Podcast DEVision to polski podcast IT dla programistów, którzy chcą rozwijać swoją wiedzę, posłuchać o ciekawych projektach oraz zainspirować się innymi. A to wszystko w przyjemnej formie rozmowy, której możesz słuchać w tramwaju, na siłowni, a nawet w pracy 😉
💌 Zapisz się do naszego newslettera: https://bit.ly/37TTNCK
🌏 Więcej o nas przeczytasz na stronie: https://bit.ly/3Pttiox
Obserwuj nas na social media: 🚀
LinkedIn: https://bit.ly/3PxlHFQ
🎧 Spotify: https://spoti.fi/39xU0fm
🎧 iTunes: https://apple.co/3PsjhrQ
Jeśli Ci się temat spodobał, subskrybuj nasz kanał, bo dopiero się rozkręcamy z gorącymi tematami! 🙂
