Redakcja
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.
- 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.
- 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.
