ISTQB PART II: Statyczne techniki testowania (przegląd ręczny, statyczna analiza automatyczna)

Hejo,

Jest piątek, wieczorowa pora i właśnie uświadomiłem sobie, jak bardzo muszę być w to wszystko wkręcony, skoro nie wyszedłem zobaczyć się ze znajomymi, odrzuciłem fajną propozycję spotkania i spędzę dłuugi wieczór z tematem testowania. Powinienem postukać się w głowę, prawda? Nie chcę traktować górnolotnymi hasłami ale szukaj podpowiedzi w nazwie bloga, sam właśnie na to wpadłem. Meh.

Okay, Statyczne techniki testowania. Zrobimy to tak samo, jak w poprzednim poście - wymienimy sobie cele nauczania (wg. mnie te najważniejsze i najbardziej interesujące) i je opiszemy starając się żyć w zgodzie z sylabusem ISTQB FL. Zaczynajmy!


=======================

Kandydat potrafi rozpoznać produkty, które mogą zostać sprawdzone przez różne techniki testowania statycznego. Potrafi również opisać ich znaczenie oraz wartość w ocenie produktów procesu rozwoju oprogramowania. Dodatkowo potrafi wyjaśnić różnice pomiędzy testami statycznymi i dynamicznymi.

Okay, zacznijmy od końca. W przeciwieństwie do technik dynamicznych (które wymagają uruchomienia oprogramowania) techniki statyczne polegają na sprawdzeniu ręcznym (robi się przeglądy) lub na analizie automatycznej (analiza statyczna) kodu źródłowego testowanego produktu (software'u) lub innych dokumentów projektowych bez uruchamiania kodu :)

Co ważne, to to, że przeglądy są jednym ze sposobów na testowanie produktów procesu wytwarzania oprogramowania i to łącznie z kodem. Może je wykonywać długo przed wykonaniem testów dynamicznych. Dzięki temu usterki, jakie uda się znaleźć w tak wczesnej fazie produkcji oprogramowania są o wiele tańsze to załatania/usunięcia, iż te wykryte podczas testów dynamicznych.

Jak wcześniej wspomnieliśmy przeglądy wykonujemy ręcznie ale istnieje do nich wsparcie narzędziowe. Główną czynnością wykonywaną manualnie jest sprawdzenie produktu i zanotowanie uwag. Przeglądom mogą podlegać wszystkie produktu SLC - od specyfikacji wymagań, poprzez projekt, kod, plany i specyfikacja testów, przypadki testowe, skrypty na podręcznikach użytkownika i stronach webowych kończąc.

Po co robić testowanie przeglądowe? Ano najważniejszym wariantem jest tutaj ekonomia wykonania. Przeglądy pozwalają zaoszczędzić mnóstwo pieniędzy, pozwalają również na wczesną naprawę usterek, zwiększenie produktywności produkcji software'u i notowanie uwag, które inkrementują doświadczenia osób pracujących przy danym projekcie. Dodatkowo przeglądy mogą wykrywać braki, które trudno wykryć na poziomie testów dynamicznych.

Ciekawostka - do tych najbardziej typowych usterek wykrywanych za pomocą testów przeglądowych należą: odchylenia od standardów, usterki w wymaganiach, usterki w projekcie czy nieprawidłowa pielęgnowalność oraz specyfikacje interfejsów.


Warto zajrzeć w ten link, gdzie fajnie pokazano porównanie pomiędzy tymi dwoma typami testowania (statycznego oraz dynamicznego).

Kandydat pamięta kroki, role i odpowiedzialności związane z typowym przeglądem formalnym, potrafi wyjaśnić różnice pomiędzy różnymi typami przeglądów oraz potrafi wskazać czynniki wpływające na skuteczne przeprowadzanie przeglądów.

Okay, pora wejść głębiej w testowanie statyczne (przeglądowe - ręczne), a dokładniej w jego typy. Wyróżniamy ich wiele - od tych nieformalnych (które cechują się notabene brakiem spisanych instrukcji dla przeglądających - co jest częste w tej branży), do systematycznych, które z kolei uwzględniają przygotowanie zespołu, zapisanie wyników przeglądu oraz udokumentowanie procedury wykonania przeglądu.

Warto wiedzieć, iż stopień sformalizowania przeglądu zależy od takich czynników jak dojrzałość procesu produkcyjnego oraz wymagań wynikających z prawa lub też konieczności udokumentowania przebiegu przeglądu.

PRZEGLĄD FORMALNY 

Chcę zaznaczyć, iż to, co teraz przeczytacie to idealnie zaplanowany, rozpisany i wykonany proces przeglądu formalnego. W zależności od specyfiki pracy, teamu, potrzeb, projektu może to wyglądać zupełnie inaczej i zazwyczaj jest to budujące i niezwykle inspirujące doświadczenie, tylko na papierze wygląda to nudno. Podkreśliłem te czynności, które imho wzbogacają naszą wiedzę oraz doświadczenie najbardziej.

Zatem przegląd formalny składa się z następujących po sobie faz:

1. planowanie, a w nim:
- definiowanie kryteriów przeglądu,
- przydział ról,
- ustalenie kryteriów wejścia i zakończenia dla bardziej formalnych typów przeglądów,
- wybór fragmentów dokumentu do przejrzenia,

2. rozpoczęcie, a w nim:
- rozesłanie dokumentów,
- opisanie celów przeglądu, procesu i dokumentów uczestnikom przeglądu,
- sprawdzenie kryteriów wejścia,

3. przygotowanie indywidualne
- przygotowanie przed spotkaniem przeglądowym przez 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,
- zapisywanie defektów i rekomendacji dotyczących ich poprawiania, podejmowanie decyzji co do defektów,

5. poprawki
- naprawianie znalezionych defektów, zwykle wykonywane przez autora kodu,
- uaktualnianie statusów defektów,

6. zakończenie
- sprawdzenie, że usterki zostały obsłużone,
- zbieranie metryk,
- sprawdzenie kryteriów zakończenia.

Jak możecie się domyślać praca testera jest ściśle kooperacyjna, nawet, jeśli my jako osoba mamy wyznaczone pojedyncze zadania musimy być komunikatywni, spostrzegawczy, ambitni, nie możemy zostawać w tyle za zespołem - i tutaj dobrze w zespole mieć ludzi, którzy 'pchają' do przodu - czasem na dobre wychodzi wskoczenie w ocean - jeżeli uda się wypłynąć, to wypłynie się z ogromną wiedzą i satysfakcją. Napominam również o tym dlatego, że w każdym z projektów biorą udział osoby, które posiadają różne role. Wymienię je teraz w skrócie:

kierownik - myślę, że wyjaśniać nie trzeba - osoba decyzyjna, ustalająca harmonogram projektu oraz sprawdza poszczególne cele wykonania projektu,

moderator - osoba ta prowadzi przegląd dokumentu (włącza w to planowanie przeglądu, prowadzenie spotkań i odhacza, czy wszystkie kryteria spotkania zostały spełnione),

autor - jest to osoba, która nadzorowała powstawanie dokumentu, który podlega przeglądowi,

przeglądający - są to osoby z odpowiednimi kompetencjami (posiadający zaplecze techniczne etc.), którzy znajdują i spisują uwagi (np. usterki) do przeglądanego produktu.

protokólant - dłubie w nosie ołówkiem ale tą stroną z naoszczonym przodem.

Podczas tego typu spotkań warto robić burzę myśli - spojrzenia różnych specjalistów na sprawy kluczowe opisane np. w dokumencie pozwalają podejść do problemu na wiele sposobów, co ostatecznie pozwala na wykrycie większej ilości defektów :)

==================

Pojedynczy produkt programistyczny może podlegać więcej niż jednemu przeglądowi. Głównymi cechami, opcjami i celami powszechnie stosowanych typów przeglądów są:

przegląd nieformalny - brak kompletnego procesu, nie musi być udokumentowany, jego głównym celem jest tani sposób na osiągnięcie niewielkich korzyści (tak, wiem, jak to brzmi),

przejrzenie - są to nieograniczone czasowo sesje, których celem jest przede wszystkim uczenie się, zrozumienie oraz (a jakże!) znajdowanie usterek,

przegląd techniczny - posiada zdefiniowany proces wykrywania defektów, może być organizowany bardziej lub mniej formalnie, w praktyce może być bardzo nieformalny albo bardzo formalny, a jego głównymi celami są dyskusja, podjęcie decyzji nt. zaistniałych problemów, ocena alternatyw, wyszukiwanie usterek oraz rozwiązywanie problemów technicznych :)

inspekcja - przeprowadzana jest przez moderatora, który sprawdza kolegów, czy robią wszystko tak, jak jest to zapisane w harmonogramie, planie, dokumencie technicznym, przyjętymi na spotkaniu wytycznymi, jej efektem jest raport dla kierownika, głównym celem jest oczywiście wyszukiwanie usterek,

======

Czynniki, które mogą wpływać pozytywnie na powodzenie przeglądów to:

- jasno określony cel przeglądu,
- znalezione usterki są przyjmowane pozytywnie i wyrażane w sposób obiektywny,
- rozwiązuje się problemy personalne i psychologiczne,
- przegląd prowadzone jest w atmosferze zaufania,
- kierownictwo wspiera dobry proces przeglądu,
- kładzie się nacisk na uczenie się oraz doskonalenie procesów.


Kandydat pamięta typowe błędy wykrywane przez analizę statyczną i umie porównać je z przeglądami i testami dynamicznymi, potrafi opisać używając przykładów typowe korzyści z analizy statycznej oraz potrafi wymienić typowe defekty kodu i projektu, które mogą zostać wykryte przez narzędzia do analizy statycznej.

Celem analizy statycznej jest wyszukanie usterek w kodzie programu lub w modelach bez uruchamiania samego programowania, które jest sprawdzane przez narzędzie używane w tym procesie.  Analiza statyczna może znaleźć usterki, które są trudne do znalezienia podczas testowania dynamicznego (wspominaliśmy o tym wcześniej ale to najważniejsza różnica i powód dla robienia ręcznych przeglądów). Analiza statyczna znajduje usterki, a nie awarie. Narzędzia do analizy statycznej analizują kod oprogramowania (np. przepływ sterowania lub przepływ danych) jak również wygenerowane wyjście w postaci htmla lub xmla.

O wartości analizy statystycznej świadczą następujące cechy:
- (znowu) wczesne wykrywanie usterek, jeszcze przed wykonaniem prawilnych testów,
- wczesne wykrywanie podejrzanych aspektów kodu lub projektu przez wyliczenie miar (np. stopień złożoności kodu),
- identyfikacja defektów trudnych do wykrycia podczas prawilnego testowania,
- zwiększenie pielęgnowalności kodu i projektu,
- zapobieganie defektom, jeżeli zastosowane zostają wnioski z analizy z SLC.

Analiza statyczna zwykle wykrywa następujące typy usterek:

- odwołanie do niezainicjowanej zmiennej,
- niespójne interfejsy między modułami,
- niewykorzystywane lub niepoprawnie zadeklarowane zmienne,
- martwy kod,
- brakująca albo błędna logika,
- zbyt skomplikowane instrukcje,
- naruszenie standardów kodowania,
- słabe punkty zabezpieczeń,
- naruszenie reguł składni kodu i modeli oprogramowania.

Narzędzia do analizy statycznej używane są zwykle przez programistów przed lub w trakcie testów modułowych lub integracyjnych. Narzędzia te mogą zaraportować dużą liczbę ostrzeżeń, którymi trzeba jednak dobrze zarządzać, by uzyskać jak największą skuteczność użycia narzędzia.

================

Wybaczcie mi za to, że ta część to praktycznie sam tekst. W praktyce jest ciekawiej, bardziej stresująco, a sama teoria często w ogólnym zarysie wygląda inaczej. ISTQB to model idealny, a wiadomo, że ilu ludzi w teamie, tyle kombinacji pracy tego teamu nad danym projektem :)

Trzymajcie się,

F.

Ps. Jeżeli nie rozumiecie pojęć tj. kryteria wejścia i im podobnych to najprawdopodobniej będą one wyjaśnione w kolejnych częściach :) Poza tym używanie Googla nie boli, prawda? A przynajmniej w odwrotną stronę..