Redakcja
Iain McCowatt na swoim [nieistniejącym już] blogu "Exploring Uncertainty" celnie punktował, że pokrycie testów jest mało ważnym celem testowania oprogramowania.
W prawdziwym życiu pokrycie testowe to:
- uzyskanie odpowiedzi o procentowy lub czasowy zakres przeprowadzenia testów pewnych obszarów aplikacji,
- uzyskanie odpowiedzi o procent wykonania pewnych działań, jak np. uruchomienie przypadków testowych.
Pokrycie testowe w wielu organizacjach staje się celem nadrzędnym w stosunku do kontroli i próby zapewnienia jakości testowanego produktu. "Uzyskajmy 100% pokrycia!" nie może być celem sesji testowej z kilku podstawowych powodów.
- Za każdym pokryciem kryje się jakaś technika. Każda technika ma swoje ograniczenia i obszary, których nie jest w stanie zweryfikować.
- Każde pokrycie koncertuje się na pojedynczym aspekcie działania oprogramowania i pomija inne. Przez definiowanie 200% kompletności testowania odbiera nam się szansę na rozszerzenie eksploracji.
- Pokrycie jest zazwyczaj ściśle powiązane z harmonogramem i jego ślepe realizowanie może odsuwać nas od ważniejszych celów.
Według Iaina pokrycie nie powinno być naszym celem w testowaniu, powinno być po prostu środkiem określającym to, co pozostaje do zrobienia.
Które ze stwierdzeń jest dla nas ważniejsze - "Pokryliśmy wymagania" czy "Istnieją pewne ryzyka, których jeszcze nie pokryliśmy"? Pierwsze nie mówi zasadniczo nic o jakości oprogramowania lub skuteczności naszych testów, podczas gdy drugie daje nam konkretny cel do zrealizowania.
Pomyśl dwa razy zanim swój cel zdefiniujesz w odniesieniu do pokrycia.
Cały artykuł znajdował się na stronie http://exploringuncertainty.com/blog/archives/754
