To jest 14 odcinek podcastu „Porozmawiajmy o IT”, w którym z moim gościem rozmawiam o zawodzie testera oprogramowania. Z tego odcinka dowiesz się: jakie obowiązki sprawuje tester, czy musi mieć specjalne cechy charakteru, czy wymagane jest, by znał się na oprogramowaniu i na czym polega automatyzacja testów. Bardzo ciekawa rozmowa z doświadczonym testerem, pracującym na co dzień w międzynarodowych firmach. Jeśli pracujesz jako tester lub myślisz o pokierowaniu swojej kariery zawodowej w tym kierunku to jest odcinek właśnie dla Ciebie. Zapraszam Cię zatem do wysłuchania.

Witam Cię serdecznie w Porozmawiajmy o IT. Ja się nazywam Krzysztof Kempiński i w tym podcaście rozmawiam z moimi gośćmi o branży informatycznej. Przedstawiam trendy, zjawiska i opinie. Staram się przybliżyć tę branżę tym, których w niej na co dzień nie ma, jak również zaciekawić stałych bywalców. Pozostań z nami, a teraz zapraszam już na kolejny odcinek.

Krzysztof: Cześć. Dzisiaj moim i Waszym gościem jest doświadczony tester oprogramowania, pracujący w wielu międzynarodowych start-up’ach. W przeszłości współtworzył software house specjalizujący się w Rubion Race, gdzie jego przygoda z testowaniem się rozpoczęła. Pracował później jako tester w wielu poznańskich przedsięwzięciach. Prowadził firmę zajmującą się wydawaniem aplikacji na platformę iOS. Ma szerokie doświadczenie w branży IT, z nastawieniem na testowanie. Dzisiaj moim i Waszym gościem jest Jacek Norbert. Cześć Jacek! Bardzo się cieszę, że przyjąłeś zaproszenie do podcastu.

Jacek: Cześć! Witaj! Dziękuje bardzo za zaproszenie. Miło mi.

Krzysztof: Mi też jest bardzo miło. I na początku takie standardowe wprowadzające i rozluźniające pytanie: czy słuchasz podcastów i jeśli tak, to jakich najczęściej?

Jacek: Przyznam szczerze, że do tej pory, po za Twoim nie miałem okazji słuchać. Natomiast nie ukrywam, że coraz więcej ciekawych podcastów się pojawia i na pewno jest to coś co, co warto robić.

Krzysztof: Zgadza się, faktycznie scena podcastingu w Polsce rośnie i to bardzo cieszy. Super. Jacek, masz szerokie doświadczenie, jeśli chodzi o testowanie oprogramowania i właśnie dzisiaj zawód tester oprogramowania będzie tematem naszej rozmowy. Zatem zacznijmy od takiego pytania. Jakie cechy charakteru i osobowości musi mieć tester?

Jacek: Myślę, że takimi podstawowymi cechami to jest przede wszystkim zdrowy pesymizm, czyli takie zdrowe podejście do testowania i takie pesymistyczne, czyli bardziej nastawienie, że coś może jednak nie działać, pomimo tego, że wielu programistów będzie próbowało testera przekonać, że coś działa. Cierpliwość – często trzeba na pewno cierpliwie tłumaczyć programistom czy innym członkom zespołu co jest błędem, w jaki sposób mogą go zreplikować. Na pewno komunikatywność. Dobry tester powinien wiedzieć, w jaki sposób przekazać niekiedy informację o tym, że coś złego dzieje się w testowanej aplikacji. Dobry tester musi tez dbać na pewno o relację z pozostałymi członkami zespołu. Myślę, że chęć uczenia się nowych rzeczy – to jest tak jak praktycznie w każdym zawodzie. Tak samo rozwój w zawodzie testera nigdy się nie kończy. Cały czas pojawiają się nowinki, nowe narzędzia, nowe techniki testowania, także na pewno jest to ważna cecha. Myślę też, że dokładność z racji wykonywanego zawodu, dużą wagę przykłada się też do dokładności, do szczegółów i myślę, że wykształcenie i hobby też jest czymś ważnym, bo trzeba się rozwijać we wszystkim i dobrze jest, jeśli tester ma jakieś wykształcenie informatyczne. Myślę, że również asertywność niekiedy bardzo się przydaje, ponieważ często próbuje się, tak jak już wspomniałem na początku, przekonać testera, że coś nie jest błędem, a ewidentnie jest. Wówczas asertywność bardzo się przydaje.

Krzysztof: Dzięki za tę odpowiedź. Tak jak wiemy, całe szczęście, programiści piszą testy, tak zwane JUnit testy do kodu, który jest przez nich pisany. Zatem czy tutaj są nadal potrzebni testerzy, skoro programiści już ogarniają testy?

Jacek: Myślę, że zdecydowanie tak. Oczywiście rola testera będzie się zmieniać. Zresztą widzimy to już od kilku lat. Jeszcze kilka lat temu rolą takiej osoby było klikanie aplikacji i potwierdzenie, że spełnia ona wymagania klienta. Myślę, że dziś rynek bardziej niż testerów poszukuje Quality Assurance specjalistów, czyli osoby, która jest kimś więcej niż tylko testerem. Jest osobą, która zadba o procesy jakościowe w cyklu wytwarzania oprogramowania od etapu zbierania wymagań po proces diplojowania aplikacji na środowisko produkcyjne. Oczywiście testy pisane przez programistów to bardzo ważny aspekt tworzenia jakości w projekcie. Pamiętajmy jednak, że programiści najczęściej pokrywają testami funkcjonalności czy też klasy, których są autorami, natomiast testerzy patrzą w kontekście jakości zawsze na cały projekt. Nie mogą patrzeć tylko na jakiś wycinek stąd, moim zdaniem, ich rola zawsze będzie istotna.

Krzysztof: Wspomniałeś przed chwilą o tym testowaniu manualnym i o tym, że rola testera na przestrzeni kilku lat, zgodnie z Twoją obserwacją, się zmienia. W związku z tym moje pytanie jest: czy tester testuje tylko manualnie czy może też jego działania jeszcze idą w jakimś innym kierunku?

Jacek: W dużej mierze tak, ale oczywiście jest to tylko część jego pracy, gdyż tester używa w swojej pracy wiele narzędzi, które pomagają mu na weryfikację różnych aspektów testowanej aplikacji, jak funkcjonalność, wydajność bądź interfejs użytkownika. Z mojego doświadczenia wynika, że opłacalne jest automatyzowanie często powtarzanych zadań, ponieważ w tej sposób otrzymamy szybki feedback na temat testowanego oprogramowania i tego czy, na przykład możemy w danej chwili zrobić wydanie na produkcji bądź nie.

Krzysztof: Wspomnieliśmy tutaj przez chwilę o automatyzacji, do której jeszcze wrócimy. Jak gdyby elementem tej automatyzacji jest fakt, że testerzy piszą swoje testy, wręcz programują je, prawda? O tym sobie jeszcze za chwilę powiemy. Moje pytanie jest na początku takie: skoro tester też pisze testy to na ile musi umieć programować?

Jacek: Dobrze jest, jeśli tester zna choć podstawy języka, w którym pisze testy. To z pewnością ułatwi mu to zadanie. Dzięki temu będzie mu łatwiej pisać testy oraz przede wszystkim je utrzymywać. Myślę, że zrozumienie architektury frameworka testowego pozwoli na stosowanie dobrych praktyk. Znajomość języka oprogramowania umożliwia również pisanie własnych narzędzi oraz daje pogląd na czym polega praca programisty. Myślę, że dzięki temu tester jest bardziej świadomy wiedząc z czym związane jest oprogramowanie i jakiego rodzaju błędy można popełnić pisząc kod.

Krzysztof: Rola testera po angielsku to QA, czyli Quality Assurance, ale często też ten akronim rozwija się w trzech takich wersjach jako Quality Analytics, Asssurer i Quality Ambassador. Moje pytanie jest takie: czy tester robi coś jeszcze by zapewnić i utrzymać jakość kodu oprócz pisania, testów i manualnego testowania. Czy ma jakieś inne, dodatkowe obowiązki.

Jacek: Myślę, że generalnie Quality Assurance to szeroko pojęte zapewnienie jakości oprogramowania i rolą takiej osoby jest wykrywania błędów w celu ich usunięcia, sprawdzenie zgodności aplikacji z innymi aplikacjami, także ułatwienie interesariuszom podjęcia decyzji o wypuszczeniu bądź niewypuszczaniu danego produktu, jak również minimalizacja kosztów pomocy technicznej, jak i kontrola zgodności tworzonego oprogramowania z wieloma wymaganiami. Także myślę, że wszystko to zamyka się w tych trzech pojęciach, które wymieniłeś.

Krzysztof: Zgadza się. Wydaje mi się, że polskie określenie tester nie do końca tutaj oddaje w pełni rolę, pełen zakres obowiązków, który jakby spoczywa na takiej osobie, bo tester bardziej, przynajmniej mi, się kojarzy z osobą, która faktycznie manualnie coś tam sprawdza, natomiast szeroko rozumiane, tak jak to opowiedziałeś, zapewnienie jakości to już jest szerszy zakres działań i ta  faktycznie, z mojej obserwacji, wynika, że ta rola testera z biegiem lat rośnie, umacnia się i coraz więcej obowiązków mu tutaj przybywa. Moje pytanie jest takie: wspomniałeś na początku, że dobrze by było, gdyby tester znał jakieś podstawy przynajmniej języka programowania. A na ile dobrze musi znać cały projekt, jego wymagania funkcjonalne i biznesowe, żeby móc go testować?

Jacek: Oczywiście wszystko zależy od tego, od kontekstu, czyli z jakim projektem mamy do czynienia, w jakiego typu organizacji. Czasami zdarzy się, że tester musi przetestować jakąś aplikacje bądź moduł w aplikacji, do którego nie ma dokumentacji, wtedy musi się oprzeć tylko na własnym doświadczeniu i tym co mu intuicja podpowiada, a intuicja w testowaniu jest bardzo istotnym aspektem. Ale oczywiście, jeśli pracujemy nad jakaś aplikacja w zespole, przez dłuższy okres czasu i jest stworzona do niego dokumentacja, jakakolwiek by ona nie była to oczywiście im lepiej tester jest zaznajomiony z dokumentacją, im lepiej zrozumie jak dane moduły funkcjonalności działają, tym lepiej będzie mógł oczywiście testować daną aplikację, ponieważ będzie miał rozeznanie na temat różnorakich zależności, które w tej aplikacji występują. Jest to bardzo ważny aspekt, no i kluczowy przy testowaniu.

Krzysztof: Jasna sprawa. Na pytanie o cechach osobowości testera wspomniałeś, że asertywność jest jedną z takich istotnych cech, walorów testera. Zastanawiam się na ile tester powinien przymykać oko na pewne niedociągnięcia i zapewnienia programistów, że będzie działać, albo że jest trudne do zrobienia i po prostu zbyt czasochłonne. Gdzie tutaj leży ta granica, ta bariera pomiędzy byciem bardzo stricte takim, który faktycznie wymaga i żąda, a takim, który przymyka oko?

Jacek: Również generalnie wszystko zależy od kontekstu tak naprawdę. Idealnie jeśli tester nigdy nie przymyka oka i zawsze jest w stanie zweryfikować to co programista wykona. Natomiast czasem zdarzają się sytuacje, że czegoś nie jesteśmy w stanie przetestować, bo na przykład, nie mamy odpowiedniego środowiska, jakiś danych czy też możliwości i czasami pewne rzeczy zostawia się klientowi do przetestowania, natomiast trzeba to w jakiś sposób kontrolować. Generalnie, jeżeli ktoś nam powie, że na pewno będzie coś działać to dobrze, że jest co do tego faktu przekonany, natomiast wiadomo naszą rolą, testerów, jest to żeby to zweryfikować i potwierdzić w 100%, że faktycznie to działa i spełnia wymagania klienta.

Krzysztof: Dzięki za tę odpowiedź. Przybliżmy może nieco naszym słuchaczom warsztat pracy testera. Gdybyś mógł Jacku powiedzieć jakie są typy testów i sposoby testowania.

Jacek: Jasne. Generalnie jest bardzo wiele typów testów jak i sposobów testowania. Może przedstawię te podstawowe. Pierwszym takim typem są testy funkcjonalne. Zadaniem testów funkcjonalnych, które oparte są na wymaganiach jest sprawdzenie systemu pod kątem zgodności działania poszczególnych funkcjonalności ze specyfikacją. Dokonywane jest sprawdzenie podstawowych funkcji aplikacji, na przykład wprowadzanie tekstu, sprawdzenie funkcji menu, instalacji lub konfiguracji. Generalnie skoncentrowanie się na wymaganiach klienta oraz jego oczekiwaniach. Prowadzi się tego typu testy zarówno przy pomocy testów manualnych jak i testów automatycznych. Bardzo ważne jest, aby testy funkcjonalne były przeprowadzane nie na koniec procesu tworzenia oprogramowania, ale od samego początku stworzenia pierwszych funkcjonalności. Takim kolejnym typem testów, o których warto wspomnieć są testy niefunkcjonalne. Testy niefunkcjonalne są testami niepowiązanymi z wymaganiami funkcjonalnymi. Mają one ogromny wpływ na późniejsze zadowolenie klienta czy użytkowników i trzeba przyznać, że są dość trudno definiowalne. Zadaniem testów niefunkcjonalnych jest ocena cech testowanego oprogramowania, na przykład niezawodności, użyteczności, łatwości konserwacji. Przykładami testów niefunkcjonalnych są testy obciążeniowe, testy wydajnościowe czy testy przeciążające. Kolejną taką grupą testów są testy użyteczności. Są to testy nastawione na weryfikację łatwości użytkowania oprogramowania przez użytkowników końcowych. Są to głównie testy czarnoskrzynkowe, czyli manualne, sprawdzające jak łatwo korzysta się z oprogramowania, jak łatwo użytkownicy uczą się korzystać z tego oprogramowania, jak wygodne w obsłudze jest generalnie oprogramowanie dla użytkowników końcowych. Są również testy strukturalne. Są to testy określane jako testy białej skrzynki. Wynika to z tego, że w ich przypadku jesteśmy zainteresowani tym co dzieje się wewnątrz systemu. W testowaniu strukturalnym testerzy powinni posiadać wiedze z zakresu implementacji kodu oraz architektury.

Krzysztof: Dzięki za to rzeczowe przedstawienie tematu. Gdy ja rozpoczynałeś swoją karierę z IT to dosyć powszechne było to, że albo programiści testują rozwiązania, które sami piszą, albo robi to klient. Z perspektywy czasu wiemy, że ani jedno ani drugie rozwiązanie nie jest zbyt dobre. Teraz powszechne jest już stosowanie wyodrębnionej roli testera, który właśnie ma za zadanie zapewnienie tej jakości. Jak wynika z Twojego doświadczenia, czy tester ma albo powinien mieć kontakt z klientem końcowym? Czy też powinien to być raczej jeden z pracowników firmy, który po prostu nie ma dostępu do klienta końcowego?

Jacek: Generalnie z mojego doświadczenia wynika, że bardzo dobrze, jeśli tester ma kontakt z takim klientem, ponieważ często umożliwia mu to zobaczenie w jaki sposób klient końcowy postrzega na pewne funkcjonalności i na pewno daje mu to dużą wiedzę i przydaje się, szczególnie na początku kariery testera. Tester bardzo często niejako wciela się w rolę klienta końcowego. Bardzo ważne jest to, żeby patrzył na testowane oprogramowanie właśnie z punktu widzenia takiego klienta. Dlatego wydaje mi się, że jest to pozytywny aspekt na pewno.

Krzysztof: W dzisiejszych czasach w IT dosyć powszechne jest takie podejście stosowania agile, bardzo często spotyka się frameworki typu scrum i tak dalej, stosowane przez firmę. I zastanawiam się, czy w kolejnym sprincie, który jest kolejnym elementem właśnie scrum’a testuje się cały system od nowa, czy może tylko te ficzery, które są wypuszczane w tym reezie.

Jacek: Generalnie praktyką jest to, że stosuje się te ficzery, które są wypuszczane w danym sprincie. Natomiast przez cały okres budowy oprogramowania pisze się właśnie testy automatyczne, które są odpalane automatycznie na jakimś CI i generalnie ich rolą jest to, żeby sprawdzać regresyjnie czy nie pojawiły się jakieś nowe błędy w już wcześniej napisanych funkcjonalnościach.

Krzysztof: Jasne. Powiedziałeś o CI. A mógłbyś bardziej rozszerzyć ten temat?

Jacek: Continuous Integration jest to praktyka, która umożliwia częste budowanie aplikacji, wgrywanie ich na dane środowisko testowe bądź produkcyjne, natomiast główną zaletą jest to, że przed wgraniem danego kodu nas serwer całość jest sprawdzana przez różnego rodzaju testy, jak właśnie testy funkcjonalne, automatyczne, testy wydajnościowe, testy JUnitowe i dopiero wówczas jak wszystkie te testy zwrócą pozytywny rezultat i będziemy mieli pewność, że oprogramowanie nie zawiera żadnych błędów, wówczas oprogramowanie, kod jest wgrywany na środowisko testowe czy produkcyjne.

Krzysztof: Jasna sprawa, dzięki. Jak testerzy pracują jak jest ich więcej niż jeden, czyli jak pracują w momencie, w którym tworzy się team QA?

Jacek: Myślę, że jest to bardzo ciekawe doświadczenie i generalnie jest to bardzo pozytywny aspekt, jeśli w danym teamie jest więcej niż jeden QA, ponieważ często jest tak, że w danym teamie jest więcej niż jeden programista, natomiast jeden QA. Natomiast, że tak powiem, jak to się mówi „co dwie głowy to nie jedna”. Wówczas naprawdę można zdecydowanie lepiej planować całą pracę, można się podzielić scenariuszami do testowania. Można wtedy lepiej automatyzować testy, tworzyć więcej przypadków testowych, rozwijać framework. Także przede wszystkim uważam, że zdecydowanie lepiej wówczas jest planowana praca testerów. Testerzy mogą się konsultować. Z mojego doświadczenia jak najbardziej jest to coś pozytywnego.

Krzysztof: Świetnie. Teraz pewnie poruszę temat rzekę. Czy testowanie aplikacji webowych, desktopowych i mobilnych mocno się od siebie różni, czy używa się do tego innych tooli. A co, na przykład, z różnymi wersjami przeglądarek, presji, systemami operacyjnymi czy telefonami? Jak się do tego podchodzi?

Jacek: Nie mam doświadczenia, jeśli chodzi o aplikacje desktopowe, natomiast mogę nieco więcej powiedzieć o aplikacjach webowych i mobilnych. Testowanie aplikacji mobilnych różni się od testowania aplikacji internetowych i to pod wieloma względami. Najczęściej testy funkcjonalne tego typu aplikacji opierają się na testowanie interakcji użytkowników. Oczywiście, inaczej wygląda testowanie aplikacji bankowej, jeszcze inaczej aplikacji społecznościowej. Dużo również zależy od docelowej grupy przyszłych użytkowników. Duże znaczenie ma również platforma, na jakiej pracuje aplikacja mobilna, a co za tym idzie, sposób jej rozpowszechniania. Najpopularniejsze to oczywiście Google Play oraz AppStore. Dużą wada jest to, że aby naprawić jakiś znaleziony defekt musimy w pierwszej kolejności wgrać nową aplikację do danego sklepu i w przypadku AppStore’a jeszcze czekać, aż nowa wersja aplikacji zostanie zatwierdzona, co może niekiedy potrwać kilka dni, czy niekiedy nawet tygodni. Także jeśli nasza aplikacja zawierała jakiś krytyczny błąd uniemożliwiający normalne korzystanie, możemy sobie wyobrazić co zrobi jej użytkownik. Myślę, że po prostu ją usunie i w jej miejsce zainstaluje aplikację innego producenta. Również testowanie aplikacji mobilnych i aplikacji webowych różni się pod kątem testów funkcjonalnych, gdyż w przypadku aplikacji mobilnych musimy sprawdzić, na przykład, jak aplikacja sprawuje się, kiedy przychodzi połączenie telefoniczne bądź wiadomość SMS, co się robi z danymi po usunięciu aplikacji z telefonu. Również testy wydajnościowe bardzo się różnią. Tego typu testy w przypadku aplikacji mobilnych, które wykorzystują infrastrukturę serwerową należy sprawdzić, czy aplikacja działa w określonych warunkach. Co się dzieje, kiedy na przykład infrastruktura, która powinna dostarczyć dane nie działa z różnych powodów. Jakie są czasy reakcji, co się dzieje w przypadku, kiedy jest wolne łącze. Również testy użyteczności bardzo się różnią. Celem testów użyteczności jest w przypadku aplikacji potwierdzenie, że obsługa aplikacji jest intuicyjna. Celem jest również to, żeby sprawdzić czy spełnione są wytyczne dotyczące interfejsu użytkownika. Te są również dostarczane przez firmę Apple, także myślę, że tych różnic jest bardzo dużo. Są oczywiście podobieństwa, natomiast należy jeszcze w przypadku aplikacji mobilnych sprawdzić wiele innych aspektów, które są charakterystyczne stosunku do urządzenia, na którym będzie aplikacja uruchamiana.

Krzysztof: No to faktycznie jest tych różnic trochę. Czy zauważasz coś takiego jak specjalizację testerów, którzy zajmują się aplikacjami webowymi, tudzież mobilnymi, czy raczej jest to rzecz podobna i tak naprawdę wtórna?

Jacek: Zdecydowanie tak, może mniej jeszcze na naszym rynku, natomiast widać pierwsze sygnały, że taka specjalizacja jest i jest też już wielu testerów, którzy się specjalizują tylko, na przykład w aplikacjach mobilnych, także myślę, że rynek będzie wymuszać taką specjalizację.

Krzysztof: OK, dzięki. Wspomnieliśmy na początku o automatyzacji w testowaniu. Faktycznie, coraz więcej się o niej mówi, coraz więcej słychać o automatyzacji. Powiedz proszę, na czym ona polega?

Jacek: Testy automatyczne wykonywane są przy pomocy dedykowanego oprogramowania, natomiast testy manualne bądź ręczne wymagają zaangażowania człowieka. Zaletą testów automatycznych jest to, że pozwalają zaoszczędzić czas oraz koszty. Po stworzeniu testu automatycznego łatwiej taki test wykonać niż angażować do tego wykwalifikowanego testera, który musi przygotować taki test, przeprowadzić go. Każdy rodzaj aplikacji można testować ręcznie, jednak testy automatyczne zalecane są w szczególności już dla aplikacji pracujących stabilnie i wykorzystywane są najczęściej jako testy regresji. Testy manualne na dłuższą metę, trzeba przyznać, że są mniej wiarygodne, ponieważ ich cykliczność powoduje, że każdy kolejny test wykonywany jest z mniejszą starannością. Manualne testowanie po jakimś czasie może spowodować znudzenie testera. Tworzenie testów automatycznych, myślę, że jest zdecydowanie ciekawsze i raz napisany test możemy uruchamiać wielokrotnie w dowolnym momencie. Ten sam test automatyczny można także uruchomić na wielu przeglądarkach, pod rożnymi systemami operacyjnymi. W przypadku testów manualnych niestety należy dla każdego środowiska przeprowadzić osobne testy.

Krzysztof: Mówiliśmy tutaj, że tester nie pracuje sam, prawda? Pracuje w grupie, jakimś zespole, wspiera działania całego zespołu, aby tę jakość zapewnić. Zastanawiam się jaki powinien być lub jaki jest stosunek testera do innych ról w zespole, na przykład do programistów, bo najczęściej tutaj dochodzi do pewnych antagonizmów i są już takie powiedziałbym legendy o tym jak bardzo testerzy się nie lubią z programistami. Wiadomo, obydwoje grają do tej samej bramki, natomiast często faktycznie programiści mają takie wyobrażenie, że tester coś tam wymyśla i w ich opinii dany ficzer mógłby być już wypuszczony na produkcję, tymczasem wraca do jakiś poprawek. Jak wynika z Twojego doświadczenia? Jaki powinien być ten stosunek testera do innych osób w zespole?

Jacek: Jasne. Myślę, że obecnie jest to tylko taki stereotyp, że tester jest w dziwny sposób postrzegany przez programistów. Myślę, że w tej chwili, jeśli tester pracuje w zespole, gdzie kodują osoby, już z jakimś doświadczeniem to jest to naprawdę silny zespół, który jest świadom tego, że jest proces jakościowy w tworzeniu oprogramowania, doceniają go i współpracują ze sobą. Na bazie swojego doświadczenia mogę powiedzieć, że jest to bardziej współpraca, gdzie tester z programista uzupełniają się wiedzą, wymieniają się informacjami na temat ewentualnych niebezpieczeństw, czy też ścieżek, które warto przetestować. Także zdecydowanie myślę, że jest to już taki stereotyp i obecnie jest to bardziej nastawione na współpracę i uzupełnianie się.

Krzysztof: To dobrze słyszeć, że to się polepsza i idzie w dobrym kierunku. Myślę, że czas, kiedy programowało się na produkcji mamy już za sobą. Mam pytanie, czy tester testuje na produkcji czy może na jakiejś specjalnej maszynie, w specjalnym środowisku?

Jacek: Oczywiście wszystko zależy od projektu i od organizacji, w której pracuje tester. Jakiekolwiek testowanie jest tak naprawdę lepsze, niż jakby go nie było, nawet jeśli, o zgrozo, odbywa się w środowisku produkcyjnym. Generalnie testowanie zawsze powinno się odbywać w środowisku testowym, czyli wydzielonym środowisku, specjalnie przeznaczonym na testy. Takie środowisko powinno być zbliżone lub najlepiej identyczne jak produkcyjne, ale zazwyczaj takie środowisko testowe zawiera specjalnie spreparowane dane umożliwiające bezpieczne przeprowadzenie testów. Absolutnie karygodna praktyką jest przeprowadzanie jakiś operacji na realnych danych w środowisku produkcyjnym, gdzie nasze działania mogą mieć wpływ na dane użytkowników jakiejś usługi. Oczywiście, jest też rodzaj testów, które przeprowadza się w środowisku produkcyjnym. Są to najczęściej smoke testy, czyli testy, które sprawdzają najbardziej typowe ścieżki, które może przebyć potencjalny użytkownik. Dzięki takim testom możemy uzyskać informację, po aktualizacji środowiska produkcyjnego o nowy kod czy krytyczne funkcjonalności działają poprawnie.

Krzysztof: W 2015r. na konferencji OnAgile Elisabeth Hendrickson powiedziała, że automatyzacja w testowaniu umożliwia sprawdzanie, angielskie checking. Ale w jej opinii testowanie to jest suma dwóch rzeczy, checking czyli sprawdzanie i exploring. I o ile checking-sprawdzanie może być głupie, robione przez maszyny, o tyle exploring wymaga już pewnej kreatywności, uczenia. I w jej opinii na razie tylko człowiek posiada takie możliwości. Mam pytanie do Ciebie, czy jeśli można wszystko zautomatyzować, wszystko próbuje się to czy nadal potrzebny jest tester?

Jacek: Zdecydowanie zgadzam się z opinią. Uważam, że zawsze będzie potrzebny tester z tego względu, że nie zawsze da się wszystko zautomatyzować. Zdecydowanie testy automatyczne służą do tego, żeby sprawdzać aplikacje, a nie testować. Żaden test automatyczny nie wykona ścieżki, na którą może wpaść tester, ponieważ tester buduje swoje doświadczenie wiele lat, na bazie różnych projektów, różnych technologii i nie da się tego doświadczenia, całej tej wiedzy zdobywanej latami, w jakiś sposób przekazać do testów automatycznych czy jakiegoś innego rodzaju testów. Także myślę, że zdecydowanie rola testera jeszcze przez wiele, wiele lat będzie niezagrożona i jest to osoba, która będzie potrzebna w projekcie.

Krzysztof: Czyli ta ludzka intuicja, która nie da się przenieść czy zaszczepić maszynie, prawda, jest to atut testera. Super. Jaką w związku z tym widzisz przyszłość przed zawodem testera? W którym kierunku ten zawód zmierza?

Jacek: Myślę, że tak jak tutaj rozmawialiśmy, zresztą widać to obecnie na rynku, że najwięcej jest poszukiwanych testerów, którzy zajmują się tworzeniem narzędzi automatyzujących, testów automatycznych, jest to na pewno przyszłość, jeśli chodzi o testowanie. Moim zdaniem ciągle są potrzebni testerzy, którzy testują manualnie. Oczywiście do tego dochodzą aspekty sztucznej inteligencji i coraz częściej w naszym życiu codziennym wchodzą machine learning, czyli jest to na pewno też przyszłość. Nie do końca jestem w stanie jeszcze powiedzieć, w jaki sposób technologie przełożą się na testowanie, natomiast myślę, że to jest coś czym warto się interesować i na pewno warto śledzić.

Krzysztof: Bardzo wiele osób wybiera zawód testera jako taką swoją drogę wejścia do IT. Co byś polecił właśnie osobom, które chcą rozpocząć swoja karierę jako tester oprogramowania?

Jacek: Myślę, że najlepiej jest szukać materiałów, który naprawdę w Internecie nie brakuje. Jest wiele kursów testowania manualnego. Naprawdę Internet jest świetnym źródłem wiedzy i rzeczywiście te materiały dostępne, chociażby na YouTubie, są wysokiej jakości i wiele się z nich możemy nauczyć. Przede wszystkim starać się zdobywać doświadczenie, testować projekty i starać się mieć kontakt z tym środowiskiem i obserwować jak to robią inni.

Krzysztof: Super Jacku. Ja Ci bardzo dziękuje za ciekawą rozmowę. Sam się wiele dowiedziałem. Myślę, że słuchacze też z tego wyniosą wiele cennej wiedzy, bo podzieliłeś się faktycznie swoimi doświadczeniami z wielu alt pracy. Bardzo Ci serdecznie dziękuje i powiedz proszę, gdzie Cię można znaleźć w Internecie?

Jacek: W tej chwili można mnie znaleźć na LinkedIn’ie. Tam mam swój profil, zapraszam do kontaktu, chętnie wymienię się doświadczeniami.

Krzysztof: Świetnie, dzięki Jacku! Hej.

Jacek: Dziękuje Krzysztof.

I to na tyle co przygotowałem dla Was na dzisiaj. Mam nadzieję, że po tej rozmowie z Jackiem masz już lepszy obraz zawodu testera oprogramowania i wiesz, czy to jest droga dla Ciebie. Ja osobiście uważam, że jest to niezwykle odpowiedzialna i potrzebna rolą, która wymaga cierpliwości i dokładności. A z drugiej strony rozwój technologiczny, zwłaszcza automatyzacja powoduje, że próg wejścia do tego zawodu stale się podnosi. Bardzo Ci dziękuje, że ze mną jesteś. Jeśli masz jakieś pytania, komentarze albo propozycje co do kolejnych odcinków, a może czujesz się na siłach, aby wystąpić w jednym z kolejnym epizodów, zapraszam do kontaktu ze mną pod adresem krzysztof@porozmawiajmyoit.pl Ten podcast otrzymałeś ode mnie bezpłatnie, ale nie jest on tak do końca darmowy. Poproszę Cię o polubienia fanpage na Facebooku lub gwiazdki i recenzję na ITunes, Soundcloud, Spriker lub innej aplikacji, na której słuchasz tego podcastu. Zapraszam Cię też na mój Instagram, gdzie od pewnego czasu publikuję zwiastuny odcinków w postaci filmów z iście hollywoodzkim scenariuszem. Już teraz zapraszam Cię do kolejnych odcinków, a żeby ich nie przegapić odwiedź stronę porozmawiajmyoit.pl/newsletter i zapisz się na listę mailingową, aby otrzymać informację o zapowiedziach i nowych odcinkach. Dzięki, hej!