CTFL2011 Zarządzanie testowaniem
Z AmberPlace
|
| K3 285min |
Cele nauczania dla zarządzania testami.
Te cele określają co będziesz potrafił po zakończeniu modułu.
- LO-5.1.1 Kandydat uznaje wagę testowania niezależnego. (K1)
- LO-5.1.2 Kandydat potrafi wyjaśnić korzyści i wady niezależnego testowania w organizacji. (K2)
- LO-5.1.3 Kandydat uznaje potrzebę włączenia różnych członków zespołu podczas tworzenia zespołu testerskiego. (K1)
- LO-5.1.4 Kandydat pamięta zadania typowego lidera testów oraz testera. (K1)
5.2 Planowanie i szacowanie testów (K2)
- LO-5.2.1 Kandydat rozpoznaje różne poziomy i cele planowania testów. (K1)
- LO-5.2.2 Kandydat potrafi omówić krótko cel i zawartość planu testów, projektu testów, procedury testowej zgodnie ze standardem dokumentacji testowania oprogramowania ("Standard for Software Test Documentation" IEEE STD 829-1998). (K2)
- LO-5.2.3 Kandydat rozróżnia odmienne podejścia do testowania, takie jak analityczne, oparte na modelach, metodyczne, zgodne z procesem lub standardem, dynamiczne/heurystyczne, konsultatywne oraz regresywne. (K2)
- LO-5.2.4 Kandydat odróżnia planowanie testów systemu od harmonogramowania ich wykonania. (K2)
- LO-5.2.5 Kandydat potrafi napisać harmonogram wykonania testów dla danego zbioru przypadków testowych, uwzględniając ich priorytety oraz zależności logiczne i techniczne. (K3)
- LO-5.2.6 Kandydat potrafi wymienić czynności przygotowania i wykonania testów, które należy wziąć pod uwagę przy planowaniu. (K1)
- LO-5.2.7 Kandydat pamięta typowe czynniki, które mają wpływ na pracochłonność testowania. (K1)
- LO-5.2.8 Kandydat odróżnia od siebie dwa koncepcyjnie odmienne podejścia do szacowania: podejścia bazujące na metrykach i podejścia wykorzystujące ekspertów. (K2)
- LO-5.2.9 Kandydat potrafi rozpoznać i uzasadnić odpowiednie kryteria wejścia oraz zakończenia konkretnych poziomów testowania oraz grup przypadków testowych (np. testów integracyjnych, testów akceptacyjnych lub przypadków testowych w testach użyteczności). (K2)
5.3 Monitorowanie postępu testów i nadzór (K2)
- LO-5.3.1 Kandydat potrafi wskazać najczęściej używane metryki do monitorowania przygotowania i wykonania testów. (K1)
- LO-5.3.2 Kandydat potrafi wyjaśnić i porównać metryki stosowane w raportowaniu i kontroli testów (np. znalezione i poprawione usterki, zaliczone i niezaliczone testy). (K2)
- LO-5.3.3 Kandydat potrafi omówić krótko cel i zawartość raportu podsumowującego testy zgodnie ze standardem dokumentacji testowania oprogramowania (IEEE STD 829-1998). (K2)
5.4 Zarządzanie konfiguracją (K2)
- LO-5.4.1 Kandydat potrafi opisać krótko, w jaki sposób zarządzanie konfiguracją wspiera testowanie. (K2)
- LO-5.5.1 Kandydat potrafi opisać ryzyko jako potencjalny problem, który zagrażałby osiągnięciu celów projektowych jednego lub kliku interesariuszy projektu. (K2)
- LO-5.5.2 Kandydat pamięta, że poziom ryzyka jest określany przez prawdopodobieństwo wystąpienia oraz wpływ (potencjalną szkodę, jaką może uczynić gdy wystąpi). (K1)
- LO-5.5.3 Kandydat rozróżnia elementy ryzyka projektowego i produktowego. (K2)
- LO-5.5.4 Kandydat rozpoznaje typowe elementy ryzyka projektowego i produktowego. (K1)
- LO-5.5.5 Kandydat potrafi opisać przy użyciu przykładów jak analiza ryzyka i zarządzanie ryzykiem mogą zostać wykorzystane przy planowaniu testów. (K2)
5.6 Zarządzanie incydentami (K3)
- LO-5.6.1 Kandydat uznaje zawartość raportu incydentu zgodnie ze standardem dokumentacji testowania oprogramowania (IEEE STD 829-1998). (K1)
- LO-5.6.2 Kandydat potrafi napisać raport incydentu zawierający opis awarii zaobserwowanej podczas testowania. (K3)
5.1 Organizacja testów
| K2 30min |
| Pojęcia |
|---|
| tester, lider testów, kierownik testów |
5.1.1 Organizacja testów a ich niezależność
Skuteczność wykrywania usterek w testach i przeglądach może zostać podniesiona przez zaangażowanie niezależnych testerów. Niezależność może występować w różnych wariantach, włączając w to następujące:
- brak niezależnych testerów, programiści testują swój własny kod
- niezależni testerzy wewnątrz zespołu projektowego
- niezależny zespół testowy lub grupa testerów wewnątrz organizacji podlegająca kierownikowi projektu lub zarządowi
- niezależni testerzy z departamentów biznesowych lub społeczności użytkowników
- niezależni specjaliści od określonych typów testów takich jak użyteczności, zabezpieczeń lub certyfikacji oprogramowania (którzy przeprowadzają certyfikację oprogramowania na zgodność z regulacjami prawnymi lub standardami)
- niezależni testerzy, którzy zostali wynajęci lub są na zewnątrz organizacji
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 ograniczają skuteczność tych testów. Niezależni testerzy mogą zostać upoważnieni do zdefiniowania i egzekwowania procesu testowania i ról z nim związanych, ale powinni to robić tylko w przypadku posiadania zdecydowanego poparcia ze strony kierownictwa.
Korzyści z niezależności:
- niezależni testerzy widzą inne i odmienne usterki oraz nie mają uprzedzeń
- niezależny tester może zweryfikować założenia poczynione podczas specyfikacji i implementacji systemu
Wady niezależności:
- izolacja od zespołu deweloperskiego (jeżeli niezależność jest całkowita)
- programiści mogą utracić poczucie odpowiedzialności za jakość
- niezależni testerzy mogą być postrzegani jako wąskie gardło lub obwiniani za opóźnienia w wydaniach
Zadania związane z testowaniem mogą być wykonywane przez ludzi pełniących konkretne role testerskie lub przez ludzi pełniących inne role np. kierownika projektu, menedżera jakości, programistę, eksperta biznesowego lub dziedzinowego, ludzi związanych z serwisem operacyjnym lub IT.
5.1.2 Zadania lidera testów oraz testera
| K2 |
W tym sylabusie zostały omówione dwie role testerskie: lider testów oraz tester. Zadania wykonywane przez ludzi pełniących te dwie role zależą od kontekstu projektowego i produktowego, pełniących te role oraz organizacji.
Czasami lider testów nazywany jest kierownikiem testów lub koordynatorem testów. Rolę lidera testów może pełnić kierownik projektu, kierownik zespołu wytwórczego[1], kierownik zapewnienia jakości lub kierownik zespołu testowego. W większych projektach mogą być obecne dwa stanowiska: lidera oraz kierownika testów. Zwykle to lider testów planuje, monitoruje i kontroluje zadania testowe i czynności tak jak to było podane w podrozdziale 1.4.
Typowe zadania lidera testów to:
- koordynowanie strategii oraz planu testów z kierownikami projektu i innymi interesariuszami
- tworzenie lub przeglądanie strategii testów w projekcie oraz polityki testowania w organizacji
- przedstawianie perspektywy testowania w innych zadaniach projektowych takich jak planowanie integracji
- 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 oraz sprawdzanie spełnienia kryteriów zakończenia
- zmiana planów z uwzględnieniem wyników oraz postępu testów (czasami udokumentowanego w raporcie statusu testów), a także podejmowanie działań koniecznych do rozwiązania problemów
- zorganizowanie odpowiedniego zarządzania konfiguracją testaliów w celu zwiększenia możliwości śledzenia powiązań
- wprowadzenie odpowiednich metryk do mierzenia postępu testów i oceny jakości testowania oraz produktu
- decydowanie co powinno zostać zautomatyzowane, w jakim stopniu i w jaki sposób
- wybór narzędzi wspierających testy oraz organizacja dla testerów szkoleń z użycia tych narzędzi
- decydowanie o implementacji środowiska testowego
- sporządzanie raportów podsumowujących testy bazując na informacjach zebranych podczas testów
Typowe zadania testera to:
- 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 (często jest to koordynacja pracy administratorów oraz osób odpowiedzialnych za sieć)
- przygotowanie i pozyskanie danych testowych
- implementacja testów na wszystkich poziomach, wykonanie i logowanie testów, ocena wyników oraz dokumentowanie odchyleń od oczekiwanych wyników
- używanie narzędzi do administracji lub zarządzania testami oraz narzędzi do monitorowania testów, gdy jest to wymagane
- automatyzacja testów (może być wspierana przez programistę lub eksperta od automatyzacji testów)
- pomiar wydajności modułów i systemów (o ile ma zastosowanie)
- przeglądanie testów wytworzonych przez innych
Ludzie, którzy pracują nad analizą testów, projektowaniem testów, konkretnymi typami testów lub ich automatyzacją mogą być specjalistami w swoich rolach. W zależności od poziomu testów oraz ryzyka produktowego i projektowego, różne osoby mogą pełnić rolę testera, będąc do pewnego stopnia niezależnymi. Na poziomach modułowym i integracyjnym testerami zwykle będą programiści, na poziomie testów akceptacyjnych testerami mogą być eksperci biznesowi oraz użytkownicy, a testerami w produkcyjnych testach akceptacyjnych często są operatorzy.
5.2 Planowanie i szacowanie testów
| K3 40min |
| Pojęcia |
|---|
| podejście do testów, strategia testów |
5.2.1 Planowanie testów
| K2 |
Podrozdział ten wyjaśnia cel planowania testów w projektach deweloperskich i wdrożeniowych oraz czynności pielęgnacyjnych. Planowanie może zostać udokumentowane w głównym planie testów lub w oddzielnych planach testów dla każdego poziomu np. dla testów systemowych oraz testów akceptacyjnych. Schematy dokumentów planistycznych dla testów zawarte są w dokumencie "Standard for Software Test Documentation" IEEE STD 829-1998.
Na planowanie testów wpływ ma polityka testowania w organizacji, zakres testów, cele, ryzyko, ograniczenia, krytyczność, testowalność oraz dostępność zasobów. Im dłużej trwa planowanie projektu i 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ń cyklu życia oprogramowania. 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.
5.2.2 Czynności związane z planowaniem testów
| K2 |
W planowanie testów dla całego systemu lub jego części mogą wchodzić następujące czynności:
- ustalenie zakresu i ryzyka oraz zidentyfikowanie celów testowania
- zdefiniowanie ogólnego podejścia do 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 cyklu życia oprogramowania: zakupami, dostawami, rozwojem, działaniem produkcyjnym oraz pielęgnacją
- podejmowanie decyzji co testować, którym rolom będą przypisane które zadania testowe, jak zadania testowe powinny być wykonane oraz jak powinno się oceniać wyniki testów
- harmonogramowanie analizy i projektowania testów
- harmonogramowanie implementacji, wykonania i oceny testów
- przydzielanie zasobów do zdań testowych
- definiowanie ilości, poziomu szczegółowości, struktury oraz wzorców dokumentacji testowej
- wybór metryk do monitorowania i kontroli przygotowania i wykonania testów, naprawy defektów oraz elementów ryzyka
- decydowanie o poziomie szczegółowości procedur testowych, aby dostarczyć wystarczającą ilość informacji dla powtarzalnego przygotowania i wykonania testów
5.2.3 Kryteria wejścia
Kryteria wejścia definiują warunki 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
5.2.4 Kryteria zakończenia
| K2 |
Celem kryteriów zakończenia jest zdefiniowanie momentu zakończenia testów na danym poziomie lub gdy zbiór testów osiągnął określony 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 niezawodnoś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[2]
5.2.5 Szacowanie testów
| K2 |
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ń na podstawie oszacowań wykonanych przez ich przyszłych wykonawców lub przez ekspertów
Gdy pracochłonność zostanie już oszacowana można przyporządkowywać zasoby do zadań oraz szkicować harmonogram.
Pracochłonność testów może zależeć od wielu czynników, a w tym:
- cech produktu
- jakości specyfikacji oraz innych informacji używanych w modelach testowych (t.j. w podstawie testów), wielkości produktu, złożoności dziedziny problemu, wymagań na niezawodność oraz zabezpieczenie oraz 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
5.2.6 Podejście do testowania, strategia testowania
| K2 |
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. Zwykle zawiera decyzje podejmowane na podstawie celów projektu (testowego) 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.
Wybrane podejście zależy od kontekstu i może uwzględniać ryzyka, niebezpieczeństwa oraz wymagane bezpieczeństwo, dostępne zasoby oraz umiejętności, technologię, naturę systemu (np. system pod klucz vs. z półki), cele testów i uregulowania prawne.
Typowe podejścia do testów to:
- 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[3] (takich jak modele wzrostu niezawodności oprogramowania) lub wykorzystania oprogramowania (takich jak profile operacyjne)
- podejścia metodyczne, takie jak podejścia oparte na awariach (włącznie ze zgadywaniem błędów i atakami usterkowymi), 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 lub metodyki zwinne
- 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 wykonywanie 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.
5.3 Monitorowanie postępu testów i nadzór
| K2 20min |
| Pojęcia |
|---|
| gęstość błędów , współczynnik awarii , kontrola testów, monitorowanie testów, raport podsumowujący testy |
5.3.1 Monitorowanie postępu testów
| K1 |
Celem monitorowania 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.
Często wykorzystywanymi metrykami są:
- procent pracy wykonanej przy przygotowywaniu przypadków testowych lub odsetek przygotowanych przypadków testowych
- procent prac wykonanych przy przygotowywaniu środowiska testowego
- wykonanie przypadków testowych (np. liczba wykonanych/nie wykonanych przypadków testowych oraz liczba przypadków testowych zaliczonych/niezaliczonych)
- informacje o usterkach (np. gęstość błędów, defekty znalezione i poprawione, współczynnik awarii oraz wyniki testów)
- 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
5.3.2 Raportowanie testów
| K2 |
Raportowanie testów podaje podsumowanie projektu testowego, a w tym:
- co się zdarzyło 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
Zarys raportu podsumowującego testy przedstawiony jest w dokumencie „Standard for Software Documentation” (IEEE STD 829-1998).
Pomiary 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
5.3.3 Kierowanie testami
| K2 |
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 cyklem życia oprogramowania.
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. oprogramowania zostanie dostarczone 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 (wykonał testy potwierdzające) zanim włączy je do wydania
5.4 Zarządzanie konfiguracją
| K2 10min |
| Pojęcia |
|---|
| zarządzanie konfiguracją, kontrola wersji |
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 cykl życia produktu.
Z punktu widzenia testowania, zarządzanie konfiguracją może wymagać zapewnienia, że:
- wszystkie elementy oprogramowania zostały zidentyfikowane, poddane kontroli wersji, są śledzone, powiązane między sobą oraz z elementami deweloperskimi (przedmiotem testów), tak żeby można utrzymać możliwość śledzenia zmian i powiązań[4] przez cały proces testowy
- odwołania w dokumentacji testowej do wszystkich zidentyfikowanych dokumentów oraz elementów softwarowych są jednoznaczne
Zarządzanie konfiguracją 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 infrastruktura (narzędzia).
5.5 Ryzyko a testowanie
| K2 30 min |
| Pojęcia |
|---|
| ryzyko produktowe, ryzyko projektowe, ryzyko, testowanie oparte na ryzyku |
Ryzyko może zostać zdefiniowane, jako możliwość wystąpienia zdarzenia, niebezpieczeństwa, zagrożenia lub jakiejś sytuacji powodującej niepożądane konsekwencje lub potencjalny 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).
5.5.1 Obszary ryzyka projektowego
| K2 |
Ryzyko projektowe, to obszary ryzyka otaczające zdolność projektu do osiągnięcia postawionych przed nim celów, takie jak:
- czynniki organizacyjne
- braki w umiejętnościach, szkoleniach lub personelu
- problemy kadrowe
- problemy polityczne takie jak:
- problemy z testerami komunikującymi swoje potrzeby oraz wyniki testów
- brak reakcji zespołu w związku z informacjami pozyskanymi podczas testów i przeglądów (np. brak doskonalenia procesów produkcji i testowania)
- nieprawidłowe nastawienie i oczekiwania od testowania (np. niedocenianie wartości znajdowania błędów podczas testowania)
- problemy techniczne
- problemy ze zdefiniowaniem poprawnych wymagań
- stopień, w jakim wymagania mogą zostać spełnione przy istniejących ograniczeniach
- środowisko testowe niegotowe na czas
- spóźniona konwersja danych, planowanie migracji oraz rozwój i testowanie narzędzi do migracji i konwersji danych
- niska jakość projektu, kodu, danych konfiguracyjnych, danych testowych i 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. Wzorzec planu testów ze standardu „Standard for Software Documentation” (IEEE STD 829-1998) wymaga wymienienia elementów ryzyka oraz zabezpieczeń przed nimi.
5.5.2 Obszary ryzyka produktowego
| K2 |
Potencjalne obszary wystąpienia awarii (przyszłych niekorzystnych zdarzeń lub niebezpieczeństw) w oprogramowaniu lub systemie nazywane są ryzykiem produktowym, ponieważ stanowią ryzyko dla jakości produktu. Mogą to być:
- dostarczanie awaryjnego oprogramowania
- możliwość wyrządzenia szkody człowiekowi lub firmie przez oprogramowanie lub sprzęt
- niedostateczne atrybuty oprogramowania (np. funkcjonalność, niezawodność, użyteczność lub wydajność)
- niska jakość i spójność danych (np. problemy z migracją danych, problemy z konwersją danych, problemy z przekazywaniem danych, naruszenie standardów danych)
- 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. Testowanie jest wykorzystywane do zredukowania ryzyka wystąpienia niekorzystnych zdarzeń lub do zredukowania ich wpływu.
Obszary ryzyka produktowego są specjalnym rodzajem ryzyka produktowego. 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 proaktywny obniżanie ryzyka produktowego poczynając już od wstępnej fazy projektu. Zawiera ono identyfikację obszarów ryzyka produktowego, co umożliwia użycie ich jako przewodnika w planowaniu i kontroli testów, specyfikacji, przygotowaniu oraz wykonaniu testów. W podejściu do testów opartym 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ślenia, czy nie można użyć działań niezwiązanych z testowaniem w celu redukcji ryzyka (np. przeszkolenie niedoświadczonych projektantów)
Testowanie oparte na ryzyku bazuje na grupowej wiedzy i obserwacjach interesariuszy 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 (powtarzanej regularnie), co może pójść nie tak (ryzyka)
- 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.
5.6 Zarządzanie incydentami
| K3 40min |
| Pojęcia |
|---|
| rejestracja incydentu, zarządzanie incydentami, raport o incydencie |
Ponieważ jednym z celów testowania jest znajdowanie usterek, rozbieżności pomiędzy oczekiwanymi i rzeczywistymi wynikami muszą być zapisywane jako incydenty. Incydenty powinny być analizowane i 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 powinny 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 softwarowego. Mogą być zgłoszone dla problemów w kodzie lub działającym systemie, a także dla dokumentów dowolnego typu, czyli 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, aby umożliwić identyfikację, wyodrębnienie i naprawę jeżeli okaże się to konieczne
- dostarczenia liderom testów środków do śledzenia jakości testowanego systemu oraz postępu testów
- dostarczenia pomysłów na doskonalenie procesu testowania
Raport incydentów może zawierać następujące szczegóły:
- datę zgłoszenia, zgłaszającą organizację oraz autora
- wyniki oczekiwane oraz rzeczywiste
- wskazanie na element testowy (element konfiguracji) oraz na środowisko
- proces cyklu życia oprogramowania lub systemu w którym incydent został zaobserwowany
- opis incydentu, w celu umożliwienia odtworzenia i rozwiązania, włącznie z logami, zrzutami baz danych oraz zrzutami ekranu
- obszar lub stopień wpływu na interesy interesariuszy
- stopień wpływu na system
- pilność, priorytet naprawy
- status incydentu (np. otwarty, odłożony, duplikat, oczekujący na naprawę, naprawiony i 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
- historia zmian, np. ciąg czynności podjętych przez członków zespołu w celu wyizolowania incydentu, jego naprawy oraz potwierdzenia tej naprawy
- referencje, włączając w to identyfikator specyfikacji przypadku testowego, który wykrył problem
Struktura raportu incydentu jest również przedstawiona w dokumencie „Standard for Software Test Documentation” (IEEE STD 829-1998).
Literatura
| 5.1.1 | Black, 2001, Hetzel, 1998 |
| 5.1.2 | Black, 2001, Hetzel, 1998 |
| 5.2.5 | Black, 2001, Craig, 2002, IEEE STD 829-1998, Kaner 2002 |
| 5.3.3 | Black, 2001, Craig, 2002, Hetzel, 1998, IEEE STD 829-1998 |
| 5.4 | Craig, 2002 |
| 5.5.2 | Black, 2001, IEEE STD 829-1998 |
| 5.6 | Black, 2001, IEEE STD 829-1998 |
