Seledynowy

Sytuację gdy to, co widzi użytkownik końcowy różni się od wyspecyfikowanego lub oczekiwanego zachowania nazywamy awarią.

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.

Zgodnie z podrozdziałem 1.1.5 Jak dużo testowania jest potrzebne? sylabusa:

Podczas podejmowania decyzji jak dużo testów należy wykonać, powinno się wziąć pod uwagę poziom ryzyka, włączając w to ryzyko techniczne, ryzyko związane z bezpieczeństwem, a także ryzyko biznesowe oraz ograniczenia projektowe takie jak czas i budżet.

Testowanie powinno dostarczać interesariuszom informacji wystarczających do podjęcia świadomych decyzji o dopuszczeniu testowanego oprogramowania lub systemu do następnej fazy rozwoju lub przekazaniu go klientowi.

Wiemy, że nie możemy przetestować wszystkiego, nawet jeśli diablo tego chcemy. Zgodnie z jedną z siedmiu podstawowych zasad testowania (zob. w sylabusie rozdział 1.3 Ogólne zasady testowania), testowanie gruntowne jest niewykonalne. Wiemy również, że każdy system podlega ryzyku takiego czy innego rodzaju oraz że istnieje pewien poziom jakości, który jest akceptowalny dla danego systemu.

Kluczowym aspektem osiągnięcia akceptowalnego wyniku w ramach skończonej i ograniczonej liczbie testów jest nadawanie priorytetów (priorytetyzacja). Najważniejsze testy należy wykonać w pierwszej kolejności, tak żeby w każdej chwili mieć pewność, że testy już wykonane są ważniejsze od tych, które są jeszcze do zrobienia. Dzięki temu nawet jeśli aktywność testowa zostanie zmniejszona o połowę, będziemy mogli zapewnić klienta lub kierownika, że najważniejsze testy zostały wykonane. Najważniejsze testy to te, które testują najbardziej istotne aspekty systemu: testują najważniejsze funkcje zdefiniowane przez użytkowników lub sponsorów systemu lub najważniejsze atrybuty niefunkcjonalne, a także dotyczą najbardziej ryzykownych obszarów.

Innym ważnym aspektem jest ustalenie kryteriów, które pozwolą w sposób najbardziej obiektywny określić, czy można bezpiecznie przerwać testy – kryteria te znane są jako kryteria zakończenia (wyjścia).

Priorytety i kryteria zakończenia stanowią podstawę planowania. W rezultacie pożądany poziom jakości i ryzyka może być zagrożony, ale nasze podejście zapewnia, że możemy jeszcze określić, ile testów jest wymaganych w celu osiągnięcia uzgodnionych poziomów i nadal możemy mieć pewność, że każda redukcja czasu lub wysiłku nie wpłynie na ostateczny bilans – najważniejsze testy będą nadal tymi, które zostały już wykonane, gdy tylko się zatrzymamy.

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.

Jednym z głównych zadań wykonywanych podczas planowania testów jest planowanie czynności związanych z analizą i projektowaniem testów (ustalenie rozkładu tych prac w czasie). Wymienione w pozostałych opcjach czynności są związane raczej z kontrolą i monitorowaniem testów aniżeli z ich planowaniem. Czynności te jednakowoż są ze sobą bardzo powiązane – podczas planowania testów bierze się pod uwagę informacje pochodzące z monitorowania i kontroli testów.

Etap planowania i kontroli testów, o którym mowa w pytaniu, został opisany w sylabusie w podrozdziale 1.4.1 Planowanie i nadzór oraz 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.

Raportowanie rozbieżności jako incydentów to jedno z głównych zadań wykonywanych podczas implementacji i wykonania testów.

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,
• 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).

Jedną z głównych korzyści wynikających z niezależnego testowania jest często większa skuteczność w znajdowaniu defektów. Wynika ona przede wszystkim z braku stronniczości testerów w ocenie oprogramowania, która to stronniczość mogłaby w sposób naturalny wystąpić, gdyby oceny własnego dzieła dokonywał jego autor (deweloper).

Zgodnie z rozdziałem 1.5 Psychologia testowania sylabusa:

Sposób myślenia stosowany podczas testowania i przeglądania różni się od stosowanego podczas rozwoju oprogramowania. Programiści posiadający odpowiednie nastawienie są w stanie testować swój kod, ale zwykle odpowiedzialność za testowanie przekazuje się testerom, żeby wzmocnić koncentrację wysiłków oraz uzyskać dodatkowe korzyści, takie jak niezależne spojrzenie wyszkolonych, zawodowych testerów.  (…)

Niezależność do pewnego stopnia jest często bardziej skuteczna w znajdowaniu defektów i awarii (unika się stronniczości autora). Nie może ona jednak zastąpić znajomości rzeczy i z tego względu programiści są w stanie efektywnie znajdować usterki w swoim własnym kodzie.

Testy przeprowadzane w celu sprawdzenia, czy defekt został skutecznie usunięty to testy potwierdzające (tzw. re-testy). Należy przy tym pamiętać, że naprawa defektu (czyli debagowanie) jest czynnością programistyczną, a nie czynnością testową .

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 (testowanie potwierdzające) oraz szukanie niezamierzonych zmian (testowanie regresywne).

Wskazane wśród możliwych odpowiedzi testowanie pielęgnacyjne to testowanie zmian we wdrożonym systemie lub testowanie wpływu zmienionego środowiska na wdrożony system, zaś testowanie ad hoc to testy wykonywane nieformalnie, w których m.in. brak jest oczekiwań co do rezultatów oraz wykonaniem testu kieruje dowolność.

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. Udział testerów w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania oprogramowania 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).

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

Fałszywa jest zatem odpowiedź, że usterki znalezione podczas wcześnie zaprojektowanych testów są droższe do naprawienia, ponieważ zazwyczaj są tańsze – np. zmiana w jednym punkcie specyfikacji powinna być tańsza niż poprawa kilkuset linijek kodu. Wczesne projektowanie testów nie zawsze również wymaga więcej wysiłku (dużo w tym przypadku zależy od kontekstu systemu i projektu).

Aktywność testowa wykonywana w celu wykrycia defektów w interfejsach i interakcjach pomiędzy modułami to testowanie integracyjne.

Testowanie integracyjne to jeden z poziomów testów (zob. w sylabusie rozdział 2.2 Poziomy testów), obok testów modułowych, systemowych i akceptacyjnych. Zgodnie z sylabusem:

Dla każdego poziomu testowania można zdefiniować: ogólne cele, produkty, na podstawie których tworzy się przypadki testowe (podstawę testów), przedmiot testów (to co jest testowane), typowe defekty i awarie do wykrycia, wymagania na jarzmo testowe oraz wsparcie narzędziowe, środowisko testowe, specyficzne podejście, odpowiedzialność.

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.

Podstawą testów w testowaniu integracyjnym mogą być projekt oprogramowania i systemu, architektura, przepływy pracy oraz przypadki użycia.

Typowymi przedmiotami testów w testowaniu integracyjnym są podsystemy, implementacja baz danych, infrastruktura, interfejsy oraz konfiguracja systemu i dane konfiguracyjne.

Testowanie integracyjne może być wykonywane na więcej niż jednym poziomie i dla przedmiotów testów o różnej wielkości, np. testowanie integracji modułów sprawdza interakcje pomiędzy modułami oprogramowania i jest wykonywane po testach modułowych, zaś 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.

Przeglądy kodu lub inspekcje są uważane za testowanie.

Spośród wymienionych przypadków analiza statyczna będzie najbardziej użyteczna dla wymuszania stosowania standardów kodowania podczas procesu wytwarzania oprogramowania.

Białoskrzynkowe techniki projektowania testów to procedura wywodzenia i/ lub wybierania przypadków testowych oparta na analizie wewnętrznej struktury modułu lub systemu (zob. w sylabusie rozdziały 4.2 Kategorie technik projektowania testów oraz 4.4 Techniki oparte na strukturze lub białoskrzynkowe).

Białoskrzynkowe techniki projektowania testów określane są także po prostu jako białoskrzynkowe techniki lub jako projektowanie strukturalnych przypadków testowych, techniki oparte o strukturę lub techniki projektowania testów w oparciu o strukturę.

Pozostałe opcje odpowiedzi (testowanie oparte na projekcie, zgadywanie błędów, testowanie oparte na doświadczeniu) dotyczą innych technik i sposobów testowania.

W związku z tym, że 100% pokrycia decyzji implikuje 100% pokrycia instrukcji, dodanie do kodu kolejnych instrukcji nie wpłynie na pokrycie instrukcji i decyzji w zaprojektowanych już przypadkach testowych.

W oparciu o treść pytania można wydzielić następujące klasy równoważności: { x < 5 }, { 5 ≤ x < 100 } oraz { x ≥ 100 }. Spośród możliwych opcji odpowiedzi, dane wejściowe, które zostałyby wygenerowane przy użyciu analizy wartości brzegowych zawiera odpowiedź „4, 5, 99”.

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.

Procedury zarządzania konfiguracją powinny zostać wybrane, udokumentowane i wdrożone podczas fazy planowania testów (więcej na temat fazy planowania testów zob. w sylabusie w podrozdziałach 1.4.1 Planowanie i nadzór oraz 5.2.2 Czynności związane z planowaniem testów).

Zgodnie z treścią rozdziału 5.4 Zarządzanie konfiguracją sylabusa:

Celem zarządzania konfiguracją jest ustanowienie i utrzymanie integralności produktów (modułów, danych i dokumentacji) związanych z oprogramowaniem lub systemem przez cały projekt lub cykl życia produktu.

Z punktu widzenia procesu testowania, zarządzanie konfiguracją zapewnia, że:

• wszystkie elementy oprogramowania testaliów* są zidentyfikowane, poddane kontroli wersji, śledzone pod względem zmian, powiązane między sobą oraz z elementami wytwarzania (przedmiotami testów), tak aby utrzymać możliwość ich śledzenia przez cały proces testowy,
• wszystkie zidentyfikowane dokumenty oraz elementy oprogramowania posiadają jednoznaczne odniesienie w dokumentacji testowej .

Z punktu widzenia testera, zarządzanie konfiguracją pomaga w jednoznaczny sposób zidentyfikować (i odtworzyć) testowany element, dokumenty testowe, testy oraz jarzmo testowe.

* W wersji polskiej sylabusa (wersja 2011.1.1 oraz 2011.1.2) w tym punkcie jest mowa o „elementach oprogramowania”, a nie o testaliach, natomiast wersja angielska mówi o „all items of testware”, czyli właśnie testaliach – co wydaje się bardziej logiczne w kontekście rozdziału. Zawarte w polskim sylabusie tłumaczenie zwrotu „items of testware” jako „elementy oprogramowania” należy uznać w tym kontekście za co najmniej wprowadzające w błąd, dlatego powyżej napisałem o testaliach, a nie elementach oprogramowania.

Zgodnie z podrozdziałem 6.1.2 Klasyfikacja narzędzi testowych sylabusa, niektóre narzędzia testowe oferują wsparcie bardziej odpowiednie dla programistów (np. narzędzia używane w testowaniu modułowym lub testowaniu integracji modułów), niż dla testerów.

Do narzędzi skierowanych bardziej w stronę programistów (oznaczonych w sylabusie w podrozdziałach od 6.1.3 do 6.1.8 literką „D”) zaliczono:

• narzędzia do analizy statycznej (zob. podrozdział 6.1.4 Wsparcie narzędziowe dla testów statycznych),
• narzędzia do modelowania (zob. podrozdział 6.1.4 Wsparcie narzędziowe dla testów statycznych),
• jarzma testowe / struktury do testów jednostkowych (zob. podrozdział 6.1.6 Wsparcie narzędziowe dla wykonania testów oraz logowania),
• narzędzia mierzące pokrycie (zob. podrozdział 6.1.6 Wsparcie narzędziowe dla wykonania testów oraz logowania),
• narzędzia do analizy dynamicznej (zob. podrozdział 6.1.7 Wsparcie narzędziowe dla wydajności i monitorowania).