Testowanie jest nieskończone. Cz. 4 powstającej książki "Zapewnienie jakości w procesie wytwarzania oprogramowania".

Brak zdefiniowanego kryterium zakończenia testowania pozwala nam powiedzieć, że testowanie się nie kończy, więc i koszt jest nieskończony. Kontynuując ten tok myślenia dochodzimy do stwierdzenia, że cena testów jest tak wysoka, tak niewyobrażalna, że testowanie staje się bezcenne. Jak „Mona Lisa”. Nie da się ukryć, że sytuacja, w której jesteśmy w stanie skonsumować każdy przekazany nam budżet i jednocześnie nie dawać żadnych gwarancji byłaby kusząca. Niestety musimy zmierzyć się z faktem, że w prawdziwym świecie budżet nigdy nie jest nieskończony. Co więcej, w praktyce jest on zazwyczaj niesatysfakcjonujący.

Poniższa publikacja jest częścią powstającej właśnie, nowej książki Radosława Smilgin o roboczej nazwie "Zapewnienie jakości w procesie wytwarzania oprogramowania. Proces testowy."

Moment zakończenia testów będzie wynikał z końca budżetu przeznaczonego na testy (lub projekt), z końca czasu przeznaczonego na testowanie, z ryzyka pojawienia się zawodnego oprogramowania na rynku. Dwa pierwsze elementy są najbardziej oczywiste i najmniej pożądane z punktu widzenia testerów. Ostatni będzie wynikał z naszych testerskich estymat jakości oprogramowania.

Zakładamy, po raz kolejny, że działania (testowe) mogą zminimalizować ryzyko w najbardziej krytycznych obszarach i że nasza aplikacja osiąga poziom jakości wystarczający do publicznej prezentacji. Oczywiście musimy podkreślić, że jest to jedynie założenie. Brak otwartych błędów krytycznych w aplikacji nie oznacza, że ich tam nie ma. Testowanie po raz kolejny pokazuje nam, że poziom niepewności może być mniejszy, ale nigdy nie sięgnie zera. W całym procesie zarządzania ryzykiem wystarczy, że nasze testy pokryją ryzyka powiązane z celem aplikacji, pod warunkiem, że wszystkie kluczowe ryzyka zostaną zidentyfikowane. Chcemy, aby aplikacja krytyczna, jeśli chodzi o bezpieczeństwo, nie przyczyniła się do niczyjej śmierci. Chcemy, aby aplikacja internetowa była w stanie świadczyć (w założonych) warunkach swoje funkcje. Czy chcemy za dużo? Oczywiście. Te proste zdania przekładają się na olbrzymią ilość ryzyk i nieskończoną ilość przypadków testowych do uruchomienia.

Możemy pocieszać się jedynie tym, że nikt przed nami i nikt na długo po nas nie stworzy aplikacji idealnej i bezawaryjnej.

Testowanie jest potrzebne. Część 3 >>