Testowanie oprogramowania to proces teoretycznie nieskończony. Zawsze można znaleźć warunki lub ścieżki, które nie zostały jeszcze sprawdzone.

Kowal bezskrzydły. Foto: moje, 2016

W warunkach biznesowych proces testowania jest jednak ograniczony (czasem, budżetem, możliwościami). Często pojawia się pytanie: kiedy można zakończyć testowanie, uznając że produkt jest dostatecznie dobrze sprawdzony?

Odpowiedź nie jest jednoznaczna – zakończenie testów jest umowne i zależy od spełnienia jakiegoś warunku:

• Budżet – kwestia dość prosta.
• Czas – może produkt „pudełkowy” ze sztywną datą wydania, może wytwarzany w modelu kaskadowym (a może w Scrumie), może trzeba gonić konkurencję, a może po prostu osoba decyzyjna stwierdza, że czas na testy ubiegł – kończymy.
• Metryki. Tu zaczyna się robić ciekawie, o czym w dalszej części wpisu.

Ciekawy materiał na ten temat od IBM:
[ftp://public.dhe.ibm.com] – kopia [IBM_Kiedy_mozna_zakonczyc_testowanie].

Metryki

Metryki są pewnym założeniem i są to wartości dość względne. Mogą zostać ustalone na początku testowania. Niektóre z nich to np.:

• Wykonanie założonego procentu przypadków testowych zakończyło się sukcesem (nie zostały wykryte błędy).
• Ilość wykrytych błędów (lub krzywa wykrywanych błędów) spadła poniżej założonego progu.
• Pokrycie funkcjonalności testami (manualnymi, automatycznymi) osiągnęło założony zakres, np.:
  • przetestowano ręcznie najważniejszą ścieżkę,
  • pokrycie testami jednostkowymi na poziomie 90%.