programista tester

Od programisty do testera. Jak doświadczenie programistyczne pomaga w byciu lepszym QA

Pewnie wielu z Was czytając tytuł, zadaje sobie pytanie: “dlaczego zmiana ścieżki kariery z programisty na QA”? Można by pomyśleć, że to degradacja… Ja tak nie uważam. Postaram się przybliżyć, co takiego urzeka mnie w pracy testera oraz jak moje doświadczenie devsowe pomaga mi w tej “nowej” ścieżce na co dzień. 

Paweł Ratalewski

Na początek dodam tylko, że do bycia strażnikiem jakości nie trzeba wcześniej przecierać szlaków programistycznych. Jeśli ktoś z Was chce rozpocząć przygodę z testowaniem od zera – dostanie kilka wskazówek na koniec. 

W jaki sposób były frontend developer znalazł się po stronie testów? W mojej pierwszej pracy jako front  mieliśmy w zespole garstkę osób (głównie programistów). Pewnego dnia przyszła pilna potrzeba przetestowania nowej wersji aplikacji. Rąk do pracy niewiele, więc błędy zgłaszały osoby spoza IT, a uwagi były zbyt ogólne, typu “nie działa”. Dlatego zabrałem się za to tak, jak sam – jako wtedy jeszcze developer – chciałbym zobaczyć prawdziwy i mięsisty raport z błędem, po którym od razu będę wiedział, o co chodzi. 

Ta czynność tak mnie pochłonęła, że przez kilka kolejnych dni zamiast pisać kod, zgłaszałem błędy… I szczerze mówiąc, wolałem to robić dalej, a kodzenie pozostawić osobom, które mają zajawkę na programowanie – taką, jaką ja wtedy odkryłem na testowanie. 

Nie trudno było mi odkryć, że wiele umiejętności, które przydawały mi się w pracy developera, są równie cenne i użyteczne w roli QA. Dla mnie to połączone ze sobą, równoważne światy. Dzisiaj tę wiedzę, którą zdobyłem jako programista, wykorzystuję do bycia jeszcze lepszym testerem w Displate (a to, nawiasem mówiąc, stawia mnie na równi z innymi programistami). 

Spróbuję więc przeprowadzić Was teraz przez różne aspekty koderskie, które moim zdaniem są nieocenioną pomocą w pracy testera.

1. Komunikacja z developerami

Myślę, że to najlepszy benefit, jaki czerpię dzięki wcześniejszemu doświadczeniu jako developer. Będąc w zespole, który w większości składa się z programistów, wiemy przecież, że komunikacja odbywa się w niejasnej dla zwykłego śmiertelnika nomenklaturze. Język obcy to nie jest, ale znając developerską terminologię, można zaoszczędzić dużo czasu, a nierzadko i stresu w komunikacji z programistami. 

Weźmy przykład: zła walidacja inputu dotyczącego kodu pocztowego przy składaniu zamówienia. Patrzę zatem na ostatni commit, który tego dotyczył – zmiana w regex. I taką właśnie informację podaję developerowi podkreślając miejsce w kodzie, gdzie może wystąpić potencjalny błąd. 

Często słyszę też, że początkujący testerzy mają duży problem, aby włączyć się w dyskusję na planowaniu tygodnia/sprintu, czy też programistycznej burzy mózgów, czasem wręcz siedzą, jak na “tureckim kazaniu”. Myślę, że często wynika to z onieśmielenia się właśnie przez techniczny żargon, a że sam jestem już z nim oswojony – nie boję się i śmiało włączam się do dyskusji. 

Czy trzeba wcześniej pracować jako programista, aby “umieć w komunikację” z deweloperami? Niekoniecznie, ale są sytuacje lub terminy, których można się nauczyć współpracując tylko z innymi developerami – nie wszystko zapisane jest w dokumentacji, książce czy na Stack Overflow.

2. Automatyzacja testów

Klucz do powiedzenia “Mniej robić, a więcej zarobić” – a żeby to robić, przydaje się znowu umiejętność programowania. 

Oczywiście testy automatyczne można wyklikać w specjalnym narzędziu, które do tego służy, ale można też napisać je samodzielnie, co daje nam większą kontrolę nad tym, czym się posługujemy. 

Otwierając wrota do testów automatycznych, nie musiałem przerabiać podstaw programowania. Próg wejścia został obniżony niemalże do zera. Przyswojenie wiedzy, czym jest zmienna, pętle, instrukcje warunkowe, asercje, czyli podstawowa wiedza programistyczna – miałem już za sobą, bo wiedziałem to zanim zostałem testerem oprogramowania.

Dla przykładu, wiedza poparta praktyką pozwala mi samodzielnie pisać lokatory, nie muszę w inspektorze kopiować ścieżki do selektora, która zazwyczaj jest długa i mało czytelna. Może i kopiowanie jest wygodne, ale pisząc samodzielnie selektor, który działa, poprawia czytelność w kodzie dla nas samych oraz zespołu.

Przykład z mojego aktualnego podwórka testowego – w Displate automatami pokrywamy ścieżki krytyczne testami e2e. Piszemy je głównie w Cypressie – bazującym na JavaScript. No właśnie, JavaScript. Osobiście nie “polubiłem się” z JSem, jednak nietrudno było mi się z nim “oswoić” mając już doświadczenie programistyczne.

I kolejna rzecz, tym razem nie była ona widoczna na pierwszy rzut oka, a bardzo poprawia wydajność podczas pisania testów automatycznych i nie tylko, programowanie też się w to wlicza. Dobór i umiejętne korzystanie z narzędzi (o ile nie ma się narzuconego z góry), jak np. IDE. Jeśli ktoś się w nim gubi, mocno utrudnia sobie pracę. Zmiana na dark mode lub “ctrl” + “f”, nie czyni nas zaawansowanym użytkownikiem IDE podczas pisania. Miałem na myśli choćby skróty klawiszowe, które można przemycić w naszej twórczości. 

Z perspektywy QA w Displate, testy automatyczne znacznie przyspieszyły regresję, zwłaszcza po wdrożonych releasach, które są wykonywane nawet kilka razy w ciągu dnia. Z początku, kiedy automatów nie było, taką regresję wykonywało się głównie manualnie. Teraz rolą QA staje się dopilnowanie, aby testy e2e znalazły swoje zastosowanie. Oprócz pokrycia ścieżki krytycznej, QA je utrzymuje i dba ich o jakość, tak aby zarówno zespół testerski, jak i cały dział IT, miał do nich pełne zaufanie. Cieszy mnie fakt, że byłem uczestnikiem tego procesu, zwłaszcza że mogłem do tego wykorzystać doświadczenie programistyczne.

3. Bazy danych

Ujmę to klasykiem: “Easy to learn, hard to master”. Pierwszą rzeczą, jaką przemyciłem z developerskiego doświadczenia, była optymalizacja zapytań do bazy danych. O ile podstawy SQL dla QA niekiedy wystarczą do codziennej w miarę samodzielnej pracy, o tyle bardziej zaawansowana wiedza w tym obszarze staje się kluczem przede wszystkim do usprawnienia workflow

Przykład z życia wzięty, w Displate, czyli marketplace działającym na skalę globalną, na wysoki priorytet w zapewnieniu jakości zasługuje ścieżka zakupowa. A konkretnie? Klient kupuje produkt z linku afiliacyjnego, gdzie prowizja jest naliczana po określonym czasie od dokonaniu zakupu. Nim frontendzi naszyją pełną warswę wizualną, już na etapie prototypu mogę w bazie sprawdzić odpowiedni status zamówienia. Czy status się zmienił po zakupie, czy została wysłana informacja dla kuriera, czy w tabeli z zamówieniem jest zawarta informacja o linku afiliacyjnym itp.  

Mogę więc zweryfikować prawie każdy jej etap, który aktualizuje się w bazie danych. Znając sql, mogę bez problemu  zapobiec występowaniu błędów jeszcze przed zaktualizowaniem się danego etapu w warstwie wizualnej.

Oszczędza to przede wszystkim czas, ale też daje satysfakcję, że jestem samodzielny w tym, co się robi. Oczywiście, gdy mam jakiś problem bądź chce zoptymalizować zapytanie, zawszę mogę zwrócić się do bardziej doświadczonych osób, które są skłonne mi w tym pomóc.

4. Praca z systemem kontroli wersji

Drogi czytelniku, wiedz, że na swojej ścieżce kariery testerskiej, prędzej czy później zapoznasz się z tym narzędziem, szczególnie jeśli będziesz chciał skręcić w stronę testów automatycznych. Śmiem stwierdzić, że będzie ono dla Ciebie – stety, niestety – niezbędne do opanowania. 

Jeśli już znasz jakikolwiek system kontroli wersji, super, możesz przejść do kolejnego punktu, jeśli nie – spokojnie, to narzędzie, które ma nam testerom ułatwiać pracę, a nie być koszmarem, śniącym się po nocach. Swoją drogą w internecie dostępne są również narzędzia UI, które ułatwiają posługiwanie się systemem kontroli wersji.

Nie ukrywam, że przebranżawiając się na strażnika jakości, dosyć sprawnie przeskoczyłem szczebelek o nazwie “system kontroli wersji” w drabinie QA. 

Co konkretnie z poprzedniego doświadczenia jako frontend dev pomogło mi ten skok wykonać? To, że bez obaw i pewnością siebie posługuję się komendami, tymi podstawowymi, jak i bardziej zaawansowanymi. Przywracanie zmian, rozwiązywanie konfliktów, praca na tagach, konwencjonalne commity, tworzenie pull-requestów, robienie code-review, to coś co z pewnością przyda się każdemu testerowi.

programista tester

W Displate’owym sprincie QA ma do czynienia z repozytorium zawierającym testy e2e. Staramy się stosować dobre praktyki, jeśli chodzi o korzystanie z repozytorium (zwłaszcza w powyżej wymienionych przykładach). Większość pull-requestów jest poddana code-review, a nazewnictwo commitów jest na tyle czytelne, że po ich nazwie nie musimy się w kodzie doszukiwać, za co odpowiedzialna jest zmiana.

Zachęcam do zapoznania się z tematem, ponieważ jak wyżej wspomniałem, prędzej czy później się na niego natkniemy.

Dalsza część artykułu na następnej stronie.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
JUnit 5 i Selenium. Optymalizacja konfiguracji i uruchomienia projektu