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