Psychologia testów

Charakterystyka pracy podczas testowania i przeglądu dokumentów jest różna do tego jaka powstaje podczas analizy i rozwoju oprogramowania.

Programiści są zdolni do testowania własnego kodu, ale rozdzielenie tych obowiązków na testera i programistę jest działaniem korzystnym. Uzyskujemy niezależny wgląd w kod dokonany przez wykwalifikowaną i profesjonalnie przygotowaną kadrę testerów. Niezależne testowanie może odbywać się na każdym poziomie weryfikacji.
Wysoki poziom niezależności (unikając stronniczości autora) jest bardzo efektywny w znajdywaniu defektów i uszkodzeń z nich wynikających. Niezależność nie wyklucza jednak, że również programiści mogą samodzielnie wychwycić dużo błędów we własnym kodzie.
Zdefiniowano kilka poziomów niezależności:
  • projektowanie testów przez osobę, która pisze testowane oprogramowanie (niski poziom niezależności)
  • projektowanie testów przez inną osobę (np. z ekipy programistów)
  • projektowanie testów przez osobę z innej grupy organizacji (np. niezależny zespół testowy)
  • projektowanie testów przez osobę z innej organizacji lub firmy (np. certyfikowanie przez zewnętrzną organizację)

Ludzie i projekty kierowane są poprzez różne cele. Ludzie są skłaniani do dopasowywania swoich planów do celów przez zarząd oraz innych udziałowców np. dla znalezienia defektów lub potwierdzenia, że oprogramowanie działa. Ważne jest więc aby cele były czytelne dla całej organizacji.

Identyfikacja problemów podczas testowania może być postrzegana jako kryzys w projekcie i wymierzony w autora. Testowanie jest więc rozważane jako destruktywna czynność, nawet gdy jest bardzo konstruktywna w zarządzaniu ryzykiem. Szukanie problemów w systemie wymaga ciekawości, profesjonalnego pesymizmu, krytycznego spojrzenia, przypisywania uwagi do szczegółów, dobrej komunikacji z kolegami programistami i doświadczeniu, na którym można oprzeć zgadywanie błędów.

Gdy błąd, defekt i jego konsekwencje są zakomunikowane w konstruktywny sposób, negatywne emocje pomiędzy testerami a analitykam, projektantami i programistami mogą być wykluczone. Zasada ta stosuje się nie tylko do testowania ale i do przeglądu dokumentacji.

Testerzy i liderzy grup testowych muszą potrafić komunikować defekty, postęp, ryzyko z użyciem świetnych umiejętności interpersonalnych i w konstruktywny sposób. Dla autora oprogramowania lub dokumentu informacja o defektach może być pomocna w uczeniu się na własnych błędach. Znalezione defekty, które zostały naprawione podczas testowania oszczędzą organizacji czas i pieniądze i obniżą ryzyko.

Problemy komunikacyjne mogą pojawić się gdy tester jest postrzegany jako dostarczyciel złych wiadomości o defektach. Jednakże istnieje wiele dróg dla poprawienia zdolności komunikacji i współpracy między testerami i innymi pracownikami firmy:
  • rozpocząć współpracę raczej niż walkę – przypomnieć wszystkim o wspólnych celach polepszenia jakości systemu
  • zakomunikować informacje o produkcie w sposób neutralny i skoncentrowany na faktach, bez krytyki osób, które go stworzyły; dla przykładu zapisać obiektywnie i zgodnie z faktami raporty na temat przypadków i przejrzeć spostrzeżenia
  • spróbować zrozumieć jak odczuwają ludzie i dlaczego reagują tak jak reagują
  • upewnić się, że każda osoba rozumie co zostało powiedziane i vice versa.

 

 

Najbliższe terminy szkoleń

 

28-30 listopada - Katowice

ISTQB Poziom Podstawowy (Foundation Level)


28 listopada-1 grudnia - Wrocław

Zawód Tester


4-6 grudnia - Warszawa

ISTQB Poziom Podstawowy (Foundation Level)

 

Partnerzy

Narzędzia testerskie