Kilka rzeczy, o których żałuję że nie powiedziano mi, gdy zmieniałem branżę na IT.


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ć:

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.


Otagowano: , ,

Kategoria: wymysły

9 odpowiedzi do: “Kilka rzeczy, o których żałuję że nie powiedziano mi, gdy zmieniałem branżę na IT.“  

  • Marcin piszę:

    Witam,
    Zawsze cenie sobie szczere wpisy oparte na doświadczeniu, nie na przeczytanej lekturze. Jedyne co mnie trochę ukłuło, to akapit o motywacji i najczestsze powody dla których ludzie chcą zacząć testować. Osobiście uważam, ze kazda motywacja jest dobra do tego, aby zacząć testować, programować, lub zmienić branże, jeśli tylko powoduje to, ze jesteś dobrym pracownikiem. Nawet jeśli tego nie lubisz, a robisz to poprawnie i rozwijasz sie w danym kierunku, nie widzę przeszkód, aby to robić. Zauważyłem, ze zanim sie przebranzowiles Twoja ścieżka zawodowa wyglądała dość ciekawe, dlatego bardzo jestem ciekaw co Ciebie skłoniło by zacząć rozwijać sie w kierunku IT?

    • Runaurufu piszę:

      „Nawet jeśli tego nie lubisz, a robisz to poprawnie i rozwijasz sie w danym kierunku, nie widzę przeszkód, aby to robić.”
      Ja za to widzę… testowanie i programowanie… i w zasadzie większość prac „umysłowych” ma jedną bardzo ważną cechę wspólną – ciężko je wykonywać gdy nienawidzi się swojej pracy. To nie znaczy, że nie można – bo człowiek zmusi się do wszystkiego – pytanie tylko ile wytrzymasz Ty i ile wytrzymają Twoi współpracownicy.

      Jeśli chcesz zmienić branżę (chcesz, a nie musisz) to nie zmieniaj na taką, w której będzie ci źle – poszukaj tego co będzie budzić uśmiech na Twej twarzy.

    • Michal Dobrzycki piszę:

      W dużym skrócie zmęczenie aktualną pracą i brak radości z tego co robię (robiłem to poprawnie, nie lubiłem tego, przestałem się dalej rozwijać). Dlaczego testowanie / automaty? Zadałem sobie pytanie: „Co potrafię robić, mogę to sprzedać i sprawa mi frajdę?” Wyszło coś pomiędzy testowaniem i programowaniem.

      W pierwszej pracy w IT zarobki spadły mi o ~50% w porównaniu do poprzedniej pracy. Wciąż uważam, że było warto 😉

  • Marcin piszę:

    Jestem programistą. Często widzę wpisy ludzi, którzy się przebranzowili i w większości są irytujące. Autorzy opisują swój urojony obraz IT. Dodatkowo większość z tych wpisów leczy kompleksy autorow i czytamy, jak to testowanie jest trudniejsze od programowania bo trzeba „widzieć szerzej” i jak to programiści klepią na pałę nic nie rozumiejąc. Ci autorzy niewiele wiedzą. Nie wiedzą np. że dobre praktyki programowania zakładają, że programiści piszą bardzo dużo różnych rodzajów testów (jednostkowe, integracyjne, nawet funkcjonalne np. w Selenium dla kluczowych funkcji aplikacji).

    Twój wpis jest pierwszym tego typu wpisem, z którym się zgadzam. Potrzebujemy więcej testerów takich jak Ty. Testerów którzy znają podstawy technologii, które testują, a nie tylko klikaczy. Muszę powiedzieć, że nigdy w pracy nie spotkałem testera takiego jak Ty 🙂

    • Gosia piszę:

      Bardzo wartościowy i mądry wpis. Takich nam na rynku brakuje. Zgadzam się z komentarzem Marcina, który twierdzi, że autorzy opisują swój urojony obraz IT. Większość (albo może część) nie zdaje sobie sprawy, że testy jednostowe w zasadzie zawsze (z mojego doświadczenia) są pisane przez programistów (programiści umieją testować powiedziałby ktoś ?;)) , ale nie tylko jednostkowe ( i pisze to QA nie programistka :)). Probrem polega też na tym, że dzisiaj co druga osoba chce prowadzić bloga a internet jak papier „wszystko przymnie”. Czekamy na więcej interesujących wpisów. Pozdrawiam 🙂

    • Antey piszę:

      @Marcin
      Jeżeli negujesz fakt, że większość branży „klepie na pałę” niezaleznie od specjalności, to znaczy że albo miałeś ogromne szczęście zawodowe, albo nie wiesz o czym piszesz. Prawdopodobieństwo oceń sam.

      Tester wręcz NIE POWINIEN znać technologii – tester ma poza charakterem znać i rozumieć biznes. Tester to de facto symulator specyficznego użytkownika, a nie wannabe developer któremu się matmy uczyć nie chciało.

      Role analityków: systemowego/biznesowego/testów obiły Ci się w ogóle o uszy ?
      Bo autor najwyraźniej to pominął, podobnie jak fakt że devops to nie stanowisko ani nie człowiek.

  • Michał piszę:

    Bardzo ciekawy artykuł, mi właśnie otworzył oczy na wejscie w C#, to tej pory tylko JAVA i JAVA 🙂 szczególnie ostanie zdanie godne zacytowania:
    „Ucz się, rozwijaj, czytaj. Praca w IT wymaga nieustannego dokształcania. Do samej emerytury.”
    PS. Tylko jak tu liczyć na dobrą emeryture?
    pozdrawiam

  • Kasia piszę:

    Nauka programowanie nie jest równa umiejętności testowania. Bo to, że potrafisz napisać test automatyczny nie oznacza że wiesz jakie dane testowe dobrać, na co zwrócić uwagę przy testach usability, bezpieczeństwa.

    Tak testerzy powinni interesować się technologiami w jakich wykonane są aplikacje. Ale pójście w opcję tylko automaty jest ślepą uliczą. Bo testy automatyczne może równie dobrze napisać developer, który będzie miał wyższe umeijętności programowania i taką samą wiedzę o projektowaniu testów co tester auttomatyczny który nigdy nie interesował się technikami testów.

  • Antifragile – jak i czym konkurować w wytwarzaniu oprogramowania? – SCV Consultants piszę:

    […] słowach krytyki i wsparcia dotyczących mojego poprzedniego postu postanowiłem opisać spojrzenie od strony klienta / stakeholderów dotyczących jakości […]