Łukasz Kołpak
Łukasz KołpakQuality Assurance Team Leader

Instrukcja obsługi testera

Sprawdź, co musisz wiedzieć o pracy testera i współpracy z nim, żeby żyło Ci się lepiej.
17.12.20214 min
Instrukcja obsługi testera

Z racji stale rosnącej popularności metodyk zwinnych w procesie tworzenia oprogramowania, w zespołach testowych coraz częściej znajduje swoje miejsce dedykowany tester. Niestety, taka sprawa nigdy nie jest tak prosta, jak posadzenie nowego członka zespołu przed komputerem, i powiedzenie: “masz, testuj”. Niezależnie od doświadczenia programisty, w karierze wielu z nich następuje kontakt z testerem. Czego się spodziewać po takiej sytuacji? Czy to już czas na zmianę pracy? Oto kilka kluczowych punktów, które mogą być pomocne w oswojeniu się z nową sytuacją.

Tester nie jest Twoim wrogiem

Stereotypowy tester jest często przedstawiany jako nemesis programisty - ktoś, kogo głównym celem jest znajdowanie dziury w całym i wytykanie ludziom, że źle wykonują swoją pracę. Oczywiście, jest to dość karykaturalne zobrazowanie, ale mimo wszystko, czasem ciężko jest nie wziąć tego do siebie, kiedy nowy feature, na którego implementację poświęciłeś ostatnie dni, wraca do Ciebie po 30 minutach z listą rzeczy, które według testera powinny zostać poprawione.

Takie odczucie jest w pełni zrozumiałe, ale trzeba pamiętać, że zadaniem testera nie jest ocenianie osoby, a zapewnienie jak najlepszej jakości dostarczanego oprogramowania.

Komunikacja to podstawa

Skutkiem ubocznym obecności testera w zespole projektowym jest znaczne zwiększenie przepływu informacji - na więcej niż jednej płaszczyźnie.

    • Komunikacja 1:1 - pytania o bieżąco sprawdzane feature’y/taski - testerzy zwykle wychodzą z założenia, że lepiej dopytać, niż od razu zgłaszać. A może to jednak feature, a nie bug? :)
    • Issue tracker - główna wykładnia testera testującego bieżące zadania. Jest inaczej niż w description? Bug. Funkcjonalność nie zgadza się z kryteriami? Reject.


Warto korzystać z komentarzy, jeśli podczas implementacji zadania okazało się, że coś będzie inaczej niż zapisane w tickecie - jeśli nie będzie takiej informacji, tester i tak wróci. Pro tip: +10 do reputacji u testerów za wrzucanie komentarzy, jeśli coś może być trudne do sprawdzenia ;)

Ustalenie zasad współpracy

…czyli więcej komunikacji. Zorganizowanie 30-minutowego spotkania, gdzie w gronie programistów i testerów będzie można porozmawiać o wzajemnych oczekiwaniach bardzo pomaga, nawet jeśli obie strony mają już doświadczenie w pracy tego typu. Każdy projekt, i każdy człowiek jest inny - poświęcenie pół godziny na początku współpracy na pewno oszczędzi dużo więcej czasu (i niepotrzebnych nerwów) w dłuższej perspektywie.

Obecność testera nie zwalnia programisty z testowania

Mamy testera, więc nie muszę się przejmować bugami.” Brzmi dość logicznie, ale niestety rzeczywistość jest nieco inna. Za jakość jest odpowiedzialny nie tylko tester, ale wszyscy członkowie zespołu.

Co to znaczy w praktyce? Jeśli programista wypycha zadanie do testów, powinien się upewnić, że wszystkie kryteria są spełnione, a sama funkcjonalność działa na docelowym środowisku. Domyślam się, że brzmi to jak oczywistość, ale w praktyce, nie do końca zaimplementowane funkcjonalności, oraz takie, które np. wyrzucają error 500 przy podstawowej ścieżce, zdarzają się relatywnie często.

Inna nie do końca intuicyjna rzecz: testowanie przez programistę oszczędza jego czas. Biorąc pod uwagę scenariusz, gdzie błąd jest oczywisty i dotyczy głównej ścieżki, wyłapanie go przez programistę oszczędza czas na kilka sposobów:

  • naprawienie błędu jest prostsze (naprawianie błędu od razu vs. wracanie do niego np. następnego dnia)
  • nie trzeba robić dwa razy Code Review
  • tester nie odrywa deva od pracy przy kolejnym zadaniu

Testowanie zajmuje czas

Testowanie nie dzieje się magicznie - każdy to wie. Ale jest jeden moment, kiedy duża część osób o tym zapomina - koniec sprintu. Sytuacja, kiedy 80% zadań jest kończona w popołudnie ostatniego dnia sprintu jest… nie do końca idealna. Doliczmy jeszcze czas na Code Review, zbudowanie się środowiska, i nagle na testerze tworzy się duża presja. Rozwiązanie - patrz punkt 2 :)

Tester a estymacje

Przychodzisz na swoje pierwsze spotkanie estymacyjne, a tutaj tester. Ale dlaczego? Otóż, w tym szaleństwie jest metoda.

Domyślną praktyką w Agile jest estymacja czasu potrzebnego do uznania zadania za wykonane - oznacza to, że estymata powinna składać się nie tylko z czasu programisty, ale również i testera. Oczywiście, najłatwiej ocenić czas na testy, kiedy na spotkaniu jest właśnie tester :)

Innym plusem jest to, że rolą testera jest upewnianie się, że estymacje uwzględniają wszystkie obsłużone przypadki - “Hej, a czy te 5 storypointów uwzględnia, że user może zrobić Y, robiąc X?”.

Dlaczego nie każdy tester automatyzuje

Czytając okresowy feedback devów na temat testerów, najczęściej powtarzającym się zdaniem jest “Wszystko super, ale byłoby jeszcze lepiej, gdyby pisał automaty.” Krótko mówiąc, to nie działa w ten sposób.

Na to, czy tester pisze testy automatyczne w projekcie, ma wpływ wiele czynników - budżet, decyzje klienta, charakter projektu, aspekty techniczne, obłożenie czasowe, czy też stopień zaawansowania i chęci danego testera. Jak widać - czynników jest mnóstwo. Trzeba brać też pod uwagę fakt, że testy automatyczne nie są jedyną ścieżką rozwoju testera, więc o ile taka osoba z pewnością widzi, jakie benefity niosą ze sobą takie testy, o tyle po prostu może siebie nie widzieć w takiej roli.

Podsumowanie

Jak widać, współpraca programisty i testera nie tylko nie musi być antagonistyczna, a z odpowiednią dozą komunikacji i dobrej woli, uzupełnia się nawzajem, i tworzy współpracę, która wnosi więcej, niż te dwie jednostki oddzielnie. Słowo-klucz na dziś, to synergia. Oczywiście, ten tekst jest tylko zalążkiem góry lodowej, ale mam nadzieję, że dzięki niemu tester nie jest taki straszny, jak go malują. Koniec końców, wszyscy mamy ten sam cel - dostarczyć coś, co działa.

<p>Loading...</p>