7 podstawowych zasad testowania

W tym artykule chciałem przedstawić 7 podstawowych zasad testowania głoszonych
przez ISTQB. Czy są to faktycznie najważniejsze zasady pozostaje kwestią dyskusyjną
natomiast na pewno warto je znać i pamiętać o nich przy każdym procesie testowania w

jakim bierzemy udział.

I Testowanie ujawnia usterki, a nie ich nieobecność
Testowanie może wykazać, że usterki są obecne, ale nie może udowodnić, że w
oprogramowaniu usterki się nie znajdują. Nawet po dokładnym przetestowaniu nie
możemy stwierdzić, że produkt jest w 100% wolny od usterek. Jedyne co możemy
osiągnąć testując oprogramownie to zmniejszenie prawdopodobieństwa, że pozostały
niezidentyfikowane błędy. Należy też mieć na względzie, że niewykrycie defektów nie jest

dowodem na poprawność testowanego oprogramowania.

II Testowanie gruntowne
Testowanie gruntowne jest praktycznie niemożliwe lub możliwe, ale kompletnie
nieopłacalne.
Jest bardzo mało prawdopodobne, żeby ramy czasowe projektu pozwalały na przebadanie
każdej możliwej kombinacji wejść oraz warunków. Biorąc pod uwagę te czynniki należy

podczas testowania kierować się analizą ryzyka oraz priorytetyzacją.

III Testowanie powinno zacząć się jak najwcześniej
Czynności testowe powinny rozpoczynać się jak najszybciej. Im szybciej wykryjemy błąd
tym mniejszy będzie koszt jego usunięcia.

IV Kumulowanie się defektów blisko siebie
Mała liczba modułów najczęściej zawiera większość defektów znalezionych podczas
testowania. Jeśli w danym module znajdziemy jakiś błąd to powinniśmy skupić większą

uwagę na nim.

V Paradoks pestycydów
Paradoks pestycydów przypomina nam, że jeśli te same rodzaje testów będą wielokrotnie
powtarzane to w końcu ten sam zestaw przypadków testowych nie będzie już w stanie
znaleźć żadnych nowych błędów. W celu uniknięcia wspomnianego paradosku bardzo
ważne jest, aby regularnie dokonywać przeglądu przypadków testowych i odpowiednio je
modyfikować.

VI Testowanie zależne jest od kontekstu
Testowanie zawsze zależne jest od kontekstu czyli powinno być wykonywane w różny
sposób w różnych sytuacjach. Na przykład inaczej będziemy testować systemy krytyczne,
systemy bankowe czy gry komputerowe.

VII Mylne przekonanie o braku błędów
W zasadzie tej chodzi o to, że nawet oprogramowanie teoretycznie nie posiadające
defektów może nie spełniać wymagań użytkownika. Wniosek z tego płynie taki, iż
konieczne jest również testowanie w oparciu o wymagania. Satysfakcja z użytkownia
zależy również od atrybutów niefunkcjonalnych oprogramowania np: wydajności,

niezawodności czy użytecznośc.