Sztuka testowania

Testowanie oprogramowania to w równej mierze sztuka wymagająca talentu, rzemiosło dla wytrwałych, a także nauka.

Testowanie oprogramowania to w równej mierze sztuka wymagająca talentu, rzemiosło dla wytrwałych, a także nauka.

Dokładne wyniki wyborów można poznać dopiero po zakończeniu głosowania, niemniej zawsze znajdą się chętni do szacowania przyszłego układu sił zanim jeszcze wszystkie karty zostaną rozdane. Różnica między sondażem a wyborami dotyczy przede wszystkim skali, a więc i kosztów, jakie trzeba ponieść, by poznać preferencje wyborców oraz ich skłonność do udziału w wyborach. O ile w wyborach biorą udział miliony, wiarygodne badanie opinii można, dzięki statystyce, przeprowadzić z udziałem zaledwie ok. tysiąca osób. Prawdopodobieństwo przypadkowego trafienia w sondażu na kilkaset osób, których poglądy różnią się znacząco od poglądów kilkudziesięciomilionowego ogółu, jest tak znikome, że w praktyce można je zignorować.

Dla zapewnienia badaniu wysokiej wiarygodności kluczowe znaczenie ma jego przebieg, a zwłaszcza sposób doboru próby. Prawa statystyki działają wtedy, gdy struktura próbki jest reprezentatywna dla społeczeństwa jako całości. Nie będzie więc wiarygodnym badanie, w którym próba będzie dobierana spośród zwolenników jednej tylko opcji politycznej (chyba, że cel badania zawężono właśnie tylko do jej zbadania). Nie będzie także reprezentatywne np. posłużenie się w badaniu medium wykluczającym reprezentatywność, np. Internetem. Wiadomo bowiem że większość polskich wyborców nie ma dostępu do Internetu, a nawet jeżeli ma, nie zawsze potrafi z niego skorzystać. Ponadto są powody, by sądzić, że preferencje polityczne osób posługujących się i nie posługujących Internetem odbiegają od siebie znacząco.

Aby próba była reprezentatywna, osoby, którym postawimy pytanie, trzeba wybrać, jeszcze lepiej wylosować spośród wszystkich, którzy później będą głosować. W przeciwnym razie uzyskamy fałszywe czy przynajmniej bardzo niepewne prognozy.

Sztuka testowania

Testowanie oprogramowania w wielu aspektach przypomina sondaż przedwyborczy. Gdyby wszystko to, co w przyszłości użytkownicy aplikacji z nią uczynią, wykonać zawczasu jako przypadki testowe, mielibyśmy wynik testów absolutnie pewny. Wykonanie pełnego testu, podobnie jak przepytanie wszystkich wyborców, byłoby jednak niezmiernie kosztownym przedsięwzięciem. Wymagałoby bowiem sprawdzenia milionów czynności, które setki czy tysiące użytkowników wykonają przez wiele lat.

Wykonanie "testów doskonałych" nie wydaje się ani realne, ani też sensowne, toteż testowanie polega w praktyce na przeprowadzeniu swego rodzaju badania opinii. Problem sprowadza się zasadniczo do tego, jak przy użyciu ograniczonej grupy pytań - w tym wypadku przypadków testowych - przewidzieć w miarę trafnie jakość programu, którym dużo osób będzie się posługiwać intensywnie przez wiele lat. Umiejętność odpowiedniego formułowania zadań testowych jest sednem tego, co można nazwać sztuką testowania.

Wybór przypadków testowych może przebiegać bardzo różnie. Jedną z technik jest tzw. przeczuwanie błędu (error guessing), polegające na tym, że doświadczony tester, użytkownik czy programista wybiera, co warto przetestować, niejako na wyczucie. Wyczucie to może wynikać np. z doświadczeń nabytych przy produkcji poprzedniej wersji programu. Wiedząc, w jakim obszarze problemy pojawiały się w przeszłości, można domniemywać, że mogą się tam pojawić ponownie. Można też przyjąć założenie odwrotne: wiedząc, które funkcje są nowe czy w największym stopniu zmodyfikowane, koncentrujemy się na poszukiwaniu błędów właśnie w tym obszarze.

Źródłem przeczuć może być też analiza architektury systemu lub kodu źródłowego. Zbyt skomplikowane algorytmy usprawiedliwiają podejrzenie, że te obszary warto poddać wzmożonej inwigilacji. Są ludzie obdarzeni niewytłumaczalną smykałką do znajdowania błędów: talent do wprowadzania takich wartości zmiennych wejścia, które szybko obnażają słabe strony programu. Często zresztą sami nie są w stanie powiedzieć, skąd ta ich intuicja się bierze.

Testowanie jako rzemiosło

Na przestrzeni lat sformułowano sporo opartych na doświadczeniu praktycznych zasad, mogących służyć jako wskazówki, co i w jakim stopniu testować. Oto niektóre z nich:

  • Testowanie powinno opierać się na dobrej, szczegółowej specyfikacji wymagań i pokrywać wszystkie objęte nią obszary funkcjonalne.

  • Przy wyborze przypadków testowych należy brać pod uwagę ryzyko: zarówno prawdopodobieństwo, jak i konsekwencje awarii. Im wyższe ryzyko, tym więcej przypadków testowych należy stworzyć.

  • Efektywną metodą na to, by osiągnąć dobre rozłożenie przypadków testowych i np. uniknąć pominięcia jakiegoś istotnego obszaru, jest zwykle wykonanie modelu działania systemu i formułowanie przypadków testowych dopiero na tej podstawie. Niektóre takie modele opisano dalej.

  • Dla jakości testów korzystne jest łączenie przypadków testowych opartych na technikach formalnych, np. na wspomnianych modelach, z przypadkami testowymi opartymi na przeczuwaniu błędów.

  • Korzystną i w sumie niezbyt kosztowną metodą testowania jest kontrola tzw. pokrycia strukturalnego (structural coverage), czyli np. jaki jest udział instrukcji choć raz przetestowanych w trakcie wykonywania wszystkich przypadków testowych w stosunku do łącznej jej liczby. Ta relatywnie prosta technika umożliwia wykrycie przeoczonych fragmentów kodu, które nie zostały dotychczas w ogóle przetestowane.


  • TOP 200