2h4

7 – Statyczne techniki testów i organizacja

TESTOWANIE STATYCZNE:

Agenda

 
• Testowanie Statyczne
• Proces przeglądu
• Typy przeglądów
 

Testowanie statyczne

Testowanie statyczne to sposób testowania, w którym nie następuje uruchomienie kodu. Testowanie statyczne może znaleźć zastosowanie w dokonaniu oceny projektu, dokumentacji lub specyfikacji.

Dzieli się na dwie podgrupy:

  • Analiza Statyczna – stosuje się najczęściej do formalnych produktów pracy – przykładem tutaj może być dokument – w celu weryfikacji gramatyki czy kodu.
  • Przeglądy – można je stosować do prawie wszystkich produktów pracy. Ograniczeniem do udziału w takim przeglądzie jest konieczność możliwości zrozumienia obiektu przeglądu i jakość przeglądanego produktu pracy. 


Zalety testowania statycznego:
• Pozwala na wczesne wykrywanie defektów i problemów i ich usuwanie w początkowych fazach projektu
• Wykrywanie problemów trudnych do identyfikacji w późniejszych testach
• Obniżenie kosztów i zwiększenie wydajności prac programistycznych i późniejszych testów dynamicznych
• Lepsza komunikacja między członkami zespołu dzięki organizacji przeglądów

Techniki testowania statycznego można stosować wobec większości produktów pracy:
• Specyfikacje
• Epiki, Historie użytkownika
• Architektura projektowa
• Kod
• Dokumentacja testowa
• Podręczniki użytkownika
• Dokumentacja projektu
• Strony internetowe



Testowanie statyczne a dynamiczne
Testowanie statyczne i dynamiczne mają te same cele – dokonanie oceny czy przedmiotu testów spełnia wymagania pod względem jakości, ale także najszybsze odnalezienie defektów. Mimo, że koszty testowania statycznego nie są tanie, jednakże należy pamiętać, że im późniejsze wykrycie i naprawa defektu tym większe koszty usunięcia defektu. Obie czynności wzajemnie się uzupełniają, ponieważ pozwalają na wykrywanie innych rodzajów defektów.
W przypadku testowania statycznego możemy znaleźć defekty w produkcie pracy, natomiast za względu na to, że nie uruchamiamy kodu – nie jesteśmy w stanie wykryć awarii.
Natomiast w przypadku testowania dynamicznego niepoprawne działanie objawia się awarią, gdyż kod jest uruchomiony.

Testowanie statyczne służy do zwiększenia spójności i jakości wnętrza produktu, a dynamiczne sprawdza jak działa kod na zewnętrznym zachowaniu oprogramowania.

Proces przeglądu

  • Przeglądy wykonywane są manualnie
  • Typy przeglądów różnią się od siebie specyficznymi atrybutami
  • Według Sylabusa ISTQB FL wyróżniamy 4 typy przeglądu:
    • I. Inspekcja
    • II. Przegląd Techniczny
    • III. Przejrzenie
    • IV. Przegląd nieformalny
  • Istnieją także inne typy przeglądów (przejrzenie koleżeńskie)

 
Proces przeglądu

 

Planowanie – podczas planowania przeglądu po wyborze produktu następuje zwyczajowo określenie jaki zakres będzie obejmować, określenie uczestników, celu przeglądu, ile czasu będzie trwać, typ przeglądu, role i listy kontrolne, jeśli typ przeglądu tego wymaga.

Rozpoczęcie przeglądu – przesłanie produktu pracy przeznaczonego do przeglądu z dokumentacją oraz formularzami lub listami kontrolnymi do uczestników. W tym momencie mogą mieć miejsce dodatkowe wyjaśnienia dla uczestników, jeśli są wymagane.

Przegląd indywidualny – uczestnicy przeglądają produkt pracy i dokonują zapisu ewentualnych pytań lub zaleceń. Zazwyczaj jest to moment, kiedy wykrywany jest największy odsetek błędów.

Dokumentacja i przekazanie informacji – w tym momencie następuje analiza problemów. Następuje komunikacja problemów do autora produktu. Także na tym etapie występuje ocena związana z dalszą przyszłością produktu – czy zostaje zaakceptowany, a może wymagane są w nim jakieś zmiany lub co gorsza – produkt pracy zostaje odrzucony.

Usunięcie defektów i raportowanie – jest to ostatni etap – tworzone są raporty o znalezionych defektach a na autorze produktu ciąży obowiązek ich rozwiązania.

Role i obowiązki w procesie przeglądu

 
Autor
• Twórca produktu objętego przeglądem
• Jest odpowiedzialny za usunięcie wykazanych podczas przeglądu defektów

Kierownicy
• Planowanie i decyzja o przeprowadzeniu przeglądu
• Określa zasoby i czas
• Funkcja kontrolna

Facylitator
• Jest odpowiedzialny za przebieg spotkania (gdy wymagana jest jego obecność)
• Pełni funkcję mediatora
• Bardzo często od niego zależy sukces spotkania

Lider Przeglądu
• Odpowiedzialny za przegląd
• Wyznacza uczestników, czas i miejsce spotkania

Przeglądający
• Uczestnicy projektu, interesariusze lub eksperci
• Wskazują defekty

Protokolant
• Funkcja skryby – dokumentacja defektów ujawnionych podczas spotkania
 

Inspekcja

• Jest to najbardziej formalna forma przeglądu
• Musi być przeprowadzony w zgodzie z określonym procesem, który oparty jest na listach kontrolnych i regułach
• Wymagane jest przygotowanie przez uczestników przed spotkaniem inspekcyjnym
• Prowadzony przez facylitatora
• Wymagana jest obecność protokolanta
• Obowiązują kryteria wejścia i wyjścia
• Produktem inspekcji może być dziennik defektów i raporty z przeglądów
Ma na celu:

  • Wykrycie defektów, jeśli istnieją i usunięcia w możliwie najkrótszym czasie
  • Ewaluacja jakości przedmiotu inspekcji
  • Podniesienie zaufania
  • Pozwala na wyciągnięcie wniosków i zapobieganie podobnym defektom w przyszłości

Przegląd Techniczny

• Spotkanie mające na celu podjęcie decyzji w aspekcie projektu lub technologii z udziałem ekspertów z opcjonalną obecnością kierownictwa
• Obowiązkowe jest przygotowanie indywidualne przed spotkaniem
• Rezultatem jest raport z przeglądu lub dziennik defektów
• Może przybierać formy od przeglądu nieformalnego po formalny
• Spotkanie powinno być prowadzone przez facylitatora

Celami przeglądu technicznego są:
• Wykrycie defektów
• Brainstorming
• Ocena potencjalnych alternatywnych rozwiązań
• Ocena jakości i budowanie zaufania do przedmiotu przeglądu
 

Przejrzenie

• Spotkanie często w gronie zespołu
• Częstym powodem spotkania jest analiza kodu, by określić przyczynę awarii
• Nie jest wymagane przygotowanie indywidualne
• Spotkanie przeważnie prowadzi autor
• Nie jest wymagany udokumentowany raport czy dziennik defektów
• Może przybierać formy od nieformalnego do formalnego
• Może przybrać formę scenariusza, analizy kodu linia po linii lub symulacji

Celami przejrzenia są:
• Identyfikacja defektów
• Wymiana doświadczeń
• Podniesienie kwalifikacji uczestników
• Podnoszenie jakości przedmiotu przejrzenia
 

Przegląd nieformalny

• Jest to często zwykła rozmowa członków zespołu o defekcie lub problemie technicznym
• Nie istnieje żaden formalny proces a rezultat często nie jest nigdzie dokumentowany
• Często wykorzystywany w metodykach zwinnych

Cele przeglądu nieformalnego:
• Szybka, niewielka korzyść przy małym nakładzie pracy
• Wykrycie defektów
• Rozwiązanie małych problemów
• Brainstorming
 

Czynniki sukcesu przeglądów


Czynniki sukcesów możemy podzielić na te o cechach organizacyjnych i kadrowych.

Organizacyjne (Procesy):
• Mają sprecyzowane cele z określonymi kryteriami wyjścia
• Sprzyjają osiąganiu zamierzonych celów poprzez weryfikację
• Wsparcie kierownictwa
• Zagwarantowany czas na dokładne przygotowanie się do przeglądów poprzez wcześniejsze planowanie

Kadrowe:
• Zaangażowanie odpowiednich uczestników
• Uczestnictwo testerów w celu lepszego zrozumienia i przygotowania się do testów
• Przegląd dotyczy produktu nie oceny autora
• Możliwość uczenia się
 


Źródło do materiałów: SJSI Sylabus ISTQB FL

ORGANIZACJA TESTÓW:


Agenda:

  • Role w procesie testowym
  • Planowanie Testów
  • Kryteriach wejścia i wyjścia
  • Szacowania pracochłonności testów

Role w procesie testowym

  •  Kierownik Testów/Test Manager
  •  Lider Testów/Test Lead
  • Tester

Kierownik testów


Ogólna odpowiedzialność za proces testowy i zarządzanie nim.
Kierownik testów może posiadać kilka zespołów testowych. Każdym z nich kierują liderzy testów.
 
Podstawowe obowiązki: 

  • Tworzenie i aktualizacji strategii testów w organizacji,
  • Kompleksowe planowanie testów, w tym:
    •   Wybór podejścia do testowania,
    •   Szacowanie czasu, pracochłonności i kosztów testowania, 
    •   Pozyskiwanie zasobów do testów,
    •   Definiowanie poziomów testów i iteracji testowych,
    •   Planowanie zarządzania błędami,
  • Sporządzanie i aktualizowanie planu testów,
  • Koordynowanie wykonania strategii testów i planu testów, 
  • Monitorowanie rezultatów testów oraz sprawdzanie statusu kryteriów wyjścia (definicji ukończenia),
  •  Przygotowanie i dostarczenie raportu z postępu testów i raportu sumarycznego z testów na podstawie zgromadzonych informacji.

Lider Testów

 
Koordynowanie pracy testerów i raportowanie wyników.
 
Podstawowe obowiązki: 

  • Koordynowanie wykonania strategii testów i planu testów, 
  •  Monitorowanie rezultatów testów oraz sprawdzanie statusu kryteriów wyjścia (definicji ukończenia),
  •  Przygotowanie i dostarczenie raportu z postępu testów i raportu sumarycznego z testów na podstawie zgromadzonych informacji.

  Tester

  • Wykonanie planów testów a także uczestniczenie w ich opracowywaniu,
  • Analizowanie, dokonywanie przeglądu i ocenianie wymagań, historyjek użytkownika i kryteriów akceptacji (w przypadku Scrum) pod kątem testów,
  • Analizowanie, dokonywanie przeglądu specyfikacji oraz modeli (tj. podstawy testów) pod kątem testów (Kaskada),
  • Tworzenie wymagań i specyfikacji dot. Potrzebnych środowisk testowych,
  •  Projektowanie i implementowanie przypadków testowych i skryptów testowych,
  •  Przygotowywanie danych testowych,
  • Przygotowanie harmonogramu wykonywania testów,
  • Testowanie, ocenianie rezultatów i zgłaszanie błędów w odpowiednich narzędziach,
  • ewaluacja charakterystyk niefunkcjonalnych, takich jak: wydajność, niezawodność, użyteczność, zabezpieczenia, zgodność, przenaszalność;
  • Przeglądy testów innych osób.

Planowanie Testów





Planowanie testów to dokument określający strategię, która została wykorzystana do weryfikacji, czy oprogramowanie zostało wytworzone zgodnie ze specyfikacją i ustalonymi wymaganiami.
 Jego celem jest zdefiniowanie celów testowania i działań testowych z tym związanych.
Plan testów – Jest podstawowym dokumentem w procesie testowym.
W miarę postępu realizowania projektu i planu testów dostarczane są nowe informacje, które uszczegóławiają plan testu danego projektu. Jest to czynność, która ma charakter ciągły – wykorzystywany jest przez cały cykl życia produktu, dlatego też będzie aktualizowany przez informacje zwrotne lub zmieniające się ryzyka. Co jest istotne – jeden projekt może mieć wiele planów – mogą być podzielone ze względu na poziomy jak i typy testów.

Plan testów musi zawierać:

  • Wstęp
  • Przedmiot testów
  • Zakres testów
  • Kryteria wejścia / wyjścia
  • Kryteria zaliczenia/niezaliczenia testów
  • Lista funkcjonalności do przetestowania
  • Środowisko/Środowiska testowe
  • Lista narzędzi
  • Harmonogram testów
  • Zarządzanie incydentami, błędami
  • Wzór i zakres Raport z testów
  • Role i odpowiedzialności
  • Ryzyka

 
Wstęp
Zawiera:

  • Cel dokumentu – informacje o celu powstania dokumentu wraz z jego agendą,
  • Cel działań testowych – informacja dla interesariuszy, aby mogli w sposób świadomy odebrać aplikacje i wyrazić zgodę na wdrożenie na produkcję


Zakres Testów
Zawiera:

  • poziomy i typy testów (testy jednostkowe, testy integracyjne, testy funkcjonalne, testy wydajnościowe, testy bezpieczeństwa, testy regresji, testy automatyczne)
  • rodzaje testów które zostaną pominięte i nie zostaną wykonane wraz z uzasadnieniem
  • liczbę iteracji testów

 
Przedmiot testów
Zawiera:

  • Precyzyjnie określony przedmiot testów(cała aplikacja, moduł, usługa)


Kryteria zaliczenia / niezaliczenia testów
Zawiera:

  • Definicja kryteriów zaliczenia (test pozytywny) i niepowodzenia (test negatywny) dla każdego konkretnego testu, aby jednoznacznie określać wynik testu.



Kryteria wejścia / wyjścia
Zawiera:

  • Kryteria wejścia: są to wszystkie elementy, warunki, które muszą zostać spełnione, aby rozpocząć testowanie, czyli np. działające środowisko testowe, dostępny zespół ludzi o odpowiednich kompetencjach technicznych i biznesowych, czy zakończone określone fazy developmentu.
  • Kryteria wyjścia: informacje kiedy można przerwać testowanie danej funkcji, czyli kiedy jest moment że dana funkcjonalność działa zgodnie z wymaganiami.
  • Kryteria zawieszenia: kiedy należy wstrzymać test, ponieważ dalsze testowanie może być nieefektywne.

 
Lista wymagań / funkcjonalności do przetestowania
Zawiera: 

  •  Szczegółową listę funkcjonalności zaplanowaną do testów wraz ze scenariuszami testowymi podpiętymi pod konkretne funkcjonalności.


Środowisko testowe
Zawiera:

  • Listę potrzebnych środowisk testowych, narzędzi wraz z ich specyfikacją i konfiguracją aby wykonać miarodajne testy.


Harmonogram testów
Zawiera:

  • Harmonogram testów, które zamierzamy przeprowadzić wraz z fazami oraz typami testów wraz z ich określonymi przedziałami czasowymi (datami).


Raport z testów
Zawiera:

  •  Informację jak będzie wyglądał raport końcowy z testów wraz zakresem informacji będzie dostarczał decydentom aby mogli podjąć decyzję o wdrożeniu.

 
Lista narzędzi
Zawiera: 

  • Listę wszystkich narzędzi, które będą wykorzystywane w całym procesie testowym.


Zarządzanie incydentami, błędami
Zawiera:

  • Proces, który przedstawia zarządzanie wykrytymi błędami od ich znalezienia, po naprawę, a kończąc na retestach i finalnym zamknięciu. 


Role i odpowiedzialność
Zawiera:

  • Listę ról i odpowiedzialności (konkretny zakres) w procesie testowym.


Ryzyka
Zawiera:

  • Listę potencjalnych ryzyk, o których mamy świadomość, a które wydają się istotne i mogą mieć wpływ na proces testowy.

Szacowania pracochłonności testów


Czym jest Szacowanie?
„szacowanie testów: Obliczona aproksymacja wyniku związana z różnymi aspektami testowania (takimi jak wysiłek, data zakończenia, poniesione koszty, ilość przypadków testowych itp.), która jest użyteczna, nawet gdy dane wejściowe są niekompletne, niepewne lub zakłócone.”*
 
Szacowanie:

  • ilości pracy – potrzebna do zrealizowania zadania, serii zadań lub całego procesu testowego, 
  • czasu trwania – szacowanie ilość pracy, a następnie zaplanowanie jej realizacji w czasu,
  •  budżetu – koszty wynikającymi z ilości pracy wraz z kosztami licencji, sprzętu, delegacji.


* ISTQB
 
Zakres szacowania:

  • Czas potrzebny na planowanie testów,
  • Przygotowanie testów,
  • Wykonywanie testów,
  •  Raportowanie błędów, 
  • Retesty, czyli weryfikacja błędów,
  • Testy regresji,
  • Cykle testowe,
  • Przygotowanie i utrzymanie automatyzacji,
  • Dokumentacja,
  • Testy niefunkcjonalne.


 
Techniki estymacji:
 

  • Ocena ekspercka – wycena wykonywana przez osobę bardzo doświadczoną,
  • Estymacja na podstawie historycznych danych – wycena na podstawie informacji ile czasu trwał podobny projekt,
  • Trzypunktowa estymacja – określamy najbardziej optymistyczny scenariusz, średni oraz pesymistyczny. Finalna wartość estymacji jest średnią tych liczb, przy czym wzór może być modyfikowany poprzez zastosowanie innych wag dla parametrów, przykładowo: (opt. + 3 x śr. + pes)/5,
  • Estymacje „od dołu do góry” (bottom-up) – szacowanie niskopoziomowych zadań w projekcie a następnie pogrupowanie ich i zsumowanie,
  • Spotkania, głosowania – wszelkie interaktywne dyskusje, które mają na celu wypracowanie wspólnych szacunków.