Écru

Awarią jest nieprawidłowe zachowanie oprogramowania spowodowane usterką.

Sylabus w podrozdziale 1.1.2 Przyczyny usterek w oprogramowaniu wskazuje następująco:

Człowiek może popełnić błąd (pomyłkę), która powoduje powstanie defektu (usterki, pluskwy) w kodzie programu lub dokumencie. Jeżeli kod zawierający defekt zostaje wykonany, system nie zrobi tego co powinien (lub wykona to czego nie powinien) powodując awarię. Usterki w oprogramowaniu, systemach lub dokumentach mogą prowadzić do wystąpienia awarii, ale nie wszystkie usterki powodują awarie.

Defekty istnieją, ponieważ ludzie są omylni, działają pod presją, pracują ze złożonym kodem, w skomplikowanej infrastrukturze, ze zmieniającymi się technologiami oraz z dużą ilością interakcji pomiędzy systemami.

Awarie mogą zostać spowodowane też przez warunki środowiskowe. Na przykład promieniowanie, pole magnetyczne i elektryczne oraz zanieczyszczenia mogą spowodować awarie oprogramowania wbudowanego lub wpływać na oprogramowanie przez zmianę warunków działania sprzętu.

Celem testowania jest m.in. wykrywanie defektów oprogramowania.

Zgodnie z sylabusem testowanie może mieć następujące cele:

• znajdowanie defektów,
• nabieranie zaufania do poziomu jakości,
• dostarczanie informacji potrzebnych do podejmowania decyzji,
• zapobieganie defektom.

Zgodnie z podrozdziałem 2.3.4 Testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne sylabusa:

Testowanie regresywne, to powtórzenie testów na już przetestowanym programie wykonywane po modyfikacjach żeby wykryć nowe usterki lub usterki odsłonięte na skutek wykonanych zmian. Usterki te mogą występować w testowanym oprogramowaniu, jak również w innych powiązanych lub niepowiązanych modułach. Testy regresywne wykonuje się po zmianach w oprogramowaniu, a także po zmianach w jego środowisku. Zakres testów regresywnych wynika z ryzyka nieznalezienia usterek w oprogramowaniu, które poprzednio działało poprawnie.

Testy, które mają być stosowane w testowaniu potwierdzającym i regresywnym muszą być powtarzalne.

Testy regresywne można wykonywać na wszystkich poziomach testów i dla wszystkich typów testów: funkcjonalnych, niefunkcjonalnych i strukturalnych. Zestawy testów regresywnych są wykonywane wiele razy i są stosunkowo niezmienne, wobec czego są dobrymi kandydatami do automatyzacji.

Zgodnie z podrozdziałem 2.2.4 Testy akceptacyjne  sylabusa:

Celem testów akceptacyjnych jest nabranie zaufania do systemu, jego części lub pewnych atrybutów niefunkcjonalnych. Wyszukiwanie usterek nie jest tym, na czym skupiają się testy systemowe. Mogą one oceniać gotowość systemu do wdrożenia i użycia, chociaż nie muszą być ostatnim poziomem testowania. Na przykład może po nich następować testowanie integracji systemów w większej skali.

Zobacz więcej w podrozdziale 2.2.4 Testy akceptacyjne  sylabusa.

Najmniej zasadne wydaje się zaangażowanie w przegląd formalny asystenta kierownika.

Zobacz więcej w podrozdziale 3.2.2 Role i odpowiedzialność sylabusa.

Zgodnie z podrozdzialem 3.3 Analiza statyczna przy pomocy narzędzi sylabusa, analiza statyczna zwykle wykrywa następujące typy usterek:

• odwołanie do niezainicjalizowanej zmiennej
• niespójne interfejsy pomiędzy modułami
• niewykorzystywane lub niepoprawnie zadeklarowane zmienne
• martwy kod
• brakująca albo błędna logika (pętle potencjalnie nieskończone)
• zbyt skomplikowane konstrukcje
• naruszenie standardów kodowania
• słabe punkty zabezpieczeń
• naruszenie reguł składni kodu i modeli oprogramowania

Zgodnie z rozdziałem 4.2 Kategorie technik projektowania testów sylabusa, cechą czarnoskrzynkowych technik projektowania przypadków testowych (zwanych także m.in. technikami projektowania testów opartymi na specyfikacji) jest m.in. używanie modelów, z których można, w sposób usystematyzowany, wywodzić przypadki testowe.

Zgodnie z podrozdziałem 4.3.5 Testowanie w oparciu o przypadki użycia sylabusa:

Testy można projektować na podstawie przypadków użycia. Przypadek użycia opisuje interakcje pomiędzy aktorami (użytkownikami lub systemami), które powodują powstanie wyniku wartościowego z punktu widzenia użytkownika lub klienta. Przypadek użycia może być opisany na wysokim poziomie abstrakcji (biznesowy przypadek użycia, poziom procesów biznesowych, niezawierający informacji o technologii) lub na poziomie systemowym (systemowy przypadek użycia na poziomie funkcjonalności systemu). Każdy przypadek użycia posiada warunki wstępne, które muszą zostać spełnione, żeby przypadek użycia został wykonany. Każdy przypadek użycia kończy się warunkami końcowymi. Są nimi widoczne rezultaty jego wykonania oraz stan systemu po zakończeniu przypadku użycia. Przypadki użycia zwykle posiadają scenariusz główny (tj. najbardziej prawdopodobny) oraz czasami scenariusze poboczne.

Przypadki użycia opisują „przepływy” procesu przez system bazując na najbardziej prawdopodobnym rzeczywistym jego użyciu, co sprawia że przypadki testowe wywiedzione z przypadków użycia najbardziej przydają się wykrywaniu usterek w przepływach procesów z rzeczywistego użytkowania systemu. Przypadki użycia bardzo przydają się w projektowaniu testów akceptacyjnych, w których ma brać udział klient/użytkownik. Pomagają również wykrywać defekty integracji spowodowane interakcją i interfejsami różnych modułów, co nie byłoby widoczne w testach modułowych. Projektowanie przypadków testowych z przypadków użycia może zostać połączone z innymi technikami projektowania testów opartymi na specyfikacji (czarnoskrzynkowymi).

Podział na klasy równoważności to czarnoskrzynkowa techniki projektowania przypadków testowych (zob. w sylabusie podrozdział 4.3.1 Podział na klasy równoważności).

W technice podziału na klasy równoważności wejścia programu lub systemu są dzielone na grupy, które powodują podobne zachowanie oprogramowania, więc jest bardzo prawdopodobne, że będą przetwarzane w ten sam sposób. Dzięki temu nie musimy testować wszystkich elementów w zbiorze (powinno wystarczyć sprawdzenie wartości dla jednego elementu z klasy równoważności).

Klasy równoważności można znaleźć zarówno dla danych poprawnych, jak i danych niepoprawnych:

• klasy poprawności – zbiory wartości, dla których przewidujemy poprawne działanie programu;
• klasy niepoprawności – zbiory wartości, dla których przewidujemy błędne działanie programu.

Technikę podziału na klasy równoważności można zastosować na każdym poziomie testowania.

Zgodnie z rozdziałem 5.5 Ryzyko a testowanie sylabusa:

Ryzyko może zostać zdefiniowane, jako możliwość wystąpienia zdarzenia, niebezpieczeństwa, zagrożenia lub jakiejś sytuacji powodującej niepożądane konsekwencje lub potencjalny problem. Poziom ryzyka jest określony przez prawdopodobieństwo wystąpienia niekorzystnego zdarzenia oraz jego wpływ (szkoda, jaką może wyrządzić to zdarzenie).

Sylabus wymienia dwa rodzaje ryzyk:

• ryzyko projektowe – dotyczy zdolności projektu do osiągnięcia postawionych przed nim celów (zob. więcej w podrozdziale 5.5.1 Obszary ryzyka projektowego),
• ryzyko produktowe – dotyczy jakości produktu, czyli oprogramowania lub systemu (zob. więcej w podrozdziale 5.5.2 Obszary ryzyka produktowego).

Według sylabusa:

Ryzyka używa się do określenia, kiedy rozpocząć testowanie oraz co powinno zostać dokładniej przetestowane. Testowanie jest wykorzystywane do zredukowania ryzyka wystąpienia niekorzystnych zdarzeń lub do zredukowania ich wpływu.

Zgodnie z sylabusem (zob. podrozdział 5.2.4 Kryteria zakończenia), celem kryteriów zakończenia, zwanych także kryteriami wyjścia, jest zdefiniowanie momentu zakończenia testów na danym poziomie testów lub gdy zbiór testów osiągnął określony cel.

Typowo kryteria zakończenia mogą składać się z:

• miar staranności, takich jak pokrycie kodu, funkcjonalności lub ryzyka
• estymat gęstości błędów lub miar niezawodności
• kosztu
• istniejącego ryzyka, takiego jak niepoprawione usterki lub brak pokrycia pewnych obszarów
• harmonogramów np. zdefiniowanych na podstawie czasu do wypuszczenia produktu na rynek

Zgodnie z treścią podrozdziału 6.2.1 Potencjalne korzyści i ryzyko wsparcia narzędziowego dla testów (dla wszystkich narzędzi sylabusa, potencjalne korzyści wynikające z użycia narzędzi wspierających testy to:

• zredukowana zostaje powtarzająca się praca (np. uruchamianie testów regresywnych, powtórne wprowadzanie tych samych danych testowych oraz sprawdzanie zgodności ze standardami kodowania),
• zwiększa się spójność i powtarzalność (np. testy wykonywane przez narzędzie w tej samej kolejności i z tą samą częstością oraz testy wywiedzione z wymagań),
• ocena jest obiektywna (np. miary statyczne, pokrycie),
• łatwiejszy jest dostęp do informacji o testach i testowaniu (np. statystyki i wykresy obrazujące postęp testów, współczynniki występowania incydentów oraz wydajność).

Zgodnie z sylabusem, ryzyka związane z użyciem narzędzi do testowania to:

• nierealistyczne oczekiwania względem narzędzia (co do funkcjonalności lub łatwości użycia),
• niedoszacowanieczasu, kosztów oraz pracochłonności wstępnego wdrożenia narzędzia (włączając w to szkolenia oraz zewnętrzne ekspertyzy),
• niedoszacowanie czasu i pracochłonności potrzebnych do osiągnięcia znaczących i trwałych korzyści z narzędzia (włączając w to potrzebę dokonania zmian w procesie testowym oraz ciągłe doskonalenie sposobu wykorzystania narzędzia),
• niedoszacowanie pracochłonności wymaganych do utrzymania artefaktów testowych wygenerowanych przez narzędzie,
• zbytnie poleganie na narzędziu (zastąpienie narzędziem projektowania testów lub wykorzystywanie zautomatyzowanych testów w sytuacji, gdy testowanie manualne byłoby lepsze),
• zaniedbywanie kontroli wersji artefaktów testowych w narzędziu,
• zaniedbywanie kwestii zależności i współpracy (interoperacyjności) między krytycznymi narzędziami, takimi jak narzędzia do zarządzania wymaganiami, narzędzia do kontroli wersji, narzędzia do zarządzania incydentami, narzędzia do śledzenia defektów oraz narzędzia od różnych dostawców,
• słaba reakcja dostawcy w ramach wsparcia, nowych wersji oraz poprawiania usterek,
• ryzyko wstrzymania projektu dla narzędzia darmowego / open-source,
• ryzyka nieprzewidziane, takie jak niezdolność do wspierania nowej platformy.