Redakcja
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 >>
