Testy systemowe

Ten rodzaj testów zalecany jest zaraz po stworzeniu programu, przed jego wdrożeniem w środowisko zintegrowane. Zasadniczym celem jest sprawdzenie, czy w kodzie nie wystąpiły błędy mające wpływ na stabilność produktu. Po wykryciu błędów, możliwe jest ich w miarę szybkie usunięcie, przez bezpośrednią korektę kodu.

Podstawą wykonania planu przypadków testowych pojedynczego programu jest stworzona dokumentacja, najczęściej dokumenty typu „High Level Definition”, w skrócie HLD. Zawierają one opis wszystkich funkcjonalności modułu/programu, z punktu widzenia użytkownika końcowego. W przeciwieństwie do LLD (Low Level Definition) nie zagłębiają się w szczegóły architektury kodu. Uwzględnione w HLD przypadki użycie (z reguły UC od angielskiego „use case”), powinny znaleźć swoje odzwierciedlenie w skonstruowanych przypadkach testowych.

Dobrą praktyką jest tworzenie całościowego planu przypadków testowych, poukładanych tak w nazewnictwie, jak i w kolejności, zgodnie z dokumentacją projektu. Utrzymanie porządku w ułatwi późniejszą korektę przypadków, a także pozwoli na szybkie reagowanie na zmiany niezbędne do wprowadzenia w dokumentacji.

W przypadku testów dużego oprogramowania, posiadającego wiele różnorodnych funkcji, testowanie gruntowne często nie jest możliwe. Każdy element oprogramowania może mieć wpływ na inne, nawet pozornie niezwiązane, moduły. Dlatego też testy absolutne często wiążą się z nieopłacalnymi biznesowo nakładami finansowymi. Tu z pomocą przychodzi zasada, mówiąca że 20% kodu odpowiada za 80% błędów występujących w oprogramowaniu. Kierując się nią przy przygotowywaniu planu testów należy szczególnie uwzględnić elementy najbardziej narażone na niestabilność, o mocno rozbudowanym kodzie, używające wielu zależności. Te same elementy trzeba szczególnie uwzględniać w testach regresji, o których będzie mowa dalej.

Powrót do Etapów testowania

Jeżeli jesteście Państwo zainteresowani naszą ofertą prosimy o kontakt: e-biznes@itbcg.pl