Redakcja
Wybrane aspekty zarządzania testowaniem.
Niezależność organizacyjna testów
Efektywność w znajdowaniu defektów może zostać poprawiona dzięki niezależnej grupie testowej.
Wyróżniamy następujące typy niezależności:
- niezależny tester wewnątrz grup programistów
- niezależna grupa testowa lub po prostu grupa wewnątrz organizacji, raportująca do kierownika projektu lub zarządu
- niezależność testera od organizacji biznesowej, społeczności użytkowników czy działu IT
- specjalista testów niezależny od testerów takich jak testerzy użyteczności, bezpieczeństwa czy certyfikacji (certyfikujący produkt zgodnie ze standardami i regulacjami)
- niezależny tester spoza organizacji.
Dla potrzeb skomplikowanych i rozbudowanych projektów najlepsze jest stosowanie testowania na każdym poziomie przez niezależną grupę testową. Programiści mogą uczestniczyć w procesie testowym, szczególnie na niskich poziomach, ale ich brak obiektywności często skutkuje ich niską skutecznością. Niezależny tester może mieć umiejętności wymagane i zdefiniowane w procesie testowym, ale nade wszystko koniecznie powinien on mieć mandat do wykonania wszystkich zadań związanych z przypisanymi mu obowiązkami nadany mu przez kierownictwo.
Korzyści płynące z niezależności to:
- postrzeganie różnych defektów w sposób bezstronny
- weryfikacja założeń wprowadzanych przez ludzi zajmujących się specyfikacją i implementacją systemu. Istnieją również negatywne aspekty:
- izolacja od programistów (w przypadku pełnej niezależności)
- niezależny tester może być zwężeniem a przez to opóźniać projekt jako jego ostatni punkt kontrolny
- programiści przestają przejmować się jakością wiedząc, że ktoś i tak ich sprawdzi (ewentualnie zaproponuje poprawki).
Zadanie testowe są wykonywane przez ludzi o określonych rolach, ale mogą one być również wykonywane przez ludzi na innych stanowiskach jak np. kierownik projektu, kierownik jakości, programista, ekspert biznesowy lub pracownicy IT.
- Zadania lidera i testera
- Zadanie i obowiązki ludzi na tych dwóch kluczowych stanowiskach zależą od projektu i sytuacji wokół produktu. Zależą również od ludzi na konkretnych stanowiskach i struktury samej organizacji.
Czasami liderzy testowi nazywani są kierownikami testów lub koordynatorami testów. Zadania lidera mogą być wykonywane przez kierownika projektu, kierownika programistycznego, kierownika ds. zapewnienia jakości lub kierownika grupy testowej. W dużych projektach zazwyczaj rozróżniamy dwa stanowiska: lider i kierownik testów. Lider zazwyczaj planuje, monitoruje i kontroluje czynności testowe.
Zadania lidera grupy testowej:
- planowanie i koordynacja strategii wraz z kierownikiem projektu i innymi udziałowcami
- pisanie i przegląd strategii testów dla projektów oraz polityki testowej dla organizacji
- stosowanie perspektywy testów dla innych aktywności testowych takich jak planowanie integracji
- planowanie testów - rozważanie kontekstu i rozumienie ryzyka - włączając w to wybór metod testowych, szacowanie czasu, wysiłku i kosztów testowania; zdobywanie zasobów, definiowanie poziomów testowych, cykli, metodologii i celów oraz planowanie zarządzania przypadkami
- inicjowanie, specyfikacja, przygotowanie, implementacja i wykonanie testów oraz późniejsze ich monitorowanie i kontrola
- korekty planowania oparte na wcześniejszych planach w odniesieniu do postępu testów (czasami udokumentowanych w statusie) oraz podjęcie niezbędnych czynności dla kompensacji problemów
- dla ułatwienia śledzenia wersji ustanowienie adekwatnego zarządzania konfiguracją dla narzędzi testowych
- decydowanie, co powinno być zautomatyzowane, do jakiego stopnia oraz jak powinno to być przeprowadzone
- zaproponowanie dopasowanych miar dla pomiarów postępu testowego oraz szacowania jakości testowania oraz jakości produktu
- decydowanie o implementacji środowiska testowego
- rozpisanie na osi czasu testów
- pisanie raportów podsumowujących testy, opartych na informacjach zebranych podczas testowania.
Typowe zadania testera:
- przegląd i własny wkład w plany testów
- analiza, przegląd i ocena wymagań użytkowników, specyfikacji i modeli pod kątem testowalności
- tworzenie specyfikacji testowej
- ustanowienie środowiska testowego (często koordynacja z administratorem systemu i sieci)
- przygotowanie i zdefiniowanie danych testowych
- implementowanie testów na wszystkich poziomach testowych, wykonanie i zapisywanie wyników testów, ocena wyników i dokumentacja różnic w stosunku do oczekiwanego rezultatu
- użycie narzędzi administrowania, zarządzania i monitorowania testów
- automatyzacja testów (wspierana programistami lub ekspertami od automatyzacji testów)
- pomiar wydajności komponentów systemu (gdy wymagane)
- przegląd i sprawdzenie testów napisanych przez innych.
Ludzie pracujący nad analizą, projektowaniem i automatyzacją testów mogą być specjalistami w tych zadaniach. W zależności od poziomu testowego oraz ryzyka powiązanego z produktem i projektem, różni ludzie mogą przyjmować zadania testerów, zachowując ciągle niezależność.
Typowo testerzy na poziomie komponentu lub integracji będą programistami, testerzy na poziomie testów akceptacyjnych będą ekspertami biznesowymi i użytkownikami, a testerzy operacyjnych testów akceptacyjnych będą po prostu operatorami.
Planowanie testów
Ta część podejmuje się zdefiniować cel planowania testów wewnątrz projektu tworzenia oprogramowania, implementacji i potrzeb serwisowych. Planowanie może być udokumentowane w projektowym lub głównym planie testów lub oddzielnym planie testów stworzonym specjalnie dla poszczególnych poziomów testowych, takich jak testowanie systemu i testowanie akceptacyjne. Dokładne wskazówki jak planować testy można znaleźć w "Standard for Software Test Documentation" (IEEE 829).
Na planowanie wpływa polityka testów organizacji, zakres testowanie, cele, ryzyko, ramy, ważność, testowalność i dostępność zasobów. Czym bardziej planowanie projektu i testów jest zaawansowane tym więcej informacji jest dostępnych i więcej szczegółów może zostać dołączonych do planów.
Planowanie testów jest ciągłą czynnością wykonywaną w ciągu trwania cyklu życia projektu. Informacja zwrotna z czynności testowych jest użyta do rozpoznania ryzyka tak by planowanie mogło być dopasowane do rzeczywistych warunków.
Czynności związane z planowaniem testów obejmują:
- zdefiniowanie ogólnej metody testowej (strategia testów), włączając w to definiowanie poziomów testowych oraz kryteriów rozpoczęcia i zakończenia testów
- integracja i koordynacja czynności testowych w ramach cyklu tworzenia oprogramowania: zakupu, dostarczenia, rozwoju, operacji i serwisu
- dokonywanie decyzji o tym co należy testować, kto ma wykonywać każdą z czynności testowych, kiedy i jak czynności testowe powinny być wykonane, jak wyniki testów będą analizowane i kiedy przerwać testowanie (kryterium wyjścia)
- przypisanie zasobów dla różnych, zdefiniowanych zadań
- definiowanie ilości, poziomu dokładności, struktury i wzorców dokumentacji testowej
- wybór miar dla monitorowania i kontrolowania przygotowania testów, rozwiązywania problemu defektów oraz oceny ryzyka
- ustanawianie poziomu dokładności dla procedur testowych w celu dostarczenia wystarczającej informacji do wsparcia reprodukowalnych czynności przygotowania i wykonania testów
- Kryterium zakończenie testów
- Celem definiowania kryterium zakończenia testów jest określenie kiedy przerwać testowanie, na różnych poziomach lub kiedy zestaw testów zostanie wyczerpany.
Kryterium wyjścia zawiera:
- dokładne metryki takie jak pokrycie kodu, funkcjonalności lub ryzyka
- kalkulacja ilości defektów w stosunku do tych, możliwych do wystąpienia lub miary niezawodności
- koszty
- pozostałe ryzyko, takiej jak nie naprawione defekty, niepełne pokrycie testów w określonym obszarze
- rozpiska planów w czasie, takich jak data dostarczenia produktu na rynek.
- Ocena testów
- Dwie metody oceny wysiłku testowego:
- ocena wysiłku testowego oparta na metrykach poprzedniego lub podobnego projektu lub oparte na znanych, typowych wartościach
- ocena zadań dokonana przez właściciela tych zadań lub przez eksperta.
Kiedy wysiłek zostanie już oceniony, zasoby mogą zostać określone oraz można przygotować plan działań.
Wysiłek testowy zależy od różnych czynników takich jak:
- parametry produktu: jakość specyfikacji i innych informacji użytych dla modeli testowych, rozmiar produktu, złożoność obszaru problemu, wymagań niezawodności i bezpieczeństwa, wymagań względem dokumentacji
- parametry procesu rozwoju oprogramowania: stabilność organizacji, użyte narzędzia, procesy testowe, umiejętności ludzi zaangażowanych w projekt oraz presja czasu
- wynik testowania: ilość znalezionych defektów i ilość wymaganych poprawek
- Strategia testów
- Jedna z metod klasyfikacji strategii testów jest oparte na okresie czasu w którym największe nawał pracy w projektowaniu testów się rozpoczyna:
- metoda prewencji, gdzie testy projektowane są jak najwcześniej
- metoda reaktywna, gdzie testy projektowane są po wyprodukowaniu oprogramowania lub systemu.
Do typowych metod lub strategii zaliczamy:
- analityczne metody oparte na ryzyku testowym gdzie testowanie jest ukierunkowane na obszary najbardziej narażone na ryzyko wystąpienia błędów
- metody oparte na modelu takie jak testowanie stochastyczne z użyciem informacji statystycznych o kalkulacji problemów występujących po wystąpieniu defektów
- metodologiczne takie jak oparte na konsekwencjach błędów (włączając w to zgadywanie błędów), oparte na punktach kontrolnych, oparte na jakości parametrów
- metody zgodne z procesami i standardami, takie jak te opisane przez standardy przemysłowe lub różne metodologie Agile
- metody dynamiczne, takie jak wyczerpujące testowanie gdzie testowanie jest bardziej konsekwencją zdarzeń poprzednio zaplanowanych i gdzie wykonywanie i ocenianie są równoległymi zadaniami
- metody konsultatywne, kierowane wcześniejszą radą, przy pomocy przewodnika technologicznego i/lub obszarem biznesowych ekspertyz wykonanych poza zespołem testowym
- metody regresywne takie jak ponowne użycie materiałów testowych, automatyzacji testów regresji oraz standardów testowych.
Różne metody mogą być ze sobą łączone np. dynamiczne metody oparte na ryzyku.
Wybór strategii powinien być poprzedzony rozważaniem kontekstu:
- ryzyka wystąpienia konsekwencji błędów w projekcie, niebezpieczeństwo dla produktu i ryzyko narażenia bezpieczeństwa użytkownika, środowiska lub firmy
- umiejętności i doświadczenie ludzi w zaproponowanych technikach, narzędziach i metodach
- cele zdolności testowania i misja zespołu testowego
- aspekty regulujące takie jak wewnętrzne i zewnętrzne regulacje dla procesu tworzenia oprogramowania
- natura produktu i biznesu.
