Zobaczmy dlaczego właściwie testuje się oprogramowanie – bo odpowiedź nie jest tylko prostym „żeby kod działał jak oczekujemy”.

”Co może pójść nie tak?” - odpowiedź na to pytanie to podstawowy cel testów

Dlaczego po prostu nie zautomatyzujemy wszystkich testów? Czy pokrycie testami jest użytecznym miernikiem jakości kodu? Kiedy i gdzie powinniśmy testować? Wiele zamieszania i niezrozumienia między programistami i testerami wynika z braku zrozumienia celu testowania.

Za każdym razem, gdy zmieniamy oprogramowanie — dodając nową funkcję albo zmieniając lub zastępując funkcję już istniejącą czy też po prostu wprowadzając „pod maską” zmiany w celu ulepszenia kodu — ponosimy ogromne ryzyko. W przypadku każdej zmiany istnieje niezerowe prawdopodobieństwo, że spowodujemy przy okazji coś złego. Dotyczy to nie tylko samego kodu, ale także jego systemu budowania, ścieżek wdrożeniowych, środowiska operacyjnego, punktów integracji i wszelkich innych bezpośrednich lub pośrednich zależności z kodem.

A co się może takiego złego wydarzyć?

A proszę, przykładowo możemy mieć do czynienia z takimi oto Złymi Rzeczami:

• Poprawność funkcjonalna nie daje oczekiwanych rezultatów.
• Wiarygodność leży: kod w większości pokazuje poprawne odpowiedzi, ale czasami nie.
• Użyteczność: program działa ale jest niespójny i frustrujący w użyciu.
• Przewidywalność: aplikacja ma losowe skoki zasobów, takich jak pamięć, operacje wejścia/wyjścia lub użycie procesora albo czasami zawiesza się na zauważalny czas.
• Bezpieczeństwo: kod działa wprawdzie zgodnie z założeniami, ale są luki w zabezpieczeniach.
• Zgodność: program zasadniczo działa, ale nie obsługuje poprawnie konkretnych ciągów danych (np. ze względu na niestandardowe kodowanie).
• Obserwowalność: na ogół działa ale kiedy nie to trudno jest określić dlaczego tak się dzieje.

Dla każdego rodzaju Złej Rzeczy istnieje osoba lub rola, której szczególnie zależy aby tej Złej Rzeczy nie było w programie - nazywamy ją interesariuszem. Ci ludzie reprezentują różne wymiary ryzyka lub wymiary jakości w naszych przedsięwzięciach programistycznych.

Testy to dowody

Mając to na uwadze, możemy śmiało stwierdzić, że celem testowania jest zwiększenie zaufania interesariuszy poprzez przedstawienie im dowodów.

Interesariusze to wszyscy, których bezpośrednio lub pośrednio dotyczy nasza praca, jak to ujmuje specjalista UX Marc McNeill, [cite]ludzie, których życia dotykamy[/quote]. Jest to pojęcie szersze niż klienci czy użytkownicy końcowi produktu lub usługi. To współpracownicy, którzy wnoszą wkład z różnych perspektyw. A dowody to niepodważalne informacje lub dane. Interesariusze nie powinni polegać na naszym zapewnieniu lub gwarancji albo reputacji. Zasługują na zimne, twarde dowody i coraz częściej ich po prostu wymagają.

Trzy cechy ważne przy testowaniu

Możemy opisać proces zmniejszania tej niepewności jako zapewnienie interesariusza o tym, że rzeczy o które zabiega są w porządku. Mówimy więc o zapewnianiu jakości (quality assurance, QA). A QA czy to w laboratorium mleczarni czy to w pokoju deva musi być oparte zapewnione dowodami, a nie opierać się na ślepej wierze czy stwierdzeniu „tak to zawsze działało”.

W związku z tym można wskazać na trzy „supermoce”, przydatne każdemu testerowi:

• Empatia: umiejętność wejścia do głowy interesariuszy, zobaczenia świata z ich perspektywy, zrozumienia przyczyn ich, mhm, niepokoju.
• Sceptycyzm: umiejętność wątpienia w pracę, którą wykonujesz, nawet gdy ją wykonujesz dobrze. Jest to szczególnie trudne dla programisty: nasze ego jest zawsze obecne w czasie pracy. Ten sceptycyzm wpisuje się w metodę naukową, którą warto stosować – chodzi o to aby starać się sfalsyfikować hipotezę, a nie ją „udowodnić”.
• Pomysłowość: zdolność i determinacja, aby zrobić wszystko byle tylko zapewnić spokój swoim interesariuszom — lub odkryć, że mieli rację, gdy byli sceptyczni wobec naszej pracy! Testowanie jest nieliniowe i nieoczywiste: to szperanie w bazie danych, węszenie pakietów w sieci, wstrzykiwanie serwera proxy usługi w celu rejestrowania interakcji; śledzenie ruchów oczu; zmiana wpisów DNS - nic nie jest niedostępne w pracy IT dla dobrego testera, którego powinna cechować multidyscyplinarność.