W niniejszym artykule zajmiemy się pozostałymi trzema zasadami testowania.

Zasada 5. Paradoks pestycydów

Jeżeli te same testy są wielokrotnie powtarzane, to w końcu ten sam zestaw przypadków testowych nie będzie w stanie wynaleźć nowych defektów. Skupiska defektów, o których wspomina czwarta zasada, mają tendencję do przemieszczania się. Dlaczego tak się dzieje?

Taka analogia została zaproponowana przez Borisa Beizera w 1983. Podał wtedy przykład stosowania pestycydów. Pestycyd zabija pluskwy, ale wielokrotne stosowanie tej samej trucizny na tym samym polu spowoduje wzrost odporności u pozostałych pluskiew. Jeżeli nadal stosuje się ten sam pestycyd, w końcu owady rozwijają oporność na niego i pestycyd przestaje działać. Wielokrotne stosowanie tych samych testów i tych samych metodologii w konsekwencji doprowadzi do defektów w oprogramowaniu, których już nie da się znaleźć za pomocą tych testów i tych metodologii.

Aby pokonać ten 'paradoks pestycydów', trzeba poddawać istniejące przypadki testowe regularnej analizie i modyfikacji, a także pisać różne nowe testy, służące do sprawdzenia różnych części systemu. Pomoże to znaleźć więcej defektów.

Zasada 6. Testowanie jest zależne od kontekstu

W różnych kontekstach testowanie jest wykonywane w różny sposób. Na przykład, oprogramowanie krytyczne ze względów bezpieczeństwa powinno być testowane inaczej niż sklep internetowy.

Zasada jest ściśle związana z pojęciem ryzyka. Czym właściwie jest ryzyko? Ryzyko to potencjalny problem. Prawdopodobieństwo (likelyhood) wystąpienia ryzyka w przyszłości wynosi od 0% do 100%; ryzyko także ma wpływ (impact), tj. negatywne konsekwencje których się obawiamy. Analizując ryzyko zawsze rozważamy te dwa aspekty - prawdopodobieństwo i wpływ. Na przykład, przechodząc przez jezdnię zawsze narażamy się na ryzyko że przejedzie nas samochód. Prawdopodobieństwo zależy od takich czynników jak intensywność ruchu drogowego, bezpieczne przejście, od tego jak dobrze widzimy i jak szybko jesteśmy w stanie iść. Wpływ zależy od tego, jak szybko jedzie samochód, czy mamy na sobie odzież ochronną, od naszego wieku, stanu zdrowia itp. W zależności od tych czynników człowiek może wybrać najlepszą dla siebie strategię przechodzenia.



To samo można powiedzieć o oprogramowaniu: różne systemy są połączone z różnymi poziomami ryzyka i wpływ problemów może znacznie się różnić. Niektóre problemy są dość trywialne, jednak inne mogą być kosztowne i szkodliwe - związane ze stratą pieniędzy, czasu czy reputacji biznesowej - a nawet mogą doprowadzić do urazu czy śmierci.

Poziom ryzyka może wpływać na wybór metodologii, technik i typów testów.

Zasada 7. Mylne przekonanie o braku błędów

Znalezienie i usuwanie defektów nie ma sensu, jeżeli zbudowany system jest bezużyteczny i nie spełnia wymagań i oczekiwań użytkowników.

Klienci - ludzie i organizacje, kupujące i używające oprogramowania do swojej codziennej pracy - nie interesują się defektami czy ilością defektów, o ile niestabilność oprogramowania nie wpływa na nich bezpośrednio. Nie ma dla nich znaczenia, na ile oprogramowanie spełnia udokumentowane wymagania formalne. Użytkowników oprogramowania interesuje bardziej, aby pomagało im w wykonaniu zadań w sposób efektywny. Oprogramowanie powinno odpowiadać ich potrzebom i jest oceniane przez nich z tego punktu widzenia.

Nawet jeśli zrobiono wszystkie testy i nie znaleziono żadnych defektów, nie daje to gwarancji, że oprogramowanie będzie spełniało wymogi i oczekiwania użytkowników.

Innymi słowy, weryfikacja i walidacja.

Weryfikacja to egzaminowanie systemu w celu ustalenia, czy spełnia zdefiniowane wymagania. Walidacja to sprawdzenie systemu w celu ustalenia, czy spełnia wymagania i oczekiwania użytkownika i jest dostosowany do jego potrzeb.

Część aktywności testowych powinna się koncentrować na weryfikacji, druga część na walidacji.

Teoretycznie, jeżeli wymagania zostały odpowiednio zebrane i przeanalizowane i nie wystąpiły zniekształcenia na etapie architektury i wytwarzania kodu, nie powinno być żadnych niezgodności. Ale życie, niestety, nie jest idealne.

Victoria Slinyavchuk
Consultant on Software Testing