"Uciekinierzy" w testowaniu

"Uciekinierzy" w testowaniu
Spośród wszystkich błędów oprogramowania to "uciekinierzy" są naszym największym wrogiem i z nimi przede wszystkim walczymy. "Uciekinierzy"? To te błędy, które pomimo pól minowych analizy statycznej, zasieków przypadków testowych i obrony testerskiej przedarły się do użytkownika końcowego.

 

Nie ma dużego znaczenia czy błąd jest krytyczny, ważny czy trywialny tak długo, jak jesteśmy świadomi jego istnienia. Poważne kłopoty pojawiają się jeśli nie wykryjemy go (ich) przed wydaniem oprogramowania klientowi.

"Uciekinier" stanowi zupełnie inną kategorię błędu, uzupełniając jednocześnie wszystkie inne nam znane. Nie pojawi się w raportach z testów, ale pojawi się jako skarga na infolinii, towar zwrócony do sklepu, czy żądanie zapłaty kary umownej. "Uciekinier" ma poważną wagę biznesową. Może powodować utratę dobrego imienia w oczach klienta, lub też stratę przy kolejnym produkcie, który znajdzie mniejszą ilość zrażonych już nabywców.

Nie bez powodu ocenia się zespoły wytwórcze miarą: ilość ("uciekinierów" / ilość wszystkich znalezionych defektów)*100%. I nie bez powodu każdy wytwórca marzy o ilości "uciekinierów" o wartości równej "0".

Jeśli jednak zdarzy nam się sytuacja, w której defekty przedostały się do klienta, musimy zastanowić się nad gęstością oczek w siatce do ich łapania, oraz nad poprawnością procesu ich eliminacji, itp. Czy mogliśmy zrobić coś aby zatrzymać "uciekiniera"? Jaki wysiłek oznacza to dla naszej organizacji i kto będzie odpowiedzialny za to, aby dany błąd nie wyciekł ponownie?

 

Końcowy rezultat to np.:

- przypadek testowy dla tego (lub podobnego) defektu będzie w zestawie regresywnym przed wydaniem wersji

- analiza przyczyny "uciekiniera" i możliwości narzędziowe, procesowe i ludzkie jego powstrzymania.

 

Inspirowane: http://www.testthisblog.com/2012/06/escape-review-meeting-model.html

 

 

 

 

 

 

 

 

To powinno Cię zainteresować