Rubinowy

Spośród wymienionych opcji najlepsza definicja testowania gruntownego związana jest ze znalezieniem w programie wszystkich usterek.

Pamiętaj, że zgodnie z jedną z siedmiu podstawowych zasad testowania (zob. w sylabusie rozdział 1.3 Ogólne zasady testowania), testowanie gruntowne jest niewykonalne:

Przetestowanie wszystkiego (wszystkich kombinacji wejść i warunków początkowych) jest wykonalne tylko w trywialnych przypadkach. Zamiast testowania gruntownego, do kierowania testami należy wykorzystać analizę ryzyka i priorytetyzację.

Odpowiedź na pytanie związana jest także z inną zasadą testowania – że testowanie ujawnia usterki. W sylabusie opisano tę zasadę testowania następująco:

Testowanie może pokazać, że istnieją usterki, ale nie może dowieść, że oprogramowanie nie posiada defektów. Testowanie zmniejsza prawdopodobieństwo występowania w oprogramowaniu niewykrytych defektów, ale nawet jeżeli nie zostały znalezione żadne usterki, nie stanowi to dowodu poprawności oprogramowania.

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.

Określenie kryteriów zakończenia to jedno z głównych zadań wykonywanych podczas planowania testów.

Etap planowania, o którym mowa w pytaniu, został opisany ogólnie w sylabusie w podrozdziale 1.4.1 Planowanie i nadzór oraz szczegółowo w kilku rozdziałach działu 5. Zgodnie z podrozdziałem 1.4.1 sylabusa, planowanie testów polega na zdefiniowaniu celów testowania oraz określeniu czynności testowych potrzebnych do wypełnienia celów i misji testowania. Podrozdział 5.2.1 precyzuje, iż planowanie może zostać udokumentowane w głównym planie testów lub w oddzielnych planach testów dla każdego poziomu.

Zgodnie z podrozdziałem 5.2.2 Czynności związane z planowaniem testów sylabusa, w planowanie testów mogą wchodzić następujące czynności:

• ustalanie zakresu i ryzyka oraz zidentyfikowanie celów testowania,
• określanie ogólnego podejścia do testowania, włącznie z określeniem poziomów testów oraz kryteriów wejścia i zakończenia,
• integrowanie i koordynowanie czynności testowych z innymi czynnościami w cyklu życia oprogramowania (zakupami, dostawami, rozwojem, działaniem produkcyjnym oraz pielęgnacją),
• podejmowanie decyzji o tym, co testować, którym rolom przypisać jakie czynności testowe, jak czynności testowe powinny być wykonane oraz jak powinno się oceniać wyniki testów,
• harmonogramowanie analizy i projektowania testów,
• harmonogramowanie implementacji, wykonania i oceny testów,
• przydzielanie zasobów do różnych czynności testowych,
• określanie dokumentacji testowej: ilości, poziomu szczegółowości, struktury oraz wzorców,
• wybieranie metryk do monitorowania i kontrolowania przygotowania i wykonania testów, naprawy defektów oraz ryzyka,
• ustalanie poziomu szczegółowości procedur testowych, tak aby dostarczyć wystarczającą ilość informacji dla wsparcia powtarzalnego przygotowania i wykonania testów.

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.

Wszystkie wymienione w pytaniu zadania – oprócz zadania E – są zadaniami związanymi z implementacją i wykonaniem testów. Wymienione w odpowiedzi E „analizowanie doświadczeń zdobytych podczas testowania” jest jednym z głównych zadań podczas czynności zamykających testy (zob. w sylabusie podrozdział 1.4.5 Czynności zamykające testy).

Etap implementacji i wykonania testów, o którym mowa w pytaniu, został opisany w podrozdziale 1.4.3 Implementacja i wykonanie testów sylabusa. 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,
• wykonywanie procedur 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).

Koszt naprawienia usterki jest najniższy na początku cyklu życia produktu i wzrasta w miarę zbliżania się do etapu oddania produktu do użytku.

Naprawienie defektu we wczesnych etapach rozwoju oprogramowania jest zdecydowanie tańsze – na przykład usterki znalezione podczas przeglądów (np. defekty znalezione w wymaganiach) często okazują się dużo tańsze do usunięcia niż te wykryte podczas wykonywania testów dynamicznych (zob. w sylabusie rozdział 3.1 Techniki statyczne a proces testowania). Dlatego też m.in. zgodnie z jedną z podstawowych zasad testowania (zob. w sylabusie rozdział 1.3 Ogólne zasady testowania), testowanie należy rozpocząć tak wcześnie, jak to możliwe w cyklu życia oprogramowania.

Testowanie integracji systemów powinno odbywać się po testowaniu systemowym.

Zgodnie z sylabusem (zob. podrozdział 2.2.2 Testy integracyjne):

Testy integracyjne mogą być wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości:

• testowanie integracji modułów sprawdza interakcje pomiędzy modułami oprogramowania i jest wykonywane po testach modułowych,
• testowanie integracji systemów sprawdza interakcje pomiędzy różnymi systemami lub pomiędzy sprzętem a oprogramowaniem i może być wykonywane po testowaniu systemowym.

(…) Im większy jest zakres integracji, tym trudniejsze może być określenie, który moduł lub system zawiera defekt, co powoduje zwiększone ryzyko i dłuższy czas rozwiązywania problemów.

W ramach testów systemowych możemy zbadać wymagania zarówno funkcjonalne, jak i niefunkcjonalne.

Zgodnie z podrozdziałem 2.2.3 Testy systemowe sylabusa, testy systemowe zajmują się zachowaniem systemu/produktu:

Testy systemowe powinny sprawdzać funkcjonalne jak i niefunkcjonalne wymagania na system oraz jakość danych. Wymagania mogą być wyrażone w formie tekstu lub modeli. Testerzy muszą umieć sobie poradzić z wymaganiami niekompletnymi lub nieudokumentowanymi.

Testowanie systemowe wymagań funkcjonalnych rozpoczyna się przez użycie najbardziej odpowiednich technik opartych na specyfikacji (czarnoskrzynkowych) dla testowanego aspektu systemu. Na przykład można utworzyć tablicę decyzyjną zawierającą kombinacje skutków opisane w regułach biznesowych.

Następnie można użyć technik opartych na strukturze (białoskrzynkowych) do oceny dokładności testowania w odniesieniu do elementów struktury, takich jak menu lub nawigacja po stronach webowych.

Aby sprawdzić, czy modyfikacje nie wprowadziły nowych defektów wykonuje się testy regresywne.

Sylabus (zob. rozdział 2.3 Typy testów) wymienia następujące cztery typy testów wyodrębnione według kryterium celu testów:

• testowanie funkcji (testowanie funkcjonalne) – gdy celem jest przetestowanie funkcji wykonywanej przez oprogramowanie;
• testowanie atrybutów niefunkcjonalnych (testowanie niefunkcjonalne) – gdy celem jest przetestowanie niefunkcjonalnej cechy jakościowej, np. niezawodności lub użyteczności oprogramowania,
• testowanie struktury / architektury oprogramowania (testowanie strukturalne) – gdy celem jest przetestowanie struktury lub architektury oprogramowania lub systemu;
• testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne – gdy celem jest potwierdzanie, że defekty zostały naprawione (testy potwierdzające) oraz szukanie niezamierzonych zmian (testowanie regresywne).

Zgodnie z sylabusem (zobacz rozdział 2.3.4 Testowanie związane ze zmianami: testowanie potwierdzające oraz regresywne):

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 3.2.1 Kroki przeglądu formalnego sylabusa, przegląd formalny zwykle składa się z następujących sześciu faz:

1. Planowanie:

• definiowanie kryteriów przeglądu,
• wybór uczestników przeglądu,
• przydział ról,
• wybór fragmentów dokumentów do przeglądu,
• dla bardziej formalnych typów przeglądów (np. inspekcji) – zdefiniowanie kryteriów wejścia i kryteriów zakończenia.

2. Rozpoczęcie

• rozdanie (rozesłanie) dokumentów,
• wyjaśnienie uczestnikom przeglądu celów przeglądu, procesu przeglądu oraz dokumentów,
• dla bardziej formalnych typów przeglądów (np. inspekcji) – sprawdzenie kryteriów wejścia.

3. Przygotowanie indywidualne

• przygotowanie przed spotkaniem przeglądowym poprzez przejrzenie dokumentów,
• zapisywanie potencjalnych defektów, pytań i komentarzy.

4. Kontrola / ocena / zapisanie wyników (spotkanie przeglądowe)

• dyskusja lub spisywanie, z udokumentowaniem wyników i sporządzeniem protokołu (dla bardziej formalnych typów przeglądów),
• zapisywanie defektów i rekomendacji dotyczących ich poprawiania, podejmowanie decyzji w sprawie defektów.

5. Poprawki

• naprawianie znalezionych defektów (zwykle wykonywane przez autora),
• zapisywanie zaktualizowanych statusów defektów (w przeglądach formalnych).

6. Zakończenie

• sprawdzenie, że usterki zostały obsłużone,
• zbieranie metryk,
• dla bardziej formalnych typów przeglądów (np. inspekcji) – sprawdzenie kryteriów zakończenia.

Więcej na temat faz przeglądu formalnego w filmie „Phases of Review” (otwórz w nowym oknie).

Zgodnie z podrozdziałem 3.2.3 Typy przeglądów sylabusa, przejrzenie jako jeden z typów przeglądu posiada następujące cechy:

• spotkanie jest prowadzone przez autora,
• może przybrać formę scenariuszy, uruchamiania „na sucho”, grupa kolegów,
• sesje nie ograniczone czasowo,
• opcjonalnie przygotowanie przeglądających przed spotkaniem,
• opcjonalnie raport z przeglądu, lista uwag,
• opcjonalnie protokólant (którym nie jest autor),
• w praktyce może być od całkiem nieformalnego do bardzo formalnego,
• główne cele: uczenie się, zrozumienie, znajdowanie usterek.

Wyniki oczekiwane są najbardziej użyteczne, gdy są określone przed testowaniem.

Zgodnie z treścią sylabusa (zob. rozdział 4.1 Proces rozwoju testów), oczekiwane wyniki powinny zostać określone jako część specyfikacji przypadków testowych oraz:

powinny (…) zawierać opis wyjść, zmian w danych i stanie oprogramowania oraz inne skutki testu. Gdy wyniki oczekiwane nie są zdefiniowane, może się zdarzyć, że wiarygodne, ale błędne, wyniki zostaną uznane za poprawne. Najlepiej jest, gdy wyniki oczekiwane zostaną zdefiniowane przed wykonaniem testów.

Wszystkie wymienione w odpowiedziach zwroty to techniki projektowania testów, określane także jako techniki projektowania przypadków testowych, techniki specyfikacji testowej lub techniki testowe. Klasyczny podział technik projektowania testów wyróżnia techniki czarnoskrzynkowe oraz białoskrzynkowe.

Czarnoskrzynkową techniką projektowania przypadków testów nie jest LSKiS. Technika LSKiS (Liniowe Sekwencje Kodu i Skok) to technika białoskrzynkowa (zob. rozdział 4.4 Techniki oparte na strukturze lub białoskrzynkowe sylabusa).

Aby móc udzielać prawidłowych odpowiedzi na egzaminie na podobne pytania, należy poznać nazwy technik projektowania testów i umieć przyporządkować je do jednej z dwóch głównych kategorii: technik biało- i czarnoskrzynkowych (warto przy tym pamiętać, że oprócz powyższych technik sylabus wyróżnia także techniki oparte na doświadczeniu).

W odróżnieniu technik biało- od czarnoskrzynkowych pomogą Wam poniższe dwie tabele. Dlaczego dwie? Ponieważ w jednej wymieniłem techniki, które mniej lub bardziej szczegółowo zostały opisane w sylabusie i o których warto wiedzieć więcej, bo mogą być przedmiotem różnych pytań na egzaminie. W drugiej tabeli wymieniłem zaś techniki, które nie są szczegółowo omówione w sylabusie (ba, mogą nawet nie być w nim wymienione), natomiast wzmianka o nich pojawia się w słowniku.

Tabela 1: Techniki umówione w sylabusie

Tabela 2: Techniki bez szczegółowego omówienia w sylabusie (wspomniane tylko w słowniku)

Do pełnego pokrycia wystarczy 1 przypadek testowy dla pokrycia instrukcji oraz 2 przypadki testowe dla pokrycia decyzji.

W oparciu o treść pytania można wydzielić następujące klasy równoważności: { x < 18 }, { 18 ≤ x ≤ 21 } oraz { x > 21 }. Najlepsze wartości do pokrycia wszystkich klas równoważności zawiera zatem odpowiedź „15, 19, 25”.

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.

Testowanie stochastyczne wykorzystujące informacje statystyczne o współczynnikach awarii lub informacje o wykorzystaniu oprogramowania (takie jak profile produkcyjne) wykorzystuje się w podejściu opartym na modelach.

Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania sylabusa:

Podejście do testów jest implementacją strategii testów w konkretnym projekcie. Podejście do testów jest definiowane i uszczegóławiane w planach testów oraz projektach testów. Zwykle zawiera decyzje podejmowane na podstawie celów projektu (testowego) oraz oceny ryzyka. Stanowi ono punkt wyjściowy do planowania procesu testowania, wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia.

W oparciu o informacje zawarte w sylabusie i słowniku warto zapamiętać, że podejście do testów:

• stanowi punkt wyjścia do planowania procesu testowego, do wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia,
• jest definiowane i udoskonalane w planach testów i projektach testów,
• jest definiowane na etapie planowania czynności testowych (zob. w sylabusie m.in. podrozdział 1.4.1 Planowanie i nadzór),
• jest implementacją strategii testów dla konkretnego projektu testowego.

Typowe podejścia do testów opisane w sylabusie to:

1. podejścia analityczne: na przykład testowanie oparte na ryzyku, w którym testowanie jest kierowane na obszary o największym ryzyku;

2. podejścia oparte na modelach – na przykład testowanie stochastyczne wykorzystujące informacje statystyczne o współczynnikach awarii (takie jak modele wzrostu niezawodności) lub informacje o wykorzystaniu oprogramowania (takie jak profile produkcyjne);

3. podejścia metodyczne – na przykład podejścia oparte na awariach (włącznie ze zgadywaniem błędów i atakami usterkowymi), oparte na doświadczeniu, oparte na listach kontrolnych lub oparte na atrybutach jakościowych;

4. podejścia zgodne ze standardem lub procesem – na przykład podejścia określone przez standardy branżowe lub metodyki wytwarzania oprogramowania (np. metodyki zwinne);

5. podejścia dynamiczne i heurystyczne – na przykład testowanie eksploracyjne, w którym testowanie bardziej reaguje na zdarzenia podczas testów niż jest wykonywane według planu i w którym wykonywanie testów i ocena wyników dzieją się równolegle;

6. podejścia konsultatywne – podejścia, w których pokrycie testowe jest sterowane (napędzane) głównie przez wskazówki i porady ekspertów technologicznych lub biznesowych z zewnątrz zespołu testowego;

7. podejścia regresywne przeciwregresywne – podejścia, w których używa się powtórnie istniejących materiałów testowych, rozbudowanej automatyzacji regresywnych testów funkcjonalnych oraz standardowych zestawów testów. [„Regression-averse” w sylabusie przetłumaczono na polski jako „regresywne”, natomiast w słowniku jako „przeciwregresywne”. Tłumaczenie zawarte w słowniku jest bardziej zgodne z duchem oryginału.]

W razie potrzeby różne podejścia mogą być łączone, np. podejście dynamiczne oparte na ryzyku. Decyzja o tym, jak i dlaczego zostaną połączone, zależy od okoliczności rozpowszechnionych w danym projekcie. Na przykład organizacja może jako standard używać metodyk zwinnych, ale w szczególnej sytuacji mogłaby posłużyć się podejściem opartym na ryzyku, aby upewnić się, że testy są prawidłowo ukierunkowane.

Zgodnie z podrozdziałem 5.2.6 Podejście do testowania, strategia testowania, wybrane podejście do testów zależy od kontekstu i może uwzględniać (opis rozszerzony w stosunku do zawartości sylabusa):

• ryzyka, niebezpieczeństwa (zagrożenia) oraz wymogi bezpieczeństwa,
• dostępne zasoby oraz umiejętności i doświadczenie ludzi w użyciu wybranych technik, narzędzi i metod – np. nie ma sensu zastosowanie wyrafinowanego podejścia opartego na informacjach statystycznych o współczynnikach awarii lub informacji o wykorzystaniu oprogramowania, gdy jedynymi dostępnymi zasobami są użytkownicy biznesowi bez podstawowej wiedzy technicznej,
• technologię i charakter systemu (np. oprogramowanie na zamówienie vs. oprogramowanie z półki) – np. w celu sprawdzenia aplikacji na telefon komórkowy wymagane jest inne podejście niż testowanie aplikacji do bankowości internetowej,
• cele testów – np. sytuację gdy celem testów jest znalezienie tylko najpoważniejszych defektów,
• uregulowania prawne (np. przepisy dotyczące oprogramowania dla szpitali, banków czy administracji publicznej).

Jeśli chcesz dowiedzieć się więcej na temat podejścia do testów, polecam artykuł What is test strategy in software testing?

Bonus: w pytaniu występują zwroty, których raczej rzadko używa się w codziennym życiu: stochastyczny i heurystyczny:

• stochastyczny (od greckiego stóchastikos – zdolny do domyślenia się czegoś, bystry) to pojęcie z obszaru matematyki i statystyki, które oznacza przypadkowy, nie wykazujący żadnej określonej tendencji, nie zmierzający do określonego celu (zobacz w Słowniku Języka Polskiego oraz w Wikisłowniku),
• z kolei heurystykę (od greckiego heuresis – odnaleźć, odkryć, heureka – znalazłem) można zdefiniować najszerzej jako umiejętność twórczego myślenia, kojarzenia ze sobą faktów, wyszukiwania i zbierania informacji itp. (zobacz wiele znaczeń pojęcia heurystyka na Wikipedii).

Komparator testowy zalicza się do grupy narzędzi wspierających wykonywanie testów oraz logowanie wyników.

Zgodnie z podrozdziałem 6.1.1 Znaczenie i cel wsparcia narzędziowego dla testów sylabusa, narzędzia testowe mogą być wykorzystywane w jednej lub wielu czynnościach wspierających testowanie (np. używane wprost w testach lub tylko przy zarządzaniu procesem testowym) i w zależności do kontekstu mogą realizować wiele celów (np. zwiększenie efektywności i zwiększenie niezawodności).

W oparciu o kryterium rodzaju czynności testowych wspieranych przez narzędzie, w sylabusie (zob. podrozdział 6.1.2 Klasyfikacja narzędzi testowych i kolejne od 6.1.3 do 6.1.8) dokonano podziału narzędzi na sześć grup. Z poniższej tabeli dowiesz się, jakie typy narzędzi zaklasyfikowano do tych głównych grup.