Programowanie i testowanie to dwie okładki tej samej książki

Najlepsi developerzy znają wartość testowania. Zarówno tego wykonywanego samodzielnie, jak i wykonywanego z pomocą testera (dev-test pairing) lub przez testera – mówi Aleksandra Kornecka, testerka z wieloletnim doświadczeniem. Poprosiliśmy ją, by opowiedziała nam na czym polega praca testera, ale też o tym, kiedy zatrudnianie testera nie jest konieczne. Zapraszamy do przeczytania długiej, ale wartościowej rozmowy z Olą, która jest Quality Assurance Engineer’ką w OLX Group.

Spróbujmy wyjaśnić czytelnikowi, na czym polega testowanie oprogramowania.

Praca nad oprogramowaniem to niezłe wyzwanie. Mając za sobą kilka lat doświadczenia w zapewnianiu jakości, mogę stwierdzić, że testowanie polega na poddaniu napisanego kodu różnym “próbom”. Czasami są to próby proste — np. czy przedmiot testów działa (co nazywamy weryfikacją), albo czy działa zgodnie z wymaganiami biznesowymi i technicznymi (to walidacja). Czasami próby te są różnego rodzaju (testy funkcjonalne, wydajności, bezpieczeństwa, użyteczności itd.), a czasami testowanie to istne umysłowo-techniczne zmagania w dążeniu do jak najbardziej wolnego od słabości kodu — próba przewidzenia wszelkich ruchów użytkownika końcowego, wymyślanie jak jeszcze można popsuć kod, gdzie mogą czaić się pominięcia lub niewłaściwie działające elementy.

Wszystko po to, by pomóc programiście wycisnąć z jego dzieła jak najwięcej dobrego oraz by dostarczyć klientowi i użytkownikom wysokiej jakości produkt (działający sprawnie i zgodnie z oczekiwaniami).

Każdy tester zna piramidę automatyzacji. Powiedz dlaczego przewiduje ona najwięcej testów jednostkowych, a najmniej testów interfejsu graficznego? Z czego to wynika?

Wzór piramidy automatyzacji testów jest już w kanonie dobrych praktyk i znajduje potwierdzenie w niejednej firmie (polecam poczytać źródło, Martin Fowler). Struktura i ilość testów w piramidzie wynikają z relacji korzyść-koszt. Mamy więcej korzyści z pisania wielu testów jednostkowych (ang. “unit tests”), niż wielu testów “end-to-end” (czyli przekrojowych przez całe funkcjonalności od pierwszego kroku użytkownika, aż do ostatniego).

Mogłabym rozgadać się przy tym punkcie bardziej, ale pozwolę sobie zilustrować to tylko za pomocą metafory. Otóż po co nam testowanie domu za pomocą burzy i tornada, jeśli nie wiemy nawet, czy jest on zbudowany z cegły, czy z drewna, czy może z lodu, oraz jeśli nie wiemy czy elementy go budujące zostały w ogóle w jakiś sposób połączone — a jeśli zostały to czy zrobiono to za pomocą kleju, zaprawy cementowej czy może gliny. W tym porównaniu testy jednostkowe to elementy budulcowe (np. cegły), spoiwo (np. glina) to testy integracyjne, a warunki testowe (np. tornado) to testy end-to-end.

Podsumowując, ważniejsze jest żeby sprawdzić, czy cegły (unit tests, wiele testów) są porządnie połączone (integration tests) i potem dopiero poddać taki dom pod tornado, wystarczy kilka testów (end-to-end). Warto napisać więcej testów jednostkowych, które już na poziomie “komórkowym” zbadają za nas, omylnych ludzi, czy nie zrobiliśmy “byka” w warunkach albo wartościach, albo typach zmiennych, niż zignorować ten poziom i radośnie automatyzować interfejs użytkownika. A to między innymi z powodu kosztu automatyzacji testów interfejsu użytkownika.

Testy jednostkowe są tańsze?

Pisanie testów jednostkowych na poziomie developmentu jest o niebo tańsze, niż pisanie automatów end-to-end na niepewnym kodzie, utrzymywanie potem tych testów, martwienie się czy aby nie stracą zbyt szybko na aktualności. A co gorsza jak wyłapie się błąd takim testem, kiedy nie otestowało się jednostkowo kodu — grzebanie w tym kodzie i szukanie przyczyny to gwarantowany ból głowy. I to w znakomitej większości przypadków ból biednego programisty, a nie testera. Lepiej zatem, by takie unit testy programista zawczasu pisał do swojego kodu.

Po co zatem testy end-to-end?

Ano jednak też się przydają — tylko nie trzeba ich aż tyle co jednostkowych i integracyjnych.

Jak już mówimy o automatyzacji to polecam Waszej uwadze CypressJS — bibliotekę, a właściwie cały framework do testów e2e. Obserwuję od niedawna jej performance i jeśli potrzebujesz tylko testów webowych z prostym wstrzykiwaniem danych, to CypressJS jest super. Na razie działa tylko pod silnik Chrome’a, ale chłopaki dzielnie dłubią ją dalej. Przyglądam się z zaciekawieniem co też dalej wyczarują.

Najlepiej otestować najbardziej profitogenne ścieżki użytkownika, by mieć kilka głównych “przejść” niczym prawdziwy użytkownik, by sprawdzić, czy nasz nowy kod nie zepsuł istniejącego już przepływu danych i kolejnych operacji wymaganych na tych ścieżkach. Innymi słowy, automatyzacja testów end-to-end powinna być implementowana jako testy regresyjne — badające, czy nie wprowadziliśmy swoim nowym kodem regresji funkcjonalności istniejącego kodu.

I co ważniejsze — zawsze, niezależnie jakiego rodzaju testy piszemy, piszmy je z głową, tzn. nie kierujmy się na ślepo pokryciem testów, tylko bądźmy świadomi, po co piszemy dany test oraz co on powinien sprawdzać, jaką dać nam wartość. A także czy faktycznie sprawdza to, co w zamyśle powinien sprawdzać.

Ok, wiemy już czym są testy, a teraz pokażmy, kto ich potrzebuje. Dlaczego software house albo po prostu developer potrzebuje testera?

Developer bardzo potrzebuje kogoś, kto spojrzy zarówno na strukturę, jak i działanie napisanego przez siebie kodu. Część tego “spojrzenia”, sprawdzenia wykonuje analiza statyczna i automaty, część inny developer, a część tester. Im bardziej zaawansowany, stary i skomplikowany kod, im większy jest dług techniczny, to tym więcej oczu i wyspecjalizowanych ról przydaje się przy jego ogarnianiu.

W niektórych przypadkach nie ma środków na zatrudnianie testerów, np. w startupach, gdzie wszystkie siły kładzie się na stworzenie MVP. Co wtedy?

Jeśli tworzysz soft od nowa i z pomocą małego zespołu (1-3 osoby) to jesteś w stanie zapanować nad tym jak on wygląda i czy nie tworzysz zbyt wielu błędów — dlatego też np. w startupach często nie znajdziemy testerów. Brutalnie rzecz ujmując, testerzy na sam początek mogą być zbyt dużym kosztem dla pączkującej firmy. Ale potem ten stan rzeczy się zmienia. Ogrom rzeczy wymagających uwagi niesamowicie zwiększa się w miarę rozrostu softu, przyrostu ilości integracji, funkcjonalności, rozrostu architektury oraz ilości punktów styku różnych technologii. To wszystko powoduje, że niechybnie rośnie ilość miejsc, gdzie nawet dobrzy programiści robią błędy. I wtedy tester zaczyna być naprawdę potrzebny. Co nie znaczy oczywiście, że nie wniósłby on wartości od samego początku. Tłumaczę tylko, dlaczego tak często testerzy pojawiają się w firmie później, niż programiści.

Czasami rolę testera może objąć inny programista (prócz zrobienia code review każdy jest w stanie wykonać najbardziej podstawowe testy), czasami lepiej żeby to był faktycznie tester (np. przy weryfikacji wymagań, sprawdzaniu przypadków użycia, testowaniu różnych scenariuszy oraz różnymi technikami, mając doświadczenie w tym, gdzie mogą się czaić błędy i jak je znaleźć, poprzez umiejętność zadawania odpowiednich pytań).

Czasami wartość jest w stanie wnieść nawet osoba na nietechnicznym stanowisku, która po prostu sprawdzi, “przeklika” soft i stwierdzi czy działa zrozumiale i zgodnie z założeniami.

Prawda jest więc taka, że nawet jeśli w firmie nie ma nikogo na stanowisku testera, to i tak ta rola jest jakoś wykonywana przez innych członków zespołu. Dlatego w miarę wzrostu dojrzałości firmy pojawiają się w niej testerzy “stanowiskowi”. Wartość testowania jest niezaprzeczalna, natomiast od specyfiki implementacji i firmy zależy czy zespół jest w stanie efektywnie działać bez testera.

Czego o pracy testera nie wie przeciętny developer? Jaką istotną cechę w pracy testera chciałabyś utrwalić w głowach developerów?

Najlepsi developerzy znają wartość testowania. Wartość testowania zarówno tego wykonywanego samodzielnie, jak i wykonywanego z pomocą testera (dev-test pairing) lub przez testera. Jeśli rozumiemy przeciętnego developera jako takiego, który już nie jest juniorem to zapewne wie on, że tester wnosi bezcenną perspektywę na tworzone oprogramowanie.

To trochę jak z byciem autorem — kiedy piszesz teksty, rozwijasz siebie i swój warsztat artystyczny w czasie. Widzisz, że poprzedni tekst mogłeś napisać lepiej. Tester pomaga developerowi szybciej stawać się lepszym “pisarzem”. I z o wiele mniejszą ilością wtop! Ze smutkiem zauważam, że wielu początkujących programistów nie docenia testowania, jak i testerów.

Zobacz też

Wywiady W Packhelp nie boimy się szukać wyjątkowych rozwiązań

Z czego to wynika?

Może to wynikać z różnych rzeczy. Myślę, że niezależnie od doświadczeń programistów oraz ich stażu pracy istotne jest też zachowanie samych testerów — np. w jaki sposób tester przekazuje informacje o znalezionych błędach i ryzyku. Czy jest rzeczowy i przyjazny, czy też przeciwnie — robi najgłupszą rzecz pod słońcem i zachowuje się, jakby wytykał programiście błąd, łącząc element profesjonalny z elementem osobistym w fatalny sposób.

Gdyby określić jaka cecha testera jest szczególnie przydatna w codziennej pracy, wskazałabym na empatię pod kątem tzw. umiejętności miękkich. A pod kątem tzw. umiejętności twardych uznałabym za cenną wszechstronną perspektywę techniczną (“big picture”) i umiejętność wielopoziomowego “dłubania” w sofcie. Tester często użyje większej ilości narzędzi i technik by przetestować kod programisty, niż programista by przetestować kod innego programisty.

Jakich narzędzi Ty używasz, a jakich pewnie użyłby developer testujący kod innego deva?

Zauważyłam, że testowanie w wykonaniu developerów różni się od testowania w wykonaniu testerów bardziej sposobem, niż narzędziami. Często developer stara się jak najszybciej sprawdzić zadanie, ignorując czasami realną ścieżkę użytkownika. Na przykład zamiast “wyklikać” coś w interfejsie, “pomaga” sobie zmianami w bazie danych, albo dopisuje sobie na szybko lokalnie jakiś endpoint w kodzie. Oczywiście w wielu przypadkach taki zabieg jest w porządku i faktycznie przyspiesza test bez uszczerbku dla jego rzetelności. Ale czasem taki sposób jest zgubny w skutkach i absolutnie niewłaściwy. To zależy co i w jakich warunkach powinno zostać przetestowane — context is the king. Istotna okazuje się testerska cierpliwość, zdarza się, że warto poślęczeć nieco dłużej nad danym zadaniem dla dobra jakości i spokoju zespołu przy wdrożeniu.

Ja używam takich narzędzi, jakie są mi akurat potrzebne do jak najlepszego przetestowania danego aspektu oprogramowania i danego zadania. Narzędzia wybieram w zależności od typu softu (web, mobile, inne), zakresu jego funkcjonalności, zakresu wymiarów jakości, jakie powinnam sprawdzić (funkcjonalność, wydajność, użyteczność, bezpieczeństwo, dostępność itd.).

Czasami wystarczy IDE, terminal, przeglądarki w trybie incognito i zwykłym z całą feerią funkcjonalności devtoolsów oraz JIRA, coś do zrzutów ekranu i notatnik. Czasem zaś łatwiej skorzystać mi z dodatkowych “pomocy” w zależności od tego, czy testuję API, performance czy bezpieczeństwo. Tutaj pomocne będą narzędzia takie, jak Postman, JMeter, Fiddler, Burp. Jest tego wiele, zarówno open source, jak i enterprise, płatnych i darmowych.

Oczywiście nie we wszystkich narzędziach jestem biegła, ale mam obycie techniczne i branżowe na tyle duże, że jestem w stanie sama ogarnąć co trzeba w danej sytuacji w niedługim czasie. A z pomocą programistów to już w ogóle minuta, dwie. Uważam, że na rynku istnieje tyle rodzajów i marek narzędzi oraz nakładek na nie, że warto poszukać narzędzia najbardziej pasującego do tego, co potrzebujemy akurat zrobić oraz jakie mamy warunki i preferencje. To się tyczy zarówno programistów, jak i testerów czy specjalistów Quality Assurance (QA).

Nie wspominam tu o narzędziach infrastruktury typu repozytorium, Docker, czy całe pipeline’y, bo zakładam, że to bardziej sprawa całej organizacji, niż pojedynczego testera czy programisty.

Oferty pracy regular z

Powiedziałaś, że tester ma inne podejście do testowania. To znaczy, że tworzy więcej plików testowych?

Odnoszę wrażenie, że tester częściej korzysta z rozszerzeń do przeglądarek (jeśli testuje akurat soft webowy) no i instaluje więcej rodzajów danego oprogramowania — np. kilka typów przeglądarek albo klientów poczty (np. testując szablon maila). Z pewnością tester tworzy też więcej plików testowych — czy to obrazów, czy plików tekstowych czy jeszcze innych. Pamiętajmy, że narzędzia to zarówno te “twarde”, techniczne elementy jak IDE, terminal, ale też “miękkie”, jak zestawy dobrych praktyk, checklisty (listy kontrolne), retrospektywa, Definition of Ready, dobre procesy wspierające szybkość wykonania zadań, efektywność i harmonię zespołu. QA używa więcej tych “miękkich”.

Generalnie współdzielimy narzędzia — tester i programista mają do dyspozycji to samo. Pytanie czy w ten sam sposób i z taką samą częstością z tego korzystają. Dobór konkretnych narzędzi zależy od firmy oraz technologii, w jakiej firma pracuje. Często pracownicy mają w firmach mniejszą lub większą dowolność w doborze narzędzi, ale najczęściej jest jakiś ogólny trend firmowy — np. produkty enterprise albo wręcz przeciwnie, bo open source.

Dla podsumowania powiem może trochę trywialną rzecz, ale jakże prawdziwą — QA, tester pracują najbardziej swoim mózgiem i umysłem, jak zresztą wszyscy pracownicy branży IT.

Zauważyłaś, że na bootcampach i różnych kursach programowania raczej mało czasu poświęca się tematowi testowania oprogramowania? Skąd się to bierze i czym może skutkować?

Moim zdaniem wyodrębnienie się dziedziny testowania jako samodzielnego obszaru nastąpiło o wiele później, niż wyodrębnienie się dziedzin informatyki i programowania. Przez to testowanie jest nieco mniej ugruntowane w kanonach wiedzy. Z moich spostrzeżeń wynika, że w Polsce dopiero dekadę temu zaczęły szerzej pojawiać się informacje, artykuły i kursy testerskie. Podobnie z community, które też napędza rynek — działa niecałą dekadę. Zatem fakt, że w ogóle testowanie pojawia się czasami w kursach programistycznych lub jako samodzielne kursy, napawa optymizmem.

Niedobór czasu poświęconego na naukę testowania oraz samo testowanie skutkuje zawsze tym samym — nawarstwianiem się złych praktyk, długu technicznego i grozi odroczonym wstydem za własny soft. To jak w życiu — kto nie wystawia się na opinię innych i nie stara się być coraz lepszym w tym, w czym się szkoli, ten de facto cofa się w rozwoju.

Co do treści samych kursów to podejrzewam, że wiele firm myśli logiką pieniądza — upakujmy najbardziej korzystny marketingowo content w jak najmniejszą ilość godzin. Temat testowania nie jest tak marketingowy “hot” dla programistów, jak temat popularnych bibliotek. Poza tym bez testowania da się napisać kod, prawda? Potem ten kod jest co prawda nierzadko jak jabłko-robaczywka, ale póki jakoś wygląda i przechodzi “happy path’y” to jest super i początkujący programista jest szczęśliwym konsumentem kursu. Nauka pisania kodu dobrej jakości czeka go dopiero w pracy, kiedy już ją dostanie.

Zaznaczam, że nie oceniam tu wszystkich kursów — z pewnością istnieją takie, podczas których zwraca się uwagę na testowanie i jakość kodu.

Sama też uczysz testowania podczas szkoleń. Co na zajęciach mówisz na temat programowania?

Mówię o programowaniu jako zestawie umiejętności i sposobie myślenia, staram się budować szacunek do umiejętności programistów. Mówię też o dobrych praktykach. Ponadto zachęcam do zaglądania w devtoolsy, walidatory webowe CSS, HTML, jak chociażby te od W3C. Programowanie i testowanie to są dwie okładki tej samej książki, rozdzielanie ich grubą kreską jest moim zdaniem wprowadzaniem sztucznego i szkodliwego podziału. Przecież wszyscy (programiści, testerzy i inni członkowie zespołu) walczymy o to samo — dobrej jakości produkt. Czyli w skrócie: produkt napisany kodem, który będzie satysfakcjonował nas, jak i klientów i przede wszystkim użytkowników.

Twoim zdaniem pracodawcy na rozmowach rekrutacyjnych powinni większą uwagę zwracać na umiejętności testerskie programisty?

Mam przyjemność być już w drugiej firmie, gdzie w ramach rekrutacji programistów na rozmowie technicznej jedno z pytań brzmi “Jak dbasz o jakość swojego kodu?”. Nie chodzi tu może o samo testowanie czy znajomość technik projektowania testów, ale o skuteczne, nawet własne sposoby dbania o to co się pisze i commituje do wspólnej puli kodu oraz docelowo na produkcję.

Wspaniale jest pracować z programistami, którzy potrafią coś ciekawego odpowiedzieć na takie pytanie rekrutacyjne, bo współpraca z nimi jest o wiele bardziej efektywna. No i jest zwyczajnie fajniej działać razem z kimś, kto rozumie co robisz jako tester czy QA oraz rozumie po co to robisz.

Gorąco polecam pracodawcom i rekruterom zadawać pytania z obszaru jakości i testowania nie tylko na rekrutacjach testerskich. To świetnie weryfikuje podejście kandydata do pracy, jego “mindset” oraz wskazuje na zaawansowanie kandydata. A dodatkowo można dowiedzieć się o nowych sposobach dbania o jakość i wypróbować je w firmie, nawet jeśli kandydat ostatecznie nie nawiąże z nami współpracy.

Ile jest kreatywności w pracy testera i na czym ona polega? Z jakimi problemami/wyzwaniami spotyka się tester?

O ile kreatywność programisty wydaje się wszystkim oczywista (w końcu tworzy kod — albo od zera, albo rozwija kod już istniejący), o tyle kreatywność testera bywa poddawana dyskusji, zwłaszcza przez osoby, które mało się znają na testowaniu i QA.

Zacznijmy od samego testera i testowania. Podstawowe obszary dla kreatywności testera zaczynają się zanim powstanie linijka kodu. Jest to między innymi zrozumienie i “przetrawienie” założeń projektu oraz wymagań technicznych i biznesowych, zwalidowanie ich czyli stwierdzenie czy mają sens w stosunku do wybranych rozwiązań, a także weryfikacja, czy te wymagania faktycznie spełnią potrzeby klienta i użytkowników.

Kolejną sferą dla kreatywności testera jest wymyślanie przypadków testowych (nie mam tu na myśli pisania przydługawych kroków wykonywania testów, ani tym bardziej ‘przeklikiwania’ przez napisane przez kogoś kroki), dzięki którym powinno się przewidzieć, co może pójść nie tak w różnych warunkach, jakim poddamy soft. Często przypadki te trzeba wymyślić nie mając jeszcze ani napisanego kodu, ani designów, a wymagania dosyć niejasne.

Mam tu na myśli zarówno testy funkcjonalne (różne przypadki tzw.“happy path”, a także różne przypadki “negative testing”), jak i obciążeniowe (np. czy w przypadku tej aplikacji jest sens rozważać sytuację zalogowania się w niej 1 mln użytkowników na godzinę z różnych stref czasowych? Czy tylko 1000 z jednego kraju?), jak i testy bezpieczeństwa (np. czy w tym polu potrzebujemy walidacji zarówno po stronie frontendu i backendu?), jak i wszelkie testy, jakie tester widzi, że warto byłoby wykonać. Tutaj jest pole do popisu dla kreatywności testera.

Oczywiście programista też powinien przemyśleć różne przypadki. Jednak jakoś tak się dzieje, że często tester potrafi ich podać więcej na dany czas. Dlatego doświadczeni programiści, mimo że sami są niezwykle kreatywni, to chętnie korzystają z pomocy testerów i doceniają testerską perspektywę.

A z jakimi problemami spotyka się QA?

Quality Assurance to obszar działań jeszcze szerszy niż testowanie. Obejmuje on swego rodzaju doradztwo na każdym kroku projektu oraz współpracę ze wszelkimi rolami w projekcie. QA prócz robienia tego co tester, dodatkowo tworzy lub stymuluje tworzenie narzędzi usprawniających pracę, pilnuje procesu wytwórczego (np. proponuje jakie kroki powinna przejść zmiana od programisty do wydania na produkcję, albo pilnuje istniejącego procesu, mierzy czy ten proces działa, przypomina o dobrych praktykach), a także zadaje odpowiednie pytania w odpowiednim czasie.

To już jest ekstremalnie kreatywna sytuacja, gdyż nie ma dwóch identycznych projektów o takich samych osobach w zespole, o takim samym przebiegu oraz przedmiocie działań. Ponadto tester i QA często są jakby tłumaczami z “języka technicznego” na “język ludzki”. Można więc powiedzieć, że zarówno tester, jak i QA jest czasem współtwórcą, czasami tłumaczem, redaktorem, adwokatem.

Przytoczę kolejną metaforę — programista i tester są jak poeta i interpretator. Nie każdy potrafi napisać wiersz, ale czasami trudniej jest zinterpretować wiersz, niż go napisać (zwłaszcza jeśli poeta jest małomównym człowiekiem niepiszącym treści w zadaniach ani dokumentacji). No i tester też jest czasami poetą — tworzącym takie opisy zadań, czy przypadków, czy raportów błędów, czy raportów testów — by były zrozumiałe zarówno dla programistów, jak i biznesu. A to naprawdę czasami nie lada wyzwanie, nawet w rodzimym języku.

Zobacz też

Polski Ład Polski Ład w praktyce - co się zmieniło od stycznia? Wywiad z Piotrem Juszczykiem

Co motywuje testera? Co sprawia, że dalej chce zajmować się testowaniem?

Motywatory wewnętrzne testera to między innymi: pasja detektywa, chęć rozwiązywania zagadek i wymyślania przypadków, wyzwanie namierzania ryzyk, ciekawość różnego rodzaju softu albo nowych integracji między softami, ciekawość nowych technologii oraz ich mocnych i słabych stron, pasja tropienia różnego rodzaju niespodziewanych błędów, chęć współpracy z coraz lepszymi programistami, DevOpsami, Project Managerami, analitykami, projektantami systemów, designerami (itd.).

Co do motywatorów zewnętrznych to prócz interesujących projektów, pensji i atmosfery w pracy mogą to być wyzwania merytoryczno-społeczne jak udział w meetup’ach, konferencjach, spotkania z innymi ludźmi zajmującymi się jakością (nie tylko testerami). Mnie motywuje też chęć dzielenia się potem zdobytą wiedzą z innymi, taka trochę misja społeczna — czy to będzie “poratowanie” mojego zespołu znalezieniem ryzyka albo “luki” zanim w nią wpadniemy, czy to będzie prelegowanie na meetupie czy konferencji, czy prowadzenie warsztatu. Prócz samej chęci by wiedzieć więcej i szerzej (zobacz “T-shaped tester”), chcę się zajmować testowaniem, jakością, QA po to, by lepiej się przydać ludziom naokoło (praca, po pracy, end userzy). Informatyzacja dotyka całą ludzkość, czy ktoś pracuje na komputerze, czy tylko jeździ tramwajem — a stosunek specjalistów IT do całej ludzkości jest dość ułamkowy. W taki sposób definiuję swoją misję społeczną — by więcej ludzi było mniej zagubionych w świecie.

Co testerowi przeszkadza w pracy?

Zawsze chciałoby się mieć więcej czasu na testy — przeszkadza więc czas. Głowa pęka od pomysłów, a czas nagli. Zatem sztuką w pracy testera jest priorytetyzacja przypadków testowych, czyli wybieranie i wykonywanie takich testów, które najszybciej dadzą największą wartość i najbardziej przekrojowy efekt. Im lepszym jesteś testerem i QA, tym więcej widzisz rzeczy do sprawdzenia, testów wartych wykonania i potencjalnych ryzyk do namierzenia. Musisz nauczyć się sobie z tym radzić w świecie IT pędzącym na łeb na szyję z czasem zamówienia i wykonania softu (presja czasu dotyczy oczywiście nie tylko testerów).

Ponadto trudną kwestią często przeszkadzającą w skupieniu się na zadaniu jest konieczność dzielenia uwagi. Tester częściej niż programista musi “przełączać” się między zadaniami. Czasami, w zależności od specyfiki firmy, zadania te są diametralnie różne.

Mogę dodać jeszcze, że choć komunikacja to naturalny element pracy testerskiej, którą zresztą lubię, to czasami zbyt dużo osób “dobija się” do testera. Wynika to między innymi z tego, że tester jest, jak wcześniej wspominałam, czasem takim tłumaczem z “technicznego” na “ludzki”. Osoby mniej techniczne miewają tendencje do dopytywania się testera o stan implementacji albo wytłumaczenie czegoś co mówił/pisał programista, zaś osoby techniczne czasami dopytują go o to, jak rozumieć wymagania biznesowe zarysowane na spotkaniu koncepcyjnym projektu lub w zadaniach już stworzonych przez osoby nietechniczne.

Oczywiście w dojrzałych zespołach poszczególne osoby raczej same zadają odpowiednie pytania i robią to na czas (np. na samym spotkaniu startującym projekt a nie już po napisaniu jakiegoś kodu), jednak i tak zawsze pozostaje wiele rzeczy do ukonkretnienia w toku życia projektu i często to ukonkretnianie zostaje po stronie testera.

Wspomniałaś o czasie. Powiedz, jakie błędy są trudniejsze do wykrycia i wymagają więcej pracy testera?

Wszelkie błędy na styku systemów (np. funkcjonalna integracja zewnętrznego systemu płatności) wymagają więcej uwagi i często więcej zachodu by zostać wykrytymi. Na poziomie kodu dobrą robotę robią automatyczne testy integracyjne. Jednak nie każde flow da się w pełni załatwić takimi testami. Czasem warto się po prostu “przeklikać” przez flow różnymi ścieżkami.

Często nie jesteśmy pewni od razu, czy błąd leży po stronie naszej integracji z zewnętrznym dostawcą (tzw. ’third party vendor’), czy też ów dostawca ma błąd po swojej stronie. Jeżeli nie mamy żadnego wglądu do systemu dostawcy to jesteśmy zdani na maile i telefony do dostawcy co najczęściej trwa o wiele dłużej, niż zerknięcie w kod lub do bazy.

Bardzo żmudne jest też wyłapywanie błędów w pełnych ścieżkach użytkownika (end-to-end), zwłaszcza jeśli wykonujesz je kilka razy pod rząd (co zasadniczo powinno dziać się jak najrzadziej, bo od tego są testy automatyczne). Wówczas łatwo o zwykłe ludzkie przeoczenie i zmęczenie poznawcze. Warto podzielić sobie taki test na części i robić sobie małe przerwy, by nie stracić czujności. Najgorsze są tzw.”heisenbugi”.

“Heisenbugi” — co to?

To błędy występujące czasami i w trudno uchwytnych warunkach. Zdarza się, że programista na taki błąd nie trafi, a Ty jako tester trafisz, ale nie potrafisz ich zreprodukować 🙁 Jesteś pewna/pewien, że dany błąd istnieje, tylko cholernie trudno jest Ci określić w jakich warunkach występuje. Otrzymasz go np. 2-3 razy, albo co 10 raz… i tracisz siły, cierpliwość, a czas mija.

W zasadzie nie ma jednej recepty na “heisenbugi”. Czasami po konsultacji z zespołem lub liderem zostawia się taki błąd w spokoju. Ale w duszy testera pozostaje niepokój, że błąd pozostanie bezkarny 😉 Pół biedy jeśli to coś błahego jak na przykład zmiana stylu czcionki na pół sekundy. Gorzej jeśli to bug, który blokuje użytkownikowi dostęp do aplikacji. A i takie się niestety zdarzają. Wówczas nie pozostaje nic innego, jak tropić takiego “heisenbuga” do skutku i naprawić.

Zobacz też

Praca w IT Luxoft wprowadza system Advanced Hiring. Czym różni się od zwykłej rekrutacji?

Do czego testerowi przydaje się znajomość biznesowej strony danego przedsięwzięcia? Możesz podać przykład?

Biznesowa strona projektu jest równie ważna jak techniczna. Nie możesz być dobrym testerem jeśli którąś z tych stron ignorujesz. Zresztą programista też niedobrze by ignorował stronę biznesową. Przykład ogólny mogę podać taki, że soft może działać poprawnie (np. technicznie poprawnie), ale w sposób zupełnie niepodobny do zamierzonego (np. niezrealizowane założenie biznesowe).

Przykład konkretny nr 1: Klient chciał, by kliknięcie w przycisk powodowało przejście na kolejną stronę aplikacji. Napisany kod pozwala na to, ale przycisk jest tak duży, że zasłania kluczowy fragment tekstu strony poprzedniej. Tutaj spełnione zostały założenia techniczne, ale zaniedbany został aspekt biznesowy.

Przykład konkretny nr 2, nieco hardcorowy: Klient chciał, by pole adresu email czyściło się z formularza logowania przy odświeżeniu sesji przeglądarki (np. przeładowaniu strony). Programista napisał kod, który to robi, jednak zrobił on to tak dziwnie, że to czyszczenie pola obejmuje działanie na bazie danych w postaci usunięcia adresu email w ogóle z bazy klienta. Tutaj zatem biznesowy, jak i techniczny aspekt jest teoretycznie zrealizowany, ale technicznie jest to implementacja niedopuszczalna, głupia wręcz. W tym przykładzie wymagania biznesowe i techniczne zostały spełnione, ale były niedoprecyzowane. Teoretycznie wiadomo, że żaden klient nie chce raczej tracić w taki sposób danych swoich klientów, ale nie należy brać niczego za pewnik, tylko dopytać czy aby na pewno tak to powinno działać.

Poruszyłam przy okazji temat jakości wymagań — im bardziej konkretnie są one sformułowane i im więcej przypadków wypunktujemy w nich zawczasu, tym bardziej sensowna będzie praca programisty, a także testera po napisaniu kodu przez programistę. No i ponadto: dobrze określone wymagania = szybciej dostarczona satysfakcjonująca implementacja.

Co byś radziła programistom, którzy chcą podnieść swoje umiejętności testerskie?

Gdzie są tacy programiści? Chcę ich poznać! 🙂 W celu podniesienia umiejętności testerskich mogę polecić rozmowy z testerami, dev-tester pairing, czytanie blogów testerskich, wejść na grupy na Facebooku albo artykuły o testowaniu.

Gorąco polecam też uczyć się testerskiego sposobu myślenia, takiego “inverse engineering” — popatrz na kod lub całą funkcjonalność niczym na element większej całości, który wcale nie działa zawsze w ten sam sposób. Nawet jeśli jesteś święcie przekonana/przekonany, że tak właśnie zawsze działa. Pomyśl, co musiałoby się wydarzyć, jakie warunki musiałyby zaistnieć, by to działało inaczej albo co gorsza błędnie.

Zdekomponuj swoje postrzeganie softu na rzecz postrzegania interfejsu użytkownika. Przypomnij sobie jak to jest, kiedy widzisz dany projekt pierwszy raz i próbujesz rozgryźć jak on działa. Zajrzyj najpierw od strony użytkownika, ignorując chociaż na chwilę sam kod. Dzięki temu poznasz ograniczenia, jakich doświadcza użytkownik i będziesz w stanie trafniej uczynić kod bardziej pomocnym dla użytkownika. A przecież o to między innymi walczymy.

Aleksandra Kornecka. Software Quality Assurance Engineer oraz certyfikowana testerka. Pasjonatka dbania o jakość w IT, nurtu TestOps, analizy wymagań, user experience, ochrony danych osobowych oraz architektury informacji. Pomysłodawczyni i liderka Girls Who Test oraz mentorka wielu adeptek i adeptów testowania. Prelegentka meetupów i konferencji w Polsce, a czasem i na świecie. Autorka tekstów o testowaniu, branży IT oraz jakości.