automatyzacja testów

POIT #016: Automatyzacja testów

Witam w szesnastym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest automatyzacja testów oprogramowania.

Dziś moimi gościem jest Michał Ślęzak. Michał od kilku lat zajmuje się testowaniem aplikacji ze szczególnym nastawieniem na automatyzację. Jest jednym z liderów PTaQ (Poznań Testing and Quality meetup) oraz współprowadzącym pierwszego w Polsce podcastu o testowaniu – Testing Parrot. Dodatkowo prowadzi blog testingplus.me o testowaniu i tematach związanych z IT. Jest prelegentem na warsztatach i meetupach. Interesuje się marketingiem i produktywnością.

W tym odcinku o automatyzacji testów oprogramowania opowiemy w następujących kontekstach:

  • czym są testy automatyczne?
  • po co automatyzować testy?
  • jakie są typy testów i kiedy się je uruchamia?
  • czy tester automatyczny musi potrafić programować?
  • na ile testy automatyczne powinny dzielić kod z aplikacją?
  • czy automatyzacja testów może się nie udać?
  • czy jest droga?
  • co to jest BDD w kontekście testowania?
  • czy w realnych projektach tester automatyczny także testuje manualnie?
  • w jakim kierunku zmierza testowanie automatyczne?
  • czy sztuczna inteligencja jest zagrożeniem dla testerów specjalizujących się w automatyzacji testów?
  • czy jest to zawód przyszłości i warto w niego inwestować swój czas?


Subskrypcja podcastu:

Linki:

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner  (posłuchaj)

Zwiastun filmowy:

Transkrypcja podcastu

To jest 16 odcinek podcastu „Porozmawiajmy o IT”, w którym z moim gościem rozmawiam o automatyzacji testów oprogramowania. Z tego odcinka dowiesz się:

*na czym polega tytułowa automatyzacja,

*czy tester musi potrafić programować,

*kiedy testy są uruchamiane,

*w jaki sposób integrują się z kodem aplikacji.

 

Powiemy także o tym czy sztuczna inteligencja nie jest zagrożeniem dla tego zawodu. Jeśli spodoba Ci się ta rozmowa powiedz o niej koleżankom i kolegom – może też wyciągną z niej coś wartościowego dla siebie.

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.

Cześć! Mój gość od kilku lat zajmuje się testowaniem aplikacji ze szczególnym nastawieniem na automatyzację. Jest jednym z liderów PTaQ – Poznań testing and quality meetup oraz współprowadzącym pierwszego w Polsce podcastu o testowaniu – Testing Parrot. Dodatkowo, prowadzi blog – Testing Plus Me – o testowaniu i tematach związanych z IT. Jest prelegentem na warsztatach i meetup’ach. Interesuje się marketingiem i produktywnością. Moim dzisiejszym gościem jest Michał Ślęzak.

 

Krzysztof: Cześć Michał! Bardzo się cieszę, że zgodziłeś się wystąpić w podcaście.

Michał: Cześć! Bardzo dziękuje za zaproszenie.

Krzysztof: Dzisiaj trochę skorzystamy z doświadczenia i wiedzy Michała i porozmawiamy sobie o automatyzacji testów. OK. Ja zawsze zaczynam od takiego wprowadzającego i rozluźniającego pytania. Michał, czy słuchasz podcastów i jeśli tak to jakich najczęściej?

Michał: Tak, podcastów słucham i to spore ilości. Również kilka Twoich odcinków słuchałem. A z takich podcastów niezwiązanych z IT to ostatnio słuchaj Mirka Burnejko podcastu Projektant Życia, Mirek Burnejko jest w IT dość znaną osobą, ale też prowadzi fajny podcast z dużą ilością konkretnych informacji, więc jeżeli interesuje się biznesem i rozwojem biznesu to polecam. Również dość znany podcast Mała Wielka Firma – bardzo wiele różnych tematów i biznesowych, i marketingowych. Tak naprawdę tych odcinków jest prawie 200, na pewno ponad 100, więc każdy znajdzie coś dla siebie. I podcast Michała Szafrańskiego – Finansowy Ninja – skupiany na finansach, ale nie tylko, również wiele ciekawych dyskusji i go również polecam.

Krzysztof: Tak, to są faktycznie świetne podcasty. Zalinkujemy w notatkach do odcinka. Fajnie. OK. To Michał, może zacznijmy od tego – czym są testy automatyczne?

Michał: Testy automatyczne jest to odpowiedź na problem taki, że wykonujemy niektóre rzeczy powtarzalnie, albo rzeczy są żmudne i ktoś wpadł na pomysł, że możemy to zautomatyzować. Testy regresji, które często musimy wykonywać, powtarzalne jakby kroki, które są często żmudne, potem nasza też produktywność może spadać. Już nie jesteśmy tacy uważni, a dobrze napisany test automatyczny, na przykład interfejsu użytkownika może pomóc nam wyłapać jakieś regresję oprogramowania, na przykład programista wprowadził jakąś zmianę i coś nagle się popsuło. Także tym są. To jest też odpowiedź na to, że coraz szybciej chcemy dostarczać oprogramowanie, więc przez to testy muszą być szybko wykonywane.

Krzysztof: Google trends pokazuje, że takie hasła jak automation testing w wyszukiwaniu zyskują na popularności na przestrzeni ostatnich miesięcy czy lat. Zatem pytanie – po co automatyzować testy? Jakie są benefity automatyzacji?

Michał: Tak jak wspomniałem – pomoc działom testerskim w odciążeniu ich od takiej żmudnej pracy jak testy regresji lub testy wizualnej regresji, bo też są narzędzia, które pozwalają wyłapywać różnice interfejsie użytkownika pomiędzy środowiskami, na przykład środowiskiem produkcyjnym a środowiskiem stagingowym. A testerzy mogą się skupić na eksploracji, na szukaniu błędów takich ciekawszych. Ja lubię takie podejście do testów – jak detektyw, który szuka błędów, szuka co jeszcze mogło się popsuć. To jest moim zdaniem dobre podejście do testów takie ogólne. Popularność jest też taka, ponieważ i klienci, i biznes chce coraz szybciej dostarczać wartość. My jako firmy programistyczne chcemy dostarczać tą wartość, bo klienci i biznes wymaga tego. I żeby to robić to musimy automatyzować niektóre obszary, cały continuous delivery wyrasta na tym, że potrzebujemy automatyzować testy i wiele rzeczy możemy dzięki tej automatyzacji przyspieszyć tak naprawdę. Testy też możemy, jeśli są dobrze napisane, używać współbieżnie, czyli pararell i tak naprawdę, jeśli mamy kilka maszyn to kilkaset testów możemy puścić na tych maszynach i to zamiast 4 godzin może zając pół godziny. Nawet mniej. Przy dobrze napisanych testach to dużo zależy od serwerów, które są używane. Jeżeli one są dobre, a te koszty nie są tak wysokie jak kiedyś, bo wystarczy kupić na Amazonie czy na innym serwerze i to będzie działać.

Krzysztof: Dokładnie. Myślę, że bardzo fajnie podsumowałeś, że te przyczyny czy też powody, dla których chcemy automatyzować to jest taka mieszanka powodów biznesowych, powodów ściśle IT, powiedziałbym technologicznych, ale też takich, które mają za zadanie przysłużyć się pracy zespołowi. Świetnie. Zanim przejdziemy do bardziej wyszukanych pytań, dajmy może małą dawkę teorii, gdybyś mógł Michał powiedzieć – jakie są podstawowe typy testów automatycznych?

Michał: Podstawowymi typami, tak naprawdę, powstała jakiś czas temu piramida testów, na przykład Martin Fowler ją proponuje, to najniższy poziom to testy jednostkowe. To jest najważniejszy obszar, tak naprawdę. Testy jednostkowe powinny być w największej ilości i one są najtańsze w implementacji, bo automatyzujemy metod poszczególnych, więc nie jest to tak drogie kosztowo w egzekucji czasowej jak na przykład automatyzacja interfejsu użytkownika, ponieważ nie mamy przeglądarki i tych elementów po drodze. Następnie testy integracyjne, czyli odwoływanie się do jakiś API jakiś webserwisów. I na końcu testy end to end, czyli testy akceptacyjne, czyli od zalogowania po wylogowanie w jakieś aplikacji webowej. Dochodzą jeszcze testy performance również automatyzowane. Tak naprawdę te testy performance to taki dodatkowy obszar, który jest coraz częściej automatyzowany. To z takich podstawowych. Jeszcze testy API, bo teraz coraz częściej się robi tak, że zamiast korzystać z testów end to end, które są dość drogie, w sumie są najdroższe z testów implementacji i w egzekucji korzysta się z API, żeby pominąć ten element, na przykład tworzenia danych testowych przez skrypt, który biega sobie po interfejsie użytkownika, tylko uderzamy do API i tam to tworzymy.

Krzysztof: OK, Michał. Dałeś bardzo fajną klasyfikację wszystkich testów automatycznych, czyli testy się pisze, to o czym jeszcze powiemy, do czego przejdziemy. Teraz chciałbym Cię zapytać o to, w którym momencie cyklu wytwarzania oprogramowania się je uruchamia?

Michał: Tak naprawdę to zależy od organizacji. Moim zdaniem najlepiej, jeśli tworzymy nowy produkt, robić to od początku, ponieważ im szybciej tym lepiej. jeśli testy są dobrze pisane to mogą szybko dostarczać feedback, jednak często, jeśli mamy jakieś wielkie aplikacje typu Legacy to tworzone są testy end to end na początku i dopiero potem dopisywane jakieś testy integracyjne i jednostkowe. To też jest jakieś podejście, ale jednak moim zdaniem, zaczynanie od najniższego poziomu – potem testy integracyjne i potem na końcu testy end to end, testy interfejsu użytkownika to jest dobre podejście. Najlepiej jak najszybciej, ale bywa to różnie.

Krzysztof: Jak to w IT. Praktyka często różni się od teorii.

Michał: Tak Ci przerwę, bo testy tak naprawdę nie są takie łatwe do implementacji, żeby one były stabilne i żeby działały, na przykład uruchamiane razem, nie tylko pojedynczo, właśnie działały współbieżnie, to tych wyzwań się pojawia więcej. Taką ciekawostkę dodam, że Google na swoim blogu, jakiś czas temu – ogólnie polecam tego bloga googletestingblog – ukuł taki termin flaky test, czyli testy, które nie są stabilne, czyli czasem przechodzą, czasem nie. Tak naprawdę tych powodów, dlaczego test nie przechodzi, a dlaczego przechodzi jest również sporo, bo również ma na to wpływ nasz ram, nasz procesor. Taką bolączką też jest AJAX i Javascript, z którym trzeba nauczyć się pracować, no bo powstał przed tym renesansem frameworków JSowych, więc nie był do tego przystosowany, więc to wyzwanie. Tym bardziej na początku, żeby radzić sobie z czekaniem na te elementy, które chcemy. To jest to.

Krzysztof: I teraz właśnie słowo o tej implementacji. Często o osobach zajmujących się automatyzacją testów mówi się, że są to programiści testów. Czy faktycznie ta specjalizacja bliższa jest zawodowi programisty niż testera manualnego, na przykład?

Michał: Wiesz, Krzysiu to zależy od organizacji, bywa to różnie, ale moim zdaniem najlepiej jak tak jest, bo tak naprawdę kod testów jest to kod produkcyjny. I żeby on był pisany dobrze to musi być pisany przez osoby, które w tym siedzą tyle samo czasu co inni programiści, innego typu. Tak naprawdę, moim zdaniem, programista testów to jest programista, który się w tym specjalizuje się. Tak naprawdę, moim zdaniem, programista testów to jest programista, który się w tym specjalizuje się. Specjalizuje się w pisaniu testów. Oczywiście warto, żeby background testerski, bo pisanie testcase’ow – podejście detektywistyczne do tego kodu jest warte i potrzebne. Można również widzieć po większych organizacjach, jak Microsoft czy Google, oni mają testy manualne, ale one są często outsourcowane, a rolę testera pełni właśnie stanowisko software deweloper in test, więc osoby, które są programistami, ale rozwijają się w tym, żeby automatyzować, szukać tych obszarów, które przez automatyzację, przez pomoc w swoją w postaci kodu pomóc testom przyspieszać je również.

Krzysztof: Jasna sprawa. Myślę, że po części odpowiedziałeś na pytanie, które miałem teraz zamiar zadać. Ale może zadam je nieco inaczej. Czy tester zajmujący się automatyzacją musi znać język programowanie czy też framework biblioteki, w którym ten projekt jest napisany. Przykładowo, mając projekt napisany w Rubion Race czy praktykuje się coś takiego, że testy pisze się w Javie, dajmy na to?

Michał: Raczej się stosuje ten język, w którym się jest pisany kod, bo to jest dodatkowa zaleta, bo jeśli ten programista testów czegoś nie potrafi albo ma z czymś problem, to może udać się do zespołu programistów, którzy w danej technologii programują, więc może szybciej znaleźć odpowiedź. Z drugiej strony też, moim zdaniem, język to jest narzędzie prawda? Jeśli potrafimy jeden język programowania dość dobrze, to nauczenie się składni drugiego czy podstawowych frameworków nie powinno stanowić problemu. Zajmie nam to więcej czasu, ale jest to możliwe do nauczania, więc nie widzę problemu. Jeśli mamy aplikację w Javie, to testy raczej piszemy w Javie.

Krzysztof: Jasne. Z pewnością ma to duży sens w przypadku JUnit testów, które są nisko poziomowe, że tak powiem, i wiąże się bezpośrednio z kodem. jeszcze troszeczeczkę postaram się zagłębić w ten temat i zapytam – jak sprawdza się i czy w ogóle sprawdza się takie podejście, że testy nieco wyższego poziomu, integracyjne powiedzmy, są napisane z wykorzystaniem troszkę innej technologii niż technologia projektu, czy coś takiego w ogóle ma rację bytu?

Michał: Szczerze to raczej widziałem takie projekty, że raczej korzysta się z takich technologii, które się już zna. Oczywiście, jeśli byłaby potrzeba to można się ich nauczyć, ale najczęściej, na przykład selenium webdriver ma implementacje dla każdego języka popularnego i Ruby, i Python, i Java, i C sharp. Tak naprawdę większość znanych technologii jest, więc sama składnia jest bardzo podobna i przeskoczenie nie ma jakiegoś problemu. Przeskoczenie również między językami, więc jeżeli ktoś się nauczy selenium webdriver w jednym języku to troszeczkę mu się składnia zmieni w innym, ale same koncepty są bardzo podobne. Raczej się stosuje te same technologie, ale jeśli jest jakaś potrzeba albo jakaś zaleta, na przykład znaleźliśmy jakiś framework, chociaż z tym podchodzeniem do nowości bywa różnie, bo pojawia się jakiś nowy framework i potem się okazuje, że nie jest utrzymywany, a sami też nie mamy czasu go utrzymywać, więc raczej polecam sprawdzone rozwiązania, tym bardziej jeśli to jest aplikacja produkcyjna. Jeżeli uczymy się czegoś to jak najbardziej warto, ale jeśli aplikacja produkcyjna to lepiej korzystać ze sprawdzonych rozwiązań, gdzie już to community się utworzyło. Jeśli będziemy jakiś problem to szybciej znajdziemy to rozwiązanie.

Krzysztof: Jasna sprawa. Na ile testy automatyczne powinny zatem współdzielić kod z kodem aplikacji? Zastanawiam się. Mogą być na przykład takie sytuacja, że jeśli nasze testy czerpią z kodu aplikacji i ten kod się w jakiś sposób zmieni to ma bezpośredni wpływ na testy, które piszemy. Czy zatem lepszym podejściem jest zupełna separacja tych dwóch rzeczy czy może praktyka pokazuje, że lepiej, żeby te rzeczy się ze sobą łączyły?

Michał: Tak naprawdę zależy od potrzeb, bo taką potrzebą może tu być komunikacja z bazą, prawda? Czyli używany gdzieś unhibernate na przykład i potem korzystamy z tego obiektu w testach. Moim zdaniem to jest OK, bo tak jak wspomniałeś, jak coś się zmieni, to też będziemy mieli o tym info też w naszych testach. Jeśli chodzi o testy seleniowe to tak naprawdę to warto komunikować się z działem programistów, czy jeżeli mamy też jakiegoś frontendowca, żeby te selektory dla danych elementów przyjąć jakąś na przykład konwencje albo żeby zawsze były nadawane IDki, żeby to się prościej wykorzystywało w testach. Ale ta separacja raczej tak jest, bo ta warstwa komunikacji z bazą może być współdzielona. Chyba, że ktoś ma jeszcze bardziej specyficzne przypadki użycia. Tak na szybko na myśli mi przychodzi, że ta warstwa komunikacji z bazą bywa często współdzielona.

Krzysztof: Myślę, że jesteś kolejną osobą, która potwierdza taką zmianę współpracy pomiędzy programistami a testerami. Wcześniej to wyglądało trochę tak jak obozy, które się w jakiś sposób zwalczały, albo które gdzieś patrzyły na siebie z wrogością. W 14 odcinku mojego podcastu rozmawiałem o zawodzie testera z wieloletnim, doświadczonym testerem i on przekonywał mnie, że nie ma już miejsca, zwłaszcza w testach automatycznych konieczna jest współpraca programistów i testerów. Ty jesteś kolejną osobą, która faktycznie potwierdza, że coś takiego ma miejsce. W sumie to dobrze.

Michał: Dokładnie. W projektach IT jesteśmy zespołem i ja uważam, że gramy do jednej bramki. Tym bardziej jeżeli to są zespoły produktowe to ta współpraca jest, moim zdaniem, jeszcze bardziej zaciśnięta, bo gramy do jednej bramki i sprzedawcy, i marketingowcy, i testerzy. Wszyscy chcą dowieźć cel, prawda? Moim zdaniem to jest ważne, żeby współpracować. Raczej takie obozy i takie podejście to osoby początkujące często wykazują, że albo lubią znajdować błędy, albo programiści lekceważą testerów. Zdarzają się takie przypadki, ale jednak moim zdaniem takie podejście, że jesteśmy teamem jest budujące i nie jest to czysty frazes, tylko pokazuje, że razem chcemy dowieść tą aplikację i produkt w jak najlepszej wersji.

Krzysztof: Super. To bardzo budujące. Mamy różne narzędzia testowe typu Guide JST, przykładowo Selenium ID i one nie wymagają takiej dużej wiedzy programistycznej. Mamy również narzędzia takie powiedziałbym code driven, gdzie ta wiedza jest wymaga w dużo większym stopniu. Czy któreś z tych typów narzędzi jest według Ciebie lepsze i czy to być może zależy od przypadku?

Michał: Jeśli chodzi o selenium i ID i pokrewne rozwiązania to szczerze powiedziawszy nie korzystałem. Z tego co wiem, to z nimi jest taki problem, że raz nagrasz sobie dany przypadek testowy i potem rzadko on za drugim razem działa. Nie wiem czy to się teraz zmieniło, bo tam też był taki problem, że przez pewien czas na githubie oni szukali osoby, która miała się zająć opieką tego projektu i chyba znaleźli i chyba jakiś tam rozwój jest, jednak ja się skupiam na selenium webdriverze lub tego typu rozwiązaniach. Jest jeszcze kilka innych frameworków dla JSa, które też są popularne, jednak pod spodem i tak to jest selenium webdriver ale są jakoś opakowane. Jest trochę inna składnia, przyjaźniejsza, czasami mają fajne raporty w sobie zawarte. Różnica na pewno jest, bo tak naprawdę moim zdaniem, żeby pisać dobre testy automatyczne to trzeba programować jak programista, czyli siedzieć w tym tak samo dużo czasu. Mogą się pojawić takie wyzwania jak pararell, żeby testy był współbieżnie i tutaj już się pojawia wiedza o dependency injection, żeby wstrzykiwać te obiekty, żeby się nie gryzło i żeby umieć korzystać z kontekstu. Tak naprawdę, to już pojawia nam się produkcyjny kod, gdzie jest też potrzebna opieka do niego podobna jak w normalnym kodzie. Drugą sprawą jest to, że osoby, które są programistami testów interesują się również w pewien sposób infrastrukturą – pojawiają się rozwiązania, które pozwalają uruchamiać testy w kontenerze, czyli wiedza o dockerze. Ten Jenkins jest wykorzystywany tutaj, także tak naprawdę tych umiejętności technicznych, które wokół tego są to trochę jest. Co jakiś czas pojawiają się ciekawe rozwiązania, tak jak wspominałem, porównywanie wizualnej regresji, to jest ciekawa sprawa, że jest na przykład framework backstud JS, który robi screenshot danej strony, której chcemy, na przykład na naszej stronie stagingowej i produkcyjnej i porównujemy jeszcze przed ostatecznym deploymentem czy te zmiany, które nastały w interfejsie użytkownika to są wszystkie te, które chcemy. Jeśli nie, no to możemy zadziałać. Tych rozwiązań się pojawia coraz więcej ciekawych i coraz ciekawsze obszary automatyzacji mogą następować.

Krzysztof: bardzo fajne narzędzie, które wymieniłeś. OK. Michał chciałbym nawiązać do tego, co przed chwilą powiedziałeś, że tak naprawdę w wyniku pisania testów automatycznych powstaje produkcyjny kod, który wymaga osób do rozwoju i opieki. Czy według Ciebie automatyzacja ma wpływ na koszty projekty i czy może się zakończyć niepowodzeniem? Chodzi mi o to, że tak jak powiedziałeś – pisanie testów wymaga czasu, w związku z czym jest to jakaś inwestycja w projekt. Czy wobec tego zawsze, w każdym przypadku jest sens inwestować w automatyzacje?

Michał: Pewnie nie, pewnie nie w każdym. Jeśli nie mamy budżetu, a tak jak wspominałeś – to kosztuje. Jeżeli sami się też nie czujemy dobrze z programowaniem albo nie mamy takiej osoby, no to pytanie czy mamy pieniądze, żeby zainwestować w naukę, bo ona zajmie trochę, wbrew pozorom. Pewnie wtedy można pójść w eksplorację testów – jeżeli robią to osoby doświadczone to może też dawać ciekawe wyniki i może być tańsze. Tak naprawdę zależy jaki mamy ten budżet. Myślę, że może się skończyć niepowodzeniem, jeśli ktoś nie będzie potrafił i te testy będzie cały czas naprawiał, a nie będzie przybywało nowych to może się zakończyć. Wtedy zespół przestaje wierzyć w te testy i potem ktoś zapomina ich uruchamiać, albo testy są na jednym wątku i potem się okazuje, że czas uruchamiania testów to jest kilka godzin. Słyszałem nawet o przypadkach tygodnia uruchamiania testów, to są takie przypadki, że prawdopodobnie testy zostaną wyrzucone i niekontynuowane. Nawet jak nie mamy osoby dedykowanej, ale mamy testera manualnego, który chciałby się nauczyć i mamy trochę tego budżetu, albo on ma trochę wolnego czasu to z czasem może się tego nauczyć i może to wyglądać dobrze.

Krzysztof: OK, czyli właściwie potwierdziłeś to co myślałem, że testy automatyczne nie są zawsze najlepszym rozwiązaniem i powinno się dobierać rozwiązanie do problemu, a nie powiedzmy za każdym razem próbować przemycić rozwiązania, które są teraz w modzie, prawda?

Michał: Dokładnie. Jednak trzeba pamiętać, że to też zależy od skali, prawda? jeżeli mamy dużą organizację, albo aplikacja jest na tyle rozwojowa, no to w takim przypadku raczej nie obędzie się bez automatyzacji i to jest ten przypadek. Ale jeśli to jest mniejsza aplikacja lub budżet nas ogranicza to możemy pójść w eksplorację na przykład.

Krzysztof: OK. Często wykorzystywane w dewelopmencie aplikacje jest podejście BDD – Behavior-driven development. Wówczas mamy scenariusze, prawda, opisujące sposoby zachowania użytkownika, odpowiedź systemu na takie zachowania. Takie scenariusze możemy pisać w takich pseudo językach typu Gherkin na platformę Cucumber. Następnie tego typu scenariusze możemy uruchamiać jakby w ten sposób jednocześnie testując, prawda? Mamy specyfikację biznesową jednego przypadku, jednocześnie testy. Pewnego rodzaju testy automatyczne w jednym. Czy tutaj gdzieś według Ciebie jest jeszcze rola testera?

Michał: Tak, bo jak Cucumber ja na przykład używam specflow, który jest po prostu implementacją cucumbera pod .Net. Pod spodem tego Gherkina tych właśnie kroków i ficzerów i scenariuszy, bo to na tym polega, że najpierw piszemy ficzer, potem on się składa ze scenariuszy i pod spodem jest tak naprawdę kod C#, który potem jest w kod behind jest jakiś runner testów – to jest N-Unit albo xUnit. Jeszcze jest mstest dla tego specflowa. I rola testera może być taka – ja to na przykład praktykuję, że współpracuję z jednym kolegą, który jest testerem i on jakby dobiera te przypadki testowe, dobieramy je razem, a on też często proponuje, które są warte uwagi, bo lepiej zna biznesową aplikację i przez to też ta współpraca jest. Ważne jest BDD, moim zdaniem, żeby był ten element biznesowy. Chodzi mi o to, że tak naprawdę BDD jest sens pisania tych wszystkich scenariuszy i ficzerów jeśli ktoś inny oprócz nas będzie to czytał, bo jeżeli ma to być BDD, a sami jesteśmy w projekcie i tylko robimy to dla siebie, albo bo ktoś tak usłyszał – to jest to niepotrzebna abstrakcja. Jednak ja stosuję, i z sukcesem mogę powiedzieć, i BDD właśnie z osobami z biznesu, osobami, które znają jeszcze lepiej produkt, no bo są też dłużej. Przez to, tak jak wspominałeś, mamy fajny tak naprawdę dokumentację tego co się zmienia. Jeśli jakaś zmiana w kodzie jest to test nie przechodzi więc wiemy, że trzeba go naprawić i przez to jest to żyjąca dokumentacja i mamy wiedzę o systemie, bo testy są pisane tak, żeby każdy zrozumiał o co w nich chodzi. Moim zdaniem wtedy jest wartość. Tester może zacząć, to może być taki pierwszy krok, od pisania tych scenariuszy i dodawania ich do gita i do Code Review. To może być taki pierwszy krok.

Krzysztof: Jak wynika z Twojego doświadczenia – czy tester automatyczny to osobne stanowisko pracy czy jest to osoba, która łączy testowanie manualne i automatyzacje? Potrafię sobie wyobrazić, że w startupie czy też w korporacji może się to znacząco różnić, ale jestem ciekawy z jakimi przypadkami Ty miałeś do czynienia?

Michał: Wiesz co, różnie. Najczęściej to jest tak, że tester manualny chce przejść właśnie na testera automatycznego z różnych powodów. Nawet ostatnio mieliśmy jak PTaQ taką dyskusję luźną, że tak naprawdę powodu są z jednej strony, bo tester manualny ma w pewien sposób szklany sufit i chodzi troszeczkę o rozwój, jakby chciał zacząć coś nowego robić. Pojawia się też potrzeba tego, że coraz częściej testerzy są techniczni. Już tak naprawdę nie znam organizacji, które by raczej inwestowały w klikaczy, czyli osoby, które tylko klikają. Raczej już teraz się liczy i eksploracja i ta umiejętność devopsa i gita, i rozumienia kodu, debugowania go. Coraz częściej i więcej jest tych umiejętności technicznych. A ze stanowiskami bywa różne, czasami też organizacje nie wiedzą czego chcą, czasem tak bywa. Najczęściej z tego co ja widzę, z tych trendów to właśnie taka osoba techniczna z taką nutką testowania – albo kiedyś testowała, albo też się trochę na tym zna. Tak to widzę.

Krzysztof: Wobec tego – w jakim kierunku zmierza testowanie automatyczne? Czego możemy się spodziewać?

Michał: To jest bardzo ciekawe pytanie. Z najciekawszych takich ciekawostek albo ciekawych wykorzystani to widziałem jakiś czas temu wykorzystanie Amazon Lambda i pod spodem korzystanie z Selenium. Dzięki temu możemy mieć bardzo dużą ilość przypadków testowych, a testy wykonują się na przykład w kilku minut przez działanie Amazon Lambdy. Tych rozwiązań jest sporo ciekawych. Pojawiają się też fajne frameworki wspierające na przykład uruchamianie testów seleniowych w kontenerach, na przykład zalenium, to jest przez firmę Zalando, myślę znaną, jeśli chodzi o standardy marketingowe i stworzyli fajny framework, który pozwala na nagrywanie również wideo z testów, mieć dostęp do VNC podczas testów i poprzez to, że dostawali to do dokera to możemy w dość szybki sposób rozszerzać to. To jest fajna sprawa. Solenoid też polecam go. Jakiś czas temu napisałem o nim artykuł, bo jest naprawdę fajnym frameworkiem. Osoby, które go stworzyły próbowały uruchamiać kilkadziesiąt tysięcy testów i przez to sam Solenoid jest bezstanowy. Jeżeli mamy taką dużą ilość maszyn to jest to możliwe i to działa. To są też ciekawe rozwiązanie. Tych trendów trochę jest, ale tak naprawdę we wszystkich chodzi o to, żeby dostarczać szybciej.

Krzysztof: Dzięki za tę odpowiedź. Myślę, że zwłaszcza w IT będzie tak, że przyszłość z pewnością nas zaskoczy. OK Michał. Czy nie obawiasz się, że sztuczna inteligencja, o której tak dużo się mówi, która wkracza we wszelkie aspekty życia może być zagrożeniem dla testerów?

Michał: To jest ciekawe pytanie. Tak naprawdę, moim zdaniem to może być i zagrożenie, i szansa. Scenariusze są różne. Niektórzy podchodzą do tego pesymistycznie, niektórzy pozytywnie. Szczerze powiedziawszy sam nie wiem. Wydaje mi się, że IT to będzie raczej ostatni z obszarów, który będzie wspomagany w skrajnej formie przez inteligencje. Z drugiej strony może też pojawią się ograniczenia sztucznej inteligencji. Może dojdziemy do takiego etapu, że się okaże, że może coś będzie zbyt trudne do przeskoczenia. To jest ciekawe, a czy to będzie szansa czy zagrożenie to się dowiemy za jakiś czas.

Krzysztof: Dokładnie. Zgadzam się z Tobą. Z pewnością sztuczna inteligencja, machine learning i tego typu trendy pojawią się w IT. Zresztą, już są tak naprawdę i odcisną swoje piętno, ale myślę, że to pójdzie w tym kierunku, że będziemy widzieć zmiany i pewną ewolucję niż jakąś totalną zmianę pod tytułem „Roboty programujące” albo „Algorytmy, które za nas piszą programy.” Myślę, że to raczej nie pójdzie w tym kierunku. OK. Powiedzieliśmy tutaj, a w zasadzie Ty powiedziałeś, że piszesz artykuły, ja powiedziałem, że prowadzisz swój blog, wygłaszasz prelekcje, nagrywasz podcast o testowaniu, o którym wspomnieliśmy. Czy według Ciebie jest to zawód przyszłości, skoro inwestujesz swój czas, działasz w społeczności testerskiej? Czy to jest zawód dla Ciebie? Czy to jest zawód przyszłości?

Michał: Ja się czuję właśnie testerem, znaczy programistą testów i myślę, że jak najbardziej, bo tych obszarów, które się pojawiają wokół wytwarzania oprogramowania, czyli trochę dewops, trochę zajmujesz się tymi sprawami. Myślę, że jak najbardziej. Trend widać, że jest coraz bardziej popularny na naszych spotkaniach takowych, które organizujemy. Tak naprawdę teraz często pojawia się ponad 100 osób. Mieliśmy w tym roku kilka takich spotkań. Jak na to, że spotkania są często po pracy, osoby mogą być zmęczone – jak widać te zainteresowanie jest spore. Również wiele konferencji testerkich ma wyprzedawane bilety, więc widać, że to zainteresowanie jest i jakby coraz więcej organizacji na to zwraca uwagę. Myślę, że kiedyś bardziej tester był traktowany jako taka kula u nogi, a teraz widać, że i automatyzacja i testowanie może dostarczać efekty to jakby na to zapotrzebowanie jest. Po za tym to jest inny obszar programowania. Mnie on ciekawi, więc tak, widzę sporo rzeczy ciekawych jeszcze do rozwoju.

Krzysztof: Ja obserwuję takie zjawisko, że jakiś czas temu jeszcze zawód testera traktowany był jako taka furtka do IT, wiele osób chciało tutaj wejść. Wydawało się, że próg wejścia jest stosunkowo nisko. I faktycznie może dla zawodu testera manualnego było to prawdą, natomiast automatyzacja testów mam wrażenie, że to już jest zupełnie inny poziom, tak jak już tutaj powiedzieliśmy, wymagający wiedzy znacznie szerszej z programowania, infrastruktury, z projektu. Wydaje mi się też, że ta branża testerska bardzo szybko się zmienia i zachodzą w niej naprawdę duże zmiany, polegające na tym, że nie dosyć, że trzeba znacznie większą wiedzą i umiejętnościami dysponować to jeszcze, mam wrażenie, że zaczyna się taki etap, gdzie nie ma już testera jednego, który robi wszystko. Zaczynają się pewnego rodzaju specjalizacje, na przykład od aplikacji mobilnych, deskopowych, webowych. Czy też coś podobnego obserwujesz?

Michał: Tak, myślę, że tak. Tak jak wspominałem, to że testerzy są coraz bardziej techniczni, często potrafią bardzo dobrze SQLa, jakiś język programowania, interesują się devopsem, wiedzą czym jest Jenkins, jak się go używa. Coraz więcej jest tam wiedzy informatycznie i to moim zdaniem jest bardzo dobrze, bo jeżeli te braki informatyczne są to czasami nie wiemy, jak to przetestować. Możemy nie wiedzieć nawet, że jakiś przypadek testowy mógłby wystąpić, a te podstawy informatyczne są bardzo ważne, żeby je mieć. Jak rozmawiam ze znajomymi, którzy zatrudniają również do różnych organizacji to mówią, że często osoba przychodzi, jest po jakimś kursie, ale brakuje też takich podstaw informatycznych, które są teraz bardzo ważne. To może być też taka rada dla osoby, która by chciała iść w testowanie czy potem może w automatyzacje, to jest to, żeby poznać czym jest HTTP, jak postawić stronę, oczywiście jeśli nie studiowaliśmy informatyki, no bo jeżeli studiowaliśmy to zakładam, że mamy te podstawy, to żeby je poznać, bo to ułatwi tez zrozumienie co z czego wynika i może nam pomóc w pierwszej pracy.

Krzysztof: OK, Michał, zmierzając do końca. Co byś poradził osobie, która myśli o karierze testera automatycznego? Lub jest testerem manualnym i chce się rozwijać – w którym kierunku najlepiej iść? W jaki sposób pokierować swoją karierą? Skąd czerpać wiedzę? Może jakieś certyfikaty?

Michał: Pewnie. Przede wszystkim, moim zdaniem, nauka takiego testowania na początek, żeby mieć ten mindset testera. Jak to zrobić? Najlepiej poprzez praktykę. Jeżeli chcemy wejść w tę branżę to najlepiej pójść na jakieś praktyki, zrobić może jakiś kurs. Starać się nauczyć tej informatyki. Mamy wiele tych źródeł w Internecie, które pozwolą nam na to. mamy te kursy MOC tak zwane, czyli organizowane przez znane uniwersytety, które również wykładają podstawy informatyki. Jak najbardziej możemy od tego zacząć, to jest moim zdaniem fajna sprawa, żeby te podstawy informatyki posiąść. No na pewno angielski, to jest ważna sprawa, żeby go szkolić, bo coraz więcej jednak organizacji go używa. To jest standard, żeby się poruszać w angielskich. Często warto potrafić jeszcze dodatkowy język, to tam na pewno pomoże w karierze. Czyli pierwszy krok – poznanie testowanie. Potem nauka programowania – to jest moim zdaniem podstawa, bo widzę, że czasem osoby zaczynają automatyzować i uczą się tych komend na pamięć, zamiast zobaczyć co z czego wynika, czym jest to ID, z którego korzystają, czym jest programowanie, czym jest aplikacja konsolowa, okienkowa. Popróbować i zaciekawić się tym, wtedy ta automatyzacja przyjdzie nam łatwiej i ta nauka będzie łatwiejsza. To jest moim zdaniem bardzo ważne. Jeśli chodzi o źródła to polecam kanał ExecuteAutomation – to jest takiego chłopaka z Indii, bardzo ciekawy. Jest tam sporo podstaw, ale właśnie dla osób, które chcą się zapoznać od podstaw jest bardzo fajny. On ma również i stronę, i kanał na Youtubie – bardzo dużo materiałów ma za darmo. Ma jakieś kursy płatne, na nie patrzyłem, ale na Youtubie sporo jest ciekawych kursów od podstaw. Również na pluralsight – to taka strona, która zawiera dużą ilość kursów. Jeżeli mamy dostęp to tam jest sporo, na przykład o specflow, które są ciekawymi wstępami w automatyzacje selenium. Również o C sharpie jest tam wiele kursów i praktycznie o wszystkim, ale jeśli mamy dostęp do Pluralsight to tam możemy też tę wiedzę zdobywać. No i jeszcze bardzo polecam – to moim zdaniem najlepsza konferencja odnośnie automatyzacji – SeleniumConf. Nazywa się SeleniumConf ale tak naprawdę często osoby pokazują nie tylko selenium, więc są tam najlepsze prezentacje. W tamtym roku była w Berlinie i co ciekawe, wszystkie nagrania są dostępne na Youtubie, więc można sobie je przyswoić.

Krzysztof: Dodałbym jeszcze, że polecamy podcast Testing Parrot, który jest współprowadzony przez Michała. Nie zapominajmy o tym.

Michał: Dzięki. Wielkie dzięki.

Krzysztof: To ja Ci Michał bardzo dziękuje. Zawsze bardzo fajnie słucha się praktyka opowiadającego o swoich doświadczeniach. Myślę, że słuchacze skorzystają z Twojej wiedzy, doświadczeń i przede wszystkim porad, których tutaj wiele powiedziałeś. Powiedz proszę, gdzie Cię można znaleźć w Internecie? Jak się z Tobą najlepiej skontaktować?

Michał: Znaleźć mnie można przez mojego bloga testingplus.me. Staram się dosyć często dodawać nowe wpisy, także tam, jeśli się chcecie dowiedzieć czegoś o automatyzacji to polecam. Mój LinkedIn również polecam, jeśli ktoś chce się dowiedzieć czegoś o automatyzacji, służę pomocą. Również polecam słuchać naszego podcastu, który jest głównie skupiany na testowaniu. Mieliśmy ostatnio ciekawą dyskusję z koleżanką, która jest rekruterką – sporo w niej ciekawych rad. No i ostatnie to jeżeli jesteście z Poznania przyjść na PTaQ-a, nasz meetup – we wrześniu będzie spotkanie, wstęp jest darmowy i można się poznać i zainspirować, dowiedzieć nowych rzeczy.

Krzysztof: Oczywiście zapraszamy. Wszystkie linki znajdą się w opisie do tego odcinka. Ja Ci Michał jeszcze raz bardzo dziękuje i do usłyszenia! Cześć!

Michał: Wielkie dzięki za zaproszenie! Cześć!

I to na tyle z tego co przygotowałem dla Ciebie na dzisiaj. Myślę, że masz teraz lepsze wyobrażenie o pracy testera specjalizującego się w automatyzacji. W mojej opinii jest to kolejny krok w karierze testera, a z drugiej strony większa odpowiedzialność za utrzymanie jakości oprogramowania. Bardzo Ci dziękuje za wysłuchanie. Dzięki za kolejne oceny w iTunes. Jeśli masz jakieś 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, Spreaker lub innej aplikacji, na której słuchasz tego podcastu. Już teraz zapraszam Cię do kolejnych odcinków, a żeby ich nie przegapić odwiedź stronę htttps://porozmawiajmyoit.pl/newsletter i zapisz się na listę mailingową, aby otrzymać informację o zapowiedziach i nowych odcinkach. I to na tyle. Dzięki, hej!

mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny.