Alabastrowy

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

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 jest jednym z głównych zadań etapu planowania (zob. w sylabusie podrozdział 5.2.2 Czynności związane z planowaniem testów), a nie etapu implementacji i wykonania testów. Pozostałe zadania wymienione w pytaniu jak najbardziej są głównymi zadaniami implementacji i wykonania testów.

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

„Unikanie stronniczości autora” oraz „konstruktywne komunikowanie problemów” to wyrazy niezależnego testowania i dobrych umiejętności interpersonalnych testera.

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.

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.

W związku z tym, że faza planowania testów jest najwcześniejsza (zob. rozdział 1.4 Podstawowy proces testowy), wykrywanie defektów podczas tej fazy jest najtańsze.

Testowanie integracyjne zewnętrzne (dużej skali), zwane także testowaniem integracji systemów to, zgodnie ze słownikiem, testowanie integracji systemów i pakietów; testowanie interfejsów z organizacjami zewnętrznymi, np. Elektroniczna Wymiana Danych, Internet. Dla porównania istnieje także testowanie integracyjne małej skali, nazywane testowaniem integracji modułów lub testowaniem połączenia.

Zarówno testowanie integracji systemów (testowanie integracyjne zewnętrzne), jak i testowanie integracji modułów (testowanie połączenia, testowanie integracyjne małej skali) to „formy” testowania integracyjnego. Zgodnie z sylabusem (zob. podrozdział 2.2.2 Testy integracyjne), testowanie integracyjne może być bowiem 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.

Dodatkowo można wyróżnić testowanie integracji sprzęt-oprogramowanie czy testowanie interfejsu.

Wymienione w wariantach odpowiedzi testowanie systemu z dużą liczbą użytkowników to testowanie obciążeniowe, zaś łączenie komponentów oprogramowania i testowanie ich w jednym przejściu pasuje do testowania według podejścia „wielkiego wybuchu”.

Testowanie zgodności z kontraktem i regulacjami prawnymi to jedna z form testowania akceptacyjnego (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. 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ść.

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

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

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:

Testowaniem statycznym nie jest zgadywanie błędów.

Faza planowania jest pierwszą fazą przeglądu formalnego i obejmuje m.in. wybór uczestników oraz przydzielanie ról.

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

Prowadzenie mediacji między uczestnikami jest jednym z zadań moderatora podczas przeglądu formalnego. Za sporządzanie notatek ze spotkania oraz ew. odbieranie telefonów odpowiada protokolant (określany także jako skryba lub rejestrator), natomiast przygotowanie dokumentów podlegających przeglądowi to zadanie przypisane do roli autora.

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 < 10000 }, { 10000 ≤ x ≤ 99999 } oraz { x > 99999 }. Poprawną klasą równoważności jest klasa { 10000 ≤ x ≤ 99999 }. Spośród możliwych opcji odpowiedzi, do poprawnych klas równoważności ORAZ wartości granicznych należą zatem wartości 10000 i 99999.

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.