Gdy przeprowadzam rozmowy kwalifikacyjne na stanowisko testera automatyzującego, zawsze pytam kandydatów, jakie jest ich podejście do testowania…  testów automatycznych. Jednym z istotnych aspektów, na jakie zwracam uwagę, jest właśnie to, czy testy przechodziły proces code review. Czym jest code review w kontekście testów automatycznych? Jak wdrożyć proces inspekcji kodu w (niechętnym do tego) zespole oraz od czego zacząć, jeśli do tej pory nie miałeś do czynienia z code review? Zachęcam do lektury artykułu, w którym zdradzam najlepsze praktyki.

Czym jest code review?

Code review (przegląd / inspekcja kodu) można zdefiniować jako praktykę programistyczną polegającą na wykonaniu statycznej analizy kodu przed jego scaleniem z inną (najczęściej główną) wersją kodu. Code review jest wykonywane przez osoby inne niż twórca zmian, ponieważ łatwiej jest wyłapać czyjeś błędy niż swoje własne.

Code review: a po co nam to? Wprowadzenie procesu do zespołu

Jeżeli zespół nie wdrożył procesu code review w kontekście testów, to warto wyjść z inicjatywą i go zaproponować. Nikt nie jest nieomylny, a wyłapanie potencjalnych błędów w teście automatycznym pozwala testerowi rozwijać umiejętności, nie wspominając o korzyściach dla samej testowanej funkcjonalności.

Główne korzyści to:

  • Zwiększenie czytelności kodu i łatwiejsze utrzymanie.
  • Transfer wiedzy małym kosztem, ponieważ robiąc code review, uczymy się od siebie nawzajem.
  • Większa świadomość tworzonego kodu (co jest szczególnie istotne w dużych projektach) – unika się duplikowania już raz stworzonego kodu.

Moim zdaniem dobre wdrożenie procesu code review powinno spełniać kilka założeń:

Proces code review, aby wnosił wartość, musi mieć chętnych i aktywnych uczestników. W idealnym świecie powinni to być wszyscy członkowie zespołu, tj. analitycy, developerzy oraz inni testerzy (niezależnie od specjalizacji). W praktyce taka sytuacja występuje bardzo rzadko, niemniej jednak warto szukać sojuszników we wdrażaniu code review. Do tej pory w swojej karierze, nawet podczas pracy w bardzo małych zespołach, nie przytrafiła mi się sytuacja, aby nikt nie był chętny do rzucenia okiem na testy. Jeżeli pracujecie w metodyce zwinnej, pomocne może być wpisanie testów automatycznych do Definition of Done. Tym samym w interesie zespołu będzie doprowadzenie do sytuacji, w której kod został przejrzany i zaakceptowany.

Proces code review powinien zostać wprowadzony na tak wczesnym etapie tworzenia testów automatycznych, jak to tylko możliwe (najlepiej od samego początku).

Rozmowa techniczna, czyli jaka?

Przeczytaj także artykuł naszego QA Technical Leadera, który doradza, jak przejść techniczną rozmowę kwalifikacyjną.

Artykuł

Nigdy nie robiłem code review – i co teraz?

Kiedy zostaję poproszony o przejrzenie czyjegoś kodu testów, to rozpatruję go z dwóch punktów widzenia – na poziomie scenariuszy testowych oraz na poziomie technicznych rozwiązań (czysto programistycznym).

1) Poziom scenariuszy testowych

Czy tytuł testu jasno mówi mi, jaki jest cel testu?

Jedną z cech testów automatycznych jest to, że mogą być traktowane jako żywa dokumentacja. Oznacza to, że na tzw. pierwszy rzut oka cel danego testu powinien być jasny dla odbiorcy. A najłatwiej jest to osiągnąć poprzez poprawne zdefiniowane tytułu testu. Idealnie jest, gdy czytam i od razu wiem, która ścieżka jest pokryta (bez konieczności analizy samego testu). Dlatego też warto wcześniej zdefiniować standard nazewnictwa testów (np. „given conditions when action then result” czy „should action when conditions”) i trzymać się go w trakcie rozwoju projektu.

Czy asercja odpowiada tytułowi?

Jeżeli tytuł mówi o sprawdzeniu wyniku jakiejś akcji, to odpowiednia asercja powinna znaleźć się na końcu testu. Czasami zdarza się, że test sprawdza dużo więcej, niż wskazuje na to jego opis.  W takiej sytuacji warto albo zmienić tytuł, albo podzielić go na kilka testów, gdzie każdy będzie weryfikować inny, mniejszy obszar. Może zdarzyć się też sytuacja odwrotna, gdy test sprawdza mniej niż w opisie – wówczas należy dopisać brakujące warunki lub przeredagować tytuł.

Czy widzę testowaną akcję?

Kiedy czytam test, chcę widzieć testowaną akcję. Nie powinna być ona „ukryta” pośród innych fragmentów kodu, jak np. przygotowanie danych czy asercje. Uważam, że dobrą praktyką jest stosowanie w testach wzorca wydzielającej w nich poszczególne ich etapy, np. arrange / act / assert czy given / when / then. Pewnym ułatwieniem może być zastosowanie narzędzi do testów automatycznych, które wymuszą taki podział, jak np. Spock.

Czy istotne / wymagane ścieżki są pokryte?

Jeżeli oceniam testy systemu, nad którym również pracuję (a co za tym idzie, wiem, jak powinien się zachowywać), to sprawdzam, czy zautomatyzowane ścieżki odpowiadają tym, które miały zostać uwzględnione w tym procesie. Może się zdarzyć, że automatyzacji zostaną poddane ścieżki, które nie były wcześniej ustalane lub też któreś zostały pominięte. W takiej sytuacji można dodać stosowny komentarz z prośbą o poprawkę lub wyjaśnienie sytuacji (bo np. zmieniły się wymagania i dana ścieżka nie będzie implementowana lub będzie, ale w innym terminie).

Czy fragmenty testów nie powtarzają się?

Częścią każdego testu jest przygotowanie danych. Osobiście, pisząc kod poszczególnych scenariuszy, piszę go niejako w „oderwaniu” od pozostałych. Przykładowo, jeżeli mam pokryć ścieżkę, to potrzebuję określonych danych, muszę wykonać konkretną akcję i sprawdzić wynik. Po czym, tworząc kolejny scenariusz, powtarzam tę sekwencję postępowania. W efekcie część kodu odpowiedzialna za przygotowanie danych powtarza się. Warto rozważyć jej wyodrębnienie do metod i wywoływać je w każdym teście lub przenieść kod do metod wykonywanych przed klasą testową lub każdym testem.

Testy eksploracyjne

Dlaczego warto przeprowadzać testy eksploracyjne?
W jakich sytuacjach warto zastosować testy eksploracyjne i jakie są plusy tego rozwiązania? Przeczytaj materiał, który przygotowała Justyna Rybarczyk z JCommerce.

Przeczytaj artykuł

2) Poziom techniczny

Drugą część code review poświęcam na techniczne aspekty ocenianego kodu – nie skupiam się na tym, co jest testowane, ale jak.

Na tym etapie zwracam uwagę na takie rzeczy, jak:

  • czy kod jest „czytelny” – czy nazwy metod opisują dokładnie to, co jest wykonywane, czy długie metody są podzielone na mniejsze, czy nie istnieją jakieś aspekty, które mogłyby spowodować dodatkowe błędy (np. nieobsłużone wyjątki lub zwrot niepoprawnej wartości),
  • czy kod jest zgodny z dobrymi praktykami programowania,
  • czy są inne, nowocześniejsze rozwiązania danego problemu (np. w Javie zastąpienie klasycznych pętli strumieniami),
  • czy zastosowane rozwiązania można zastąpić metodami obecnymi w bibliotekach, które są używane w projekcie,
  • czy zastosowane rozwiązanie jest poddawane code review po raz pierwszy (może się zdarzyć, że jest kopią kodu z innej części projektu, która była już oceniania wcześniej).

Code review narzędzi – smaczki i dedykowane rozwiązania

Istotnym aspektem jest również fakt, iż biblioteki / frameworki testowe miewają swoje autorskie rozwiązania. Warto wtedy zwrócić uwagę na to, czy zostały one poprawnie zaimplementowane lub czy rzeczone narzędzia zawierają gotowe, dedykowane rozwiązania. Na przykład – w narzędziu Selenide nie trzeba czekać na pojawienie się elementu przed wykonaniem na nim akcji – dzieje się to automatycznie. Narzędzie to posiada również wbudowane asercje – nie trzeba wykorzystywać w testach dodatkowych bibliotek do asercji (typu JUnit, AssertJ czy Hamcrest).

Zanim stworzysz pull requesta

Bądź swoim pierwszym krytykiem. Zanim naciśniesz przycisk otwierający, tzw. pull requesta, sam przejrzyj swój kod. Są trzy główne powody ku temu.

  1. Upewnisz się, że PR zawiera to, co powinien zawierać. Nieraz zdarzyło mi się, że na potrzeby testów używałem danych z plików na dysku, a później ich nie usuwałem. Innym przykładem może być źle skonfigurowany plik .gitignore, co powoduje, że do code review trafiają pliki, które nie powinny się w nim znaleźć.
  2. Kod gotowy do code review nie powinien zawierać błędów, które mogą być określane jako „widoczne na pierwszy rzut oka”. Pomimo że tworząc kod, zawsze staram się to robić z jak najwyższą starannością, dużo łatwiej jest mi wyłapać popełnione przez siebie błędy, kiedy na ekranie widzę kod w postaci „przed i po”, niż kiedy widzę go w wersji „po” w IDE.
  3. Usuwając błędy widoczne gołym okiem, oszczędzasz czas swój i pozostałych członków zespołu. Nie będą musieli oni przeglądać kodu złej jakości, nie będą musieli go komentować, a następnie czekać na moje poprawki. Tym samym cały proces przebiegnie szybciej.

Dobre praktyki w code review

  • Ustalcie w zespole przedział czasowy na code review. Przykładowo – wykonujcie je na samym początku dnia pracy. Dzięki temu łatwiej jest zorganizować sobie czas i podzielić go pomiędzy obowiązki, jakie należy wykonać w danym dniu (jak np. przygotowanie nowych scenariuszy), a zaopiekowanie się scenariuszami w trakcie przeglądu.
  • Odpisuj na otrzymane komentarze. Moim zdaniem dużo łatwiej robi się code review, jeżeli pod czyimś komentarzem pojawia się odpowiedź od autora kodu. Może to być zdawkowe: „OK” czy „Poprawione” lub bardziej rozbudowana wypowiedź (jeżeli jest taka konieczność). Dzięki temu od razu widać, że czyjaś uwaga nie została pominięta.
  • Rób poprawki w osobnych, opisanych commitach. Dużo szybciej przegląda się kod po poprawkach, gdy w historii commitów można przejrzeć tylko te, które są związane z uwagami autora.
  • Staraj się, aby liczba zmian w kodzie, które należy przejrzeć, była jak najmniejsza. Z mojego doświadczenia wynika, że dużo szybciej i chętniej przegląda się kod z małą liczbą zmian niż jeden wielki pull request zawierający wiele zmian.
  • W przeglądzie kodu może brać udział każdy, niezależne od nazwy stanowiska czy poziomu specjalizacji. W trakcie code review można się nauczyć czegoś nowego lub zmienić swój punkt widzenia na pewne rozwiązania czy podejścia tylko dlatego, że ktoś powiedział: „Nie rozumiem tego kawałka kodu”.

Mamy to, czyli kiedy kod jest gotowy

Aby przeglądanie tego samego kodu nie zamieniło się w „niekończącą się opowieść”, zdefiniujcie w zespole zasady określające, kiedy kod będzie uznany za gotowy / zaakceptowany. Mogą to być np.:

  • Akceptacja przez co najmniej jednego testera (jeżeli w zespole pracuje więcej niż jeden).
  • Akceptacja przez określoną liczbę developerów.
  • Poprawne wykonanie się wszystkich lub części (np. „smoke”) testów uruchomionych z wersji kodu zawierającej zmiany.

Podsumowanie

Na szczęście coraz mniej osób trzeba przekonywać co do wartości code review w testach. Warto wdrożyć ten proces w zespole i dbać o to, aby był stosowany poprawnie, z zaangażowaniem wszystkich członków zespołu. Błędy w code review to szeroki temat zasługujący na osobny artykuł. Na początek najważniejsze, aby zespół był chętny do wypracowania wspólnych metod i aktywnego uczestnictwa w procesie. Takie podejście przyniesie korzyści zarówno testerowi, jak i przyczyni się do dostarczenia możliwie najlepszego produktu dla klienta.

Autorem wpisu jest:
Senior QA Engineer & Technical Leader

Żadna przygoda w moim życiu zawodowym nie zaczęła się od: „Potrzymaj mi sałatkę!", ale wiele zaczęło się od: „Mariusz – mam problem. Pomożesz?" Z wykształcenia biotechnolog, z zawodu tester automatyzujący. Obecnie doskonali swoją wiedzę z Javy w kontekście testów automatycznych aplikacji webowych oraz API. Prywatnie fotograf.

Dodaj komentarz

Skontaktuj się z nami

Chcesz dowiedzieć się więcej o naszych usługach? Napisz do nas – odpowiemy na każdą wiadomość.

    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach handlowych.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach marketingowych.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma w celach rekrutacyjnych.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma na potrzeby przyszłych rekrutacji.
    W związku z obowiązującymi przepisami dotyczącymi ochrony danych osobowych tj. Ustawą o ochronie danych osobowych z dnia 10 maja 2018 roku, jak również treścią Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO), informujemy, że: 1. Administratorem danych osobowych jest JCommerce Sp. z o.o. z siedzibą w Katowicach, ul. Ściegiennego 3, 40-114 Katowice (KRS: 00007393418).
    2. Powyższe dane osobowe przetwarzane będą przez JCommerce Sp. z o.o. – w zależności od udzielonych przez Panią/Pana zgód (podstawa prawna przetwarzania: art. 6 ust. 1 pkt a) RODO):
    • w celach handlowych,
    • w celach marketingowych,
    • w celach rekrutacyjnych;
    • w celach przyszłych rekrutacji.
    3. Podanie powyższych danych osobowych nie jest wymogiem ustawowym, umownym lub warunkiem zawarcia umowy. Nie jest Pan/Pani zobowiązany/a do podania powyższych danych osobowych, jednak brak ich podania uniemożliwi realizacje ww. celu.
    4. Posiada Pan/ Pani prawo dostępu do treści swoich danych, w tym otrzymania ich kopii i ich sprostowania, usunięcia, ograniczenia przetwarzania, prawo do przenoszenia danych, prawo do sprzeciwu wobec przetwarzania, prawo do cofnięcia zgody w dowolnym momencie, jeśli została udzielona. Wycofanie zgody nie wpływa jednak na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody przed jej wycofaniem; oświadczenie o cofnięciu zgody na przetwarzanie danych osobowych należy złożyć w siedzibie JCommerce Sp. z o.o. lub przesłać na adres mailowy zgody@jcommerce.pl. Cofnięcie zgody na przetwarzanie danych osobowych skutkuje brakiem możliwości realizacji ww. celów przetwarzania;
    5. Dane osobowe są udostępniane przez JCommerce Sp. z o.o. upoważnionym pracownikom i osobom współpracującym z JCommerce Sp. z o.o. na podstawie umów cywilnoprawnych, przez których realizowany jest cel przetwarzania;
    6. Wszelkie pytania dotyczące ochrony danych osobowych oraz realizacje przysługujących praw, prosimy kierować na adres odo@jcommerce.pl;
    7. W zależności od udzielonej zgody, dane osobowe będą przetwarzane przez czas niezbędny do realizacji ww. celów przetwarzania. W przypadku wniesienia sprzeciwu, JCommerce Sp. z o.o. przestanie przetwarzać Pani/Pana dane w ww. celu, chyba że będzie w stanie wykazać, że w stosunku do tych danych istnieją ważne prawnie uzasadnione podstawy, które są nadrzędne wobec Pana/Pani interesów, praw i wolności, lub niezbędne do ewentualnego ustalenia, dochodzenia lub obrony roszczeń;
    8. Nie przekazujemy Pani/Pana danych poza teren Europejskiego Obszaru Gospodarczego oraz do organizacji międzynarodowych.
    9. Pani/Pana dane osobowe nie podlegają zautomatyzowanemu podejmowaniu decyzji, w tym profilowaniu.
    10. Ma Pani/Pan prawo wniesienia skargi do organu nadzorczego gdy uzna Pan/Pani, iż przetwarzanie ww. danych osobowych narusza przepisy ogólnego rozporządzenia o ochronie danych osobowych z dnia 27 kwietnia 2016 r.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach handlowych.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma, w celach marketingowych.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma w celach rekrutacyjnych.
    Niniejszym wyrażam zgodę na przetwarzanie przez JCommerce Sp. z o.o. moich danych osobowych (dalej „dane osobowe”), takich jak: imię i nazwisko, adres e-mail, nr telefonu, firma na potrzeby przyszłych rekrutacji.
    W związku z obowiązującymi przepisami dotyczącymi ochrony danych osobowych tj. Ustawą o ochronie danych osobowych z dnia 10 maja 2018 roku, jak również treścią Rozporządzenia Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (RODO), informujemy, że: 1. Administratorem danych osobowych jest JCommerce Sp. z o.o. z siedzibą w Katowicach, ul. Ściegiennego 3, 40-114 Katowice (KRS: 00007393418).
    2. Powyższe dane osobowe przetwarzane będą przez JCommerce Sp. z o.o. – w zależności od udzielonych przez Panią/Pana zgód (podstawa prawna przetwarzania: art. 6 ust. 1 pkt a) RODO):
    • w celach handlowych,
    • w celach marketingowych,
    • w celach rekrutacyjnych;
    • w celach przyszłych rekrutacji.
    3. Podanie powyższych danych osobowych nie jest wymogiem ustawowym, umownym lub warunkiem zawarcia umowy. Nie jest Pan/Pani zobowiązany/a do podania powyższych danych osobowych, jednak brak ich podania uniemożliwi realizacje ww. celu.
    4. Posiada Pan/ Pani prawo dostępu do treści swoich danych, w tym otrzymania ich kopii i ich sprostowania, usunięcia, ograniczenia przetwarzania, prawo do przenoszenia danych, prawo do sprzeciwu wobec przetwarzania, prawo do cofnięcia zgody w dowolnym momencie, jeśli została udzielona. Wycofanie zgody nie wpływa jednak na zgodność z prawem przetwarzania, którego dokonano na podstawie zgody przed jej wycofaniem; oświadczenie o cofnięciu zgody na przetwarzanie danych osobowych należy złożyć w siedzibie JCommerce Sp. z o.o. lub przesłać na adres mailowy zgody@jcommerce.pl. Cofnięcie zgody na przetwarzanie danych osobowych skutkuje brakiem możliwości realizacji ww. celów przetwarzania;
    5. Dane osobowe są udostępniane przez JCommerce Sp. z o.o. upoważnionym pracownikom i osobom współpracującym z JCommerce Sp. z o.o. na podstawie umów cywilnoprawnych, przez których realizowany jest cel przetwarzania;
    6. Wszelkie pytania dotyczące ochrony danych osobowych oraz realizacje przysługujących praw, prosimy kierować na adres odo@jcommerce.pl;
    7. W zależności od udzielonej zgody, dane osobowe będą przetwarzane przez czas niezbędny do realizacji ww. celów przetwarzania. W przypadku wniesienia sprzeciwu, JCommerce Sp. z o.o. przestanie przetwarzać Pani/Pana dane w ww. celu, chyba że będzie w stanie wykazać, że w stosunku do tych danych istnieją ważne prawnie uzasadnione podstawy, które są nadrzędne wobec Pana/Pani interesów, praw i wolności, lub niezbędne do ewentualnego ustalenia, dochodzenia lub obrony roszczeń;
    8. Nie przekazujemy Pani/Pana danych poza teren Europejskiego Obszaru Gospodarczego oraz do organizacji międzynarodowych.
    9. Pani/Pana dane osobowe nie podlegają zautomatyzowanemu podejmowaniu decyzji, w tym profilowaniu.
    10. Ma Pani/Pan prawo wniesienia skargi do organu nadzorczego gdy uzna Pan/Pani, iż przetwarzanie ww. danych osobowych narusza przepisy ogólnego rozporządzenia o ochronie danych osobowych z dnia 27 kwietnia 2016 r.