ISTQB 3

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