Cyjan

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. Można zdefiniować kilka poziomów niezależności (od najniższego do najwyższego):

• testy zaprojektowane przez osobę, która napisała testowane oprogramowanie (niski poziom niezależności)
• testy zaprojektowane przez inną osobę (np. z zespołu programistów)
• testy zaprojektowane przez osobę z innego zespołu w organizacji (np. niezależnego zespołu testerów) lub przez specjalistów od testów (np. testów wydajnościowych lub użyteczności)
• testy zaprojektowane przez osobę z innej organizacji lub firmy (np. testy zlecone lub certyfikacja przez niezależny organ certyfikujący)

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.

Tworzenie zestawów testowych w celu efektywnego wykonania testów to jedno z głównych zadań wykonywanych podczas implementacji i wykonania testów (zob. w sylabusie podrozdział 1.4.3 Implementacja i wykonanie testów).

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ównywanie wynikó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).

Zgodnie z podrozdziałem 2.1.3 Testowanie w cyklu życia oprogramowania sylabusa, w każdym modelu rozwoju oprogramowania (modelu V,  modelu iteracyjnym etc.) 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 dla tego poziomu cele testowania,
• analiza i projektowanie testów dla danego poziomu testowania powinny rozpoczynać się już podczas odpowiadającej im fazy wytwarzania,
• testerzy powinni uczestniczyć w przeglądach już od wczesnych wersji dokumentacji tworzonej podczas wytwarzania.

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 (zob. 3.1 Techniki statyczne a proces testowania).

Zgodnie z podstawą testów i typowymi obiektami testów na czterech poziomach testowania:

• testy modułowe (A) odpowiadają etapowi kodowania (II),
• testy integracyjne (D) odpowiadają etapowi projektowania niskiego poziomu (III),
• testy systemowe (C) odpowiadają etapowi projektowania wysokiego poziomu (I),
• testy akceptacyjne (B) związane są z weryfikacją wymagań biznesowych (IV).

Sylabus wprost wskazuje, iż odpowiedzialność za testy akceptacyjne leży często po stronie klientów lub użytkowników systemu. Mogą w nie być zaangażowani również inni interesariusze (zob.  podrozdział 2.2.4 Testy akceptacyjne sylabusa).

Testowanie akceptacyjne to jeden z poziomów testów (zob. w sylabusie rozdział 2.2 Poziomy testów), obok testów modułowych, testów integracyjnych i testów systemowych.

Celem testowania akceptacyjnego jest nabranie zaufania do systemu, jego części lub pewnych atrybutów niefunkcjonalnych systemu. Wyszukiwanie defektów nie jest głównym celem testowania akceptacyjnego. Testowanie akceptacyjne może oceniać gotowość systemu do wdrożenia i użycia, chociaż nie musi być ostatnim poziomem testowania (na przykład po testach akceptacyjnych systemu mogą nastąpić testy integracji systemów dużej skali).

Testowanie akceptacyjne może wystąpić w różnych momentach cyklu życia oprogramowania, na przykład:

• tzw. oprogramowanie z półki może podlegać testom akceptacyjnym, gdy jest instalowane lub integrowane,
• testowanie akceptacyjne użyteczności modułu może być wykonane podczas testowania modułowego,
• testowanie akceptacyjne nowej funkcjonalności może być przeprowadzone przed testowaniem systemowym.

Sylabus wymienia następujące formy testów akceptacyjnych:

• testowanie akceptacyjne przez użytkownika,
• (akceptacyjne) testowanie produkcyjne,
• testowanie akceptacyjne zgodności z umową i testy zgodności legislacyjnej
• testowania alfa i testowanie beta (lub testy w warunkach polowych).

Za dokumenty podlegające przeglądowi formalnemu odpowiada autor.

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 < 18 } – chłodzenie wyłączone (bo zimno),
• { 18 ≤ x ≤ 21 } – temperatura odpowiednia,
• { x > 21 } – chłodzenie włączone (bo cieplutko).

Do tej samej klasy równoważności należą zatem wartości 22, 23 i 24.

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 klasom równoważności 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 podrozdziałem 4.3.5 Testowanie w oparciu o przypadki użycia sylabusa:

Przypadki testowe wywiedzione z przypadków użycia najbardziej przydają się wykrywaniu usterek w przepływach procesów z rzeczywistego użytkowania systemu. (…) Pomagają również wykrywać defekty integracji spowodowane interakcją i interfejsami różnych modułów, co nie byłoby widoczne w testach modułowych (…).

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.

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.

Zgodnie z ww. rozdziałem sylabusa, wdrażanie wybranego narzędzia w organizacji zaczyna się od projektu pilotażowego (wdrożenia narzędzia w małym zespole w celu opracowania najlepszej metody jego używania), który ma następujące cele:

• szczegółowe zapoznanie się z narzędziem,
• ocena, jak narzędzie pasuje do aktualnie istniejących procesów i praktyk oraz ustalenie, co ewentualnie należałoby zmienić,
• ustalenie standardów użycia, zarządzania, przechowywania oraz pielęgnacji narzędzia i artefaktów testowych (np. wypracowanie konwencji nazewnictwa plików i testów, stworzenie bibliotek oraz zdefiniowanie modułowości zestawów testów),
• ocena, czy korzyści zostaną osiągnięte przy rozsądnych kosztach.

Narzędzie, które przechowuje treść wymagań, wspomaga śledzenie powiązań między wymaganiami, pozwala nadawać priorytety wymaganiom oraz zapewnia powiązanie przypadków testowych z wymaganiami to narzędzie zarządzania wymaganiami. Zgodnie z podrozdziałem 6.1.3 Wsparcie narzędziowe dla zarządzania testowaniem i testami sylabusa:

Narzędzia te przechowują tekst wymagań, ich atrybuty (np. priorytet), generują unikalne identyfikatory i wspierają śledzenie powiązań pomiędzy wymaganiami, a poszczególnymi testami. Mogą one również pomóc w znalezieniu niespójnych lub brakujących wymagań.