Kilka lat temu gdy zaczynaliśmy budować Divante byłem dużym przeciwnikiem osobnego stanowiska „Testera oprogramowania”. Bardzo mocno wierzyliśmy, że to programiści – w prawdziwym, zwinnym zespole – powinni testować wyniki swojej pracy. Project manager powinien testować wyniki pracy programistów. Ale dedykowany tester? Wydawało nam się to dziwne.

Wydawało mi się, że to takie rozleniwienie programistów :) Myślę, że to, że sam bardzo lubię testować (i nadal często to robię) wypaczały moją ocenę sytuacji. Myślałem wtedy, że każdy jest testerem.

Dzisiaj zatrudniamy 120 osób i nie wyobrażamy sobie życia bez testerów. Takich z prawdziwego zdarzenia, którzy budują oprogramowanie – na równi z programistami. Nasz dział QA bardzo dynamicznie się rozwija – zatrudniamy sporo nowych osób. Chciałbym podzielić się naszymi spostrzeżeniami dotyczącymi tego jak budować dział QA i współpracę testerów z innymi działami firmy.

Na blogu pojawiało się już sporo wpisów dotyczących metod zachowania jakości – checklisty, sposoby zarządzania projektami. Pora opisać najbardziej fundamentalne zagadnienia – rolę działu Quality Assurance i rolę testerów.

Kim jest dobry tester?

Z mojego doświadczenia dobry tester to osoba którą nie zadowalają zdawkowe odpowiedzi i jest bardzo bystra. Ciągle doszukuje się przyczyn działania (lub nie) funkcji. Próbuje zrozumieć mechanizmy i wychwycić dziury. Osoby które chcą być dobrymi testerami powinny mieć mindset pilotów oblatywaczy. Ryzykują, używając nieznany system. Nie wiadomo co się stanie. Wiadomo, że będą błędy. Dużo błędów – które trzeba znaleźć. W inny sposób nigdy nie zostaną poprawione.

Testerzy powinni nie zostawiać za sobą rannych. Czyli zgłaszać wszystko co budzi ich niepokój, lepiej zgłosić więcej błędów niż mniej.

Rola testera pozwala rozwinąć się w różnych kierunkach w branży IT. Znam osoby które będąc testerami pokierowały swoją karierę w stronę zarządzania projektami, w stronę programowania a jeszcze inni zostali analitykami biznesowymi.

Dzieje się tak dlatego, że na wszystkich tych stanowiskach jest potrzebne to co tester musi wykazywać od dnia zero dobre zrozumienie działania systemu który testuje.

Co ciekawe nie zauważyłem, aby dla bycia dobrym testerem miało znaczenie wykształcenie, poprzednie doświadczenie zawodowe :-)

Jakie rodzaje testów wykonuje tester?

To zależy. W Divante mamy dosyć podzielone kompetencje – jedne osoby zajmują się testami automatycznymi (np. Selenium), testami wydajnościowymi (np. JMeter), inne osoby są testerami funkcjonalnymi (sprawdzają działanie funkcji, zgodne z dokumentacją). Jeszcze inne osoby piszą dokumentację do testów.

Wszystko zależy od profilu osoby i tego co ją interesuje. Zasady współpracy testera z innymi osobami z zespołu w każdej specjalności są generalnie podobne i zaraz powiem o co chodzi.

Jak wygląda dzień pracy testera?

Pewnie w każdej firmie inaczej. W Divante testerzy wchodzą w skład zespołów projektowych. Czasami na pełen etat, czasami biorą udział w dwóch projektach na raz. Tester bardzo dużo się komunikuje – rozmawia z programistami, liderem technicznym i project managerem  aby uzyskać informacje potrzebne do wykonania testów. Jak coś działa, dlaczego nie działa i kiedy zacznie :)

Jeśli wykonywane są testy funkcjonalne to dzień pracy zazwyczaj zaczyna się i kończy w przeglądarce internetowej (tworzymy e-Commerce) – w systemie Redmine gdzie zgłaszane są błędy. Najpierw sprawdzane są błędy zgłoszone jako „Wymagają testów” (np. poprawione wcześniej zgłoszone usterki) – wykonywane są ich retesty (po których błędy mogą być zamykane).

Dalej testowana jest już sama aplikacja i nowe błędy pojawiają się w systemie Redmine – przypisywane do project managera lub programistów bezpośrednio.

Jak najsprawniej zgłaszać błędy?

Opisujemy generalnie maksymalnie dużo szczegółów które programiście pozwalają odtworzyć i poprawić błąd. Aby nie być gołosłownym przykład w formie krótkiej tabeli (dzięki Damian Kowalski, Automation Test Engineer).

Typ zagadnienia Błąd – Bug
Przed pierwszym zgłoszeniem zapytaj PM z jakim typem raportować błędy
Temat [KOSZYK] – Można kupić produkty ponad stan magazynowy
W nawiasie kwadratowym umieść obszar serwisu do którego dotyczy zgłoszenie. Po nim krótki opis błędu
Opis W koszyku użytkownik może zmienić ilość produktów w koszyku ponad stan magazynowy w sklepie a następnie poprawnie zrealizować zamówienie. Należy zablokować możliwość zwiększania ilości przedmiotów w koszykuZnalezione/sprawdzone na test.divante plPrzeglądarka: Chrome 38 WIN
Opis wyjaśniający możliwie szczegółowo czego dotyczy zgłoszenie. Mile widziane są też możliwe rozwiązania defektu. Jeżeli cały opis błędu jest w temacie nie bój się powtórzyć tego w opisie.
Opis c.d. Scenariusz:

  1. Znajdź produkt ze skończonym stanem magazynowym np <nazwa produktu>
  2. Dodaj do koszyka maksymalną dostępną ilość produktu
  3. Przejdź do koszyka
  4. Zwiększ ilość produktów w koszyku przez wciśnięcie przycisku “+”
  5. Złóż zamówienie
Przy bardziej skomplikowanych ścieżkach dojścia do błędu wymagany jest scenariusz w jaki sposób ten błąd odtworzyć.
Status Nowy lub Przypisany
Nowy – jeżeli rozdzielaniem zadań zajmuje się inna osoba. Jest to dla niej informacja że zadanie/błąd czeka na przydzielenie odpowiedniej osobiePrzypisany – jeżeli wiesz kto odpowiedzialny jest za część serwisu w której znajduje się defekt
Priorytet W zależności od błędu
O typach błędów można poczytać w dokumencie Kilka słów o defektach
Przypisany do PM lub programista
Pliki screen.jpg
Do każdego zgłoszenia staraj się załączać screen. Wyżej wymienione narzędzia umożliwiają bezproblemową edycję zrzutów ekranu i nanoszenie na nie strzałek, tekstów i figur.

Zrzut ekranu 2014-11-25 14.21.55

Przydatne mogą być narzędzia do szybkiego wykonywania zrzutów ekranu:

Jak wygląda rola testera w zespole?

Podstawowe zasady pracy testera przy projekcie wdrożeniowym – spisane przez Tomka Widlińskiego, Project Manager (dzięki Tomek)

  • tester zapoznaje się z założeniami projektu,
  • tester odbiera zgłoszenia od klienta i weryfikuje wstępnie (prosi w razie potrzeby o zrzuty, wskazanie przeglądarki itp.), dopiero tak obrobiony i opisany ticket może trafić do programisty (który potrzebuje informacji i zreplikowanego błędu aby móc wprowadzić poprawkę),
  • tester zna projekt i potrafi zweryfikować czy testowana funkcja spełnia założenia z dokumentacji,
  • tester obowiązkowo opisuje tickety i opatruje zrzutami (dla szybszego rozpoznania miejsca wystąpienia błędu),
  • tester dba o jakość projektu, patrzy całościowo, nie ignoruje błędów napotkanych po drodze,
  • w fazie finalizacyjnej projektu tester dba, aby wszystkie błędy w platformie miały zgłoszenie w Redmine,
  • tester wie, który programista jest odpowiedzialny za które części systemu i przypisuje zadania do odpowiednich osób,

Tester jest częścią zespołu i powinien wymagać: aby programiści lub webmasterzy nie byli niechlujni, od PMa decyzji biznesowych (np. komu przydzielić nową funkcję, której brakuje) lub pomocy w problemach jakościowych, od programistów wyjaśnień odnośnie realizowanych funkcji etc.

 

Aktualnie szukamy testerów. Możliwy jest również płatny staż w czasie którego nauczymy Cię jak być dobrym testerm w praktyce. Napisz na rekrutacja@divante.pl jeśli jesteś zainteresowany!