Świat się zmienia. Ciężko z tym polemizować. Wiek pary, wiek elektryczności, wiek komputerów. Obecnie znajdujemy się w okresie określanym jako „industry 4.0”, w którym dzięki szerokiemu zastosowaniu internetu, automatyzacji i przetwarzania danych, powoli zaciera się granica między człowiekiem a maszyną. Jak wpłynie to na kształt znanego nam IT? Analiza w dalszej części wpisu.

Jednym z zasadniczych plusów blogowania jest możliwość stałego poszerzania wiedzy. Komentarze pod artykułem nierzadko mają większą wartość niż sam wpis blogera. Podobnie jest z wiadomościami od czytelników. Taka właśnie wiadomość od Marcina Konwerskiego była inspiracją dzisiejszego wpisu. Marcin pisze:

Jestem testerem i zastanawiam się czy to stanowisko jest zagrożone. W chwili obecnej całe IT to eldorado ale to musi się kiedyś skończyć. Ktoś zacznie liczyć koszty i się kapnie że przejście z fail-safe do safe to fail jest opłacalne. Chciałbym poznać twoją opinie na ten temat.

Marcin bardzo trafnie przedstawił bliski mi punkt widzenia na to, jak dzisiaj wygląda rozwój projektów IT. Zastanówmy się więc głębiej nad odpowiedzią.

Więcej niż małpki?

O tzw. testerach manualnych słyszałem bardzo różne opinie. Jedni uważali, że ich funkcję równie dobrze mogłyby pełnić przyuczone małpy. Inni twierdzili, że to bardzo trudny zawód, wymagający nielichych umiejętności. Jak jest naprawdę? Odpowiedź brzmi jak zwykle w IT – to zależy. Jest grupa osób, które w roli testera widzą prostego użytkownika aplikacji. Taką samą wartość jak w zatrudnianiu 20 studentów dostrzegają w wykorzystaniu platform takich, jak Amazon Mechanical Turk. Tylko czy takie „klikanie” po aplikacji faktycznie jest efektywne? Wątpię. Z pewnością pokryje ścieżki pozytywne (w taki sposób większość ludzi używa aplikacji). Jednak sporo poważnych błędów będzie miała się dobrze. Równie dobrze moglibyśmy zatrudnić do tego swoje dzieci.

Co umie tester?

Kim dla mnie jest dobry tester? To ktoś posiadający bardzo specyficzne umiejętności analityczne. Analitycznego szukania dziury w całym. Programista, widząc wymaganie „przy zamówieniu 5 książek wysyłka ma być darmowa”, od razu widzi prostego ifa. Jeżeli liczba książek jest większa lub równa pięć, ustaw koszt wysyłki zamówienia na zero złotych. I super. Robota zrobiona, fajrant, wypłata 15k. A co mówi dobry tester? „Krótkie wymaganie. Na pewno nie przewidzieli większości scenariuszy”. I zaczyna się seria niewygodnych pytań:

Tester: A co jeżeli będą dostępne 2, a 3 zostaną wysłane dopiero drugą paczką? To obie będą za darmo?

Klient: Hmmm, nie. Wtedy nie. Wszystkie muszą wyjść w jednej paczce.

Programista: (Nowy if.)

Tester: A jak zamówię 5 książek i zmywarkę to też będę miał darmową wysyłkę?

Klient: No nie – oczywiście, że nie. Tylko książki.

Programista: (Ehhh, kolejny if.)

Tester: A 4 ebooki i jedną drukowaną?

Klient: To też nie. Musza być wszystkie drukowane.

Programista: (Chyba trzeba będzie jednak powtórzyć szacowanie.)

Obecnie w projektach IT rezygnuje się z klasycznej roli analityka. Dość szeroko omawia tę sytuację Jakub Nabrdalik w prezentacji User Stories considered harmful. Po części ta rola przechodzi właśnie na testerów, bo mają oni znacznie bardziej niż inne profesje rozwiniętą zdolność zgłębiania wymagań.

Serce programisty

Stare przysłowie IT mówi, że tester powinien mieć serce programisty. W słoiku na biurku. I faktycznie – dobry tester wie, jak przyprawić developerów o szybsze bicie serca. Natomiast w obecnych czasach powinien mieć je już nie tylko na biurku. Zwiększanie częstotliwości wdrożeń, nawet do modelu ciągłego dostarczania, zmienia reguły kontroli jakości oprogramowania. Skracanie czasu od zbudowania paczki do jej produkcyjnego uruchomienia do godzin czy kilkunastu minut, w sposób oczywisty wyklucza możliwość manualnej weryfikacji jakości. W dużych projektach testy potrafiły zajmować całe tygodnie. O skompresowaniu ich do godziny nie ma nawet co marzyć. Przynajmniej, jeżeli nie zastąpimy ludzi automatami. Te ostatnie mają sporo zalet. Są całkowicie powtarzalne, nie miewają gorszych dni ani kaca. Dużo łatwiej estymować czas ich trwania. I ciężko zaprzeczyć temu, że w tę stronę zmierzamy.

Takie czołgi można kupić w każdym sklepie z czołgami

Wiele memów od czasu aneksji Krymu w tym stylu komentuje nieprawdopodobne wydarzenia. A skąd wziąć automaty do testów? Czy są w każdym sklepie z automatami? Tutaj właśnie do gry wkraczają osoby, które łączą doświadczenie testerskie z umiejętnością programowania. Z naciskiem na to pierwsze. To zresztą pokrywa się często z popularną testerską ścieżką kariery. Tester manualny -> tester automatyzujący -> programista. Ten ostatni etap wynika często z wypalenia zawodowego lub też ciągot w stronę wyższych zarobków (co powoli zaczyna się w wielu przypadkach zacierać) . Natomiast ten pierwszy krok jest obecnie według mnie obligatoryjny. Wielu testerów już posiada umiejętność wykonywania zapytań na relacyjnych i nierelacyjnych bazach danych. Kolejnym krokiem jest zatem poznanie podstaw programowania. Na temat popularnych języków takich, jak Python, Java czy Groovy, bezpłatnych kursów, tutoriali, książek i prezentacji z konferencji znajdziemy tysiące. O ile do przygotowania wygodnego frameworku testów akceptacyjnych w projekcie wymagane jest naprawdę duże doświadczenie i wyczucie, o tyle do jego sprawnego wykorzystania można przystąpić dość szybko.

Tester idealny

Czy ktoś taki istnieje? Pewnie nie. Jednak nie mogłem się powstrzymać przed uzewnętrznieniem swojej wizji takiej osoby. Na pewno wspomniana wcześniej znajomość baz danych i programowania jest podstawą. Pisanie testów automatycznych z wykorzystaniem technologii takich, jak Geb, RestAssured etc., pozwoli  weryfikować zarówno interfejs użytkownika, jak i API. Jeżeli testy wykryją błąd, potrafi przejrzeć logi, zalogować się ssh na serwer, zerknąć na zmiany w kodzie aplikacji i wstępnie określić przyczynę błędu. Oczywiście nie przeanalizuje w pełni problemu z transakcjami czy race-condition, ale brakujący wykrzyknik w warunku if – czemu nie. Poza tym wsparcie w analizie biznesowej wymagań, a może nawet wzięcie za nią odpowiedzialności.

TLDR

Czy testerzy są zagrożeni? Absolutnie nie. Czy muszą się zmienić, aby przeżyć? Oczywiście tak. Czy statystyczny programista może zastąpić dobrego testera? Wątpię – inny sposób myślenia.

A jakie jest Wasze zdanie na ten temat? Zapraszam do dyskusji.

11
Dodaj komentarz

avatar
6 Comment threads
5 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
7 Comment authors
Jakub KubryńskiŁukaszOlaPatrykG.J. Recent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Paweł
Gość
Paweł

Panie Jakubie, Pełna zgoda z tezami postawionymi w artykule – dorzuciłbym jedynie, iż praca dla testerów manualnych, którzy nie mają ochoty bądź zdolności do ewolucji w strone automatyzacji również nie jest zagrożona w perspektywie „nastu” lat – a to za sprawą olbrzymich „legacy” projektów i instytucji, w której utrzymywane są starodawne twory, rozwijane skomplikowane okołobankowe systemy etc.. Rozwój oprogramowania (a właściwie tempo rozwoju) w takich firmach nie implikuje konieczności automatyzacji „wszystkiego co się rusza”. Nie mniej dla dobra każdej osoby poruszającej się w obrembie IT jest ciągły rozwój – taka specyfika branży – więc na pewno nie należy liczyć na… Czytaj więcej »

Sebastian
Gość

Ciekawy artykuł, widać jednak, że autor albo nigdy nie był testerem albo miał styczność z pseudo testerami, którzy nie mieli większych ambicji. Czy to tester manualny czy automatyczny musi się rozwijać i odważę się postawić tezę, że to właśnie tester manualny powinien zdobywać więcej wiedzy (teoretycznej oraz praktycznej). Co do głównego wątku uważam, że to właśnie zawody związane bezpośrednio z programowaniem mogą być zagrożone – czyli programista oraz tester automatyczny. Programowanie zostanie zastąpione przez maszyny i pozostaną tylko testerzy, którzy swoją ludzką umiejętnością twórczego myślenia (czyt. tester manualny) będą musieli sprawdzić czy przypadkiem maszyny nie planują ataku na świat… 😉… Czytaj więcej »

G.J.
Gość
G.J.

Szanuję za użycie nazwy „tester automatyzujący”, zamiast niestety wciąż jeszcze popularnego sformułowania „tester automatyczny”.

Patryk
Gość
Patryk

Dobry artykuł, seria niewygodnych pytań jest znakomicie przedstawiona.

Brakuje mi tylko informacji, która potrzebują testerzy a jest o tym mało mówione, albo zapominane. Testerzy (których głównym zdaniem jest zdobycie informacji) muszą mieć odpowiednie soft skills. W pracy „manualnej” bez odpowiednich umiejętności komunikacji (czy bugów czy raportów testowych) nie ma dobrych testerów. Bo koniec końców, jeżeli dobrze nie przedstawimy problemu to on nigdy nie zostanie naprawiony.

Ola
Gość
Ola

Kuba, bardzo dobry wpis, czekam na artykuł „Czy programiści są potrzebni?” 😉 Masz jakieś doświadczenia z testerami, którzy wywodzą się z programowania vs programistami wywodzącymi się z testowania?

Zastanawiam się też, dlaczego panuje przekonanie o tym, że bycie testerem jest łatwiejsze, niż bycie programistą. Tak najczęściej myślą osoby, które wchodzą do branży i taki obraz wysyłamy (głównie programiści oczywiście) w świat. Jak pisał Sebastian, dobre testowanie manualne jest trudną sztuką, bo wymaga wiedzy biznesowej i technicznej, a sprowadzone jest do małpiego klikania (a chaos monkeys przecież już zautomatyzowano)…

Łukasz
Gość

Dobre podejście do sprawy. Dodałbym do tego problem hype’u na rewolucję życiową, np. pod tytułem „przekwalifikowanie na testera”. Znam przypadki takiej zmiany, gdzie osoba zupełnie nie-IT poszła w działkę testerską. Odbyło się to prawdopodobnie w przekonaniu, że bycie testerem to taka właśnie „małpia” ale i nieźle płatna robota. Nie wiem czy do takiej wizji nie dokładają swojego firmy szkoleniowe, które wykorzystują obecny czas… W każdym razie, próby te skończyły się niepowodzeniem, bo tak jak piszesz – tester to coś więcej niż klikacz. Ja cenię takie osoby właśnie za umiejętność zadawania pytań, za szersze widzenie problemów, którego zamknięci w swoim boksie… Czytaj więcej »