10 prostych sposobów, aby programiści znienawidzili cię

Jeśli pracujesz jako tester, możesz wiedzieć coś na temat relacji tester vs. programista. Musimy współpracować, aby projekt szedł naprzód. Oto dziesięć sposobów, aby zniszczyć tę kruchą równowagę.

  1. Zgłaszaj błędy opisane jak najbardziej ogólnie
    • Tytuł: „System nie działa”
    • Opis: „System po pewnym czasie przestaje działać na moim komputerze
    • Priorytet: krytyczny
  2. Programiści często czują się źle, kiedy w ich kodzie zostanie znaleziony błąd. Możesz wzmocnić ten efekt dokładnie wskazując, kto napisał dany fragment kodu.
  3. Krytykuj publiczne.
  4. Przetestuj nieaktualny build. Zgłoś krytyczny błąd. Pozwól programiście spędzić dzień na analizie problemu. Kiedy w końcu zorientuje się, że testowałeś na starej wersji, na pewno zapamięta twoje imię.
  5. Jeśli masz taką możliwość, wskaż sposób poprawienia błędu i wyznacz deadline.
  6. Nalegaj, aby każdy znaleziony przez ciebie błąd został poprawiony. Nawet jeśli czujesz, że nie warto tego poprawiać.
  7. Eskaluj do przełożonych w projekcie. Zaangażuj ich w długie, techniczne dyskusje prowadzone wyłącznie drogą mailową.
  8. Najlepsze zachowaj na koniec. Blokujący dostawę, krytyczny błąd zgłaszaj tuż przed końcem etapu testów. Liczy się efekt WOW i miny deweloperów.
  9. Zgłaszaj zduplikowane raporty błędów. Nie spędzaj swojego czasu na przeglądnięcie listy istniejących defektów.
  10. Przerywaj im regularnie, kiedy kodują. Powrót do rytmu pracy zajmuje średnio 20 minut. Ale to nie twoje minuty.

Cechy testera i programisty

Proces wytwarzania oprogramowania wymaga zaangażowania całej grupy projektowej.
Skupię się jednak na dwóch rolach: testera i programisty. Ten sam projekt – zupełnie różne punkty spojrzenia. Inaczej mówiąc: dwie grupy pomiędzy którymi problemy w komunikacji stanowią źródło zagrożeń dla jakości systemu.

W dobrze dobranym zespole projektowym testerzy i programiści uzupełniają się nawzajem, dostarczając umiejętności, wiedzę i spoglądając na tworzoną aplikację z różnej perspektywy. Typowym błędem jest postrzeganie testerów jako “młodszych programistów”, a co za tym idzie zachęcanie ich do rozwijania umiejętności i nastawienia typowego dla programistów.

W rzeczywistości dobry tester posiada cechy kontrastujące z tymi, których potrzebuje dobry programista. Rozumiejąc to, menedżer może połączyć owe cechy w jeden, dobrze funkcjonujący zespół.

Wielu programistów nie zdaje sobie sprawy jak trudnym zadaniem jest testowanie. Cierpliwość, elastyczność, umiejętność dostrzegania szczegółów i obraz całego mechanizmu działania systemu.
Wielu testerów jest sfrustrowanych, pracując z programistami, którzy uważają testowanie za oraz pracę “drugiej kategorii” lub coś co robić może każdy.

Testerzy potrzebują tego rodzaju wiedzy, który posiadają końcowi użytkownicy systemu. To pozwala im na używanie produktu w sposób w jaki robi to klient zamiast tak jak chciałby tego programista. Dobre pytanie – czy znajomość wewnętrznej architektury aplikacji pomaga czy przeszkadza w przeprowadzeniu testów? Moim zdaniem nie jest konieczna do wykonania testów.

Testerzy powinni przejawiać specyficzny rodzaj ignorancji czy co więcej -naiwności w odniesieniu do testowanego systemu. Programiści nie. Jest to jedną z przyczyn dla której programiści mogą uznać testera za osobę zadającą oczywiste czy wręcz głupie pytania :)
Dobrzy testerzy posiadają wiedzę zarówno na temat wymagań klienta jak i – do pewnego stopnia – działania systemu wewnątrz. Pozwala to spojrzeć na testowany system z innej niż programista strony.

Cechy dobrego testera:
– nie obawia się reakcji na złe wiadomości, które przynosi
– potrafi rozdzielić błąd od osoby, która go popełniła
– informację o znalezionym błędzie potrafi przedstawić w neutralny sposób

Komunikacja, tester i programista

Testerzy nie powinni unikać konfrontacji. Przynoszenie “złych” wiadomości to ich praca, jednak nie zawsze jest to dobrze przyjmowane. Czasami trudno jest określić przyczynę błędu. Czy jest to błąd w wymaganiach, kodzie czy w dokumentacji. Zdarza się, że błędu nie ma, jednak tester nie jest pewien jak interpretować działanie aplikacji.

Niezależnie od przyczyny – zadaniem testera jest zgłoszenie problemu. Niektórzy z nas mogą iść o krok dalej wskazując błąd ORAZ programistę aby skłonić go do lepszej pracy. To nie pomaga. Spekulowanie – kto, w jakim miejscu i kiedy, zrobił błąd, jest złe z dwóch powodów:
– szukanie winnych nie pozwala skupić się na pracy
– to źródło konfliktów w grupie