Purpurowy

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 sylabusem (zob. rozdział 1.4 Podstawowy proces testowy), podstawowy proces testowy składa się z następujących czynności (czynności te w praktyce mogą się zazębiać lub występować jednocześnie i zwykle konieczne jest ich dostosowanie do kontekstu systemu oraz projektu):

1. planowanie i kontrola (nadzór) testów,
2. analiza i projektowanie testów,
3. implementacja i wykonanie testów,
4. ocena kryteriów zakończenia i raportowanie,
5. czynności zamykające testy.

Projektowanie środowiska testowego oraz identyfikacja wymaganej infrastruktury i narzędzi to jedno z głównych zadań wykonywanych podczas analizy i projektowania testów.

Etap analizy i projektowania testów, o którym mowa w pytaniu, został opisany w podrozdziale 1.4.2 Analiza i projektowanie testów sylabusa. Podczas tego etapu ogólne cele testowania są przekształcane w konkretne warunki testowe i przypadki testowe.

Głównymi zadaniami analizy i projektowania testów są:

• przeglądanie podstawy testów – podstawą testów mogą być m.in. wymagania, poziom integralności oprogramowania (stopień, w jakim oprogramowanie spełnia lub musi spełniać zbiór określonych przez interesariuszy atrybutów (np. złożoność oprogramowania, poziom bezpieczeństwa, pożądana wydajność, niezawodność lub koszt), raporty analizy ryzyka, architektura, projekt, specyfikacja interfejsów,
• ocenianie testowalności podstawy testów i przedmiotu testów,
• identyfikacja i priorytetyzacja warunków testowych na podstawie analizy elementów testowych, specyfikacji, zachowania i struktury oprogramowania,
• projektowanie i priorytetyzacja przypadków testowych wysokiego poziomu
• identyfikacja danych testowych potrzebnych dla warunków testowych oraz przypadków testowych,
• projektowanie środowiska testowego oraz identyfikacja wymaganej infrastruktury i narzędzi,
• tworzenie dwukierunkowego śledzenia pomiędzy podstawą testów i przypadkami testowymi.

Jednym z głównych zadań wykonywanych podczas implementacji i wykonania testów jest raportowanie rozbieżności jako incydentów oraz ich analizowanie w celu ustalenia ich przyczyny (np. defekt w kodzie, defekt w danych testowych, defekt w dokumencie testowym, pomyłka w sposobie wykonania testu).

Pomiar i analiza wyników testów to zadania wykonywane w ramach etapu planowania i kontroli testów, identyfikowanie warunków testowych – w ramach etapu analizy i projektowania testów, zaś ocena, czy potrzeba więcej testów  – w ramach etapu oceny spełnienia kryteriów zakończenia i raportowania.

Zgodnie z sylabusem (zob. rozdział 1.4 Podstawowy proces testowy), podstawowy proces testowy składa się z następujących czynności (czynności te w praktyce mogą się zazębiać lub występować jednocześnie i zwykle konieczne jest ich dostosowanie do kontekstu systemu oraz projektu):

1. planowanie i kontrola (nadzór) testów,
2. analiza i projektowanie testów,
3. implementacja i wykonanie testów,
4. ocena kryteriów zakończenia i raportowanie,
5. czynności zamykające testy.

Etap implementacji i wykonania testów, o którym mowa w pytaniu, został opisany w sylabusie w podrozdziale 1.4.3 Implementacja i wykonanie testów. Zgodnie z sylabusem, implementacja i wykonanie testów to czynność, podczas której specyfikowane są – m.in. poprzez połączenie przypadków testowych w konkretnej kolejności – procedury testowe (zwane również scenariuszami testowymi lub skryptami testowymi), a także ustawiane jest środowisko testowe oraz uruchamiane są testy.

Głównymi zadaniami implementacji i wykonania testów są:

• dokończanie, implementacja i priorytetyzacja przypadków testowych (włącznie z identyfikacją danych testowych),
• przygotowanie i priorytetyzacja procedur testowych, tworzenie danych testowych oraz (opcjonalnie) przygotowywanie jarzm testowych i pisanie automatycznych skryptów testowych,
• tworzenie zestawów testowych z procedur testowych w celu efektywnego wykonania testów,
• sprawdzanie, czy środowisko testowe zostało poprawnie ustawione,
• sprawdzanie oraz uaktualnianie dwukierunkowego śledzenia pomiędzy podstawą testów i przypadkami testowymi,
• wykonywanieprocedur testowych w zaplanowanej kolejności – ręcznie lub przy pomocy narzędzi do wykonywania testów,
• zapisywanie wyników wykonania testów oraz zapisywanie identyfikatorów i wersji testowanego oprogramowania, narzędzi testowych oraz testaliów,
• porównywaniewyników rzeczywistych z wynikami oczekiwanymi,
• raportowanie rozbieżności jako incydentów oraz ich analizowanie w celu ustalenia ich przyczyny (np. defekt w kodzie, defekt w danych testowych, defekt w dokumencie testowym, pomyłka w sposobie wykonania testu),
• powtarzanie czynności testowych jako rezultat akcji podjętej po stwierdzeniu rozbieżności, na przykład powtórne wykonanie testów poprzednio niezaliczonych, aby potwierdzić naprawę (testowanie potwierdzające), wykonanie poprawionych testów i/lub wykonanie testów w celu sprawdzenia, czy w niezmienianych częściach oprogramowania nie pojawiły się usterki lub czy naprawa usterek nie ujawniła innych usterek (testowanie regresywne).

Cechy dobrego testowania właściwe dla każdego modelu rozwoju oprogramowania zostały opisane w sylabusie w podrozdziale 2.1.3 Testowanie w cyklu życia oprogramowania. Zgodnie z sylabusem, w każdym modelu rozwoju oprogramowania dobre testowanie posiada kilka niezmiennych cech:

• dla każdej czynności związanej z wytwarzaniem oprogramowania istnieją odpowiadające jej czynności związane z testowaniem,
• każdy poziom testów ma zdefiniowane cele testów specyficzne dla tego poziomu,
• analiza i projektowanie testów dla danego poziomu powinny rozpoczynać się już podczas odpowiadającej im fazy wytwarzania,
• testerzy powinni uczestniczyć w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania.

Zgodnie z powyższym poprawne są zdania B, C i D. Pełne pokrycie gałęzi kodu nie jest cechą dobrego testowania, lecz jedną z miar stosowanych przy projektowaniu przypadków testowych.

Charakterystyką jakości oprogramowania według normy ISO 9126 nie jest skalowalność.

Norma ISO 9126 “Software engineering – Product quality” to międzynarodowa norma opisująca model jakości oprogramowania. W marcu 2011 r. norma ISO 9126 została zastąpiona normą ISO 25010 „Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models”. Główne różnice między normami ISO 9126 i ISO 25010 zostały klarownie przedstawione w artykule „Charakterystyki jakości oprogramowania – ISO 25010” (otwórz w nowym oknie) w portalu testerzy.pl.

Warto zauważyć, że sylabus ISTQB CTFL powołuje się wyłącznie na normę ISO 9126 (nie uwzględnia normy ISO 25010).

Norma ISO 9126, do której odwołuje się sylabus, specyfikuje sześć charakterystyk, którym przypisane są podcharakterystyki oraz definiuje przykładowe metryki jakości oprogramowania.

Charakterystyki i podcharakterystyki jakości oprogramowania według normy ISO 9126 to:

Osoba, która w ramach przeglądu formalnego prowadzi przegląd dokumentu, planuje przegląd, przewodniczy spotkaniu przeglądowemu i sprawdza wykonanie ustaleń to moderator.

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

W oparciu o treść pytania można wydzielić następujące klasy równoważności: { x < 1 }, { 1 ≤ x ≤ 99 } oraz { x > 99 }. Pełne pokrycie wartości brzegowych zapewniają wartości 0, 1, 99, 100.

Podział na klasy równoważności oraz analiza wartości brzegowych to czarnoskrzynkowe techniki projektowania przypadków testowych (zob. w sylabusie podrozdziały 4.3.1 Podział na klasy równoważności oraz 4.3.2 Analiza wartości brzegowych).

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.

W analizie wartości brzegowych zakłada się, że istnieje większe prawdopodobieństwo, że oprogramowania będzie się błędnie zachowywać dla wartości na krawędziach klas równoważności niż w ich środku, więc testowanie tych obszarów najprawdopodobniej wykryje błędy. Wartość brzegowa poprawnego przedziału jest nazywana poprawną wartością brzegową, a wartość brzegowa niepoprawnego przedziału – niepoprawną wartością brzegową. Testy można zaprojektować tak, żeby pokrywały zarówno poprawne, jak i niepoprawne wartości brzegowe.

Podczas projektowania testów tworzy się przypadek testowy dla każdej wartości brzegowej. Technika analizy wartości brzegowych jest często uważana za rozwinięcie techniki podziału na klasy równoważności lub innych technik czarnoskrzynkowych.

Obie techniki (podział na klasy równoważności, analiza wartości brzegowych) można zastosować na każdym poziomie testowania.