Indygo

Do podstawowych zasad testowania nie należy testowanie gruntowne. Wręcz przeciwnie – jedna z zasad testowania brzmi „Testowanie gruntowne jest niewykonalne”. Zasada ta została opisana w sylabusie następująco:

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ę.

W oparciu o powyższą zasadę należy podczas testowania zastanowić się, jaka funkcja lub cecha w oprogramowaniu może spowodować awarię – i następnie na tej funkcji lub cesze w szczególności skoncentrować wysiłek testerski.

Podstawowe zasady testowania zostały opisane w rozdziale 1.3 Ogólne zasady testowania sylabusa. Siedem podstawowych zasad testowania to:

1. Testowanie ujawnia usterki
2. Testowanie gruntowne jest niewykonalne
3. Wczesne testowanie
4. Kumulowanie się błędów usterek*
5. Paradoks pestycydów
6. Testowanie zależy od kontekstu
7. Mylne przekonanie o braku błędów

Z podstawowych zasad testowania w szczególności warto zapamiętać następujące zwroty, które w różnym kontekście mogą pojawić się w pytaniach egzaminacyjnych:

• testowanie może pokazać, że usterki istnieją, ale nie może dowieść, że usterek nie ma w ogóle;
• testowanie zmniejsza prawdopodobieństwo występowania w oprogramowaniu niewykrytych usterek;
• nawet jeżeli nie zostały znalezione żadne usterki, nie stanowi to dowodu poprawności oprogramowania;
• testowanie gruntowne jest niewykonalne;
• zamiast testowania gruntownego, należy wykorzystać analizę ryzyka oraz priorytetyzację;
• testowanie należy rozpocząć tak wcześnie, jak to możliwe w cyklu życia oprogramowania;
• przypadki testowe muszą być regularnie przeglądane i poprawiane.

* Wziąwszy pod uwagę anglojęzyczne brzmienie zasady (Defect clustering) oraz wyraźne rozgraniczenie w testerskiej terminologii błędów (ang. errors), defektów (ang. defects) oraz awarii (ang. failures), prawidłowe tłumaczenie tej zasady na język polski powinno brzmieć „Kumulowanie defektów”. Tymczasem w sylabusie (od wersji 2011.1.1 do 2011.1.3) przetłumaczono tę zasadę jako „Kumulowanie się błędów”, co moim zdaniem należy uznać za tłumaczenie błędne.

Wszystkie wymienione w odpowiedziach czynności składają się na podstawowy proces testowy.

Zgodnie z sylabusem (zob. rozdział 1.4 Podstawowy proces testowy), podstawowy proces testowy składa się z następujących czynności:

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.

Czynności te w praktyce mogą się zazębiać lub występować jednocześnie. Zwykle konieczne jest także ich dostosowanie do kontekstu systemu i projektu.

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.

Przeglądanie podstawy testów to jedno z głównych zadań wykonywanych podczas fazy 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.

Testowanie można – wręcz wypada – rozpocząć, gdy tylko zaakceptowano wymagania oprogramowania. Podstawą testów w takiej sytuacji może być na przykład specyfikacja wymagań biznesowych.

Zgodnie bowiem 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.

Udział testerów w przeglądach już od wczesnych wersji dokumentacji jest także jedną z cech dobrego testowania w każdym modelu rozwoju oprogramowania (zob. w sylabusie podrozdział 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 wytworzeniem oprogramowania istnieją odpowiadające jej czynności związane z testowaniem,
• każdy poziom testowania ma zdefiniowane cele,
• 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.

Testowanie modułowe zgodnie ze słownikiem nazywane jest także testowaniem jednostkowym, testowaniem programu oraz testowaniem komponentów. Pojęcie „testowania komponentów systemu” nie występuje ani w słowniku, ani w sylabusie.

Testowanie modułowe to jeden z poziomów testów (zob. więcej w sylabusie w rozdziale 2.2 Poziomy testów). Zgodnie z podrozdziałem 2.2.1 Testy modułowe sylabusa:

Testy modułowe polegają na wyszukiwaniu błędów i weryfikacji funkcjonalności oprogramowania (np. modułów, programów, obiektów, klas), które można testować oddzielnie. Może być wykonywane w izolacji od reszty systemu, w zależności od kontekstu cyklu rozwoju oprogramowania i od samego systemu. Można podczas nich użyć zaślepek, sterowników testowych oraz symulatorów.

Testy modułowe mogą zawierać testy funkcjonalności oraz niektórych atrybutów niefunkcjonalnych, takich jak stopień wykorzystania zasobów (np. wycieków pamięci) lub odporności, jak również testy strukturalne (np. pokrycia decyzji). Przypadki testowe są projektowane na podstawie takich produktów jak specyfikacja modułu, projekt oprogramowania lub model danych.

Testy modułowe zwykle wykonuje się mając dostęp do kodu źródłowego i przy wsparciu środowiska rozwojowego (np. bibliotek do testów jednostkowych, narzędzi do debagowania) oraz, w praktyce, zwykle angażują też programistę, który jest autorem kodu. Usterki są usuwane jak tylko zostaną wykryte, bez formalnego zarządzania nimi.

Pytanie związane jest z testowaniem integracyjnym, czyli jednym z poziomów testowania (zob. w sylabusie rozdział 2.2 Poziomy testów). Testowanie integracyjne sprawdza interfejsy pomiędzy modułami, interakcje z innymi częściami systemu (takimi jak system operacyjny, system plików i sprzęt) oraz interfejsy pomiędzy systemami.

Integracja elementów może przebiegać w różny sposób. W sylabusie wspomniano – jednak bez szczegółowego wyjaśnienia – o trzech podejściach: integracji zstępującej, integracji wstępującej oraz integracji metodą „wielkiego wybuchu”. Na marginesie, są to podejścia stosowane nie tylko w dziedzinie integracji modułów czy systemów przy wytwarzaniu oprogramowania, ale szerzej przy rozwiązywaniu problemów z różnych kwestii, w tym np. w ekonomii.

Podczas integracji wstępującej („z dołu do góry”) łączenie modułów zaczyna się od modułów, które nie wywołują innych modułów, a które są wywoływane przez inne „wyższe” moduły. W integracji zstępującej („z góry do dołu”) kolejność jest odwrócona – łączenie modułów w większą całość zaczyna się od modułów, które leżą najwyżej w strukturze systemu i które wywołują inne „niższe” moduły. Obie te metody integracji to tzw. metody przyrostowe (inkrementacyjne), gdyż integrujemy w nich elementy stopniowo. Ich przeciwieństwem jest integracja metodą „wielkiego wybuchu”, w której integruje się wszystkie elementy jednocześnie.

Sylabus do tych metod odnosi się następująco (zobacz podrozdział 2.2.2 Testy integracyjne):

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. (…) Żeby ułatwić namierzanie usterek oraz ich wczesne wykrywanie, w normalnych warunkach integracja powinna być raczej prowadzona metodą inkrementalną niż metodą „wielkiego wybuchu”.

W oparciu o powyższe różnice wyróżnia się testowanie zstępujące, testowanie wstępujące oraz testowanie „wielkiego wybuchu”.

Testy funkcjonalne, podobnie zresztą jak testy strukturalne, można wykonywać na każdym poziomie testów.

W podrozdziale 2.3.1 Testowanie funkcji (testowanie funkcjonalne) wskazano, iż:

Testy funkcjonalne dotyczą funkcji lub innych cech (opisanych w dokumentach lub domniemanych przez testerów) oraz ich współdziałania z innymi systemami. Można je wykonywać na wszystkich poziomach (np. testy modułowe mogą bazować na specyfikacji modułów).

W podrozdziale 2.3.3 Testowanie struktury/architektury oprogramowania (testowanie strukturalne) określono natomiast:

Testy strukturalne (białoskrzynkowe) można wykonywać na każdym poziomie testowania. Technik strukturalnych najlepiej użyć po technikach opartych na specyfikacji, po to by zmierzyć dokładność testowania przez ocenę stopnia pokrycia wybranego typu struktury.

Testowanie statyczne można wykorzystać we wszystkich wymienionych fazach wytwarzania oprogramowania, począwszy od analizy wymagań, poprzez projektowanie, na kodowaniu skończywszy.

Zgodnie z rozdziałem 3.1 Techniki statyczne a proces testowania:

W przeciwieństwie do technik dynamicznych, które wymagają uruchomienia oprogramowania, techniki statyczne polegają na sprawdzeniu ręcznym (przeglądy) lub analizie automatycznej (analiza statyczna) kodu lub innych dokumentów projektowych bez uruchamiania kodu.

Przeglądy są jednym ze sposobów na testowanie produktów procesu wytwarzania oprogramowania (łącznie z kodem). Przeglądy można wykonywać na długo przed wykonaniem testów dynamicznych. Usterki znalezione podczas przeglądów we wczesnych fazach produkcji oprogramowania (np. defekty znalezione w wymaganiach) często okazują się dużo tańsze do usunięcia niż te wykryte podczas wykonywania testów dynamicznych.

Przeglądy można wykonywać całkowicie ręcznie, ale istnieje dla nich również wsparcie narzędziowe. Główną czynnością wykonywaną manualnie jest sprawdzenie produktu i zanotowanie uwag. Przeglądom mogą podlegać wszystkie produkty procesu wytwarzania oprogramowania: specyfikacja wymagań, projekt, kod, plany testów, specyfikacja testów, przypadki testowe, skrypty testowe, podręcznik użytkownika oraz strony webowe.

Jednym z celów fazy planowania przeglądu jest przydzielenie ról uczestnikom (zob. więcej na temat ról osób biorących w przeglądzie w sylabusie w podrozdziale 3.2.2 Role i odpowiedzialność). Zapisywanie defektów może mieć miejsce w fazie przygotowania indywidualnego (gdy każda osoba indywidualnie zapisuje zauważone defekty) i spotkania przeglądowego (gdy o defektach się dyskutuje), wyjaśnianie dokumentu uczestnikom – w fazie rozpoczęcia, zaś zbieranie metryk – w fazie zakończenia.

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 to spotkanie prowadzone przez autora, zaś inspekcja prowadzona jest przez przeszkolonego moderatora (nie autora). Mimo, że autor nie prowadzi inspekcji, powinien również brać w niej udział.

Oczekiwane wyniki dla testu określa się w przypadkach testowych, w związku z czym prawidłowa odpowiedź to specyfikacja przypadków testowych.

Przypadki testowe są tworzone i określane podczas projektowania testów (zob. w sylabusie podrozdział 1.4.2 Analiza i projektowanie testów), następnie podczas implementacji testów przypadki testowe są rozwijane, implementowane, priorytetyzowane i układane w specyfikację procedur testowych, zwaną także procedurą testową lub scenariuszem testowym.

Zgodnie z treścią sylabusa (zob. rozdział 4.1 Proces rozwoju testów), oczekiwane wyniki powinny zostać określone jako część specyfikacji przypadku testowego 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.

Wskazany wśród odpowiedzi projekt testu, zwany także specyfikacją projektu testu to dokument specyfikujący warunki testowe (elementy pokrycia) dla elementu testowego, szczegółowe podejście do testów oraz identyfikujący powiązane przypadki testowe wysokiego poziomu.

W oparciu o treść pytania można wydzielić następujące klasy równoważności:

• { x < 26 } – jeśli liczba punktów otrzymanych przez kandydata jest mniejsza niż 26 punktów, kandydat niestety nie zdał,
• { 26 ≤ x ≤ 40 } – w sytuacji otrzymania punktów w liczbie zawierającej się w tym przedziale, kandydat zdał.

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.

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 testowanie decyzji. Technika testowania decyzji to technika białoskrzynkowa (zob. w sylabusie podrozdział 4.4.2 Testowanie i pokrycie decyzji).

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)

Prawidłowe pary są następujące:

• 1-d: identyfikacja konfiguracji – wymaga, aby wszystkie elementy konfiguracji i ich wersje były znane,
• 2-a: kontrola konfiguracji – utrzymuje elementy konfiguracji w bibliotece,
• 3-c: informacja o statusie – funkcja rejestrowania i raportowania informacji potrzebnych do efektywnego zarządzania konfiguracją,
• 4-b: audyt konfiguracji – sprawdza zawartość bibliotek elementów konfiguracji.

Aby udzielić prawidłowej odpowiedzi na pytanie, konieczna jest znajomość ww. pojęć zawartych w słowniku.

Zasady wprowadzania narzędzi do organizacji zostały opisane w rozdziale 6.3 Wdrażanie narzędzi w organizacji sylabusa. W rozdziale przedstawiono główne aspekty do wzięcia pod uwagę podczas wyboru narzędzia dla organizacji, cele projektu pilotażowego wdrażania wybranego narzędzia w organizacji oraz czynniki wpływające na sukces wdrożenia narzędzia w organizacji.

Główne aspekty do wzięcia pod uwagę podczas wyboru narzędzia dla organizacji to zgodnie z ww. rozdziałem sylabusa:

• ocena dojrzałości organizacyjnej, mocnych i słabych stron oraz identyfikacja możliwości doskonalenia procesu testowania przy wsparciu narzędzi,
• ocena według jasnych wymagań i obiektywnych kryteriów,
• wykonanie dowodu słuszności pomysłu poprzez użycie narzędzia testowego, po to żeby zbadać, czy jest ono skuteczne dla danego testowanego oprogramowania w ramach istniejącej infrastruktury lub po to, żeby określić jakie zmiany w infrastrukturze są potrzebne do skutecznego użycia narzędzia,
• ocena dostawcy (w tym ocena szkoleń, wsparcia oraz aspektów handlowych) lub firm udzielających wsparcia w przypadku narzędzi niekomercyjnych,
• identyfikacja wewnętrznych wymagań na doradztwo i mentoring związanych z użyciem narzędzia,
• ocena potrzeb szkoleniowych z uwzględnieniem obecnych umiejętności zespołu testowego w zakresie automatyzacji testów,
• szacowanie stosunku korzyści do kosztów na podstawie konkretnego przypadku biznesowego.