,

Psychologia w testowaniu oprogramowania komputerowego

W poniższym wpisie postaram się Wam przybliżyć:

  • Czym różni się sposób myślenia programisty od sposobu myślenia testera w kontekście oprogramowania nad którym pracują.
  • Co kryje się pod pojęciem poziomu niezależności testowania
  • Czym należy się kierować, żeby współpraca na linii programista-twórca i tester-krytyk odbywała się bez konfliktów.

Różne role, różne podejścia…

Testowanie i sprawdzanie oprogramowania jest czymś zupełnie innym niż jego tworzenie. Mam tutaj na myśli podejście i nastawienie programistów rozwijających aplikację w porównaniu do podejścia tych szukających „dziury w całym” – testerów. Podejście tych pierwszych jest z reguły pozytywne. Wszak tworzą oni niczym artyści coś z niczego. Rozwiązują problem klienta, bazując przy tym na określonych wymaganiach które system ma spełniać. Podejście drugiej ze wspomnianych grup jest diametralnie inne. Testerzy patrzą na to co stworzyli programiści w krytyczny sposób. Testerzy szukają błędów, usterek, niedoróbek – można rzec, że z reguły nie zachwycają się „dziełem” stworzonym przez programistów. Intuicyjnie można zatem wyczuć, że chcąc tworzyć oprogramowanie, potrzebne są różne zespoły ludzi. Składające się z osób o różnym sposobie myślenia, w zależności od zespołu do którego danych człowiek ma należeć.

Programista jest testerem…

Z powyższego akapitu nie wynika i nie jest to moim celem, żeby stwierdzić, że programista nie może być testerem, a tester programistą – pomimo, że te role zazwyczaj są przydzielone różnym osobom. Co może nie być wprost widoczne, a jednak jest spotykane, a w zasadzie jest regułą programiści czy tego chcą czy nie – są testerami. Testują komponenty aplikacji które piszą. W całej swojej dotychczasowej karierze nie spotkałem programisty, który pisałby kod niczym na kartce i przekazywał go dalej bez chociaż wstępnej weryfikacji i sprawdzenia czy dany fragment kodu robi to co ma robić – chociaż z grubsza. Podczas takiej weryfikacji programiści znajdują wiele błędów. Poprawiają je jeszcze przed przekazaniem przygotowanego kawałka aplikacji do sprawdzenia przez inną osobę. Każdy (albo prawie każdy) zdaje sobie jednak sprawę z tego, że nie jest łatwo znaleźć swoje własne błędy. Nie jest więc niczym zaskakującym, że programiści (ale nie tylko, bo również architekci, analitycy biznesowi, także testerzy) proszą o pomoc w sprawdzeniu ich produktu przez innych np. kolegów z tego samego zespołu (peer-review) lub kolegów z innych zespołów np. zespołu testerów.

Poziomy niezależności testów…

W zależności od tego kto zostaje zaangażowany do sprawdzenia wytworzonego przez programistę fragmentu aplikacji możemy mówić o różnych poziomach niezależności testów.

W praktyce idąc od najniższego poziomu niezależności do najwyższego poziomu niezależności możemy rozróżnić kilka poziomów niezależności prowadzenia testów:

  1. Prowadzenie testów przez osobę która tworzyła fragment aplikacji podlegający testowaniu (programista sam testuje swój produkt)
  2. Prowadzenie testów przez osobę z tego samego zespołu (inny programista sprawdza produkt wytworzony przez swojego kolegę programistę)
  3. Prowadzenie testów przez osobę z innego zespołu w ramach tej samej organizacji (np. tester z zespołu testowego)
  4. Prowadzenie testów przez osobę z innej organizacji niż programista dostarczający produkt do testów (np. tester z zewnętrznego w stosunku do organizacji programisty, zespołu testowego)

Jak nie wykopać topora wojennego…

Wiemy już, że nastawienie programisty w stosunku do aplikacji przy której pracuje, jest inne niż nastawienie testera do tego samego oprogramowania. Dodatkowo wiemy, że testy mogą się odbywać na różnych poziomach niezależności. Czas na to, żeby przyjrzeć się temu w jaki sposób raportować defekty bez narażania się na pogorszenie stosunków międzyludzkich pomiędzy twórcami i krytykami.

Każdy z nas popełnia błędy i prawie nikt z nas nie lubi jak mu się je wytyka. Należy o tym pamiętać wcielając się w rolę testera!

Podczas wykonywania sprawdzenia oprogramowania, testerzy często mają bezpośredni kontakt z programistami, którzy przygotowywali fragment aplikacji poddawanej sprawdzeniu. Warto pamiętać, że w tym przypadku to co jest sukcesem testera tj. znalezienie defektów w oprogramowaniu, nie koniecznie, a raczej wcale nie jest w ten sam sposób odbierane przez twórcę kodu (programistę), analityka (przygotowującego wymagania) czy architekta rozwiązania któremu ten błąd zdarzyło się (nieumyślnie) popełnić.

W związku z powyższym należy przestrzegać kilku reguł podczas komunikowania błędów odkrytych podczas testów:

  1. raportować błędy w sposób obiektywny, bez wskazywania winnego/winnej zaistniałego problemu,
  2. nie traktować raportu o defekcie jako sposobu odgryzania się za jakieś dotychczasowe sytuacje konfliktowe wynikłe na linii programista-tester, analityk-tester,  itd.
  3. starać się dokumentować je w taki sposób, żeby nie powstawała wątpliwość o co w zasadzie chodzi w zgłoszeniu, co będzie wymagało dodatkowego nakładu pracy w celu uszczegółowienia co w systemie jest nie tak jak trzeba.

Podsumowując, defekty powinno zgłaszać się w ten sposób, żeby osoba do której ten defekt trafi do naprawy nie odbierała go jako osobistej krytyki.

Z mojego punktu widzenia, do tego wszystkiego o czym napisałem powyżej warto dodać to czego nie zapewni w projekcie, żadna metodyka i dobre praktyki. Należy po prostu żyć dobrze z ludźmi z którymi się pracuje. Z doświadczenia wiem, że będąc osobą kontaktową, skorą do pomocy i dzielącą się wiedzą można zdziałać cuda jeżeli chodzi o rozwiązywania spraw kryzysowych. Natomiast walka „na noże” nigdy nie przynosi dobrego rezultatu.

 


Źródło:
http://sjsi.org/wp-content/uploads/2014/10/slownik-termin%C3%B3w-testowych-ver-2.3-PL.pdf
http://www.testerzy.pl/materialy/index.php?file=AKTUALNY_sylabus_ISTQB_poziomu_podstawowego_wersja_2011.pdf

Doświadczenie własne

Dodaj komentarz