Sposób myślenia stosowany podczas testowania i przeglądania różni się od stosowanego podczas rozwoju oprogramowania. Programiści posiadający odpowiednie nastawienie są w stanie testować swój kod, ale zwykle odpowiedzialność za testowanie przekazuje się testerom żeby wzmocnić koncentrację wysiłków oraz uzyskać dodatkowe korzyści, takie jak niezależne spojrzenie wyszkolonych, zawodowych testerów. Testowanie niezależne może być wykonywane na dowolnym poziomie testów.

Niezależność do pewnego stopnia jest często bardziej skuteczna w znajdowaniu defektów i awarii (unika się stronniczości autora). Nie może ona jednak zastąpić znajomości rzeczy i z tego względu programiści są w stanie efektywnie znajdować usterki w swoim własnym kodzie. Można zdefiniować kilka poziomów niezależności (od najniższego do najwyższego):

• testy zaprojektowane przez osobę, która napisała testowane oprogramowanie (niski poziom niezależności)
• testy zaprojektowane przez inną osobę (np. z zespołu programistów)
• testy zaprojektowane przez osobę z innego zespołu w organizacji (np. niezależnego zespołu testerów) lub przez specjalistów od testów (np. testów wydajnościowych lub użyteczności)
• testy zaprojektowane przez osobę z innej organizacji lub firmy (np. testy zlecone lub certyfikacja przez niezależny organ certyfikujący)

Ludzie i projekty kierują się celami. Ludzie mają skłonność do dopasowywania planów do celów określonych przez kierownictwo lub innych interesariuszy. Na przykład, żeby znajdować błędy albo żeby potwierdzić, że oprogramowania spełnia zadane cele. Dlatego bardzo ważne jest jasne wyrażenie celów testowania.

Znajdowanie błędów podczas testów może być odbierane jako krytykowanie produktu lub jego autora. Z tego powodu testowanie często jest postrzegane jako działanie destrukcyjne, nawet jeżeli jest bardzo konstruktywne z punktu widzenia zarządzania ryzykiem produktowym. Wyszukiwanie awarii w systemie wymaga ciekawości, profesjonalnego pesymizmu, krytycznego spojrzenia, przywiązywania wagi do szczegółów, dobrej komunikacji z programistami oraz doświadczenia, na którym można oprzeć zgadywanie błędów.

Można uniknąć spięć pomiędzy testerami, a analitykami, projektantami i programistami przez komunikowanie błędów, usterek i awarii w sposób konstruktywny. Ta zasada ma zastosowanie zarówno do defektów znalezionych podczas przeglądów, jak i w testowaniu.

Tester i lider testów potrzebują dużych umiejętności interpersonalnych, żeby przekazywać fakty dotyczące usterek, postępów i ryzyka w sposób konstruktywny. Informacje na temat usterek w oprogramowaniu lub dokumencie mogą pomóc ich autorom w podnoszeniu kwalifikacji. Usterki znalezione i naprawione podczas testowania oszczędzają czas i pieniądze w przyszłości, a także ograniczają ryzyko.

Problemy z komunikacją mogą wystąpić jeżeli testerzy są postrzegani jedynie jako posłańcy przynoszący niechciane informacje o usterkach. Istnieje kilka sposobów na poprawienie komunikacji i relacji pomiędzy testerami i resztą zespołu:

• zacznij od współpracy, a nie od wojny – przypomnij wszystkim, że celem jest wyprodukowanie systemów o lepszej jakości
• komunikuj informacje na temat produktu w sposób neutralny, skoncentrowany na faktach bez krytykowania autora produktu, na przykład pisz obiektywne i konkretne raporty incydentów oraz uwagi z przeglądów
• spróbuj zrozumieć, co druga osoba czuje i dlaczego reaguje tak jak reaguje
• upewnij się, że druga strona zrozumiała, co powiedziałeś i upewnij się, że rozumiesz uwagi drugiej strony