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ń.

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.

Oferty pracy z

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 engineera 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 engineera 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 engineera 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.

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.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ń.

5. Sprawne posługiwanie się devtoolsami

Nadmienię, że nie wszędzie korzystanie z devtoolsów jest użyteczne. Proces testowy wdrażany jest nie tylko w aplikacjach webowych, ale również np. gamedevie (wyłączając gry przeglądarkowe oraz mobilne), gdzie inspektor w przeglądarce nie jest wymagany. Displate jest akurat marketplacem z branży produktowej, która głównie skupia się na działaniu w przeglądarce, stąd znajomość wspomnianych devtoolsów dla testera jest wręcz niezbędna.

Łącząc wiedzę z zakresu testów i programowania można odkryć szerszy potencjał zakładek, jakie możemy znaleźć w inspektorze. Podczas testów, jeśli widzę, że coś mnie razi po oczach w warstwie wizualnej, otwieram inspektora i zaczynam bawić się css’ami – czy to zmiana stylu czy też dodanie własnej klasy w elemencie – po czym podsuwam rozwiązanie zespołowi.

Kolejna sprawa, ecommerce Displate napisany jest w większości we frameworku React.js. Mając taką informację, mogę dodać sobie plugin “React Developer Devtools”, wykorzystując go do testów e2e oraz manualnej weryfikacji. W praktyce – zweryfikować czy dobrze wyrenderowały się komponenty zawierające propsy, np. podczas dodawania produktu do koszyka.

Takich ukrytych smaczków jest dużo więcej i nie tylko do jednego frameworka.

Zatem moim zdaniem połączenie wiedzy testerskiej z programistyczną pozwala na “wyciśnięcie” więcej z narzędzi do debugowania, jakie oferują nam przeglądarki.

Bonus – tipy dla testerów wanna-be

Żeby zostać testerem nie trzeba kończyć żadnych specjalistycznych kursów ani bootcampów, których w internecie jest mnóstwo (o ile firma, do której się aplikuje, tego nie wymaga). Tę radę przeczytaliście już pewnie nieraz, dlatego przygotowałem coś nieszablonowego. Coś, czemu zawdzięczam swój pobyt w Displate – misja firmy, czyli “Collect your passions”. To jedno zdanie uświadomiło mi, że jeśli nie wiesz od czego zacząć, zawsze najlepiej sięgnąć po pasję, coś co naprawdę lubisz robić, co Cię interesuje, a niekoniecznie zaczynać od testowania “dowolnego formularza na dowolnej stronie”.

W moim przypadku gaming to właśnie moje hobby. Zatem dlaczego nie zostać testerem gier? Wolę zostać przy grach jako odbiorca aniżeli twórca, gdzie karmię się tą sztuką. Jeśli chcesz wejść do branży QA, a nie wiesz od czego zacząć, zacznij od swojego hobby, od pasji. Zacznij testować, sprawdzać, usprawniać, a odkryjesz, że to świetna zabawa i gdy podczas pierwszej rekrutacji zaczniesz o tym opowiadać, rekruter na pewno to doceni.

Drugą kluczową wskazówką jest umiejętność komunikowania się. Polecam dla ćwiczenia przetestować jakąś funkcjonalność/część oprogramowania, po czym znaleźć w niej nieprawidłowość i opowiedzieć o tym swojemu znajomemu, bądź komuś z rodziny. Jeśli ta druga osoba Cię zrozumiała, jesteś na dobrej drodze, jeśli nie, jest nad czym popracować.

Trzecia i ostatnia wskazówka – dodałbym tu podstawy teorii testowania. Jest to coś, z czym będziesz pracować na co dzień, warto mieć więc w tym obszarze jakąś wiedzę. Branżowa terminologia pozwoli Ci na komunikowanie się z innymi testerami, będziesz mieć swobodę w czytaniu dokumentacji. Polecam do tego przejrzeć słownik terminów testowych ISTQB

Podsumowując

Jeśli dobrnęliście aż tutaj, jestem pod wrażeniem! W ciągu tych kilku minut czytania przyjrzeliśmy się, jak wygląda codzienna “walka o lepsze jutro” QA w oparciu o moje doświadczenie z Displate oraz jak programistyczne umiejętności pozwalają mi spoglądać na tę rolę z szerszej perspektywy.

Trafiając do zespołu z innymi testerami, myśląc że pozjadałem wszystkie rozumy będąc wcześniej programistą, zdałem sobie sprawę, że QA to nie klepanie, utrzymywanie testów automatycznych i klikanie po aplikacji wyszukując błędy. Tutaj można się rozwijać na różne sposoby. Testy automatyczne to tylko jedna z gałęzi jakim dysponuje drzewo o nazwie Quality Engineer. Największy potencjał jaki odkryłem to droga z Quality Assurance przez Quality Engineer aż do Software Development Engineer in Test, ale to już wykracza poza ramy tego artykułu.

Opisane wyżej sytuacje z życia QA, mogą stanowić pogląd na pracę testera dla osób, które chcą nim zostać. To niestandardowe działanie, ponieważ na rynku, zazwyczaj możemy zaobserwować odwrotną sytuację: z QA na developera, gdzie ten pierwszy jest tylko wstępną ścieżką do wejścia w branżę IT.

Patrząc z mojej perspektywy po zmianie pozycji otrzymałem:

• większy wachlarz rozwoju, czy to w stronę kompetencji miękkich (procesy biznesowe, sztuka dawania feedbacku) czy bardziej twardych (umiejętności techniczne, programowanie, bazy danych),
• świadomość zapobiegania błędom,
• bycie strażnikiem produktu,
• dowolność. Bycie QA jest tak kreatywne jak on sam.

Moim zdaniem łączenie doświadczeń zawsze wychodzi na plus, zwłaszcza w środowisku pełnym kreatywnych ludzi, myślących o ciągłym doskonaleniu się, w którym akurat sam mam szansę być.