"Jeśli miał prawidłową budowę i był silny, nakazywali go żywić i przydzielali mu z dziewięciu tysięcy działów ziemi. Jeśli miał wadliwą budowę, odsyłali go na miejsce zwane Apothetai, będące urwiskiem w górach Tajgetu. Sądzili bowiem, że lepiej było dla niego samego i dla polis, aby nie żyło to, co od samego początku nie miało zdrowia i siły do testowania" - wychowanie Spartan, Plutarch*
Całe szczęście czasy Spartan dawno już minęły i nikt nie kontynuuje tej barbarzyńskiej tradycji zrzucania nieogarniętych juniorów ze skały w górach Tajgetu. Nie oznacza to jednak, że juniorzy powinni sobie jakoś bardziej folgować tuż po znalezieniu swojej pierwszej pracy w IT. Tak naprawdę to właśnie teraz zabawa dopiero się zaczyna. Gdy wspominam czasy, gdy to ja byłem juniorem stawiającym swoje pierwsze kroki w świecie software’u, uczuciem, które dominowało w mojej głowie było wszechogarniające zagubienie. Nie bardzo wiedziałem, jak zabrać się do większości zadań, które otrzymywałem. Nie do końca znałem składnię języka, w którym miałem je realizować. Nie byłem pewny, czy jestem mentalnie gotowy do ogarnięcia tych gór złota, które ta branża oferowała. Całe 15 zł/h – ludzie na wiosce zaczęli nagle mówić mi per pan.
Dla młodych testerów brak znajomości składni języka programowania nie będzie oczywiście problemem tak jak dla mnie. Zestaw waszych wyzwań jest inny. Głównym zadaniem testera jest – uwaga – testowanie. To na czym powinniście się skupić w pierwszych dniach, tygodniach i miesiącach waszej pracy to przygotowanie sobie gruntu pod tą właśnie czynność. A żeby to zrobić, musicie jak najlepiej poznać ekosystem, w którym będziecie się poruszać oraz wejść w odpowiedni mindset. Oto kilka praktycznych rad, które pomogą wam poradzić sobie z pierwszymi dniami w nowej pracy.
Zbudujcie mindset
Każdy kto zatrudnia juniora i ma ociupinkę zdrowego rozsądku zdaje sobie sprawę, że potrzeba trochę czasu zanim zacznie on efektywnie wykonywać swoje obowiązki. Dlatego, jeżeli coś wam zajmuje – w waszym przekonaniu – zbyt dużo czasu, często czegoś nie wiecie i macie sporo pytań, robicie jakieś błędy i nie możecie za bardzo się odnaleźć – nie przejmujcie się tym! To nie ma tak wielkiego znaczenia i jest po prostu wpisane w charakterystykę pracy juniora. Dlatego junior jest juniorem, ponieważ dopiero musi się wszystkiego nauczyć. A to trochę trwa.
To co jest istotne to wasze podejście i nastawienie. Nikt was nie zrzuci ze skały, jeżeli zespół będzie widział, że cały czas próbujecie rozwiązywać problemy, które napotykacie na drodze, zadajecie wnikliwe pytania, nie poddajecie się i nie brakuje wam entuzjazmu do nauki. Z drugiej stronny, nie ma nic gorszego niż załamany, nieporadny junior, który tylko cały czas siedzi i nic sensownego nie robi przez cały dzień, ani nie zapyta, ani nic nie powie, ani me, ani be, tylko „kmini” bez żadnych rezultatów. Dla takich kierunek jest tylko jeden – Tajget.
Rozpoznajcie teren
Warunkiem koniecznym skutecznego przeprowadzania testów jest dobra znajomość terenu, po którym się poruszacie. Dlatego już od pierwszych dni powinniście rysować sobie mapę oprogramowania, które testujecie. Tak – mapę – i nie jest to bynajmniej żadna kwiecista metafora. Otwórzcie painta albo cokolwiek innego (ja lubię https://excalidraw.com/) i po prostu rysujcie zależności pomiędzy poszczególnymi serwisami, notujcie co rozmawia z czym, co na co wpływa i od czego zależy, który serwis woła którą bazę danych itp. I nie chodzi mi tutaj o to, żebyście już pierwszego dnia przygotowali pełny plan architektury całego oprogramowania w firmie – idźcie małymi kroczkami. Jeżeli dzisiaj testujecie UI do zarządzania userami, i wiecie, że woła on serwis o enigmatycznej nazwie „usersService”, który jest zahostowany pod adresem http://some-url.com:3000 to rozrysujcie to w swojej mapce.
Ktoś mógłby spytać: a po co, a dlaczego? Chodzi o to, żebyście coraz więcej problemów mogli rozwiązywać sami. Przeprowadzać coraz dokładniejsze testy bez konieczności pytania kolegów o to, co wy właściwie musicie przetestować. Następnym razem, jak ktoś powie wam „hej juniorze, zmieniłem parę rzeczy w usersService, przetestujesz mi to?” to nie musicie się go pytać co jeszcze przy okazji mógł popsuć, tylko patrzycie na swoją mapkę i sami mówicie „jasne! Sprawdzę od razu usersUI czy tam wszystko dalej śmiga jak należy!”. Tester, któremu nie trzeba pokazywać palcem, gdzie dokładnie ma testować, to skarb.
Róbcie notatki
Nikt nie lubi odpowiadać na te same pytania po 10 razy, więc jeżeli pytacie kolegów z pracy jaki jest adres do Kibany (oprogramowanie do przeglądania logów) to sobie gdzieś ten adres zanotujcie, żeby nie pytać ich za tydzień o to kolejny raz. Jak pytacie o credentiale do użytkownika testowego na środowisku QA to sobie je gdzieś zapiszcie (jeżeli firma nie ma jakiegoś oprogramowania do centralnego przechowywania credentiali jak LastPass – jeżeli ma, to poproście o dostęp). Jeżeli waszym obowiązkiem jest deployment serwisów na środowisko testowe, co wymaga przeprowadzenia jakiejś złożonej procedury to skrupulatnie rozpiszcie każdy krok, żebyście mogli to potem za miesiąc, jak przyjdzie taka potrzeba, odtworzyć samodzielnie.
Zadawajcie mądre pytania
Mówi się, że nie ma głupich pytań – ale nie mogę się z tym stwierdzeniem zgodzić. Jest wiele różnych rodzajów głupich pytań. Najgłupszym, z którym osobiście miałem do czynienia, to gdy pewien junior, który budował ze mną pewien serwis spytał mnie, tydzień po tym, gdy skończył pracę i musiał do niej z pewnych powodów wrócić:
„czy w tym serwisie jest swagger?”
Myślałem, że żartuje, dlatego powiedziałem:
„kolego, przecież to twój kod, sam dodawałeś tam swaggera tydzień temu”,
„aha, no faktycznie. O, jest swagger!”.
Jak się okazało nie żartował. Serwis składał się z trzech plików, a jeden z nich nazywał się „swagger.yaml”. Załapał u mnie srogiego minusa. Smutna to historia, ale takie jest życie – pomyślcie o tym sami. Chętnych na stanowisko juniora jest naprawdę wielu i nie ma najmniejszego sensu inwestować czasu w kogoś, kto po prostu nie rokuje. A inteligencja jest czymś wysoce pożądanym w tym zawodzie. Więc nawet jeżeli ktoś potrafi programować lepiej niż inni, ale widać z góry, że „nie ogarnia” to lepiej wziąć kogoś kto nawet nie widział kodu na oczy, ale bije od niego aura ogarniacza. Dokładnie tak samo jest z testerami.
Więc skupmy się na tym, jak zadawać pytania, żeby nie wyjść na głupka. I zdaję sobie sprawę, że nie brzmi to poprawnie politycznie, ale taka jest niestety gorzka prawda. Po tym jakie zadajemy pytania bardzo łatwo można nas zaszufladkować – a tego przecież chcemy uniknąć.
Żeby zadać mądre pytanie, trzeba przede wszystkim wiedzieć o co chcemy spytać – i właśnie po to od dnia zero rysujemy mapę naszego ekosystemu oraz robimy skrupulatne notatki. Dzięki temu nie musimy za każdym razem pytać o wszystko od nowa. Weźmy userService – kolega programista mówi, że trzeba tam potestować. Możemy spytać: „a co to jest ten userService?”. Błąd! Głupie pytanie. Przecież wiemy co to jest, testowaliśmy to tydzień temu. Lepiej zapytajmy tak: „ok, przetestuje userService, pewnie warto dodatkowo sprawdzić userUI, a czy są jeszcze jakieś inne powiązane serwisy, które powinienem sprawdzić po Twoich zmianach?”. Jak okaże się, że są – to dorysujcie je do mapy, następnym razem będziecie już wiedzieć.
Inne głupie pytania to takie, na które odpowiedź możecie sami znaleźć w googlu w ciągu 5 sekund szukania. Mądre pytania to takie, na które spróbowaliście odpowiedzieć sobie sami, ale z jakiś powodów wam się nie udało. Na przykład, szukacie w Internecie jak użyć Kibany, i jak napisać kwerendę, która wyfiltruje wam logi dla serwisu usersService – ale bezskutecznie. Zapytajcie kolegi jak to zrobić: „hej Staszku! Pomożesz mi z Kibaną? Próbowałem tak i tak, ale nie chce mi zadziałać, co robię źle?”. Moglibyście oczywiście spytać: „Staszku, jak się używa Kibany” – ale to byłaby oznaka lenistwa – nie bądźcie leniwi. Na lenistwo przyjdzie czas jak będziecie seniorami.
Nie kręćcie nosem jak dostajecie nudne zadania
Niestety, jedną z wad bycia juniorem jest to, że często będziecie dostawać te zadania, których nie chce się robić seniorom. Takie są prawa wszechświata – pogódźcie się z tym. Nikt nie zatrudnia was po to, żebyście mogli się uczyć i dobrze bawić – raczej po to, żeby po taniości (taniej niż godzinami seniora) zrobić rzeczy, które ktoś zrobić musi. Ale za to jak wpadnie coś ciekawego, to postarajcie się wyciągnąć z tego tyle wiedzy, ile się da. Nie bójcie się zadawać (mądrych) pytań i nie bójcie się robić błędów.
Podsumowanie
To chyba już wszystkie złote rady, które dla was mam. Wydaje mi się, że można by je skrócić do jednej prostej sentencji: bądźcie proaktywni. Im więcej zaangażowania i skrupulatności po waszej stronie, tym szybciej minie ten pierwszy czas zagubienia w nowej pracy. A poza tym – ludzie lubią pracować z osobami, które są proaktywne.
*Prawdziwa treść cytatu: „Jeśli miał prawidłową budowę i był silny, nakazywali go żywić i przydzielali mu jeden z dziewięciu tysięcy działów ziemi. Jeśli niemowlę miało wadliwą budowę, odsyłali je na miejsce zwane Apothetai, będące urwiskiem w górach Tajgetu. Sądzili bowiem, że lepiej było dla niego samego i dla polis, aby nie żyło to, co od samego początku nie miało zdrowia i siły”
Comments