Do napisania tego posta natchnął mnie wpis na blogu Kuby Łopuszańskiego pt. Kilka rzeczy, o których żałuję, że nie powiedziano mi, gdy byłem młody

Mniej więcej 2,5 roku temu podjąłem decyzję o nauczeniu się programowania i przejściu do branży IT. Wcześniej przez ~8 lat zajmowałem się projektami w budownictwie i instalacjach sanitarnych. Przeszedłem drogę od inżyniera budowy przez konsultanta po PMa. Dziś po trochę ponad dwóch latach świadczenia usług w IT postanowiłem spisać rzeczy, które chciałbym żeby ktoś mi powiedział (lub móc powiedzieć sobie) na początku drogi związanej z przebranżowieniem.

Zacznij naukę od języka programowania, testowanie przyjdzie samo.

Żeby zacząć testować powinieneś wiedzieć czym są: css selektory, xpath, id. Poczytaj o tym czym jest DOM, jak może go przebudowywać JavaScript. HTMLa i XMLa zakładam, że już znasz. Jeżeli nie – to przeczytaj i napisz prostą stronę.

Wybierz dowolny język programowania, który Ci się podoba. Naprawdę nie ma znaczenia jaki. Python, Java, C#, JavaScript.  Napisz w nim pierwszy test, odpal Selenium (lub nakładki/wrappery do niego), jakiegoś drivera przeglądarki którą lubisz i napisz prosty test który zarejestruje użytkownika na demoqa.com. Poczytaj o Page Object Patternach i innych wzorcach projektowych. Spróbuj je zastosować w swoim projekcie. Podziel się kodem z kimś kto jest bardziej doświadczony i posłuchaj jego uwag.

W ciągu dwóch lat pisałem automaty w Javie, Pythonie i C#. Dlaczego? Bo zespół developerów potrafił mnie wesprzeć w momentach gdy mieli trochę luzu. Zawsze pisałem automaty w języku w którym pisany był projekt. Czy można inaczej? Pewnie tak. Czy można wtedy liczyć na pomoc developerów? Pewnie nie. Jeżeli potrafisz napisać test z użyciem Selenium w jednym z języków, napisanie go w drugim to tylko kwestia czasu.

Jeżeli potrafisz programować, to potrafisz też testować.

Developerzy są świetnymi testerami, często też wiedzą o bugach zanim dostaną raport od QA. Nie zachowuj się jakbyś odkrył amerykę, nie ciesz się z tego że wydaje Ci się, że znalazłeś coś co ktoś inny przeoczył. W 90% przypadków Developerzy wiedzą o problemach zanim je zgłosisz.

Mogę Cię zapewnić, że większość pozytywnych ścieżek aplikacji będzie działała poprawnie pod koniec developmentu. Z Tobą lub bez. To co możesz zrobić to wnieść inną perspektywę do wytwarzania oprogramowania. Szukaj przypadków brzegowych (edge case), wyjdź poza pudełko. Zwracaj uwagę na to na co inni nie zwracają. Zachowuj się jak użytkownik a nie programista. Zapytaj programistów co jest pokryte testami jednostkowymi (a najlepiej sam je przejrzyj i zrozum).

Nie idź na skróty. Odpowiedz sobie na pytanie – co Cię motywuje.

Najczęstsze powody dla których ludzie chcą testować:

  • wydaje im się to łatwe
  • słyszeli o dobrych zarobkach w IT
  • wydaje im się że mają „oko do detali”
  • chcą „jakoś” wystartować w IT

Te powody są złą motywacją. Bardzo złą. Twoja praca to ułatwianie developerom pracy, walidacja wymagań ze stakeholderami, pilnowanie żeby zespół czegoś nie przeoczył. Jeżeli na rozmowie wyjdzie, że poza wymienionymi powyżej czterema powodami nie znasz innych – Twoje szanse na pracę spadają.

To prawda, że testowanie jest łatwiejsze niż programowanie, ale… jeżeli nie rozumiesz czym różni się POST od PUT w protokole HTTP, to będzie ciężko Ci raportować błędy serwisów REST. Jeżeli nie wiesz czym różni się jQuery od Angulara i Reacta – ciężko będzie Ci wytłumaczyć developerom gdzie widzisz błąd.

Nie musisz opanować wymienionych technologii na poziomie senior developera, ale poziom wczesnego juniora sprawi że zespół będzie Cię traktował jak „swojego”. Poświęć czas na naukę i spróbuj napisać sam kilka prostych projektów.

Zadawanie typowych pytań jest niepotrzebne i blokuje Twój rozwój.

Sam pytałem o wszystko i wszędzie, straciłem czas na szukanie „najlepszego” sposobu na naukę. Nie znalazłem ani odpowiedzi, ani sposobu. Straciłem tylko karmę na reddicie i reputację na stackoverflow 😉

Pytanie które chcesz zadać (i odpowiedź na nie) już istnieje – na mikroblogu, grupach FB takich jak testowanie oprogramowania, reddicie czy stackoverflow. Ktoś już te pytania zadał, więc szanse że po raz n-ty dostaniesz na nie odpowiedź są coraz mniejsze. Na pytanie „od którego języka warto rozpocząć naukę” nie da się odpowiedzieć poprawnie. Są tylko opinie ludzi, którzy już się czegoś nauczyli (lub co gorsza takich którzy odpowiadają bez jakiejkolwiek wiedzy) – przez co są mocno subiektywni. Wpisz swoje pytanie w Google, jest duża szansa że znajdziesz na nie kilka odpowiedzi.

Kolejnym pytaniem nietechnicznym które wciąż się powtarza jest „Ile zarabia tester / programista w technologii x/y.„. Dokładnie tyle ile firma za niego kasuje klienta minus marża firmy. Ani mniej, ani więcej. Próba nauczenia się konkretnego języka ze względu na zarobki zazwyczaj się nie udaje. Polub to co robisz, a później myśl o pieniądzach. Jeżeli interesują Cię tylko zarobki, hydraulicy i stolarze zarabiają równie dobrze 😉

Sylabus ISTQB, certyfikaty i traktowanie tego jako startu nie przyniesie żadnych wymiernych efektów.

Zerknij na posty w social mediach. Co dzień lub dwa pojawiają się pytania „Zrobiłem certyfikat ISTQB – co dalej?”. Być może problemem jest mnóstwo kursów obiecujących gruszki na wierzbie, duża ilość ogłoszeń o prace w testowaniu oprogramowania, lub świetny marketing ISTQB. W 95% przypadków ten certyfikat może służyć za podkładkę pod kawę lub do powieszenia na ścianie. Papierek może być przydatny – ale nie gwarantuje niczego.

Płatne kursy w większości nie spełnią Twoich oczekiwań. A na pewno nie pomogą Twojej karierze.

Czy zapłacisz za nie sam, czy zapłaci za nie pracodawca. Na rynku testowania (który jest w miarę młody) mamy wysyp szkoleń (od podstaw). W internecie mamy wysyp tutoriali i postów na blogu, które pokazują jak coś zrobić od podstaw. Przychodzisz na szkolenie nazwane „Selenium dla zaawansowanych” po czym okazuje się, że 30% grupy nie wie jak napisać najprostszy test w Javie przy użyciu Selenium. W związku z tym prowadzący cofa się do podstaw (sic!). Tracą na tym firmy, tracą na tym uczestnicy, zyskują ludzie którzy nie powinni się na takim szkoleniu znaleźć.

Napisanie prostego frameworka do testów, opanowanie wrappera do Selenium, czy próba napisania istniejących testów w innym języku programowania da Ci wymierne korzyści. Ze szkoleniami 1-2 dniowymi bywa różnie (moje opinie o nich nie są najlepsze).

Umiejętność dobrej komunikacji jest cenniejsza niż dokładność w wykonywaniu zadań.

90% kłótni (lub różnicy zdań) w pracy wynika ze złej komunikacji międzyludzkiej. Wytłumacz i opisz dokładnie swój punkt widzenia. Rozmawiaj o faktach  a nie o tym co Ci się wydaje. Opinie zachowuj dla siebie. Zacznij wyjaśnienia od początku swojego procesu myślowego, nie ukrywaj informacji (nawet kosztem wydłużenia wyjaśnień), nie skracaj myśli zakładając że rozmówca wie o co Ci chodzi, wystrzegaj się uprzedzeń. Proste? Do dziś mam z tym problemy.

Naucz się od razu czym jest Continuous Integration, Continuous Delivery i Continuous Deployment

W której fazie uruchamiamy testy automatyczne? Kiedy należy zgłosić do PM/PO krytyczny błąd aplikacji? Czy błędy krytyczne na jednym środowisku będą reprodukowalne na pozostałych? Jakie mogą być przyczyny tego, że testy automatyczne pokazują błędy? Żeby dobrze odpowiedzieć na te pytania, powinieneś naprawdę rozumieć wasz wewnętrzny proces wytwarzania oprogramowania.

Jeżeli zaczniesz raportować błędy, które pojawiają się tylko na środowisku developerskim – masz dużą szansę na utratę statusu wśród developerów. A to znacznie utrudni Ci życie. Jeżeli nie będziesz rozumieć o czym rozmawia developer z devopsem, oni szybko to wyłapią. Jeżeli nie rozumiesz czegoś – zapytaj.

Dbaj o cudze emocje.

Jesteśmy ludźmi. Reagujemy emocjonalnie czy tego chcemy czy nie. Nie śmiej się z cudzych niedociągnięć. Na pewnym etapie współpracy emocje i animozje są w stanie rozbić zespół. Pamiętaj, że z racji Twojej pozycji 90% informacji które przekazujesz w pracy to „złe wieści”. Powiedz głośno raz na jakiś czas do zespołu „ale ładnie wyczyszczone zgłoszenia bugów w Jirze, dziękuję”. Rozmawiaj z ludźmi nieformalnie, pytaj, wyjaśniaj – a dopiero na końcu raportuj. Zdziwisz się ile osób chętnie Ci pomoże, jeżeli powiesz wprost że usunięcie błędu „X” bardzo pomoże Ci w Twoich obowiązkach zawodowych.

Testerzy manualni konkurują między sobą ceną. Testerzy automatyczni – jakością.

Poznałem dość sporą liczbę osób, które nie bardzo chcą się rozwijać w kierunku automatów. O ile Twoja ścieżka kariery idzie w stronę zarządzania lub bycia architektem (to też się zdarza) – to pamiętaj, że są kraje na świecie gdzie zatrudnienie „klikacza” jest 2 lub 3 razy tańsze niż w Polsce. Przy globalizacji rynku IT, to tylko kwestia czasu aż prace „mniej wymagające” będą outsourcowane do tańszych krajów. Pamiętaj o tym, za każdym razem kiedy przyjdzie Ci do głowy, że „nie warto się uczyć” nowych rzeczy. To grozi wypadnięciem z obiegu.

Ucz się, rozwijaj, czytaj. Praca w IT wymaga nieustannego dokształcania. Do samej emerytury.