ISTQB PART IV: Zarządzanie testowaniem (organizacja, planowanie, szacowanie, monitorowanie, konfiguracja testów)

Hejka,

Dzisiaj pomówimy sobie o logistyce zarządzania testowaniem. Jak zawsze teoria będzie przedstawiać sytuacje idealną, niemniej uważam, że jest tutaj wiele prawd, które pozwolą przeprowadzić rzetelne, ekonomiczne (czas, $$) testy, które będą przede wszystkim niezależne, przejrzyste dla teamu oraz będą posiadać konkretne cele. Zacznijmy zatem od ogółów i powoli przenosić będziemy się do szczegółu.

Kandydat uznaje ważność testowania niezależnego. Potrafi wyjaśnić korzyści, jak i wady niezależnego testowania w organizacji. Uznaje również potrzebę włączenia różnych członków zespołu podczas tworzenia zespołu testerskiego oraz pamięta zadania lidera testów oraz testera.

Skuteczność wykrywania usterek w testach i przeglądach może zostać podniesiona przez zaangażowanie niezależnych testerów. Niezależność może (lub nie) występować w różnych wariantach:

- brak niezależnych testerów - programiści testują swój własny kod (brak jakiejkolwiek zależności),
- niezależni testerzy wewnątrz zespołu projektowego testują kod,
- niezależny zespół testowy lub grupa testerów wewnątrz organizacji podlegająca kierownikowi projektu testuje kod,
- niezależni testerzy z departamentów biznesowych lub społeczności użytkowników testują kod,
- niezależni specjaliści od określonych typów testów testują kod,
- niezależni testerzy, którzy zostali wynajęci lub są na zewnątrz organizacji (maksymalna niezależność).

W projektach dużych, złożonych lub przy wytwarzaniu aplikacji krytycznych ze względu na bezpieczeństwo, zwykle najlepiej mieć kilka poziomów testów, z których niektóre lub wszystkie wykonywane są przez niezależnych testerów. Programiści mogą uczestniczyć w testach, szczególnie na niższych poziomach ale ich brak obiektywności często ogranicza skuteczność.

Korzyści z niezależności to przede wszystkim świeże spojrzenie na software bez żadnych uprzedzeń, niezależny tester może również zweryfikować założenia poczynione podczas specyfikacji i implementacji systemu.

Wady niezależności są typowe i są jej następstwem t.j. izolacja od deweloperów oraz obwinianie testerów jako tych złych, którzy opóźniają release poprzez 'wąskie gardło'. Tak, obwiniają deweloperzy. Teraz już rozumiecie, dlaczego ważnym jest kodeks etyczny testera, komunikatywność, uśmiech i ogólnie dobra atmosfera w pracy? : )

Zadania związane z testowaniem mogą być pełnione przez testerów lub też przez kierowników, menadżerów jakości, programistów etc.

Zadania lidera testów oraz testera

Czasem lider testów nazywany jest po prostu kierownikiem (umówmy się, mówmy mu po imieniu) testów, bądź ich koordynatorem. Rolę lidera testów może pełnić kierownik projektu, kierownik zespołu wytwórczego, kierownik zapewnienia jakość bądź kierownik zespołu testowego (co zdarza się najczęściej). W większych projektach wyróżnić możemy dwa stanowiska: lidera oraz kierasa testów. Lider planuje, monitoruje i kontroluje zadania testowe, a tester testuje. Wymienię teraz parę zadań lidera, jak i testera, by mieć clue sytuacyjne (w projektach nigdy nie wchodzimy sobie w swoje zadania bądź kompetencje bez konsultacji z kierownikiem):

typowe zadania lidera testów to m.in.:

- koordynowanie strategii oraz planów testów z kierownikami projektu i innymi zainteresowanymi,
- tworzenie oraz przeglądanie strategii testów w projekcie oraz polityki testowania w organizacji,
- planowanie testów, uwzględniając ich kontekst oraz rozumiejąc cele testów i ryzyko, włącznie z wyborem podejścia do testów, szacowaniem czasu, pracochłonności i kosztów testowania, zdobywaniem zasobów, definiowaniem poziomów testów, cykli testowych oraz planowaniem zarządzania incydentami,
- inicjowanie specyfikacji, przygotowania, implementacji i wykonania testów, monitorowanie ich wyników, sprawdzenia kryteriów zakończenia,
- sporządzanie raportów podsumowujących testy bazując na informacjach zebranych podczas testów,

typowe zadania testera to i.in.:

- przeglądanie i wnoszenie wkładu do planów testów,
- analiza, przegląd oraz ocena wymagań użytkownika, specyfikacji oraz modeli ze szczególnym uwzględnieniem testowalności,
- tworzenie specyfikacji testów,
- współtworzenie środowiska testowego,
- przygotowywanie i pozyskiwanie danych testowych,
- implementacja testów na wszystkich poziomach, wykonanie i logowanie testów, ocena wyników oraz dokumentowanie odchyleń od oczekiwanych wyników,
- automatyzacja testów (może być wspierana przez programistę),
- pomiar wydajności modułów i systemów,
- przeglądanie testów wytworzonych przez innych.

Ważne jest, aby wiedzieć, że na różnych poziomach testów te same osoby mogą pełnić różną rolę. Np. na poziomie modułowym oraz integracyjnym testerami zwykle są programiści. na poziomie testów akceptacyjnych eksperci biznesowi, a testerami w produkcyjnych testach akceptacyjnych - operatorzy.

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



Kandydat rozpoznaje różne poziomy i cele planowania testów. Potrafi omówić krótko cel i zawartość planu testów, projektu testów, procedury testowej zgodnie ze standardem dokumentacji testowania oprogramowania. Rozróżnia również odmienne podejścia do testowania, takie jak analityczne, oparte na modelach, metodyczne, zgodne z procesem lub standardem, dynamiczne/heurystyczne, konsultatywne oraz regresywne. Odróżnia planowanie testów systemu od harmonogramowania ich wykonania. Potrafi napisać harmonogram wykonania testów dla danego zbioru przypadków testowych, uwzględniając ich priorytety oraz zależności logiczne i techniczne. Potrafi wymienić czynności przygotowania i wykonania testów, które należy wziąć pod uwagę przy planowaniu. Pamięta typowe czynniki, które mają wpływ na pracochłonność testowania. Odróżnia od siebie dwa koncepcyjnie odmienne podejścia do szacowania: podejścia bazujące na metrykach i podejścia wykorzystujące ekspertów. Potrafi rozpoznać i uzasadnić odpowiednie kryteria wejścia oraz zakończenia konkretnych poziomów testowania oraz grup przypadków testowych.

Na planowanie testów wpływ ma polityka testowania w organizacji, zakres samych testów, ich cele, ryzyko, ograniczenia, krytyczność, testowalność oraz dostępność zasobów. Logicznie - im dłużej trwa planowanie projektu u testów, tym więcej informacji jest dostępnych i tym więcej szczegółów może być włączone do planowania.

Planowanie testów jest czynnością stałą i wykonuje się je dla wszystkich procesów i zadań SLC.

Informacje zwrotne z czynności testowych są używane do wykrywania zmieniających się ryzyk, tak, że planowanie może zostać dopasowane do bieżącej sytuacji w projekcie.

Czynności związane z planowaniem testów

- ustalenie zakresu i ryzyka oraz zidentyfikowanie celów testowania,
- zdefiniowanie ogólnego podejścia od testowania włącznie z definicją poziomów testów oraz kryteriów wejścia i zakończenia,
- integrowanie i koordynowanie zadań testowych z innymi zadaniami SLC,
- podejmowanie decyzji co testować, którym rolom będą przypisane które zadania testowe,
- harmonogramowanie analizy i projektowania testów oraz implementacji i wykonania oceny testów,
- przydzielanie zasobów do zadań testowych,
- definiowanie ilości, poziomu szczegółowości, struktury oraz wzorców do dokumentacji testowej,

! Kryteria wejścia

Definiują one warunku pozwalające na rozpoczęcie testów na początku poziomu testów lub gdy zbiór testów jest gotowy do wykonania.

Kryteria wejścia zwykle mogą zawierać następujące zagadnienia:
- dostępność i gotowość środowiska testowego,
- gotowość narzędzi testowych w środowisku testowym,
- dostępność testowalnego kodu,
- dostępność danych testowych

! Kryteria zakończenia

Celem kryteriów zakończenia jest zdefiniowanie momentu zakończenia testów na danym poziomie testów lub gdy zbiór testów osiągnął cel.

Typowo kryteria zakończenia mogą składać się z:
- miar staranności, takich jak pokrycie kodu, funkcjonalności lub ryzyka,
- estymat gęstości błędów lub miar zawodności,
- kosztu,
- istniejącego ryzyka, takiego jak niepoprawione usterki lub brak pokrycia pewnych obszarów,
- harmonogramów np. zdefiniowanych na podstawie czasu do wypuszczenia produktu na rynek.

!Szanowanie testów

Istnieją dwa podejścia do szacowania pracochłonności testów:

> podejście oparte na metrykach - szacowanie pracochłonności testów bazując na pomiarach minionych lub podobnych projektów lub bazujące na typowych wartościach,

> podejście oparte na ekspertach - szacowanie zadań przez ich przyszłych wykonawców :)

Gdy pracochłonność zostanie oszacowana następuje przyporządkowanie zasobów do zadań oraz zaczyna się rozpisywać harmonogram.

Pracochłonność testów zależy od wielu czynników, np od:

- cech produktu - jakości specyfikacji produktu, informacji o używanych modelach testowych, wielkości, złożoności, wymagań na niezawodność oraz zabezpieczenie, wymagań na dokumentację,

- cech procesu produkcyjnego - stabilności organizacji, użytych narzędzi, procesu testowego, umiejętności ludzi oraz presji czasu,

- wyników testów - liczby usterek oraz pracochłonności napraw i przeróbek.


Podejście do testowania, strategia testowania

Podejście do testów jest implementacją strategii testów w konkretnym projekcie. Podejście do testów jest definiowane i uszczegóławiane w planach testów oraz projektach testów. Zawiera ono zwykle decyzje podejmowane na podstawie celów projektu oraz oceny ryzyka. Stanowi ono punkt wyjściowy do planowania procesu testowania, wyboru technik projektowania testów i stosowanych typów testów, a także do definiowania kryteriów wejścia i zakończenia.

Typowe podejścia do testów.

> podejścia analityczne, takie jak testy oparte na ryzyku, w którym testowanie jest kierowane na obszary o największym ryzyku,
> podejścia oparte na modelach, takie jak testowanie stochastyczne wykorzystujące informacje statystyczne na temat współczynników awarii,
> podejścia metodyczne - podejścia oparte na awariach, oparte na doświadczeniu, na listach kontrolnych lub na atrybutach jakościowych,
> podejścia zgodne ze standardem lub procesem, takie jak te określone przez standardy przemysłowe,
> podejścia dynamiczne i heurystyczne, takie jak testowanie eksploracyjne, w którym testowanie bardziej reaguje na zdarzenia podczas testów niż jest wykonywane według planu i w którym wykonanie testów i ocena wyników dzieją się równolegle,
> podejścia konsultatywne, w których pokrycie testowe jest sterowane głównie przez wskazówki i porady ekspertów technologicznych lub biznesowych z zewnątrz zespołu testowego,
> podejścia regresywne, w których używa się powtórnie istniejących materiałów testowych, rozbudowanej automatyzacji regresywnych testów funkcjonalnych oraz standardowych zestawów testów.

Różne podejścia mogą zostać połączone, np. w dynamiczne testy oparte na ryzyku.

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

Kandydat potrafi wskazać najczęściej używane metryki do monitorowania przygotowania i wykonania testów. Potrafi wyjaśnić i porównać metryki stosowane w raportowaniu i kontroli testów. Potrafi również omówić krótko cel i zawartość raportu podsumowującego testy zgodnie ze standardem dokumentacji testowania oprogramowania.


Monitorowanie postępów testów i ich nadzór

Celem monitorowania testów jest uzyskanie informacji zwrotnych oraz uzyskanie wglądu w przebieg zadań testowych. Informacje, które mają być monitorowane, mogą zostać zebrane ręcznie lub automatycznie i mogą zostać użyte do pomiarów spełnienia kryteriów zakończenia (np. pokrycia). Metryki mogą również zostać wykorzystane do oceny postępów według zaplanowanego harmonogramu i budżetu.

Takimi metrykami są:

- procent pracy wykonanej przy przygotowaniu przypadków testowych lub odsetek przygotowanych przypadków testowych,
- procent prac wykonanych przy przygotowaniu środowiska testowego,
- wykonanie przypadków testowych,
- informacje o usterkach,
- pokrycie testami wymagań, ryzyka i kodu,
- subiektywne zaufanie testerów do produktu,
- daty kamieni milowych,
- koszt testowania, włączając w to porównanie kosztu do korzyści dla znalezienia kolejnego defektu lub wykonania kolejnego testu.

Raportowanie testów

Raportowanie testów podaje podsumowanie projektu testowego, a w tym:

- co zdarzyło się w czasie testowania, np. daty spełnienia kryteriów zakończenia,
- analizę informacji oraz metryk wspierającą rekomendację oraz decyzje co do przyszłych działań, takich jak pozostałe usterki, opłacalność dalszego testowania, pozostałe obszary ryzyka oraz poziom zaufania do testowanego oprogramowania.

Pomiary testów powinny być wykonywane w trakcie oraz na koniec poziomu testów, żeby ocenić:

- dopasowanie celów testów do poziomu testów,
- adekwatność wybranego podejścia do testów,
- skuteczność testów w odniesieniu do celów testowania.

Kierowanie testami

Kierowanie testami to wszystkie działania zarządcze lub korekcyjne podjęte na skutek zebranych i zaraportowanych informacji i pomiarów. Działania te mogą dotyczyć dowolnego zadania testowego lub mogą wpływać na dowolną czynność lub zadanie związane z SLC.

Przykładami działań związanych z kierowaniem testami są:

- podejmowanie decyzji na podstawie informacji uzyskanych z monitorowania testów,
- zmiana priorytetów testów, kiedy zmaterializuje się ryzyko (np. oprogramowanie zostaje dostarczone testerom z opóźnieniem),
- zmiana harmonogramu testów związana z dostępnością lub niedostępnością środowiska testowego,
- ustanowienie kryteriów wejścia wymagających, aby programista zretestował poprawki zanim włączy je do wydania.

Kandydat potrafi opisać krótko, w jaki sposób zarządzanie konfiguracją wspiera testowanie.


Celem zarządzania konfiguracją jest ustanowienie i utrzymanie integralności produktów (modułów, danych i dokumentacji) związanych z oprogramowaniem lub systemem przez cały projekt lub SLC.

Z punktu widzenia testowania - zarządzanie konfiguracją wymaga zapewnienia, że wszystkie elementy oprogramowania zostały zidentyfikowane, poddane kontroli wersji, są śledzone, powiązane między sobą oraz z elementami deweloperskimi, tak, żeby można utrzymać możliwość śledzenia zmian i powiązań przez cały proces testowy. 

Zarządzanie konfiguracja pomaga testerom jednoznacznie wskazać (i odtworzyć) testowany element, dokumenty testowe, testy oraz jarzmo testowe.

Podczas planowania testów powinny zostać wybrane, udokumentowane i wdrożone procedury zarządzania konfiguracją oraz infrastrukturą.

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

Kandydat potrafi opisać ryzyko jako potencjalny problem, który zagrażałby osiągnięciu celów projektowych jednego lub kilku interesariuszy projektu. Pamięta, że poziom ryzyka jest określany przez prawdopodobieństwo wystąpienia oraz wpływ. Rozróżnia też elementy ryzyka projektowego i produktywnego Rozpoznaje typowe elementy ryzyka projektowego i produktywnego, potrafi opisać przy użyciu przykładów jak analiza ryzyka i zarządzanie ryzykiem mogą zostać wykorzystane przy planowaniu testów.

Ryzyko definiujemy jako możliwość wystąpienia zdarzenia, niebezpieczeństwa, zagrożenia lub jakiejś sytuacji powodującej niepożądane konsekwencje lub poważny problem. Poziom ryzyka jest określony przez prawdopodobieństwo wystąpienia niekorzystnego zdarzenia oraz jego wpływ (szkoda, jaką może wyrządzić to zdarzenie).

Ryzyko projektowe to obszary języka otaczające zdolność projektu do osiągnięcia postawionych przed nim celów. Te cele to m.in.:

> czynniki organizacyjne 
- brak skilla u uczestników projektu,
- problemy kadrowe,
- problemy polityczne (wieczna wojna dev vs tester),
- nieprawidłowe nastawienie i oczekiwania co do testowania,

> czynniki techniczne
- problemy ze zdefiniowaniem poprawnych wymagań,
- środowisko testowe nie jest gotowe na czas,
- niska jakość projektu kodu, danych konfiguracyjnych, danych testowych i samych testów,

> problemy z dostawcami
- niewywiązywanie się dostawców ze zobowiązań,
- problemy z kontraktami.

Podczas analizowania, zarządzania i łagodzenia powyższych obszarów ryzyka kierownik testów postępuje według uznanych zasad kierowania projektami.

!Obszar ryzyka produktowego

Potencjalne obszary wystąpienia awarii w oprogramowaniu lub systemie nazywane są ryzykiem produktowym, ponieważ stanowią zagrożenie dla jakości produktu. Mogą to być m.in.:

- dostarczanie awaryjnego oprogramowania,
- możliwość wyrządzenia szkody człowiekowi lub firmie przez oprogramowanie lub sprzęt,
- niedostateczne atrybuty oprogramowania (np. niezawodność, funkcjonalność, wydajność etc.),
- niska jakość lub brak spójności danych (np. problemy z ich migracją, konwersją, przekazywaniem),
- oprogramowanie, które nie spełnia założonych funkcji.

Ryzyka używa się do określenia, kiedy rozpocząć testowanie oraz co powinno zostać dokładniej przetestowane. Samo testowanie jest wykorzystywane do zredukowania ryzyka wystąpienia niekorzystnych zdarzeń lub do zredukowania ich wpływu (jakbyście jeszcze nie wiedzieli).

Testowanie jako działanie kontrolujące ryzyko dostarcza informacji na temat istniejących obszarów ryzyka przez pomiar skuteczności usuwania krytycznych usterek oraz planów awaryjnych.

Oparte na ryzyku podejście do testowania umożliwia w sposób aktywny obniżanie ryzyka produktowego rozpoczynając już od wstępnej fazy projektu. Zawiera ono identyfikacje obszarów ryzyka produktowego, co umożliwia użycie ich jako wskazówek w planowaniu i kontroli testów, ich przygotowywaniu i wykonaniu. W podejściu do testów opartych na ryzyku zidentyfikowane obszary ryzyka mogą zostać wykorzystane do:

- określenia technik testowania, które powinny zostać użyte,
- określenia zakresu testów,
- priorytetyzacji testów w celu znalezienia usterek krytycznych tak wcześnie, jak to tylko możliwe,
- określenie, czy nie można użyć działań niezwiązanych z testowaniem w celu redukcji ryzyka.

Testowanie oparte na ryzyku bazuje na grupowej wiedzy i obserwacji wykonawców projektu w celu określenia obszarów ryzyka oraz poziomów testowania wymaganych, żeby odnieść się do nich.

W celu zapewnienia minimalizacji szansy wystąpienia awarii produktu, zarządzanie ryzykiem daje zdyscyplinowane podejście do:

- oceny co może pójść nie tak,
- ustalenia, którymi obszarami ryzyka należy się zająć,
- wdrożenia działań zarządzających tymi obszarami ryzyka.

Dodatkowo testy mogą wspierać identyfikację nowych obszarów ryzyka, mogą pomóc w ustaleniu, które obszary ryzyk powinny zostać zminimalizowane oraz mogą zmniejszyć niepewność co do ryzyka.

Kandydat zna zawartość raportu incydentu zgodnie ze standardem dokumentacji testowania oprogramowania. Potrafi napisać raport incydentu zawierający opis awarii zaobserwowanej podczas testowania.

Ponieważ jednym z celów testowania jest znajdowanie usterek, rozbieżności pomiędzy oczekiwaniami i rzeczywistymi wynikami muszą być zapisywane jako incydenty. Incydenty powinny być analizowane, bo może się okazać, że stanowią defekty. Odpowiednie czynności, mówiące jak należy postępować z incydentami i defektami, powinny zostać zdefiniowane. Incydenty i defekty muszą być śledzone od momentu wykrycia i klasyfikacji do naprawy i potwierdzenia rozwiązania. Żeby być w stanie zarządzać wszystkimi incydentami aż do ich zamknięcia, organizacja powinna wprowadzić proces zarządzania incydentami oraz reguły klasyfikacji.

Incydenty można zgłaszać podczas programowania, przeglądów, testowania lub użytkowania produktu. Mogą to być problemy w kodzie lub działającym systemie oraz dokumenty dowolnego typu, wymagań, dokumentów deweloperskich, dokumentów testowych lub informacji dla użytkownika takich jak pomoc lub instrukcja instalacji.

Raporty incydentów istnieją w celu:

- dostarczenia programistom i innym stronom informacji na temat problemów tak, aby umożliwić ich identyfikację, wyodrębnienie i naprawę. 

- dostarczenia liderom testów środków do śledzenia jakości testowanego systemu oraz postępów testów,

- dostarczenia pomysłów na doskonalenie procesu testowania.

!Raport incydentów może zawierać takie szczegóły, jak:

- datę zgłoszenia, organizacje zgłaszającą i imię autora,

- wyniki oczekiwane oraz rzeczywiste,

- wskazanie na element testowy oraz na środowisko,

- SLC w którym incydent został zaobserwowany,

- opis incydentu (w celu odtworzenia i rozwiązania, włącznie z logami, zrzutami ekranu oraz baz danych),

- obszar lub stopień wpływu na interesy interesariuszy,

- stopień wpływu na system,

- pilność, priorytetyzowanie naprawy,

- status incydentu (np. otwarty, duplikat, oczekujący na naprawę, poprawiony, oczekujący na retest, zamknięty),

- podsumowania, rekomendacje oraz zgody,

- zagadnienia globalne, takie jak inne obszary, na które mogą mieć wpływ zmiany związane z incydentem,

- historię zmian np. ciąg czynności podjętych przez zespół w celu wyizolowania incydentu,

- referencję, włączając w to identyfikator specjalizacji przypadku testowego, który wykrył problem.

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

Uff, wszystko z zarządzania testami. Zwróćcie uwagę zwłaszcza na raportowanie incydentów. Jako przyszli testerzy poznacie tę sztukę, gwarantuję wam to : )

Zostaje nam jeszcze jedna kwestia - następna i zarazem ostatnia część kursu traktująca o narzędziach wpierających testowanie. Postaram się, żeby była jeszcze dzisiaj ale najpierw skoczę na basen. Muszę odświeżyć umysł i dać sobie dla odmiany trochę innego wycisku, niźli ten umysłowy ;)

Trzymajcie się, ej!

F.