Przebranżowienie na testera

4. Techniki testowania — 330 min.
Słowa kluczowe analiza wartości brzegowych, białoskrzynkowe techniki testowania, czarnoskrzynkowe techniki testowania, podział na klasy równoważności, pokrycie, pokrycie decyzji, pokrycie instrukcji kodu, techniki testowania, techniki testowania oparte na doświadczeniu, testowanie eksploracyjne, testowanie oparte na przypadkach użycia, testowanie przejść pomiędzy stanami, testowanie w oparciu o listę kontrolną, testowanie w oparciu o tablicę decyzyjną, zgadywanie błędów
Cele nauczania — techniki testowania 4.1. Kategorie technik testowania FL-4.1.1. (K2) Kandydat potrafi wyjaśnić cechy charakterystyczne i elementy wspólne czarnoskrzynkowych technik testowania, białoskrzynkowych technik testowania oraz technik testowania opartych na doświadczeniu, a także różnice między nimi. 4.2. Czarnoskrzynkowe techniki testowania FL-4.2.1. (K3) Kandydat potrafi zaprojektować przypadki testowe na podstawie podanych wymagań metodą podziału na klasy równoważności. FL-4.2.2. (K3) Kandydat potrafi zaprojektować przypadki testowe na podstawie podanych wymagań metodą analizy wartości brzegowych. FL-4.2.3. (K3) Kandydat potrafi zaprojektować przypadki testowe na podstawie podanych wymagań metodą testowania w oparciu o tablicę decyzyjną. FL-4.2.4. (K3) Kandydat potrafi zaprojektować przypadki testowe na podstawie podanych wymagań metodą testowania przejść pomiędzy stanami. FL-4.2.5. (K2) Kandydat potrafi wyjaśnić, w jaki sposób można wyprowadzać przypadki testowe z przypadku użycia. 4.3. Białoskrzynkowe techniki testowania FL-4.3.1. (K2) Kandydat potrafi wyjaśnić pojęcie pokrycia instrukcji kodu. FL-4.3.2. (K2) Kandydat potrafi wyjaśnić pojęcie pokrycia decyzji. FL-4.3.3. (K2) Kandydat potrafi wyjaśnić korzyści wynikające z pokrycia instrukcji kodu i pokrycia decyzji. 4.4. Techniki testowania oparte na doświadczeniu FL-4.4.1. (K2) Kandydat potrafi wyjaśnić pojęcie zgadywania błędów. FL-4.4.2. (K2) Kandydat potrafi wyjaśnić pojęcie testowania eksploracyjnego. FL-4.4.3. (K2) Kandydat potrafi wyjaśnić pojęcie testowania w oparciu o listę kontrolną.

4.1. Kategorie technik testowania
Każda technika testowania, włączając te omówione w tym rozdziale, ma z założenia pomagać w identyfikowaniu warunków testowych, przypadków testowych i danych testowych. 
4.1.1. Wybór technik testowania Przy wyborze technik testowania, które będą stosowane, należy wziąć pod uwagę wiele czynników takich jak:
• typ modułu lub systemu;
• złożoność modułu lub systemu;
• obowiązujące przepisy i normy;
• wymagania klienta lub wymagania wynikające z umów;
• poziomy ryzyka;
• typy ryzyka;
• cele testów;
• dostępną dokumentację;
• wiedzę i umiejętności testerów;
• dostępne narzędzia;
• czas i budżet;
• model cyklu życia oprogramowania;
• przewidywany sposób korzystania z oprogramowania;
• dotychczasowe doświadczenie w użyciu technik testowania w testowaniu modułów i systemów;
• typy defektów spodziewane w modułach i systemach.
Niektóre techniki testowania lepiej sprawdzają się w określonych sytuacjach lub na określonych poziomach testów, inne zaś można z powodzeniem stosować na każdym poziomie testów. Aby uzyskać najlepsze rezultaty, testerzy zazwyczaj tworzą przypadki testowe łącząc ze sobą różne techniki.
Użycie technik testowania w analizie, projektowaniu i implementacji testów może mieć zróżnicowany charakter: od bardzo nieformalnego (wymagającego minimalnej lub nie wymagającego żadnej dokumentacji) po bardzo formalny. Właściwy stopień sformalizowania zależy od kontekstu testowania, w tym od: dojrzałości procesów testowych i procesów wytwarzania oprogramowania, ograniczeń czasowych, norm bezpieczeństwa i wymogów prawnych, wiedzy i umiejętności zaangażowanych osób oraz przyjętego modelu cyklu życia oprogramowania.
4.1.2. Kategorie technik testowania i ich cechy charakterystyczne W niniejszym sylabusie techniki testowania podzielono na: czarnoskrzynkowe, białoskrzynkowe i oparte na doświadczeniu.
Techniki czarnoskrzynkowe (zwane również technikami behawioralnymi lub opartymi na specyfikacji) bazują na analizie podstawy testów np. na formalnych dokumentach zawierających wymagania, specyfikacjach, przypadkach użycia, historyjkach użytkownika lub procesach biznesowych. Techniki z tej grupy można stosować zarówno w testowaniu funkcjonalnym, jak i w testowaniu niefunkcjonalnym. Techniki czarnoskrzynkowe koncentrują się na danych wejściowych i wyjściowych przedmiotu testów, bez odwoływania się do jego struktury wewnętrznej.
Podstawą białoskrzynkowych technik testowania (zwanych także technikami strukturalnymi lub opartymi na strukturze) jest analiza architektury, szczegółowego projektu, struktury wewnętrznej lub kodu przedmiotu testów. W przeciwieństwie do technik czarnoskrzynkowych techniki białoskrzynkowe koncentrują się na strukturze i przetwarzaniu wewnątrz przedmiotu testów.
Techniki testowania oparte na doświadczeniu pozwalają wykorzystać doświadczenie programistów, testerów i użytkowników do zaprojektowania, zaimplementowania i wykonania testów. Techniki te są często stosowane razem z technikami czarnoskrzynkowymi i białoskrzynkowymi.
Najważniejsze cechy charakterystyczne czarnoskrzynkowych technik testowania:
• warunki testowe, przypadki testowe i dane testowe wyprowadza się z podstawy testów, którą mogą stanowić wymagania na oprogramowanie, specyfikacje, przypadki użycia i historyjki użytkownika;
• przypadki testowe mogą być wykorzystywane do wykrywania rozbieżności między wymaganiami a ich implementacją bądź odstępstw od wymagań;
• pokrycie mierzy się na podstawie przetestowanych elementów podstawy testów i techniki zastosowanej do podstawy testów.
Najważniejsze cechy charakterystyczne białoskrzynkowych technik testowania:
• warunki testowe, przypadki testowe i dane testowe wyprowadza się z podstawy testów, która może obejmować: kod, architekturę oprogramowania, projekt szczegółowy bądź dowolne inne źródło informacji o strukturze oprogramowania;
• pokrycie mierzy się na podstawie przetestowanych elementów wybranej struktury (np. kodu lub interfejsów);
• dodatkowym źródłem informacji wykorzystywanym przy określaniu oczekiwanych wyników przypadków testowych są często specyfikacje.
Najważniejsze cechy charakterystyczne technik testowania opartych na doświadczeniu:
• warunki testowe, przypadki testowe i dane testowe wyprowadza się z podstawy testów, która może obejmować wiedzę i doświadczenie testerów, programistów, użytkowników oraz innych interesariuszy;
• wiedza i doświadczenie mogą dotyczyć między innymi przewidywanego sposobu korzystania z oprogramowania, środowiska pracy oprogramowania oraz prawdopodobnych defektów i ich rozkładu.
Techniki testowania i odpowiadające im miary pokrycia opisuje międzynarodowy standard ISO/IEC/IEEE 29119-4. Więcej informacji o technikach testowania zawierają publikacje: [Craig 2002] oraz [Copeland 2004], a także [Roman 2015].
4.2. Czarnoskrzynkowe techniki testowania
4.2.1. Podział na klasy równoważności Technika podziału na klasy równoważności polega na dzieleniu danych na grupy (zwane klasami równoważności lub klasami abstrakcji) w taki sposób, aby każda grupa zawierała elementy, które z założenia mają być przetwarzane w ten sam sposób (zobacz [Kaner 2013] i [Jorgensen 2014], a także [Roman 2015]). 
Klasy równoważności można wyznaczać zarówno dla wartości poprawnych, jak i dla wartości niepoprawnych:
• wartości poprawne to wartości, które powinny zostać zaakceptowane przez moduł lub system, a zawierająca je klasa równoważności nosi nazwę „poprawnej klasy równoważności”;
• wartości niepoprawne to wartości, które moduł lub system powinien odrzucić, a zawierająca je klasa równoważności to „niepoprawna klasa równoważności”;
• klasy można identyfikować w odniesieniu do wszelkich elementów danych, które są związane z przedmiotem testów, takich jak: dane wejściowe, dane wyjściowe, wartości wewnętrzne bądź wartości zależne od czasu (np. występujące przed zdarzeniem lub po zdarzeniu), a także w odniesieniu do parametrów interfejsu (np. integrowanych modułów testowanych w ramach testowania integracyjnego);
• każdą klasę można w razie potrzeby podzielić na podklasy;
• każda wartość musi należeć do jednej i tylko jednej klasy równoważności;
• jeśli w przypadkach testowych są stosowane niepoprawne klasy równoważności, należy je testować indywidualnie (tzn. nie należy ich łączyć z innymi niepoprawnymi klasami równoważności3), aby uniknąć zamaskowania awarii. Maskowanie awarii może mieć miejsce, gdy w tej samej chwili występuje kilka awarii, ale tylko jedna jest widoczna, przez co pozostałe awarie pozostają niewykryte.
Warunkiem uzyskania stuprocentowego pokrycia przy korzystaniu z tej techniki jest pokrycie przez przypadki testowe wszystkich zidentyfikowanych klas równoważności (włączając niepoprawne klasy równoważności), co wymaga wybrania do testów co najmniej jednej wartości z każdej klasy. Pokrycie mierzy się jako iloraz liczby klas równoważności przetestowanych przy użyciu co najmniej jednej wartości przez łączną liczbę zdefiniowanych klas równoważności i zazwyczaj wyrażane jest w procentach. Podział na klasy równoważności można stosować na wszystkich poziomach testów.
4.2.2. Analiza wartości brzegowych Technika analizy wartości brzegowych jest rozszerzeniem techniki podziału na klasy równoważności, ale może być stosowana tylko w przypadku uporządkowanych klas zawierających dane liczbowe lub sekwencyjne. Wartościami brzegowymi klasy równoważności są jej wartość minimalna i maksymalna (lub pierwsza i ostatnia wartość).
Rozważmy następujący przykład. Załóżmy, że pole umożliwia akceptację jednoznakowej wartości całkowitej wprowadzanej z klawiatury numerycznej (tym samym zakładamy, że niemożliwe jest wprowadzenie wartości nienumerycznych). Akceptowalny zakres wartości całkowitych mieści się w przedziale od 1 do 5 włącznie. W tym przypadku możemy więc wyróżnić trzy klasy równoważności: niepoprawna (wartości za niskie), poprawna, niepoprawna (wartości za wysokie). Dla poprawnej klasy                                                     
 3 Niniejszy fragment sylabusa dotyczy sytuacji, w której przypadek testowy zawiera rozważane jednocześnie wartości z kilku klas równoważności pochodzących z różnych podziałów jednej lub kilku dziedzin (przyp. tłum.) równoważności wartości brzegowe to 1 i 5. Dla niepoprawnej klasy równoważności (za wysokie) wartości brzegowe to 6 i 9. Dla niepoprawnej klasy równoważności (za niskie) jest tylko jedna wartość brzegowa 0, ponieważ jest to klasa z jednym tylko przedstawicielem. 
W powyższym przykładzie identyfikujemy dwie wartości brzegowe do przetestowania dla każdej granicy pomiędzy sąsiadującymi klasami. Granica pomiędzy klasą niepoprawną (za niskie) a poprawną daje dane testowe 0 i 1. Granica pomiędzy klasą poprawną i niepoprawną (za wysokie) daje dane testowe 5 i 6. 
Pewna odmiana tej techniki identyfikuje trzy wartości do przetestowania dla zadanej wartości brzegowej: wartość leżącą tuż przed wartością brzegową, wartość brzegową i wartość leżącą tuż za wartością brzegową. Jeśli rozpatrujemy poprawną klasę równoważności z poprzedniego przykładu, wartości testowe dla dolnej wartości brzegowej wynoszą 0, 1 i 2, a wartości testowe dla górnej wartości brzegowej — 4, 5 i 6 [Jorgensen 2014].
Niepoprawne zachowanie jest bardziej prawdopodobne dla wartości brzegowych klas równoważności niż dla wartości z wnętrza klasy. Należy pamiętać, że zarówno wyspecyfikowane, jak i zaimplementowane wartości brzegowe, mogą zostać przesunięte powyżej lub poniżej zamierzonego położenia lub całkowicie pominięte, a ponadto mogą wystąpić niechciane nadmiarowe wartości brzegowe. Analiza wartości brzegowych i ich testowanie pozwala wykryć niemal wszystkie takie defekty, ponieważ pozwala na wykazanie w oprogramowaniu zachowań z klasy równoważności innej niż klasa, do której powinna należeć wartość brzegowa.
Analizę wartości brzegowych można stosować na wszystkich poziomach testów. Technika ta służy zwykle do testowania wymagań, które odwołują się do przedziału liczb (włączając w to daty i godziny). Pokrycie wartości brzegowych danej klasy mierzy się jako iloraz liczby przetestowanych wartości brzegowych przez łączną liczbę zidentyfikowanych wartości brzegowych, zazwyczaj wyrażony w procentach4.
4.2.3. Testowanie w oparciu o tablicę decyzyjną Przy testowaniu implementacji wymagań systemowych, które określają, w jaki sposób różne kombinacje warunków powodują uzyskanie różnych wyników, przydatne są techniki kombinatoryczne. Jednym z podejść wykorzystujących tego typu technikę jest testowanie w oparciu o tablicę decyzyjną.
Tablice decyzyjne są dobrym sposobem na modelowanie złożonych reguł biznesowych, które muszą zostać zaimplementowane w systemie. Opracowując tablice decyzyjne, tester identyfikuje warunki (zazwyczaj dane wejściowe) i wynikające z nich akcje (zazwyczaj dane wyjściowe) systemu. Tworzą one wiersze tablicy, przy czym warunki znajdują się zwykle u góry, a akcje — na dole. Każda kolumna odpowiada regule decyzyjnej, która określa unikatową kombinację warunków powodującą wykonanie akcji związanych z tą regułą. Wartości warunków i akcji przedstawia się zwykle jako wartości logiczne (prawda/fałsz) lub dyskretne (np. czerwony, zielony, niebieski), ale mogą one mieć również postać liczb lub przedziałów liczb. W tej samej tabeli mogą występować różne typy warunków i akcji.
Poniżej przedstawiono typową notację stosowaną w tablicach decyzyjnych.
Warunki:
• „T” oznacza, że warunek został spełniony (spotykane są również oznaczenia „P” i „1”).
• „N” oznacza, że warunek nie został spełniony (spotykane są również oznaczenia „F” i „0”).
                                                    
 4 W przypadku wspomnianej wcześniej odmiany „trójpunktowej" metryka pokrycia uwzględnia nie tylko wartości brzegowe, ale również wszystkie wartości do przetestowania, mimo, że niektóre z nich formalnie nie są wartościami brzegowymi — np. wartości 2 i 4 z cytowanego wyżej przykładu. (przyp. tłum.).
• „—” oznacza, że wartość warunku nie ma znaczenia (spotykane jest również oznaczenie „nd”).
Akcje:
• „X” oznacza, że akcja powinna zostać wykonana (spotykane są również oznaczenia „T”, „P” i „1”).
• Puste pole oznacza, że akcja nie powinna zostać wykonana (spotykane są również oznaczenia „N”, „F” i „0”).
Pełna tablica decyzyjna zawiera tyle kolumn, ile jest niezbędne do pokrycia wszystkich kombinacji warunków. Tablicę można zredukować poprzez usunięcie kolumn zawierających kombinacje warunków niemożliwe do spełnienia, kolumny zawierające możliwe, ale niewykonalne kombinacje warunków oraz kolumn służących do testowania kombinacji warunków, które nie mają wpływu na wynik. Więcej informacji na temat minimalizowania tablic decyzyjnych zawiera sylabus [ISTQB® ATA].
Minimalnym wymogiem dotyczącym pokrycia w przypadku testowania w oparciu o tablicę decyzyjną jest zazwyczaj utworzenie co najmniej jednego przypadku testowego dla każdej reguły decyzyjnej w tablicy. Zwykle wiąże się to z koniecznością pokrycia wszystkich kombinacji warunków. Pokrycie jest mierzone jako iloraz liczby warunków przetestowanych przez przynajmniej jeden przypadek testowy przez liczbę wszystkich reguł, zazwyczaj wyrażony w procentach. 
Atutem testowania w oparciu o tablicę decyzyjną jest możliwość zidentyfikowania wszystkich ważnych, istotnych kombinacji warunków, które w innym przypadku mogłyby zostać przeoczone. Ponadto metoda ta pomaga znaleźć ewentualne luki w wymaganiach. Można ją stosować we wszystkich sytuacjach, w których zachowanie oprogramowania zależy od kombinacji warunków oraz na dowolnym poziomie testów.
4.2.4. Testowanie przejść pomiędzy stanami Moduł lub system mogą różnie reagować na dane wejściowe w zależności od warunków bieżących lub historycznych (np. zdarzeń, które wystąpiły od momentu uruchomienia systemu). Historię dotychczasowych zdarzeń można przedstawiać przy pomocy pojęcia stanu. Do zobrazowania możliwych stanów oprogramowania oraz przejść między nimi służy diagram przejść między stanami. Przejście inicjowane jest przez zdarzenie (np. wprowadzenie przez użytkownika wartości w pole). Wynikiem zdarzenia jest przejście ze stanu do stanu. Jeżeli to samo zdarzenie może skutkować dwoma lub więcej przejściami z tego samego stanu, to zdarzenie to może być dodatkowo uwarunkowane tzw. warunkiem dozoru. Rezultatem zmiany stanu może być akcja oprogramowania (np. wyświetlenie wyniku lub komunikatu błędu). 
Tabela przejść między stanami zawiera wszystkie poprawne przejścia między stanami (a potencjalnie również przejścia niepoprawne) oraz zdarzenia, warunki dozoru i akcje związane z poprawnymi przejściami. Diagramy przejść5 między stanami przedstawiają zwykle tylko poprawne przejścia, nie zawierają natomiast przejść niepoprawnych.
Testy przejść między stanami można zaprojektować w sposób zapewniający pokrycie typowej sekwencji stanów, przetestowanie wszystkich stanów bądź przetestowanie wszystkich przejść, konkretnych sekwencji przejść lub przejść niepoprawnych.
Technikę testowania przejść między stanami stosuje się w przypadku aplikacji wyposażonych w menu. Jest ona również rozpowszechniona w branży oprogramowania wbudowanego. Ponadto technika ta nadaje się do modelowania scenariuszy biznesowych zawierających określone stany oraz
                                                    
 5 Diagram przejść jest graficzną prezentacją tabeli przejść (przyp. tłum.).
do testowania sposobu poruszania się (nawigacji) po ekranach. Pojęcie stanu ma charakter abstrakcyjny i może odpowiadać zarówno kilku wierszom kodu, jak i całemu procesowi biznesowemu.
Pokrycie zwykle mierzy się jako iloraz liczby przetestowanych stanów lub przejść między stanami przez łączną liczbę zidentyfikowanych stanów lub przejść w przedmiocie testów, zazwyczaj wyrażony w procentach. Więcej informacji na temat kryteriów pokrycia dotyczących testowania przejść między stanami można znaleźć w [ISTQB® ATA], a także w [Roman 2015].
4.2.5. Testowanie oparte na przypadkach użycia Testy można wyprowadzać z przypadków użycia (opisujących interakcję z elementami oprogramowania), weryfikując wymagania dla funkcjonalności reprezentowanych przez te przypadki. Z przypadkami użycia związane są pojęcia „aktorów” (tj. użytkowników, urządzeń zewnętrznych bądź innych modułów lub systemów) oraz „podmiotów” (moduł lub system, do którego przypadek użycia jest zastosowany).
Każdy przypadek użycia określa konkretne działanie (zachowanie), które podmiot może wykonywać we współpracy z jednym lub kilkoma aktorami (UML 2.5.1 2017). Przypadki użycia można opisywać w kategoriach interakcji i działań, warunków wstępnych bądź warunków wyjściowych, a jeśli wymagają tego okoliczności — również w języku naturalnym. Interakcje między aktorami a podmiotem mogą powodować zmianę stanu podmiotu. Do odwzorowywania takich interakcji można użyć graficznych modeli przepływów pracy (ang. workflow), diagramów aktywności lub modeli procesów biznesowych.
Przypadek użycia może obejmować potencjalne odmiany podstawowego zachowania, zachowania wyjątkowe i mechanizmy obsługi błędów (odpowiedź systemu i ewentualnie odtworzenie go po wystąpieniu awarii wynikającej z pomyłki, defektu w aplikacji lub błędu komunikacji np. skutkującego komunikatem błędu). Testy projektuje się tak, aby umożliwiały sprawdzenie wszystkich zdefiniowanych zachowań (tj. zachowania podstawowego, wyjątkowego  — zwanego też alternatywnym — oraz obsługę błędów). Pokrycie można mierzyć procentowo jako iloraz liczby przetestowanych zachowań przypadków użycia przez łączną liczbę zachowań przypadków użycia. 
Więcej informacji na temat kryteriów pokrycia dotyczących testowania opartego na przypadkach użycia można znaleźć w [ISTQB® ATA], a także w [Roman 2015].
4.3. Białoskrzynkowe techniki testowania
Testowanie białoskrzynkowe opiera się na strukturze wewnętrznej przedmiotu testów. Techniki testowania białoskrzynkowego mogą być stosowane na wszystkich poziomach testów, jednakże dwie techniki związane z kodem, które omówiono w tym podrozdziale, najczęściej stosuje się na poziomie testów modułowych. Istnieją również bardziej zaawansowane techniki, których używa się w systemach krytycznych ze względów bezpieczeństwa, w systemach o newralgicznym znaczeniu dla działalności przedsiębiorstwa oraz w środowiskach wymagających wysokiego poziomu integralności (w celu uzyskania pełniejszego pokrycia), ale nie są one przedmiotem tego opracowania.
Więcej informacji na temat tych technik można znaleźć w [ISTQB® ATTA] oraz w [Roman 2015].
4.3.1. Testowanie i pokrycie instrukcji kodu Testowanie instrukcji służy do sprawdzania wykonywalnych instrukcji zawartych w kodzie. Pokrycie mierzy się procentowo jako iloraz liczby instrukcji wykonanych przez testy przez łączną liczbę instrukcji wykonywalnych w przedmiocie testów, zazwyczaj wyrażany w procentach.
4.3.2. Testowanie i pokrycie decyzji Testowanie decyzji służy do sprawdzania decyzji zawartych w kodzie oraz kodu wykonywanego na podstawie wyników decyzji. W tym celu tworzy się przypadki testowe, które odzwierciedlają przepływy sterowania występujące po punkcie decyzyjnym. W przypadku instrukcji IF tworzy się jeden przypadek dotyczący spełnienia warunku i jeden przypadek dotyczący niespełnienia warunku, a w przypadku instrukcji CASE niezbędne są przypadki testowe odpowiadające wszystkim możliwym wynikom, włącznie z wynikiem domyślnym.
Pokrycie mierzy się procentowo jako iloraz liczby wyników decyzji wykonanych przez testy przez łączną liczbę możliwych wyników decyzji w przedmiocie testów.
4.3.3. Korzyści wynikające z testowania instrukcji i testowania decyzji Uzyskanie stuprocentowego pokrycia instrukcji kodu gwarantuje, że wszystkie instrukcje wykonywalne zawarte w kodzie zostały przetestowane co najmniej raz, nie gwarantuje natomiast, że przetestowana została cała logika decyzyjna. Jeśli chodzi o techniki białoskrzynkowe omówione w tym sylabusie, testowanie instrukcji kodu może zapewnić mniejsze pokrycie niż testowanie decyzji.
Uzyskanie stuprocentowego pokrycia decyzji oznacza, że wykonano wszystkie wyniki decyzji, czyli przetestowano zarówno wyniki „prawda”, jak i wyniki „fałsz” — nawet jeśli instrukcja warunkowa nie zawiera bloku instrukcji odpowiadającego decyzji „fałsz" (np. IF bez bloku ELSE). Pokrycie instrukcji kodu pomaga znaleźć defekty w kodzie, który nie został przetestowany przy użyciu innych testów, a pokrycie decyzji — w kodzie, w przypadku którego w innych testach nie uwzględniono wszystkich możliwych wyników decyzji.
Uzyskanie stuprocentowego pokrycia decyzji gwarantuje stuprocentowe pokrycie instrukcji kodu (ale nie odwrotnie).
4.4. Techniki testowania oparte na doświadczeniu
W ramach technik opartych na doświadczeniu przypadki testowe projektuje się z wykorzystaniem umiejętności i intuicji testerów oraz ich doświadczenia z podobnymi aplikacjami i technologiami. Techniki te pomagają w identyfikowaniu przypadków testowych, które trudno jest zidentyfikować przy użyciu innych, bardziej usystematyzowanych technik. Z drugiej strony uzyskany poziom pokrycia i skuteczność mogą bardzo różnić się w zależności od podejścia i doświadczenia testera — w pewnych przypadkach pokrycie może być trudne do oszacowania, a nawet niemożliwe do zmierzenia.
W kolejnych punktach omówiono najczęściej stosowane techniki oparte na doświadczeniu.
4.4.1. Zgadywanie błędów Zgadywanie błędów6 to technika pozwalająca przewidywać wystąpienie pomyłek, defektów i awarii na podstawie wiedzy testera dotyczącej między innymi:
• dotychczasowego działania aplikacji;
• typowych pomyłek popełnianych przez programistów;
                                                    
 6 Formalnie rzecz ujmując, trzymając się terminologii ISTQB®, ten typ techniki powinien nazywać się „zgadywaniem defektów", ale pozostawiamy nazwę „zgadywanie błędów" ze względu na historyczne uwarunkowania (przyp. tłum.).
• awarii, które wystąpiły w innych aplikacjach.
Metodyczne podejście do zgadywania błędów polega na stworzeniu listy potencjalnych pomyłek, defektów i awarii, a następnie zaprojektowaniu testów pozwalających uwidocznić te awarie i defekty, które je spowodowały. Listy pomyłek, defektów i awarii można opracowywać na podstawie własnego doświadczenia, danych dotyczących defektów i awarii oraz powszechnej wiedzy na temat przyczyn awarii oprogramowania.
4.4.2. Testowanie eksploracyjne Testowanie eksploracyjne polega na projektowaniu, wykonywaniu i rejestrowaniu testów nieformalnych (tj. testów, które nie zostały wcześniej zaprojektowane) oraz dokonywaniu ich oceny w sposób dynamiczny podczas wykonywania. Rezultaty testów dostarczają wiedzy na temat modułu lub systemu, a także pomagają tworzyć testy dotyczące obszarów wymagających dalszego przetestowania.
Testowanie eksploracyjne jest czasami przeprowadzane w formie tzw. testowania w sesjach, na potrzeby ustrukturyzowania aktywności. W testowaniu w sesjach, testowanie eksploracyjne odbywa się w ściśle określonym przedziale czasu, a tester może udokumentować wykonane kroki i uzyskane informacje w arkuszu sesji testowej.
Testowanie eksploracyjne jest najbardziej przydatne w przypadku niepełnych lub niewłaściwie sporządzonych specyfikacji bądź w przypadku testowania pod presją czasu. Ponadto może być uzupełnieniem innych, bardziej formalnych technik testowania.
Testowanie eksploracyjne jest mocno związane z reaktywną strategią testowania (zobacz p. 5.2.2.). W ramach testowania eksploracyjnego można korzystać z innych technik czarnoskrzynkowych, białoskrzynkowych i opartych na doświadczeniu.
4.4.3. Testowanie w oparciu o listę kontrolną W testowaniu w oparciu o listę kontrolną tester projektuje, implementuje i uruchamia testy tak, aby pokryć warunki testowe znalezione w liście kontrolnej. Podczas analizy tester tworzy nowe listy kontrolne lub rozszerza istniejące, ale może również użyć gotowych list kontrolnych bez ich modyfikacji. Listy kontrolne można opracowywać na podstawie własnego doświadczenia, danych dotyczących potencjalnych defektów i awarii, znajomości oczekiwań użytkowników lub wiedzy na temat przyczyn i objawów awarii oprogramowania.
Listy kontrolne można tworzyć na potrzeby różnych typów testów, w tym na potrzeby testów funkcjonalnych i niefunkcjonalnych. W przypadku braku szczegółowych przypadków testowych testowanie w oparciu o listę kontrolną zapewnia niezbędne wytyczne i pozwala uzyskać pewien stopień spójności procesu testowania. Listy mają charakter wysokopoziomowy, w związku z czym podczas faktycznego testowania może występować pewna zmienność przekładająca się na większe pokrycie, ale kosztem mniejszej powtarzalności.

Testowanie statyczne — 135 min.
Słowa kluczowe analiza statyczna, czytanie oparte na perspektywie, inspekcja, przegląd, przegląd ad hoc przegląd formalny, przegląd nieformalny, przegląd oparty na liście kontrolnej, przegląd oparty na rolach,przegląd oparty na scenariuszach, przegląd techniczny, , przejrzenie, testowanie dynamiczne, testowanie statyczne
 
Cele nauczania — testowanie statyczne 3.1. Podstawy testowania statycznego FL-3.1.1. (K1) Kandydat potrafi rozpoznać typy produktów pracy związanych z oprogramowaniem, które mogą być badane przy użyciu poszczególnych technik testowania statycznego. FL-3.1.2. (K2) Kandydat potrafi opisać (podając przykłady) wartość testowania statycznego. FL-3.1.3. (K2) Kandydat potrafi wyjaśnić różnicę między technikami testowania statycznego a technikami testowania dynamicznego z uwzględnieniem celów, typów identyfikowanych defektów oraz roli tych technik w cyklu życia oprogramowania. 3.2. Proces przeglądu FL-3.2.1. (K2) Kandydat potrafi podsumować czynności wykonywane w ramach procesu przeglądu produktów pracy. FL-3.2.2.  (K1) Kandydat potrafi rozpoznać poszczególne role i obowiązki w przeglądzie formalnym. FL-3.2.3. (K2) Kandydat potrafi wyjaśnić różnice między poszczególnymi typami przeglądów: przeglądem nieformalnym, przejrzeniem, przeglądem technicznym i inspekcją. FL-3.2.4. (K3) Kandydat potrafi zastosować technikę przeglądu do produktu pracy w celu wykrycia defektów. FL-3.2.5. (K2) Kandydat potrafi wyjaśnić, jakie czynniki decydują o powodzeniu przeglądu.

3.1. Podstawy testowania statycznego
W przeciwieństwie do testowania dynamicznego, które wymaga uruchomienia testowanego oprogramowania, testowanie statyczne opiera się na ręcznym badaniu produktów pracy (tj. wykonywaniu przeglądów) bądź dokonywaniu oceny kodu przy użyciu odpowiednich narzędzi lub innych produktów pracy (tj. analizie statycznej). Oba typy testowania statycznego pozwalają ocenić testowany kod lub inny produkt pracy bez jego uruchamiania.
Analiza statyczna jest szczególnie ważna w przypadku systemów komputerowych krytycznych ze względów bezpieczeństwa (np. systemów stosowanych w lotnictwie, medycynie lub w energetyce jądrowej), ale staje się też coraz bardziej istotna i powszechnie stosowana w innych kontekstach (analiza taka jest np. ważnym elementem testowania zabezpieczeń). Ponadto analiza statyczna jest często elementem automatycznych systemów budowy i dostarczania stosowanych w modelach zwinnego wytwarzania oprogramowania, ciągłego dostarczania i ciągłego wdrażania.
3.1.1. Produkty pracy badane metodą testowania statycznego Przy użyciu technik testowania statycznego (tj. przeglądów i/lub analizy statycznej) można zbadać niemal wszystkie produkty pracy, na przykład:
• specyfikacje (w tym: wymagania biznesowe, wymagania funkcjonalne i wymagania w zakresie bezpieczeństwa);
• opowieści, historyjki użytkownika i kryteria akceptacji;
• architekturę i specyfikacje projektowe;
• kod;
• testalia (w tym: plany testów, procedury testowe, przypadki testowe i skrypty testów automatycznych);
• podręczniki użytkownika;
• strony internetowe;
• umowy, plany projektów, harmonogramy i budżety;
• modele takie jak diagramy aktywności, które mogą być używane do testowania opartego na modelu (patrz [ISTQB® MBT] i [Kramer 2016]).
Przeglądy mogą dotyczyć dowolnego produktu pracy, który uczestnicy potrafią przeczytać i zrozumieć. Z kolei analizę statyczną można zastosować efektywnie do każdego produktu pracy o strukturze formalnej (w typowych sytuacjach to kod lub modele), dla którego istnieje odpowiednie narzędzie do jej przeprowadzenia. Dostępne są również narzędzia pozwalające oceniać produkty pracy napisane w języku naturalnym takie jak wymagania (np. sprawdzające te produkty pracy pod kątem pisowni, gramatyki czy też czytelności).
3.1.2. Zalety testowania statycznego Techniki testowania statycznego dostarczają wielu korzyści. W przypadku ich stosowania w początkowym etapie cyklu życia oprogramowania, pozwalają one wykryć defekty jeszcze przed rozpoczęciem testowania dynamicznego (np. w ramach przeglądów specyfikacji wymagań lub projektu bądź doprecyzowywania listy zaległości produktowych). Usunięcie defektów wykrytych w początkowym etapie cyklu życia jest często dużo tańsze niż usunięcie defektów wykrytych w kolejnych etapach — zwłaszcza po wdrożeniu oprogramowania i rozpoczęciu jego eksploatacji.
Zastosowanie technik testowania statycznego do wykrywania defektów i ich niezwłocznego usuwania jest prawie zawsze dużo tańsze niż wykrywanie defektów w przedmiocie testów i ich usuwanie metodą testowania dynamicznego, szczególnie jeżeli weźmie się pod uwagę dodatkowe koszty związane z aktualizacją pozostałych produktów pracy oraz testowaniem potwierdzającym i testowaniem regresji.
Wśród dodatkowych zalet testowania statycznego wymienić można:
• efektywne wykrywanie i usuwanie defektów jeszcze przed wykonaniem testów dynamicznych;
• identyfikowanie defektów, które trudno jest wykryć metodą testowania dynamicznego;
• zapobieganie wystąpieniu defektów w projekcie i kodzie poprzez wykrywanie niedociągnięć takich jak: niespójności, niejednoznaczności, wewnętrzne sprzeczności, nieścisłości, przeoczenia, opuszczenia czy też elementy nadmiarowe w wymaganiach;
• zwiększenie wydajności prac programistycznych między innymi dzięki udoskonaleniom projektowania i utrzymywalności kodu;
• obniżenie kosztów i zmniejszenie czasochłonności wytwarzania oprogramowania;
• obniżenie kosztów i zmniejszenie czasochłonności testowania;
• obniżenie łącznego kosztu zapewnienia jakości w całym cyklu życia oprogramowania poprzez zmniejszenie liczby awarii na późniejszych etapach tego cyklu lub po przekazaniu oprogramowania do eksploatacji;
• usprawnienie komunikacji pomiędzy członkami zespołu uczestniczącymi w przeglądach.
3.1.3. Różnice między testowaniem statycznym a dynamicznym Testowanie statyczne i testowanie dynamiczne mogą mieć te same cele (patrz p. 1.1.1.), takie jak dokonywanie oceny jakości produktów pracy czy jak najwcześniejsze identyfikowanie defektów. Czynności te uzupełniają się wzajemnie, ponieważ umożliwiają wykrywanie różnych typów defektów.
Główna różnica pomiędzy testowaniem statycznym a dynamicznych polega na tym, że testowanie statyczne pozwala wykryć defekty bezpośrednio w produktach pracy, a nie na podstawie spowodowanych przez te defekty awarii zidentyfikowanych podczas uruchamiania oprogramowania. Zdarza się, że defekt w produkcie pracy pozostaje przez bardzo długi czas ukryty, ponieważ nie powoduje awarii. Ścieżka, na której się on znajduje, może być rzadko testowana lub trudno dostępna, przez co nie będzie łatwo zaprojektować i wykonać test dynamiczny, który go wykryje. Testowanie statyczne może znaleźć defekt przy znacznie mniejszym nakładzie pracy.
Kolejna różnica pomiędzy opisanymi powyżej rodzajami testów polega na tym, że testowanie statyczne może być wykorzystywane do zwiększania spójności i wewnętrznej jakości produktów pracy, natomiast testowanie dynamiczne koncentruje się głównie na widocznych z zewnątrz zachowaniach systemu/oprogramowania.
Przykładami typowych defektów, które są łatwiejsze i tańsze do wykrycia oraz usunięcia przy zastosowaniu metody testowania statycznego (niż przy użyciu metody testowania dynamicznego), są między innymi:
• defekty w wymaganiach (takie jak: niespójności, niejednoznaczności, opuszczenia, nieścisłości, przeoczenia, wewnętrzne sprzeczności czy też elementy nadmiarowe w wymaganiach);
• defekty w projekcie (np. nieefektywne algorytmy lub struktury baz danych, wysoki stopień sprzężenia (ang. coupling) czy mała spójność (ang. cohesion);
• defekty w kodzie (np. zmienne z niezdefiniowanymi wartościami, zmienne zadeklarowane — lecz nigdy nie używane, niedostępny (martwy) kod, powielony kod);
• odchylenia od standardów (np. brak zgodności ze standardami tworzenia kodu);
• niepoprawne specyfikacje interfejsów (np. użycie różnych jednostek miary w systemie wywołującym i systemie wywoływanym);
• wrażliwości zabezpieczeń (np. podatność na przepełnienie bufora);
• luki lub nieścisłości w zakresie śledzenia powiązań lub pokrycia (np. brak testów odpowiadających kryteriom akceptacji).
Ponadto tylko testowanie statyczne umożliwia wykrycie większości typów defektów związanych z utrzymywalnością (takich jak: nieprawidłowa modularyzacja, niski poziom ponownego wykorzystania modułów czy występowanie kodu, który trudno jest analizować i modyfikować bez wprowadzania nowych defektów).
3.2. Proces przeglądu
Przeglądy mogą mieć różny charakter: od nieformalnego po formalny. Cechą charakterystyczną przeglądów nieformalnych jest to, że nie przebiegają zgodnie ze zdefiniowanym procesem, a uzyskanych dzięki nim informacji nie trzeba formalnie dokumentować. Z kolei przeglądy formalne są przeprowadzane zgodnie z udokumentowanymi procedurami i z udziałem zespołu o ustalonym wcześniej składzie, a ich rezultaty muszą być obowiązkowo dokumentowane. Stopień sformalizowania przeglądu zależy od takich czynników jak: model cyklu życia oprogramowania, dojrzałość procesu wytwarzania oprogramowania, złożoność produktu pracy będącego przedmiotem przeglądu, wymogi prawne czy konieczność prowadzenia ścieżki audytu.
Przedmiot zainteresowania zależy od uzgodnionych celów przeglądu, takich jak: wykrywanie defektów, poszerzanie wiedzy, edukowanie uczestników (np. testerów i nowych członków zespołu) bądź omawianie określonych zagadnień i podejmowanie decyzji w drodze konsensusu.
Bardziej szczegółowy opis procesu przeglądu produktów pracy (w tym ról i technik związanych z przeglądem) zawiera standard międzynarodowy ISO/IEC 20246.
3.2.1. Proces przeglądu produktów pracy Proces przeglądu obejmuje zwykle następujące czynności:
Planowanie
• Określenie zakresu prac, w tym celu przeglądu i dokumentów (lub ich części) będących jego przedmiotem oraz ocenianych charakterystyk jakościowych.
• Oszacowanie nakładu pracy i ram czasowych.
• Wskazanie cech charakterystycznych przeglądu, takich jak: typ przeglądu, role, czynności i listy kontrolne.
• Wybór osób, które mają wziąć udział w przeglądzie oraz wyznaczenie im ról.
• Określenie kryteriów wejścia i wyjścia (w przypadku bardziej formalnych typów przeglądów np. inspekcji).
• Sprawdzenie, czy zostały spełnione kryteria wejścia (w przypadku bardziej formalnych typów przeglądów).
Rozpoczęcie przeglądu
• Rozesłanie produktu pracy (w formie papierowej lub elektronicznej) oraz innych materiałów (np.: formularzy, dziennika problemów, list kontrolnych i innych powiązanych produktów pracy).
• Wyjaśnienie uczestnikom zakresu, celów, procesu, ról i produktów pracy.
• Udzielenie odpowiedzi na ewentualne pytania uczestników dotyczące przeglądu.
Przegląd indywidualny (tj. indywidualne przygotowanie)
• Dokonanie przeglądu całości lub części produktów pracy.
• Odnotowanie potencjalnych defektów oraz zaleceń i pytań.
Przekazanie informacji o problemach i analiza problemów
• Przekazanie informacji o zidentyfikowanych, potencjalnych defektach (np. na spotkaniu przeglądowym).
• Przeanalizowanie defektów (w tym wyznaczenie osób za nie odpowiedzialnych oraz określenie statusu defektów).
• Dokonanie oceny i udokumentowanie charakterystyk jakościowych.
• Dokonanie oceny wniosków z przeglądu pod kątem kryteriów wyjścia w celu podjęcia decyzji (odrzucenie produktu pracy, wymagane poważne zmiany, akceptacja – być może z niewielkimi zmianami).
Usunięcie defektów i raportowanie
• Utworzenie raportów o defektach dotyczących wykrytych defektów wymagających wprowadzenia zmian.
• Usunięcie defektów wykrytych w produkcie pracy będącym przedmiotem przeglądu (czynność tę zwykle wykonuje autor).
• Poinformowanie odpowiedniej osoby lub odpowiedniego zespołu o defektach wykrytych w produkcie pracy związanym z produktem będącym przedmiotem przeglądu.
• Zarejestrowanie zaktualizowanego statusu defektów (w przypadku przeglądów formalnych), włączając w to potencjalną zgodę autora komentarza.
• Zebranie miar (w przypadku bardziej formalnych typów przeglądów).
• Sprawdzenie, czy zostały spełnione kryteria wyjścia (w przypadku bardziej formalnych typów przeglądów).
• Zaakceptowanie produktu pracy po spełnieniu kryteriów wyjścia.
Rezultaty przeglądu produktu pracy mogą być różne w zależności od typu przeglądu oraz stopnia jego sformalizowania (patrz p. 3.2.3.).
3.2.2. Role i obowiązki w przeglądzie formalnym W typowym przeglądzie formalnym wyróżnia się następujące role:
Autor
• Tworzy produkt pracy będący przedmiotem przeglądu.
• Usuwa defekty w produkcie pracy będącym przedmiotem przeglądu (jeśli jest to konieczne).
Kierownictwo
• Odpowiada za zaplanowanie przeglądu.
• Podejmuje decyzję o przeprowadzeniu przeglądu.
• Wyznacza pracowników oraz określa budżet i ramy czasowe.
• Monitoruje na bieżąco opłacalność przeglądu.
• Wykonuje decyzje kontrolne w przypadku uzyskania niezadowalających wyników.
Facylitator (zwany często moderatorem)
• Dba o sprawny przebieg spotkań związanych z przeglądem (o ile je prowadzi).
• Występuje w roli mediatora, jeśli konieczne jest pogodzenie różnych punktów widzenia.
• Jest często osobą, od której zależy powodzenie przeglądu.
Lider przeglądu
• Ponosi ogólną odpowiedzialność za przegląd.
• Decyduje o tym, kto ma wziąć udział w przeglądzie oraz określa miejsce i termin przeglądu.
Przeglądający
• Mogą być ekspertami merytorycznymi, osobami pracującymi przy projekcie, interesariuszami zainteresowanymi produktem pracy i/lub osobami mającymi określone doświadczenie techniczne lub biznesowe.
• Identyfikują potencjalne defekty w produkcie pracy będącym przedmiotem przeglądu.
• Mogą reprezentować różne punkty widzenia (np. punkt widzenia testera, programisty, użytkownika, operatora, analityka biznesowego, specjalisty ds. użyteczności itd.).
Protokolant
• Gromadzi informacje o potencjalnych defektach wykryte w ramach przeglądu indywidualnego.
• Rejestruje nowe potencjalne defekty, otwarte punkty i decyzje podczas spotkania związanego z przeglądem (gdy ma ono miejsce).
W przypadku niektórych typów przeglądów jedna osoba może pełnić kilka ról. W zależności od typu przeglądu mogą również różnić się czynności przypisane do poszczególnych ról. Ponadto w związku z pojawieniem się narzędzi wspomagających proces przeglądu (a zwłaszcza rejestrowanie defektów, otwartych punktów i decyzji), często nie ma potrzeby wyznaczania protokolanta.
Oprócz ról opisanych powyżej mogą również występować bardziej szczegółowe role opisane w standardzie ISO/IEC 20246.
3.2.3. Typy przeglądów Przeglądy mogą być przeprowadzane w różnych celach, ale jednym z głównych celów każdego przeglądu jest ujawnienie defektów. W wykryciu defektów mogą pomóc przeglądy wszystkich typów.
Odpowiedni typ przeglądu należy wybrać na podstawie potrzeb projektu, dostępnych zasobów, typu produktu i związanych z nim czynników ryzyka, dziedziny biznesowej, kultury korporacyjnej i innych kryteriów.
Przeglądy mogą być klasyfikowane według różnych atrybutów. Poniżej wymieniono cztery najczęściej występujące typy przeglądów wraz z odpowiadającymi im atrybutami.
Przegląd nieformalny (np. sprawdzenie koleżeńskie, przegląd w parach)
• Cel główny: wykrycie potencjalnych defektów.
• Potencjalny cel dodatkowy: wygenerowanie nowych pomysłów lub rozwiązań, szybkie rozwiązywanie problemów mniejszej wagi.
• Przegląd nie odbywa się zgodnie z formalnym (udokumentowanym) procesem.
• Przegląd nie musi obejmować spotkania.
• Przegląd może zostać przeprowadzony przez współpracownika autora (sprawdzenie koleżeńskie) lub przez grupę osób.
• Rezultaty przeglądu mogą zostać udokumentowane.
• Przydatność przeglądu zależy od przeglądających.
• Używanie list kontrolnych jest opcjonalne.
• Ten typ przeglądu jest powszechnie używany w przypadku zwinnego wytwarzania oprogramowania.
Przejrzenie
• Cele główne: wykrycie potencjalnych defektów, podniesienie jakości oprogramowania, rozważenie alternatywnych implementacji, dokonanie oceny zgodności z normami/standardami i specyfikacjami.
• Potencjalne cele dodatkowe: wymiana informacji na temat technik lub odmian stylów, przeszkolenie uczestników, osiągnięcie konsensusu.
• Indywidualne przygotowanie przed spotkaniem związanym z przeglądem jest opcjonalne.
• Spotkanie związane z przeglądem prowadzi zwykle autor produktu pracy.
• Wymagany jest udział protokolanta.
• Używanie list kontrolnych jest opcjonalne.
• Przegląd może mieć formę scenariuszy, przebiegów próbnych („na sucho”) lub symulacji.
• Mogą być tworzone dzienniki potencjalnych defektów i raporty z przeglądu.
• Charakter przeglądu może być w praktyce różny — od raczej nieformalnego po bardzo formalny.
Przegląd techniczny
• Cele główne: uzyskanie konsensusu, wykrycie potencjalnych defektów.
• Potencjalne cele dodatkowe: dokonanie oceny jakości produktu pracy i zwiększenie zaufania do niego, wygenerowanie nowych pomysłów, zmotywowanie autorów do udoskonalania przyszłych produktów pracy i stworzenie im warunków do tego, rozważenie alternatywnych rozwiązań.
• Przeglądający powinni mieć takie same kompetencje techniczne jak autor oraz powinni być ekspertami technicznymi w tej samej dyscyplinie lub w innych dyscyplinach.
• Indywidualne przygotowanie przed spotkaniem związanym z przeglądem jest obowiązkowe.
• Spotkanie związane z przeglądem jest opcjonalne, powinien je w miarę możliwości prowadzić przeszkolony facylitator (zwykle nie jest nim autor).
• Wymagany jest udział protokolanta (w miarę możliwości nie powinien nim być autor).
• Korzystanie z list kontrolnych jest opcjonalne.
• Na ogół są tworzone: dziennik potencjalnych defektów i raporty z przeglądu.
Inspekcja
• Cele główne: wykrycie potencjalnych defektów, dokonanie oceny jakości produktu pracy i zwiększenie zaufania do niego, zapobieganie wystąpieniu w przyszłości podobnych defektów poprzez przekazanie wniosków autorowi i przeprowadzenie analizy przyczyny podstawowej.
• Potencjalne cele dodatkowe: zmotywowanie autorów do udoskonalania przyszłych produktów pracy oraz procesu wytwarzania oprogramowania i stworzenie im warunków do tego, osiągnięcie konsensusu.
• Przegląd odbywa się zgodnie ze zdefiniowanym procesem opartym na regułach i listach kontrolnych, a rezultaty są formalnie dokumentowane.
• Występują jednoznacznie zdefiniowane role (takie jak obowiązkowe role określone w p. 3.2.2.), a ponadto może być wymagane wyznaczenie konkretnej osoby czytającej (która głośno czyta produkt pracy podczas spotkania przeglądowego).
• Indywidualne przygotowanie przed spotkaniem związanym z przeglądem jest obowiązkowe.
• Przeglądającymi są osoby zajmujące stanowiska równorzędne do autora lub eksperci w innych dyscyplinach istotnych z punktu widzenia produktu pracy.
• Obowiązują określone kryteria wejścia i wyjścia.
• Obecność protokolanta jest obowiązkowa.
• Przegląd prowadzi przeszkolony facylitator (nie jest nim autor).
• Autor nie może być liderem przeglądu, osobą czytającą ani protokolantem.
• Mogą być tworzone dzienniki potencjalnych defektów i raporty z przeglądu.
• Zbierane są miary wykorzystywane następnie do udoskonalania całego procesu wytwarzania oprogramowania (w tym procesu inspekcji).
Produkt pracy może być przedmiotem więcej niż jednego typu przeglądu, a w przypadku przeprowadzania kilku przeglądów różnych typów ich kolejność może być różna — np. przed przeglądem technicznym może zostać przeprowadzony przegląd nieformalny, by upewnić się, że produkt pracy jest gotowy do przeglądu technicznego.
Wszystkie typy przeglądów mogą być realizowane jako przeglądy koleżeńskie, czyli przeprowadzane przez współpracowników pracujących na zbliżonym szczeblu organizacyjnym.
Typy defektów znalezionych w przeglądach są różne, zależą w szczególności od przeglądanego produktu pracy. Przykłady defektów, które można znaleźć w przeglądach różnych produktów pracy, zostały opisane w p. 3.1.3., zaś informacje na temat inspekcji formalnych można znaleźć w [Gilb 1993].
3.2.4 Stosowanie technik przeglądu Istnieje kilka różnych technik, z których można skorzystać podczas przeglądu indywidualnego (tj.  indywidualnego przygotowania) przeprowadzanego w celu wykrycia defektów. Techniki te można stosować w ramach wszystkich opisanych powyżej typów przeglądów, jednak ich skuteczność może różnić się w zależności od wybranego typu przeglądu. Poniżej przedstawiono przykładowe techniki przeglądu indywidualnego w kontekście różnych typów przeglądów.
Przegląd ad hoc
Podczas przeglądu ad hoc przeglądający otrzymują niewiele wskazówek dotyczących sposobu wykonywania zadania (lub nie otrzymują ich wcale). Uczestnicy często czytają produkt pracy sekwencyjnie, na bieżąco identyfikując i dokumentując stwierdzone problemy. Przegląd ad hoc to powszechnie stosowana technika, której stosowanie nie wymaga intensywnych przygotowań. Powodzenie przeglądu zależy w dużej mierze od umiejętności przeglądających. Ponadto technika ta wiąże się z ryzykiem wielokrotnego zgłaszania tych samych problemów przez różnych przeglądających.
Przegląd oparty na liście kontrolnej
Przegląd oparty na liście kontrolnej to usystematyzowana technika, zgodnie z którą przeglądający wykrywają problemy na podstawie list kontrolnych rozsyłanych w momencie rozpoczęcia przeglądu (np. przez facylitatora). Lista kontrolna przeglądu zawiera zestaw pytań odpowiadających potencjalnym defektom wskazanym na podstawie dotychczasowych doświadczeń. Listy kontrolne powinny być dostosowane do specyfiki produktu pracy będącego przedmiotem przeglądu i regularnie aktualizowane w celu uwzględnienia typów problemów, które zostały pominięte w poprzednich przeglądach. Najważniejszą zaletą techniki opartej na listach kontrolnych jest systematyczne pokrycie najczęściej występujących typów defektów. Należy jednak pamiętać, że przegląd indywidualny nie powinien ograniczać się do wykonania czynności z listy kontrolnej. Ważne jest również szukanie defektów, które nie zostały w niej uwzględnione.
Scenariusze i przebiegi próbne
Podczas przeglądu opartego na scenariuszach przeglądający otrzymują ustrukturyzowane wytyczne dotyczące sposobu zapoznawania się z produktem pracy. Podejście oparte na scenariuszach umożliwia przeglądającym wykonywanie przebiegów próbnych takich produktów zgodnie z ich przewidywanym zastosowaniem (jeśli produkty pracy są udokumentowane w odpowiednim formacie np. jako przypadki użycia). Dzięki scenariuszom przeglądający mogą skuteczniej identyfikować określone typy defektów niż przy użyciu prostych list kontrolnych. Podobnie jak w przypadku przeglądów opartych na listach kontrolnych, przeglądający nie powinni ograniczać się do udokumentowanych scenariuszy, ponieważ grozi to pominięciem innych typów defektów (takich jak brakujące funkcjonalności).
Przegląd oparty na rolach
Przegląd oparty na rolach to technika, w której recenzenci oceniają produkt pracy z perspektywy poszczególnych ról przypisanych interesariuszom. Typowe role obejmują konkretne typy
użytkowników końcowych (doświadczonych, niedoświadczonych, starszych, dzieci itp.) oraz określone funkcje w organizacji (użytkownik, administrator, administrator systemu, tester wydajności itp.).
Czytanie oparte na perspektywie
W przypadku czytania opartego na perspektywie, podobnie jak w przypadku przeglądu opartego na rolach, przeglądający przyjmują podczas przeglądu indywidualnego punkty widzenia różnych interesariuszy (zwykle są to punkty widzenia użytkownika, pracownika działu marketingu, projektanta, testera lub operatora). Uwzględnienie punktów widzenia różnych interesariuszy umożliwia bardziej wnikliwe przeprowadzenie przeglądu indywidualnego, a także pozwala uniknąć wielokrotnego zgłaszania tych samych problemów przez różnych przeglądających. 
Ponadto czytanie oparte na perspektywie wymaga również od przeglądających, aby spróbowali wykorzystać produkt pracy podlegający przeglądowi do wygenerowania produktu, który się da z niego wyprowadzić. Przykładem takiego wykorzystania produktu pracy jest podjęcie przez testera próby wygenerowania wersji roboczych testów akceptacyjnych, jeśli przeprowadzi przegląd specyfikacji wymagań oparty na perspektywie, aby sprawdzić, czy zawiera wszystkie niezbędne informacje. Ponadto w czytaniu opartym na perspektywie oczekuje się użycia list kontrolnych.
Badania empiryczne wykazały, że czytanie oparte na perspektywie jest zazwyczaj najskuteczniejszą techniką przeglądu wymagań i produktów pracy o charakterze technicznym. Kluczowym czynnikiem sukcesu jest uwzględnienie i wyważenie punktów widzenia poszczególnych interesariuszy w sposób adekwatny do ryzyka. 
Więcej szczegółowych informacji na temat czytania opartego na perspektywie można znaleźć w [Shul 2000], a informacji na temat skuteczności różnych rodzajów przeglądów w [Sauer 2000].
3.2.5. Czynniki powodzenia związane z przeglądami Kluczem do pomyślnego przeprowadzenia przeglądu jest staranny dobór typu przeglądu i stosowanych technik. Ponadto należy uwzględnić wiele innych czynników, które mogą mieć wpływ na uzyskany wynik.
Do czynników sukcesu o charakterze organizacyjnym zaliczają się między innymi następujące kryteria:
• każdy przegląd ma jednoznaczne cele zdefiniowane podczas planowania, które wykorzystuje się jako mierzalne kryteria wyjścia;
• stosowane typy przeglądów sprzyjają osiągnięciu założonych celów, a także są adekwatne do typu i poziomu produktów pracy związanych z oprogramowaniem oraz do poziomu wiedzy i doświadczenia uczestników;
• stosowane są różne techniki przeglądu (takie jak przegląd oparty na listach kontrolnych lub oparty na rolach), które pozwalają skutecznie identyfikować defekty występujące w danym produkcie pracy;
• stosowane listy kontrolne są aktualne i uwzględniają główne czynniki ryzyka;
• obszerniejsze dokumenty są pisane i przeglądane partiami, dzięki czemu autorzy szybko i często otrzymują informacje zwrotne na temat defektów (co jest elementem kontroli jakości);
• uczestnicy mają wystarczająco dużo czasu na indywidualne przygotowanie;
• przeglądy są planowane z należytym wyprzedzeniem;
• kierownictwo wspiera przebieg przeglądów (np. poprzez wyznaczenie wystarczającej ilości czasu na wykonanie czynności związanych z przeglądem w harmonogramie projektu).
Do czynników sukcesu o charakterze kadrowym zaliczają się między innymi następujące kryteria:
• w przegląd są zaangażowane osoby, których udział sprzyja osiągnięciu jego celów — np. osoby o różnych umiejętnościach lub punktach widzenia, które będą potencjalnie korzystać z dokumentu w ramach wykonywanej pracy;
• testerzy są uznawani za ważnych uczestników przeglądu, a zdobywana przez nich wiedza na temat produktu pracy umożliwia wcześniejsze przygotowanie bardziej efektywnych testów;
• uczestnicy przeznaczają wystarczającą ilość czasu na wzięcie udziału w przeglądzie i wykazują się należytą dbałością o szczegóły;
• recenzowane są małe fragmenty dokumentacji, dzięki czemu recenzenci nie tracą koncentracji podczas pracy indywidualnej i/lub spotkania przeglądowego (o ile się odbywa);
• informacje o wykrytych defektach są przyjmowane do wiadomości, zaś defekty są potwierdzane i rozpatrywane w sposób obiektywny;
• spotkanie jest prowadzone we właściwy sposób, tak, aby uczestnicy mieli poczucie, że pożytecznie spędzili czas;
• przegląd odbywa się w atmosferze wzajemnego zaufania, a jego wyniki nie są wykorzystywane do oceny uczestników przeglądu;
• uczestnicy unikają gestów i zachowań, które mogłyby wskazywać na znudzenie, irytację bądź wrogie nastawienie wobec innych uczestników;
• uczestnikom zapewnia się należyte szkolenie, zwłaszcza w przypadku bardziej formalnych typów przeglądów (takich jak inspekcje);
• tworzy się atmosferę sprzyjającą poszerzaniu wiedzy i doskonaleniu procesów.
Więcej informacji o udanych przeglądach można znaleźć w [Gilb 1993], [Wiegers 2002] i [van Veenendaal 2004].