W pierwszym artykule mówiliśmy o pierwszej i drugiej zasadzie testowania oprogramowania - Testowanie ujawnia obecność defektów i Testowanie gruntowne nie jest możliwe. Tym razem porozmawiamy o trzeciej i czwartej zasadzie.

Zasada 3. Wczesne testowanie

Aktywności testowe powinny rozpocząć się jak najwcześniej w cyklu życia wytwarzania oprogramowania albo systemu i powinny skupić się na sprecyzowanych celach.
Dana zasada jest związana z pojęciem "cena defektu" (cost of defect). Cena defektu znacznie rośnie w miarę cyklu życiowego. Im wcześniej znajdziemy defekt, tym szybciej, łatwiej i taniej będzie można go usunąć.

Usterka znaleziona w wymaganiach jest najtańsza. Jeżeli defekt wykryto na etapie projektowania, projekt może być w miarę łatwo poprawiony. Jednak jeśli defekt został wprowadzony w specyfikacji wymagań i nie wykryto go aż do testowania systemowego czy akceptacyjnego, będzie znacznie droższy w usunięciu. Dzieje się tak, ponieważ trzeba będzie wprowadzić zmiany w specyfikacji i w projekcie przed dokonaniem zmian w budowie. Poza tym, jeden defekt w wymaganiach może pociągnąć za sobą defekty w kilku miejscach w projekcie i kodzie, a po implementacji wymaganych zmian trzeba będzie ponownie przeprowadzić testy. Często się zdarza, że za późno wykryte usterki w ogóle nie są naprawiane, bo zbyt wiele by to kosztowało.

Zdarza się też, że oprogramownanie jest dostarczone i formalnie odpowiada specyfikacji, ale nie odpowiada zapotrzebowaniom użytkowników. Może to skutkować niezadowoleniem użytkowników z nowego systemu, problemami ze sprzedażą i implementacją systemu itp. Oznacza to, że wymagania były niekompletne, ale ten błąd nie został wykryty.

Dlatego ważne jest, aby testowanie rozpoczęło się jak najwcześniej, za pomocą technik statycznych.



Jeszcze jedną ważną zaletą wczesnego testowania jest to, że oszczędza czas. Aktywności testowe mogą się zacząć, zanim pierwsza linia kodu zostanie napisana. Podczas przygotowania wymagań tester może zacząć opracowanie i przegląd przypadków testowych. I gdy tylko powstanie pierwsza wersja testowa, można zabrać się do wykonania testów.

Zasada 4. Skupienie się defektów

Niewielka liczba modułów zawiera większość defektów, wykrytych w trakcie testowania wytwórczego, albo pokazuje najwięcej awarii produkcyjnych.

Testerzy często obserwują zjawisko "skupienia się" defektów. Może to wynikać z tego, że pewna część kodu jest szczególnie skomplikowana, albo z tego, że wprowadzenie zmian w oprogramowanie i inne produkty często powoduje efekt domina. Testerzy używają tej wiedzy oceniając ryzyko podczas planowania testów i koncentrują się na znanych 'hot-spotach'.

Skupiska defektów można rozpoznać na wczesnych etapach podczas testowania statycznego (np. przeglądu kodu czy analizy kodu za pomocą specjalnych narzędzi). Gdy zabierzemy się za testowanie dynamiczne, można będzie skoncentrować się na obszarach, w których znaleziono więcej defektów za pomocą technik statycznych.

Także przydatne byłoby dokonanie analizy podstawowej przyczyny (root cause analysis) w celu zapobiegania ponownym defektom i awariom oraz rozpoznania przyczyny powstania tych skupisk i ewentualnych przyszłych skupisk.

W następnym artykule poruszymy kwestie pozostałych zasad.

Victoria Slinyavchuk
Consultant on Software Testing