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.