Test Maturity Model integration

TMMi®

Wytyczne dotyczące doskonalenia procesu testowego

wersja 1.3.

Opracowane przez TMMi Foundation

Redaktor: Erik van Veenendaal

Informacja o prawach autorskich:

Nieograniczona dystrybucja podlegająca prawu autorskiemu

Copyright © TMMi Foundation, Ireland

Informacje ogólne

Opracowano na podstawie TMMi Release 1.0.

Materiał TMMi Foundation jest dostarczany na zasadzie „w obecnym stanie”.

TMMi Foundation nie udziela żadnych gwarancji, zarówno jawnych, jak i domniemanych,

w odniesieniu do wszelkich kwestii, w tym (ale nie wyłącznie) gwarancji przydatności do określonego celu lub przydatności handlowej, wyłączności lub w odniesieniu do rezultatów uzyskanych w wyniku wykorzystania materiału. TMMi Foundation nie udziela żadnych gwarancji jakiegokolwiek rodzaju w odniesieniu do nienaruszania patentów, znaków towarowych lub praw autorskich.

Używanie jakichkolwiek znaków towarowych w niniejszym dokumencie nie ma na celu naruszenia praw właściciela znaku towarowego.

Udzielana jest zgoda na powielanie niniejszego dokumentu i przygotowanie prac będących pochodnymi tego dokumentu do użytku wewnętrznego, pod warunkiem, że do wszystkich reprodukcji i prac będących pochodnymi tego dokumentu dołączone zostaną oświadczenia

o prawach autorskich i adnotacja „brak gwarancji".

Wnioski o zgodę na powielanie niniejszego dokumentu lub przygotowanie prac będących pochodnymi tego dokumentu do użytku zewnętrznego i komercyjnego należy kierować do TMMi Foundation.

W dokumentacji TMMi Foundation są używane następujące zarejestrowane znaki towarowe

i znaki usługowe: CMM®, CMMI®, TMMSM, TMMi, IDEALSM, SCAMPISM, TMap®, TPI®, ISTQB® i TPI-Next®.

CMMI jest zarejestrowanym znakiem towarowym w ISACA, USA,a

IDEAL i SCAMPI są znakami usługowymi CMMI Institute, USA.

TMM jest zarejestrowanym znakiem usługowym Illinois Institute of Technology.

TMMi® jest zarejestrowanym znakiem towarowym TMMi Foundation, Wielka Brytania.

TMap, TPI i TPI-Next są zarejestrowanymi znakami towarowymi Sogeti, Niderlandy.

ISTQB® jest zarejestrowanym znakiem International Software Testing Qualifications Board.

Prawa autorskie wersji polskiej zastrzeżone dla © Stowarzyszenie Jakości Systemów Informatycznych (SJSI).

Tłumaczenie rozdziału 1:Arnika Hryszko, Jarosław Hryszko, Natalia Respekta, Jan Sabak, Karolina Zmitrowicz

Redakcja merytoryczna i korekta tłumaczenia:

Monika Petri-Starego

Tłumaczenie rozdziałów 2-6: Kontekst A. Wolski sp. k.

Redakcja merytoryczna i korekta tłumaczenia: Monika Petri-Starego, Sebastian Małyska

Tłumaczenie poprawek wprowadzonych do wersji 1.3.: Monika Petri-Starego

Współpracownicy

Doug Ashworth            (Wielka Brytania)

Stuart Baker                   (Wielka Brytania)

Clive Bates                  (Wielka Brytania)

Jan Jaap Cannegieter       (Niderlandy)

Laura Casci                   (Wielka Brytania)

Vicky Chen                   (Kanada)

Jerry E Durant                  (USA)

Akhila  E. K                  (Indie)

Attila Fekete                  (Szwecja)

Thomas George             (Indie)

Andrew Goslin                  (Wielka Brytania)

Murali Krishnan             (Indie)

Leanne Howard            (Australia)

Adrian Howes                  (Wielka Brytania)

Klaus Olsen                   (Dania)

Fran O’Hara                   (Irlandia)

Simon Lamers             (Niemcy)

Hareton Leung             (Hong Kong)

Robert Magnussion             (Szwecja)

Tang MiaoMiao            (Chiny)

Nico van Mourik             (Niderlandy)

Bill McGirr                   (USA)

Judy McKay                   (USA)

Mac Miller                   (Wielka Brytania)

Sandhya Nagaraj             (Indie)

Viswanathan Narayana Iyer      (Indie)

Adewunmi Okupe             (USA)

Piotr Piotrowski             (Polska)

Meile Posthuma            (Niderlandy)

Meeta Prakash             (Indie)

Alec Puype                   (Belgia)

Matthias Rasking             (Niemcy)

Howard Roberts            (Wielka Brytania)

Geoff Thompson             (Wielka Brytania)

Ella Shang                  (Chiny)

Greg Spindler                   (USA)

Tiruvallur Thattai Srivatsan       (Indie)

Narayanamoorthy Subramanian (Indie)

David Tracey                   (Wielka Brytania)

Erik van Veenendaal            (Bonaire, Małe Antyle)

Nathan Weller             (Wielka Brytania)

Brian Wells                   (Wielka Brytania)

Historia zmian

W tej sekcji podsumowano poprawki wprowadzone między wersją 1.0 a wydaniem 1.3 tego dokumentu. Sekcja ta ma charakter wyłącznie informacyjny.

Wersja

Uwagi

1.3.

Rozdział 1:

zaktualizowano do ostatniego statusu odnoszącego się do TMMi, dodano odniesienie do ankiety, mniejszą zależność od CMMI, a w sekcji zakresu dodano akapit dotyczący cyklu życia w celu odniesienia do Agile i DevOps.

Rozdział 3:

dostosowanie do terminologii i obszarów praktyki CMMI V2,

TMMi poziom 2:

przykłady dokumentów zaktualizowanych w celu dostosowania do ISO 29119-3 (polityka testów, strategia testów, plan testów, raport z testów, specyfikacja projektu testowego, specyfikacja przypadku testowego, specyfikacja procedury testowej, raport z incydentu testowego i dziennik testów).

TMMi poziom 3:

przykłady dokumentów zaktualizowanych w celu dostosowania do ISO 29119-3 (główny plan testów, specyfikacja projektu testowego, specyfikacja przypadku testowego, specyfikacja procedury testowej, raport z incydentu testowego i dziennik testów). Zaktualizowano niefunkcjonalne charakterystyki jakościowe w celu dostosowania do normy ISO 25010.

TMMi poziom 4:

Zaktualizowano niefunkcjonalne charakterystyki jakościowe w celu dostosowania do normy ISO 25010.

Słownik:

poprawienie zgodność ze Słownikiem ISTQB®, słownikiem CMMI V2

i normami międzynarodowymi (ISO 20246, ISO 25010, ISO 25040, ISO 29119-1, ISO 29119-3 i ISO 33061). Usunięto odniesienia do wycofanych norm.

Odniesienia zaktualizowane do nowszych wersji, usunięto nieużywane odwołania i dodano nowo używane odwołania.

1.2

W dokumencie wprowadzono tylko drobne aktualizacje na podstawie uwag otrzymanych z rynku. Brak większych zmian w poziomach dojrzałości, obszarach procesów, celach lub praktykach.

1.1

Wersja, którą opracowaliśmy w kontekście książki TMMi, która ma zostać opublikowana (wersja niepubliczna). W dokumencie wprowadzono tylko drobne aktualizacje w oparciu o defekty znalezione podczas edycji książki.

Spis treści:

HISTORIA ZMIAN

TEST MATURITY MODEL INTEGRATION (TMMI)

1.1.      WPROWADZENIE

1.2.      KONTEKST I HISTORIA

1.3.      ŹRÓDŁA

1.4.      ZAKRES TMMI

1.4.1. Inżynieria oprogramowania i systemów

1.4.2. Poziomy testów

1.4.3. TMMi oraz CMMI

1.4.4. Cykl życia

1.4.5. Oceny

1.4.6. Podejście usprawniające

2.      POZIOMY DOJRZAŁOŚCI TMMI

2.1.      OPIS OGÓLNY

2.2.      POZIOM 1.  WSTĘPNY

2.3.      POZIOM 2.  ZARZĄDZANY

2.4.      POZIOM 3.  ZDEFINIOWANY

2.5.      POZIOM 4.  MIERZALNY

2.6.      POZIOM 5.  OPTYMALIZACJA

3.  STRUKTURA TMMI

3.1.      ELEMENTY WYMAGANE, OCZEKIWANE I INFORMACYJNE

3.1.1. Elementy wymagane

3.1.2. Elementy oczekiwane

3.1.3. Elementy informacyjne

3.2.      ELEMENTY SKŁADOWE / KOMPONENTY TMMI

3.2.1. Poziomy dojrzałości

3.2.2. Obszary procesowe

3.2.3. Cel

3.2.4. Uwagi wstępne

3.2.5. Zakres

3.2.6. Cele szczegółowe

3.2.7. Cele ogólne

3.2.8. Praktyki szczegółowe

3.2.9. Przykładowe produkty pracy

3.2.10. Podpraktyki

3.2.11. Praktyki ogólne

3.2.12. Opracowanie praktyk ogólnych

3.2.13. Pomocnicze komponenty informacyjne

3.2.13.1. Uwagi

3.2.13.2. Przykłady

3.2.13.3. Odniesienia

3.3.      OGÓLNE CELE I PRAKTYKI

3.4.      OBSZARY PROCESOWE WSPIERAJĄCE OGÓLNE PRAKTYKI

3.5.      WSPARCIE OBSZARÓW PROCESOWYCH CMMI DLA TMMI

3.6.      OBSZARY PRAKTYK CMMI WERYFIKACJA, WALIDACJA  I PRZEGLĄDY KOLEŻEŃSKIE

POZIOM TMMI 2: ZARZĄDZANY

PA 2.1      POLITYKA I STRATEGIA TESTÓW

PA 2.2      PLANOWANIE TESTÓW

PA 2.3       MONITOROWANIE I KONTROLA TESTÓW

PA 2.4       PROJEKTOWANIE I WYKONYWANIE TESTÓW

PA 2.5      ŚRODOWISKO TESTOWE

POZIOM TMMI 3: ZDEFINIOWANY

PA 3.1      ORGANIZACJA TESTOWA

PA 3.2       PROGRAM SZKOLEŃ TESTERSKICH

PA 3.3       CYKL ŻYCIA I INTEGRACJA TESTÓW

PA 3.4       TESTOWANIE NIEFUNKCJONALNE

PA 3.5      PRZEGLĄDY KOLEŻEŃSKIE

POZIOM TMMI 4: MIERZALNY

PA 4.1      POMIAR TESTÓW

PA 4.2      OCENA JAKOŚCI PRODUKTÓW

PA 4.3      ZAAWANSOWANE PRZEGLĄDY

POZIOM TMMI 5: OPTYMALIZACJA

PA 5.1      ZAPOBIEGANIE DEFEKTOM

PA 5.2      KONTROLA JAKOŚCI

PA 5.3       OPTYMALIZACJA PROCESU TESTOWEGO

DODATEK A OCENY I CERTYFIKACJA TMMI

DODATEK B PROCES DOSKONALENIA

GLOSSARY

ODNIESIENIA:

Test Maturity Model integration (TMMi)

1.1.      Wprowadzenie

Organizacje codziennie stają w obliczu coraz trudniejszych celów biznesowych, np. skrócenia czasu wprowadzania produktów na rynek, wymagań dotyczących wyższego poziomu jakości i niezawodności oraz obniżenia kosztów. Systemy, w których oprogramowanie jest dominującym czynnikiem, stają się bardziej złożone, a zatem trudniejsze do zbudowania. Odgrywają one coraz ważniejszą rolę w społeczeństwie. Nowe metody, techniki i narzędzia stają się dostępne w celu wsparcia zadań związanych z rozwojem

i pielęgnacją. Ponieważ systemy odgrywają tak ważną rolę w naszym życiu zarówno ze względów ekonomicznych, jak i społecznych, wywierana jest presja na branżę inżynierii oprogramowania, by skupiła się ona na kwestiach jakości. Oprogramowanie niskiej jakości nie jest już akceptowane przez społeczeństwo. Awarie oprogramowania mogą spowodować katastrofalne straty. W tym kontekście znaczenie branży testowania rozumianej jako jedna z miar jakości, którą można wprowadzić, szybko rośnie.      Testowanie stało się kluczowym działaniem, które bezpośrednio wpływa nie tylko na jakość produktu, ale także na wydajność całego procesu wytwarzania i produkcji.

W ostatnim dziesięcioleciu branża wytwarzania oprogramowania włożyła znaczny wysiłek w poprawę jakości swoich produktów. Było to trudne zadanie, ponieważ rozmiar

i złożoność oprogramowania gwałtownie rosną a klienci i użytkownicy stają się coraz bardziej wymagający. Jednocześnie wytwarzanie oprogramowania staje się działalnością zlecaną na zewnątrz lub jest rozwijane wspólnie z innymi zainteresowanymi stronami.

Pomimo zachęcających wyników obserwowanych w różnych podejściach do poprawy jakości, przemysł wytwarzania oprogramowania jest nadal występują defekty w wysyłanych produktach. Aby poprawić jakość produktów, branża wytwarzania oprogramowania często koncentrowała się na doskonaleniu procesów wytwórczych. Wytyczne, które często były stosowane w celu udoskonalenia procesów wytwarzania, zostały opisane w  Capability Maturity Model Integration (CMMI). Pomimo faktu, że testowanie często stanowi co najmniej 30-40% całkowitych kosztów projektu, jedynie niewielka część prac projektowych poświęcona jest testom w różnych modelach doskonalenia procesów oprogramowania, takich jak CMMI. W odpowiedzi na ten problem społeczność testerska stworzyła własne modele usprawnień. Niniejszy dokument opisuje Test Maturity Model integration. TMMi jest szczegółowym modelem doskonalenia procesu testowego i może być używany niezależnie lub i jest pozycjonowany jako uzupełnienie CMMI lub jakiejkolwiek innej struktury doskonalenia procesów dotyczących oprogramowania.

1.2.      Kontekst i historia

Ramy TMMi zostały opracowane przez TMMi Foundation jako wytyczne i punkt odniesienia dla usprawnienia procesu testowego zajmując się kwestiami, które są ważne dla kierowników testów, inżynierów testów, specjalistów ds. jakości oprogramowania i członków zespołów crossfunkcjonalnych. Testowanie zdefiniowane w TMMi jest stosowane

w najszerszym znaczeniu, obejmującym wszystkie działania związane z zapewnieniem jakości oprogramowania.

Testowanie: proces składający się ze wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów w celu określenia, czy spełniają one wyspecyfikowane wymagania oraz na wykazaniu, że są one dopasowane do swoich celów oraz na wykrywaniu usterek. [Słownik terminów testowych ISTQB®].

W TMMi wykorzystano koncepcję poziomów dojrzałości do oceny i doskonalenia procesów. Ponadto zidentyfikowano obszary procesowe, cele i praktyki. Zastosowanie kryteriów dojrzałości TMMi usprawni proces testowania i będzie miało pozytywny wpływ na jakość produktu, wydajność inżynierii testów i nakład czasu przeznaczony na pojedynczą iterację. TMMi został stworzony w celu wspierania organizacji w ocenie

i doskonaleniu ich procesu testowego. W ramach TMMi testowanie ewoluuje od chaotycznego, źle zdefiniowanego procesu z brakiem zasobów, narzędzi i dobrze przeszkolonych testerów, do dojrzałego i kontrolowanego procesu, którego głównym celem jest zapobieganie usterkom (defektom).

Dotychczasowe, praktyczne doświadczenia pokazują, że TMMi wspiera proces tworzenia bardziej skutecznego i wydajnego procesu testowego. Ogólnoświatowa ankieta użytkowników TMMi wykazała, że 88% użytkowników TMMi odczuwa korzyści w zakresie jakości produktu, np. zmniejszonego ryzyka związanego z produktem i wydajności testów (77%), np. zwiększonej wydajności testowania. [Ankieta], Z TMMi testowanie staje się zawodem (profesją) i w pełni zintegrowaną częścią procesu rozwoju oprogramowania. Jak stwierdzono, wysiłek testowy zmienia się z wykrywania usterek na zapobieganie im.

1.3.      Źródła

W początkowym rozwoju TMMi wykorzystano platformę TMM opracowaną przez Illinois Institute of Technology [Burnstein]. Oprócz TMM, na model TMMi w dużej mierze miała wpływ praca wykonana nad Capability Maturity Model Integration (CMMI), modelem doskonalenia procesów, który cieszy się dużym uznaniem w branży IT. CMMI wersja 1.3 [CMMI] posiada zarówno reprezentację etapową, jak i ciągłą. W ramach reprezentacji wieloetapowej architektura CMMI określa etapy, przez które organizacja musi przejść

w sposób uporządkowany, aby usprawnić swój proces rozwoju. W ramach reprezentacji ciągłej nie ma ustalonego zestawu poziomów lub etapów, przez które należy przejść. Organizacja stosująca ciągłą reprezentację może wybrać obszary wymagające poprawy spośród wielu różnych kategorii.

TMMi został opracowany jako model etapowy. Model etapowy wykorzystuje predefiniowane zestawy obszarów procesów w celu zdefiniowania ścieżki doskonalenia organizacji. Ta ścieżka doskonalenia jest opisana przez komponent modelu zwany poziomem dojrzałości. Poziom dojrzałości jest dobrze zdefiniowaną ewolucyjną płaszczyzną ukierunkowaną na osiąganie bardziej udoskonalonych procesów organizacyjnych.

Inne źródła rozwoju TMMi obejmują Ewolucję modelu testowania [Evolution of Testing Model - Gelperin i Hetzel], który opisuje ewolucję procesu testowania na przestrzeni ponad

40 lat, model testowania Beizera, który opisuje ewolucję myślenia indywidualnych testerów [Beizer], badania nad TMM prowadzone w ramach finansowanego przez UE projektu MB-TMM oraz międzynarodowych standardów testowania, np. standardu IEEE i ISO. Terminologia

z obszaru testowania używana w TMMi pochodzi ze Słownika terminów testowych ISTQB®[1] [ISTQB].

Jak stwierdzono przy definiowaniu poziomów dojrzałości, Ewolucja modelu testowania Gelperina i Hetzla posłużyła jako podstawa do zróżnicowania TMMi na poziomie historycznym. Model Gelperina i Hetzla opisuje fazy i cele testowania na lata pięćdziesiąte i dziewięćdziesiąte XX wieku. Początkowy okres jest opisywany jako „zorientowany na debugowanie”, podczas którego większość organizacji zajmujących się tworzeniem oprogramowania nie dostrzegała jeszcze różnicy między testowaniem a debugowaniem. Testowanie było działaniem doraźnym związanym z debugowaniem. Według Gelperina i Hetzla testowanie przeszło od tego czasu do etapu ukierunkowanego na zapobieganie, który jest powiązany z bieżącymi najlepszymi praktykami i odzwierciedla najwyższy poziom dojrzałości TMMi.

Ponadto do rozwoju TMMi przyczyniły się najlepsze i różnorodne praktyki branżowe, praktyczne doświadczenia z wykorzystaniem TMM oraz badania ankietowe, zapewniając mu niezbędne podstawy empiryczne i wymagany poziom praktyczności. Ilustrują one aktualne najlepsze i najgorsze praktyki w obszarze testowania w branży IT i pozwoliły twórcom modelu TMMi na uzyskanie realistycznych punktów odniesienia dla oceny i poprawy praktyk

w obszarze testowania.

1.4.      Zakres TMMi

1.4.1. Inżynieria oprogramowania i systemów

TMMi ma na celu wspieranie działań testowych i doskonalenie procesu testowego zarówno w dziedzinie inżynierii systemów, jak i w inżynierii oprogramowania. Inżynieria systemowa obejmuje rozwój całych systemów, które mogą, ale nie muszą, zawierać oprogramowanie, ale zazwyczaj obejmują kombinację sprzętu i oprogramowania. . Inżynieria oprogramowania obejmuje rozwój systemów oprogramowania.

1.4.2. Poziomy testów

Podczas gdy niektóre modele doskonalenia procesu testowego po pierwsze koncentrują się głównie na wyższych poziomach testów, np. Test Process Improvement (TPI) [Koomen i Pol] i jego następca TPI-Next [Sogeti] lub dotyczą tylko jednego aspektu testowania ustrukturyzowanego, np. organizacja testów, TMMi zajmuje się wszystkimi poziomami testów oraz testowaniem statycznym i aspektami ustrukturyzowanego testowania. W odniesieniu do testowania dynamicznego w zakres TMMi wchodzą zarówno niższe poziomy testów (np. testowanie modułowe, testowanie integracyjne), jak i wyższe poziomy testów (np. testowanie systemowe, testowanie akceptacyjne). Szczegółowa analiza modelu pozwoli stwierdzić, że model odnosi się do wszystkich czterech kamieni węgielnych ustrukturyzowanego testowania (cykl życia, techniki, infrastruktura i organizacja) [TMap].

1.4.3. TMMi oraz CMMI

Ważne jest również, aby pamiętać, że TMMi jest przede wszystkim pozycjonowany jako niezależny model doskonalenia testów, ale może być również używany jako model uzupełniający CMMI. W wielu przypadkach dany poziom TMMi wymaga szczególnego wsparcia ze strony obszarów procesowych, które są poza testowaniem i są zdefiniowane na odpowiadającym im lub niższym poziomie CMMI. W wyjątkowych przypadkach istnieje nawet związek z wyższymi poziomami CMMI. Obszary procesu i praktyki opracowywane w ramach CMMI, w większości nie są powtarzane w TMMi, są one jedynie przywoływane. Na przykład obszar procesu o nazwie Zarządzanie konfiguracją, który ma również zastosowanie do testowych produktów (pracy) / testaliów, nie jest szczegółowo omówiony w TMMi; praktyki CMMI są przywoływane i pośrednio ponownie wykorzystywane.

1.4.4. Cykl życia

TMMi ma być niezależny od cyklu życia. Jako taki może być na przykład używany

z sekwencyjnymi, zwinnymi i DevOps modelami cyklu życia, Ogólnoświatowa ankieta użytkowników TMMi ujawniła już, że 78% użytkowników TMMi (również) stosuje TMMi

w kontekście Agile, a 57% użytkowników stosuje TMMi w kontekście DevOps [Ankieta]. Aby wesprzeć tych, którzy stosują TMMi w kontekście Agile, TMMi Foundation opublikowała bardzo szczegółowe, wspierające wytyczne [TMMiAgile]. Te wytyczne wyjaśniają, w jaki sposób TMMi może być używany i stosowany korzystnie w kontekście Agile. Zwinne alternatywy są dostarczane tradycyjnym podejściom do testowania, które wdrażają praktyki TMMi przy jednoczesnym utrzymaniu, a może nawet zwiększeniu zwinności. Każdy obszar procesowy TMMi i jego cele szczegółowe są omawiane jeden po drugim. Określono, w jaki sposób odnoszą się one do Agile i jak zazwyczaj będą wyglądać praktyki. Jeśli nie oczekuje się, że praktyka będzie wykonywana w kontekście Agile, ponieważ nie ma wartości dodanej, jest to również wyraźnie określone. Oprócz wytycznych Agile, TMMi Foundation opracowała białą księgę zatytułowaną „Jak TMMi wspiera trzy metody DevOps" opisującą, w jaki sposób TMMi pasuje do kontekstu DevOps [TMMiDevOps].

1.4.5. Oceny

Wiele organizacji widzi wartość w analizie porównawczej postępów w doskonaleniu procesu testowego, zarówno dla celów wewnętrznych, jak i dla zewnętrznych klientów

i dostawców. Oceny procesu testowego koncentrują się na zidentyfikowaniu możliwości doskonalenia i zrozumieniu pozycji organizacji w stosunku do wybranego modelu lub normy. TMMi stanowi doskonały model odniesienia, który można wykorzystać podczas takich ocen. Zespoły oceniające korzystają z TMMi, aby wspomóc identyfikację i ustalanie priorytetów swoich ustaleń. Ustalenia te wraz z wytycznymi dotyczącymi praktyk TMMi są wykorzystywane do planowania usprawnień dla organizacji. Sama struktura oceny nie jest częścią TMMi. Wymagania dotyczące oceny TMMi zostały opisane przez TMMi Foundation w oddzielnym dokumencie TMMi Assessment Method Application Requirements [Tamar]. Wymagania te oparte są na normie ISO 15504. Osiągnięcie określonego poziomu dojrzałości dla różnych ocenianych organizacji musi oznaczać to samo. Zasady mające na celu zapewnienie tej spójności zawarte są w wymogach dotyczących metody oceny TMMi. Wymagania dotyczące metod oceny TMMi zawierają wytyczne dla różnych klas ocen, np. ocen formalnych, szybkich skanów i samoocen. Więcej szczegółów na temat oceny i akredytacji TMMi znajduje się

w załączniku A.

Ponieważ TMMi może być używany w połączeniu z CMMI (wersja etapowa), oceny TMMi i CMMI są często łączone, oceniając zarówno proces rozwoju, jak i proces testowania. Ponieważ modele mają podobną strukturę, a słowniki i cele modelu pokrywają się, zespół oceniający może przeprowadzić szkolenie równoległe i oceny równoległe. TMMi może być również używany do rozwiązywania problemów testowych w połączeniu z modelami ciągłymi. Nakładające się obszary procesów, które odnoszą się do testowania, można ocenić

i udoskonalić za pomocą TMMi, podczas gdy inne obszary procesu wchodzą w zakres modelu o szerszym zakresie.

1.4.6. Podejście usprawniające

TMMi dostarcza kompletnej struktury do wykorzystania jako model odniesienia podczas doskonalenia procesu testowego. Nie zapewnia podejścia do doskonalenia procesu testowania, takiego jak model IDEAL (inicjowanie, diagnozowanie, ustanawianie, działanie

i uczenie się) [IDEAL]. Praktyczne doświadczenia pokazały, że przynoszącym największe rezultaty początkowym krokiem prowadzącym do usprawnienia procesu testowego jest zbudowanie silnego wsparcia organizacyjnego przed zainwestowaniem w ocenę procesu testowego. Przy wystarczającym wsparciu ze strony kierownictwa wyższego szczebla, skutecznym podejściem okazuje się ustanowienie specjalnej grupy ds. procesu testowania, posiadającej kompetencje techniczne i reprezentującej odpowiednich interesariuszy oraz mającej na celu kierowanie działaniami na rzecz poprawy procesu testowania. Więcej informacji na temat podejścia do doskonalenia przedstawiono w załączniku B. Inne pomysły

i wytyczne dotyczące podejścia do doskonalenia procesu testowego można znaleźć w The little TMMi [Veenendaal i Cannegieter].

2.      Poziomy dojrzałości TMMi

2.1.      Opis ogólny

TMMi posiada architekturę stopniowego usprawniania procesów. Zawiera ona etapy lub poziomy, przez które przechodzi organizacja, w miarę jak jej proces testowania ewoluuje od etapu doraźnego i niezarządzanego (etap wstępny), do etapu zarządzanego, zdefiniowanego, mierzalnego i wreszcie będącego w stanie ciągłego doskonalenia, określanego jako optymalizacja. Osiągnięcie każdego etapu zapewnia, że zostały wdrożone odpowiednie usprawnienia i mogą one służyć jako podstawa dla następnego etapu. Wewnętrzna struktura TMMi obfituje w dobre praktyki testowania, których można się nauczyć i stosować w sposób systematyczny, aby wspierać jakościowy proces testowania, który jest usprawniany w kolejnych krokach. W TMMi istnieje pięć poziomów, które określają hierarchię dojrzałości i ewolucyjną ścieżkę doskonalenia procesu testowego. Każdy poziom posiada zestaw obszarów procesowych, które organizacja musi wdrożyć, aby osiągnąć dojrzałość na tym poziomie. Doświadczenie pokazało, że organizacje robią wszystko, co w ich mocy, gdy koncentrują swoje wysiłki w zakresie usprawniania procesu testowego na możliwej do zarządzania liczbie obszarów procesowych w danym czasie oraz z doświadczeń wynika,

że obszary te wymagają coraz większego zaangażowania w miarę, jak organizacja się doskonali. Z uwagi na fakt, że każdy poziom dojrzałości stanowi niezbędną podstawę dla następnego poziomu, próba pominięcia jednego z poziomów dojrzałości jest zazwyczaj szkodliwa. Jednocześnie należy zdawać sobie sprawę z tego, że wysiłki na rzecz usprawnienia procesu testowego powinny koncentrować się na potrzebach organizacji w kontekście jej otoczenia biznesowego, a obszary procesowe o wyższym poziomie dojrzałości mogą odpowiadać na bieżące potrzeby organizacji lub projektu. Przykładem tego są organizacje pragnące przejść z 1. poziomu dojrzałości do 2. poziomu dojrzałości, które często są zachęcane do utworzenia grupy testowej, do której odnosi się obszar procesu organizacji testowej, który znajduje się na 3. poziomie dojrzałości. Chociaż grupa testowa nie jest konieczną cechą organizacji TMMi na poziomie 2., może ona być użyteczną częścią podejścia organizacji do osiągnięcia poziomu dojrzałości TMMi 2.

(1)Wstępny

(

(4) Mierzalny

4.1 Pomiar testów

4.2 Ocena jakości produktów

4.3 Zaawansowane przeglądy

(3) Zdefiniowany

3.1 Organizacja testowa

3.2 Program szkoleń testerskich

3.3 Cykl życia i integracja testów

3.4 Testowanie niefunkcjonalne

3.5 Przeglądy koleżeńskie

(5) Optymalizacja

5.1 Zapobieganie defektom

5.2 Kontrola jakości

5.3 Optymalizacja procesu testowego

(2) Zarządzany

2.1 Polityka i strategia testów

2.2 Planowanie testów

2.3 Monitorowanie i kontrola testów

2.4 Projektowanie i wykonywanie testów

2.5 Środowisko testowe

Test

Rysunek 1. Poziomy dojrzałości i obszary procesowe TMMi.

Obszary procesowe dla każdego poziomu dojrzałości TMMi przedstawiono na Rysunku 1. Są one w pełni opisane w kolejnych rozdziałach oraz wymienione poniżej wraz z krótkim opisem każdego z obszarów procesowych organizacji na każdym poziomie TMMi. Opis ma na celu wprowadzenie czytelnika na ścieżkę ewolucyjną zalecaną przez TMMi w celu usprawnienia procesu testowego.

Należy pamiętać, że TMMi nie posiada określonego obszaru procesowego dedykowanego narzędziom testowym i/lub automatyzacji testów. W ramach TMMi narzędzia testowe są traktowane jako źródło wsparcia (dla praktyk) i dlatego są częścią obszaru procesowego, dla którego zapewniają wsparcie, np. zastosowanie narzędzia do projektowania testów jest pomocniczą praktyką testową w obszarze procesowym Projektowanie

i wykonywanie testów na poziomie TMMi 2, a zastosowanie narzędzia do testowania wydajności jest pomocniczą praktyką testową w obszarze procesowym Testowanie niefunkcjonalne na poziomie TMMi 3.

2.2.      Poziom 1.  Wstępny

Na poziomie TMMi 1 testowanie jest procesem chaotycznym, niezdefiniowanym

i często uważanym za część debugowania. Organizacja zazwyczaj nie zapewnia stabilnego środowiska wspierającego procesy. Sukces w tych organizacjach zależy od kompetencji

i bohaterstwa ludzi w organizacji, a nie od wykorzystania sprawdzonych procesów. Testy są projektowane w sposób doraźny po zakończeniu kodowania. Testowanie i usuwanie usterek przeplatają się, aby możliwe było ujawnienie usterek w systemie. Celem testowania na tym poziomie jest wykazanie, że oprogramowanie działa bez większych awarii. Produkty są wydawane bez odpowiedniej świadomości jakości i ryzyk. W praktyce produkt często nie spełnia wymagań, nie jest stabilny i/lub działa zbyt wolno. W ramach testów brakuje zasobów, narzędzi i dobrze wykształconego personelu. Na poziomie TMMi 1 nie ma zdefiniowanych obszarów procesowych. Organizacje znajdujące się na poziomie dojrzałości 1. charakteryzują się tendencją do nadmiernego zaangażowania, porzucania procesów w czasach kryzysów

i niemożnością powtórzenia swoich sukcesów. Ponadto produkty zazwyczaj nie są wydawane na czas, budżety są przekraczane, a jakość dostarczanych produktów nie jest zgodna

z oczekiwaniami.

2.3.      Poziom 2.  Zarządzany

Na poziomie TMMi 2 testowanie staje się procesem zarządzanym i jest wyraźnie oddzielone od debugowania. Dyscyplina procesu odzwierciedlona przez poziom dojrzałości 2. pomaga zapewnić, że istniejące praktyki są utrzymywane w kryzysowych sytuacjach. Jednakże wielu interesariuszy nadal postrzega testowanie jako fazę projektu, która następuje po kodowaniu.

W kontekście doskonalenia procesu testowego tworzona jest strategia testowa obejmująca całą firmę lub program. Opracowywane są  plany testów. W ramach planu testów definiowane jest podejście do testów, przy czym podejście to opiera się na wyniku oceny ryzyka produktowego. Do identyfikacji ryzyk produktowych wykorzystywane są techniki zarządzania ryzykiem oparte na udokumentowanych wymaganiach. Plan testów określa, jakie testy są wymagane, kiedy, w jaki sposób powinny być realizowane i przez kogo. Zobowiązania są uzgadniane z interesariuszami i w razie potrzeby zmieniane. Testowanie jest monitorowane

i kontrolowane w celu upewnienia się, że przebiega zgodnie z planem i że można podjąć działania w przypadku wystąpienia odchyleń. Status produktów pracy i świadczenie usług

w zakresie testowania są widoczne dla kierownictwa. Techniki projektowania testów są stosowane do wyprowadzania i wyboru przypadków testowych ze specyfikacji. Jednakże testowanie może się rozpocząć stosunkowo późno w cyklu wytwarzania, np. w fazie projektowania lub nawet w fazie kodowania.

W TMMi na poziomie 2. testowanie jest wieloetapowe: istnieją poziomy testów modułowych, integracyjnych, systemowych i akceptacyjnych. Dla każdego zidentyfikowanego poziomu testów istnieją określone cele testowania zdefiniowane w strategii testów w całej organizacji lub w programie. Procesy testowania i usuwania usterek są zróżnicowane.

Głównym celem testowania w organizacji TMMi na poziomie 2. jest sprawdzenie, czy produkt spełnia określone wymagania. Na tym poziomie TMMi występuje wiele problemów jakościowych, ponieważ testowanie odbywa się późno w cyklu wytwarzania. Usterki powstałe

w fazie wymagań i projektowania przechodzą do kodu. Nie ma jeszcze formalnych przeglądów, aby rozwiązać ten ważny problem. Testowanie wykonywane po kodowaniu przez wielu interesariuszy jest nadal uważane za podstawową czynność testową.

Obszary procesowe na poziomie TMMi 2 są następujące:

2.1. Polityka i strategia testów

2.2. Planowanie testów

2.3. Monitorowanie i kontrola testów

2.4. Projektowanie i wykonywanie testów

2.5. Środowisko testowe

2.4.      Poziom 3.  Zdefiniowany

Na poziomie 3. w TMMi testowanie nie ogranicza się już do fazy, która następuje po kodowaniu. Jest ono w pełni zintegrowane z cyklem wytwarzania i związanymi z nim kamieniami milowymi. Planowanie testów odbywa się na wczesnym etapie projektu,

np. w fazie specyfikacji wymagań i jest dokumentowane w głównym planie testów. Opracowanie głównego planu testów opiera się na umiejętnościach planowania testów

i zobowiązaniach uzyskanych na poziomie TMMi 2. Zbiór standardowych procesów organizacji w obszarze testowania, który stanowi podstawę dla poziomu dojrzałości 3, jest ustalany

i doskonalony w czasie. Istnieje organizacja testowa i specyficzny program szkoleń testerskich, a testowanie jest postrzegane jako profesja. Udoskonalanie procesów organizacji w obszarze testowania jest w pełni zinstytucjonalizowane w ramach przyjętych praktyk organizacji testowej.

Organizacje na poziomie 3. rozumieją znaczenie przeglądów w kontroli jakości; wdrażany jest plan przeglądu formalnego, choć nie jest on jeszcze w pełni powiązany

z procesem testowania dynamicznego. Przeglądy odbywają się w całym cyklu życia.

W przeglądy specyfikacji wymagań zaangażowani są specjaliści ds. testów. Podczas gdy projektowanie testów na poziomie TMMi 2. koncentruje się głównie na testowaniu funkcjonalności, na poziomie 3. projektowanie i techniki testowania są rozszerzone w celu uwzględnienia testów niefunkcjonalnych, np. użyteczności i/lub niezawodności, w zależności od celów biznesowych.

Kluczową różnicą pomiędzy poziomami dojrzałości TMMi 2. a 3. jest zakres norm, opis procesów i procedur. Na poziomie dojrzałości 2. mogą one być zupełnie inne w każdym przypadku, np. w przypadku konkretnego projektu. Na poziomie dojrzałości 3. są one ustalane na podstawie zbioru standardowych procesów organizacji w celu dostosowania ich do konkretnego projektu lub jednostki organizacyjnej, a zatem są bardziej spójne, za wyjątkiem różnic, na jakie pozwalają wytyczne dotyczące ich dostosowania. Kolejną istotną różnicą jest to, że na poziomie dojrzałości 3. procesy są zazwyczaj opisane bardziej rygorystycznie niż na poziomie dojrzałości 2. W konsekwencji na poziomie dojrzałości 3. organizacja musi zrewidować obszary procesowe na poziomie dojrzałości 2.

Obszary procesowe na poziomie TMMi 3 są następujące:

3.1. Organizacja testowa

3.2. Program szkoleń testerskich

3.3. Cykl życia i integracja testów

3.4. Testowanie niefunkcjonalne

3.5. Przeglądy koleżeńskie

2.5.      Poziom 4.  Mierzalny

Osiągnięcie celów poziomu 2. i 3. TMMi przynosi korzyści w postaci wprowadzenia infrastruktury technicznej, zarządczej i kadrowej, zdolnej do dokładnego testowania

i zapewniającej wsparcie w usprawnianiu procesu testowego. Dzięki tej infrastrukturze testowanie może stać się mierzalnym procesem, zachęcającym do dalszego rozwoju

i doskonalenia. W organizacjach poziomu TMMi 4 testowanie jest dokładnie zdefiniowanym, dobrze uzasadnionym i mierzalnym procesem. Testowanie jest postrzegane jako ewaluacja; składa się z wszystkich czynności związanych z cyklem życia produktu i powiązanych z nim produktów pracy.

W całej organizacji zostaje wprowadzony program pomiarów testów, który może być wykorzystany do oceny jakości procesu testowania, oceny wydajności i monitorowania udoskonaleń. Wdrażane są miary do zbioru danych pomiarowych organizacji w celu wspierania podejmowania decyzji opartych na faktach. Program pomiarów testowania wspiera również przewidywania dotyczące wydajności i kosztów testów.

W odniesieniu do jakości produktu, obecność programu pomiarowego pozwala organizacji na wdrożenie procesu oceny jakości produktu poprzez zdefiniowanie potrzeb jakościowych, charakterystyk jakościowych i wskaźników jakości. Produkty (pracy) są oceniane przy użyciu ilościowych kryteriów dla charakterystyk jakościowych takich jak: niezawodność, użyteczność i utrzymywalność. Jakość produktu jest pojmowana z punktu widzenia ilościowego i jest zarządzana zgodnie z określonymi celami przez cały cykl życia produktu.

Przeglądy i inspekcje są uważane za część procesu testowego i są wykorzystywane do pomiaru jakości produktu na wczesnym etapie cyklu życia oraz jako formalne bramki kontroli jakości. Przeglądy koleżeńskie jako technika wykrywania defektów są przekształcane w technikę pomiaru jakości produktu, zgodnie z obszarem procesowym Ocena jakości produktu.

Poziom 4. TMMi obejmuje również ustanowienie skoordynowanego podejścia testowego pomiędzy przeglądami koleżeńskimi (testowanie statyczne) a testowaniem dynamicznym oraz wykorzystaniem wyników i danych z przeglądów koleżeńskich w celu optymalizacji podejścia testowego po to, by zwiększyć skuteczność i efektywność testowania. Przeglądy koleżeńskie są odtąd w pełni zintegrowane z procesem testowania dynamicznego, np. częścią strategii testowania, planu testów i podejścia do testów.

Obszary procesowe na poziomie TMMi 4 są następujące:

4.1. Pomiar testów

4.2. Ocena jakości produktów

4.3. Zaawansowane przeglądy

2.6.      Poziom 5.  Optymalizacja

Osiągnięcie wszystkich poprzednich celów doskonalenia testowania na poziomach TMMi od 1. do 4. tworzy infrastrukturę organizacyjną do testowania, która wspiera całkowicie zdefiniowany i mierzalny proces. Na 5. poziomie dojrzałości TMMi organizacja jest w stanie

w sposób ciągły doskonalić swoje procesy w oparciu o ilościowe zrozumienie procesów sterowanych statystycznie. Poprawa wydajności procesów testowych odbywa się poprzez przyrostowe i innowacyjne procesy oraz udoskonalenia technologiczne. Metody i techniki testowania są zoptymalizowane, a nacisk kładziony jest na dokładne dostrajanie

i doskonalenie procesów.

Zoptymalizowany proces testowy, zdefiniowany przez TMMi, to proces, który jest:

• Zarządzany, zdefiniowany, mierzalny, wydajny i skuteczny

• Statystycznie kontrolowany i przewidywalny

• Skoncentrowany na zapobieganiu defektom

• Wspierany przez automatyzację, dla efektywnego wykorzystania zasobów

• Zdolny do wspierania transferu technologii z przemysłu do organizacji

• Zdolny do wspierania ponownego wykorzystania zasobów testowych

• Skoncentrowany na zmianie procesu w celu osiągnięcia ciągłego doskonalenia

W celu wspierania ciągłego doskonalenia infrastruktury procesu testowego oraz identyfikacji, planowania i wdrażania usprawnień tegoż procesu, powoływana jest stała grupa

ds. doskonalenia procesu testowego, w skład której wchodzą osoby, które przeszły specjalistyczne szkolenia w celu podniesienia poziomu swoich umiejętności i wiedzy niezbędnych do osiągnięcia sukcesu przez grupę. W wielu organizacjach grupa ta nazywana jest grupą ds. procesów testowych. Wsparcie dla grupy ds. procesów testowych rozpoczyna się formalnie na poziomie TMMi 3., kiedy wprowadzany jest obszar procesowy Organizacja testowa. Na poziomach TMMi 4. i 5. zakres odpowiedzialności grupy rośnie wraz

z wprowadzaniem praktyk na wyższym poziomie, np. w zakresie identyfikacji zasobów testowych wielokrotnego użytku oraz rozwoju i utrzymania biblioteki zasobów testowych.

Obszar procesowy Zapobieganie defektom został ustanowiony w celu identyfikacji

i analizy typowych przyczyn defektów w całym cyklu życia produktu oraz określenia działań zapobiegających występowaniu podobnych defektów w przyszłości. Odstępstwa od wydajności procesu testowego, zidentyfikowane w procesie kontroli jakości, są analizowane

w celu zaadresowania ich przyczyn w ramach czynności zapobiegania defektom.

Proces testowy jest zarządzany statystycznie za pomocą obszaru Kontrola jakości. Statystyczne pobieranie próbek, pomiary poziomów zaufania, wiarygodności i niezawodności stymulują proces testowy. Proces testowy charakteryzuje się pomiarem jakości opartym na próbkowaniu.

Na poziomie TMMi 5 w obszarze Optymalizacja procesu testowego wprowadzono mechanizmy precyzyjnego dostrajania i ciągłego doskonalenia testów. Istnieje ustalona procedura identyfikacji usprawnień procesu, jak również wyboru i oceny nowych technologii testowania. Narzędzia wspierają proces testowania w takim stopniu, w jakim jest on efektywny

w fazie projektowania testów, wykonywania testów, testowania regresji, zarządzania przypadkami testowymi, zbierania i analizy defektów itp. Powszechną praktyką w całej organizacji jest ponowne wykorzystanie procesu i testaliów. Jest to wspierane przez bibliotekę zasobów testowych.

Trzy obszary procesów na poziomie TMMi 5: Zapobieganie defektom, Kontrola jakości

i Optymalizacja procesu testowego zapewniają wsparcie dla ciągłego doskonalenia procesów. W praktyce te trzy obszary procesu są ze sobą ściśle powiązane. Na przykład Zapobieganie defektom wspiera obszar Kontroli jakości poprzez analizę wartości odbiegających od norm wydajności procesu oraz poprzez wdrażanie praktyki analizy przyczyn powstawania defektów i zapobiegania ponownemu ich wystąpieniu. Kontrola jakości przyczynia się do Optymalizacji procesu testowego, a Optymalizacja procesu testowego wspiera zarówno Zapobieganie defektom, jak i Kontrolę jakości na przykład poprzez wdrażanie projektów podniesienia jakości testów. Wszystkie te obszary procesowe są z kolei wspierane przez praktyki, które zostały zastosowane podczas wdrażania obszarów procesowych niższego poziomu. Na poziomie TMMi 5 testowanie jest zdefiniowane jako proces mający na celu zapobieganie usterkom.

Obszary procesowe na poziomie TMMi 5 są następujące:

5.1. Zapobieganie defektom

5.2. Kontrola jakości

5.3. Optymalizacja procesu testowego

3.  Struktura TMMi

Struktura TMMi w dużej mierze opiera się na strukturze CMMI w. 1.3 [CMMI].. Jest to sporą zaletą modelu, ponieważ wiele osób/organizacji jest już zaznajomionych ze strukturą CMMI w. 1.3. Struktura CMMI w. 1.3 jasno definiuje praktyki, które są wymagane (cele) lub zalecane (konkretne praktyki, przykładowe artefakty itp.) do wdrożenia. Podejście to jest również zawarte w TMMi. W tym rozdziale opisane zostały elementy i struktura TMMi. Ponadto opisano wsparcie zapewnione przez CMMI dla wdrożenia TMMi. W tym ostatnim przywoływana i używana jest najnowsza wersja CMMI, CMMI w wersji 2 [CMMIV2].

3.1.      Elementy wymagane, oczekiwane i informacyjne

Poszczególne elementy składowe są pogrupowane w trzy kategorie: elementy wymagane, oczekiwane oraz informacyjne.

3.1.1. Elementy wymagane

Elementy wymagane zawierają opis tego, co organizacja musi osiągnąć, żeby spełnić wymagania obszaru procesowego. Implementacja zasad zdefiniowanych dla obszaru musi być widoczna w procesach w organizacji. Elementami wymaganymi przez metodykę TMMi są cele ogólne i szczegółowe. Osiąganie celów jest wykorzystywane podczas oceny procesów jako podstawa do podjęcia decyzji, czy obszar procesowy został osiągnięty.

3.1.2. Elementy oczekiwane

Elementy oczekiwane zawierają opis tego, co organizacja zwykle wdraża, aby osiągnąć elementy wymagane. Elementy oczekiwane prowadzą tych, którzy wprowadzają udoskonalenia lub przeprowadzają oceny procesów. Na elementy oczekiwane składają się praktyki ogólne i szczegółowe. Zanim cele zostaną uznane za zrealizowane, w planowanych

i wdrażanych procesach muszą być obecne albo praktyki opisywane w standardzie, albo ich akceptowalne odpowiedniki.

3.1.3. Elementy informacyjne

Elementy informacyjne dostarczają szczegółów, które pomagają organizacjom

w rozpoczęciu rozważań, jak podejść do wymaganych i oczekiwanych elementów. Elementy informacyjne modelu stanowią podpraktyki, przykładowe produkty pracy, notatki, przykłady

i odniesienia.

3.2.      Elementy składowe / komponenty TMMi

Rysunek 2. przedstawia podsumowanie oraz związki pomiędzy wymaganymi

a oczekiwanymi elementami modelu TMMi. Poniższe podrozdziały opisują te elementy. Model TMMi dostarcza również słownik pojęć. Pojęcia zawarte w słowniku są w większej części zaczerpnięte z międzynarodowego standardu terminologicznego wypracowanego przez International Software Testing Qualifications Board (ISTQB®): Słownik terminów testowych ISTQB® (https://glossary.istqb.org/) zawierający pojęcia używane w testowaniu oprogramowania.

3.2.1. Poziomy dojrzałości

Poziom dojrzałości w modelu TMMi można traktować jako stopień organizacyjnej jakości procesu testowego. Jest on definiowany jako ewolucyjny poziom doskonalenia procesu testowego. Każdy poziom stopniowo rozwija istotną część procesu testowego organizacji.

W ramach TMMi zdefiniowano pięć poziomów dojrzałości. Każdy poziom dojrzałości określa, co należy wdrożyć, aby osiągnąć dany poziom. Im wyższy poziom dojrzałości, tym bardziej dojrzały jest proces testowy w organizacji. Aby osiągnąć określony poziom dojrzałości, organizacja musi zrealizować wszystkie określone cele (zarówno te specyficzne, jak i ogólne) zdefiniowane dla obszarów procesowych na określonym poziomie, a także dla tych charakterystycznych dla wcześniejszych poziomów dojrzałości. Należy pamiętać, że wszystkie organizacje osiągają przynajmniej poziom TMMi 1, ponieważ poziom ten nie zawiera żadnych celów, które muszą być zrealizowane.

3.2.2. Obszary procesowe

Jak wspomniano, każdy poziom dojrzałości, z wyjątkiem poziomu 1., składa się z kilku obszarów procesowych, które wskazują, na czym organizacja powinna się skupić, aby usprawnić swój proces testowy. Obszary procesowe identyfikują zagadnienia, którymi należy się zająć, aby osiągnąć kolejny poziom dojrzałości. Każdy obszar procesowy wskazuje grupę działań związanych z testami. Kiedy wszystkie działania z danej grupy zostaną zrealizowane, nastąpi znaczna poprawa w działaniu tego obszaru procesowego. W TMMi wyodrębnia się tylko te obszary procesowe, które są uważane za kluczowe wyznaczniki zdolności procesu testowego. Aby osiągnąć kolejny poziom dojrzałości, wszystkie obszary procesowe dla danego i niższego poziomu dojrzałości muszą być osiągnięte. Na przykład jeśli organizacja znajduje się na poziomie TMMi 3, to oznacza, że spełniła wszystkie wymagania zdefiniowane w obszarach procesowych zarówno na poziomie TMMi 2., jak i TMMi 3.

Obszar procesowy 1

Obszar procesowy 2

Obszar procesowy n

Cele szczegółowee

Cele ogólne

Praktyki szczegółowe

Praktyki

ogólne

Poziomy dojrzałości

Rysunek 2. Struktura i komponenty TMMi

3.2.3. Cel

Deklaracja celu zawiera opis zakresu obszaru procesowego i stanowi element informacyjny. Na przykład deklaracja celu obszaru Planowanie procesu testowego to „zdefiniowanie podejścia do testów w oparciu o zidentyfikowane ryzyka i zdefiniowaną strategię testową oraz ustanowienie i utrzymanie dobrze uzasadnionych planów wykonania

i zarządzania działaniami w obszarze testowania".

3.2.4. Uwagi wstępne

Część wprowadzająca do obszaru procesowego zawiera opis głównych koncepcji ujętych w obszarze procesowym i stanowi element informacyjny.

3.2.5. Zakres

W części dotyczącej zakresu obszaru procesu wyraźnie określono praktyki testowe, do których odnosi się obszar procesu, a w razie potrzeby także praktyki testowe, które wyraźnie wykraczają poza zakres tego obszaru procesowego.

3.2.6. Cele szczegółowe

Cel szczegółowy zawiera opis  unikalnej cechy, która musi być obecna, aby zaspokoić potrzeby obszaru procesowego. Cel szczegółowy jest wymaganym elementem modelu i jest wykorzystywany w ocenie, aby pomóc w ustaleniu, czy wymagania zdefiniowane dla danego obszaru procesowego zostały osiągnięte.

3.2.7. Cele ogólne

Ogólne cele pojawiają się pod koniec obszaru procesowego i są nazywane „ogólnymi”, ponieważ ta sama deklaracja celów pojawia się w wielu obszarach procesowych. Cel ogólny zawiera opis cech, które muszą być obecne, aby zinstytucjonalizować procesy służące wdrażaniu danego obszaru procesowego. Cel ogólny jest wymaganym elementem modelu

i jest wykorzystywany w ocenach, aby pomóc w ustaleniu, czy dany obszar procesu jest osiągnięty.

3.2.8. Praktyki szczegółowe

Szczegółową praktyką jest opis czynności, która jest uważana za ważną dla osiągnięcia określonego celu. Szczegółowa praktyka zawiera opis działań, które mają doprowadzić do osiągnięcia konkretnych celów danego obszaru procesowego. Szczegółowa praktyka jest oczekiwanym elementem modelu.

3.2.9. Przykładowe produkty pracy

W części poświęconej przykładowym produktom pracy wymieniono przykładowe produkty charakterystyczne dla określonej praktyki. Produkty te nazywane są „przykładowymi produktami pracy”, ponieważ często istnieją produkty pracy, które są równie skuteczne, ale nie zostały wymienione. Przykładowy produkt pracy jest informacyjnym elementem modelu.

3.2.10. Podpraktyki

Podpraktyka stanowi szczegółowy opis, który zawiera wskazówki dotyczące interpretacji i wdrażania konkretnej praktyki. Podpraktyki mogą być sformułowane w sposób nakazowy, ale w rzeczywistości są elementem informacyjnym, którego celem jest jedynie dostarczenie pomysłów, które mogą być użyteczne w doskonaleniu procesu testowego.

3.2.11. Praktyki ogólne

Praktyki ogólne pojawiają się pod koniec obszaru procesowego i są nazywane „ogólnymi", ponieważ ta sama praktyka pojawia się w wielu obszarach procesowych. Praktyka ogólna to opis działania, które uważane jest za ważne dla osiągnięcia powiązanego celu ogólnego. Praktyka ogólna jest oczekiwanym elementem modelu.

3.2.12. Opracowanie praktyk ogólnych

Opracowanie ogólnych praktyk pojawia się po opracowaniu praktyki ogólnej

w obszarze procesowym i ma na celu dostarczenie wskazówek, w jaki sposób ogólna praktyka powinna być stosowana w danym obszarze procesowym. Opracowanie praktyki ogólnej jest informacyjnym elementem modelu.

3.2.13. Pomocnicze komponenty informacyjne

Jest wiele miejsc, w których potrzebne są dalsze informacje do opisania koncepcji. Informacje te dostarczane są w postaci następujących elementów składowych:

3.2.13.1. Uwagi

Uwaga to tekst, który może towarzyszyć każdemu innemu elementowi modelu. Może zawierać szczegóły, tło (kontekst) lub uzasadnienie. Uwaga jest informacyjnym elementem modelu.

3.2.13.2. Przykłady

Przykład jest komponentem zawierającym tekst i często wykaz pozycji i zazwyczaj mieści się w ramach, które mogą towarzyszyć niemal każdemu innemu komponentowi oraz zawiera jeden lub więcej przykładów w celu wyjaśnienia pojęcia lub opisanej czynności. Przykład jest elementem informacyjnym modelu.

3.2.13.3. Odniesienia

Odniesienie jest wskazówką do dodatkowych lub bardziej szczegółowych informacji

w powiązanych obszarach procesowych i może dotyczyć niemal każdego komponentu modelu. Odniesienie jest informacyjnym elementem modelu.

3.3.      Ogólne cele i praktyki

Ta sekcja opisuje wszystkie ogólne cele i praktyki TMMi. Ogólne cele i ogólne praktyki zostały w większości zaczerpnięte z CMMI w. 1.3. Ogólne cele zostały ponumerowane. Ogólne praktyki również zostały ponumerowane jako podpunkty wspierające, należące do celów ogólnych. Należy zauważyć, że cel ogólny CMMI w. 1.3. GG 1. Osiągnięcie celów szczegółowych nie został wzięty pod uwagę, ponieważ odnosi się on jedynie do ciągłej reprezentacji CMMI, a zatem nie ma znaczenia dla etapowej reprezentacji TMMi. Poza tym jednym przypadkiem schemat numerowania CMMI w. 1.3. został w pełni przyjęty w TMMi, aby uniknąć nieporozumień w organizacjach korzystających zarówno z CMMI w. 1.3., jak i z TMMi.

Poziom dojrzałości, który chce osiągnąć organizacja, umożliwi określenie, które ogólne cele i praktyki mają zastosowanie. Jeżeli organizacja chce  osiągnąć poziom dojrzałości TMMi 2., to musi wdrożyć obszary procesowe właściwe dla tego poziomu oraz cel ogólny 2 (GG 2.)

i towarzyszące mu ogólne praktyki. Cel ogólny 3 (GG 3.) ma zastosowanie tylko dla poziomów dojrzałości TMMi 3. i wyższych. Oznacza to, że jeżeli osiągnięto już poziom TMMi 2., to aby osiągnąć poziom TMMi 3. należy powrócić do obszarów procesowych poziomu TMMi 2.

i zastosować do nich cel ogólny 3 (GG 3.) oraz towarzyszące mu praktyki.

Ważnym pojęciem w doskonaleniu procesów jest instytucjonalizacja. Gdy pojęcie to zostało użyte w opisie ogólnych celów i praktyk, to w tym przypadku instytucjonalizacja oznacza, że proces jest zakorzeniony w sposobie wykonywania pracy oraz że proces jest wykonywany z zaangażowaniem oraz konsekwencją. Proces zinstytucjonalizowany ma większe szanse na przetrwanie w czasach kryzysu. Kiedy jednak wymogi i cele procesu ulegną zmianie, może zaistnieć potrzeba zmiany sposobu jego realizacji, aby zapewnić jego ciągłość. Ogólne praktyki dotyczą właśnie tych aspektów instytucjonalizacji.

Poniższa lista zawiera wszystkie ogólne cele i praktyki należące do TMMi.

GG 2.   Instytucjonalizacja procesu zarządzanego

Proces zarządzany to proces, który realizuje pracę konieczną do wytworzenia produktów pracy. Jest planowany i wykonywany zgodnie z polityką organizacji, wykorzystuje ludzi posiadających odpowiednie kwalifikacje i posiada odpowiednie zasoby, by wygenerować wyniki podlegające kontroli. Proces zarządzany posiada odpowiednich interesariuszy, jest monitorowany i kontrolowany, podlega przeglądom i jest oceniany pod kątem zgodności

z opisem. Proces może być realizowany przez projekt, grupę lub jednostkę organizacyjną. Kontrola zapewniana przez proces zarządzany pomaga w zapewnieniu, że ustanowiony proces będzie działał w czasach kryzysu.

GP 2.1. Ustanowienie polityki organizacyjnej

Celem tej ogólnej praktyki jest zdefiniowanie oczekiwań organizacji w zakresie procesu i pokazanie tych oczekiwań tym członkom organizacji, na których proces ma wpływ. Ogólnie rzecz ujmując, kierownictwo wyższego szczebla jest odpowiedzialne za opracowanie

i ogłoszenie zasad, którymi organizacja ma się kierować, kierunków jej rozwoju i oczekiwań.

GP 2.2. Zaplanowanie procesu

Celem tej ogólnej praktyki jest zdefiniowanie oczekiwań organizacyjnych dotyczących procesu i uczynienie tych oczekiwań widocznymi dla osób w organizacji, których to dotyczy. Ogólnie rzecz ujmując, kierownictwo wyższego szczebla jest odpowiedzialne za ustanowienie i przekazanie zasad przewodnich, kierunku i oczekiwań wobec organizacji.

GP 2.3. Zapewnienie zasobów

Celem tej ogólnej praktyki jest zapewnienie, że zasoby potrzebne do przeprowadzenia procesu określonego w planie będą dostępne wtedy, kiedy będą potrzebne. Zasoby oznaczają wystarczające fundusze, odpowiednią infrastrukturę, wykwalifikowanych pracowników oraz odpowiednie narzędzia.

GP 2.4. Przydzielenie odpowiedzialności

Celem tej ogólnej praktyki jest zapewnienie, że wyznaczona jest osoba odpowiedzialna za wykonywanie procesu i osiąganie wyznaczonych celów przez cały czas istnienia procesu. Wyznaczone osoby muszą posiadać odpowiednie uprawnienia do wykonywania przydzielonych im obowiązków. Zakresy odpowiedzialności mogą być wyznaczone za pomocą szczegółowych opisów stanowisk lub w formie dokumentów takich jak plan wykonania procesu.

GP 2.5. Przeszkolenie ludzi

Celem tej ogólnej praktyki jest zapewnienie, że ludzie posiadają umiejętności

i kompetencje konieczne do wykonywania lub wspierania procesu. Osobom, które będą wykonywać pracę, zapewnia się odpowiednie szkolenie. Pracownicy wchodzący

w interakcję z osobami wykonującymi proces podlegają skróconym szkoleniom. Szkolenie wspiera pomyślne wykonanie procesu poprzez wypracowanie wspólnego zrozumienia procesu oraz przekazanie kompetencji i wiedzy potrzebnych do jego wykonania.

GP 2.6. Zarządzanie konfiguracją

Celem tej ogólnej praktyki jest ustanowienie i utrzymywanie integralności wybranych produktów pracy procesu przez cały okres ich użytkowania. Wybrane produkty pracy są specjalnie oznaczane w planie wykonania procesu wraz z odpowiadającym im poziomem zarządzania konfiguracją np. kontrola wersji lub formalne zarządzanie konfiguracją

z wykorzystaniem punktów odniesienia. Przykładami praktyk zarządzania konfiguracją są: kontrola wersji, kontrola i historia zmian, identyfikacja statusu oraz wykorzystanie narzędzi do zarządzania konfiguracją do przechowywania produktów procesu. Obszar praktyki Zarządzanie konfiguracją w CMMI dokładniej opisuje, w jaki sposób produkty obejmuje się zarządzaniem konfiguracją [CMMI w.2].

GP 2.7. Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Celem tej praktyki ogólnej jest uzyskanie i utrzymanie oczekiwanego poziomu zaangażowania interesariuszy w trakcie wykonywania procesu. Właściwi interesariusze są angażowani w takie czynności jak: planowanie, podejmowanie decyzji, zobowiązań, komunikacja, przeprowadzanie przeglądów czy rozwiązywanie problemów. Krytycznymi interesariuszami procesu testowania są menedżerowie oraz użytkownicy/klienci. Rola kierownika wiąże się z zaangażowaniem i umiejętnością wykonywania czynności i zadań związanych z doskonaleniem zdolności testowych. Rola użytkownika lub klienta polega między innymi na współpracy, wspieraniu, a czasami wykonywaniu zadań testowych. Użytkownicy i klienci powinni być angażowani w zadania związane z jakością oraz zadania skupiające się na realizacji ich potrzeb. Nacisk powinien zostać położony na uzyskanie wsparcia użytkowników/klientów, zgodę oraz udział w czynnościach takich jak: analiza ryzyka produktowego, testowanie akceptacyjne czy testowanie użyteczności. W zależności od poziomu testów interesariuszami mogą być też programiści. Na przykład na poziomie testów modułowych deweloperzy często sami wykonują testy, jednakże na poziomie testów akceptacyjnych programista staje się interesariuszem w dyskusji na temat zaraportowanych incydentów, ustalaniu kryteriów wejścia itp.

GP 2.8. Monitorowanie i kontrola procesu

Celem tej ogólnej praktyki jest sprawowanie codziennego nadzoru i kontroli nad procesem testowego. Należy utrzymywać odpowiedni wgląd w proces testowy tak, aby można było wykonać działania korygujące, jeżeli zaistnieje taka potrzeba. Na monitorowanie i kontrolę procesu składa się pomiar odpowiednich atrybutów procesu testowego oraz produktów pracy tego procesu. Więcej informacji na temat obiektywnej oceny przestrzegania zasad znajduje się w obszarze praktyki Zarządzanie wydajnością i pomiary (Managing Performance and Measurement) w CMMI [w.2.].

GP 2.9. Obiektywna ocena przestrzegania zasad

Celem tej ogólnej praktyki jest dostarczenie wiarygodnego zapewnienia, że proces został wdrożony tak, jak planowano i że jest zgodny z opisem, standardem

i procedurami. Oceny przestrzegania zasad przez proces testowy zwykle dokonują ludzie, którzy nie są bezpośrednio odpowiedzialni za zarządzanie lub wykonywanie czynności

w ramach tego procesu. W wielu przypadkach przestrzeganie zasad jest oceniane przez osoby w organizacji będące poza procesem testowym lub projektem. Więcej informacji na temat obiektywnej oceny przestrzegania zasad znajduje się w obszarze praktyki Zapewnienie jakości procesu (Process Quality Assurance) w CMMI [w. 2.].

GP 2.10. Przegląd statusu z kierownictwem wyższego szczebla

Celem tej ogólnej praktyki jest zapewnienie kierownictwu wyższego szczebla odpowiedniego wglądu w proces. Zarządzanie wyższego szczebla obejmuje te poziomy zarządzania w organizacji, które znajdują się powyżej bezpośredniego poziomu zarządzania odpowiedzialnego za ten proces. Przeglądy statusu są przeznaczone dla menedżerów, którzy opracowują zasady i ogólne wytyczne dla procesu, a nie dla tych, którzy na co dzień bezpośrednio monitorują i kontrolują proces.

GG 3.   Instytucjonalizacja procesu zdefiniowanego

Zdefiniowany proces jest procesem zarządzanym, który jest dostosowany do zbioru standardowych procesów w organizacji, zgodnie z jego wytycznymi dotyczącymi indywidualnego dopasowania w organizacji. Zdefiniowany proces charakteryzują przygotowane opisy procesów i wnosi on do zasobów procesów organizacyjnych produkty pracy, narzędzia i inne istotne informacje o doskonaleniu procesów. Krytycznym czynnikiem odróżniającym proces zarządzany od procesu zdefiniowanego jest zakres stosowania opisów procesów, standardów i procedur. Najbardziej istotna różnica pomiędzy procesem zarządzanym a zdefiniowanym leży w zakresie zastosowania opisów procesów, standardów

i procedur. Dla procesu zarządzanego opisy, standardy i procedury stosuje się dla poszczególnych projektów, grup lub funkcji w organizacji. Skutkuje to tym, że w dwóch różnych projektach w tej samej organizacji proces zarządzany może być różny. Proces zdefiniowany jest zestandaryzowany w takim stopniu, w jakim jest to możliwe w organizacji i adaptowany na potrzeby konkretnych projektów lub funkcji organizacyjnych tylko wtedy, kiedy to jest konieczne i z zachowaniem wytycznych dotyczących dostosowywania procesów.

GP 3.1. Ustanowienie procesu zdefiniowanego

Celem tej ogólnej praktyki jest ustalenie i utrzymanie opisu procesu, który jest dostosowany do potrzeb konkretnej instancji z zestawu standardowych procesów organizacji.  Organizacja powinna posiadać standardowe procesy, które pokrywają obszar procesowy oraz reguły ich dostosowywania do potrzeb projektów lub funkcji w organizacji. Jeżeli istnieje proces zdefiniowany, rozbieżności pomiędzy sposobami wykonywania różnych procesów

w organizacji są zminimalizowane, a zasoby procesów, dane i wnioski mogą być skutecznie udostępniane. Więcej informacji na temat zbioru standardowych procesów i wytycznych dotyczących dostosowania znajduje się w obszarze praktyki Zarządzanie aktywami procesu procesów w organizacji (Process Asset Development) w CMMI.

GP 3.2. Zbieranie informacji o usprawnieniach

Celem tej ogólnej praktyki jest zbieranie informacji oraz artefaktów pochodzących

z planowania i wykonywania procesu w celu wykorzystania ich w przyszłości oraz

w celu doskonalenia procesów i ich produktów w organizacji. Te informacje i artefakty są przechowywane i udostępniane tym, którzy są (lub będą) planować i wykonywać

te same lub podobne procesy.

3.4.      Obszary procesowe wspierające ogólne praktyki

Ogólne cele i ogólne praktyki są tymi komponentami modelu, które wprost odnoszą się do instytucjonalizacji procesu w całej organizacji. Wiele obszarów procesowych TMMi lub tak zwanych obszarów praktyk CMMI [CMMI w. 2.] również dotyka instytucjonalizacji poprzez wspieranie wprowadzania w życie ogólnych praktyk. Poniższa tabela przedstawia przegląd tych obszarów procesowych TMMi lub obszarów praktyk CMMI, które częściowo lub całkowicie wspierają wdrażanie ogólnych praktyk.

Ogólna praktyka

Wspierające obszary procesowe i praktyk

GP 2.2.

Zaplanowanie procesu

Planowanie testów - obszar procesowy Planowanie testów z TMMi pozwala na pełne zaimplementowanie GP 2.2. dla wszystkich obszarów procesowych związanych z projektem (za wyjątkiem samego planowania testów). Planowanie testów może stanowić część obszaru praktyki Planowanie (Planning) z CMMI.

GP 2.5.

Przeszkolenie ludzi

Program szkoleń testerskich - obszar procesowy TMMi Program szkoleń testerskich wspiera wdrażanie GP 2.5. dla wszystkich obszarów procesowych poprzez udostępnienie ogólnoorganizacyjnego programu szkoleniowego tym, którzy będą realizować lub wspierać procesy.

Ponadto obszar TMMi Planowanie testów (Test Planning) może wspierać tę ogólną praktykę poprzez identyfikację i organizowanie szkoleń

w zakresie testowania w projekcie i dokumentowania ich w planie testów.

GP 2.6.

Zarządzanie konfiguracją

Zarządzanie konfiguracją - obszar praktyki CMMI Zarządzanie konfiguracją może w pełni wdrożyć GP 2.6. dla wszystkich obszarów procesów związanych z projektem, jak również niektórych obszarów procesów organizacyjnych.

GP 2.7.

Zidentyfikowanie

i zaangażowanie właściwych interesariuszy

Planowanie testów - obszar procesowy TMMi Planowanie testów może wspierać tę ogólną praktykę dla wszystkich obszarów procesu związanego z projektem poprzez planowanie zaangażowania zidentyfikowanych interesariuszy i wpisanie ich do planu testów.

Zaangażowanie interesariuszy w planowanie testów może zostać uwzględnione jako część obszaru praktyki CMMI Planowanie.

GP 2.8.

Monitorowanie

i kontrola procesu

Monitorowanie i kontrola testów - obszar procesowy TMMI Monitorowanie i Kontrola Testów może w pełni wdrożyć GP 2.8 dla wszystkich obszarów procesu.

GP 2.9.

Obiektywna ocena przestrzegania zasad

Zapewnienie jakości procesu – obszar praktyki CMMI Zapewnienie Jakości Procesu może w pełni wdrożyć GP 2.9. dla wszystkich obszarów procesu.

GP 3.1. Ustanowienie procesu zdefiniowanego

Zarządzanie aktywami procesu - obszar praktyki CMMI Zarządzanie aktywami procesu może wspierać implementację GP 3.1. poprzez ustanowienie zasobów organizacyjnych niezbędnych do wdrożenia GP 3.1.

Cykl życia i integracja testów - ten obszar procesowy TMMi może wspierać implementację GP 3.1. poprzez ustanowienie zasobów organizacyjnych niezbędnych do wdrożenia GP 3.1., w oparciu o swój cel szczegółowy SG 1. Ustanowienie zasobów organizacyjnych procesu testowego (Establish Organizational Test Process Assets).

GP 3.2.

Zbieranie informacji

o usprawnieniach

Zarządzanie procesem  - obszar praktyki CMMI Zarządzanie Wydajnością i Pomiary (Managing Performance and Measurement) może zapewnić wsparcie przy wdrażaniu GP 3.2., ponieważ tworzy organizacyjne repozytorium pomiarowe.

Cykl życia i integracja testów - ten obszar procesowy TMMi może zapewnić podobne wsparcie przy wdrażaniu GP 3.2, ponieważ tworzy organizacyjną bazę danych procesu testowego.

Zarządzanie Wydajnością i Pomiary - dla wszystkich procesów obszar praktyki CMMI Zarządzanie wydajnością i pomiary oraz obszar procesowy TMMI Pomiar testów (Test Measurement) zapewniają ogólne wytyczne dotyczące pomiaru, analizy i zapisu informacji, które mogą być wykorzystane w ustanawianiu środków do monitorowania rzeczywistej wydajności procesów.

Tabela 1. Obszary procesowe i obszary praktyk wspierające ogólne praktyki

3.5.      Wsparcie obszarów procesowych CMMI dla TMMi

Chociaż TMMi może i dzisiaj jest najczęściej używane osobno, jest również wykorzystywane jako model uzupełniający CMMI. W związku z tym w wielu przypadkach dany poziom modelu TMMi wymaga szczególnego wsparcia ze strony obszarów praktyki na odpowiadającym mu poziomie CMMI lub wyższym. Obszary praktyki i praktyki wypracowane w ramach CMMI z reguły nie są powtarzane, a jedynie przywoływane w TMMi. W tabelach od numeru 2 do 5 podsumowano obszary praktyki CMMI, które uzupełniają i/lub pokrywają się

z obszarami procesu TMMi. Należy zauważyć, że jak pokazano w tabelach 2–5, obszary praktyki pomocniczej (S) i równoległe obszary praktyki (P) są oznaczone. Wspierane obszary praktyki (S) obejmują te obszary praktyki i powiązane praktyki, które powinny być idealnie wdrożone, aby wspierać osiągnięcie celów TMMi. Równoległe obszary praktyki (P) to te, które mają podobny charakter w TMMi i CMMI i prawdopodobnie mogą być wdrażane jednocześnie. Przegląd obszarów praktyk CMMI wymaganych do osiągnięcia poziomu 2 TMMi przedstawiono w tabeli 2. Tabele 3, 4 i 5 zawierają przegląd pomocniczych i równoległych obszarów procesu CMMI wymaganych odpowiednio dla poziomów TMMI 3, 4 i 5. Należy zauważyć, że niektóre z tych relacji zostały już zidentyfikowane, choć z innej perspektywy,

w poprzedniej sekcji.

Wsparcie obszarów praktyk CMMI dla TMMi 2

Zarządzanie konfiguracją (S) – jak zaznaczono powyżej, obszar praktyki CMMI Zarządzanie konfiguracją może wdrożyć GP 2.6. Zarządzanie konfiguracją dla wszystkich obszarów procesów związanych z projektem, jak również niektórych obszarów procesów organizacyjnych.

Zapewnienie jakości procesu (S) – jak zaznaczono powyżej, obszar praktyki CMMI Zapewnienie jakości procesu może w pełni wdrożyć GP 2.9. dla wszystkich obszarów procesu.

Monitorowanie i kontrola(S) – ten obszar praktyki CMMI zapewnia wsparcie dla wdrażania obszaru procesowego TMMi Monitorowanie i kontrola testów. Metody zarządzania projektami mogą być ponownie wykorzystane do zarządzania testami.

Planowanie (S) – ten obszar praktyki CMMI zapewnia wsparcie przy wdrażaniu obszaru procesowego TMMi Planowanie testów. Praktyki zarządzania projektami mogą być ponownie wykorzystane do zarządzania testami. Planowanie wspiera również

w szczególności wdrożenie ogólnej praktyki GP 2.7. Zidentyfikowanie i zaangażowanie właściwych interesariuszy.

Zarządzanie Wydajnością i Pomiary (S) – ten obszar praktyki CMMI zapewnia wsparcie przy wprowadzaniu SG 3. Ustanowienie wskaźników skuteczności testów obszaru procesowego TMMi Polityka i strategia testów.

Rozwój i zarządzanie wymaganiami (S) – ten obszar praktyki CMMI zapewnia wdrożenie ograniczeń w zarządzaniu pochodnymi produktami (pracy) takimi jak Analiza ryzyka produktowego i projektowanie testów wraz z ich aktualizacją. Praktyki dotyczące monitorowania mogą być ponownie wykorzystane w obszarze TMMi Projektowanie

i wykonywanie testów.

Rozwój i zarządzanie wymaganiami (S) – praktyki z obszaru praktyki CMMI mogą być ponownie wykorzystane przy opracowywaniu wymagań dotyczących środowiska testowego w obszarze procesowym TMMi Środowisko testowe.

Zarządzanie ryzykiem i szansami (S) – działania z tego obszaru praktyki CMMI mogą być ponownie wykorzystane do identyfikacji i kontroli ryzyka produktowego oraz ryzyka projektu testowego w ramach obszarów procesu TMMi Planowanie testów oraz Monitorowanie

i kontrola testów.

Tabela 2. Wsparcie dla poziomu dojrzałości TMMi 2 z obszarów praktyk CMMI w. 2.

Wsparcie obszarów praktyk CMMI dla TMMi 3

Zarządzanie konfiguracją (S) – obszar praktyki CMMI Zarządzanie konfiguracją może

w pełni wdrożyć GP 2.6. dla wszystkich obszarów procesów związanych z projektem, jak również niektórych obszarów procesów organizacyjnych.

Zarządzanie wydajnością i pomiary (S) – obszar praktyki CMMI Zarządzanie wydajnością

i pomiary zapewnia ogólne wskazówki dotyczące pomiaru, analizy i zapisu informacji, wspierając tym samym wdrożenie ogólnej praktyki TMMi GP 3.2. Zbieranie informacji

o usprawnieniach.

Zapewnienie jakości procesu (S) – obszar praktyki CMMI Zapewnienie jakości procesu może wdrożyć GP 2.9. Obiektywna ocena przestrzegania zasad dla wszystkich obszarów procesu.

Planowanie (S) - ten obszar praktyki CMMI zapewnia wsparcie przy wdrażaniu  obszaru procesowego TMMi Cykl życia i integracja testów, zwłaszcza SG 3. Ustalenie głównego planu testów. Praktyki zarządzania projektami mogą być ponownie wykorzystane do zarządzania testami.

Rozwój aktywów procesu (P) – ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia obszaru procesowego TMMi Cykl życia i integracja testów, zwłaszcza dla SG 1. Ustanowienie zasobów organizacyjnych procesu testowego.

Obszar praktyki CMMI Rozwój aktywów procesu może również wspomagać implementację GP 3.1. Ustanowienie procesu zdefiniowanego poprzez określenie zasobów procesów organizacyjnych niezbędnych do wdrożenia GP 3.1.

Zarządzanie procesem (P) –  ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia obszaru procesu TMMi Organizacja testowa, w szczególności dla SG 4. Określanie, planowanie i wdrażanie usprawnień procesu testowego oraz SG 5. Wdrożenie procesów testowych

w organizacji i wykorzystanie zdobytych doświadczeń.

Obszar procesowy CMMI Koncentracja na procesie organizacyjnym zapewnia również wsparcie dla implementacji ogólnej praktyki TMMi GP 3.2. Zbieranie informacji

o usprawnieniach, ponieważ tworzy organizacyjne repozytorium wyników.

Szkolenia organizacyjne (S) – ten obszar procesowy CMMI zapewnia wsparcie przy wdrażaniu obszaru procesowego TMMi Program szkoleń testerskich.

Weryfikacja (P) – praktyki w ramach SG 2. Przeprowadzanie przeglądów koleżeńskich obszaru procesu CMMI będą stanowić wsparcie dla wdrażania obszaru procesu TMMi Przeglądy koleżeńskie.

Tabela 3. Wsparcie dla poziomu dojrzałości TMMi 3 z obszarów praktyk CMMI w. 2.

Wsparcie obszarów praktyk CMMI dla TMMi 4

Zarządzanie konfiguracją (S) – obszar praktyki CMMI Zarządzanie konfiguracją może zaimplementować GP 2.6. Zarządzanie konfiguracją dla wszystkich obszarów procesów związanych z projektem, jak również niektórych obszarów procesów organizacyjnych.

Zarządzanie wydajnością i pomiary (S, P) – ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia obszaru procesowego TMMi Pomiar testów. Infrastruktura i praktyki pomiarowe mogą być ponownie wykorzystane do pomiarów testów. Praktycznym rozwiązaniem może być wdrożenie programu pomiarów testów jako dodatku do ogólnego programu pomiarowego. Ten obszar praktyki CMMI zapewnia również wsparcie dla wdrożenia obszaru procesowego TMMi Ocena jakości produktu, zarówno dla SG 1 Mierzalne cele projektu dla jakości produktu i ich priorytety są ustalone, jak i SG 2 Rzeczywisty postęp w osiąganiu celów jakości produktu jest określany ilościowo i zarządzany

Ostatecznie obszar praktyki CMMI Zarządzanie wydajnością i pomiary  zapewnia również ogólne wskazówki dotyczące pomiaru, analizy, zapisu i przekazywania informacji, wspierając w ten sposób wdrożenie ogólnej praktyki TMMi GP 3.2. Zbieranie informacji

o usprawnieniach.

Zapewnienie jakości procesu (S) – obszar praktyki CMMI Zapewnienie jakości procesu może zaimplementować GP 2.9. Obiektywna ocena przestrzegania zasad dla wszystkich obszarów procesowych.

Rozwój aktywów procesu (S) – ten obszar praktyki CMMI wspiera wdrożenie GP 3.1. Ustanowienie procesu zdefiniowanego poprzez określenie zasobów procesu organizacyjnego niezbędnych do implementacji GP 3.1.

Zarządzanie procesem (S) – ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia GP 3.2. Zbieranie informacji o usprawnieniach, ponieważ tworzy on organizacyjne repozytorium pomiarów.

Tabela 4. Wsparcie dla poziomu dojrzałości TMMi 4 z obszarów praktyk CMMI w. 2.

Wsparcie obszarów praktyk CMMI dla TMMi 5

Zarządzanie konfiguracją (S) – obszar praktyki CMMI Zarządzanie konfiguracją może zaimplementować GP 2.6. dla wszystkich obszarów procesów związanych z projektem, jak również niektórych obszarów procesów organizacyjnych.

Obszar praktyki CMMI Zarządzanie wydajnością i pomiary (S) zapewnia ogólne wskazówki dotyczące pomiaru, analizy i zapisu informacji, wspierając w ten sposób wdrożenie ogólnej praktyki TMMi GP 3.2. Zbieranie informacji o usprawnieniach. Ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia obszaru procesowego TMMi Kontrola jakości, szczególnie dla SG 1 Ustanowienie statystycznie kontrolowanego procesu testowego.

Zapewnienie jakości procesu (S) – obszar praktyki CMMI Zapewnienie jakości procesu

i produktu może zaimplementować GP 2.9. Obiektywna ocena przestrzegania zasad dla wszystkich obszarów procesowych.

Rozwój aktywów procesu (S) – ten obszar praktyki CMMI wspiera wdrożenie GP 3.1. Ustanowienie procesu zdefiniowanego poprzez określenie zasobów procesu organizacyjnego niezbędnych do implementacji GP 3.1. Zapewnia również wsparcie dla wdrożenia obszaru procesowego TMMi Optymalizacja procesu testowego, szczególnie w przypadku udoskonaleń procesu testowego SG 1 Wybór nowych technologii testowych, SG 2 Nowe technologie testowe są oceniane w celu określenia ich wpływu na proces testowania oraz SG 3 Wdrażanie udoskonaleń testów.

Zarządzanie procesem (S) – ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia GP 3.2. Zbieranie informacji o usprawnieniach, ponieważ tworzy on organizacyjne repozytorium pomiarów.

Analiza przyczyn i rozwiązanie (P) – ten obszar praktyki CMMI zapewnia wsparcie dla wdrożenia obszaru procesowego TMMi Zapobieganie defektom, szczególnie dla SG 1. Określenie typowych przyczyn błędów.

Tabela 5. Wsparcie dla poziomu dojrzałości TMMi 5 z obszarów praktyk CMMI w. 2.

Należy pamiętać, że specyficzne dla testów obszary procesowe Weryfikacja i walidacja CMMI nie są wymienione jako wspierające lub równoległe obszary procesowe dla dynamicznych procesów testowania w TMMi. Dla tych obszarów procesu CMMI relacja jest komplementarna. Obszary procesowe TMMi zapewniają wsparcie i bardziej szczegółową specyfikację tego, co jest wymagane do ustanowienia zdefiniowanego procesu weryfikacji

i walidacji. Praktyczne doświadczenia pokazały, że organizacja, która spełnia wymagania TMMi na poziomie 2., jednocześnie w dużej mierze lub całkowicie spełni wymagania dotyczące weryfikacji i walidacji obszarów procesu CMMI (w wyjątkiem konkretnego celu wzajemnej oceny i powiązanych praktyk w obszarze procesu weryfikacji). Jest to dobry przykład tego, jak spełnienie celów i wdrożenie praktyk w jednym modelu (TMMi) może prowadzić do zadowalającego wdrożenia w drugim (CMMI). Jest to również dobry przykład tego, w jaki sposób model doskonalenia TMMi specyficzny dla testów uzupełnia bardziej ogólne modele doskonalenia oprogramowania i rozwoju systemu (np. CMMI).

3.6.      Obszary praktyk CMMI Weryfikacja, walidacja

i przeglądy koleżeńskie

Należy zauważyć, że obszary praktyk szczegółowych dla testów CMMI w. 2. [CMMIV2] Weryfikacja i walidacja oraz Przeglądy koleżeńskie nie są wymienione jako wspierające lub równoległe obszary procesowe dla dynamicznych i statycznych procesów testowania w TMMi. Dla tych obszarów praktyki CMMI relacja jest komplementarna. Obszary procesowe TMMi zapewniają wsparcie i bardziej szczegółową specyfikację, w szczególności tego, co jest wymagane do ustanowienia zdefiniowanego procesu weryfikacji i walidacji. Praktyczne doświadczenia pokazały, że organizacja, która spełnia wymagania TMMi poziomu 2, będzie jednocześnie w dużej mierze lub w pełni spełniać wymagania dotyczące weryfikacji i walidacji obszarów praktyki CMMI. Jest to dobry przykład tego, jak satysfakcjonujące cele i wdrożenie praktyk w jednym modelu (TMMi) może prowadzić do zadowalającego wdrożenia w drugim (CMMI). Jest to również dobry przykład tego, jak model doskonalenia specyficzny dla testu TMMI uzupełnia bardziej ogólne modele doskonalenia oprogramowania i rozwoju systemu (np. CMMI).

Poziom TMMi 2: Zarządzany

Na poziomie TMMi 2 testowanie staje się procesem zarządzanym i jest wyraźnie oddzielone od debugowania. Dyscyplina procesu odzwierciedlona przez poziom dojrzałości 2 pozwala zachować sprawdzone praktyki również w kryzysowych sytuacjach. Jednakże wielu interesariuszy nadal postrzega testowanie jako fazę projektu, która następuje po kodowaniu.

W kontekście doskonalenia procesu testowego tworzona jest strategia testów obejmująca całą firmę lub program. Opracowywane są również plany testów. W ramach planu testów definiowane jest podejście do testów, przy czym podejście to opiera się na wyniku oceny ryzyka produktowego. Do identyfikacji ryzyka produktowego wykorzystywane są techniki zarządzania ryzykiem oparte na udokumentowanych wymaganiach. Plan testów określa, jakie testy są wymagane oraz kiedy, w jaki sposób i przez kogo powinny być wykonywane. Zobowiązania są uzgadniane z interesariuszami i w razie potrzeby zmieniane. Testowanie jest monitorowane i kontrolowane, aby zapewnić jego zgodny z planem przebieg i stworzyć możliwość podjęcia działań w przypadku wystąpienia odchyleń. Status produktów pracy i realizacji usług w zakresie testowania jest widoczny dla kierownictwa. Do wyprowadzania i wyboru przypadków testowych ze specyfikacji stosowane są techniki projektowania testów. Jednakże testowanie może się rozpocząć stosunkowo późno w cyklu wytwarzania, np. w fazie projektowania lub nawet w fazie kodowania.

W TMMI na poziomie 2. testowanie jest wieloetapowe: istnieją poziomy testów modułowych, integracyjnych, systemowych i akceptacyjnych. Dla każdego zidentyfikowanego poziomu testów istnieją określone cele testowania zdefiniowane w strategii testów w całej organizacji lub w programie. Procesy testowania i usuwania usterek są rozróżniane.

Głównym celem testowania w organizacji TMMi na poziomie 2. jest sprawdzenie, czy produkt spełnia określone wymagania. Na tym poziomie TMMi występuje wiele problemów jakościowych, ponieważ testowanie odbywa się późno w cyklu wytwarzania. Usterki powstałe w fazie wymagań i projektowania przechodzą do kodu. Nie ma jeszcze przeglądów formalnych umożliwiających rozwiązanie tego ważnego problemu. Testowanie wykonywane po kodowaniu przez wielu interesariuszy jest nadal uważane za podstawową czynność testową.

Obszary procesowe na poziomie TMMi 2 są następujące:

2.1      Polityka i strategia testów

2.2      Planowanie testów

2.3      Monitorowanie i kontrola testów

2.4      Projektowanie i wykonywanie testów

2.5      Środowisko testowe

Poszczególne obszary zostały dokładniej omówione w kolejnych rozdziałach.

PA 2.1      Polityka i strategia testów

Cel

Celem obszaru procesowego Polityka i strategia testów jest opracowanie

i ustanowienie polityki testów oraz obejmującej całą organizację lub program strategii testów, w której w sposób jednoznaczny zostaną zdefiniowane poziomy testów. Na potrzeby pomiaru wydajności testowania wprowadzane są wskaźniki wydajności testów.

Uwagi wstępne

Jeśli organizacja zamierza usprawnić stosowany proces testowy, powinna najpierw

w jednoznaczny sposób zdefiniować politykę testów. Polityka testów określa ogólne cele testowania w organizacji, a także strategiczne koncepcje dotyczące testowania. Istotne jest, aby polityka testów była dopasowana do ogólnej polityki biznesowej (polityki jakości) danej organizacji. Polityka testów jest niezbędna do uzyskania przez wszystkich interesariuszy

w organizacji wspólnej wizji testowania i jego celów. Taka wspólna wizja jest warunkiem dostosowania czynności testowych (udoskonalenia procesu) w całej organizacji. Polityka testów powinna dotyczyć czynności testowych zarówno w nowych projektach rozwojowych, jak i projektach utrzymania. Polityka testów powinna również określać cele doskonalenia procesu testowego. Takie cele zostaną w dalszej kolejności odzwierciedlone w postaci zestawu kluczowych wskaźników wydajności testów. Polityka testów i związane z nią wskaźniki wydajności określają wyraźny kierunek działań oraz sposoby wyrażania oczekiwanych i uzyskiwanych poziomów wydajności testów. Wskaźniki wydajności muszą prezentować interesariuszom wartość testowania i odzwierciedlać udoskonalenia procesu testowego. Wskaźniki wydajności testów stanowią ilościową miarę usprawnień w organizacji

i realizacji zdefiniowanego zestawu celów testowania (celów doskonalenia testowania).

Strategia testów definiowana jest na podstawie polityki testów. Strategia testów obejmuje ogólne wymagania testowe w organizacji lub programie (dla jednego lub większej liczby projektów). Uwzględnia ona ogólne ryzyka produktowe i przedstawia proces łagodzenia takich ryzyk zgodny z polityką testów. Przygotowanie strategii testów rozpoczyna się od wykonania oceny ogólnego ryzyka produktowego na podstawie analizy produktów tworzonych w ramach programu lub organizacji.

Strategia testów stanowi punkt wyjścia dla czynności testowych realizowanych

w poszczególnych projektach. Projekty są organizowane zgodnie ze strategią testów przyjętą dla całej organizacji lub programu. Typowa strategia testów zawiera opis poziomów testów, które mają zostać zastosowane, np. testy modułowe, integracyjne, systemowe i akceptacyjne. Dla każdego poziomu testów należy zdefiniować co najmniej cele, zakres odpowiedzialności, główne zadania oraz kryteria wejścia i wyjścia. Strategia testów stanowi punkt wyjścia dla czynności testowych realizowanych w poszczególnych projektach. Projekty są organizowane zgodnie ze strategią testów przyjętą dla całej organizacji lub programu. Jeśli strategia testów zostanie zdefiniowana i będzie przestrzegana, zmniejszy się prawdopodobieństwo nakładania się poszczególnych poziomów testów, co pozwoli zwiększyć efektywność procesu testowego. Ponadto ze względu na uspójnienie celów i podejścia do testów na różnych poziomach,

w procesie testowym wystąpi mniej luk, co zwiększy jego wydajność.

Warto zauważyć, że w związku z ewolucją procesu testowego w organizacji i przechodzenia na wyższe poziomy TMMi zwykle wymagane jest wprowadzenie modyfikacji w polityce

i strategii testów.

Zakres

Obszar procesowy Polityka i strategia testów uwzględnia definicję i wdrożenie polityki i strategii testów na poziomie organizacji. W ramach strategii testów identyfikowane są poziomy testów. Dla każdego poziomu testów należy zdefiniować co najmniej cele testów, zakres odpowiedzialności, główne zadania oraz kryteria wejścia i wyjścia. Definiuje się również

i wdraża wskaźniki wydajności testów, które umożliwiają pomiar wydajności testów i realizacji celów testowania (celów doskonalenia testowania).

Podsumowanie celów (ang. SG – specific goal) i praktyk szczegółowych (ang. SP – specific practice)

SG 1       Ustanowienie polityki testów

SP 1.1       Zdefiniowanie celów testów

SP 1.2       Zdefiniowanie polityki testów

SP 1.3       Przekazanie polityki testów interesariuszom

SG 2       Ustanowienie strategii testów

SP 2.1       Wykonanie oceny ogólnego ryzyka produktowego

SP 2.2       Zdefiniowanie strategii testów

SP 2.3       Przekazanie strategii testów interesariuszom

SG 3       Ustanowienie wskaźników wydajności testów

SP 3.1       Zdefiniowanie wskaźników wydajności testów

SP 3.2       Wdrożenie wskaźników wydajności testów

Praktyki szczegółowe dla poszczególnych celów

SG 1      Ustanowienie polityki testów

Ustanowienie i uzgodnienie przez interesariuszy polityki testów zgodnej z polityką biznesową (polityką jakości).

SP 1.1      Zdefiniowanie celów testów

Zdefiniowanie i utrzymywane celów testów zgodnie z potrzebami i celami biznesowymi.

Przykładowe produkty pracy

1.      Cele testów

Podpraktyki

1.      Analiza potrzeb i celów biznesowych

Przykładowe potrzeby i cele biznesowe, które należy przeanalizować:

•      Misja organizacji

•      Potrzeby biznesowe i potrzeby użytkowników dotyczące produktów

•      Czynniki biznesowe

•      Główne cele programu zapewniania jakości

•      Polityka biznesowa (polityka jakości)

•      Typ działalności, np. poziom ryzyka tworzonych produktów

2.      Przekazywanie informacji zwrotnych w celu wyjaśnienia potrzeb i celów biznesowych

w niezbędnym zakresie

3.      Definiowanie celów testowania powiązanych z potrzebami i celami biznesowymi

Przykładowe cele testów:

•      Weryfikacja przydatności produktów do użytku

•      Zapobieganie występowaniu defektów podczas eksploatacji

•      Weryfikacja zgodności ze standardami zewnętrznymi

•      Zapewnienie widoczności informacji dotyczących jakości produktów

•      Skrócenie czasu wykonywania testów

4.      Przegląd celów testowania z udziałem interesariuszy

5.      Przegląd i aktualizacja celów testów zgodnie z potrzebami, np. raz do roku

SP 1.2       Zdefiniowanie polityki testów

Zdefiniowanie polityki testów zgodnej z polityką biznesową (polityką jakości) na podstawie celów testów oraz uzgodnienie jej przez interesariuszy.

Przykładowe produkty pracy

1.       Polityka testów

Podpraktyki

1.       Zdefiniowanie polityki testów na podstawie zdefiniowanych celów testów

Przykłady typowych elementów polityki testów [wg ISO 29119-3]:

•      Definicja testowania

•      Definicja debugowania (lokalizacji i usuwania usterek)

•      Podstawowe koncepcje dotyczące testowania i obszaru kompetencji związanego z testowaniem

•      Cele testowania i dodatkowe korzyści wynikające z testowania

•      Poziomy jakości, które należy osiągnąć

•      Poziom niezależności organizacji testowej

•      Wymagane szkolenia i certyfikacje

•      Etyka testera

•      Obowiązujące normy

•      Ogólna definicja procesu testowego

•      Najważniejsze obowiązki związane z testowaniem

•      Podejście organizacyjne do usprawniania procesu testowego i cele usprawniania

2.      Wyraźne rozróżnienie w ramach polityki testów między testowaniem a debugowaniem

3.      Przegląd polityki testów z udziałem interesariuszy

4.      Definicja i ustanowienie właściciela polityki testów

5.      Przegląd i aktualizacja polityki testów zgodnie z potrzebami, np. raz do roku

SP 1.3       Przekazanie polityki testów interesariuszom

Polityka testów i cele testów są przekazywane i wyjaśniane interesariuszom uczestniczącym

i nieuczestniczącym w testowaniu.

Przykładowe produkty pracy

1.      Plan wdrożenia

2.      Prezentacja polityki testów

Przykładowe mechanizmy dystrybucji:

•      Udokumentowanie w postaci podręcznika (systemu jakości)

•      Zaprezentowanie na spotkaniach projektowych i/lub wewnętrznych (np. działu)

•      Informacja na plakatach rozwieszonych w siedzibie organizacji

•      Włączenie polityki testów do programu wprowadzenia pracownika do działu

•      Udostępnienie w centralnym portalu organizacji

SG 2       Ustanowienie strategii testów

Ustanawiana jest i wdrażana strategia testów obejmująca całą organizację lub program,

w której określono i zdefiniowano poziomy wykonywania testów.

SP 2.1       Wykonanie oceny ogólnego ryzyka produktowego

Wykonywana jest ocena ogólnego ryzyka produktowego w celu zidentyfikowania typowych obszarów krytycznych podlegających testowaniu.

Przykładowe produkty pracy

1.      Lista ogólnych ryzyk produktowych z określeniem kategorii i priorytetu dla każdego ryzyka

Podpraktyki

1.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w ocenie ogólnego ryzyka

2.      Zidentyfikowanie ogólnych ryzyk produktowych na podstawie informacji przekazanych przez interesariuszy

3.      Udokumentowanie kontekstu i potencjalnych konsekwencji ogólnych ryzyk produktowych

4.      Zidentyfikowanie odpowiednich interesariuszy związanych z poszczególnymi ogólnymi ryzykami produktowymi

5.      Analiza zidentyfikowanych ogólnych ryzyk produktowych z wykorzystaniem predefiniowanych parametrów, np. prawdopodobieństwa i wpływu

6.      Kategoryzacja i pogrupowanie ogólnych ryzyk produktowych zgodnie ze zdefiniowanymi kategoriami ryzyka

7.      Ustalenie priorytetów ogólnych ryzyk produktowych na potrzeby ich łagodzenia

8.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności, kategorii i priorytetu ogólnych ryzyk  produktowych

9.      Aktualizacja ogólnych ryzyk produktowych zgodnie z potrzebami

Należy zwrócić uwagę, że kategorie i parametry ryzyka produktowego zdefiniowane

w obszarze procesowym Planowanie testów (SP 1.1 Definiowanie kategorii i parametrów ryzyka produktowego) są w dużej mierze wykorzystywane ponownie w ramach tej praktyki szczegółowej.

Więcej informacji na temat praktyk związanych z oceną ryzyka produktowego zawiera opis celu SG 1 Wykonanie oceny ryzyka produktowego z obszaru procesowego Planowanie testów.

SP 2.2       Zdefiniowanie strategii testów

Definiowana jest strategia testów, która identyfikuje i definiuje poziomy testów. Dla każdego poziomu definiuje się m.in. cele, zakres odpowiedzialności, główne zadania oraz kryteria wejścia i wyjścia.

Przykładowe produkty pracy

1.      Strategia testów

Podpraktyki

1.      Analiza polityki i celów testów

2.      Przekazywanie informacji zwrotnych na potrzeby wyjaśnienia polityki testów i celów biznesowych w niezbędnym zakresie

3.      Definiowanie strategii testów zawierającej wyraźne powiązania ze zdefiniowaną polityką i celami testów

Przykłady zagadnień uwzględnianych w strategii testów [wg ISO29119-3]:

•      Ogólne ryzyka związane z tworzonymi produktami

•      Ogólny model testów (model V, przyrostowy cykl życia), który ma zostać zastosowany w celu łagodzenia ryzyk

•      Poziomy testów (np. testy modułowe (jednostkowe), integracyjne, systemowe

i akceptacyjne)

•      Cele, zakres odpowiedzialności i główne zadania dla każdego poziomu testów, na przykład:

•      W testach modułowych:

- Weryfikacja, czy moduł działa zgodnie ze specyfikacją określoną w projekcie modułu

- Uzyskanie pewnego poziomu pokrycia kodu

•      W testach integracyjnych:

- Weryfikacja, czy moduły wspólnie działają zgodnie ze specyfikacją określoną w globalnym projekcie

- Weryfikacja, czy interfejsy działają zgodnie ze specyfikacją interfejsów

•      W testach systemowych:

- Weryfikacja, czy system działa zgodnie ze specyfikacją wymagań

- Uzyskanie pewnego poziomu pokrycia wymagań systemowych

•      W testach akceptacyjnych:

–      Weryfikacja, czy system spełnia zdefiniowane kryteria akceptacji

–      Sprawdzenie, czy system nadaje się do użytku

–      Uzyskanie pewnego poziomu pokrycia wymagań użytkowników

•      Techniki projektowania przypadków testowych, które należy zastosować na poszczególnych poziomach testów

•      Typy testów, które należy przeprowadzić na poszczególnych poziomach testów

•      Kryteria wejścia i wyjścia dla poszczególnych poziomów testów

•         Raportowanie i dokumentacja testów

•      Standardy, których należy przestrzegać

•      Poziom niezależności testowania

•      Środowisko, w którym mają być wykonywane testy

•      Podejście do automatyzacji na poszczególnych poziomach testów

•      Zarządzanie konfiguracją

•      Zarządzanie incydentami

•      Podejście do retestowania testowania regresji

4.      Przegląd strategii testów z udziałem interesariuszy

5.      Definicja i ustanowienie właściciela strategii testów

6.      Przegląd i aktualizacja strategii testów zgodnie z potrzebami, np. raz do roku

Należy pamiętać, że strategia testów posłuży jako punkt wyjścia do testowania wykonywanego w projekcie. W każdym projekcie można dostosowywać ogólną strategię organizacyjną do konkretnych potrzeb tego projektu. Wszelkie obszary niezgodności powinny zostać wyraźnie udokumentowane w planie testów projektu.

SP 2.3       Przekazanie strategii testów interesariuszom

Strategia testów jest prezentowana interesariuszom uczestniczącym i nieuczestniczącym

w testowaniu oraz wspólnie omawiana.

Przykładowe produkty pracy

1.      Plan wdrożenia

2.      Prezentacja strategii testów

Przykładowe mechanizmy dystrybucji:

•      Udokumentowanie w postaci podręcznika i/lub systemu jakości

•      Zaprezentowanie na spotkaniach projektowych i/lub wewnętrznych (np. działu)

•      Informacja na plakatach rozwieszonych w siedzibie organizacji

•      Włączenie strategii testów do programu wprowadzenia pracownika do działu

•      Udostępnienie w centralnym portalu organizacji

SG 3       Ustanowienie wskaźników wydajności testów

Ustanawiany jest i wdrażany zestaw zorientowanych na cel wskaźników wydajności procesu testowego, służących do pomiaru jakości procesu testowego.

SP 3.1       Zdefiniowanie wskaźników wydajności testów

Na podstawie polityki i celów testów definiowane są wskaźniki wydajności testów wraz

z procedurą gromadzenia, przechowywania i analizy danych.

Przykładowe produkty pracy

1.      Wskaźniki wydajności testów

2.      Procedury gromadzenia, przechowywania, analizy i raportowania danych

Podpraktyki

1.      Analiza polityki i celów testów, np. celów doskonalenia procesu testowego

2.      Przekazywanie informacji zwrotnych na potrzeby wyjaśnienia polityki testów i celów biznesowych w niezbędnym zakresie

3.      Definiowanie wskaźników wydajności testów powiązanych z polityką i celami testów

Przykładowe wskaźniki wydajności testów:

•      Pracochłonność i koszty testowania

•      Czas realizacji testów

•      Liczba wykrytych defektów

•      Odsetek wykrytych defektów

•      Pokrycie testowe

•      Poziom dojrzałości testów

Ogólnie rzecz ujmując, zdefiniowane wskaźniki wydajności testów powinny mieć związek

z wartością biznesową testowania.

4.      Przegląd wskaźników wydajności z udziałem interesariuszy

5.      Definicja i ustanowienie właściciela wskaźników wydajności testów

6.      Określenie sposobu uzyskiwania i przechowywania wskaźników wydajności

7.      Określenie sposobu analizowania i raportowania wskaźników wydajności

SP 3.2       Wdrożenie wskaźników wydajności testów

Wdrożenie wskaźników wydajności testów i przekazanie wyników pomiarów zidentyfikowanych wskaźników wydajności testów interesariuszom.

Przykładowe produkty pracy

1.      Dane wskaźników wydajności testów

2.      Raporty z informacjami dotyczącymi wskaźników wydajności testów

Podpraktyki

1.      Uzyskanie określonych danych wskaźnika wydajności

2.      Analiza i interpretacja wskaźnika wydajności

3.      Zarządzanie danymi wskaźnika wydajności i wynikami analizy oraz ich przechowywanie

4.      Okresowe raportowanie danych wskaźnika wydajności interesariuszom

5.      Udzielenie interesariuszom pomocy w interpretacji wyników

Przykłady działań związanych z pomocą w interpretacji wyników:

•      Przedyskutowanie wyników z odpowiednimi interesariuszami

•      Udostępnienie informacji o kontekście w celu przedstawienia założeń i wyjaśnień

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Polityka i strategia testów.

Opracowanie

Zwykle na poziomie organizacji dokumentuje się fakt, że okresowo (np. raz do roku) polityka

i strategia testów będą poddawane przeglądowi i aktualizowane zgodnie z potrzebami.

GP 2.2      Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Polityka i strategia testów.

Opracowanie

Plan realizacji procesu Polityka i strategia testów może zostać uwzględniony (lub przywołany) w planie jakości organizacji lub w planie doskonalenia procesu testowego.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Polityka i strategia testów, wytworzenia produktów pracy związanych z testowaniem oraz realizacji usług związanych

z procesem.

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Polityka i strategia testów, wytworzenia produktów pracy oraz realizacj usług związanych z procesem Polityka i strategia testów.

Opracowanie

Wyznaczana jest grupa osób dysponujących odpowiednimi uprawnieniami i wiedzą, odpowiedzialnych za zdefiniowanie polityki testów, strategii testów i wskaźników wydajności testów. W skład grupy wchodzą zwykle następujący interesariusze: osoby odpowiedzialne za zarządzanie kadrami, zarządzanie biznesowe, zarządzanie jakością, zarządzanie projektami, działalność operacyjną i zarządzanie testami oraz inżynierowie testów.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Polityka i strategia testów zgodnie z potrzebami.

Opracowanie

Osoby zaangażowane w definiowanie i utrzymywanie polityki testów i strategii testów uzyskują podstawową wiedzę dotyczącą ustrukturyzowanego testowania. Osoby uczestniczące

w pracach związanych ze wskaźnikami wydajności testów są szkolone w zakresie praktyk pomiarowych.

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Polityka i strategia testów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Polityka testów

•      Strategia testów

•      Definicje wskaźników wydajności

•      Dane pomiarowe

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Polityka i strategia testów zgodnie z planem.

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Polityka i strategia testów w odniesieniu do planu jego realizacji oraz podejmowanie odpowiednich działań.

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Polityka i strategia testów oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Zgodność planów testów z polityką testów i strategią testów

•      Poziom znajomości polityki testów, strategii testów i wskaźników wydajności testów wśród specjalistów ds. testów i innych interesariuszy

•      Dostępność danych wskaźników wydajności testów dla interesariuszy

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Polityka i strategia testów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

Ma zastosowanie wyłącznie na poziomie TMMi 3.

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Polityka i strategia testów

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Polityka i strategia testów, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

PA 2.2      Planowanie testów

Cel

Celem obszaru Planowanie testów jest zdefiniowanie podejścia do testów w oparciu

o zidentyfikowane ryzyka i zdefiniowaną strategię testów, a także ustanowienie i utrzymywanie uzasadnionych planów wykonywania czynności testowych i zarządzania tymi czynnościami.

Uwagi wstępne

Po potwierdzeniu zakresu przedsięwzięcia testowego wykonywana jest ogólna analiza dotycząca testowanych produktów, organizacji projektu, wymagań i procesu wytwarzania.

W ramach obszaru Planowanie testów definiuje się podejście do testów na podstawie wyniku oceny ryzyka produktowego i zdefiniowanej strategii testów. W zależności od kategorii

i priorytetu ryzyk podejmowana jest decyzja o tym, które wymagania dotyczące produktu zostaną przetestowane, w jakim stopniu, w jaki sposób i w którym momencie. Celem tych działań jest zapewnienie możliwie najlepszego pokrycia elementów systemu, z którymi wiąże się największe ryzyko.

Na podstawie podejścia do testów szacowana jest pracochłonność zadań do wykonania, a następnie prezentowane jest proponowane podejście wzbogacone o informacje o kosztach. Ryzyka produktowe, podejście do testów i oszacowania są definiowane w ścisłej współpracy z interesariuszami, a nie wyłącznie w wyniku prac zespołu testowego. Plan testów powinien być zgodny ze strategią testów, a w przypadku występowania niezgodności zawierać ich uzasadnienie.

W ramach obszaru Planowanie testów identyfikowane są produkty testowania, które mają zostać dostarczone. Określane są również niezbędne zasoby i definiowane aspekty związane z infrastrukturą. Ponadto identyfikuje się ryzyka projektu testowego dotyczące testowania. Tworzony plan testów określi, jakie testy są wymagane oraz kiedy, w jaki sposób i przez kogo powinny być realizowane.

Na koniec opracowywany jest dokument planu testów, który podlega uzgodnieniu

w gronie interesariuszy. Plan testów stanowi podstawę do wykonania i kontroli czynności testowych. Plan testów zwykle musi podlegać modyfikacjom z zastosowaniem formalnego procesu kontroli zmian w celu uwzględnienia zmian wymagań i zobowiązań, korekt niedokładnych oszacowań, działań naprawczych i zmian w procesie (testowym).

Zakres

Obszar procesowy Planowanie testów obejmuje wykonanie oceny ryzyka produktowego dla przedmiotu testów oraz zdefiniowanie zróżnicowanego podejścia do testów na podstawie zidentyfikowanych ryzyk. Uwzględnia również opracowanie oszacowań dotyczących testów, które należy wykonać, określenie niezbędnych zobowiązań oraz zdefiniowanie i utrzymywanie planu umożliwiającego kierowanie i zarządzanie testowaniem. Plan testów jest wymagany dla każdego zidentyfikowanego poziomu testów. Na poziomie TMMi 2 plany testów zwykle są opracowywane dla każdego poziomu testów. Na poziomie TMMi 3 ustanowienie głównego planu testów jest jednym z celów obszaru procesowego Cykl życia i integracja testów.

Podsumowanie celów i praktyk szczegółowych

SG 1       Wykonanie oceny ryzyka produktowego

SP 1.1       Zdefiniowanie kategorii i parametrów ryzyka produktowego

SP 1.2      Zidentyfikowanie ryzyk produktowych

SP 1.3      Analiza ryzyk produktowych

SG 2       Ustanowienie podejścia do testów

SP 2.1       Zidentyfikowanie elementów i funkcji podlegających testowaniu

SP 2.2       Zdefiniowanie podejścia do testów

SP 2.3       Zdefiniowanie kryteriów wejścia

SP 2.4       Zdefiniowanie kryteriów wyjścia

SP 2.5       Zdefiniowanie kryteriów zawieszenia i wznowienia

SG 3       Określenie oszacowań dotyczących testowania

SP 3.1      Ustanowienie struktury podziału pracy na najwyższym poziomie

SP 3.2       Zdefiniowanie cyklu życia testów

SP 3.3       Określenie oszacowań pracochłonności i kosztów testowania

SG 4       Opracowanie planu testów

SP 4.1       Ustanowienie harmonogramu testów

SP 4.2       Zaplanowanie obsady kadrowej testów

SP 4.3       Zaplanowanie zaangażowania interesariuszy

SP 4.4       Zidentyfikowanie ryzyk projektu testowego

SP 4.5       Ustanowienie planu testów

SG 5       Uzyskanie zobowiązań dotyczących realizacji planu testów

SP 5.1       Przegląd planu testów

SP 5.2       Uzgodnienie poziomów pracy i zasobów

SP 5.3       Uzyskanie zobowiązań dotyczących realizacji planu testów

Praktyki szczegółowe dla poszczególnych celów

SG 1      Wykonanie oceny ryzyka produktowego

Wykonywana jest ocena ryzyka produktowego w celu zidentyfikowania obszarów krytycznych w celu przetestowania.

SP 1.1       Zdefiniowanie kategorii i parametrów ryzyka produktowego

Definiowane są kategorie i parametry ryzyka produktowego, które będą używane w trakcie oceny ryzyka produktowego.

Przykładowe produkty pracy

1.      Listy kategorii ryzyka produktowego

2.      Kryteria oceny i priorytetyzacji ryzyka produktowego

Podpraktyki

1.      Określenie kategorii ryzyka produktowego

Określanie kategorii ryzyka produktowego wykonuje się po to, by ułatwić późniejszą konsolidację zadań testowych w planach testów zgodnie z typem testu.

Przykładowe kategorie ryzyka produktowego:

•      Ryzyka funkcjonalne

•      Ryzyka związane z architekturą

•      Ryzyka niefunkcjonalne, np. związane z użytecznością, efektywnością, przenaszalnością, utrzymywalnością i niezawodnością

•      Ryzyka związane ze zmianami, np. regresją

2.      Zdefiniowanie spójnych kryteriów oceny i określenia wartości prawdopodobieństwa wystąpienia i poziomu wpływu ryzyka produktowego

3.      Zdefiniowanie wartości progowych dla każdego poziomu ryzyka produktowego

Poziom ryzyka jest definiowany jako stopień ważności ryzyka wynikający z jego charakterystyki (wpływu i prawdopodobieństwa wystąpienia). Dla każdego poziomu ryzyka można ustalić wartości progowe w celu określenia akceptowalności lub braku akceptowalności ryzyka produktowego oraz priorytetów poszczególnych ryzyk produktowych, a także w celu określenia warunków rozpoczęcia działań zarządczych.

SP 1.2       Zidentyfikowanie ryzyk produktowych

Ryzyka produktowe są identyfikowane i dokumentowane.

Przykładowe produkty pracy

1.       Zidentyfikowane ryzyka produktowe

Podpraktyki

1.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w ocenie ryzyka

2.      Zidentyfikowanie ryzyk produktowych z wykorzystaniem informacji przekazanych przez interesariuszy i dokumentów wymagań

Przykładowe techniki identyfikowania ryzyk produktowych:

•      Warsztaty dotyczące ryzyka

•      Burza mózgów

•      Wywiady z ekspertami

•      Listy kontrolne

•      Wyciągnięte wnioski

3.      Udokumentowanie kontekstu i potencjalnych konsekwencji ryzyka

4.      Zidentyfikowanie odpowiednich interesariuszy związanych z poszczególnymi ryzykami

5.      Przegląd zidentyfikowanych ryzyk produktowych w odniesieniu do przedsięwzięcia testowego

SP 1.3       Analiza ryzyk produktowych

Ryzyka produktowe podlegają ocenie, kategoryzacji i priorytetyzacji z wykorzystaniem predefiniowanych kategorii i parametrów ryzyka produktowego.

Przykładowe produkty pracy

1.      Lista ryzyk produktowych z określeniem kategorii i priorytetu przypisanych do każdego ryzyka

Podpraktyki

1.      Analiza zidentyfikowanych ryzyk produktowych z wykorzystaniem predefiniowanych parametrów, np. prawdopodobieństwa i wpływu

2.      Kategoryzacja i pogrupowanie ryzyk produktowych zgodnie ze zdefiniowanymi kategoriami ryzyka

3.      Ustalenie priorytetów ryzyk produktowych na potrzeby ich łagodzenia

4.      Ustalenie możliwości poziomego śledzenia powiązań między ryzykami produktowymi

a wymaganiami w celu udokumentowania źródeł ryzyka produktowego

5.      Wygenerowanie macierzy śledzenia powiązań między wymaganiami a ryzykami produktowymi

6.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności, kategorii i priorytetu ryzyk produktowych

7.      Aktualizacja ryzyk produktowych zgodnie z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji ryzyk produktowych:

•      Nowe lub zmieniające się wymagania

•      Zmiana metod wytwarzania oprogramowania

•      Wyciągnięcie wniosków z problemów dotyczących jakości występujących w projekcie

SG 2       Ustanowienie podejścia do testów

Na podstawie zidentyfikowanych ryzyk produktowych ustanawiane jest i uzgadniane podejście do testów.

SP 2.1       Zidentyfikowanie elementów i funkcji podlegających testowaniu

Elementy i funkcje, które należy przetestować, oraz te, których nie trzeba testować, są identyfikowane na podstawie ryzyk produktowych.

Przykładowe produkty pracy

1.      Lista elementów podlegających i niepodlegających testowaniu

2.      Lista funkcji podlegających i niepodlegających testowaniu

Podpraktyki

1.      Rozbicie ryzyk produktowych z przypisanymi priorytetami na elementy podlegające

i niepodlegające testowaniu

2.      Udokumentowanie poziomu ryzyka i dokumentacja źródłowa (podstawa testów) dla każdego zidentyfikowanego elementu podlegającego testowaniu

3.      Rozbicie ryzyk produktowych z przypisanymi priorytetami na funkcje podlegające

i niepodlegające testowaniu

4.      Udokumentowanie poziomu ryzyka i dokumentacja źródłowa (podstawa testów) dla każdej zidentyfikowanej funkcji podlegającej testowaniu

5.      Przegląd listy elementów i funkcji podlegających i niepodlegających testowaniu

(z udziałem interesariuszy)

SP 2.2       Zdefiniowanie podejścia do testów

Definiowane jest podejście do testów w celu złagodzenia zidentyfikowanych ryzyk produktowych z przypisanymi priorytetami.

Przykładowe produkty pracy

1.      Podejście do testów, np. wybrany zestaw technik projektowania testów, powinno zostać opisane na wystarczającym poziomie szczegółowości, umożliwiającym zidentyfikowanie głównych zadań testowych i oszacowanie czasu wymaganego do wykonania każdego

z nich.

Podpraktyki

1.      Wybór technik projektowania testów, które będą stosowane. Definiuje się różne techniki projektowania testów w celu zapewnienia odpowiedniego pokrycia testowego

z uwzględnieniem zdefiniowanych ryzyk produktowych.

Kryteria wyboru techniki projektowania testów to między innymi:

•      Rodzaj systemu

•      Obowiązujące przepisy i normy

•      Wymagania klienta lub wymagania wynikające z umów

•      Poziom ryzyka

•      Rodzaj ryzyka

•      Dostępna dokumentacja

•      Wiedza testerów

•      Czas i budżet

•      Cykl wytwarzania oprogramowania

•      Dotychczasowe doświadczenie w zakresie spodziewanych typów defektów

2.      Zdefiniowanie metod przeglądu produktów pracy związanych z testowaniem

3.      Zdefiniowanie podejścia do testowania potwierdzającego.

Przykładowe elementy podejścia do testowania potwierdzającego:

•      W przypadku wszystkich elementów testowych, z którymi wiąże się wysokie ryzyko, nastąpi pełne testowanie potwierdzające z ponownym wykonaniem całej procedury testowej

•      W przypadku wszystkich elementów testowych, z którymi wiąże się niskie ryzyko, nastąpi testowanie potwierdzające incydentów w izolacji od reszty systemu

4.      Zdefiniowanie podejścia do testowania regresji

Przykładowe elementy podejścia do testowania regresji:

•      Zakres testów regresji, np. wskazanie elementów i/lub funkcji

•      Metody wyboru przypadków testowych do wykonania

•      Typy wykonywanych testów

•      Testy manualne lub użycie narzędzi do automatyzacji testów

5.      Określenie narzędzi wspierających testowanie

6.      Zidentyfikowanie istotnych ograniczeń dotyczących podejścia do testów

Przykładowe ograniczenia dotyczące podejścia do testów:

•      Dostępność zasobów testowych

•      Cechy środowiska testowego

•      Terminy wyznaczone w projekcie

7.      Dopasowanie podejścia do testów i strategii testów zdefiniowanej w organizacji lub programie

8.      Określenie ewentualnych niezgodności ze strategią testów i ich uzasadnienie

9.      Przegląd podejścia do testów z udziałem interesariuszy

10.      Aktualizacja podejścia do testów zgodnie z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji podejścia do testów:

•      Nowe lub zmienione priorytety ryzyk produktowych

•      Wyciągnięcie wniosków po zastosowaniu podejścia do testów w projekcie

SP 2.3       Zdefiniowanie kryteriów wejścia

Kryteria wejścia testów definiuje się w celu uniemożliwienia rozpoczęcia testowania

w warunkach, które nie pozwalają zrealizować procesu testowego w dokładny sposób.

Przykładowe produkty pracy

1.      Kryteria wejścia dla ustalonych poziomów testów

Podpraktyki

1.      Zdefiniowanie zestawu kryteriów wejścia powiązanych z procesem testowym

Przykłady kryteriów wejścia powiązanych z procesem testowym:

•      Dostępność sumarycznego raportu z testów na poprzednim poziomie testów

•      Dostępność środowiska testowego zgodnie z wymaganiami

•      Dostępność dokumentacji, np. opisu wydania testów, podręcznika użytkownika, podręcznika instalacji

2.      Zdefiniowanie zestawu kryteriów wejścia powiązanych z jakością produktów

Przykłady kryteriów wejścia powiązanych z jakością produktów:

•      Pomyślnie zakończony test wstępny (dymny)[2]

•      Brak nieusuniętych defektów (o priorytecie X)

•      Wykonana analiza wszystkich nieusuniętych defektów

3.      Przegląd kryteriów wejścia z udziałem interesariuszy, zwłaszcza osób odpowiedzialnych za spełnienie tych kryteriów

SP 2.4       Zdefiniowanie kryteriów wyjścia

Kryteria wyjścia testów definiuje się w celu ustalenia momentu zakończenia testowania.

Przykładowe produkty pracy

1. Kryteria wyjścia dla ustalonych poziomów testów

Podpraktyki

1. Zdefiniowanie zestawu kryteriów wyjścia powiązanych z procesem testowym

Przykłady kryteriów wyjścia powiązanych z procesem testowym:

•      Odsetek przygotowanych testów, które zostały wykonane (pomyślnie)

•      Procentowe pokrycie poszczególnych elementów testowych, np. pokrycie kodu lub pokrycie wymagań

•      Dostępność zatwierdzonego sumarycznego raportu z testów

2.      Zdefiniowanie zestawu kryteriów wyjścia powiązanych z jakością produktów

Przykłady kryteriów wyjścia powiązanych z jakością produktów:

•      Złagodzenie wszystkich ryzyk produktowych o wysokim priorytecie

•      Obniżenie wskaźnika wykrywania defektów poniżej wartości progowej

•      Liczba nieusuniętych defektów (według priorytetu)

•      Odsetek modułów oprogramowania objętych inspekcją projektu

3.      Przegląd kryteriów wyjścia z udziałem interesariuszy

Należy pamiętać, że kryteria wyjścia danego poziomu testów powinny być zgodne z kryteriami wejścia kolejnego poziomu.

SP 2.5       Zdefiniowanie kryteriów zawieszenia i wznowienia

Definiowane są kryteria używane do zawieszania i wznawiania wszystkich lub niektórych zadań testowych dotyczących elementów testowych i/lub funkcji.

Przykładowe produkty pracy

1.      Kryteria zawieszenia

2.      Kryteria wznowienia

Podpraktyki

1.      Specyfikacja kryteriów zawieszenia używanych do zawieszania wszystkich lub niektórych zadań testowych dotyczących elementów testowych i/lub funkcji

Przykładowe kryteria zawieszenia:

•      Liczba defektów krytycznych

•      Liczba defektów nieodtwarzalnych

•      Problemy z wykonywaniem testów związane ze środowiskami testowymi

2.      Specyfikacja kryteriów wznowienia używanych do wskazania zadań testowych, które należy powtórzyć w przypadku, gdy przestaną być spełnione kryteria powodujące zawieszenie testowania

SG 3       Określenie oszacowań dotyczących testowania

Określane są i utrzymywane uzasadnione oszacowania dotyczące testowania, które są następnie używane podczas omawiania podejścia do testów z interesariuszami i planowania czynności testowych.

SP 3.1       Ustanowienie struktury podziału pracy na najwyższym poziomie

Ustanowienie struktury podziału pracy (ang. Work Breakdown Structure - WBS) na najwyższym poziomie w celu jednoznacznego zdefiniowania zakresu wykonywanego testowania, a tym samym zakresu oszacowań dotyczących testów.

Przykładowe produkty pracy

1.      Lista produktów pracy związanych z testowaniem

2.      Zadania testowe do wykonania

3.      Struktura podziału pracy

Podpraktyki

1.      Określenie produktów pracy związanych z testowaniem, które muszą zostać wytworzone zgodnie ze zdefiniowanym podejściem do testów

2.      Wskazanie produktów pracy związanych z testowaniem, które zostaną pozyskane

z zewnątrz

3.      Wskazanie produktów pracy związanych z testowaniem, które zostaną ponownie wykorzystane

4.      Określenie zadań testowych do wykonania związanych z produktami pracy

5.       Określenie pośrednich zadań testowych, które należy wykonać (zarządzanie testami, spotkania, zarządzanie konfiguracją itp.)

Należy pamiętać, że struktura podziału pracy powinna również uwzględniać zadania związane z implementacją wymagań dotyczących środowiska testowego. Więcej informacji na ten temat można znaleźć w opisie obszaru procesowego Środowisko testowe.

SP 3.2      Zdefiniowanie cyklu życia testów

Zdefiniowanie faz cyklu życia testów, które mają być objęte planowaniem.

Przykładowe produkty pracy

1      Definicja faz cyklu życia testów

2.      Kamienie milowe związane z testowaniem

Podpraktyki

1      Definiowanie faz cyklu życia testów. Wyróżniane są co najmniej faza planowania testów, faza przygotowania testów i faza wykonania testów

2.      Zaplanowanie fazy przygotowania testów, tak aby rozpoczynała się od razu po zakończeniu tworzenia podstawy testów

3.      Dopasowanie struktury podziału pracy na najwyższym poziomie do zdefiniowanego cyklu życia testów

4.      Zidentyfikowanie głównych kamieni milowych dla poszczególnych faz cyklu życia testów

Należy zauważyć, że zrozumienie cyklu życia jest kluczowym warunkiem określenia zakresu prac związanych z planowaniem testów i czasu wstępnego planowania, a także momentu

i kryteriów ponownego planowania (w krytycznych kamieniach milowych).

SP 3.3       Określenie oszacowań pracochłonności i kosztów testowania

Oszacowanie pracochłonności i kosztów związanych z produktami pracy, które mają zostać wytworzone, oraz zadaniami testowymi, które mają zostać wykonane, w oparciu

o uzasadnienie oszacowań.

Przykładowe produkty pracy

1.      Oszacowania atrybutów produktów pracy związanych z testami i zadań testowych

2.      Oszacowania pracochłonności testów

3.      Oszacowania kosztów testów

Podpraktyki

1.      Określenie i utrzymywanie atrybutów produktów pracy związanych z testami i zadań testowych

Przykładowe atrybuty używane do oszacowań dotyczących produktów pracy i zadań testowych:

•      Wielkość, np. liczba przypadków testowych, liczba stron, liczba punktów testowych, ilość danych testowych, liczba wymagań

•      Złożoność powiązanego elementu testowego, np. liczba cyklomatyczna

•      Stopień ponownego wykorzystania

•      Priorytet powiązanego ryzyka produktowego

Do określenia atrybutów produktów pracy związanych z testowaniem oraz zadań testowych, które będą wykorzystywane do szacowania wymagań dotyczących zasobów, należy zastosować właściwie metody (np. zweryfikowane modele lub dane historyczne).

2.      Analiza czynników (technicznych), które mogą mieć wpływ na oszacowania dotyczące testów

Przykłady czynników, które mogą mieć wpływ na oszacowania dotyczące testowania:

•      Używanie narzędzi testowych

•      Jakość wcześniejszych poziomów testów

•      Jakość podstawy testów

•      Środowisko programistyczne

•      Środowisko testowe

•      Dostępność testaliów do ponownego wykorzystania pochodzących z poprzednich projektów

•      Wiedza i umiejętności testerów

3.      Wybór modeli i/lub danych historycznych, które zostaną użyte do przekształcenia atrybutów produktów pracy związanych z testowaniem i zadań testowych w oszacowania pracochłonności i kosztów

Przykłady modeli, które można zastosować do oszacowań dotyczących testowania:

•      Analiza punktów testowych [TMap]

•      Estymacja trzypunktowa

•      Szerokopasmowa technika delficka [Veenendaal]

•      Stosunek pracochłonności prac programistycznych do pracochłonności testowania

4.      Uwzględnienie potrzeb związanych z infrastrukturą pomocniczą podczas szacowania pracochłonności testowania

Przykłady infrastruktury pomocniczej:

•      Środowisko testowe

•      Krytyczne zasoby komputerowe

•      Środowisko biurowe

•      Narzędzia testowe

5.      Oszacowanie pracochłonności i kosztów testowania z wykorzystaniem modeli i/lub danych historycznych

6.      Udokumentowanie założeń przyjętych w trakcie tworzenia oszacowań

7.      Zarejestrowanie danych dotyczących oszacowań, w tym powiązanych informacji niezbędnych do odtworzenia oszacowań

SG 4       Opracowanie planu testów

Tworzony i utrzymywany jest plan testów stanowiący podstawę do zarządzania testami

i komunikacją z interesariuszami.

SP 4.1       Ustanowienie harmonogramu testów

Harmonogram testów, zawierający wstępnie zdefiniowane etapy o rozsądnej wielkości, jest ustanawiany i utrzymywany na podstawie opracowanych oszacowań dotyczących testowania i zdefiniowanego cyklu życia testów.

Przykładowe produkty pracy

1.      Harmonogram testów

Podpraktyki

1.      Zidentyfikowanie ograniczeń dotyczących harmonogramu testów, takich jak czas trwania zadania, niezbędne zasoby i produkty wejściowe

2.      Ustalenie zależności między zadaniami

3.      Zdefiniowanie harmonogramu testów (momentu wykonania czynności testowych, faz cyklu życia testów i kamieni milowych związanych z testowaniem)

4.      Udokumentowanie założeń przyjętych w trakcie definiowania harmonogramu testów

5.      Określenie kryteriów działań naprawczych umożliwiających zidentyfikowanie sytuacji,

w których występuje znaczne odchylenie od planu testów i potencjalnie istnieje potrzeba zmiany harmonogramu.

SP 4.2       Zaplanowanie obsady kadrowej testów

Tworzony jest plan dostępności niezbędnego personelu testowego dysponującego wiedzą

i umiejętnościami wymaganymi do przeprowadzenia testów.

Przykładowe produkty pracy

1.      Wymagania dotyczące obsady kadrowej

2.      Lista wymaganych kwalifikacji

3.      Plan obsady kadrowej i zatrudnienia nowych pracowników

4.      Plan szkoleń testerskich

Podpraktyki

1.      Określenie wymagań kadrowych w oparciu o strukturę podziału pracy, oszacowania dotyczące testowania i harmonogram testów

2.      Określenie wiedzy i umiejętności niezbędnych do wykonania zadań testowych

3.      Ocena dostępnej wiedzy i umiejętności

4.      Wybór mechanizmów pozyskiwania niezbędnej wiedzy i umiejętności

Przykładowe mechanizmy:

•      Szkolenie wewnętrzne

•      Szkolenie zewnętrzne

•      Coaching

•      Pozyskanie kwalifikacji na zewnątrz

5.      Uwzględnienie wybranych mechanizmów w planie testów

SP 4.3       Zaplanowanie zaangażowania interesariuszy

Tworzony jest plan udziału zidentyfikowanych interesariuszy.

Interesariusze identyfikowani są we wszystkich fazach cyklu życia testów poprzez ustalenie typów osób i stanowisk, które są niezbędne podczas wykonywania czynności testowych.

W trakcie ustalania interesariuszy brane są także pod uwagę ich istotność i stopień interakcji w ramach konkretnych czynności testowych. Przydatną metodą ustalania interesariuszy jest utworzenie dwuwymiarowej macierzy, w której jeden wymiar stanowią interesariusze, a drugi czynności testowe.

Przykładowe produkty pracy

1.      Plan zaangażowania interesariuszy

SP 4.4      Zidentyfikowanie ryzyk projektu testowego

Ryzyka projektu testowego powiązane z testowaniem są identyfikowane, analizowane

i dokumentowane.

Przykładowe produkty pracy

1      Zidentyfikowane ryzyka projektu testowego

2      Lista ryzyk projektu testowego z określonymi priorytetami

3.      Plany łagodzenia ryzyka projektu testowego

Podpraktyki

1      Zidentyfikowanie ryzyk projektu testowego

Przykładowe techniki identyfikowania ryzyk projektowych:

•      Burza mózgów

•      Wywiady z ekspertami

•      Listy kontrolne

2.      Analiza zidentyfikowanych ryzyk projektu testowego pod kątem prawdopodobieństwa

i wpływu

3.      Określenie priorytetów przeanalizowanych ryzyk projektu testowego

4.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności i priorytetów udokumentowanych ryzyk projektu testowego

5.      Zdefiniowanie sytuacji awaryjnych i działań służących łagodzeniu ryzyka dla ryzyk projektu testowego (o wysokim priorytecie)

6.      Aktualizacja ryzyk projektu testowego zgodnie z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji ryzyk projektu testowego:

•      Zidentyfikowanie nowych ryzyk projektu testowego

•      Zmiana prawdopodobieństwa (wystąpienia) ryzyk projektu testowego

•      Utrata aktualności ryzyk projektu testowego

•      Istotna zmiana warunków testowania

SP 4.5       Ustanowienie planu testów

Tworzony i utrzymywany jest plan testów stanowiący podstawę do zarządzania testowaniem

i komunikacją z interesariuszami.

Wyniki zastosowania poprzednich praktyk są dokumentowane w ogólnym planie testów, wiążącym w logiczny sposób wszystkie informacje.

Przykładowe produkty pracy

1. Plan testów

Przykładowe elementy planu testów [wg ISO 29119-3]:

•      Ogólne wprowadzenie włączając w to kontekst testowania

•      Niezgodności ze strategią testów i ich uzasadnienie

•      Ryzyka produktowe

•      Elementy podlegające testowaniu (z określeniem priorytetu) i niepodlegające testowaniu

•      Funkcje podlegające testowaniu (z określeniem priorytetu) i niepodlegające testowaniu

•      Założenia i ograniczenia

•      Podejście do testów (np. techniki projektowania testów)

•      Podejście do testowania potwierdzającego (retestowania) i testowania regresji

•      Kryteria wejścia i wyjścia

•      Kryteria zawieszenia i wznowienia

•      Kamienie milowe związane z testowaniem i produkty pracy (rezultaty)

•      Cykl życia testów i zadania testowe

•      Potrzeby i wymagania dotyczące środowisk i danych testowych (w tym środowiska biurowego)

•      Potrzeby związane z obsadą kadrową i szkoleniami (włączając w to role

i odpowiedzialności)

•      Udział interesariuszy

•      Raportowanie i komunikacja

•      Oszacowania dotyczące testów

•      Harmonogram testów

•      Ryzyka projektu testowego i sytuacje awaryjne

Więcej informacji na temat potrzeb i wymagań dotyczących środowiska można znaleźć

w opisie obszaru procesowego Środowisko testowe.

SG 5       Uzyskanie zobowiązań dotyczących realizacji planu testów

Określane są i utrzymywane zobowiązania dotyczące realizacji planu testów.

SP 5.1       Przegląd planu testów

Przegląd planu testów (oraz ewentualnie innych planów, które mają wpływ na testowanie)

w celu uzyskania zobowiązań dotyczących testowania i zrozumienia ich zakresu.

Przykładowe produkty pracy

1.      Zapis przeglądu planu testów

Podpraktyki

1.      Zorganizowanie przeglądów z udziałem interesariuszy, ułatwiających im zapoznanie się ze zobowiązaniami dotyczącymi testowania.

SP 5.2       Uzgodnienie poziomów pracy i zasobów

Korekta planu testów w celu uzgodnienia dostępności zasobów z oszacowaniami.

Przykładowe produkty pracy

1.      Zaktualizowane podejście do testów i odpowiednie parametry oszacowań

2.      Renegocjowane budżety projektu testowego

3.      Zaktualizowane harmonogramy testów

4.      Zaktualizowana lista ryzyk produktowych

5.      Renegocjowane umowy z interesariuszami

Podpraktyki

1.      Omówienie z interesariuszami różnic między oszacowaniami a dostępnością zasobów

2.      Uzgodnienie ewentualnych różnic między oszacowaniami a dostępnością zasobów

Należy zwrócić uwagę, że uzgodnienie odbywa się zwykle poprzez zmniejszenie lub czasowe ograniczenie wymagań dotyczących wydajności technicznej, wynegocjowanie dodatkowych zasobów, wskazanie sposobów zwiększania produktywności, zmianę zakresu projektu (np. pominięcie niektórych funkcji), outsourcing, korektę zbioru kwalifikacji personelu lub aktualizację harmonogramu.

SP 5.3       Uzyskanie zobowiązań dotyczących realizacji planu testów

Uzyskanie zobowiązań od odpowiednich interesariuszy odpowiedzialnych za wykonanie

i wspieranie realizacji planu testów.

Przykładowe produkty pracy

1.      Udokumentowane żądania dotyczące zobowiązań

2.      Udokumentowane zobowiązania

Podpraktyki

1.      Zidentyfikowanie niezbędnego wsparcia i wynegocjowanie zobowiązań dotyczących tego wsparcia z odpowiednimi interesariuszami

Struktura podziału pracy może posłużyć jako lista kontrolna. Można dzięki niej sprawdzić, czy uzyskano zobowiązania dla wszystkich zadań. W planie komunikacji z interesariuszami powinny zostać zidentyfikowane wszystkie strony, od których należy uzyskać zobowiązania.

2.      Udokumentowanie wszystkich zobowiązań organizacyjnych (pełnych i tymczasowych)

3.      Przegląd zobowiązań wewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

4.      Przegląd zobowiązań zewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Planowanie testów.

Opracowanie

Polityka planowania testów zwykle zawiera następujące ustalenia:

•      W każdym projekcie zostanie zdefiniowany plan testów zawierający podejście do testów oraz powiązane informacje o pracochłonności testów i oszacowaniach

•      Podejście do testów przyjęte w każdym projekcie zostanie opracowane na podstawie strategii testów

•      Plany testów zostaną opracowane z wykorzystaniem standardowego procesu i szablonu

•      Określone zostaną standardowe narzędzia, które będą używane podczas planowania testów

•      Jako podstawa działań związanych z planowaniem testów zostaną wykorzystane wymagania

•      Zobowiązania dotyczące testowania będą negocjowane z osobami odpowiedzialnymi za zarządzanie kadrami, zarządzanie biznesowe i zarządzanie projektami

•      Ewentualny udział innych grup w czynnościach testowych musi zostać z takimi grupami jawnie uzgodniony

•      Kierownictwo dokona przeglądu wszystkich zobowiązań dotyczących testowania podjętych wobec grup zewnętrznych

•      Plan testów będzie podlegać zarządzaniu i kontroli

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Planowanie testów.

Opracowanie

Zwykle plan realizacji procesu planowania testów jest uwzględniany w planie projektu, co zostało opisane w obszarze procesowym CMMI o nazwie Planowanie projektu (Project Planning).

Istnieje udokumentowane i zatwierdzone przedsięwzięcie testowe. Obejmuje ono zwykle zagadnienia i oczekiwania dotyczące celów, kryteriów wyjścia, elementów i funkcji podlegających i niepodlegających testowaniu, rodzaju wykonywanych testów, przestrzeganych standardów, kosztów, harmonogramu i ograniczeń dotyczących zasobów.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Planowanie testów, wytworzenia produktów pracy związanych z testowaniem oraz realizacji usług związanych

z procesem.

Opracowanie

•      Osoby odpowiedzialne za zarządzanie testami dysponują odpowiednim czasem na wykonanie czynności związanych z planowaniem testów

•      Dostępne są doświadczone osoby dysponujące wiedzą specjalistyczną z dziedziny aplikacji oraz osoby dysponujące wiedzą w zakresie procesu wytwarzania oprogramowania; osoby te wspierają tworzenie planu testów

•      Dostępne są narzędzia wspierające proces planowania testów

Przykładowe narzędzia:

•      Narzędzia do planowania projektu i tworzenia harmonogramów

•      Narzędzia do szacowania

•      Narzędzia do oceny ryzyka

•      Narzędzia do zarządzania testami

•      Narzędzia do zarządzania konfiguracją

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Planowanie testów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Planowanie testów.

Opracowanie

Zwykle za negocjowanie zobowiązań i opracowanie planu testów odpowiedzialny jest kierownik testów. Kierownik testów koordynuje proces planowania testów w projekcie (osobiście lub po przekazaniu uprawnień).

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Planowanie testów zgodnie z potrzebami.

Opracowanie

Osoby odpowiedzialne za zarządzanie testami oraz inne osoby lub grupy uczestniczące

w planowaniu testów są szkolone w tym zakresie, jak również w zakresie powiązanych procedur i technik.

Przykładowe tematy szkoleń:

•      Zasady planowania

•      Strategia testów

•      Proces i techniki oceny ryzyka produktowego i projektowego

•      Definiowanie podejścia do testów

•      Szablony planu testów i standardy

•      Organizacja testowa

•      Oszacowania dotyczące testów i tworzenie harmonogramu testów

•      Wprowadzenie do technik projektowania testów

•      Pomocnicze narzędzia do planowania testów

•      Planowanie awaryjne

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Planowanie testów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Struktura podziału pracy

•      Dane związane z oszacowaniami dotyczącymi testów

•      Dane związane z oceną ryzyka produktowego

•      Raport z przeglądu planu testów

•      Plan testów

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Planowanie testów zgodnie z planem.

Opracowanie

Wybór odpowiednich interesariuszy spośród klientów, użytkowników końcowych, programistów, producentów, testerów, dostawców, sprzedawców, specjalistów ds. utrzymania i serwisu oraz przedstawicieli innych grup, których dotyczy lub może dotyczyć dany produkt lub proces testowy.

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Wybór produktu i modułów produktu podlegających testowaniu

•      Udział w ocenie ryzyka produktowego polegający na zidentyfikowaniu poziomu i rodzaju ryzyka dla produktu i modułów produktu podlegających testowaniu

•      Przekazywanie informacji na potrzeby oszacowań dotyczących testowania

•      Przegląd ryzyk projektu testowego i rozwiązywanie problemów

•      Bezpośrednie udostępnienie zasobów testowych zgodnie z potrzebami

•      Przegląd i zatwierdzenie planu testów

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Planowanie testów (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu planowania testów:

•      Liczba wersji planu testów

•      Porównanie rzeczywistego czasu realizacji i pracochłonności z czasem realizacji

i pracochłonnością określonymi w planie testów

•      Liczba elementów testowych, w przypadku których w poszczególnych wersjach zmieniono poziom ryzyka

•      Rozbieżności dotyczące kosztów, harmonogramu i pracochłonności w poszczególnych wersjach planu

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Planowanie testów oraz wybranych produktów pracy

z opisem procesu, standardami i procedurami, a także eliminowanie wszelkich niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Zgodność ze strategią testów

•      Zgodność ze standardami (procedurami i szablonami)

•      Jakość planu testów

•      Zdefiniowane podejście do testów

•      Proces oceny ryzyka

•      Proces szacowania testów

•      Działania wymagające przeglądu i zobowiązań dotyczących testowania

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Planowanie testów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

Ma zastosowanie wyłącznie na poziomie TMMi 3.

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Planowanie testów

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Planowanie testów, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Odsetek planów testów ustanowionych zgodnie z procedurą i szablonem

•      Odsetek planów testów z udokumentowanymi wynikami analizy ryzyka produktowego

i podejściem do testów

•      Odsetek planów testów poddanych przeglądowi formalnemu i zatwierdzonych przez kierownictwo

•      Pracochłonność planowania testów

•      Dokładność oszacowań dotyczących testów.

PA 2.3       Monitorowanie i kontrola testów

Cel

Celem obszaru procesowego Monitorowanie i kontrola testów jest udostępnienie informacji o postępie testowania i o jakości produktu, tak aby możliwe było podjęcie odpowiednich działań naprawczych w sytuacji, gdy występuje znaczne odchylenie postępu testowania od planu lub znaczna niezgodność jakości produktu z oczekiwaniami.

Uwagi wstępne

Należy monitorować i kontrolować zarówno postęp testowania, jak i jakość produktów. Postęp testowania monitoruje się poprzez porównanie statusu rzeczywistych produktów (pracy) związanych z testowaniem, zadań (w tym ich atrybutów), pracochłonności, kosztów

i harmonogramu z założeniami określonymi w planie testów. Jakość produktów monitoruje się za pomocą wskaźników takich jak liczba złagodzonych ryzyk, liczba znalezionych defektów, liczba otwartych defektów i status spełnienia kryteriów wyjścia testów.

Monitorowanie obejmuje gromadzenie wymaganych danych (surowych), np. pochodzących z dziennika testów i raportów o incydentach testowych, a także przeglądanie danych surowych pod kątem ich poprawności i obliczanie zdefiniowanych miar postępu testów i jakości produktów. Okresowo i po wystąpieniu określonych zdarzeń powinny powstawać sumaryczne raporty z testów umożliwiające wypracowanie wspólnego obrazu postępu testowania i jakości produktów. Ponieważ „testowanie to mierzenie jakości produktu” [Hetzel], praktyki związane z informowaniem o jakości produktów są podstawowym warunkiem skutecznej realizacji tego obszaru procesowego.

Jeśli postęp testowania odbiega od planu lub jakość produktu różni się od oczekiwań, należy podjąć odpowiednie działania naprawcze. Działania te mogą wiązać się

z koniecznością ponownego planowania, w tym także z aktualizacją pierwotnego planu lub wykonaniem dodatkowych działań ograniczających na podstawie bieżącej wersji planu. Działania naprawcze, które mają wpływ na pierwotny zatwierdzony plan, powinny zostać uzgodnione przez interesariuszy.

Kluczowym elementem monitorowania i kontroli testów jest zarządzanie ryzykiem związanym z projektem testowym. Ma ono na celu zidentyfikowanie najważniejszych problemów, które utrudniają realizację planu testów, oraz ich możliwie najszybsze rozwiązanie. W trakcie zarządzania ryzykiem istotne jest również zidentyfikowanie problemów, za które nie jest odpowiedzialny zespół testowy. Na przykład zmniejszenie budżetu przez przedsiębiorstwo, opóźnienie w dostarczaniu produktów pracy programistów lub zmiany/dodawanie funkcjonalności mogą w istotny sposób wpłynąć na przebieg procesu testowego. Dzięki wcześniejszemu udokumentowaniu ryzyk projektu testowego w planie testów możliwe jest monitorowanie i kontrolowanie tych ryzyk oraz inicjowanie działań naprawczych zgodnie z potrzebami.

Zakres

Obszar procesowy Monitorowanie i kontrola testów obejmuje monitorowanie postępu testów i jakości produktów w odniesieniu do udokumentowanych oszacowań, zobowiązań, planów i oczekiwań, informowanie interesariuszy o postępie testów i jakości produktów, stosowanie środków kontroli (np. podejmowanie działań naprawczych, jeśli są konieczne) oraz zarządzanie działaniami naprawczymi do momentu zamknięcia problemu.

Podsumowanie celów i praktyk szczegółowych

SG 1       Monitorowanie postępu testowania w odniesieniu do planu

SP 1.1       Monitorowanie parametrów planowania testów

SP 1.2       Monitorowanie udostępnianych i używanych zasobów środowiska testowego

SP 1.3      Monitorowanie zobowiązań dotyczących testowania

SP 1.4       Monitorowanie ryzyk projektu testowego

SP 1.5      Monitorowanie zaangażowania interesariuszy

SP 1.6       Przeprowadzenie przeglądów postępu testów

SP 1.7       Przeprowadzenie przeglądów kamieni milowych związanych

z postępem testów

SG 2       Monitorowanie jakości produktów w odniesieniu do planu i oczekiwań

SP 2.1      Sprawdzenie kryteriów wejścia

SP 2.2      Monitorowanie defektów

SP 2.3      Monitorowanie ryzyk produktowych

SP 2.4      Monitorowanie kryteriów wyjścia

SP 2.5       Monitorowanie kryteriów zawieszenia i wznowienia

SP 2.6       Przeprowadzenie przeglądów jakości produktów

SP 2.7      Przeprowadzenie przeglądów kamieni milowych      związanych

z jakością produktów

SG 3      Zarządzanie działaniami naprawczymi do zamknięcia problemu

SP 3.1      Analizowanie problemów

SP 3.2      Podejmowanie działań naprawczych

SP 3.3      Zarządzanie działaniami naprawczymi

Praktyki szczegółowe dla poszczególnych celów

SG 1       Monitorowanie postępu testowania w odniesieniu do planu

Rzeczywisty postęp i wydajność testów są monitorowane i porównywane z wartościami określonymi w planie testów.

SP 1.1       Monitorowanie parametrów planowania testów

Monitorowanie rzeczywistych wartości parametrów planowania testów i porównywanie ich

z planem testów.

Przykładowe produkty pracy

1.      Rejestr wydajności testów

2.      Rejestr znacznych odstępstw od planu

Podpraktyki

1.      Monitorowanie postępu testowania w odniesieniu do harmonogramu testów

Przykłady typowych działań w ramach monitorowania postępu:

•      Okresowy pomiar rzeczywistej realizacji zadań testowych oraz produktów (pracy)

i kamieni milowych związanych z testowaniem

•      Porównywanie rzeczywistej realizacji zadań testowych oraz produktów (pracy) i kamieni milowych związanych z testowaniem z harmonogramem testów udokumentowanym

w planie testów

•      Identyfikowanie znacznych odstępstw od oszacowań dotyczących harmonogramu testów udokumentowanych w planie testów

2.      Monitorowanie kosztów testowania i dotychczasowej pracochłonności testów

Przykłady typowych działań w ramach monitorowania kosztów i pracochłonności:

•      Okresowe mierzenie rzeczywistych kosztów testowania, dotychczasowej pracochłonności i liczby przypisanych pracowników

•      Porównywanie rzeczywistych kosztów testowania, pracochłonności i obsady kadrowej

z oszacowaniami udokumentowanymi w planie testów

•      Identyfikowanie znacznych odstępstw od oszacowań kosztów testowania, pracochłonności i obsady kadrowej udokumentowanych w planie testów

3.      Monitorowanie atrybutów produktów pracy związanych z testami i zadań testowych

Informacje na temat atrybutów produktów pracy związanych z testowaniem i zadań testowych można znaleźć w opisie praktyki SP 3.3 Określenie oszacowań pracochłonności i kosztów testowania w obszarze procesowym Planowanie testów.

Przykłady typowych działań w ramach monitorowania atrybutów produktów pracy związanych z testowaniem i zadań testowych:

•      Okresowy pomiar rzeczywistych wartości atrybutów produktów pracy związanych

z testowaniem i zadań testowych, np. wielkości lub złożoności

•      Porównywanie rzeczywistych wartości atrybutów produktów pracy związanych

z testowaniem i zadań testowych z oszacowaniami udokumentowanymi w planie testów

•      Identyfikowanie znacznych odstępstw od oszacowań udokumentowanych w planie testów

4.      Monitorowanie wiedzy i umiejętności testerów

Przykłady typowych działań w ramach monitorowania wiedzy i umiejętności:

•      Okresowy pomiar pozyskiwania wiedzy i umiejętności przez personel testowy

•      Porównywanie rzeczywiście odbytych szkoleń ze szkoleniami udokumentowanymi

w planie testów

5.       Udokumentowanie znacznych odstępstw wartości parametrów planowania testów.

SP 1.2       Monitorowanie udostępnianych i używanych zasobów środowiska testowego

Monitorowanie udostępnianych i używanych zasobów środowiska testowego w odniesieniu do zasobów zdefiniowanych w planie.

Przykładowe produkty pracy

1.      Rejestr udostępnianych i używanych zasobów środowiska testowego

2.      Rejestr znacznych odstępstw od planu

Podpraktyki

1.      Monitorowanie udostępnianych zasobów środowiska testowego w odniesieniu do planu

2.      Monitorowanie rzeczywistego wykorzystania udostępnianych zasobów środowiska testowego w odniesieniu do planu

3.      Identyfikowanie i dokumentowanie znacznych odstępstw od oszacowań udokumentowanych w planie

SP 1.3       Monitorowanie zobowiązań dotyczących testowania

Monitorowanie uzyskanych zobowiązań dotyczących testowania w odniesieniu do zobowiązań określonych w planie testów.

Przykładowe produkty pracy

1.      Zapis przeglądów zobowiązań

Podpraktyki

1.      Regularne przeglądy zobowiązań (wewnętrznych i zewnętrznych)

2.      Zidentyfikowanie zobowiązań, które nie zostały wypełnione lub w przypadku których istnieje znaczne ryzyko ich niewypełnienia

3.      Udokumentowanie wyników przeglądów zobowiązań

SP 1.4       Monitorowanie ryzyk projektu testowego

Monitorowanie ryzyk projektu testowego w odniesieniu do planu testów.

Przykładowe produkty pracy

1      Zaktualizowana lista ryzyk projektu testowego

2.      Rejestr monitorowania ryzyka projektowego

Podpraktyki

1.      Okresowe przeglądy ryzyk projektu testowego w kontekście bieżącego statusu

i okoliczności

2.      Aktualizowanie dokumentacji ryzyk projektu testowego w miarę dostępności nowych informacji, w celu uwzględnienia ewentualnych zmian

3.      Informowanie odpowiednich interesariuszy o statusie ryzyka związanego z projektem testowym

SP 1.5       Monitorowanie zaangażowania interesariuszy

Monitorowanie zaangażowania interesariuszy w odniesieniu do oczekiwań określonych

w planie testów.

Po zidentyfikowaniu interesariuszy i określeniu w planie testów stopnia ich zaangażowania

w testowanie należy monitorować to zaangażowanie, tak aby zachodziły właściwe interakcje.

Przykładowe produkty pracy

1. Rejestr zaangażowania interesariuszy

Podpraktyki

1.      Okresowe przeglądy statusu zaangażowania interesariuszy

2.      Zidentyfikowanie i udokumentowanie istotnych problemów i ich wpływu

3      Udokumentowanie wyników przeglądów statusu zaangażowania interesariuszy

SP 1.6       Przeprowadzenie przeglądów postępu testów

Okresowe przeglądy postępu testów, wydajności i problemów.

Przeglądy postępu testów są przeprowadzane w celu przekazania bieżących informacji interesariuszom. Często odbywają się przeglądy zarówno wewnętrzne, z udziałem członków zespołu testowego, jak i zewnętrzne, z udziałem interesariuszy spoza zespołu testowego. Przeglądy mają zwykle charakter nieformalny i odbywają się regularnie, np. raz w tygodniu, raz na dwa tygodnie lub raz na miesiąc.

Przykładowe produkty pracy

1.      Raport o postępie testów

2.      Udokumentowane wyniki przeglądu postępu testów, np. protokoły ze spotkań dotyczących postępu prac

Podpraktyki

1.      Gromadzenie i analiza wskaźników związanych z monitorowaniem postępu testów

2.      Regularne informowanie interesariuszy o postępie testów i wydajności

Przykładowi interesariusze:

•      Osoby odpowiedzialne za zarządzanie projektem

•      Osoby odpowiedzialne za zarządzanie biznesowe

•      Członkowie zespołu testowego

3.      Regularne organizowanie spotkań z interesariuszami dotyczących przeglądu postępu testów

4.      Identyfikowanie, dokumentowanie i omawianie istotnych problemów i odstępstw od planu testów

5.      Dokumentowanie żądań zmian produktów pracy związanych z testowaniem

i dokumentowanie zidentyfikowanych ważnych problemów dotyczących postępu

i wydajności testowania

6.      Dokumentowanie wyników przeglądów, np. podjętych decyzji i zdefiniowanych działań naprawczych

SP 1.7       Przeprowadzenie przeglądów kamieni milowych związanych z postępem testowania

Przegląd osiągniętych rezultatów i postępu testowania w wybranych kamieniach milowych.

Planowanie przeglądów kamieni milowych związanych z postępem testowania odbywa się

w ramach procesu planowania testów. Przeglądy takie są zwykle przeglądami formalnymi.

Przykładowe produkty pracy

1.      Raport dotyczący kamieni milowych związanych z testowaniem

2.      Udokumentowane wyniki przeglądu kamieni milowych, np. protokoły ze spotkań dotyczących przeglądu

Podpraktyki

1.      Przeprowadzenie przeglądów postępu testów z udziałem odpowiednich interesariuszy

w istotnych punktach realizacji harmonogramu testów, np. po zakończeniu wybranych etapów

2.      Informowanie interesariuszy o osiągniętych rezultatach, postępie testów i wydajności

3.      Przegląd zobowiązań, planu, statusu i ryzyka projektowego związanego z testowaniem

4.      Przegląd zasobów środowiska testowego

5.      Zidentyfikowanie, udokumentowanie i omówienie istotnych problemów związanych

z postępem testowania i ich wpływu na testowanie

6.      Udokumentowanie wyników przeglądów, działań do wykonania i decyzji

7.      Aktualizacja planu testów w celu uwzględnienia osiągniętych rezultatów i bieżącego statusu prac

SG 2       Monitorowanie jakości produktów w odniesieniu do planu i oczekiwań

Rzeczywista jakość produktów jest monitorowana i porównywana ze wskaźnikami jakości zdefiniowanymi w planie testów oraz oczekiwaniami dotyczącymi jakości, np. przedstawionymi przez klienta/użytkownika.

SP 2.1       Sprawdzenie kryteriów wejścia

Na początku fazy wykonania testów sprawdzane jest spełnienie kryteriów wejścia określonych w planie testów.

Przykładowe produkty pracy

1.      Zapis sprawdzenia kryteriów wejścia

Podpraktyki

1.      Sprawdzenie statusu i spełnienia kryteriów określonych w planie testów

2.      Zidentyfikowanie i udokumentowanie znacznych niezgodności z kryteriami wejścia oraz zainicjowanie działań naprawczych

SP 2.2       Monitorowanie defektów

Monitorowanie miar defektów wykrytych podczas testowania i ich porównywanie z wartościami oczekiwanymi.

Przykładowe produkty pracy

1.      Rejestr monitorowania defektów

Podpraktyki

1.      Monitorowanie miar wykrytych defektów i statusu oraz ich porównywanie

z oczekiwaniami

Przykłady użytecznych miar dotyczących defektów [Burnstein]:

•      Łączna liczba nieusuniętych defektów (w module, podsystemie lub systemie) dla poszczególnych zdefiniowanych priorytetów

•      Łączna liczba defektów wykrytych podczas ostatniego przebiegu testów dla poszczególnych zdefiniowanych priorytetów

•      Liczba defektów usuniętych/nieusuniętych (dla wszystkich poziomów testowania)

•      Liczba wykrytych defektów dla poszczególnych typów

•      Liczba defektów powodujących awarie o poziomie ważności większym niż X

•      Liczba defektów na tysiąc linii kodu / KLOC (ang. Kilo Lines of Code) („liczba incydentów”)

•      Porównanie rzeczywistej i szacowanej liczby defektów (na podstawie danych historycznych)

2.      Zidentyfikowanie i udokumentowanie znacznych odstępstw od oczekiwanych wartości miar dotyczących wykrytych defektów

SP 2.3       Monitorowanie ryzyk produktowych

Monitorowanie ryzyk produktowych w odniesieniu do planu testów.

Przykładowe produkty pracy

1.      Zaktualizowana lista ryzyk produktowych związanych z testowaniem

2.      Rejestr monitorowania ryzyka produktowego

Podpraktyki

1.      Okresowe przeglądy ryzyk produktowych w kontekście bieżącego statusu i okoliczności (z udziałem wybranych interesariuszy)

2.      Monitorowanie zmian i uzupełnień w wymaganiach w celu zidentyfikowania nowych lub zmienionych ryzyk produktowych

3.      Aktualizowanie dokumentacji ryzyk produktowych w miarę dostępności dodatkowych informacji w celu uwzględnienia zmian prawdopodobieństwa, wpływu i/lub priorytetu

4.      Monitorowanie (liczby) złagodzonych ryzyk produktowych i porównanie z założeniami dotyczącymi łagodzenia ryzyka określonymi w planie

5.       Informowanie odpowiednich interesariuszy o statusie ryzyka produktowego

SP 2.4       Monitorowanie kryteriów wyjścia

Monitorowanie statusu kryteriów wyjścia w odniesieniu do planu testów.

Przykładowe produkty pracy

1.      Rejestr monitorowania kryteriów wyjścia

Podpraktyki

1.      Monitorowanie kryteriów wyjścia związanych z procesem testowym, np. porównanie pokrycia testowego z wartościami w planie

2.      Monitorowanie kryteriów wyjścia związanych z jakością produktów w odniesieniu do planu

3.      Identyfikowanie i dokumentowanie znacznych odstępstw od planu dotyczących statusu kryteriów wyjścia

SP 2.5       Monitorowanie kryteriów zawieszenia i wznowienia

Monitorowanie statusu kryteriów zawieszenia i wznowienia w odniesieniu do planu testów.

Przykładowe produkty pracy

1.      Rejestr monitorowania kryteriów zawieszenia

2.      Rejestr monitorowania kryteriów wznowienia

Podpraktyki

1.      Monitorowanie kryteriów zawieszenia w odniesieniu do planu

2.      Zawieszanie testowania w przypadku spełnienia kryteriów zawieszenia oraz inicjowanie działań naprawczych

3.      Monitorowanie kryteriów wznowienia w odniesieniu do planu

4.      Wznawianie testowania po rozwiązaniu problemów z wykorzystaniem zdefiniowanych kryteriów wznowienia

SP 2.6       Przeprowadzenie przeglądów jakości produktów

Okresowe przeglądy jakości produktów.

Przeglądy jakości są przeprowadzane w celu przekazania bieżących informacji interesariuszom. Często odbywają się przeglądy zarówno wewnętrzne, z udziałem członków zespołu testowego, jak i zewnętrzne, z udziałem interesariuszy spoza zespołu testowego. Przeglądy mają zwykle charakter nieformalny i odbywają się regularnie, np. raz w tygodniu, raz na dwa tygodnie lub raz na miesiąc.

Przykładowe produkty pracy

1.      Raport dotyczący jakości produktów

2.      Udokumentowane wyniki przeglądu jakości produktów, np. protokoły ze spotkań dotyczących jakości produktów

Podpraktyki

1.      Gromadzenie i analiza wskaźników związanych z monitorowaniem jakości produktów

2.      Regularne informowanie interesariuszy o jakości produktów

Przykładowi interesariusze:

•      Osoby odpowiedzialne za zarządzanie projektem

•      Osoby odpowiedzialne za zarządzanie biznesowe

•      Członkowie zespołu testowego

3.      Regularne organizowanie spotkań z interesariuszami dotyczących przeglądu jakości produktów

4.      Identyfikowanie, dokumentowanie i omawianie istotnych problemów dotyczących jakości produktów oraz odstępstw od oczekiwań i planu testów

5.      Dokumentowanie wyników przeglądów, np. podjętych decyzji i zdefiniowanych działań naprawczych

SP 2.7       Przeprowadzenie przeglądów kamieni milowych związanych z jakością produktów

Przeglądy statusu jakości produktów w wybranych kamieniach milowych związanych

z testowaniem.

Planowanie przeglądów kamieni milowych związanych z jakością produktów odbywa się

w ramach procesu planowania testów. Przeglądy takie są zwykle przeglądami formalnymi.

Przykładowe produkty pracy

1.      Raport dotyczący kamieni milowych związanych z testowaniem

2.      Udokumentowane wyniki przeglądu kamieni milowych, np. protokoły ze spotkań dotyczących przeglądu

Podpraktyki

1.      Przeprowadzenie przeglądów jakości produktów z udziałem odpowiednich interesariuszy w istotnych punktach realizacji harmonogramu testów, np. po zakończeniu wybranych etapów

2.      Poinformowanie interesariuszy o statusie jakości produktów za pomocą formalnego raportu dotyczącego jakości produktów

Przykładowe elementy raportu dotyczącego jakości produktów [wg ISO 29119-3]:

•      Streszczenie dla kierownictwa (włączając w to okres raportowania)

•      Kompleksowa ocena

•      Podsumowanie wyników i działań

•      Postęp w odniesieniu do planu testów

•      Czynniki blokujące postęp

•      Miary testów (np. w odniesieniu do kryteriów wyjścia)

•      Nowe i zmienione ryzyka

•      Planowany okres testowania

3.      Przegląd statusu defektów, ryzyk produktowych i kryteriów wyjścia

4.      Zidentyfikowanie i udokumentowanie istotnych problemów dotyczących jakości produktów oraz ich wpływu

5.      Udokumentowanie wyników przeglądów, działań do wykonania i decyzji

6.      Aktualizacja planu testów w celu uwzględnienia osiągniętych rezultatów i bieżącego statusu prac

SG 3       Zarządzanie działaniami naprawczymi do zamknięcia problemu

Zarządzanie działaniami naprawczymi do zamknięcia problemu odbywa się wówczas, gdy postęp testów lub jakość produktów znacznie odbiega od planu testów lub oczekiwań.

SP 3.1       Analizowanie problemów

Gromadzenie informacji i analizowanie problemów oraz określanie działań naprawczych niezbędnych do ich rozwiązania.

Przykładowe produkty pracy

1.       Lista problemów wymagających podjęcia działań naprawczych

Podpraktyki

1.       Gromadzenie informacji o problemach do analizy

Przykładowe problemy, które należy uwzględnić:

•      Znaczne odstępstwa rzeczywistych wartości parametrów planowania testów od oszacowań podanych w planie testów

•      Zobowiązania, które nie zostały wypełnione

•      Istotne zmiany dotyczące statusu ryzyka związanego z projektem testowym, np. niebezpieczeństwo opóźnionego dostarczenia podstawy testów i/lub przedmiotu testów albo ich niskiej jakości

•      Problemy związane z reprezentacją lub zaangażowaniem interesariuszy

•      Znaczne odstępstwa postępów implementacji środowiska testowego od planu

•      Liczba, ważność i priorytety wykrytych defektów

•      Status spełnienia kryteriów wyjścia

•      Istotne zmiany dotyczące ryzyka produktowego

2.      Analiza problemów w celu określenia potrzeby podjęcia działań naprawczych

Uwaga: działania naprawcze są niezbędne wówczas, gdy pozostawiony bez rozwiązania problem może uniemożliwić testowanie albo realizację celów projektu.

SP 3.2       Podejmowanie działań naprawczych

Podjęcie działań naprawczych odpowiednich dla zidentyfikowanych problemów.

Przykładowe produkty pracy

1.      Plan działań naprawczych

Podpraktyki

1.      Określenie i udokumentowanie odpowiednich działań niezbędnych do rozwiązania zidentyfikowanych problemów

Przykładowe działania:

•      Renegocjacja zobowiązań

•      Dodanie zasobów

•      Zmiana podejścia do testów

•      Weryfikacja kryteriów wyjścia

•      Przesunięcie terminu wydania wersji

•      Zmiana zakresu projektu, np. ograniczenie dostarczanej funkcjonalności

Należy zaznaczyć, że niektóre z powyższych potencjalnych działań wiążą się z aktualizacją planu testów.

2.      Przegląd z udziałem odpowiednich interesariuszy i uzyskanie zgody na podjęcie działań

3.      Renegocjacja zobowiązań z interesariuszami (wewnętrznymi i zewnętrznymi)

SP 3.3       Zarządzanie działaniami naprawczymi

Zarządzanie działaniami naprawczymi do zamknięcia problemu.

Przykładowe produkty pracy

1.       Wyniki działań naprawczych

Podpraktyki

1.      Monitorowanie realizacji działań naprawczych

2.      Analiza wyników działań naprawczych w celu określenia efektywności tych działań

3.      Informowanie o postępie realizacji działań naprawczych

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Monitorowanie i kontrola testów.

Opracowanie

Polityka monitorowania i kontroli testów zwykle zawiera następujące ustalenia:

•      Podstawą monitorowania postępu testów jest udokumentowany plan testów

•      Monitorowanie odbywa się na podstawie zestawu wskaźników związanych

z testowaniem

•      Zadania w projekcie testowym, pracochłonność i koszy podlegają monitorowaniu przez cały czas trwania projektu

•      Na podstawie zidentyfikowanych ryzyk projektowych opracowywane są plany awaryjne

•      Kierownictwo i inni interesariusze są na bieżąco informowani o postępie testów

•      Kierownictwo i inni interesariusze są na bieżąco informowani o jakości produktów

•      Jeśli postęp testów znacznie odbiega od planu lub jakość produktów znacznie różni się od oczekiwań, podejmowane są działania naprawcze, które podlegają zarządzaniu do momentu rozwiązania problemu

•      Duże zmiany w planie testów podlegają przeglądowi ze strony kierownictwa i innych interesariuszy

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Monitorowanie i kontrola testów.

Opracowanie

Zwykle plan realizacji procesu monitorowania i kontroli testów jest uwzględniany w planie testów, co zostało opisane w obszarze procesowym TMMi o nazwie Planowanie testów.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Monitorowanie i kontrola testów, wytworzenia produktów pracy związanych z testowaniem oraz realizacji usług związanych z procesem.

Opracowanie

•      Dostępny jest plan testów, w odniesieniu do którego można monitorować i kontrolować testowanie

•      Osoby odpowiedzialne za zarządzanie testami dysponują odpowiednim czasem na wykonanie czynności związanych z monitorowaniem i kontrolą testów

•      Dostępne są narzędzia wspierające proces monitorowania i kontroli testów

Przykładowe narzędzia:

•      Narzędzia do zarządzania projektem i śledzenia postępu

•      Narzędzia do zarządzania ryzykiem

•      Narzędzia do zarządzania defektami

•      Narzędzia do zarządzania testami

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Monitorowanie i kontrola testów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Monitorowanie i kontrola testów.

Opracowanie

Zwykle za monitorowanie i kontrolę testów odpowiedzialny jest kierownik testów. Kierownik testów koordynuje proces testowana w projekcie (osobiście lub po przekazaniu uprawnień).

Przykładowe obowiązki związane z monitorowaniem i kontrolą testów, które należy przydzielić uczestnikom projektu:

•      Monitorowanie i kontrola kosztów, pracochłonności i harmonogramu testowania

•      Monitorowanie i kontrola ryzyk projektu testowego

•      Monitorowanie i kontrola ryzyk produktowych i jakości produktów

•      Tworzenie raportów dotyczących postępu testów i jakości produktów

•      Inicjowanie działań naprawczych w sytuacji, gdy postęp testów znacznie odbiega od planu testów

•      Inicjowanie działań naprawczych w sytuacji, gdy jakość produktów znacznie odbiega od oczekiwań

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Monitorowanie

i kontrola testów zgodnie z potrzebami.

Opracowanie

Osoby odpowiedzialne za zarządzanie testami oraz inne osoby lub grupy uczestniczące

w monitorowaniu i kontroli testów są szkolone w tym zakresie, jak również w zakresie powiązanych procedur i technik.

Przykładowe tematy szkoleń:

•      Podstawy zarządzania projektami

•      Zarządzanie testami

•      Śledzenie jakości produktów, pracochłonności, kosztów i harmonogramu

•      Zarządzanie ryzykiem

•      Raporty dotyczące testowania

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Monitorowanie i kontrola testów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Harmonogram testów i status realizacji

•      Dane i analiza pomiarów testów

•      Raporty dotyczące testów

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Monitorowanie

i kontrola testów zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Ocena wydajności testowania w porównaniu z planem testów

•      Przegląd zobowiązań i rozwiązywanie problemów

•      Przegląd ryzyk produktowych i ryzyk projektu testowego

•      Przegląd działań związanych z zarządzaniem danymi testowymi

•      Przegląd postępu testów i jakości produktów

•      Zarządzanie działaniami naprawczymi do zamknięcia problemu

Uwaga: ta ogólna praktyka dotyczy jedynie zaangażowania odpowiednich interesariuszy

w procesie monitorowania i kontroli testów.

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Monitorowanie i kontrola testów (porównywanie

z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych podczas monitorowania i kontrolowania procesu monitorowania

i kontroli testów:

•      Liczba otwartych i zamkniętych działań naprawczych

•      Liczba rodzajów wykonanych przeglądów koleżeńskich

•      Harmonogram przeglądów (zaplanowane i rzeczywiste terminy przeglądów oraz przesunięte terminy przeglądów)

•      Pracochłonność przeglądów (planowana i rzeczywista)

Uwaga: ta ogólna praktyka dotyczy jedynie monitorowania i kontrolowania działań związanych z monitorowaniem i kontrolą testów.

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Monitorowanie i kontrola testów oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Monitorowanie postępu testowania w odniesieniu do planu testów

•      Zarządzanie działaniami naprawczymi do zamknięcia problemu

•      Wydajność zarządzania ryzykiem związanym z projektem testowania

•      Zgodność ze standardami (procedurami i szablonami)

•      Raporty dotyczące testów i jakości

•      Przegląd wyników

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Monitorowanie i kontrola testów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

Ma zastosowanie wyłącznie na poziomie TMMi 3.

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Monitorowanie i kontrola testów.

GP 3.2      Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Monitorowanie i kontrola testów, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Odsetek projektów, w których używany jest szablon raportowania testów

•      Odsetek kamieni milowych związanych z testowaniem zaakceptowanych

z wykorzystaniem przeglądu formalnego

•      Odsetek działań naprawczych zamkniętych w ciągu X dni.

PA 2.4       Projektowanie i wykonywanie testów

Cel

Celem obszaru procesowego Projektowanie i wykonywanie testów jest zwiększenie skuteczności procesu testowego podczas projektowania i wykonywania testów dzięki określeniu specyfikacji projektu testów, użyciu technik projektowania testów, realizacji ustrukturyzowanego procesu wykonywania testów oraz zarządzaniu incydentami testowymi do ich zamknięcia.

Uwagi wstępne

Ustrukturyzowane testowanie oznacza, że stosowane są techniki projektowania testów, w miarę możliwości przy wsparciu narzędzi. Techniki projektowania testów służą do wyprowadzania i wyboru warunków testowych i projektowania przypadków testowych na podstawie wymagań i specyfikacji projektu. Warunki testowe i przypadki testowe są dokumentowane w specyfikacji testów. Przypadek testowy składa się z opisu wartości wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania. Na późniejszym etapie, gdy dostępne stają się dodatkowe informacje dotyczące implementacji, przypadki testowe są przekształcane w procedury testowe.

W procedurze testowej, nazywanej także skryptem testowym dla testów manualnych, ciąg konkretnych działań testowych i sprawdzeń jest zapisany w formie sekwencji działań do wykonania. Tworzone są konkretne dane testowe umożliwiające uruchamianie procedur testowych. Następnie z wykorzystaniem tych procedur wykonywane są testy.

Działania związane z projektowaniem i wykonywaniem testów odbywają się zgodnie

z podejściem do testów zdefiniowanym w planie testów. Wybór konkretnych technik projektowania testów (np. czarnoskrzynkowych, białoskrzynkowych lub opartych na doświadczeniu) jest zależny od poziomu i rodzaju ryzyka produktowego zidentyfikowanego

w trakcie planowania testów.

W fazie wykonywania testów wykrywane są incydenty i zapisywane są raporty

o incydentach. Incydenty rejestruje się za pomocą systemu zarządzanie incydentami,

a interesariusze są o nich informowani zgodnie z ustalonymi protokołami. Na potrzeby zarządzania incydentami ustanawiany jest podstawowy schemat klasyfikacji incydentów. Określana jest również procedura do obsługi cyklu życia incydentów obejmująca zarządzanie incydentami do ich zamknięcia.

Zakres

Obszar procesowy Projektowanie i wykonywanie testów wiąże się z fazą przygotowywania testów i obejmuje zastosowanie technik projektowania testów do wyprowadzania i wyboru warunków testowych i przypadków testowych. Umożliwia także utworzenie konkretnych danych testowych, wykonanie testów z użyciem udokumentowanych procedur testowych oraz zarządzanie incydentami.

Podsumowanie celów i praktyk szczegółowych

SG 1       Wykonanie analizy i projektowania testów z zastosowaniem technik projektowania testów

SP 1.1      Zidentyfikowanie warunków testowych i określenie ich priorytetów

SP 1.2      Zidentyfikowanie przypadków testowych i określenie ich priorytetów

SP 1.3       Zidentyfikowanie niezbędnych konkretnych danych testowych

SP 1.4      Utrzymywanie możliwości poziomego śledzenia powiązań

z wymaganiami

SG 2       Implementacja testów

SP 2.1       Opracowanie procedur testowych i określenie ich priorytetów

SP 2.2       Utworzenie konkretnych danych testowych

SP 2.3       Specyfikacja procedury testu wstępnego

SP 2.4       Opracowanie harmonogramu wykonywania testów

SG 3       Wykonanie testów

SP 3.1      Przeprowadzenie testu wstępnego

SP 3.2      Wykonanie przypadków testowych

SP 3.3      Raportowanie incydentów testowych

SP 3.4      Dokonanie wpisu w dzienniku testów

SG 4       Zarządzanie incydentami testowymi do ich zamknięcia

SP 4.1       Podjęcie decyzji dotyczących obsługi incydentów testowych w ramach Rady Kontroli Zmian

SP 4.2       Wykonanie odpowiednich działań w celu usunięcia problemów

SP 4.3      Śledzenie statusu incydentów testowych

Praktyki szczegółowe dla poszczególnych celów

SG 1       Wykonanie analizy i projektowania testów z zastosowaniem technik projektowania testów

Podczas analizy i projektowania testów podejście do testów jest przekształcane w konkretne warunki testowe i przypadki testowe z zastosowaniem technik projektowania testów.

SP 1.1       Zidentyfikowanie warunków testowych i określenie ich priorytetów

Następuje zidentyfikowanie warunków testowych i określenie priorytetów z wykorzystaniem technik projektowania testów, w oparciu o analizę elementów testowych określonych

w podstawie testów.

Przykładowe produkty pracy

1.      Rejestr problemów dotyczących podstawy testów

2.      Warunki testowe

3.      Specyfikacja projektu testów

Podpraktyki

1.      Analiza podstawy testów (np. wymagań, architektury, projektu, specyfikacji interfejsów

i podręcznika użytkownika)

2.      Omówienie problemów dotyczących podstawy testów z właścicielem dokumentu

3.      Wybór najbardziej odpowiednich technik projektowania testów zgodnych

z udokumentowanym podejściem do testów

Przykładowe czarnoskrzynkowe techniki projektowania testów:

•      Podział na klasy równoważności

•      Analiza wartości brzegowych

•      Tablice decyzyjne (tworzenie grafów przyczynowo-skutkowych)

•      Testowanie przejść pomiędzy stanami

Przykładowe białoskrzynkowe techniki projektowania testów:

•      Testowanie instrukcji

•      Testowanie decyzji (gałęzi)

•      Testowanie warunków

Oprócz technik czarnoskrzynkowych i białoskrzynkowych można zastosować techniki oparte na doświadczeniu, np. testowanie eksploracyjne. Wiąże się z tym dokumentowanie specyfikacji projektu testów za pomocą kart opisu testów.

Zwykle na danym poziomie testów wybiera się więcej niż jedną technikę projektowania testów w celu zróżnicowania intensywności testowania, np. liczby przypadków testowych,

w zależności od poziomu ryzyka wiążącego się z elementami testowymi. Oprócz poziomu ryzyka używanego do określania priorytetu testowania na wybór technik projektowania testów wpływają również inne czynniki, takie jak cykl tworzenia oprogramowania, jakość podstawy testów, umiejętności i wiedza testerów, wymagania wynikające z umów i przestrzegane standardy.

4.      Wyprowadzenie warunków testowych z podstawy testów z zastosowaniem technik projektowania testów

5.      Ustalenie priorytetów warunków testowych na podstawie zidentyfikowanych ryzyk produktowych

6.      Udokumentowanie warunków testowych w specyfikacji projektu testów (zgodnie ze standardem specyfikacji projektu testów)

Przykładowe elementy specyfikacji projektu testów [wg ISO 29119-3]:

•      Identyfikator specyfikacji projektu testów

•      Elementy i/lub funkcje podlegające testowaniu

•      Cel

•      Doprecyzowanie podejścia do testów

•      Warunki testowe

•      Priorytet

•      Śledzenie powiązań

7.      Przegląd specyfikacji projektu testów z udziałem interesariuszy

8.      Aktualizowanie specyfikacji projektu testów i warunków testowych zgodnie z potrzebami, np. w przypadku zmiany wymagań

SP 1.2       Zidentyfikowanie przypadków testowych i określenie ich priorytetów

Z wykorzystaniem technik projektowania testów identyfikowane są przypadki testowe

i określane są ich priorytety.

Przykładowe produkty pracy

1.      Przypadki testowe

2.      Specyfikacja przypadków testowych

Podpraktyki

1.      Wyprowadzenie przypadków testowych z warunków testowych z zastosowaniem technik projektowania testów. Przypadek testowy składa się z zestawu wartości wejściowych, wstępnych warunków wykonania, oczekiwanych rezultatów i końcowych warunków wykonania.

2.      Ustalenie priorytetów przypadków testowych na podstawie zidentyfikowanych ryzyk produktowych

3.      Udokumentowanie przypadków testowych w specyfikacji przypadków testowych (zgodnie ze standardem specyfikacji przypadków testowych)

Przykładowe elementy specyfikacji przypadków testowych [wg ISO 29119-3]:

•      Identyfikator specyfikacji przypadku testowego

Elementy pokrycia testowego

•      Cel

•      Priorytet

•      Warunki wstępne przypadku testowego (np. potrzeby środowiskowe)

•      Dane wejściowe przypadku testowego

•      Oczekiwane wyniki przypadku testowego

•      Zależności pomiędzy przypadkami

•      Śledzenie powiązań

4.      Przegląd specyfikacji przypadków testowych z udziałem interesariuszy

5.      Aktualizacja specyfikacji przypadków testowych zgodnie z potrzebami

SP 1.3       Zidentyfikowanie niezbędnych konkretnych danych testowych

Ustalane są konkretne dane testowe niezbędne do obsługi warunków testowych i wykonania przypadków testowych.

Przykładowe produkty pracy

1.      Specyfikacja danych testowych

Podpraktyki

1.      Identyfikowanie i specyfikowanie niezbędnych konkretnych danych testowych wymaganych do implementacji i wykonania przypadków testowych

2.      Udokumentowanie niezbędnych konkretnych danych testowych, np. w ramach specyfikacji przypadków testowych

SP 1.4       Utrzymywanie możliwości poziomego śledzenia powiązań pomiędzy wymaganiami

Ustalenie i utrzymywanie możliwości śledzenia powiązań między wymaganiami a warunkami testowymi.

Przykładowe produkty pracy

1.      Macierz śledzenia powiązań między wymaganiami a warunkami testowymi

Podpraktyki

1.      Utrzymywanie możliwości śledzenia powiązań z wymaganiami w celu udokumentowania źródeł warunków testowych

2.      Wygenerowanie macierzy śledzenia powiązań pomiędzy wymaganiami i warunkami testowymi

3.      Skonfigurowanie macierzy śledzenia powiązań pomiędzy wymaganiami w taki sposób, aby możliwe było monitorowanie pokrycia wymagań w trakcie wykonywania testów

SG 2       Implementacja testów

W trakcie implementacji testów opracowywane są procedury testowe (w tym związane

z testem wstępnym) oraz określane są ich priorytety. W tej fazie tworzy się dane testowe

i definiuje harmonogram wykonywania testów.

SP 2.1       Opracowanie procedur testowych i określenie ich priorytetów

Tworzone są procedury testowe i określane są ich priorytety.

Przykładowe produkty pracy

1.      Specyfikacja procedur testowych

2.      Skrypty testowe dla testów automatycznych

Podpraktyki

1.      Opracowanie procedur testowych poprzez połączenie przypadków testowych

w określonej kolejności i uwzględnienie innych informacji niezbędnych do wykonania testów

2.      Ustalenie priorytetów procedur testowych na podstawie zidentyfikowanych ryzyk produktowych

3.      Udokumentowanie procedur testowych w specyfikacji procedur testowych (zgodnie ze standardem specyfikacji procedur testowych)

Przykładowe elementy specyfikacji procedury testowej [wg ISO 29119-3]:

•      Identyfikator specyfikacji procedury testowej

•      Zestawy testowe

•      i) Unikalny identyfikator

•      ii) Cel

•      iii) Priorytet

•      iv) Treść (śledzenie powiązań)

•      Procedury testowe

•      i) Unikalny identyfikator

•      ii) Cel

•      iii) Priorytet

•      iv) Uruchomienie

•      v) Przypadki testowe do wykonania (śledzenie powiązań)

•      vi) Związek z innymi procedurami

•      vii) Zatrzymanie i zakończenie

4.      Przegląd specyfikacji procedur testowych z udziałem interesariuszy

5.      Aktualizacja specyfikacji procedur testowych zgodnie z potrzebami

6.      Opcjonalna automatyzacja procedur testowych i przekształcenie ich w skrypty testowe dla testów automatycznych

SP 2.2       Utworzenie konkretnych danych testowych

Tworzone są konkretne dane testowe zgodnie ze specyfikacją określoną w trakcie analizy

i projektowania testów.

Przykładowe produkty pracy

1.       Konkretne dane testowe

Podpraktyki

1.      Utworzenie konkretnych danych testowych wymaganych do przeprowadzenia testów zgodnie z procedurami testowymi

2.      Archiwizacja zestawu konkretnych danych testowych w celu ewentualnego odtworzenia sytuacji początkowej w przyszłości

Informacje na temat zarządzania utworzonymi danymi testowymi zawiera opis praktyki SP 3.2 Zarządzanie danymi testowymi z obszaru procesowego Środowisko testowe.

SP 2.3       Specyfikacja procedury testu wstępnego

Tworzona jest specyfikacja testu wstępnego. Test tego rodzaju, nazywany czasami testem potwierdzającym lub testem dymnym, umożliwia ustalenie na początku wykonywania testów, czy przedmiot testów jest gotowy do dalszego szczegółowego testowania.

Przykładowe produkty pracy

1.      Lista kontrolna testu wstępnego

2.      Specyfikacja procedury testu wstępnego

Podpraktyki

1.      Zdefiniowanie listy sprawdzeń wykonywanych podczas testu wstępnego

z zastosowaniem kryteriów wejścia zdefiniowanych w planie testów

Przykłady warunków, które mogą być sprawdzane podczas testu wstępnego:

•      Wszystkie niezbędne istotne funkcje są dostępne

•      Reprezentatywne funkcje są dostępne i działają przynajmniej w przypadku głównej ścieżki

•      Działają interfejsy z innymi modułami lub systemami podlegające testowaniu

•      Dokumentacja dostępnej funkcjonalności jest kompletna i obejmuje np. opis wydania testów, podręcznik użytkownika i podręcznik instalacji

2.      Opracowanie procedury testu wstępnego opartej na zidentyfikowanych operacjach sprawdzenia, składającej się z operacji sprawdzenia (przypadków testowych)

w kolejności umożliwiającej ich wykonanie, z uwzględnieniem innych informacji niezbędnych do przeprowadzenia testów

3.      Udokumentowanie procedury testu wstępnego w specyfikacji procedur testowych (zgodnie ze standardem specyfikacji procedur testowych)

4.      Przegląd specyfikacji procedury testu wstępnego z udziałem interesariuszy

5.      Aktualizacja specyfikacji procedury testu wstępnego zgodnie z potrzebami

SP 2.4       Opracowanie harmonogramu wykonywania testów

Opracowywany jest harmonogram wykonywania testów opisujący kolejność wykonywania procedur testowych.

Przykładowe produkty pracy

1.      Harmonogram wykonywania testów

Podpraktyki

1.      Analiza zależności między procedurami testowymi

2.      Zaplanowanie harmonogramu procedur testowych z uwzględnieniem priorytetu jako głównego kryterium

3.      Przypisanie testera do wykonania procedury testowej

4.      Przegląd harmonogramu wykonywania testów z udziałem interesariuszy

5.      Aktualizacja harmonogramu wykonywania testów zgodnie z potrzebami

SG 3       Wykonanie testów

Testy są wykonywane zgodnie z uprzednio wyspecyfikowanymi procedurami testowymi

i harmonogramem testów. W ich trakcie zgłaszane są incydenty i zapisywane są dzienniki testów.

SP 3.1       Przeprowadzenie testu wstępnego

Wykonanie testu wstępnego w celu ustalenia, czy przedmiot testów jest gotowy do dalszego szczegółowego testowania.

Przykładowe produkty pracy

1      Dziennik testu wstępnego

2.      Raporty o incydentach

Podpraktyki

1.      Wykonanie testu wstępnego z wykorzystaniem udokumentowanej procedury testowej

w celu ustalenia, czy przedmiot testów jest gotowy do dalszego szczegółowego testowania

2.      Udokumentowanie wyników testu wstępnego za pomocą dziennika testów (zgodnie ze standardem dziennika testów)

3.      Rejestrowanie incydentów w przypadku wykrycia rozbieżności

Uwaga: ta praktyka w znacznym stopniu wiąże się z praktyką SP 2.4 Wykonanie testu wstępnego środowiska z obszaru procesowego Środowisko testowe. Testy wstępne przedmiotu testowania i środowiska testowego można połączyć, jeśli jest to wykonalne.

SP 3.2       Wykonanie przypadków testowych

Zgodnie ze zdefiniowanym harmonogramem testów przypadki testowe są uruchamiane manualnie z wykorzystaniem udokumentowanych procedur testowych i/lub w ramach automatyzacji testowania z wykorzystaniem wstępnie zdefiniowanych skryptów testowych.

Przykładowe produkty pracy

1.      Rezultaty testów

Podpraktyki

1.      Wykonanie przypadków testowych z wykorzystaniem udokumentowanych procedur testowych i/lub skryptów testowych

2.      Zarejestrowanie rzeczywistych rezultatów

3.      Porównanie rzeczywistych rezultatów z oczekiwanymi

4.      Powtórzenie czynności testowych w ramach testowania potwierdzającego po otrzymaniu poprawki lub zmiany

5.      Wykonanie testowania regresji zgodnie z potrzebami

Należy zwrócić uwagę, że część testów może zostać przeprowadzona w sposób nieformalny, bez użycia wstępnie zdefiniowanych, szczegółowych procedur testowych, np. w formie testowania eksploracyjnego lub zgadywania błędów.

SP 3.3       Raportowanie incydentów testowych

Rozbieżności między rzeczywistymi a oczekiwanymi rezultatami zgłaszane są w postaci incydentów testowych.

Przykładowe produkty pracy

1. Raporty o incydentach testowych

Podpraktyki

1.      Rejestrowanie incydentów testowych w przypadku wykrycia rozbieżności

2.      Analizowanie incydentu testowego w celu uzyskania dodatkowych informacji

o problemie

3.      Określenie przyczyn incydentu testowego (np. testowany system, dokumentacja testowa, dane testowe, środowisko testowe lub błąd podczas wykonywania testu)

4.      Przypisanie początkowego priorytetu i poziomu ważności do incydentu testowego

5.      Formalne zgłoszenie incydentu testowego z wykorzystaniem schematu klasyfikacji incydentów

Przykładowe elementy raportu o incydencie testowym [wg ISO 29119-3]:

•      Identyfikator raportu o incydencie testowym

•      Podsumowanie

•      Informacje o czasie

•      Pomysłodawca

•      Kontekst

•      Opis incydentu (dane wejściowe, oczekiwane wyniki, rzeczywiste wyniki, anomalie, krok procedury testowej, środowisko, próby powtórzenia, testerzy, obserwatorzy)

•      Ocena ważności przez pomysłodawcę

•      Ocena priorytetu przez pomysłodawcę

•      Status incydentu

6.      Przegląd raportu o incydentach testowych z udziałem interesariuszy

7.      Zapisanie informacji o incydentach testowych w centralnym repozytorium

SP 3.4       Dokonanie wpisu w dzienniku testów

Tworzone są dzienniki testów w celu zarejestrowania chronologicznego zapisu istotnych szczegółów związanych z wykonaniem testów.

Przykładowe produkty pracy

1.      Dzienniki testów

Podpraktyki

1.      Gromadzenie danych dotyczących wykonywania testów

2.      Udokumentowanie danych dotyczących wykonywania testów za pomocą dziennika testów (zgodnie ze standardem dziennika testów)

Przykładowe elementy dziennika testów [wg ISO 29119-3]:

•      Identyfikator dziennika testów

•      Data i czas

•      Opis (testowane elementy, środowisko, w którym było prowadzone testowanie)

•      Informacje o działaniach i zdarzeniach (opis wykonania, rezultaty testów, nietypowe zdarzenia, identyfikatory raportów o incydentach)

•      Wpływ

3.      Przegląd dziennika testów z udziałem interesariuszy

SG 4       Zarządzanie incydentami testowymi do ich zamknięcia

Incydenty testowe są zarządzane, a problemy rozwiązywane zgodnie z potrzebami.

SP 4.1       Podjęcie decyzji dotyczących obsługi incydentów w ramach Rady Kontroli Zmian

Rada Kontroli Zmian (RKZ) podejmuje decyzje dotyczące działań, które należy podjąć

w związku z incydentami testowymi.

Przykładowe produkty pracy

1.      Raport ze spotkania RKZ, w tym zapis decyzji dotyczących incydentów testowych

2.      Zaktualizowane raporty o incydentach

Podpraktyki

1.      Ustanowienie RKZ z udziałem interesariuszy, w tym osób uczestniczących w testowaniu

2.      Przegląd i analiza wykrytych incydentów

3.      Aktualizacja priorytetu i poziomu ważności incydentów testowych

4.      Określenie działań, które należy podjąć dla wykrytych incydentów

Przykładowe decyzje, które można podjąć:

•      Odrzucenie; incydent nie jest defektem

•      Odroczenie; problem na razie nie zostanie usunięty, ale może zostać rozwiązany na późniejszym etapie

•      Do usunięcia; incydent został zaakceptowany i problem zostanie usunięty

5.      Zarejestrowanie decyzji w bazie incydentów wraz z uzasadnieniem i innymi istotnymi informacjami; raport o incydencie jest aktualizowany

6.      Przypisanie incydentu do odpowiedniej grupy, np. programistów, w celu wykonania odpowiednich działań

SP 4.2       Wykonanie odpowiednich działań w celu usunięcia incydentów testowych

Podejmowane są odpowiednie działania w celu usunięcia przyczyn incydentów testowych, ponownego przetestowania i zamknięcia incydentów albo odroczenia ich rozwiązywania do kolejnych wersji.

Przykładowe produkty pracy

1.      Dziennik testów (z rezultatami testów)

2.      Zaktualizowany raport o incydencie

Podpraktyki

1.      Usunięcie incydentu; może się to wiązać ze zmianami w dokumentacji i/lub kodzie oprogramowania

2.      Zarejestrowanie informacji o czynnościach naprawczych w bazie incydentów; zaktualizowanie raportu o incydencie

3.      Wykonanie testowania potwierdzającego i ewentualnie testowanie regresji w celu potwierdzenia usunięcia problemu

4.      Zarejestrowanie informacji o czynnościach związanych z testowaniem potwierdzającym w bazie incydentów; zaktualizowanie raportu o incydencie

5.      Formalne zamknięcie incydentu w przypadku pomyślnego zakończenia testowania potwierdzającego

SP 4.3       Śledzenie statusu incydentów testowych

Status incydentów testowych podlega śledzeniu i w miarę potrzeby podejmowane są odpowiednie działania.

Przykładowe produkty pracy

1.      Raport ze spotkania RKZ

2.      Raport o statusie incydentów

Podpraktyki

1.      Przekazanie interesariuszom raportów o statusie incydentów

Przykładowe elementy umieszczane w raporcie o statusie incydentów:

•      Incydenty otwarte w okresie XXXX-XXXX

•      Incydenty zamknięte w okresie XXXX-XXXX

•      Incydenty, które pozostają otwarte przez co najmniej X lub więcej tygodni

2.      Omówienie raportów dotyczących statusu na spotkaniu RKZ

3.      Podjęcie odpowiednich działań, jeśli są konieczne; np. w sytuacji, gdy incydent wymagający usunięcia nie zmienia statusu przez okres dłuższy niż uzgodniony

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Projektowanie i wykonywanie testów.

Opracowanie

Polityka projektowania i wykonywania testów zwykle zawiera następujące ustalenia:

•      Dla każdego poziomu testów zostanie zidentyfikowany odpowiedni zestaw technik projektowania testów

•      Specyfikacje testów będą wspierane przez szablony i standardy

•      Testy będą wykonywanie w oparciu o udokumentowane procedury testowe

•      Określony jest wymagany poziom automatyzacji wykonywania testów

•      Incydenty testowe są dokumentowane i zgłaszane z wykorzystaniem schematu klasyfikacji incydentów

•      Zgłoszone incydenty testowe są analizowane, klasyfikowane i przetwarzane zgodnie

z udokumentowaną procedurą

•      Wdrażane jest centralne repozytorium incydentów testowych

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Projektowanie i wykonywanie testów.

Opracowanie

Zwykle plan realizacji procesu projektowania i wykonywania testów jest uwzględniany w planie testów, co zostało opisane w obszarze procesowym o nazwie Planowanie testów. Harmonogram czynności związanych z projektowaniem i wykonywaniem testów jest bezpośrednio ustalany w ramach planu testów.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Projektowanie i wykonywanie testów, wytworzenia produktów pracy związanych z testowaniem oraz realizacji usług związanych z procesem.

Opracowanie

•      Zapewniono odpowiedni czas na wykonanie czynności związanych z projektowaniem

i wykonywaniem testów

•      Dostępne są doświadczone osoby dysponujące wiedzą specjalistyczną z dziedziny aplikacji oraz osoby dysponujące wiedzą w zakresie procesu wytwarzania oprogramowania; osoby takie wspierają tworzenie projektów testów, np. biorą udział

w przeglądach

•      Dostępne są narzędzia wspierające proces projektowania i wykonywania testów

Przykładowe narzędzia:

•      Narzędzia do analizy dynamicznej

•      Narzędzia do analizy pokrycia

•      Narzędzia do projektowania testów

•      Narzędzia do przygotowywania danych testowych

•      Narzędzia do wykonywania testów

•      Narzędzia do zarządzania incydentami

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Projektowanie i wykonywanie testów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Projektowanie

i wykonywanie testów zgodnie z potrzebami.

Opracowanie

Inżynierowie testów oraz inne osoby lub grupy uczestniczące w projektowaniu i wykonywaniu testów są szkolone w tym zakresie, jak również w zakresie powiązanych procedur i technik.

Przykładowe tematy szkoleń:

•      Formalne i nieformalne techniki projektowania testów

•      Proces specyfikacji testów

•      Wyprowadzanie warunków testowych i określanie ich priorytetów oraz tworzenie projektów testów

•      Tworzenie przypadków testowych i określanie ich priorytetów

•      Dokumentowanie i określanie priorytetów procedur testowych

•      Czynności związane z wykonywaniem testów

•      Szablony i standardy specyfikacji testów i dziennika testów

•      Zgłaszanie incydentów testowych

•      Zarządzanie incydentami testowymi

•      Pomocnicze narzędzia do projektowania i wykonywania testów

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Projektowanie i wykonywanie testów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Specyfikacje projektu testów

•      Specyfikacje przypadków testowych

•      Specyfikacje procedur testowych (i/lub skryptów testowych)

•      Harmonogram wykonywania testów

•      Dzienniki testów

•      Skrypty testowe dla testów automatycznych

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Projektowanie

i wykonywanie testów zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Przeglądy i zatwierdzanie projektów testów i przypadków testowych

•      Wykonywanie testów, np. w celu weryfikacji przez użytkowników końcowych

•      Udział w procesie zarządzania incydentami, np. uczestnictwo w spotkaniach RKZ

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Projektowanie i wykonywanie testów (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu projektowania i wykonywania testów:

•      Liczba opracowanych specyfikacji testów

•      Liczba wykonanych testów

•      Odsetek zaliczonych testów

•      Liczba nieusuniętych defektów (według priorytetu)

•      Trendy związane z defektami

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Projektowanie i wykonywanie testów oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Użycie technik projektowania testów

•      Zgodność specyfikacji testów (projektu testów, przypadków testowych, procedur testowych) z szablonami i standardami

•      Jakość przypadków testowych

•      Stosowanie dzienników testów i ich jakość

•      Zgodność z procesem zarządzania incydentami

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Projektowanie i wykonywanie testów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

Ma zastosowanie wyłącznie na poziomie TMMi 3.

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Projektowanie i wykonywanie testów.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Projektowanie i wykonywanie testów, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Liczba projektów testów utworzonych z wykorzystaniem technik projektowania testów

•      Czas poświęcony na opracowanie poszczególnych specyfikacji testów

•      Liczba raportów o incydentach według priorytetu i poziomu ważności

•      Skuteczność technik projektowania testów, np. wyrażona jako odsetek wykrytych defektów (OWD)

•      Odsetek zautomatyzowanych przypadków testowych.

PA 2.5      Środowisko testowe

Cel

Celem obszaru procesowego Środowisko testowe jest ustanowienie i utrzymywanie odpowiedniego środowiska, włączając dane testowe, w którym możliwe jest wykonywanie testów w sposób łatwy do zarządzania i powtarzalny.

Uwagi wstępne

Zarządzane i kontrolowane środowisko testowe jest niezbędnym elementem każdego procesu testowego. Konieczne jest również uzyskanie rezultatów testów w warunkach, które

w możliwie największym stopniu przypominają rzeczywistą sytuację. Dotyczy to szczególnie wyższych poziomów testów, np. testów systemowych i akceptacyjnych. Ponadto na żadnym poziomie testów nie powinno występować niebezpieczeństwo zmniejszenia powtarzalności rezultatów testów z powodu niepożądanych lub nieznanych zmian w środowisku testowym.

Specyfikację wymagań dotyczących środowiska testowego przygotowuje się na wczesnym etapie projektu. Specyfikacja poddawana jest przeglądowi w celu zapewnienia jej poprawności, dopasowania i wykonalności oraz uzyskania właściwej reprezentacji rzeczywistego środowiska operacyjnego. Dzięki wcześniejszemu wyspecyfikowaniu wymagań dotyczących środowiska testowego można poświęcić więcej czasu na pozyskanie i/lub opracowanie wymaganego środowiska i jego komponentów, takich jak symulatory, zaślepki

i sterowniki. Rodzaj wymaganego środowiska zależy od testowanego produktu oraz stosowanych typów testów, metod i technik testowania.

Z dostępnością środowiska testowego wiąże się pewna liczba zagadnień, które należy rozpatrzyć. Należy na przykład odpowiedzieć na pytanie, czy niezbędne jest środowisko dla każdego poziomu testów. Utrzymywanie odrębnych środowisk testowych dla każdego zespołu testowego lub poziomu testów bywa bardzo kosztownym rozwiązaniem. Warto sprawdzić, czy to samo środowisko może być używane zarówno przez testerów, jak i programistów. Jeśli tak, to niezbędne są rygorystyczne mechanizmy zarządzania i kontroli, ponieważ prowadzenie obu rodzajów prac w tym samym środowisku może negatywnie wpłynąć na realizację projektu. Przy braku odpowiedniego zarządzania taka sytuacja jest źródłem wielu problemów, związanych na przykład z konfliktami rezerwacji zasobów albo z nieznanym lub niepożądanym stanem środowiska w momencie rozpoczęcia pracy.

Zarządzanie środowiskiem testowym obejmuje także zarządzanie dostępem do tego środowiska. Wiąże się z tym udostępnienie danych logowania, zarządzanie danymi testowymi, udostępnienie i egzekwowanie mechanizmów zarządzania konfiguracją oraz świadczenie wsparcia technicznego w przypadku problemów utrudniających realizację zadań podczas wykonywania testów.

W ramach obszaru procesowego Środowisko testowe rozpatrywane są także wymagania dotyczące ogólnych danych testowych oraz kwestie tworzenia danych testowych i zarządzania tymi danymi. Konkretne dane testowe są definiowane podczas analizy

i projektowania testów, natomiast bardziej ogólne dane testowe często definiuje się i tworzy

w ramach odrębnej czynności. Ogólne dane testowe są wielokrotnie używane przez wielu testerów. Są to ogólne dane środowiskowe niezbędne do realizowania funkcji systemu. Ogólne dane testowe zwykle składają się z danych głównych i wstępnej zawartości zbioru danych podstawowych. W pewnych sytuacjach na wykonanie tej czynności mają wpływ zależności czasowe.

Zakres

Obszar procesowy Środowisko testowe obejmuje wszystkie czynności związane ze specyfikowaniem wymagań dotyczących środowiska testowego, implementacją środowiska testowego oraz zarządzaniem tym środowiskiem i jego kontrolowaniem. W ramach zarządzania i kontroli uwzględnione są takie aspekty, jak zarządzanie konfiguracją

i zapewnienie dostępności. Zakres obszaru procesowego Środowisko testowe obejmuje zarówno fizyczne środowisko testowe, jak i dane testowe.

Podsumowanie celów i praktyk szczegółowych

SG 1       Określenie wymagań dotyczących środowiska testowego

SP 1.1       Uzyskanie informacji o potrzebach związanych ze środowiskiem testowym

SP 1.2      Określenie wymagań dotyczących środowiska testowego

SP 1.3      Analiza wymagań dotyczących środowiska testowego

SG 2       Implementacja środowiska testowego

SP 2.1       Implementacja środowiska testowego

SP 2.2       Utworzenie ogólnych danych testowych

SP 2.3       Specyfikacja procedury testu wstępnego środowiska testowego

SP 2.4       Wykonanie testu wstępnego środowiska testowego

SG 3       Zarządzanie środowiskami testowymi i ich kontrola

SP 3.1      Zarządzanie systemami

SP 3.2      Zarządzanie danymi testowymi

SP 3.3       Koordynowanie dostępności i używania środowisk testowych

SP 3.4       Zgłaszanie incydentów dotyczących środowiska testowego

i zarządzanie tymi incydentami

Praktyki szczegółowe dla poszczególnych celów

SG 1       Określenie wymagań dotyczących środowiska testowego

Informacje o potrzebach interesariuszy, oczekiwaniach i ograniczeniach są gromadzone

i przekształcane w wymagania dotyczące środowiska testowego.

SP 1.1       Uzyskanie informacji o potrzebach związanych ze środowiskiem testowym

Uzyskanie informacji o potrzebach dotyczących środowiska testowego, w tym ogólnych danych testowych, oczekiwaniach i ograniczeniach.

Przykładowe produkty pracy

1.      Lista potrzeb dotyczących środowiska testowego

Podpraktyki

1.      Analiza podejścia do testów i planu testów w celu określenia założeń dotyczących środowiska testowego

2.      Zaangażowanie przedstawicieli zespołu testowego w pozyskiwanie informacji

o potrzebach dotyczących środowiska testowego, w tym ogólnych danych testowych, oczekiwaniach i ograniczeniach

Przykładowe potrzeby związane ze środowiskiem testowym:

•      Komponenty sieci

•      Komponenty oprogramowania, np. systemy operacyjne, oprogramowanie wbudowane

•      Symulatory, zaślepki i sterowniki

•      Dokumentacja pomocnicza, np. podręczniki użytkownika, podręczniki techniczne

i podręczniki instalacji

•      Interfejsy komponentów lub produktów

•      Narzędzia do tworzenia zaślepek i sterowników

•      Sprzęt służący do testów

•      Wymagania dotyczące wielu środowisk testowych

•      Ogólne testowe bazy danych

•      Generatory danych testowych

•      Potrzeby w zakresie przechowywania danych testowych

•      Mechanizmy archiwizacji i odtwarzania danych testowych

3.      Udokumentowanie potrzeb dotyczących środowiska testowego, w tym ogólnych danych testowych, oczekiwań i ograniczeń

SP 1.2       Określenie wymagań dotyczących środowiska testowego

Przekształcenie potrzeb dotyczących środowiska testowego w wymagania z określonymi priorytetami.

Przykładowe produkty pracy

1.      Lista wymagań dotyczących środowiska testowego z określonymi priorytetami

2.      Arkusz przydziału wymagań

Podpraktyki

1.      Przekształcenie potrzeb dotyczących środowiska testowego, włączając w to oczekiwania i ograniczenia, w udokumentowane wymagania dotyczące środowiska testowego (ISO 29119-3), również odnoszące się do wymagań dotyczących danych testowych (ISO 29119-3).

2.      Zdefiniowanie odpowiedzialności i okresu potrzebnego dla każdego elementu środowiska testowego

3.      Ustanowienie i utrzymywanie mechanizmów określania priorytetów wymagań dotyczących środowiska testowego

Dzięki określeniu priorytetów wymagań dotyczących środowiska testowego można łatwiej określić jego zakres. Wymagania o krytycznym znaczeniu dla funkcjonowania środowiska testowego są szybciej realizowane.

4.      Przydzielenie wymagań dotyczących środowiska testowego do komponentów tego środowiska

SP 1.3       Analiza wymagań dotyczących środowiska testowego

Przeprowadzana jest analiza wymagań w celu sprawdzenia, czy są one niezbędne, wystarczające i możliwe do realizacji.

Przykładowe produkty pracy

1.      Raport z analizy wymagań dotyczących środowiska testowego

2.      Zapis przeglądu wymagań dotyczących środowiska testowego

3.      Lista ryzyk związanych ze środowiskiem testowym

Podpraktyki

1.      Analiza wymagań dotyczących środowiska testowego w celu ustalenia, czy w pełni wspierają cykl życia testów i podejście do testów

Przykładowe praktyki wspierające analizę wymagań dotyczących środowiska testowego:

•      Powiązanie wymagań dotyczących środowiska testowego z poziomami testów

•      Powiązanie wymagań dotyczących środowiska testowego z typami testów

2.      Zidentyfikowanie kluczowych wymagań dotyczących środowiska testowego mających istotny wpływ na koszty, harmonogram i wydajność testów

3.      Zidentyfikowanie wymagań dotyczących środowiska testowego, które mogą zostać zaimplementowane z wykorzystaniem istniejących lub zmodyfikowanych zasobów

4.      Analiza wymagań dotyczących środowiska testowego w celu sprawdzenia, czy są kompletne i możliwe do realizacji

5.      Analiza wymagań dotyczących środowiska testowego w celu sprawdzenia, czy

w wystarczającym stopniu opisują rzeczywistą sytuację, zwłaszcza w przypadku wyższych poziomów testów

6.      Zidentyfikowanie ryzyk związanych z projektem testowym i wymaganiami dotyczącymi środowiska testowego

7.      Przegląd specyfikacji wymagań dotyczących środowiska testowego z udziałem interesariuszy

8.      Aktualizacja specyfikacji wymagań dotyczących środowiska testowego zgodnie

z potrzebami

SG 2       Implementacja środowiska testowego

Wymagania dotyczące środowiska testowego są implementowane i udostępnione zostaje środowisko testowe, które będzie używane podczas wykonywania testów.

SP 2.1       Implementacja środowiska testowego

Implementacja środowiska testowego zgodnie ze specyfikacją wymagań dotyczących środowiska testowego i zdefiniowanym planem.

Przykładowe produkty pracy

1.      Działające środowisko testowe

2.      Rezultaty testów komponentów środowiska testowego

Podpraktyki

1.      Implementacja środowiska testowego zgodnie ze specyfikacją i zdefiniowanym planem

2.      Przestrzeganie odpowiednich standardów i kryteriów

3.      Przetestowanie komponentów środowiska testowego zgodnie z potrzebami

4.      Opracowanie dokumentacji pomocniczej, np. dokumentacji instalacji, obsługi

i konserwacji

5.      Aktualizacja komponentów środowiska testowego zgodnie z potrzebami

Środowisko musi zostać zaktualizowane na przykład wówczas, gdy podczas implementacji występują problemy, których nie można było przewidzieć w trakcie specyfikowania wymagań.

SP 2.2       Utworzenie ogólnych danych testowych

Tworzone są ogólne dane testowe zgodnie ze specyfikacją wymagań dotyczących danych testowych.

Przykładowe produkty pracy

1.      Ogólne dane testowe

Podpraktyki

1.      Tworzenie ogólnych danych testowych wymaganych do wsparcia wykonywania testów

2.      Anonimizacja danych wrażliwych zgodnie z odpowiednią polityką, jeśli jako danych źródłowych użyto danych rzeczywistych

3.      Archiwizacja zbioru ogólnych danych testowych

4.      Utworzenie raportu gotowości danych testowych (ISO 29119-3) opisującego spełnienie każdego wymagania dotyczącego danych testowych.

SP 2.3       Specyfikacja procedury testu wstępnego środowiska testowego

Specyfikowany jest test wstępny środowiska testowego, którego celem jest sprawdzenie gotowości środowiska do prowadzenia testów.

Przykładowe produkty pracy

1.      Lista kontrolna testu wstępnego środowiska testowego

2.      Specyfikacja procedury testu wstępnego środowiska testowego

3.      Zapis przeglądu dotyczącego specyfikacji procedury testu wstępnego środowiska testowego

Podpraktyki

1.      Zdefiniowanie listy operacji sprawdzeń wykonywanych podczas testu wstępnego środowiska testowego

2.      Opracowanie procedury testu wstępnego środowiska testowego opartej na zidentyfikowanych operacjach sprawdzenia, która składa się z operacji sprawdzenia (przypadków testowych) podanych w kolejności umożliwiającej ich wykonanie,

z uwzględnieniem innych informacji niezbędnych do przeprowadzenia testu wstępnego środowiska testowego

3.      Udokumentowanie procedury testu wstępnego środowiska testowego w specyfikacji procedur testowych (zgodnie ze standardem specyfikacji procedur testowych)

4.      Przegląd specyfikacji procedury testu wstępnego środowiska testowego z udziałem interesariuszy

5.      Aktualizacja procedury testu wstępnego środowiska testowego zgodnie z potrzebami

Uwaga: ta praktyka w znacznym stopniu wiąże się z praktyką SP 2.3 Specyfikacja procedury testu wstępnego z obszaru procesowego Projektowanie i wykonywanie testów. Obie praktyki można połączyć, jeśli jest to wykonalne.

SP 2.4       Wykonanie testu wstępnego środowiska testowego

Wykonywany jest test wstępny środowiska testowego w celu sprawdzenia gotowości środowiska do prowadzenia testów.

Przykładowe produkty pracy

1.      Dziennik testu wstępnego środowiska testowego

2.      Raporty o incydentach

Podpraktyki

1.      Wykonanie testu wstępnego z wykorzystaniem udokumentowanej procedury testu wstępnego w celu sprawdzenia gotowości środowiska testowego do prowadzenia testów

2.      Udokumentowanie rezultatów testu wstępnego środowiska testowego za pomocą dziennika testów w postaci raportu gotowości środowiska testowego (ISO 29119-3)

3.      Rejestrowanie incydentów w przypadku wykrycia rozbieżności

Więcej informacji na temat rejestrowania incydentów zawiera opis praktyki SP 3.3 Raportowanie incydentów testowych z obszaru procesowego Projektowanie

i wykonywanie testów.

Uwaga: ta praktyka w znacznym stopniu wiąże się z praktyką SP 3.1 Przeprowadzenie testu wstępnego z obszaru procesowego Projektowanie i wykonywanie testów. Testy wstępne przedmiotu testów i środowiska testowego można połączyć, jeśli jest to wykonalne.

SG 3       Zarządzanie środowiskami testowymi i ich kontrola

Środowiska testowe podlegają zarządzaniu i kontroli w celu zapewnienia niezakłóconego wykonywania testów.

SP 3.1       Zarządzanie systemami

Środowiska testowe objęte są zarządzaniem systemami w celu skutecznego i wydajnego wsparcia procesu wykonywania testów.

Przykładowe produkty pracy

1.      Plik dziennika zarządzania systemem

2.      Dziennik testów

Podpraktyki

1.      Zainstalowanie niezbędnych komponentów, np. na potrzeby konkretnej sesji testowej

2.      Zarządzanie dostępem do środowiska testowego poprzez udostępnienie danych logowania

3.      Świadczenie wsparcia technicznego w przypadku problemów utrudniających realizację zadań podczas wykonywania testów

4.      Udostępnienie mechanizmów rejestrowania w dziennikach, które można wykorzystać do analizy rezultatów testów

SP 3.2       Zarządzanie danymi testowymi

Dane testowe podlegają zarządzaniu i kontroli w celu skutecznego i wydajnego wsparcia procesu wykonywania testów.

Przykładowe produkty pracy

1.      Zarchiwizowane dane testowe

2.      Plik dziennika zarządzania danymi testowymi

Podpraktyki

1.      Zarządzanie zabezpieczeniami i dostępem do danych testowych

2.      Zarządzanie danymi testowymi, np. w zakresie niezbędnych zasobów pamięci masowej

3.      Archiwizowanie i odtwarzanie danych testowych i innych plików (regularnie oraz w miarę potrzeb związanych z sesjami testowymi)

SP 3.3       Koordynowanie dostępności i używania środowisk testowych

Dostępność środowiska testowego i jego wykorzystanie przez różne grupy użytkowników podlegają koordynacji w celu uzyskania maksymalnej efektywności.

Przykładowe produkty pracy

1.      Harmonogram rezerwacji środowiska testowego

Podpraktyki

1.      Zdefiniowanie procedury zarządzania wykorzystaniem środowisk testowych przez różne grupy użytkowników

2.      Tworzenie udokumentowanych rezerwacji środowisk testowych w harmonogramie rezerwacji

3.      Identyfikowanie konkretnych wymaganych komponentów środowiska testowego podczas dokonywania rezerwacji

4.      Omawianie konfliktów rezerwacji z zainteresowanymi grupami i interesariuszami

5.      Definiowanie harmonogramu rezerwacji środowiska testowego na kolejny okres

6.      Korzystanie ze środowiska testowego w zarezerwowanym i przydzielonym przedziale czasowym

7.      Poprawne uporządkowanie środowiska testowego po użyciu, m.in. przywrócenie go do znanego stanu i usunięcie plików testowych

SP 3.4       Zgłaszanie incydentów dotyczących środowiska testowego i zarządzanie tymi incydentami

Problemy, które występują podczas korzystania ze środowiska testowego, są formalnie zgłaszane i podlegają zarządzaniu aż do ich zamknięcia.

Przykładowe produkty pracy

1.      Raporty o incydentach dotyczących środowiska testowego

2.      Raporty ze spotkań RKZ, w tym zapis decyzji dotyczących incydentów związanych ze środowiskiem testowym

Podpraktyki

1.      Rejestrowanie incydentów dotyczących środowiska testowego w przypadku wykrycia problemów

2.      Formalne zgłoszenie incydentu dotyczącego środowiska testowego z wykorzystaniem schematu klasyfikacji incydentów

3.      Zarządzanie incydentami dotyczącymi środowiska testowego do ich zamknięcia

Więcej informacji na temat praktyk i podpraktyk związanych ze zgłaszaniem incydentów

i zarządzaniem nimi zawiera opis obszaru procesowego Projektowanie i wykonywanie testów.

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Środowisko testowe.

Opracowanie

Polityka dotycząca środowiska testowego zwykle zawiera następujące ustalenia:

•      Specyfikacja wymagań dotyczących środowiska testowego powinna zostać przygotowana na wczesnym etapie cyklu życia

•      Testy na wyższych poziomach powinny zostać przeprowadzone w środowisku testowym reprezentującym rzeczywiste warunki

•      Procesy zarządzania środowiskami testowymi i ich kontroli są realizowane zgodnie

z udokumentowanymi procedurami

•      W testach na niższych poziomach, np. modułowych lub integracyjnych, powinny być wykorzystywane zaślepki i sterowniki

•      Muszą być przestrzegane zasady bezpieczeństwa i ochrony prywatności dotyczące używania rzeczywistych danych do tworzenia danych testowych

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Środowisko testowe.

Opracowanie

Zwykle plan realizacji procesu Środowisko testowe jest uwzględniany w planie testów, co zostało opisane w obszarze procesowym o nazwie Planowanie testów. W projekcie, w którym środowisko testowe jest bardziej złożone i wymaga w związku z tym większej ilości zasobów, można przygotować specjalny plan środowiska testowego. Taki dokument zwykle zawiera szczegółowy opis procesu implementacji wymagań dotyczących środowiska testowego.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Środowisko testowe, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

•      Dostępne są doświadczone osoby dysponujące wiedzą specjalistyczną i techniczną, które mogą wziąć udział w specyfikowaniu wymagań dotyczących środowiska testowego

•      Zapewniono odpowiedni czas i zasoby na implementację środowiska testowego, zarządzanie nim i jego kontrolę

•      Zapewniono odpowiedni czas i zasoby na utworzenie danych testowych, zarządzanie nimi i ich kontrolę

•       Zapewniono odpowiedni czas i zasoby inżynierom testów na opracowanie zaślepek

i sterowników niezbędnych do testowania na niższych poziomach testów

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Środowisko testowe, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

Przykładowe obowiązki związane ze środowiskiem testowym, które należy przydzielić uczestnikom projektu:

•      Specyfikowanie wymagań dotyczących środowiska testowego

•      Implementacja środowiska testowego

•      Zarządzanie konfiguracją środowiska testowego

•      Konserwacja i aktualizowanie środowiska testowego

•      Rozwiązywanie problemów technicznych związanych ze środowiskiem testowym

•      Zapewnienie powtarzalności testów w środowisku testowym

•      Wsparcie i konsultacje dotyczące procedur i problemów technicznych związanych ze środowiskiem testowym

•      Zapewnienie dostępności środowiska testowego

•      Wsparcie w zakresie definiowania podejścia do obsługi danych testowych w projektach

•      Tworzenie ogólnych danych testowych

•      Zarządzanie danymi testowymi i ich ochrona

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Środowisko testowe zgodnie z potrzebami.

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Środowisko testowe odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Specyfikacja wymagań dotyczących środowiska testowego

•      Plany środowiska testowego

•      Środowiska testowe

•      Dane testowe

•      Skrypty konfiguracyjne

•      Skrypty instalacyjne

Należy pamiętać, że zarządzanie konfiguracją środowisk testowych i danych testowych to ważny element każdego rodzaju testów i warunek ich powtarzalności.

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Środowisko testowe zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Przegląd specyfikacji wymagań dotyczących środowiska testowego

•      Udostępnienie zasobów i/lub danych wejściowych na potrzeby implementacji środowiska testowego, np. podwykonawcom odpowiedzialnym za wytworzenie komponentów tego środowiska

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Środowisko testowe (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Chociaż czasami się o tym zapomina, monitorowanie postępu tworzenia zaślepek

i sterowników niezbędnych do przeprowadzenia testów modułowych i integracyjnych jest oczywiście ważnym zagadnieniem. Zadania z tym związane powinny zostać zrealizowane

w terminie, zgodnie z harmonogramem.

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Środowisko testowe oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad weryfikowane w ramach przeglądu i/lub audytu:

•      Specyfikacja wymagań dotyczących środowiska testowego została przygotowana na wczesnym etapie projektu

•      Środowiska testowe w maksymalnym możliwym stopniu odzwierciedlają rzeczywiste warunki, zwłaszcza w przypadku wyższych poziomów testowania

•      Zapewniony jest odpowiedni poziom dostępności środowisk testowych

•      Proces zarządzania środowiskiem testowym i jego kontroli jest skuteczny i efektywny

•      Dane testowe nadają się do prowadzenia testów warunków rzeczywistych

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Środowisko testowe z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

Ma zastosowanie wyłącznie na poziomie TMMi 3.

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Środowisko testowe.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Środowisko testowe, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Liczba konfliktów rezerwacji środowiska testowego

•      Pracochłonność niezbędna na konserwację, naprawy i aktualizacje

•      Liczba przypadków testowych niezaliczonych z powodu środowiska testowego

•      Średni czas przestoju środowiska testowego

•      Liczba zgłoszonych incydentów dotyczących środowiska

•      Odsetek środowisk testowych dostępnych w terminie i zgodnych ze specyfikacją

•      Liczba defektów wykrytych w środowisku produkcyjnym, które nie zostały wykryte

w testach z powodu nieodpowiedniego środowiska testowego lub nieodpowiednich danych testowych.

Poziom TMMi 3: Zdefiniowany

Na poziomie 3. w TMMi testowanie nie ogranicza się już do fazy, która następuje po kodowaniu. Jest ono w pełni zintegrowane z cyklem wytwarzania i związanymi z nim kamieniami milowymi. Planowanie testów odbywa się na wczesnym etapie projektu, np.

w fazie specyfikacji wymagań, i jest dokumentowane w głównym planie testów. Opracowanie głównego planu testów opiera się na umiejętnościach planowania testów i zobowiązaniach uzyskanych na poziomie TMMi 2. Zbiór standardowych procesów organizacji w obszarze testowania, który stanowi podstawę dla poziomu dojrzałości 3, jest ustalany i doskonalony

w miarę upływu czasu. Istnieje organizacja testowa i specyficzny program szkoleń testerskich, a testowanie jest postrzegane jako profesja. Usprawnianie procesów testowych jest w pełni zinstytucjonalizowane w ramach przyjętych praktyk organizacji testowej.

Organizacje na poziomie 3. rozumieją znaczenie przeglądów w kontroli jakości; wdrażany jest program przeglądu formalnego, choć nie jest on jeszcze w pełni powiązany

z procesem testowania dynamicznego. Przeglądy odbywają się w całym cyklu życia.

W przeglądy specyfikacji wymagań zaangażowani są specjaliści ds. testów. Podczas gdy projektowanie testów na poziomie TMMi 2 koncentruje się głównie na testowaniu funkcjonalności, to na poziomie 3. projektowanie testów i techniki testowania są rozszerzone w celu uwzględnienia testów niefunkcjonalnych, np. użyteczności i/lub niezawodności,

w zależności od celów biznesowych.

Kluczową różnicą pomiędzy 2. i 3. poziomem dojrzałości TMMi jest zakres norm, opisów procesów i procedur. Na 2. poziomie dojrzałości mogą one być zupełnie inne w każdym przypadku, np. dla konkretnego projektu. Na 3. poziomie dojrzałości są one ustalane na podstawie zbioru standardowych procesów organizacji w celu dostosowania ich do konkretnego projektu lub jednostki organizacyjnej, a zatem są bardziej spójne, z wyjątkiem różnic, na jakie pozwalają wytyczne dotyczące ich dostosowania. Tego rodzaju dostosowanie pozwala również skutecznie porównywać różne implementacje zdefiniowanego procesu

i łatwiej przenosić personel między poszczególnymi projektami. Kolejną istotną różnicą jest to, że na 3. poziomie dojrzałości procesy są zazwyczaj opisane bardziej rygorystycznie niż na poziomie dojrzałości 2. W konsekwencji na 3. poziomie dojrzałości organizacja musi zrewidować obszary procesowe z poziomu dojrzałości 2.

Obszary procesowe na poziomie TMMi 3 są następujące:

3.1      Organizacja testowa

3.2      Program szkoleń testerskich

3.3      Cykl życia i integracja testów

3.4      Testowanie niefunkcjonalne

3.5      Przeglądy koleżeńskie

Poszczególne obszary zostały dokładniej omówione w kolejnych rozdziałach.

PA 3.1      Organizacja testowa

Cel

Celem obszaru procesowego Organizacja testowa jest wybór i zorganizowanie grupy wykwalifikowanych osób odpowiedzialnych za testowanie. Oprócz samego testowania grupa ta zajmuje się zarządzaniem usprawnieniami wprowadzanymi w procesie testowym organizacji i związanych z nim zasobach dzięki zrozumieniu mocnych i słabych stron aktualnego procesu testowego i odpowiednich zasobów.

Uwagi wstępne

Ustanowienie organizacji testowej jest zobowiązaniem do skuteczniejszego testowania

i zapewnienia lepszej jakości oprogramowania. W celu zainicjowania tego procesu kierownictwo wyższego szczebla musi potwierdzić decyzję o ustanowieniu grupy testowej

i przydzielić do niej pracowników. Wymagane jest również kierownictwo merytoryczne obszarach związanych z testowaniem i jakością. Członkowie takiej grupy nazywani są specjalistami ds. testów. Działanie organizacji (grupy) testowej opiera się na efektywnym połączeniu kwalifikacji specjalistów ds. testów, infrastruktury testowej i czynności testowych występujących w projekcie, a celem jej powołania jest uzyskanie ustrukturyzowanego procesu testowego spełniającego wysokie standardy. Definiowane są odpowiednie mechanizmy komunikacji grupy testowej z działami biznesowymi i programistycznymi oraz jednostkami odpowiedzialnymi za zapewnienie jakości. Synergia między tymi elementami tworzy strukturę będącą czymś więcej niż sumą poszczególnych części.

Ważne jest, aby w organizacji istniała niezależna grupa testowa. Grupa taka powinna zajmować formalne miejsce w hierarchii organizacyjnej. Określenie „niezależna” ma charakter ogólny – każda organizacja musi zinterpretować je w sposób dopasowany do swoich potrzeb i wdrożyć właściwy poziom niezależności. Organizacja testowa może na przykład funkcjonować jako centrum kompetencji dotyczących testowania dysponujące pulą zasobów testowych. W takiej sytuacji członkowie grupy są przypisywani do projektów w ramach różnych jednostek organizacyjnych, gdzie wykonują zadania związane z testowaniem, albo działają jako niezależny zespół, który prowadzi testy akceptacyjne przed opublikowaniem kolejnej wersji produktu. W rozumieniu TMMi niezależność organizacji testowej oznacza, że testerzy są uznawani za specjalistów ds. projektowania. Testerzy nie są programistami i – co najważniejsze – podlegają innym strukturom niż jednostki odpowiedzialne za zarządzanie pracami programistycznymi. Specjaliści ds. testów mogą zachować obiektywizm

i bezstronność, nie zwracając uwagi na ewentualne naciski ze strony jednostek odpowiedzialnych za wytwarzanie oprogramowania.

Testowanie uznawane jest za ważny obszar kompetencji, a powołanie grupy testowej za konieczny element działań. Do takiej grupy przypisywane są osoby odpowiednio zmotywowane i dysponujące szczegółową, specjalistyczną wiedzą oraz kwalifikacjami

w dziedzinie projektowania testów, zarządzania testami i danego obszaru zastosowań. Definiuje się funkcje i ścieżki rozwoju związane z testowaniem wspierane przez program szkoleń testerskich. Do grupy przyjmowane są osoby o umiejętnościach i motywacji charakteryzujących dobrych testerów. Otrzymują one konkretne funkcje związane

z testowaniem i koncentrują na informowaniu o celach związanych z jakością produktów oraz o realizacji takich celów. Dokonują pomiarów charakterystyk jakości i odpowiadają za doprowadzenie systemu do stanu, który spełnia wymagania klientów. Określane są też czynności testowe, role i obowiązki innych pracowników (osób niebędących specjalistami ds. testów). Dla każdej funkcji związanej z testowaniem określane są typowe zadania, obowiązki, uprawnienia, wymagana wiedza i umiejętności oraz zakres szkoleń testerskich. Dlatego obszary procesowe Organizacja testowa i Program szkoleń testerskich są ściśle powiązane

i połączone wzajemnymi zależnościami. Jednym z głównych celów programu szkoleń jest wsparcie organizacji testowej w kształceniu specjalistów ds. testów.

Doskonalenie procesu testowego jest na poziomie TMMi 2 traktowane czasami jako projekt o nieformalnym charakterze, za to na tym poziomie stanowi zorganizowany, ustrukturyzowany obszar w ramach organizacji testowej. Za stworzenie warunków do realizacji działań związanych z usprawnianiem procesu testowego oraz zarządzanie tymi działaniami, w tym koordynowanie udziału osób z innych obszarów, zwykle odpowiada kierownik ds. technologii testowania wspierany przez komitet sterujący. W niektórych sytuacjach grupa

ds. usprawnienia procesu testowego, często nazywana grupą procesu testowego, już istnieje

w danej organizacji i ma odpowiednią obsadę kadrową. Obszary, w których można wprowadzić usprawnienia, są ustalane na podstawie różnych źródeł, m.in. pomiarów, wniosków wyciągniętych z poprzednich projektów i wyników oceny. Wymagane jest szczegółowe planowanie, tak aby prace związane z usprawnianiem procesu testowego były we właściwy sposób zarządzane i realizowane. W rezultacie powstaje plan doskonalenia procesu testowego. W dokumencie tym omówione są kwestie planowania oceny, planowania działań związanych z procesami, planowania pilotażu i planowania wdrożeń. Jeśli usprawnienia

w procesie testowym mają zostać wdrożone, stosuje się plan wdrożenia. Plan wdrożenia opisuje harmonogram i sposób implementacji zmian w całej organizacji.

Zakres

Obszar procesowy Organizacja testowa definiuje sposób funkcjonowania (zadania, zakres odpowiedzialności, hierarchię organizacyjną) oraz miejsce grupy testowej w ramach danej organizacji. Definiuje się również role i funkcje związane z testami oraz ścieżki rozwoju związane z testowaniem jako specjalistyczną dziedziną. W ramach organizacji testowej kluczowym obszarem działań jest usprawnienie procesu testowego. Obejmuje to ocenę bieżącego procesu testowego i analizę wniosków wyciągniętych z poprzednich przedsięwzięć w celu zidentyfikowania możliwości usprawnień oraz ich zaimplementowania i wdrożenia

w czynnościach testowych wykonywanych w realizowanych projektach.

Podsumowanie celów i praktyk szczegółowych

SG 1       Ustanowienie organizacji testowej

SP 1.1      Zdefiniowanie organizacji testowej

SP 1.2       Uzyskanie zobowiązań dotyczących organizacji testowej

SP 1.3      Wdrożenie organizacji testowej

SG 2       Ustalenie funkcji związanych z testowaniem dla specjalistów ds. testów

SP 2.1      Zidentyfikowanie funkcji związanych z testowaniem

SP 2.2      Opracowanie opisu stanowisk

SP 2.3       Przypisanie pracowników do funkcji związanych z testowaniem

SG 3       Określenie ścieżek rozwoju związanych z testowaniem

SP 3.1       Określenie ścieżek rozwoju związanych z testowaniem

SP 3.2       Opracowanie indywidualnych planów rozwoju związanych

z testowaniem

SG 4       Określenie, zaplanowanie i wdrożenie usprawnień procesu testowego

SP 4.1      Ocena procesu testowego w organizacji

SP 4.2      Zidentyfikowanie możliwości udoskonalenia procesu testowego

w organizacji

SP 4.3       Zaplanowanie usprawnień procesu testowego

SP 4.4       Wdrożenie usprawnień procesu testowego

SG 5       Wdrożenie procesu testowego w organizacji i uwzględnienie wyciągniętych wniosków

SP 5.1       Wdrożenie standardowego procesu testowego i związanych z nim zasobów

SP 5.2       Monitorowanie wdrożenia

SP 5.3       Uwzględnienie wniosków wyciągniętych z poprzednich projektów

w procesie testowym organizacji

Praktyki szczegółowe dla poszczególnych celów

SG 1       Ustanowienie organizacji testowej

Definiowana jest i ustanawiana organizacja testowa, która wspiera stosowanie praktyk związanych z testowaniem w projektach i całym przedsiębiorstwie.

SP 1.1       Zdefiniowanie organizacji testowej

Następuje zdefiniowanie organizacji testowej i uzgodnienie jej działania przez interesariuszy.

Przykładowe produkty pracy

1. Opis organizacji testowej

Podpraktyki

1.       Zdefiniowanie organizacji testowej, np. na podstawie zdefiniowanych celów i polityki biznesowej, celów i polityki testowania i/lub strategii testów

Przykłady typowych zagadnień uwzględnianych podczas definiowania organizacji testowej:

•      Formalne miejsce w strukturze organizacyjnej

•      Rodzaj jednostki organizacyjnej

•      Poziom niezależności od działu rozwoju oprogramowania

•      Zadania, kompetencje i zakres odpowiedzialności organizacji testowej

•      Hierarchia organizacyjna

•      Wyjściowe zasoby, np. liczba specjalistów ds. testów

Należy zwrócić uwagę, że w idealnym przypadku organizacja testowa powinna być odrębną jednostką organizacyjną lub działem. Może to jednak okazać się niemożliwe lub niepraktyczne ze względu na wielkość przedsiębiorstwa, poziom ryzyka związany z tworzonymi systemami albo dostępność zasobów.

2.      Przegląd opisu organizacji testowej z udziałem interesariuszy

SP 1.2       Uzyskanie zobowiązań dotyczących organizacji testowej

Określane są i utrzymywane zobowiązania dotyczące wdrożenia i wsparcia organizacji testowej.

Przykładowe produkty pracy

1.      Udokumentowane żądania dotyczące zobowiązań

2.      Udokumentowane zobowiązania

Podpraktyki

1.      Zidentyfikowanie niezbędnego wsparcia i wynegocjowanie zobowiązań dotyczących organizacji testowej z odpowiednimi interesariuszami

2.      Udokumentowanie wszystkich zobowiązań organizacyjnych (pełnych i tymczasowych)

3.      Przegląd zobowiązań wewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

4.      Przegląd zobowiązań zewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

SP 1.3       Wdrożenie organizacji testowej

Organizacja testowa jest wdrażana w przedsiębiorstwie zgodnie z zatwierdzoną definicją.

Przykładowe produkty pracy

1.      Status i rezultaty wdrożenia organizacji testowej

Podpraktyki

1.      Śledzenie postępu wdrożenia i zobowiązań

2.      Identyfikowanie, dokumentowanie i śledzenie aż do rozwiązania problemów związanych z wdrożeniem organizacji testowej

3.      Zapewnienie zgodności rezultatów wdrożenia organizacji testowej z celami przedsiębiorstwa

SG 2       Ustalenie funkcji związanych z testowaniem dla specjalistów ds. testów

Ustalane są funkcje związane z testowaniem wraz z opisami stanowisk. Funkcje te są przypisywane specjalistom ds. testów.

SP 2.1       Zidentyfikowanie funkcji związanych z testowaniem

Zgodnie z potrzebami definiowany jest zestaw funkcji związanych z testowaniem.

Przykładowe produkty pracy

1.       Lista zidentyfikowanych funkcji związanych z testowaniem

Podpraktyki

1.      Analiza polityki testów, strategii testów i standardowego procesu testowego w celu ustalenia typowych ról związanych z testowaniem

2.      Zidentyfikowanie zestawu funkcji związanych z testowaniem, które pozwalają obsłużyć typowe role testowe zgodnie z potrzebami

Przykładowe funkcje związane z testowaniem:

•      Kierownik testów

•      Lider zespołu testowego

•      Projektant testów

•      Inżynier testów

•      Konsultant ds. testów

•      Inżynier ds. środowiska testowego

3.      Zidentyfikowanie funkcji związanych z testowaniem dla odpowiednich obszarów specjalistycznych

Przykładowe funkcje związane z testowaniem dla obszarów specjalistycznych:

•      Architekt testów automatycznych

•      Inżynier testów automatycznych

•      Inżynier testów wydajności

•      Inżynier testów użyteczności

•      Kierownik ds. doskonalenia procesu testowego

SP 2.2       Opracowanie opisu stanowisk

Dla zidentyfikowanych funkcji związanych z testowaniem opracowywane są opisy stanowisk. W przypadku osób niebędących specjalistami ds. testów dotychczasowe opisy stanowisk są rozszerzane o opis typowych zadań i obowiązków związanych z testowaniem.

Przykładowe produkty pracy

1.      Opisy stanowisk dla funkcji związanych z testowaniem

2.      Rozszerzone opisy stanowisk dla osób niebędących specjalistami ds. testów

Podpraktyki

1.      Zdefiniowanie opisu stanowiska dla wszystkich zidentyfikowanych funkcji związanych

z testowaniem

Informacje umieszczane zwykle w opisie stanowiska:

•      Nazwa funkcji związanej z testowaniem

•      Krótki opis

•      Skala wynagrodzeń

•      Kwalifikacje

•      Typowe zadania

•      Obowiązki i uprawnienia

•      Wymagana wiedza i umiejętności

•      Wymagania dotyczące wykształcenia

•      Moduły szkoleń do ukończenia

2.      Uwzględnienie opisów stanowisk w środowisku zarządzania kadrami organizacji

3.      Rozszerzenie opisów stanowisk dla innych kategorii (tj. osób niebędących specjalistami ds. testów) z uwzględnieniem odpowiednich zadań i obowiązków związanych

z testowaniem

Przykładowe kategorie stanowisk osób niebędących specjalistami ds. testów, z którymi zwykle wiążą się pewne działania i obowiązki w zakresie testów:

•      Programista

•      Inżynier systemów

•      Integrator systemów

•      Przedstawiciel użytkowników

4.      Wykorzystanie standardowego procesu testowego organizacji jako ważnego źródła informacji umożliwiającego zdefiniowanie i rozszerzenie opisów stanowisk

5.      Przegląd opisów stanowisk z udziałem interesariuszy

6.      Aktualizacja opisów stanowisk zgodnie z potrzebami

SP 2.3       Przypisanie pracowników do funkcji związanych z testowaniem

Członkowie organizacji testowej są przypisywani do zidentyfikowanych funkcji związanych

z testowaniem.

Przykładowe produkty pracy

1.      Lista pracowników przypisanych do funkcji związanych z testowaniem (z określonym stanowiskiem)

Podpraktyki

1.      Przypisanie pracowników do funkcji związanych z testowaniem

2.      Przeprowadzenie rozmów kwalifikacyjnych w celu obsadzenia wakatów specjalistów

ds. testów, z wykorzystaniem kwestionariuszy umożliwiających określenie kompetencji technicznych poszczególnych osób oraz ich zdolności i motywacji

3.      Utrzymywanie obsady stanowisk (funkcji) specjalistów ds. testów

4.      Okresowa ocena pracy członków organizacji testowej

5.      Podejmowanie odpowiednich działań na podstawie oceny, jeśli są konieczne

SG 3       Określenie ścieżek rozwoju związanych z testowaniem

Określane są ścieżki rozwoju związane z testowaniem, umożliwiające testerom poszerzenie wiedzy, zwiększenie kwalifikacji, podniesienie statusu i uzyskanie dodatkowych korzyści.

SP 3.1       Zdefiniowanie ścieżek rozwoju związanych z testowaniem

Określane są ścieżki rozwoju związane z testowaniem, umożliwiające testerom rozwój zawodowy.

Przykładowe produkty pracy

1.      Struktura ścieżek rozwoju zawodowego związanych z testowaniem

Podpraktyki

1.      Podział funkcji związanych z testowaniem na role pracowników o krótszym, średnim

i długim stażu

2.      Powiązanie wymaganej wiedzy i umiejętności, typowych zadań i obowiązków, modułów szkoleniowych i poziomu doświadczenia z rolami pracowników o krótszym, średnim

i długim stażu w ramach poszczególnych funkcji związanych z testowaniem

3.      Zdefiniowanie opisu stanowiska dla wszystkich zidentyfikowanych poziomów funkcji związanych z testowaniem

4.      Umieszczenie zdefiniowanych i podzielonych na poziomy funkcji związanych

z testowaniem w (hierarchicznej) strukturze ścieżek rozwoju

5.      Zdefiniowanie typowych ram czasowych określających możliwość przejścia do kolejnego etapu ścieżki rozwoju

6.      Powiązanie struktury ścieżek rozwoju związanych z testowaniem z innymi strukturami ścieżek rozwoju zawodowego w organizacji (np. informacja, w jaki sposób kierownik testów może zostać kierownikiem projektu)

7.      Uwzględnienie struktury ścieżek rozwoju zawodowego związanych z testowaniem

w środowisku zarządzania kadrami organizacji

SP 3.2       Opracowanie indywidualnych planów rozwoju związanych z testowaniem

Dla każdego członka organizacji testowej opracowywane są i utrzymywane indywidualne plany rozwoju związane z testowaniem.

Przykładowe produkty pracy

1. Indywidualne plany rozwoju

Podpraktyki

1.      Utworzenie indywidualnych planów rozwoju opartych na strukturze ścieżek rozwoju zawodowego związanych z testowaniem

2.      Okresowe przeglądy indywidualnych planów rozwoju z udziałem poszczególnych testerów

3.      Określenie i udokumentowanie działań niezbędnych do rozwoju zawodowego poszczególnych członków zespołu

4.      Śledzenie realizacji zdefiniowanych działań związanych z rozwojem zawodowym do ich zakończenia

5.      Aktualizacja indywidualnych planów rozwoju zgodnie z potrzebami

SG 4       Określenie, zaplanowanie i wdrożenie usprawnień procesu testowego

Okresowo i w miarę bieżących potrzeb identyfikowane są silne i słabe strony oraz możliwości udoskonalenia procesu testowego. Zmiany w procesie uwzględniające odpowiednie usprawnienia są planowane i wdrażane.

SP 4.1       Ocena procesu testowego w organizacji

Proces testowy w organizacji podlega okresowej ocenie w celu przeanalizowania jego silnych i słabych stron.

Przykładowe produkty pracy

1.      Raport z oceny procesu testowego

Podpraktyki

1.      Ustalenie potrzeb związanych z procesem testowym w organizacji na podstawie zdefiniowanych celów biznesowych i polityki biznesowej, celów i polityki testowania oraz strategii testów

2.      Uzyskanie wsparcia sponsorskiego dla ocen procesu testowego od kierownictwa wyższego szczebla

3.      Zdefiniowanie zakresu oceny procesu testowego

4.      Zaplanowanie, stworzenie harmonogramu i przygotowanie oceny procesu testowego

5.      Przeprowadzenie oceny procesu testowego

6.      Udokumentowanie i prezentacja raportu z oceny procesu testowego

SP 4.2      Zidentyfikowanie możliwości udoskonalenia procesu testowego

w organizacji

Identyfikowane są pożądane usprawnienia w procesie testowym organizacji i zasobach tego procesu.

Przykładowe produkty pracy

1.       Lista usprawnień procesu testowego z określonymi priorytetami

Podpraktyki

1.      Ustalenie możliwości udoskonalenia procesu testowego na podstawie raportu z oceny procesu testowego lub innych źródeł

2.      Określenie priorytetów potencjalnych usprawnień procesu testowego

Przykładowe czynniki, które mogą okazać się przydatne podczas określania priorytetów usprawnień:

•      Zgodność z celami biznesowymi i celami testów

•      Zgodność z modelem dojrzałości

•      Wyższy priorytet w przypadku najbardziej widocznych usprawnień w celu zwrócenia na nie uwagi i uzyskania akceptacji

•      Określenie wymiernych i czytelnych korzyści biznesowych

•      Oszacowanie kosztów i pracochłonności zmian

•      Poziom trudności

•      Stopień akceptacji

•      Łagodzone ryzyka

3.      Omówienie i przegląd listy usprawnień z określonymi priorytetami z udziałem głównych interesariuszy

4.      Zidentyfikowanie i udokumentowanie usprawnień procesu testowego, które zostaną wdrożone

5.      Aktualizowanie listy planowanych usprawnień procesu testowego

SP 4.3       Zaplanowanie usprawnień procesu testowego

Planowane są działania niezbędne do wprowadzenia usprawnień w procesie testowym organizacji i zasobach tego procesu.

Przykładowe produkty pracy

1.      Plan doskonalenia procesu testowego

Podpraktyki

1.      Określenie strategii, metod i działań niezbędnych do realizacji zidentyfikowanych usprawnień procesu testowego (np. wszystkie nowe i niesprawdzone elementy oraz duże zmiany podlegają pilotażowi przed ich uwzględnieniem w normalnym procesie)

2.      Ustanowienie zespołów zadaniowych w celu zdefiniowania i wdrożenia usprawnień

w procesie testowym

3.      Udokumentowanie planu doskonalenia procesu testowego

Przykładowe elementy planu doskonalenia procesu testowego:

•      Cele doskonalenia procesu testowego

•      Struktura organizacyjna doskonalenia procesu testowego

•      Usprawnienia procesu testowego, które zostaną wdrożone

•      Procedury monitorowania i kontroli

•      Strategie pilotażu i wdrażania usprawnień procesu testowego

•      Obowiązki i uprawnienia

•      Zasoby i harmonogramy

•      Sposoby mierzenia skuteczności usprawnień procesu testowego

•      Ryzyko związane z planem doskonalenia procesu testowego

4.      Przegląd i negocjowanie planu doskonalenia procesu testowego z interesariuszami

(w tym członkami zespołów zadaniowych)

5.      Przegląd i aktualizacja planu doskonalenia procesu testowego zgodnie z potrzebami

SP 4.4       Wdrożenie usprawnień procesu testowego

Usprawnienia procesu testowego uwzględnione w planie doskonalenia testów podlegają wdrożeniu.

Przykładowe produkty pracy

1.      Status i rezultaty wdrożenia usprawnień procesu testowego

2.      Plany pilotażu usprawnień procesu testowego

Podpraktyki

1.      Śledzenie postępu realizacji i zobowiązań w odniesieniu do planu doskonalenie procesu testowego

2.      Zaplanowanie i uruchomienie niezbędnych projektów pilotażowych w celu przetestowania wybranych usprawnień

3.      Ocena rezultatów projektów pilotażowych w odniesieniu do planu z udziałem interesariuszy

4.      Przegląd działań i produktów pracy zespołów zadaniowych

5.      Identyfikowanie, dokumentowanie i śledzenie aż do rozwiązania problemów związanych z wdrożeniem planu doskonalenia testów

6.      Zapewnienie zgodności rezultatów wdrożenia usprawnień procesu testowego

z przyjętymi celami

7.      Poinformowanie szerszego grona odbiorców o rezultatach doskonalenia procesu testowego

SG 5       Wdrożenie procesu testowego w organizacji i uwzględnienie wyciągniętych wniosków

Standardowy proces testowy i związane z nim zasoby są wdrażane w całej organizacji,

a doświadczenia związane z testowaniem są uwzględniane w procesie i zasobach.

Praktyki szczegółowe w ramach tego celu szczegółowego opisują działania o charakterze ciągłym. Wdrażanie standardowego procesu testowego i innych zasobów związanych

z procesem testowym w organizacji musi być realizowane przez cały czas, zwłaszcza

w przypadku rozpoczynania nowych projektów.

SP 5.1       Wdrożenie standardowego procesu testowego i związanych z nim zasobów

Standardowy proces testowy i związane z nim zasoby są wdrażane w całej organizacji, zwłaszcza w rozpoczynanych projektach. Odpowiednie zmiany są wdrażane podczas realizacji poszczególnych projektów.

Istotne jest, aby we wdrożeniu uczestniczyły nie tylko osoby, które biorą albo będą brały udział w realizacji procesu testowego, ale w miarę potrzeby także przedstawiciele innych działów, np. szkoleń oraz zapewnienia jakości.

Przykładowe produkty pracy

1.      Plan wdrożenia

2.      Dokumentacja zmian w standardowym procesie testowym organizacji i związanych

z nim zasobach

3.      Lista projektów realizowanych w organizacji i status wdrożenia procesu testowego

w poszczególnych projektach

4.      Wytyczne dotyczące wdrożenia i inne materiały pomocnicze, np. szkolenia

5.      Informacje na temat ewentualnych modyfikacji standardowego procesu testowego organizacji w danym projekcie

Podpraktyki

1.      Zidentyfikowanie rozpoczynających się projektów w organizacji

2.      Zidentyfikowanie aktywnych projektów, w których wdrożenie standardowego procesu testowego organizacji i związanych z nim zasobów (albo wprowadzonych w procesie zmian) mogłoby okazać się korzystne

3.      Określenie planów wdrożenia standardowego procesu testowego organizacji

i związanych z nim zasobów we wskazanych projektach

4.      Udokumentowanie zmian w standardowym procesie testowym organizacji i związanych z nim zasobach w celu przekazania informacji o wprowadzonych zmianach

5.      Zapewnienie dostępności szkoleń dla osób, które chcą korzystać ze standardowego procesu testowego i związanych z nim zasobów

6.      Udzielanie wskazówek i konsultacji dotyczących używania standardowego procesu testowego i związanych z nim zasobów

7.      Udzielanie pomocy w trakcie dostosowywania standardowego procesu testowego organizacji i związanych z nim zasobów w celu zaspokojenia potrzeb konkretnych projektów

8.      Przechowywanie informacji o dostosowaniach i wdrażaniu procesów we wskazanych projektach oraz uwzględnienie rezultatów dostosowywania procesu testowego w planie na potrzeby oceny zgodności procesów (patrz opis praktyki SP 5.2 Monitorowanie wdrożenia)

9.      W przypadku aktualizowania standardowego procesu testowego organizacji: identyfikowanie projektów, w których należy wdrożyć odpowiednie zmiany

W opisie obszaru procesowego Cykl życia i integracja testów można znaleźć więcej informacji na temat wsparcia wdrożenia zasobów związanych z procesem testowym organizacji przez bibliotekę zasobów procesu testowego.

SP 5.2       Monitorowanie wdrożenia

Wdrożenie standardowego procesu testowego organizacji i wykorzystanie zasobów procesu testowego w projektach podlegają monitorowaniu.

Przykładowe produkty pracy

1.      Rezultaty monitorowania wdrożenia procesu testowego w projektach

2.      Status i rezultaty ocen zgodności procesów testowych

3.      Rezultaty przeglądu wybranych artefaktów procesu testowego utworzonych w ramach dostosowywania i wdrażania procesu

Podpraktyki

1.      Monitorowanie projektów pod kątem wykorzystania procesu testowego organizacji

i związanych z nim zasobów oraz wprowadzonych zmian

2.      Przegląd wybranych artefaktów procesu testowego utworzonych w trakcie projektu prowadzony w celu zapewnienia zgodności

3.      Przegląd rezultatów ocen zgodności procesów testowych w celu ustalenia poziomu wdrożenia standardowego procesu testowego organizacji i związanych z nim zasobów

4.      Identyfikowanie, dokumentowanie i śledzenie aż do rozwiązania problemów związanych z wdrożeniem standardowego procesu testowego organizacji

SP 5.3       Uwzględnienie wniosków wyciągniętych z poprzednich projektów w procesie testowym organizacji

Wnioski wyciągnięte z planowania i realizacji procesu testowego są uwzględniane

w standardowym procesie testowym organizacji i związanych z nim zasobach.

Przykładowe produkty pracy

1.      Przegląd rezultatów pod kątem skuteczności i przydatności standardowego procesu testowego i związanych z nim zasobów

2.      Dokumenty dotyczące wyciągniętych wniosków (np. sumaryczne raporty z testów)

3.      Propozycje udoskonaleń procesu testowego

4.      Rejestr podjętych działań związanych z doskonaleniem procesu testowego organizacji

Podpraktyki

1.      Prowadzenie okresowych przeglądów skuteczności i przydatności standardowego procesu testowego organizacji i związanych z nim zasobów pod kątem realizacji celów biznesowych, celów testowania, polityki testów i strategii testów

2.      Uzyskanie informacji zwrotnych na temat wykorzystania standardowego procesu testowego organizacji i zasobów procesu

3.      Wyciągnięcie wniosków z definiowania, pilotażu, wdrożenia i zastosowania standardowego procesu testowego organizacji i zasobów procesu

4.      Udostępnienie wyciągniętych wniosków odpowiednim osobom w organizacji

Wnioski wyciągnięte w projekcie zwykle są dokumentowane w sumarycznym raporcie

z testów [ISO 29119-3].

5.      Zidentyfikowanie potencjalnych najlepszych praktyk, które warto udostępnić w innych projektach i zapisać w bibliotece zasobów procesu testowego w organizacji w celu ponownego wykorzystania

6.      Analiza wskaźników wydajności testów w organizacji i wspólnego zestawu miar testowych

7.      Opracowanie propozycji udoskonaleń procesu testowego i usprawnienia procesu tworzenia oprogramowania na podstawie zgromadzonych i przeanalizowanych informacji

8.      Przedstawienie propozycji udoskonaleń procesu tworzenia oprogramowania

9.      Zarządzanie propozycjami udoskonaleń procesu testowego

Przykładowe działania związane z zarządzaniem propozycjami udoskonaleń procesu testowego:

•      Prośba o zgłaszanie propozycji udoskonaleń procesu testowego

•      Gromadzenie propozycji udoskonaleń procesu testowego

•      Przegląd propozycji udoskonaleń procesu testowego

•      Wybór propozycji udoskonaleń procesu testowego, które zostaną wdrożone

•      Śledzenie wdrożenia propozycji udoskonaleń procesu testowego

10.      Utworzenie i utrzymywanie rejestru działań związanych z doskonaleniem procesu testowego w organizacji

Praktyki ogólne dla poszczególnych celów

GG 2      Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Organizacja testowa.

Opracowanie

Polityka dotycząca organizacji testowej zwykle zawiera następujące ustalenia:

•      Grupa testowa jest traktowana jako jednostka organizacyjna

•      Zadania i obowiązki grupy testowej oraz jej miejsce w ogólnej strukturze organizacji

•      Stopień niezależności grupy testowej w ramach organizacji i w stosunku do projektów

•      Testowanie jest uznawane za specjalistyczną dziedzinę

•      Funkcje związane z testowaniem i ścieżki rozwoju zawodowego są zidentyfikowane

i zinstytucjonalizowane

Przykładowe funkcje związane z testowaniem:

•      Kierownik testów

•      Lider zespołu testowego

•      Projektant testów

•      Inżynier testów

•      Konsultant ds. testów

•      Inżynier ds. środowiska testowego

•      Standardowy proces testowy (wraz z szablonami) zdefiniowany i zarządzany przez organizację testową jest konsekwentnie stosowany

•      Podejście do metryk testów, testowych baz danych, narzędzi testowych i ponownego wykorzystania testów

•      Czynności testowe, których realizację wspiera i/lub koordynuje w projektach organizacja testowa

•      Sumaryczny raport z testów (wyciągnięte wnioski), który każdy z projektów (testowania) powinien dostarczyć na potrzeby doskonalenia standardowego procesu testowego

•      Cele i struktura organizacyjna związana z doskonaleniem procesu testowego

•      Podejście do planowania, implementacji i wdrażania usprawnień procesu testowego

w organizacji

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Organizacja testowa.

Opracowanie

Plan, o którym mowa w tej praktyce ogólnej, tworzy się w celu kompleksowego zaplanowania wszystkich praktyk szczegółowych z tego obszaru procesowego wymaganych do realizacji celów szczegółowych.

Z kolei tworzenie Planu doskonalenia procesu testowego Poziom agregacji elementów i funkcji podlegających testowaniu w przypadku

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Organizacja testowa, wytworzenia produktów pracy związanych z testowaniem oraz realizacji usług związanych

z procesem.

Opracowanie

•      Dostępny jest roczny budżet przeznaczony na działania organizacyjne związane

z testowaniem, np. na doskonalenie procesu testowego

•      Dostępne są odpowiednia infrastruktura i narzędzia umożliwiające prowadzenie działań organizacyjnych związanych z testowaniem

•      Organizacja testowa ma dostęp do w pełni funkcjonalnego środowiska i infrastruktury biurowej

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Organizacja testowa, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Organizacja testowa.

Opracowanie

Do zarządzania grupą testową wyznaczany jest kierownik. Zarządzanie standardowym procesem testowym często jest przydzielane kierownikowi ds. technologii testowania. Oprócz tego tworzony jest komitet sterujący zarządzający doskonaleniem procesu testowego

i odpowiedzialny za uzyskanie wsparcia sponsorskiego ze strony kierownictwa organizacji.

Przykładowe obowiązki związane z organizacją testową, które należy przydzielić:

•      Reprezentowanie grupy testowej wobec całej organizacji

•      Zarządzanie specjalistami ds. testów i ich ścieżkami rozwoju zawodowego

•      Zarządzanie procesem testowym i jego doskonalenie

•      Ułatwienie realizacji czynności testowych wykonywanych w projektach

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Organizacja testowa zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

•      Szkolenie dla działu kadr

•      Sesje oceny pracowników

•      Coaching specjalistów ds. testów

•      TMMi i inne wzorcowe modele doskonalenia procesów testowych

•      Planowanie doskonalenia procesu testowego i zarządzanie tym doskonaleniem

•      Zarządzanie zmianami

Należy zauważyć, że szkolenia dla inżynierów (testów) i kierowników (testów) w zakresie standardowego procesu testowego i pomocniczych narzędzi testowych zostały uwzględnione w obszarze procesowym Program szkoleń testerskich.

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Organizacja testowa odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Opis organizacji testowej

•      Opisy stanowisk dla funkcji związanych z testowaniem

•      Opisy ścieżek rozwoju zawodowego związanych z testowaniem

•      Indywidualne plany rozwoju

•      Raporty z oceny procesu testowego

•      Plany doskonalenia procesu testowego

•      Plany wdrożenia

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Organizacja testowa zgodnie z planem.

Opracowanie

Przykłady udziału interesariuszy:

•      Kierownictwo wyższego szczebla: przydział personelu do organizacji testowej

•      Dział kadr: wsparcie i uzgodnienia podczas opisywania funkcji związanych

z testowaniem i planów rozwoju zawodowego

•      Kierownik ds. doskonalenia procesów: uzgodnienia z innymi inicjatywami doskonalenia procesów (np. procesów tworzenia oprogramowania)

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Organizacja testowa (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Organizacja testowa:

•      Porównanie rzeczywistej liczby specjalistów ds. testów z planowaną liczbą dla poszczególnych funkcji związanych z testowaniem

•      Odsetek specjalistów ds. testów, w przypadku których istnieje indywidualny plan rozwoju zawodowego związany z testowaniem

•      Liczba zgłoszonych, zaakceptowanych i/lub wdrożonych propozycji udoskonaleń procesu testowego

•      Harmonogramy wdrożenia zasobów procesu testowego organizacji

•      Odsetek projektów korzystających z aktualnego zestawu standardowych procesów testowych organizacji (lub ich dostosowanych wersji)

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Organizacja testowa oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Wydajność działania organizacji testowej

•      Specjaliści ds. testów przypisani do zdefiniowanej funkcji

•      Plany rozwoju zawodowego

•      Planowanie i koordynowanie działań związanych z doskonaleniem procesu testowego

•      Wdrożenie zestawu standardowych procesów testowych organizacji w projektach

•      Plany doskonalenia procesu testowego

•      Plany wdrożenia procesu testowego

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Organizacja testowa z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

Opracowanie

Przykładowe zagadnienia, które należy omówić z kierownictwem wyższego szczebla:

•      Wydajność działania organizacji testowej

•      Liczba nieobsadzonych stanowisk związanych z testowaniem

•      Status usprawnień opracowywanych przez zespoły zadaniowe

•      Rezultaty projektów pilotażowych i wdrożeń

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Organizacja testowa

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, pozyskiwanych z planowania i realizacji procesu Organizacja testowa, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Liczba specjalistów ds. testów w organizacji testowej

•      Rotacja pracowników zajmujących się testowaniem

•      Stopień zastosowania standardowego procesu testowego

•      Wyniki oceny związane silnymi i słabymi stronami procesu testowego organizacji

•      Realizacja harmonogramu działań związanych z doskonaleniem procesu testowego.

PA 3.2       Program szkoleń testerskich

Cel

Celem obszaru procesowego Program szkoleń testerskich jest opracowanie programu szkoleń umożliwiających poszerzenie wiedzy i kwalifikacji pracowników, tak aby mogli oni skutecznie i wydajnie wykonywać zadania i wypełniać role związane z testowaniem.

Uwagi wstępne

Program szkoleń testerskich obejmuje szkolenia wspierające strategiczne cele biznesowe organizacji i zaspokajające potrzeby edukacyjne występujące w wielu projektach. Specyficzne wymagania w zakresie szkoleń pojawiające się w odrębnych projektach są realizowane na poziomie tych projektów. Obszar procesowy Program szkoleń testerskich jest ściśle powiązany i połączony zależnościami z obszarem Organizacja testowa. Jednym

z głównych celów obszaru Program szkoleń testerskich jest wsparcie organizacji testowej

w kształceniu specjalistów ds. testów i innych uczestniczących w testowaniu interesariuszy. Program szkoleń dotyczących jakości pozwala zapewnić ciągły rozwój kompetencji uczestników testów i poszerzyć ich wiedzę dziedzinową oraz wiadomości z innych obszarów związanych z testowaniem. Program szkoleń może być zorganizowany i zarządzany w ramach specjalnej grupy ds. szkoleń.

Ustanowienie programu szkoleń testerskich stanowi dodatkowe zobowiązanie ze strony kierownictwa do budowy zespołu testowego o wysokich kwalifikacjach i wspierania ciągłego doskonalenia procesu testowego. Podczas testowania niezbędne są kwalifikacje różnego rodzaju. Główne kategorie to zasady testowania, techniki testowania, zarządzanie testami, narzędzia testowe, wiedza z danej dziedziny, wiedza informatyczna, inżynieria systemów, tworzenie oprogramowania i umiejętności interpersonalne. Program szkoleń testerskich składa się z pewnej liczby modułów szkoleniowych i tworzy się go tak, aby uwzględniał powyższe kategorie. Na wyższych poziomach TMMi istotne stają się inne, bardziej zaawansowane kategorie, np. zapobieganie defektom na poziomie TMMi 5. Niektóre kompetencje można w skuteczny i efektywny sposób przekazać metodami nieformalnymi (takimi jak szkolenie na stanowisku pracy albo mentoring), natomiast w przypadku innych obszarów wymagane jest formalne przeszkolenie.

Termin „szkolenie” używany w tym obszarze procesowym obejmuje wszystkie metody zdobywania kwalifikacji. Program szkoleń testerskich jest powiązany z funkcjami i rolami występującymi w ramach testowania, a także wspiera ścieżki rozwoju związane

z testowaniem. Wdrożenie programu szkoleń gwarantuje uzyskanie odpowiedniej wiedzy

i poziomu kwalifikacji przez wszystkie osoby uczestniczące w testach. Realizacja założeń obszaru Program szkoleń testerskich wiąże się z określeniem potrzeb organizacji związanych ze szkoleniami testerskimi, opracowaniem lub pozyskaniem odpowiednich modułów szkoleniowych, przeprowadzeniem szkoleń w celu zaspokojenia określonych potrzeb zgodnie z wymaganiami, a w końcu z oceną skuteczności programu szkoleniowego.

Zakres

Obszar procesowy Program szkoleń testerskich obejmuje zdefiniowanie planu szkoleń testerskich w organizacji oraz ustanowienie organizacyjnych możliwości prowadzenia takich szkoleń. Uwzględnia także samo prowadzenie zaplanowanych szkoleń. Potrzeby szkoleniowe specyficzne dla konkretnych projektów nie są przedmiotem działań z tego obszaru; zostały one uwzględnione w obszarze procesowym Planowanie testów.

Podsumowanie celów i praktyk szczegółowych

SG 1       Ustanowienie organizacyjnych możliwości prowadzenia szkoleń testerskich

SP 1.1      Określenie strategicznych potrzeb związanych ze szkoleniami testerskimi

SP 1.2      Uzgodnienie potrzeb związanych ze szkoleniami testerskimi na poziomie organizacji i projektu

SP 1.3       Zdefiniowanie organizacyjnego planu szkoleń testerskich

SP 1.4       Ustanowienie możliwości prowadzenia szkoleń testerskich

SG 2       Udostępnienie szkoleń testerskich

SP 2.1       Przeprowadzenie szkoleń testerskich

SP 2.2       Utworzenie rejestru szkoleń

SP 2.3       Ocena skuteczności szkoleń testerskich

Praktyki szczegółowe dla poszczególnych celów

SG 1       Ustanowienie organizacyjnych możliwości prowadzenia szkoleń testerskich

Ustanowienie i utrzymywanie możliwości prowadzenia szkoleń wspierających role związane

z testowaniem występujące w organizacji.

SP 1.1      Określenie strategicznych potrzeb związanych ze szkoleniami testerskimi

Następuje zidentyfikowanie strategicznych potrzeb organizacji związanych ze szkoleniami

w zakresie testowania, a informacje o nich podlegają zarządzaniu.

Przykładowe produkty pracy

1.      Lista potrzeb związanych ze szkoleniami

2.      Analiza oceny

Podpraktyki

1.      Analiza strategicznych celów biznesowych organizacji, polityki i strategii testów oraz planu doskonalenia procesów (testowych) w celu zidentyfikowania bieżących

i potencjalnych przyszłych potrzeb w zakresie szkoleń testerskich.

Przykładowe kategorie potrzeb związanych ze szkoleniami testerskimi:

•      Projektowanie testów i proces testowy (np. standardowy proces testowy organizacji, zasady testowania, cykl życia testów, techniki testowania statycznego, techniki testowania dynamicznego, narzędzia testowe i automatyzacja testów)

•      Zarządzanie testami (np. szacowanie testów, śledzenie i zarządzanie ryzykiem)

•      Szkolenia związane z technologiami informatycznymi (np. inżynieria wymagań, zarządzanie konfiguracją, zarządzanie projektami, inżynieria systemów, tworzenie oprogramowania, modele cyklu życia oprogramowania)

•      Umiejętności interpersonalne (np. komunikacja, tworzenie zespołu)

•      Wiedza specjalistyczna z odpowiednich dziedzin

Do określenia odpowiednich szkoleń związanych z testowaniem wykorzystywana jest lista kwalifikacji wymaganych do realizacji zestawu standardowych procesów testowych organizacji.

2.      Okresowa ocena poziomów kwalifikacji osób uczestniczących w testowaniu

3.      Udokumentowanie strategicznych potrzeb organizacji w zakresie szkoleń testerskich

4.      Odwzorowanie potrzeb szkoleniowych na funkcje związane z testowaniem (w tym ścieżki rozwoju) i role testowe występujące w organizacji

5.      Aktualizacja strategicznych potrzeb organizacji w zakresie szkoleń testerskich

w niezbędnym zakresie

SP 1.2       Uzgodnienie potrzeb związanych ze szkoleniami testerskimi na poziomie organizacji i projektu

Następuje uzgodnienie potrzeb związanych ze szkoleniami testerskimi na poziomie organizacji i projektu. Ustala się przy tym, które potrzeby powinny być zaspokajane przez organizację,

a za które odpowiadają poszczególne projekty.

Personel szkoleniowy organizacji odpowiada za zaspokojenie wspólnych potrzeb występujących w wielu projektach. Jednak w pewnych sytuacjach może się on również zajmować realizacją dodatkowych wymagań w zakresie szkoleń testerskich występujących

w projektach (w kontekście zasobów szkoleniowych i priorytetów szkoleniowych organizacji).

Przykładowe produkty pracy

1.      Wspólne potrzeby związane ze szkoleniami testerskimi

2.      Zobowiązania dotyczące szkoleń testerskich w projektach

Podpraktyki

1.      Analiza potrzeb związanych ze szkoleniami testerskimi zidentyfikowanych w różnych projektach

Celem analizy potrzeb konkretnych projektów jest określenie wspólnego zestawu potrzeb szkoleniowych, które w najbardziej efektywny sposób można zaspokoić na poziomie całej organizacji. Taka analiza może również stanowić okazję do prognozowania przyszłych potrzeb w zakresie szkoleń testerskich, ponieważ nowe potrzeby pojawiają na poziomie projektów.

2.      Ustalenie, czy potrzeby zgłaszane przez różne projekty dotyczą tylko tych projektów, czy są wspólne dla całej organizacji

Do zarządzania potrzebami związanymi ze szkoleniami testerskimi wspólnymi dla całej organizacji stosowany jest na ogół organizacyjny program szkoleń testerskich.

3.      Negocjowanie z przedstawicielami różnych projektów możliwości zaspokojenia ich potrzeb szkoleniowych

Przykłady szkoleń prowadzonych w ramach projektu:

•      Szkolenie dotyczące dziedziny aplikacji w danym projekcie

•      Szkolenie dotyczące specyficznych narzędzi i metod używanych w projekcie

4.       Udokumentowanie zobowiązań dotyczących wsparcia projektów w zakresie szkoleń testerskich

Więcej informacji na temat planów szkoleń związanych z projektami zawiera opis praktyki SP 4.2 Zaplanowanie obsady kadrowej testów z obszaru procesowego Planowanie testów.

SP 1.3       Zdefiniowanie organizacyjnego planu szkoleń testerskich

Tworzony i utrzymywany jest organizacyjny plan szkoleń testerskich.

W wielu organizacjach takie planowanie wykonuje się raz do roku, a co kwartał odbywa się przegląd planu.

Przykładowe produkty pracy

1.      Plan szkoleń testerskich

2.      Zobowiązania dotyczące szkoleń testerskich

Podpraktyki

1.      Określenie zawartości planu szkoleń testerskich

Przykładowe elementy organizacyjnego planu szkoleń testerskich:

•      Tematy szkoleń testerskich

•      Harmonogramy uwzględniające działania szkoleniowe i ich zależności

•      Metody prowadzenia szkoleń

•      Wymagania i standardy jakości dotyczące materiałów szkoleniowych

•      Zadania, role i obowiązki związane ze szkoleniami

•      Wymagane zasoby, w tym narzędzia, infrastruktura, środowiska i obsada kadrowa

•      Wymagane kwalifikacje i wiedza trenerów

•      Dane, które należy gromadzić w celu pomiaru skuteczności szkoleń

2.      Przegląd planu szkoleń testerskich z udziałem odpowiednich grup i osób, np. przedstawicieli działu kadr, testerów i kierowników projektów

3.      Zdefiniowanie zobowiązań dotyczących realizacji planu szkoleń testerskich

4.      Aktualizowanie planu szkoleń testerskich i zobowiązań zgodnie z potrzebami

SP 1.4       Ustanowienie możliwości prowadzenia szkoleń testerskich

Ustanowienie i utrzymywanie możliwości szkoleń testerskich w celu zaspokojenia potrzeb szkoleniowych organizacji w zakresie testowania oraz wsparcia potrzeb szkoleniowych konkretnych projektów.

Przykładowe produkty pracy

1.       Materiały szkoleniowe i artefakty pomocnicze

Podpraktyki

1.       Wybór odpowiednich metod w celu zaspokojenia konkretnych potrzeb związanych ze szkoleniami testerskimi

Przykładowe metody prowadzenia szkoleń:

•      Szkolenia stacjonarne

•      Nauczanie wspomagane komputerowo

•      Samodzielna nauka pod nadzorem

•      Formalne programy stażu i mentoringu

•      Nieformalne seminaria

•      Ustrukturyzowane szkolenie w miejscu pracy

2.      Ustalenie, czy materiały szkoleniowe związane ze szkoleniami testerskimi należy opracować we własnym zakresie, czy pozyskać na zewnątrz

Przykładowe kryteria umożliwiające wybór najbardziej efektywnego sposobu pozyskiwania wiedzy i kompetencji:

•      Czas dostępny na przygotowanie materiałów szkoleniowych

•      Dostępność wiedzy specjalistycznej wewnątrz organizacji

•      Dostępność szkoleń (materiałów) pochodzących z zewnętrznych źródeł

•      Dostępny budżet

•      Czas wymagany na aktualizowanie materiałów szkoleniowych

3.      Opracowanie lub pozyskanie materiałów szkoleniowych z zakresu testowania

4.      Przygotowanie lub pozyskanie wykwalifikowanych trenerów

5.      Umieszczenie opisu szkoleń w programie szkoleń testerskich organizacji

Przykładowe informacje umieszczane w opisach poszczególnych szkoleń testerskich:

•      Cele szkolenia

•      Zagadnienia omawiane w trakcie szkolenia

•      Docelowi odbiorcy

•      Wymagania wstępne, np. ukończenie innych szkoleń i doświadczenie

•      Przygotowanie do udziału w szkoleniu

•      Czas trwania szkolenia

•      Plany zajęć

•      Kryteria ukończenia szkolenia

6.      Aktualizacja materiałów szkoleniowych z zakresu testowania i artefaktów pomocniczych zgodnie z potrzebami

Przykłady sytuacji, w których może okazać się niezbędna aktualizacja materiałów szkoleniowych z zakresu testowania i artefaktów pomocniczych:

•      Zmiany potrzeb związanych ze szkoleniami testerskimi (np. dostępność nowej technologii powiązanej z tematem szkolenia)

•      Stwierdzenie potrzeby wprowadzenia zmiany w trakcie oceny szkolenia (np. w wyniku analizy kwestionariuszy dotyczących skuteczności szkolenia, ocen wyników programu szkoleń lub formularzy oceny trenerów)

SG 2       Udostępnienie szkoleń testerskich

Szkolenia niezbędne do efektywnego wypełniania ról w projektach udostępniane są testerom i innym osobom uczestniczącym w testowaniu.

W trakcie wyboru potencjalnych uczestników szkoleń warto zastanowić się nad potrzebą uzyskania przez menedżerów informacji o podstawowych zasadach testowania i strategii testów, nabycia umiejętności prowadzenia testów modułowych i integracyjnych przez programistów, uzyskania przez użytkowników możliwości udziału w testach akceptacyjnych itd.

SP 2.1      Przeprowadzenie szkoleń testerskich

Szkolenia są prowadzone zgodnie z planem szkoleń testerskich organizacji.

Przykładowe produkty pracy

1.       Przeprowadzone szkolenie

2.      Wypełnione formularze oceny szkolenia

Podpraktyki

1.      Wybór osób, które odbędą szkolenie niezbędne do efektywnego wypełniania roli związanej z testowaniem

Osoby, które już dysponują wiedzą i kwalifikacjami niezbędnymi do skutecznego wypełniania odpowiedniej roli, mogą zostać zwolnione z obowiązku wzięcia udziału w szkoleniu. Należy dopilnować, by prawo do takiego zwolnienia nie było nadużywane.

2.      Zaplanowanie szkolenia z uwzględnieniem wszelkich wymaganych zasobów (np. infrastruktury i instruktorów)

3.      Przeprowadzenie szkolenia

4.      Zebranie formularzy oceny szkolenia wypełnionych przez uczestników

5.      Śledzenie realizacji szkolenia w odniesieniu do planu

SP 2.2      Utworzenie rejestru szkoleń

Tworzone są i zapisywane informacje o przeprowadzonych w organizacji szkoleniach testerskich.

Zakres tego obszaru procesowego obejmuje w zasadzie szkolenia testerskie prowadzone na poziomie organizacji, jednak w celu uzyskania spójnych i pełnych informacji o wszystkich pracownikach rejestr szkoleń powinien uwzględniać wszystkie kursy, tj. zarówno na poziomie organizacji, jak i projektu.

Przykładowe produkty pracy

1.      Rejestr szkoleń testerskich

2.      Aktualizacje informacji o szkoleniach w repozytorium organizacji

Podpraktyki

1.      Przechowywanie informacji o wszystkich pracownikach, którzy pomyślnie ukończyli kurs lub inne działania szkoleniowe, a także o pracownikach, którym nie udało się ukończyć danego szkolenia

2.      Przechowywanie informacji o wszystkich pracownikach, którzy zostali zwolnieni

z obowiązku uczestnictwa w danym szkoleniu, wraz z uzasadnieniem i zgodą kierownictwa

3.      Udostępnienie rejestrów szkoleń odpowiednim osobom w celu wykorzystania tych danych podczas przydzielania zadań, np. w postaci macierzy kompetencji

z podsumowaniem informacji o doświadczeniu i odbytych przez pracowników szkoleniach

SP 2.3       Ocena skuteczności szkoleń testerskich

Skuteczność programu szkoleń testerskich w organizacji podlega ocenie.

Na podstawie wyników ocen skuteczności programu testerskiego należy odpowiednio zaktualizować treść materiałów szkoleniowych, zgodnie z opisem praktyki szczegółowej „Ustanowienie możliwości prowadzenia szkoleń testerskich”.

Przykładowe produkty pracy

1.      Kwestionariusze dotyczące skuteczności szkolenia

2.      Oceny wyników programu szkoleń

3.      Wyniki egzaminów po szkoleniach

Podpraktyki

1.      Ocena projektów w toku lub projektów zakończonych w celu ustalenia, czy pracownicy dysponują wiedzą umożliwiającą wykonywanie w projekcie zadań związanych

z testowaniem

2.      Ocena skuteczności poszczególnych szkoleń pod kątem realizacji organizacyjnych, projektowych lub indywidualnych celów nauczania

3.      Uzyskanie od uczestników szkoleń informacji o tym, do jakiego stopnia szkolenia spełniły ich oczekiwania

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu organizacyjnego Program szkoleń testerskich.

Opracowanie

Polityka dotycząca szkoleń testerskich zwykle zawiera następujące ustalenia:

•      Wiedza i kompetencje niezbędne do wykonywania funkcji i ról związanych z testowaniem

•      Metody szkoleniowe stosowane do przekazywania wiedzy i kompetencji

•      Szkolenia testerskie służą budowaniu wiedzy i zestawu kompetencji związanych

z testowaniem, zaspokajaniu potrzeb projektów oraz rozwojowi kwalifikacji poszczególnych osób

•      Ustanawiana jest wewnętrzna grupa szkoleniowa

•      Szkolenia testerskie są opracowywane w ramach organizacji lub pozyskiwane na zewnątrz, jeśli zachodzi taka potrzeba

•      W szkoleniach testerskich mogą brać udział także przedstawiciele strony biznesowej, projektanci oprogramowania, integratorzy i architekci, którzy mają w ramach projektu rolę związaną z testowaniem

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu organizacyjnego Program szkoleń testerskich.

Opracowanie

Plan realizacji procesu Program szkoleń testerskich jest innym dokumentem niż omawiany

w odpowiedniej praktyce szczegółowej plan szkoleń testerskich. Plan związany z tą praktyką ogólną obejmuje kompleksowe planowanie wszystkich praktyk szczegółowych wskazanych

w obszarze procesowym, począwszy od określenia strategicznych potrzeb w zakresie szkoleń testerskich, a skończywszy na ocenie skuteczności działań szkoleniowych. Z kolei plan szkoleń testerskich służy do okresowego zaplanowania prac związanych z prowadzeniem poszczególnych szkoleń.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu organizacyjnego Program szkoleń testerskich, wytworzenia produktów pracy oraz realizacji usług związanych

z procesem.

Opracowanie

•      Dostępny jest roczny budżet przeznaczony na szkolenia testerskie

•      Dostępne są osoby o odpowiednich kwalifikacjach, np. personel szkoleniowy organizacji

Przykłady osób (pracowników pełnoetatowych lub zatrudnionych w niepełnym wymiarze czasowym, wewnętrznych lub zewnętrznych) o odpowiednich kwalifikacjach:

•      Specjaliści ds. testów

•      Eksperci merytoryczni

•      Projektanci programu nauczania

•      Projektanci szkoleń

•      Trenerzy

•      Administratorzy szkoleń

•      Dostępne są odpowiednia infrastruktura i narzędzia umożliwiające przeprowadzenie szkoleń

Przykłady infrastruktury i narzędzi:

•      Sale szkoleniowe z wyposażeniem

•      Stacje robocze używane w trakcie szkoleń

•      Pakiety do szkoleń komputerowych

•      Pakiety do tworzenia materiałów prezentacyjnych

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu organizacyjnego Program szkoleń testerskich, wytworzenia produktów pracy oraz realizacji usług związanych

z procesem Program szkoleń testerskich.

Opracowanie

Wyznaczana jest grupa osób (lub osoba) odpowiedzialna za opracowanie programu szkoleń testerskich, zarządzanie tym programem i jego koordynowanie. Może to być np. dział szkoleń lub koordynator ds. szkoleń w organizacji albo dział kadr.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Program szkoleń testerskich zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

•      Analiza potrzeb dotyczących wiedzy i kompetencji

•      Projektowanie szkoleń

•      Techniki/metody prowadzenia szkoleń

•      Szkolenie utrwalające wiedzę specjalistyczną z danej dziedziny

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie organizacyjnym Program szkoleń testerskich odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Plan szkoleń testerskich

•      Rejestry szkoleń

•      Materiały szkoleniowe i artefakty pomocnicze

•      Formularze oceny

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu organizacyjnego Program szkoleń testerskich zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Określenie potrzeb związanych ze szkoleniami testerskimi

•      Przegląd planu szkoleń testerskich

•      Ocena skuteczności szkoleń testerskich

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu organizacyjnego Program szkoleń testerskich (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu organizacyjnego Program szkoleń testerskich:

•      Liczba przeprowadzonych szkoleń (np. porównanie liczby zaplanowanych i faktycznie zrealizowanych szkoleń)

•      Porównanie rzeczywistej liczby uczestników każdego ze szkoleń z przewidywaną liczbą uczestników

•      Harmonogram szkoleń

•      Harmonogram przygotowania szkoleń

•      Koszty szkoleń w odniesieniu do przydzielonego budżetu

•      Postęp w opracowywaniu i prowadzeniu szkoleń w odniesieniu do udokumentowanych potrzeb związanych ze szkoleniami testerskimi

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu organizacyjnego Program szkoleń testerskich oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Proces tworzenia i aktualizacji planu szkoleń

•      Proces tworzenia i aktualizacji szkoleń

•      Prowadzenie niezbędnych szkoleń testerskich

•      Plan szkoleń testerskich

•      Rejestr szkoleń testerskich

•      Materiały szkoleniowe i artefakty pomocnicze

•      Formularze oceny trenerów i uczestników

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu organizacyjnego Programu szkoleń testerskich z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

Opracowanie

Przykładowe zagadnienia, które należy omówić z kierownictwem wyższego szczebla:

•      Skuteczność programu szkoleń testerskich

•      Postęp realizacji działań związanych ze szkoleniami testerskimi

•      Koszty szkoleń testerskich

•      Realizacja działań przez podwykonawców (zewnętrzne firmy szkoleniowe)

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu organizacyjnego Program szkoleń testerskich.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, pozyskiwanych z planowania i realizacji procesu organizacyjnego Program szkoleń testerskich, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Liczba przeprowadzonych szkoleń (np. porównanie liczby zaplanowanych i faktycznie zrealizowanych szkoleń)

•      Wyniki ocen po szkoleniach

•      Wyniki ankiet dotyczących jakości programu szkole

PA 3.3       Cykl życia i integracja testów

Cel

Celem obszaru procesowego Cykl życia i integracja testów jest ustanowienie

i utrzymywanie użytecznego zestawu zasobów procesu testowego organizacji (np. standardowego cyklu życia testów) oraz standardów środowiska roboczego, a także integracja i synchronizacja cyklu życia testów z cyklem wytwarzania oprogramowania. Zintegrowany cykl życia stanowi gwarancję uwzględnienia testów na wczesnym etapie projektu. Celem obszaru Cykl życia i integracja testów jest również zdefiniowanie spójnego podejścia do testów na różnych poziomach testów w oparciu o zidentyfikowane ryzyka i zdefiniowaną strategię testów, jak również udostępnienie ogólnego planu testów na podstawie zdefiniowanego cyklu życia testów.

Uwagi wstępne

Do podstawowych obowiązków organizacji testowej należy zdefiniowanie, udokumentowanie i utrzymywanie standardowego procesu testowego zgodnego z polityką testów i celami organizacji. Zasoby związane z procesem testowym umożliwiają spójną realizację tego procesu w całej organizacji i stanowią podstawę do uzyskania długofalowych korzyści. Biblioteka zasobów procesu testowego w organizacji to kolekcja elementów przeznaczonych do użytku w projektach i przez poszczególne osoby. Wśród elementów tych znajdują się opisy procesów testowych, opisy modeli cyklu życia testów (w tym pomocnicze szablony i wytyczne dotyczące produktów testowania), narzędzia wspierające testowanie, wytyczne dotyczące dopasowywania procesów oraz baza procesów testowych. Biblioteka wspiera mechanizmy nauczania i doskonalenia procesów w organizacji dzięki udostępnieniu najlepszych praktyk i wniosków wyciągniętych z dotychczasowych działań.

Standardowe modele cyklu życia testów definiują główne fazy, czynności i produkty dla różnych poziomów testów. Czynności testowe w projektach są wykonywane zgodnie z takimi modelami. Opracowywane są również standardy i wytyczne dotyczące produktów (pracy) związanych z testami. Standardowe modele cyklu życia testów są uzgadniane z modelami cyklu wytwarzania oprogramowania w celu zintegrowania czynności testowych w kontekście faz projektu, kamieni milowych, produktów i zadań. Integracja cykli życia odbywa się w taki sposób, aby testowanie zostało uwzględnione już we wczesnych fazach projektu,

np. planowanie testów może rozpocząć się w fazie specyfikacji wymagań, a planowanie testów modułowych i integracyjnych w trakcie tworzenia projektu szczegółowego. Testerzy wykonują przegląd dokumentów stanowiących podstawę testów w celu określenia testowalności,

a podejście do testów może wpłynąć na planowanie działań wytwórczych. Zestaw standardowych procesów testowych organizacji można dostosowywać w ramach projektów, aby utworzyć procesy specjalnie zdefiniowane na ich potrzeby. Standardy środowiska roboczego stosuje się podczas tworzenia środowisk roboczych w projektach.

Na poziomie TMMi 3 zarządzanie testami koncentruje się na tworzeniu głównego planu testów obejmującego koordynowanie zadań testowych, obowiązki i podejście do testów na wielu poziomach testów. Pozwala to uniknąć niepotrzebnych powtórzeń i luk na różnych poziomach testów, a w rezultacie znacznie zwiększyć skuteczność i jakość ogólnego procesu testowego. Informacje wynikające z planowania procesu testowego są dokumentowane

w projekcie planu testów (głównym planie testów). Jest on nadrzędny wobec szczegółowych planów testów jednego poziomu, które odnoszą się do poszczególnych poziomów testów. Główny plan testów opisuje sposoby zastosowania strategii testów w poszczególnych projektach, w tym określa poziomy testów, które należy przeprowadzić, a także relacje między tymi poziomami. Główny plan testów powinien być spójny z polityką i strategią testów, a jeśli w konkretnych obszarach występują niezgodności, powinien zawierać uzasadnienie takich odstępstw i wyjątków. Główny plan testów stanowi uzupełnienie planu projektu lub podręcznika operacyjnego opisującego prace testowe jako część większego projektu lub przedsięwzięcia. Plan ten jest ogólnym dokumentem określającym zasady planowania testów i zarządzania testami na wielu poziomach testów (w jednym lub w wielu projektach). W przypadku mniejszych projektów lub przedsięwzięć (np. w sytuacji, gdy sformalizowany jest tylko jeden poziom testów) główny plan testów i plan testów jednego poziomu są często łączone w ramach jednego dokumentu.

Zakres

Obszar procesowy Cykl życia i integracja testów obejmuje wszystkie praktyki, których celem jest ustanowienie i utrzymywanie użytecznego zestawu zasobów procesu testowego organizacji (np. standardowego cyklu życia testów) oraz standardów środowiska roboczego,

a także integracja i synchronizacja cyklu życia testów z cyklem wytwarzania oprogramowania. Obszar ten uwzględnia również praktyki związane z tworzeniem głównego planu testów. Na poziomie TMMi 3 główny plan testów definiuje spójne podejście do testów na różnych poziomach.

Podsumowanie celów i praktyk szczegółowych

SG 1       Utworzenie zasobów procesu testowego w organizacji

SP 1.1       Ustanowienie standardowych procesów testowych

SP 1.2       Ustalenie opisów modeli cyklu życia testów dotyczących wszystkich poziomów testów

SP 1.3       Ustalenie kryteriów i wytycznych dotyczących dostosowywania

SP 1.4      Utworzenie bazy procesów testowych organizacji

SP 1.5      Utworzenie biblioteki zasobów procesu testowego

SP 1.6      Określenie standardów środowiska roboczego

SG 2      Integracja modeli cyklu życia testów i modeli wytwarzania oprogramowania

SP 2.1       Zdefiniowanie zintegrowanych modeli cyklu życia

SP 2.2       Przegląd zintegrowanych modeli cyklu życia

SP 2.3       Uzyskanie zobowiązań dotyczących roli testowania w ramach zintegrowanych modeli cyklu życia

SG 3       Ustanowienie głównego planu testów

SP 3.1       Wykonanie oceny ryzyka produktowego

SP 3.2      Ustanowienie podejścia do testów

SP 3.3      Określenie oszacowań dotyczących testowania

SP 3.4       Zdefiniowanie organizacji testowania

SP 3.5       Opracowanie głównego planu testów

SP 3.6       Uzyskanie zobowiązań dotyczących realizacji głównego planu testów

Praktyki szczegółowe dla poszczególnych celów

SG 1       Utworzenie zasobów procesu testowego w organizacji

Tworzony jest i utrzymywany zestaw zasobów procesu testowego w organizacji.

SP 1.1       Ustanowienie standardowych procesów testowych

Ustanawiany jest i utrzymywany zestaw standardowych procesów testowych organizacji.

Do zaspokojenia potrzeb związanych z różnymi dziedzinami aplikacji, poziomami testów, modelami cyklu życia, metodykami i narzędziami może być konieczne zdefiniowanie wielu standardowych procesów testowych. Zestaw standardowych procesów testowych organizacji zwykle koncentruje się na procesach technicznych. Jeśli jednak kierownictwo określi taką potrzebę, w skład zbioru standardowych procesów testowych mogą wejść również procesy administracyjne, procesy wsparcia i procesy organizacyjne. Zestaw procesów testowych organizacji powinien uwzględniać wszystkie procesy niezbędne na poziomie organizacji

i projektów, w tym procesy określone na 2. poziomie dojrzałości.

Przykładowe produkty pracy

1.      Zestaw standardowych procesów testowych organizacji

Podpraktyki

1.      Dekompozycja poszczególnych standardowych procesów testowych na elementy składowe na poziomie szczegółowości koniecznym do zrozumienia i opisania procesu

2.      Specyfikacja krytycznych atrybutów poszczególnych elementów procesów

Przykładowe krytyczne atrybuty elementów procesu:

•      Role i obowiązki w procesie

•      Obowiązujące standardy

•      Stosowane procedury, metody i narzędzia

•      Kryteria wejścia

•      Dane wejściowe

•      Gromadzone miary dotyczące produktów i procesu

•      Punkty weryfikacji (np. przeglądy)

•      Dane wyjściowe

•      Interfejsy

•      Kryteria wyjścia

3.      Specyfikacja relacji między elementami procesów

Przykładowe relacje:

•      Kolejność elementów procesu

•      Interfejsy między elementami procesu

•      Interfejsy do procesów zewnętrznych względem testowania

•      Wzajemne zależności między elementami procesu

4.      Zapewnienie zgodności zestawu standardowych procesów testowych organizacji

z przyjętymi politykami, standardami i modelami

Zgodność z przyjętymi standardami i modelami zwykle wykazuje się poprzez odwzorowanie zestawu standardowych procesów testowych organizacji na odpowiednie standardy i modele.

5.      Zapewnienie zgodności zestawu standardowych procesów testowych organizacji

z celami i potrzebami organizacji testowej

6.      Udokumentowanie zestawu standardowych procesów testowych organizacji

7.      Przeprowadzenie przeglądów koleżeńskich zestawu standardowych procesów testowych organizacji

8.      Aktualizacja zestawu standardowych procesów testowych organizacji zgodnie

z potrzebami

SP 1.2       Ustalenie opisów modeli cyklu życia testów dotyczących wszystkich poziomów testów

Opracowywane są i utrzymywane opisy modeli cyklu życia testów (wraz z pomocniczymi szablonami i wytycznymi dotyczącymi produktów testowania) zatwierdzonych w organizacji,

z uwzględnieniem wszystkich zdefiniowanych poziomów testów.

Przykładowe produkty pracy

1.      Opis modeli cyklu życia testów

Podpraktyki

1.      Wybór modeli cyklu życia testów na podstawie potrzeb na poziomie projektów

i organizacji

2.      Udokumentowanie opisów modeli cyklu życia testów

Elementy, które zwykle znajdują się w opisie modelu cyklu życia testów:

•      Strategia testów, np. poziomy testów i ich cele

•      Fazy cyklu życia testów, np. planowanie testów, monitorowanie testów  i nadzór nad testami, analiza testów, projektowanie testów, implementacja testów, wykonywanie testów i ukończenie testów.

•      Kryteria wejścia i wyjścia dla poszczególnych faz

•      Czynności testowe dla poszczególnych faz

•      Zakres odpowiedzialności

•      Produkty

•      Kamienie milowe

3.      Opracowanie pomocniczych szablonów i wytycznych dotyczących produktów zidentyfikowanych w ramach modeli cyklu życia testów

Przykłady produktów testowania wspieranych przez szablony i wytyczne:

•      Główny plan testów

•      Plan testów jednego poziomu

•      Specyfikacja projektu testu

•      Specyfikacja przypadku testowego

•      Specyfikacja procedury testowej

•      Dziennik testów

•      Raport o incydencie

•      Sumaryczny raport z testów

4.      Przeprowadzenie przeglądów koleżeńskich dotyczących modeli cyklu życia testów oraz pomocniczych szablonów i wytycznych

5.      Aktualizacja modeli cyklu życia testów oraz pomocniczych szablonów i wytycznych zgodnie z potrzebami

SP 1.3       Ustalenie kryteriów i wytycznych dotyczących dostosowywania

Ustanawiane są i utrzymywane kryteria i wytyczne dotyczące dostosowywania zestawu standardowych procesów testowych organizacji.

Przykładowe produkty pracy

1.      Kryteria i wytyczne dotyczące dostosowywania zestawu standardowych procesów testowych organizacji

Kryteria i wytyczne dotyczące dostosowywania zwykle zawierają następujące elementy:

•      Sposoby wykorzystania zestawu standardowych procesów testowych organizacji oraz związanych z nimi zasobów do tworzenia dostosowanych zdefiniowanych procesów testowych

•      Obowiązkowe wymagania, które muszą zostać spełnione przez dostosowane zdefiniowane procesy

•      Opcje, z których można skorzystać, oraz kryteria wyboru opcji

•      Procedury, których należy przestrzegać podczas wykonywania i dokumentowania dostosowywania procesów

Podpraktyki

1.      Określenie kryteriów wyboru i procedur dostosowywania zestawu standardowych procesów testowych organizacji

Przykładowe działania związane z dostosowywaniem:

•      Modyfikowanie modelu cyklu życia testów

•      Łączenie elementów różnych modeli cyklu życia testów

•      Modyfikowanie elementów procesu testowego

•      Zastępowanie elementów procesu testowego

•      Usuwanie elementów procesu testowego

•      Zmiana kolejności elementów procesu testowego

2.      Określenie standardów dokumentowania dostosowanych procesów testowych

3.      Określenie procedur zgłaszania i uzyskiwania zgody na odstępstwa od wymagań określonych w zestawie standardowych procesów testowych organizacji

4.      Dokumentowanie wytycznych dotyczących dostosowywania zestawu standardowych procesów testowych organizacji

5.      Prowadzenie przeglądów koleżeńskich w odniesieniu do wytycznych dotyczących dostosowywania

6.      Aktualizacja wytycznych dotyczących dostosowywania zgodnie z potrzebami

SP 1.4       Utworzenie bazy procesów testowych organizacji

Tworzona jest i utrzymywana baza procesów testowych organizacji.

Przykładowe produkty pracy

1.      Definicja wspólnego zestawu elementów procesu testowego i danych produktów na potrzeby zestawu standardowych procesów testowych organizacji

2.      Repozytorium bazy procesów testowych organizacji (tj. struktura repozytorium

i środowisko pomocnicze)

3.      Baza procesów testowych organizacji

Podpraktyki

1.      Utworzenie bazy procesów testowych w celu gromadzenia i udostępniania danych dotyczących procesów testowych i związanych z nimi produktów pracy

Przykłady danych dotyczących procesów testowych i produktów pracy:

•      Oszacowania testów i dane rzeczywiste, np. dotyczące wielkości, pracochłonności

i kosztów

•      Miary jakości, np. liczba wykrytych defektów według priorytetu

•      Zakres pokrycia przez przeglądy koleżeńskie

•      Pokrycie testowe

•      Miary niezawodności

2.      Przegląd danych wprowadzonych do bazy procesów testowych w celu zapewnienia integralności zawartości bazy danych

Baza procesów testowych zawiera rzeczywiste dane pomiarowe (lub odwołania do takich danych), a także powiązane informacje i dane niezbędne do zrozumienia i zinterpretowania danych pomiarowych oraz oceny ich wiarygodności i możliwości zastosowania.

3.      Zarządzanie bazą procesów testowych i kontrola

Dostęp użytkowników do zawartości bazy procesów testowych podlega kontroli w celu zapewnienia kompletności, integralności, bezpieczeństwa i poprawności danych.

SP 1.5       Utworzenie biblioteki zasobów procesu testowego

Tworzona jest i utrzymywana biblioteka zasobów procesu testowego w organizacji.

Przykładowe produkty pracy

1.      Biblioteka zasobów procesu testowego w organizacji

2.      Katalog elementów w bibliotece zasobów procesu testowego w organizacji

Podpraktyki

1.      Projektowanie i implementacja biblioteki zasobów procesu testowego w organizacji,

w tym struktury biblioteki i środowiska pomocniczego

2.      Określenie kryteriów uwzględniania elementów w bibliotece, np. głównie na podstawie ich powiązań z zestawem standardowych procesów testowych organizacji

3.      Określenie procedur zapisywania i pobierania elementów

4.      Wprowadzenie wybranych elementów do biblioteki i ich skatalogowanie w celu łatwego tworzenia odwołań i pobierania

Przykładowe elementy, które mogą być zapisywane w bibliotece zasobów procesu testowego w organizacji:

•      Polityka i strategia testów

•      Opisy zdefiniowanych procesów testowych

•      Procedury (np. procedura szacowania testów)

•      Szablony

•      Zasoby procesów testowych związanych z najlepszymi praktykami

•      Wzorcowe plany testów

•      Materiały szkoleniowe

•      Narzędzia pomocnicze w procesach (np. listy kontrolne)

•      Dokumenty dotyczące wyciągniętych wniosków (np. sumaryczne raporty z testów)

5.      Udostępnienie elementów do wykorzystania w projektach

6.      Okresowe przeglądy wykorzystania poszczególnych elementów i zarządzanie zawartością biblioteki w oparciu o wnioski z przeglądów

7      Aktualizacja biblioteki zasobów procesu testowego zgodnie z potrzebami

SP 1.6       Określenie standardów środowiska roboczego

Określane są i utrzymywane standardy środowiska roboczego.

Przykładowe produkty pracy

1.      Standardy środowiska roboczego

Przykładowe standardy środowiska roboczego:

•      Procedury obsługi, ochrony i zabezpieczania środowiska roboczego

•      Standardowy sprzęt i oprogramowanie stacji roboczych

•      Standardowe aplikacje

Podpraktyki

1.      Ocena dostępnych na rynku standardów środowisk roboczych odpowiednich dla organizacji

2.      Przyjęcie istniejących standardów środowiska roboczego i opracowanie nowych w celu uzupełnienia luk zgodnie z potrzebami i celami organizacji w zakresie procesu testowego

SG 2       Integracja modeli cyklu życia testów i modeli wytwarzania oprogramowania

Cykl życia testów podlega integracji z cyklem wytwarzania oprogramowania (w kontekście faz projektu, kamieni milowych, produktów i zadań), co pozwala uwzględnić testy na wczesnym etapie prac.

SP 2.1       Zdefiniowanie zintegrowanych modeli cyklu życia

Opracowywane i utrzymywane są opisy zintegrowanych modeli cyklu życia testów

i oprogramowania zatwierdzonych w organizacji.

Przykładowe produkty pracy

1. Opis zintegrowanych modeli cyklu życia

Podpraktyki

1.      Synchronizacja faz modeli cyklu życia testów z fazami modeli cyklu wytwarzania oprogramowania

2.      Uwzględnienie testowania na wczesnych etapach cyklu wytwarzania oprogramowania, np. w trakcie opracowywania wymagań

3.      Zdefiniowanie wzajemnych zależności między czynnościami związanymi z testowaniem a wytwarzaniem oprogramowania

4.      Zdefiniowanie wzajemnych zależności między produktami i kamieniami milowymi związanymi z testowaniem a wytwarzaniem oprogramowania

5.      Udokumentowanie opisów zintegrowanych modeli cyklu życia

6.      Aktualizacja opisów zintegrowanych modeli cyklu życia zgodnie z potrzebami

SP 2.2       Przegląd zintegrowanych modeli cyklu życia

Zintegrowane modele cyklu życia podlegają przeglądowi z udziałem interesariuszy. Celem przeglądu jest uświadomienie interesariuszom roli testowania w ramach zintegrowanych modeli.

Przykładowe produkty pracy

1.      Zapis przeglądu zintegrowanego cyklu życia

Podpraktyki

1.      Zorganizowanie przeglądów z udziałem interesariuszy w celu uświadomienia im roli testowania w ramach zintegrowanych modeli cyklu życia testów i wytwarzania oprogramowania.

SP 2.3       Uzyskanie zobowiązań dotyczących roli testowania w ramach zintegrowanych modeli cyklu życia

Od odpowiednich interesariuszy odpowiedzialnych za zarządzanie czynnościami zdefiniowanymi w zintegrowanych modelach cyklu życia oraz wykonywanie i wsparcie takich czynności uzyskiwane są zobowiązania dotyczące roli testowania w ramach zintegrowanych modeli cyklu życia.

Przykładowe produkty pracy

1.      Udokumentowane żądania dotyczące zobowiązań

2.      Udokumentowane zobowiązania

Podpraktyki

1.      Zidentyfikowanie niezbędnego wsparcia i wynegocjowanie zobowiązań z odpowiednimi interesariuszami

2.      Udokumentowanie wszystkich zobowiązań organizacyjnych (pełnych i tymczasowych)

3.      Przegląd zobowiązań wewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

4.      Przegląd zobowiązań zewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

SG 3       Ustanowienie głównego planu testów

Główny plan testów definiuje spójne podejście do testów na różnych poziomach i ogólne zasady planowania testów.

SP 3.1      Wykonanie oceny ryzyka produktowego

Wykonywana jest ocena ryzyka produktowego w celu zidentyfikowania typowych obszarów krytycznych podlegających testom.

Przykładowe produkty pracy

1. Lista ryzyk produktowych z określeniem kategorii i priorytetu każdego ryzyka.

Podpraktyki

1.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w ocenie ryzyka produktowego

2.      Zidentyfikowanie ogólnych ryzyk produktowych na podstawie informacji przekazanych przez interesariuszy

3.      Udokumentowanie kontekstu i potencjalnych skutków wystąpienia ryzyka produktowego

4.      Zidentyfikowanie odpowiednich interesariuszy dla poszczególnych ryzyk produktowych

5.      Przegląd zidentyfikowanych ryzyk produktowych w kontekście przedsięwzięcia testowego

6.      Analiza zidentyfikowanych ryzyk produktowych z wykorzystaniem predefiniowanych parametrów, np. prawdopodobieństwa i wpływu

7.      Kategoryzacja i pogrupowanie ryzyk produktowych zgodnie ze zdefiniowanymi kategoriami ryzyka

8.      Ustalenie priorytetów ryzyk produktowych na potrzeby ich łagodzenia

9.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności, kategorii i priorytetu ryzyk produktowych

10.      Aktualizacja ryzyk produktowych zgodnie z potrzebami

Więcej informacji na temat praktyk (podpraktyk) związanych z oceną ryzyka produktowego zawiera opis celu SG 1 Wykonanie oceny ryzyka produktowego z obszaru procesowego Planowanie testów.

SP 3.2       Ustanowienie podejścia do testów

Ustanawiane jest i uzgadniane podejście do testów w celu złagodzenia zidentyfikowanych ryzyk produktowych z przypisanymi priorytetami.

Przykładowe produkty pracy

1.      Podejście do testów

2.      Lista elementów podlegających i niepodlegających testowaniu

3.      Lista funkcji podlegających i niepodlegających testowaniu

4.      Lista zidentyfikowanych poziomów testów

5.      Tabela przydziału elementów testowych / cech testowych / ryzyk produktowych do poziomów testów

6.      Kryteria wejścia dla ustalonych poziomów testów

7.      Kryteria wyjścia dla ustalonych poziomów testów

Podpraktyki

1.      Zidentyfikowanie i udokumentowanie elementów i funkcji, które należy przetestować, oraz tych, których nie trzeba testować, na podstawie ryzyk produktowych.

Poziom agregacji elementów i funkcji podlegających testowaniu w przypadku tworzenia głównego planu testów będzie prawdopodobnie nieco bardziej ogólny niż w miarę możliwości przy wsparciu narzędzi. Techniki testowania w przypadku jednego poziomu testów.

2.      Zidentyfikowanie poziomów testów niezbędnych do złagodzenia ryzyk produktowych

3.      Przydzielenie elementów i funkcji podlegających testowaniu oraz ryzyk produktowych do zidentyfikowanych poziomów testów

4.      Wybór technik projektowania testów używanych na różnych poziomach testów; na podstawie zdefiniowanych ryzyk produktowych definiuje się różne techniki projektowania testów w celu uzyskania odpowiedniego pokrycia testowego

5.      Zdefiniowanie metod przeglądu produktów pracy związanych z testowaniem

6.      Zdefiniowanie podejścia do testowania potwierdzającego i testowania regresji

7.      Określenie narzędzi wspierających testowanie

8.      Zidentyfikowanie istotnych ograniczeń dotyczących podejścia do testów

9.      Zdefiniowanie zestawu kryteriów wejścia powiązanych z procesem testowym i jakością produktów dla każdego zidentyfikowanego poziomu testów

10.      Zdefiniowanie zestawu kryteriów wyjścia powiązanych z procesem testowym i jakością produktów dla każdego zidentyfikowanego poziomu testów

11.      Dopasowanie podejścia do testów i strategii testów zdefiniowanej w organizacji lub programie

12.      Określenie ewentualnych niezgodności ze strategią testów i ich uzasadnienie

13.      Przegląd podejścia do testów z udziałem interesariuszy

14.      Aktualizacja podejścia do testów zgodnie z potrzebami

Więcej informacji na temat praktyk (podpraktyk) związanych z ustanowieniem podejścia do testów zawiera opis celu szczegółowego SG 2 Ustanowienie podejścia do testów z obszaru procesowego Planowanie testów.

SP 3.3       Określenie oszacowań dotyczących testowania

Określane są i utrzymywane uzasadnione oszacowania dotyczące testowania, które są następnie używane podczas omawiania podejścia do testów z interesariuszami i planowania czynności testowych.

Należy zwrócić uwagę, że we wczesnych fazach cyklu wytwarzania oprogramowania nie wszystkie wymagane informacje mogą być dostępne i nie da się opracować wiążących oszacowań dotyczących testów. W rezultacie dokładność oszacowań dokonanych w takiej sytuacji jest ograniczona. Ważne, aby kierownik testów wyjaśnił interesariuszom, że finalne wersje oszacowań zostaną określone (i ewentualnie uszczegółowione) na późniejszych etapach cyklu życia, kiedy będą dostępne dodatkowe informacje.

Przykładowe produkty pracy

1.      Struktura podziału pracy (WBS)

2.      Wybrany model cyklu życia testów

3.      Oszacowania pracochłonności testów

4.      Oszacowania kosztów testowania

Podpraktyki

1.      Wybór ze standardowego zestawu modeli organizacji konkretnego modelu cyklu życia testów, który zostanie objęty planowaniem

2.      Ustanowienie struktury podziału pracy na najwyższym poziomie zgodnie ze zdefiniowanym podejściem do testów w celu ustalenia konkretnego zakresu oszacowań dotyczących testowania

3.      Oszacowanie pracochłonności i kosztów wytworzenia produktów pracy związanych

z testowaniem w oparciu o uzasadnienie oszacowań, np. metryki testów z bazy procesów testowych

4.      Uzgodnienie szacowanej pracochłonności i kosztów testowania z ogólną szacowaną pracochłonnością i szacowanymi kosztami projektu

Więcej informacji na temat praktyk (podpraktyk) związanych z określaniem oszacowań dotyczących testowania zawiera opis celu szczegółowego SG 3 Określenie oszacowań dotyczących testowania z obszaru procesowego Planowanie testów.

SP 3.4       Zdefiniowanie organizacji testowania

Definiuje się sposoby organizacji testowania na różnych poziomach, w tym interfejsy z innymi procesami, a także klarowny opis oczekiwań wobec poszczególnych stron uczestniczących

w testowaniu.

Określone i opisane zostają relacje testowania z innymi procesami, takimi jak wytwarzanie oprogramowania, zarządzanie projektami, zapewnienie jakości i zarządzania konfiguracją. Obejmuje to kanały komunikacji z organizacją testową, uprawnienia do rozwiązywania problemów zgłoszonych przez testerów oraz uprawnienia do zatwierdzania produktów testowania i procesów. W ramach prac może powstać reprezentacja graficzna, np. schemat organizacyjny.

Przykładowe produkty pracy

1.      Opis organizacji testów

Podpraktyki

1.      Określenie ról związanych z testowaniem na różnych poziomach testów w celu wprowadzenia uzgodnień między poszczególnymi poziomami

2.      Zdefiniowanie uprawnień i obowiązków związanych z różnymi rolami, produktami

i procesami

3.      Zdefiniowanie struktury organizacyjnej, np. relacji między różnymi rolami, zidentyfikowanymi poziomami testów i innymi interesariuszami w ramach procesu wytwarzania oprogramowania

4.      Zdefiniowanie struktury komunikacji (np. spotkań i raportów) zarówno w ramach zespołu testowego, jak i z zewnętrznymi interesariuszami

SP 3.5       Opracowanie głównego planu testów

Główny plan testów definiuje spójne podejście do testowania na różnych poziomach.

Przykładowe produkty pracy

1. Główny plan testów

Podpraktyki

1.      Ustanowienie głównego harmonogramu testów, zawierającego wstępnie zdefiniowane etapy o rozsądnej wielkości, dla zidentyfikowanych poziomów testów (na podstawie opracowanych oszacowań dotyczących testowania i wybranego cyklu życia testów)

2.      Uzgodnienie głównego harmonogramu testów z ogólnym harmonogramem projektu

3.      Zaplanowanie udziału niezbędnych testerów dysponujących wiedzą i umiejętnościami wymaganymi do przeprowadzenia testów

4.      Zaplanowanie udziału zidentyfikowanych interesariuszy

5.      Zidentyfikowanie, analiza i udokumentowanie ryzyk projektowych związanych

z testowaniem

6.      Utworzenie i utrzymywanie głównego planu testów

Przykładowe elementy głównego planu testów [wg ISO 29119-3]:

•      Ogólne wprowadzenie (zakres, odwołania, przegląd systemu i przegląd testów)

•      Struktura organizacyjna, w tym role i obowiązki

•      Niezgodności ze strategią testów i ich uzasadnienie

•      Ryzyka produktowe

•      Elementy podlegające testowaniu (z określeniem priorytetu ryzyka) i niepodlegające testowaniu

•      Funkcje podlegające testowaniu (z określeniem priorytetu ryzyka) i niepodlegające testowaniu

•      Założenia i ograniczenia

•      Określenie poziomów testów i typów testów

•      Podejście do testów (np. techniki projektowania testów) dla poszczególnych poziomów testów

•      Podejście do testowania potwierdzającego (retestowania) i testowania regresji

•      Kryteria wejścia i wyjścia dla poszczególnych poziomów testów

•      Kamienie milowe związane z testowaniem i produkty pracy (rezultaty)

•      Cykl życia testów i zadania testowe

•      Potrzeby i wymagania dotyczące danych testowych i środowisk (w tym środowiska biurowego)

•      Potrzeby związane z obsadą kadrową i szkoleniami (włączając w to role

i odpowiedzialności)

•      Udział interesariuszy

•      Raportowanie testów i komunikacja

•      Oszacowania dotyczące testów

•      Główny harmonogram testów

•      Ryzyka projektu testowego i sytuacje awaryjne

Więcej informacji na temat praktyk (podpraktyk) związanych z opracowaniem głównego planu testów zawiera opis celu szczegółowego SG 4 Opracowanie planu testów z obszaru procesowego Planowanie testów.

Więcej informacji na temat potrzeb i wymagań dotyczących środowiska można znaleźć

w opisie obszaru procesowego Środowisko testowe.

SP 3.6       Uzyskanie zobowiązań dotyczących realizacji głównego planu testów

Określane są i utrzymywane zobowiązania dotyczące realizacji głównego planu testów.

Przykładowe produkty pracy

1.      Udokumentowane żądania dotyczące zobowiązań

2.      Zapis przeglądu głównego planu testów

3.      Zaktualizowany główny plan testów po renegocjacji, uwzględniający zmiany

w budżetach testowania, harmonogramie testów, liście ryzyk produktowych i umowach z interesariuszami

4.      Udokumentowane zobowiązania

Podpraktyki

1.      Zorganizowanie przeglądów z udziałem interesariuszy, ułatwiających im zapoznanie się ze zobowiązaniami dotyczącymi testowania

2.      Omówienie z interesariuszami różnic między oszacowaniami a dostępnością zasobów

3.      Uzgodnienie ewentualnych różnic między oszacowaniami a dostępnością zasobów

4.      Zidentyfikowanie niezbędnego wsparcia i wynegocjowanie zobowiązań z odpowiednimi interesariuszami

5.      Udokumentowanie wszystkich zobowiązań organizacyjnych (pełnych i tymczasowych)

6.      Przegląd zobowiązań wewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

7.      Przegląd zobowiązań zewnętrznych z udziałem kierownictwa wyższego szczebla

(w odpowiednim zakresie)

Więcej informacji na temat praktyk (podpraktyk) związanych z uzyskiwaniem zobowiązań dotyczących realizacji głównego planu testów zawiera opis celu SG 5 Uzyskanie zobowiązań dotyczących realizacji planu testów z obszaru procesowego Planowanie testów.

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Cykl życia i integracja testów.

Opracowanie

Polityka dotycząca cyklu życia i integracji testów zwykle zawiera następujące ustalenia:

•      Ustanawiany jest i utrzymywany zestaw standardowych procesów testowych

w organizacji

•      Zasoby procesu testowego są udostępniane w całej organizacji

•      Dla każdego poziomu testów definiowany jest standardowy cykl życia testów

•      Dostępne są standardy i wytyczne dotyczące produktów (pracy) związanych

z testowaniem dla poszczególnych faz cyklu życia

•      Zdefiniowany cykl życia testów podlega integracji z cyklem wytwarzania oprogramowania

•      Główny plan testów koordynuje czynności testowe realizowane na różnych poziomach testów

•      Wskazane zostają poziomy testów zarządzane za pomocą głównego planu testów

•      Tworzenie głównego planu testów jest zgodne ze strategią testów przyjętą dla całej organizacji lub programu

•      Testowanie jest uwzględniane na wczesnych etapach procesu wytwarzania oprogramowania

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Cykl życia i integracja testów.

Opracowanie

Plan utworzenia i utrzymywania standardowych procesów testowych organizacji i zasobów procesów testowych może zostać uwzględniony (lub przywołany) w planie doskonalenia procesu testowego organizacji.

Zwykle plan opracowania głównego planu testów jest uwzględniany w planie projektu, co zostało opisane w obszarze procesowym CMMI o nazwie Planowanie projektu (Project Planning).

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Cykl życia i integracja testów, wytworzenia produktów pracy związanych z testowaniem oraz realizacji usług związanych

z procesem.

Opracowanie

Kierownik ds. technologii testowania, wspierany przez grupę procesu testowego, zarządza definiowaniem standardowych procesów testowych organizacji. Zasadniczą część wspomnianej grupy stanowią zwykle specjaliści ds. testów. Działania grupy są wspierane przez właścicieli procesów testowych, kierownika ds. doskonalenia procesów oraz osoby dysponujące wiedzą specjalistyczną z zakresu testowania i z innych dziedzin.

Przykłady innych zasobów udostępnianych na potrzeby definiowania i utrzymywania standardowych procesów testowych organizacji:

•      Narzędzia do zarządzania bazami danych

•      Narzędzia do modelowania procesów

•      Narzędzia do tworzenia stron internetowych

Przykłady zasobów umożliwiających utworzenie głównego planu testów:

•      Istnieje udokumentowane i zatwierdzone przedsięwzięcie testowe; obejmuje ono zwykle zagadnienia i oczekiwania dotyczące celów, kryteriów wyjścia, elementów i funkcji podlegających i niepodlegających testowaniu, rodzaju wykonywanych testów, przestrzeganych standardów, kosztów, harmonogramu i ograniczeń dotyczących zasobów

•      Osoby odpowiedzialne za zarządzanie testami dysponują odpowiednim czasem na wykonanie czynności związanych z opracowaniem głównego planu testów

•      Dostępne są doświadczone osoby dysponujące wiedzą specjalistyczną z dziedziny aplikacji oraz osoby dysponujące wiedzą w zakresie procesu wytwarzania oprogramowania; osoby te wspierają tworzenie głównego planu testów

•      Dostępne są narzędzia wspierające proces tworzenia głównego planu testów, np. narzędzia do planowania projektu i tworzenia harmonogramów, narzędzia do szacowania, narzędzia do oceny ryzyka, narzędzia do zarządzania testami i narzędzia do zarządzania konfiguracją

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Cykl życia i integracja testów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Cykl życia

i integracja testów.

Opracowanie

Do zarządzania definiowaniem standardowych procesów testowych organizacji często wyznaczany jest kierownik ds. technologii testowania wspierany przez grupę procesu testowego. Zasadniczą część wspomnianej grupy stanowią zwykle specjaliści ds. testów. Działania grupy są wspierane przez właścicieli procesów testowych, kierownika

ds. doskonalenia procesów oraz osoby dysponujące wiedzą specjalistyczną z zakresu testowania i z innych dziedzin.

Zwykle za negocjowanie zobowiązań i opracowanie głównego planu testów odpowiedzialny jest kierownik testów. Kierownik testów koordynuje proces tworzenia głównego planu testów w projekcie (osobiście lub po przekazaniu uprawnień).

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Cykl życia i integracja testów zgodnie z potrzebami.

Opracowanie

Osoby odpowiedzialne za opracowanie zestawu zasobów procesu testowego organizacji są szkolone w zakresie tworzenia procesów i zarządzania nimi.

Przykładowe tematy szkoleń:

•      TMMi, CMMI i inne wzorcowe modele procesów (testowych)

•      Planowanie procesów, zarządzanie procesami i monitorowanie procesów

•      Modelowanie i definiowanie procesów

•      Tworzenie standardowych procesów możliwych do dostosowania

•      Tworzenie standardów środowiska roboczego

•      Ergonomia

Osoby odpowiedzialne za zarządzanie testami oraz inne osoby lub grupy uczestniczące

w tworzeniu głównego planu testów są szkolone w tym zakresie, jak również w zakresie powiązanych procedur i technik.

Przykładowe tematy szkoleń:

•      Zasady planowania

•      Strategia testów

•      Proces i techniki oceny ryzyka produktowego i projektowego

•      Definiowanie podejścia do testów

•      Szablony planu testów i standardy

•      Struktury organizacyjne

•      Oszacowania dotyczące testów i tworzenie harmonogramu testów

•      Pomocnicze narzędzia do planowania testów

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Cykl życia i integracja testów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Zestaw standardowych procesów testowych organizacji

•      Opis zintegrowanych modeli cyklu życia

•      Wytyczne dotyczące dostosowywania zestawu standardowych procesów testowych organizacji

•      Dane pomiarowe dotyczące procesów testowych organizacji i jakości produktów

•      Struktura podziału pracy

•      Dane związane z oszacowaniami dotyczącymi testów

•      Dane związane z oceną ryzyka produktowego

•      Raport z przeglądu głównego planu testów

•      Główny plan testów

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Cykl życia i integracja testów zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Przegląd zestawu standardowych procesów testowych organizacji

•      Przegląd zintegrowanych modeli cyklu życia w organizacji

•      Rozwiązywanie problemów dotyczących zasad dostosowywania

•      Ocena definicji wspólnego zestawu procesów testowych oraz danych pomiarowych dotyczących jakości produktów

•      Przegląd standardów środowiska roboczego

•      Wybór produktu i modułów produktu podlegających testowaniu

•      Identyfikowanie poziomu ryzyka i rodzajów ryzyka dla produktu i modułów produktu podlegających testowaniu (udział w ocenie ryzyka produktowego)

•      Przekazywanie informacji na potrzeby oszacowań dotyczących testowania

•      Przegląd ryzyk projektu testowego i rozwiązywanie problemów

•      Bezpośrednie udostępnienie zasobów testowych zgodnie z potrzebami

•      Przegląd i zatwierdzenie głównego planu testów

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Cykl życia i integracja testów (porównywanie

z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Cykl życia i integracja testów:

•      Odsetek projektów korzystających z elementów procesów testowych wchodzących

w skład zestawu standardowych procesów testowych organizacji

•      Odsetek żądań zmiany dla poszczególnych elementów procesów testowych wchodzących w skład zestawu standardowych procesów testowych organizacji

•      Kwota roszczeń odszkodowawczych pracowników wynikających z problemów ergonomicznych

•      Liczba dni potrzebna na opracowanie procesu testowego lub zmiany procesu testowego

•      Liczba wersji głównego planu testów

•      Porównanie rzeczywistego czasu realizacji i pracochłonności z czasem realizacji

i pracochłonnością określonymi w głównym planie testów

•      Liczba elementów testowych, w przypadku których w poszczególnych wersjach planu testów zmieniono poziom ryzyka

•      Rozbieżności dotyczące kosztów, harmonogramu i pracochłonności w poszczególnych wersjach planu

Realizację głównego planu testów monitoruje się i kontroluje z wykorzystaniem praktyk wskazanych w opisie obszaru procesowego Monitorowanie i kontrola testów.

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Cykl życia i integracja testów oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Działania związane z utworzeniem zasobów procesu testowego w organizacji

•      Zestaw standardowych procesów testowych organizacji

•      Opis modeli cyklu życia testów

•      Wytyczne dotyczące dostosowywania zestawu standardowych procesów testowych organizacji

•      Dane związane z procesem testowym organizacji

•      Zgodność ze strategią testów

•      Zgodność ze standardami (procedurami i szablonami)

•      Jakość głównego planu testów

•      Zdefiniowane podejście do testów

•      Proces oceny ryzyka produktowego

•      Proces szacowania testów

•      Działania wymagające przeglądu i zobowiązań dotyczących testowania

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Cykl życia i integracja testów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Cykl życia i integracja testów

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Cykl życia i integracja testów, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Przekazywanie wyciągniętych wniosków do biblioteki zasobów procesu organizacji

•      Liczba propozycji zmian wynikających z wyciągniętych wniosków

•      Przekazywanie danych do bazy procesów testowych organizacji

•      Status przesłanych żądań zmiany dotyczących modyfikacji standardowego procesu organizacji

•      Odsetek głównych planów testów ustanowionych zgodnie z procedurą i szablonem

•      Odsetek głównych planów testów z udokumentowanymi wynikami analizy ryzyka produktowego i podejściem do testów

•      Odsetek głównych planów testów poddanych przeglądowi formalnemu i zatwierdzonych przez kierownictwo

•      Pracochłonność tworzenia głównego planu testów

•      Dokładność oszacowań dotyczących testów

PA 3.4       Testowanie niefunkcjonalne

Cel

Celem obszaru procesowego Testowanie niefunkcjonalne jest usprawnienie możliwości uwzględnienia testów niefunkcjonalnych w trakcie planowania, projektowania

i wykonywania testów. Osiągnięcie tego celu jest możliwe dzięki zdefiniowaniu podejścia do testów opartego na zidentyfikowanych niefunkcjonalnych ryzykach produktowych, opracowaniu specyfikacji testów niefunkcjonalnych oraz realizacji ustrukturyzowanego procesu wykonywania testów koncentrującego się na testowaniu niefunkcjonalnym.

Uwagi wstępne

Jakość produktów wiąże się przede wszystkim z zaspokajaniem potrzeb interesariuszy. Takie potrzeby należy przekształcić w dobrze udokumentowane wymagania funkcjonalne („co” produkt robi) i niefunkcjonalne („jak” to robi). Często o zadowoleniu klientów decydują właśnie wymagania niefunkcjonalne. Ten obszar procesowy dotyczy tworzenia możliwości testowania niefunkcjonalnego. Istnieje zbiór podstawowych charakterystyk niefunkcjonalnych używanych do opisu jakości programów lub systemów. Ocenę tych charakterystyk jakościowych można przeprowadzić za pomocą technik testowania niefunkcjonalnego. Możliwość zastosowania różnych technik testowania jest zależna od umiejętności testera, znajomości danej dziedziny

i atrybutów podlegających testowaniu.

Na podstawie oceny niefunkcjonalnego ryzyka produktowego należy zdefiniować podejście do testów. W zależności od poziomu i typu ryzyk niefunkcjonalnych podejmowana jest decyzja o tym, które wymagania dotyczące produktu zostaną przetestowane, w jakim stopniu i w jaki sposób. Niefunkcjonalne ryzyka produktowe i podejście do testów są definiowane w ścisłej współpracy między specjalistami ds. testów i interesariuszami; testerzy nie powinni podejmować takiej decyzji samodzielnie.

Techniki testowania niefunkcjonalnego stosuje się w miarę możliwości przy wsparciu narzędzi. Techniki testowania służą do wyprowadzania i wyboru niefunkcjonalnych warunków testowych i tworzenia przypadków testowych na podstawie wymagań niefunkcjonalnych

i specyfikacji projektu. Przypadki testowe są następnie przekształcane w manualne procedury testowe i/lub skrypty testowe dla testów automatycznych. Tworzone są konkretne dane testowe umożliwiające wykonanie testów niefunkcjonalnych. W fazie wykonywania testów wykonywane są również testy niefunkcjonalne, a incydenty wykryte w ich trakcie są rejestrowane w postaci zgłoszeń.

Zakres

Obszar procesowy Testowanie niefunkcjonalne obejmuje wykonanie oceny niefunkcjonalnego ryzyka produktowego i zdefiniowanie podejścia do testów na podstawie zidentyfikowanych ryzyk niefunkcjonalnych. Obszar ten wiąże się też z fazą przygotowywania testów i uwzględnia wyprowadzanie i wybór niefunkcjonalnych warunków i przypadków testowych, tworzenie konkretnych danych testowych oraz wykonywanie testów niefunkcjonalnych. Praktyki dotyczące środowiska testowego, które w przypadku testów niefunkcjonalnych często mają znaczenie krytyczne, nie są ujęte w tym obszarze procesowym. Zostały one uwzględnione w ramach obszaru procesowego Środowiska testowe na poziomie TMMi 2 i powinny wspierać również testowanie niefunkcjonalne.

Podsumowanie celów i praktyk szczegółowych

SG 1       Wykonanie oceny niefunkcjonalnego ryzyka produktowego

SP 1.1      Zidentyfikowanie niefunkcjonalnych ryzyk produktowych

SP 1.2       Analiza niefunkcjonalnego ryzyka produktowego

SG 2       Ustanowienie podejścia do testów niefunkcjonalnych

SP 2.1       Zidentyfikowanie cech niefunkcjonalnych podlegających testowaniu

SP 2.2       Zdefiniowanie podejścia do testów niefunkcjonalnych

SP 2.3       Zdefiniowanie niefunkcjonalnych kryteriów wyjścia

SG 3       Wykonanie analizy i projektowania testów niefunkcjonalnych

SP 3.1      Zidentyfikowanie niefunkcjonalnych warunków testowych i określenie ich priorytetów

SP 3.2      Zidentyfikowanie niefunkcjonalnych przypadków testowych

i określenie ich priorytetów

SP 3.3       Zidentyfikowanie niezbędnych konkretnych danych testowych

SP 3.4       Utrzymywanie możliwości poziomego śledzenia powiązań

z wymaganiami niefunkcjonalnymi

SG 4       Implementacja testów niefunkcjonalnych

SP 4.1       Opracowanie procedur testów niefunkcjonalnych i określenie ich priorytetów

SP 4.2       Utworzenie konkretnych danych testowych

SG 5       Wykonanie testów niefunkcjonalnych

SP 5.1       Wykonanie niefunkcjonalnych przypadków testowych

SP 5.2      Raportowanie niefunkcjonalnych incydentów testowych

SP 5.3      Dokonanie wpisu w dzienniku testów

Praktyki szczegółowe dla poszczególnych celów

SG 1       Wykonanie oceny niefunkcjonalnego ryzyka produktowego

Wykonywana jest ocena ryzyka produktowego w celu zidentyfikowania obszarów krytycznych podlegających testom niefunkcjonalnym.

SP 1.1       Zidentyfikowanie niefunkcjonalnych ryzyk produktowych

Niefunkcjonalne ryzyka produktowe są identyfikowane i dokumentowane.

Przykładowe produkty pracy

1      Zidentyfikowane niefunkcjonalne ryzyka produktowe

Podpraktyki

1.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w ocenie ryzyka

2.      Zidentyfikowanie niefunkcjonalnych ryzyk produktowych w oparciu o zdefiniowane kategorie niefunkcjonalnego ryzyka produktowego, z wykorzystaniem informacji przekazanych przez interesariuszy i dokumentacji wymagań

Przykładowe techniki identyfikowania ryzyk produktowych:

•      Warsztaty dotyczące ryzyka

•      Burze mózgów

•      Wywiady z ekspertami

•      Listy kontrolne

•      Wyciągnięte wnioski

3.      Udokumentowanie kontekstu i potencjalnych skutków wystąpienia niefunkcjonalnego ryzyka produktowego

4.      Zidentyfikowanie odpowiednich interesariuszy dla poszczególnych niefunkcjonalnych ryzyk produktowych

Należy zaznaczyć, że identyfikowanie niefunkcjonalnych ryzyk produktowych można połączyć z praktyką SP 1.2 Identyfikowanie ryzyk produktowych z obszaru procesowego Planowanie testów i/lub z praktyką SP 3.1 Wykonanie oceny ryzyka produktowego z obszaru procesowego Cykl życia i integracja testów realizowaną podczas tworzenia głównego planu testów.

SP 1.2       Analiza niefunkcjonalnych ryzyk produktowych

Niefunkcjonalne ryzyka produktowe podlegają ocenie, kategoryzacji i określeniu priorytetów

z wykorzystaniem predefiniowanych kategorii i parametrów.

Przykładowe produkty pracy

1.       Lista niefunkcjonalnych ryzyk produktowych z określeniem kategorii i priorytetu każdego ryzyka

Podpraktyki

1.      Analiza zidentyfikowanych niefunkcjonalnych ryzyk produktowych z wykorzystaniem predefiniowanych parametrów, np. prawdopodobieństwa i wpływu

2.      Kategoryzacja i pogrupowanie niefunkcjonalnych ryzyk produktowych zgodnie ze zdefiniowanymi kategoriami ryzyka

Przykładowe kategorie niefunkcjonalnych ryzyk [ISO/IEC 25010]:

•      Użyteczność

•      Niezawodność

•      Wydajność

•      Kompatybilność

•      Zabezpieczenia

•      Utrzymywalność

•      Przenaszalność

3.      Ustalenie priorytetów niefunkcjonalnych ryzyk produktowych na potrzeby ich łagodzenia

4.      Ustalenie możliwości śledzenia powiązań między niefunkcjonalnymi ryzykami produktowymi a wymaganiami w celu udokumentowania źródeł ryzyka produktowego

5.      Wygenerowanie macierzy śledzenia powiązań między wymaganiami niefunkcjonalnymi a ryzykami produktowymi

6.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności, kategorii i priorytetu niefunkcjonalnych ryzyk produktowych

7.      Aktualizacja niefunkcjonalnych ryzyk produktowych zgodnie z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji ryzyk produktowych:

•      Nowe lub zmieniające się wymagania niefunkcjonalne

•      Zmiana metod wytwarzania oprogramowania

•      Wyciągnięcie wniosków z problemów występujących w projekcie  dotyczących jakości

Należy zwrócić uwagę, że kategorie i parametry ryzyka produktowego zdefiniowane

w obszarze procesowym Planowanie testów (SP 1.1 Definiowanie kategorii i parametrów ryzyka produktowego) są w dużej mierze wykorzystywane ponownie i mogą być rozszerzane w ramach tej praktyki szczegółowej.

SG 2       Ustanowienie podejścia do testów niefunkcjonalnych

Na podstawie zidentyfikowanych niefunkcjonalnych ryzyk produktowych ustanawiane jest

i uzgadniane podejście do testów niefunkcjonalnych.

SP 2.1       Zidentyfikowanie cech niefunkcjonalnych podlegających testowaniu

Cechy niefunkcjonalne, które należy przetestować, oraz te, których nie trzeba testować, są identyfikowane na podstawie niefunkcjonalnych ryzyk produktowych.

Przykładowe produkty pracy

1.      Lista cech niefunkcjonalnych podlegających i niepodlegających testowaniu

Podpraktyki

1.      Rozbicie niefunkcjonalnych ryzyk produktowych z przypisanymi priorytetami na cechy niefunkcjonalne podlegające i niepodlegające testowaniu

2.      Udokumentowanie poziomu ryzyka i dokumentacja źródłowa (podstawa testów) dla każdej zidentyfikowanej funkcji podlegającej testowaniu

SP 2.2       Zdefiniowanie podejścia do testów niefunkcjonalnych

Definiowane jest podejście do testów w celu złagodzenia zidentyfikowanych niefunkcjonalnych ryzyk produktowych z przypisanymi priorytetami.

Przykładowe produkty pracy

1.       Podejście do testów niefunkcjonalnych (udokumentowane w planie testów)

Podejście do testów powinno zostać opisane na wystarczającym poziomie szczegółowości, umożliwiającym zidentyfikowanie głównych zadań testowych i oszacowanie czasu wymaganego do wykonania każdego z nich.

Podpraktyki

1. Wybór używanych technik testowania niefunkcjonalnego

Przykładowe techniki testowania niefunkcjonalnego, które można uwzględnić:

•      Ocena heurystyczna, ankiety i kwestionariusze w przypadku użyteczności

•      Profile operacyjne w przypadku niezawodności

•      Testowanie obciążeniowe, testowanie przeciążające i testowanie obciążenia

w przypadku efektywności

Do testowania konkretnych niefunkcjonalnych charakterystyk jakościowych można również zastosować techniki czarnoskrzynkowe, białoskrzynkowe i oparte na doświadczeniu, np. testowanie eksploracyjne i listy kontrolne.

2.      Zdefiniowanie metod przeglądu produktów pracy związanych z testowaniem

3.      Zdefiniowanie podejścia do niefunkcjonalnego testowania potwierdzającego

4.      Zdefiniowanie podejścia do niefunkcjonalnego testowania regresji

5.      Określenie narzędzi wspierających testowanie

6.      Zidentyfikowanie istotnych ograniczeń dotyczących podejścia do testów niefunkcjonalnych, takich jak dostępność zasobów testowych, cechy środowiska testowego i wyznaczone terminy

7.      Dopasowanie podejścia do testów niefunkcjonalnych i strategii testów zdefiniowanej

w organizacji lub programie

8.      Określenie ewentualnych obszarów niezgodności ze strategią testów i ich uzasadnienie

9.      Przegląd podejścia do testów niefunkcjonalnych z udziałem interesariuszy

10.      Aktualizacja podejścia do testów niefunkcjonalnych zgodnie z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji podejścia do testów niefunkcjonalnych:

•      Nowe lub zmienione priorytety niefunkcjonalnych ryzyk produktowych

•      Wyciągnięcie wniosków po zastosowaniu podejścia do testów niefunkcjonalnych

w projekcie

SP 2.3       Zdefiniowanie niefunkcjonalnych kryteriów wyjścia

Kryteria wyjścia testów niefunkcjonalnych definiuje się w celu zaplanowania momentu zakończenia testowania.

Przykładowe produkty pracy

1.      Niefunkcjonalne kryteria wyjścia

Podpraktyki

1.      Zdefiniowanie zestawu kryteriów wyjścia powiązanych z niefunkcjonalnymi charakterystykami jakościowymi produktów podlegających testowaniu

Przykłady kryteriów wyjścia powiązanych z niefunkcjonalnymi charakterystykami jakościowymi produktów podlegających testowaniu:

•      Niezawodność: średni czas pomiędzy awariami (MTBF), średni czas do naprawy (MTTR)

•      Użyteczność: zadowolenie użytkowników, średni czas wykonywania funkcji

•      Efektywność: średni czas odpowiedzi, wykorzystanie pamięci

•      Utrzymywalność: średnia pracochłonność wprowadzenia zmiany, dostępność dokumentacji

2.      Przegląd niefunkcjonalnych kryteriów wyjścia z udziałem interesariuszy

Należy pamiętać, że kryteria wyjścia danego poziomu testów powinny być zgodne z kryteriami wejścia kolejnego poziomu.

Kryteria wejścia, zawieszenia i wznowienia nie są bezpośrednio definiowane w ramach tego obszaru procesowego z wykorzystaniem praktyk szczegółowych. Kryteria zdefiniowane

w obszarze procesowym Planowanie testów zwykle mają zastosowanie również w przypadku testowania niefunkcjonalnego. Na przykład kryteria wejścia związane z dostępnością środowiska testowego, pomyślnym przeprowadzeniem testu wstępnego i dostępnością opisu wydania testów stosuje się do wszystkich rodzajów testowania – zarówno funkcjonalnego, jak i niefunkcjonalnego. Zalecany jest jednak krótki przegląd zdefiniowanych w trakcie planowania testów kryteriów wejścia, zawieszenia i wznowienia pod kątem testowania niefunkcjonalnego.

SG 3       Wykonanie analizy i projektowania testów niefunkcjonalnych

Podczas analizy i projektowania testów podejście do testowania niefunkcjonalnego jest przekształcane w konkretne warunki testowe i przypadki testowe.

SP 3.1       Zidentyfikowanie niefunkcjonalnych warunków testowych i określenie ich priorytetów

Następuje zidentyfikowanie warunków testowych i określenie ich priorytetów w oparciu

o analizę niefunkcjonalnych cech testowych określonych w podstawie testów.

Przykładowe produkty pracy

1.      Rejestr problemów dotyczących podstawy testów

2.      Niefunkcjonalne warunki testowe

3.      Specyfikacja projektu testów niefunkcjonalnych

Podpraktyki

1.      Analiza podstawy testów (np. wymagań niefunkcjonalnych, architektury, projektu

i specyfikacji interfejsów)

2.      Omówienie problemów dotyczących podstawy testów z właścicielem dokumentu

3.      Wyprowadzenie warunków testowych z podstawy testów zgodnie z udokumentowanym podejściem do testów niefunkcjonalnych

4.      Ustalenie priorytetów warunków testowych na podstawie zidentyfikowanych ryzyk produktowych

5.      Udokumentowanie warunków testowych w specyfikacji projektu testów (zgodnie ze standardem specyfikacji projektu testów)

Przykładowe elementy specyfikacji projektu testów [wg ISO 29119-3]:

•      Identyfikator specyfikacji projektu testów

•      Elementy (pozycje) i/lub funkcje podlegające testowaniu

•      Cel

•      Udoskonalenie podejścia

•      Warunki testowe

•      Priorytet

•      Śledzenie powiązań6.      Przegląd specyfikacji projektu testów z udziałem interesariuszy

7.      Aktualizowanie specyfikacji projektu testów i warunków testowych zgodnie z potrzebami, np. w przypadku zmiany wymagań

SP 3.2      Zidentyfikowanie niefunkcjonalnych przypadków testowych i określenie ich priorytetów

Identyfikowane są niefunkcjonalne przypadki testowe odpowiadające zdefiniowanym warunkom testowym i określane są ich priorytety.

Przykładowe produkty pracy

1.      Niefunkcjonalne przypadki testowe

2.      Specyfikacja niefunkcjonalnych przypadków testowych

Podpraktyki

1.      Wyprowadzenie przypadków testowych z warunków testowych zgodnie

z udokumentowanym podejściem do testów niefunkcjonalnych.

2.      Ustalenie priorytetów przypadków testowych na podstawie zidentyfikowanych niefunkcjonalnych ryzyk produktowych

3.      Udokumentowanie niefunkcjonalnych przypadków testowych w specyfikacji przypadków testowych (zgodnie ze standardem specyfikacji przypadków testowych)

Przykładowe elementy specyfikacji przypadków testowych [wg ISO 29119-3]:

•      Identyfikator specyfikacji przypadku testowego

•      Elementy pokrycia testowego

•      Cel

•      Priorytet

•      Warunki wstępne przypadku testowego (np. potrzeby dotyczące środowiska)

•      Dane wejściowe przypadku testowego

•      Oczekiwane wyniki przypadku testowego

•      Zależności między przypadkami testowymi

•      Śledzenie powiązań

4.      Przegląd specyfikacji przypadków testowych z udziałem interesariuszy

5.      Aktualizacja specyfikacji przypadków testowych zgodnie z potrzebami

SP 3.3       Zidentyfikowanie niezbędnych konkretnych danych testowych

Ustalane są konkretne dane testowe niezbędne do obsługi niefunkcjonalnych warunków testowych i przypadków testowych.

Przykładowe produkty pracy

1.      Specyfikacja danych testowych

Podpraktyki

1.      Identyfikowanie i specyfikowanie niezbędnych konkretnych danych testowych wymaganych do implementacji i wykonania niefunkcjonalnych przypadków testowych

2.      Udokumentowanie niezbędnych konkretnych danych testowych, np. w ramach specyfikacji przypadków testowych

SP 3.4       Utrzymywanie możliwości poziomego śledzenia powiązań z wymaganiami niefunkcjonalnymi

Ustalenie i utrzymywanie możliwości śledzenia powiązań między wymaganiami niefunkcjonalnymi a niefunkcjonalnymi warunkami testowymi.

Przykładowe produkty pracy

1.      Macierz śledzenia powiązań między wymaganiami niefunkcjonalnymi a warunkami testowymi

Podpraktyki

1.      Utrzymywanie możliwości śledzenia powiązań z wymaganiami niefunkcjonalnymi w celu udokumentowania źródeł niefunkcjonalnych warunków testowych

2.      Wygenerowanie macierzy śledzenia powiązań między wymaganiami niefunkcjonalnymi a warunkami testowymi

3.      Skonfigurowanie macierzy śledzenia w taki sposób, aby możliwe było monitorowanie pokrycia wymagań niefunkcjonalnych w trakcie wykonywania testów

SG 4       Implementacja testów niefunkcjonalnych

Tworzone są procedury testów niefunkcjonalnych i określane są ich priorytety. Tworzone są również konkretne dane testowe wymagane do przeprowadzenia testów niefunkcjonalnych.

SP 4.1       Opracowanie procedur testów niefunkcjonalnych i określenie ich priorytetów

Tworzone są procedury testów niefunkcjonalnych i określane są ich priorytety.

Przykładowe produkty pracy

1.      Specyfikacja procedur testów niefunkcjonalnych

2.      Skrypty testowe dla testów automatycznych

Podpraktyki

1.      Opracowanie procedur testów niefunkcjonalnych poprzez połączenie niefunkcjonalnych przypadków testowych w określonej kolejności i uwzględnienie innych informacji niezbędnych do wykonania testów

2.      Ustalenie priorytetów procedur testów niefunkcjonalnych na podstawie zidentyfikowanych ryzyk produktowych

3.      Udokumentowanie procedur testów niefunkcjonalnych w specyfikacji procedur testowych (zgodnie ze standardem specyfikacji procedur testowych)

Przykładowe elementy specyfikacji procedury testowej [wg ISO 29119-3]:

•      Identyfikator specyfikacji procedury testowej

•      i) Unikalny identyfikator

•      ii) Cel

•      iii) Priorytet

•      iv) Treść (śledzenie powiązań)

•      Procedury testowe

•      i) Unikalny identyfikator

•      ii) Cel

•      iii) Priorytet

•      iv) Uruchomienie

•      v) Przypadki testowe do wykonania (śledzenie powiązań)

•      vi) Związek z innymi procedurami

•      vii) Zatrzymanie i zakończenie

4.      Przegląd specyfikacji procedur testów niefunkcjonalnych z udziałem interesariuszy

5.      Aktualizacja specyfikacji procedur testów niefunkcjonalnych zgodnie z potrzebami

6.      Opcjonalna automatyzacja procedur testów niefunkcjonalnych i przekształcenie ich

w skrypty testowe dla testów automatycznych, np. na potrzeby testowania wytrzymałości lub wydajności

7.      Określenie harmonogramu wykonywania procedur testów niefunkcjonalnych w ramach ogólnego harmonogramu wykonywania testów

Informacje na temat tworzenia harmonogramu uruchamiania procedur i skryptów testowych można znaleźć w opisie praktyki SP 2.4 Opracowanie harmonogramu wykonywania testów

z obszaru procesowego Projektowanie i wykonywanie testów.

SP 4.2       Utworzenie konkretnych danych testowych

Tworzone są konkretne dane testowe umożliwiające wykonanie testów niefunkcjonalnych zgodnie ze specyfikacją określoną w trakcie analizy i projektowania testów.

Przykładowe produkty pracy

1.      Konkretne dane testowe

Podpraktyki

1.      Utworzenie konkretnych danych testowych wymaganych do przeprowadzenia testów niefunkcjonalnych zgodnie z procedurami testowymi

2.      Archiwizacja zestawu konkretnych danych testowych w celu ewentualnego odtworzenia sytuacji początkowej w przyszłości

Informacje na temat zarządzania utworzonymi danymi testowymi zawiera opis praktyki SP 3.2 Zarządzanie danymi testowymi z obszaru procesowego Środowisko testowe.

SG 5      Wykonanie testów niefunkcjonalnych

Testy niefunkcjonalne są wykonywane zgodnie z uprzednio wyspecyfikowanymi procedurami testowymi. W ich trakcie zgłaszane są incydenty i dokonywane są wpisy w dzienniku testów.

SP 5.1      Wykonanie niefunkcjonalnych przypadków testowych

Niefunkcjonalne przypadki testowe są wykonywane ręcznie na podstawie udokumentowanych procedur testowych i/lub automatycznie za pomocą skryptów testowych.

Przykładowe produkty pracy

1.       Rezultaty testów

Podpraktyki

1.      Wykonanie niefunkcjonalnych przypadków testowych z wykorzystaniem udokumentowanych procedur testowych i/lub skryptów testowych

2.      Zarejestrowanie rzeczywistych rezultatów

3.      Porównanie rzeczywistych rezultatów z oczekiwanymi

4.      Powtórzenie czynności testowych związanych z testem niefunkcjonalnym w ramach testowania potwierdzającego po wykryciu incydentu

5.      Wykonanie niefunkcjonalnego testowania regresji zgodnie z potrzebami

Należy zwrócić uwagę, że część testów niefunkcjonalnych może zostać przeprowadzona

w sposób nieformalny, bez użycia wstępnie zdefiniowanych, szczegółowych procedur testowych, np. w formie oceny heurystycznej podczas testowania użyteczności.

Przed wykonaniem testów niefunkcjonalnych zwykle jest przeprowadzany ogólny test wstępny. Więcej informacji na temat testu wstępnego  przedmiotu testów zawiera opis praktyk SP 2.3 Specyfikacja procedury testu wstępnego oraz SP 3.1 Przeprowadzenie testu wstępnego (z obszaru procesowego Projektowanie i wykonywanie testów), natomiast informacje na temat testu wstępnego środowiska testowego można znaleźć w opisie praktyki SP 2.4 Wykonanie testu wstępnego środowiska testowego (z obszaru procesowego Środowisko testowe).

SP 5.2       Raportowanie incydentów testowych

Rozbieżności między rzeczywistymi a oczekiwanymi rezultatami zgłaszane są w postaci niefunkcjonalnych incydentów testowych.

Przykładowe produkty pracy

1.      Raporty o niefunkcjonalnych incydentach testowych

Podpraktyki

1      Rejestrowanie niefunkcjonalnych incydentów testowych w przypadku wykrycia rozbieżności

2.      Analizowanie niefunkcjonalnego incydentu testowego w celu uzyskania dodatkowych informacji o problemie

3.      Określenie przyczyn niefunkcjonalnego incydentu testowego (np. testowany system, dokumentacja testowa, dane testowe lub błąd podczas wykonywania testu)

4.      Przypisanie początkowego priorytetu i poziomu ważności do niefunkcjonalnego incydentu testowego

5.      Formalne zgłoszenie incydentu testowego z wykorzystaniem schematu klasyfikacji incydentów

Przykładowe elementy raportu o incydencie testowym [wg ISO 29119-3]:

•      Identyfikator raportu o incydencie testowym

•      Podsumowanie

Informacje o czasie

•      Pomysłodawca

•      Kontekst

•      Opis incydentu (dane wejściowe, oczekiwane wyniki, rzeczywiste wyniki, anomalie, krok procedury testowej, środowisko, próby powtórzenia, testerzy, obserwatorzy)

•      Ocena ważności przez pomysłodawcę

•      Ocena priorytetu przez pomysłodawcę

•      Ryzyko

•      Status incydentu

6.      Przegląd raportów o niefunkcjonalnych incydentach testowych z udziałem interesariuszy

7.      Zapisanie informacji o niefunkcjonalnych incydentach testowych w centralnym repozytorium

Więcej informacji na temat przetwarzania incydentów i zarządzania nimi do momentu ich zamknięcia można znaleźć w opisie celu SG 4 Zarządzanie incydentami testowymi do ich zamknięcia z obszaru procesowego Projektowanie i wykonywanie testów.

SP 5.3       Dokonanie wpisu w dzienniku testów

Tworzone są dzienniki testów w celu zarejestrowania chronologicznego zapisu istotnych szczegółów związanych z wykonaniem testów niefunkcjonalnych.

Przykładowe produkty pracy

1.       Dzienniki testów

Podpraktyki

1.      Gromadzenie danych dotyczących wykonywania testów

2.      Udokumentowanie danych dotyczących wykonywania testów za pomocą dziennika testów (zgodnie ze standardem dziennika testów)

Przykładowe elementy dziennika testów [wg ISO 29119-3]:

•      Identyfikator dziennika testów

•      Data i czas

•      Opis (testowane elementy, środowisko, w którym było prowadzone testowanie)

•      Informacje o działaniach i zdarzeniach (opis wykonania, rezultaty testów, nietypowe zdarzenia, identyfikatory raportów o incydentach)

•      Wpływ

3.      Przegląd dziennika testów z udziałem interesariuszy

Praktyki ogólne dla poszczególnych celów

GG 2      Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Testowanie niefunkcjonalne.

Opracowanie

Polityka testów niefunkcjonalnych zwykle zawiera następujące ustalenia:

•      Typowe charakterystyki jakościowe istotne dla przedsiębiorstwa i produktów

•      Zestaw istotnych charakterystyk jakościowych dla poszczególnych poziomów testów

•      Poziom automatyzacji testów i rodzaj wymaganych narzędzi

•      Schemat klasyfikacji incydentów używany podczas dokumentowania i zgłaszania niefunkcjonalnych incydentów testowych

•      Udokumentowana procedura używana do oceny, klasyfikacji i przetwarzania zgłoszonych niefunkcjonalnych incydentów testowych

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Testowanie niefunkcjonalne.

Opracowanie

Zwykle plan realizacji procesu Testowanie niefunkcjonalne jest uwzględniany w planie testów, co zostało opisane w obszarze procesowym o nazwie Planowanie testów. Harmonogram czynności związanych z testowaniem niefunkcjonalnym jest bezpośrednio ustalany w ramach planu testów.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Testowanie niefunkcjonalne, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

•      Zapewniono odpowiedni czas na wykonanie czynności związanych z planowaniem, projektowaniem i wykonywaniem testów niefunkcjonalnych

•      Dostępne są doświadczone osoby dysponujące wiedzą w zakresie testowania niefunkcjonalnego i narzędzi testowych

•      Dostępne są doświadczone osoby dysponujące wiedzą specjalistyczną z dziedziny aplikacji oraz osoby dysponujące wiedzą w zakresie procesu wytwarzania oprogramowania; osoby takie wspierają tworzenie podejścia do testów niefunkcjonalnych, np. biorą udział w sesjach analizy ryzyka produktowego

i projektowaniu testów niefunkcjonalnych, a także w przeglądach

•      Dostępne są narzędzia wspierające proces projektowania i wykonywania testów niefunkcjonalnych

Przykładowe narzędzia:

•      Narzędzie do monitorowania

•      Narzędzie do pomiaru wydajności

•      Narzędzie do analizy statycznej

•      Narzędzie do analizy dynamicznej

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Testowanie niefunkcjonalne, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Testowanie niefunkcjonalne.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Testowanie niefunkcjonalne zgodnie z potrzebami.

Opracowanie

Specjaliści ds. testów oraz inne osoby lub grupy uczestniczące w testowaniu niefunkcjonalnym są szkolone w tym zakresie, jak również w zakresie powiązanych procedur, technik i narzędzi.

Przykładowe tematy szkoleń:

•      Znaczenie testowania niefunkcjonalnego

•      Charakterystyki jakościowe (np. wg ISO/IEC 25010)

•      Analiza ryzyka produktowego na potrzeby testowania niefunkcjonalnego

•      Zdefiniowanie podejścia do testowania niefunkcjonalnego

•      Formalne i nieformalne techniki testowania przydatne w testach niefunkcjonalnych

•      Kryteria wyjścia dla atrybutów niefunkcjonalnych

•      Narzędzia pomocnicze

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Testowanie niefunkcjonalne odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Dane związane z oceną niefunkcjonalnego ryzyka produktowego

•      Specyfikacje projektu testów niefunkcjonalnych

•      Specyfikacje niefunkcjonalnych przypadków testowych

•      Specyfikacje procedur testów niefunkcjonalnych (i/lub skryptów testowych)

•      Dzienniki testów

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Testowanie niefunkcjonalne zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Udział w ocenie ryzyka produktowego polegający na zidentyfikowaniu niefunkcjonalnych ryzyk dla produktu i modułów produktu podlegających testowaniu

•      Przeglądy i zatwierdzanie projektów testów niefunkcjonalnych i przypadków testowych

•      Wykonywanie testów, np. testowanie użyteczności przez użytkowników końcowych

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Testowanie niefunkcjonalne (porównywanie

z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Liczba opracowanych specyfikacji testów niefunkcjonalnych

•      Liczba wykonanych testów niefunkcjonalnych

•      Liczba złagodzonych niefunkcjonalnych ryzyk

•      Liczba nierozwiązanych incydentów wykrytych w testach niefunkcjonalnych (według priorytetu)

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Testowanie niefunkcjonalne oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Zgodność z niefunkcjonalnymi aspektami strategii testów

•      Zdefiniowane podejście do testowania niefunkcjonalnego

•      Proces oceny niefunkcjonalnego ryzyka produktowego

•      Skuteczność i efektywność technik projektowania testów niefunkcjonalnych

•      Jakość niefunkcjonalnych przypadków testowych

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Testowanie niefunkcjonalne z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Testowanie niefunkcjonalne.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Testowanie niefunkcjonalne, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Wskaźnik pracochłonności testów niefunkcjonalnych w porównaniu z testami funkcjonalnymi

•      Pracochłonność testów dla poszczególnych atrybutów niefunkcjonalnych

•      Liczba atrybutów niefunkcjonalnych testowanych w poszczególnych projektach

•      Raporty o incydentach dotyczących atrybutów niefunkcjonalnych według priorytetu

i ważności

•      Uzyskane pokrycie wymagań niefunkcjonalnych

PA 3.5      Przeglądy koleżeńskie

Cel

Celem obszaru procesowego Przeglądy koleżeńskie jest zweryfikowanie, czy produkty pracy spełniają określone wymagania oraz wczesne i skuteczne usunięcie defektów

z wybranych produktów pracy. Istotnym dodatkowym efektem przeglądów jest wypracowanie lepszego zrozumienia produktów pracy oraz potencjalnych defektów, których można uniknąć.

Uwagi wstępne

W ramach przeglądów odbywa się metodyczne sprawdzanie produktów pracy przez współpracowników w celu zidentyfikowania defektów i obszarów, w których należy wprowadzić zmiany. Przeglądy prowadzone są w ramach niewielkiej grupy specjalistów, zwykle liczącej od dwu do siedmiu osób. Produktem poddawanym przeglądowi może być specyfikacja wymagań, dokument projektowy, kod źródłowy, projekt testów, podręcznik użytkownika lub dokument innego typu. Istnieje wiele praktycznych sposobów tworzenia grupy uczestników przeglądu. Przeglądającymi mogą być:

•      Specjaliści w dziedzinie przeglądów (osoby odpowiedzialne za zapewnienie jakości lub audytorzy)

•      Osoby z tego samego projektu

•      Osoby zaproszone przez autora ze względu na ich specjalistyczną wiedzę

•      Osoby istotnie zainteresowane produktem, np. przedstawiciele strony biznesowej

Istnieją różne typy przeglądów, a z każdym z nich wiążą się odpowiednie cele. Oprócz przeglądów nieformalnych występują bardziej formalne typy przeglądów, takie jak przejrzenie, przegląd techniczny i inspekcja [ISO 20246]. W trakcie przejrzenia autor przedstawia grupie uczestników krok po kroku swój dokument i przyjęty tok rozumowania, tak aby wszyscy rozumieli treść dokumentu w ten sam sposób i zaakceptowali jego treść lub uzgodnili zmiany, które należy wprowadzić. Podczas przeglądu technicznego grupa osób (po indywidualnych przygotowaniach) omawia zawartość dokumentu oraz podejście (techniczne), które ma być zastosowane. Inspekcja to najbardziej formalny typ przeglądu. W tej technice każda osoba

i cała grupa sprawdzają dokument i szukają ewentualnych defektów, korzystając z różnych źródeł i standardów i działając zgodnie z określonymi regułami.

Zakres

Obszar procesowy Przeglądy koleżeńskie obejmuje praktyki związane z prowadzeniem przeglądów produktów pracy, np. przeglądów specyfikacji wymagań przez testerów w celu zweryfikowania testowalności. Uwzględnia również praktyki związane z ustanowieniem podejścia do prowadzenia przeglądów koleżeńskich w ramach projektu. Przeglądy projektu (nazywane również przeglądami kierowniczymi) znajdują się poza zakresem tego obszaru procesowego. Na poziomie dojrzałości TMMi 3 przeglądy koleżeńskie nie są w pełni zintegrowane z procesem testowania dynamicznego, np. nie są częścią strategii testów, planu testów i podejścia do testów.

Podsumowanie celów i praktyk szczegółowych

SG 1       Ustanowienie podejścia do prowadzenia przeglądów koleżeńskich

SP 1.1       Zidentyfikowanie produktów pracy poddawanych przeglądom

SP 1.2       Zdefiniowanie kryteriów przeglądów koleżeńskich

SG 2       Wykonywanie przeglądów koleżeńskich

SP 2.1      Przeprowadzenie przeglądów koleżeńskich

SP 2.2      Przegląd dokumentów tworzących podstawę testów przez testerów

SP 2.3      Analiza danych związanych z przeglądami koleżeńskimi

Praktyki szczegółowe dla poszczególnych celów

SG 1       Ustanowienie podejścia do prowadzenia przeglądów koleżeńskich

Ustanawiane jest i uzgadniane podejście do prowadzenia przeglądów.

SP 1.1       Zidentyfikowanie produktów pracy poddawanych przeglądom

Identyfikowane są produkty pracy poddawane przeglądom, w tym typy przeglądów i kluczowi uczestnicy (interesariusze).

Przykładowe produkty pracy

1.      Lista produktów pracy poddawanych przeglądom

2.      Podejście do prowadzenia przeglądów

3.      Rejestr przeglądów

4      Harmonogram przeglądów koleżeńskich

Podpraktyki

1.      Wybór produktów pracy, które zostaną objęte przeglądem koleżeńskim, zgodnie

z polityką przeglądów i zidentyfikowanymi ryzykami produktowymi

2.      Określenie typu lub typów przeglądów, które będą prowadzone dla wybranych produktów pracy

Przykładowe typy przeglądów koleżeńskich (wg ISO 20246):

•      Inspekcja

•      Przejrzenie

•      Przegląd techniczny

•      Przegląd nieformalny

Dla danego produktu pracy można przeprowadzić przeglądy różnego typu, np. może to dotyczyć produktów, z którymi wiążą się krytyczne ryzyka produktowe.

3.      Zidentyfikowanie głównych uczestników przeglądów koleżeńskich

4.      Przegląd zdefiniowanego podejścia do prowadzenia przeglądów (z udziałem interesariuszy)

5.      Opracowanie szczegółowego harmonogramu przeglądów koleżeńskich,

z uwzględnieniem terminów szkoleń dotyczących takich przeglądów oraz terminów dostępności materiałów na przeglądy

6.      Uzyskanie od głównych interesariuszy zobowiązań dotyczących zastosowania podejścia do prowadzenia przeglądów oraz dotrzymania harmonogramu

SP 1.2       Zdefiniowanie kryteriów przeglądów koleżeńskich

Przygotowania do przeglądów koleżeńskich wybranych produktów pracy polegają na zdefiniowaniu kryteriów wejścia i wyjścia dla przeglądów i zarządzaniu tymi kryteriami.

Przykładowe produkty pracy

1.      Kryteria wejścia i wyjścia przeglądów koleżeńskich

2.      Kryteria określające potrzebę kolejnego przeglądu

Podpraktyki

1.      Określenie i utrzymywania kryteriów wejścia dla przeglądów koleżeńskich

Przykładowe kryteria wejścia dla przeglądu:

•      Pobieżne sprawdzenie fragmentu produktu przez lidera przeglądu (lub eksperta) nie kończy się wykryciem dużej liczby poważnych defektów

•      Dokument został sprawdzony za pomocą narzędzia do sprawdzania pisowni lub przeprowadzono inną analizę komputerową, np. analizę statyczną kodu

•      Informacje referencyjne niezbędne do wykonania przeglądu są aktualne i dostępne

•      Wszystkie źródłowe dokumenty (tj. dokumenty wyższego poziomu) pomyślnie przeszły odpowiednie przeglądy

•      Autor dokumentu jest przygotowany do udziału w przeglądzie i jest przekonany o jakości dokumentu

Kryteria wejścia będą się różnić w zależności od typu wykonywanego przeglądu.

2.      Określenie i utrzymywanie kryteriów wyjścia dla przeglądów koleżeńskich

Przykładowe kryteria wyjścia dla przeglądu:

•      Liczba poważnych defektów na stronę

•      Czas przygotowania zgodny z wcześniejszymi ustaleniami

•      Wszystkie strony sprawdzone zgodnie z planem

•      Uwzględniono wszystkie problemy i podjęto wszystkie działania do wykonania

•      Szacowana wartość rezydualnej gęstości defektów

3.      Określenie i utrzymywanie kryteriów określających potrzebę kolejnego przeglądu

4.      Przegląd zdefiniowanych kryteriów z udziałem interesariuszy

SG 2      Wykonywanie przeglądów koleżeńskich

Wykonywane są przeglądy koleżeńskie wybranych produktów pracy, a dane związane

z przeglądami podlegają analizie.

SP 2.1      Przeprowadzenie przeglądów koleżeńskich

Wybrane produkty pracy podlegają przeglądom koleżeńskim, podczas których identyfikowane są problemy.

Przykładowe produkty pracy

1.      Dzienniki przeglądów koleżeńskich (lista wykrytych defektów)

2.      Działania do wykonania wynikające z przeglądu koleżeńskiego

3.      Dane związane z przeglądem koleżeńskim (np. udokumentowane w formularzach przeglądu)

4.      Raport z przeglądu koleżeńskiego (np. udokumentowany w formularzu przeglądu)

Podpraktyki

1.      Zapewnienie zgodności produktu pracy z kryteriami wyjścia przeglądu koleżeńskiego przed dystrybucją produktu

2.      Wybór uczestników przeglądu i zdefiniowanie dla nich konkretnych zadań do wykonania

3.      Dystrybucja produktu pracy poddawanego przeglądowi oraz powiązanych informacji

w terminie umożliwiającym uczestnikom odpowiednie przygotowanie się do przeglądu

4.      Przypisanie osób do ról w ramach przeglądu koleżeńskiego zgodnie z potrzebami

Przykładowe role:

•      Lider przeglądu

•      Moderator (facylitator)

•      Przeglądający

•      Protokolant

•      Autor

5.      Udział w przeglądzie koleżeńskim osób o przypisanych rolach

6.      Zidentyfikowanie i udokumentowanie defektów i innych problemów dotyczących produktu pracy

7.      Zarejestrowanie wyników przeglądu koleżeńskiego, np. w dziennikach przeglądu

8.      Określenie działań do wykonania i poinformowanie odpowiednich interesariuszy

o problemach

9.      Przeprowadzenie dodatkowego przeglądu, jeśli istnieje taka potrzeba (określona na podstawie zdefiniowanych kryteriów)

10.      Zapewnienie spełnienia kryteriów wyjścia przeglądu koleżeńskiego

11.      Zarejestrowanie danych związanych z przygotowaniem do przeglądu, jego przeprowadzeniem i wynikami

Zazwyczaj rejestrowane dane to typ produktu, wielkość produktu, typ przeglądu koleżeńskiego, liczba przeglądających, czas przygotowania poszczególnych przeglądających, czas trwania spotkania związanego z przeglądem, liczba wykrytych (poważnych) defektów itp.

SP 2.2       Przegląd dokumentów tworzących podstawę testów przez testerów

Dokumenty używane jako podstawa testów podlegają przeglądowi przez testerów.

Przykładowe produkty pracy

1.      Lista defektów dotyczących testowalności

2.      Raport z przeglądu testowalności

Podpraktyki

1.      Przegląd dokumentów stanowiących podstawę testów przez testerów w celu określenia testowalności, np. ustalenia, czy wybrane techniki projektowania testów mogą zostać zastosowane do danej podstawy testów

2.      Zarejestrowanie i zgłoszenie defektów wykrytych podczas przeglądu dokumentów stanowiących podstawę testów

3.      Korekta treści dokumentów stanowiących podstawę testów na podstawie defektów zgłoszonych przez testerów

SP 2.3       Analiza danych związanych z przeglądami koleżeńskimi

Analizowane są dane związane z przygotowaniem do testów koleżeńskich, ich przeprowadzeniem i wynikami.

Przykładowe produkty pracy

1.      Baza danych przeglądów koleżeńskich

2.      Raport informacyjny z analizą przeglądu koleżeńskiego

Podpraktyki

1.      Zapisanie danych związanych z przeglądem koleżeńskim do wglądu i na potrzeby przyszłych analiz

2.      Zapewnienie ochrony danych związanych z przeglądem, tak aby nie mogły zostać użyte w niewłaściwy sposób

Niewłaściwe wykorzystanie danych związanych z przeglądem koleżeńskim to np. użycie ich do oceny wydajności poszczególnych osób lub obarczenia ich winą za błędy.

3.      Analiza danych związanych z przeglądami koleżeńskimi

Przykładowe dane, które można analizować:

•      Faza, w której pojawił się defekt

•      Pracochłonność lub wskaźnik przygotowania w porównaniu z oczekiwaną pracochłonnością lub wskaźnikiem

•      Rzeczywista pracochłonność związana z przeglądem w porównaniu z planowaną pracochłonnością

•      Liczba defektów w porównaniu z oczekiwaną liczbą defektów

•      Typy i poziomy ważności wykrytych defektów

•      Liczba defektów w odniesieniu do rzeczywistej pracochłonności

•      Przyczyny defektów

•      Wpływ usunięcia defektów

4.      Poinformowanie interesariuszy o wynikach analizy przeglądu koleżeńskiego

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Przeglądy koleżeńskie.

Opracowanie

Polityka dotycząca przeglądów koleżeńskich zwykle zawiera następujące ustalenia:

•       Przeglądy będą stosowane do identyfikowania defektów na wczesnych etapach cyklu wytwarzania oprogramowania

•      Organizacja określi standardowy zestaw produktów pracy, które będą poddawane przeglądom, z uwzględnieniem produktów testowania

•      W każdym projekcie wybierane będą produkty pracy, które zostaną poddane przeglądowi, a także odpowiednie typy przeglądów

•      Liderzy przeglądów koleżeńskich i inni uczestnicy zostaną przeszkoleni do wypełniania swoich ról

•      Testerzy powinni uczestniczyć w przeglądach dokumentacji projektowej w celu wyjaśnienia problemów związanych z testowalnością

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Przeglądy koleżeńskie.

Opracowanie

Na poziomie TMMi 3 przeglądy koleżeńskie nie są na ogół w pełni zintegrowane z procesem testowym, dlatego zwykle plan realizacji procesu Przeglądy koleżeńskie jest uwzględniany

w planie projektu. Zostało to opisane w obszarze procesowym CMMI o nazwie Planowanie projektu (Project Planning). Udział personelu, np. liderów przeglądów, zostaje bezpośrednio zaplanowany, aby zapewnić możliwość wykonania przeglądów.

Na wyższych poziomach TMMi przeglądy koleżeńskie stanowią integralną część procesu testowego, a plan realizacji procesu Przeglądy koleżeńskie jest uwzględniany w (głównym) planie testów.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Przeglądy koleżeńskie, wytworzenia produktów pracy testowania oraz realizacji usług związanych z procesem.

Opracowanie

•      Dostępne są sale konferencyjne na spotkania związane z przeglądami

•      Dostępni są przeszkoleni liderzy przeglądów koleżeńskich

•      Dostępne są pomocnicze artefakty, np. formularze do rejestrowania defektów

i formularze przeglądu, umożliwiające gromadzenie danych i tworzenie raportów

•      Tworzone są i utrzymywane listy kontrolne, np. związane z testowalnością, w celu zapewnienia spójnych metod przeglądu produktów pracy

Przykłady elementów uwzględnianych na listach kontrolnych:

•      Zgodność ze standardami

•      Przestrzeganie wytycznych dotyczących projektu

•      Kompletność

•      Poprawność

•      Testowalność

•      Utrzymywalność

•      Często występujące typy defektów

•      Listy kontrolne podlegają w razie potrzeby modyfikacjom w celu uwzględnienia konkretnych typów produktów pracy i przeglądów. Listy kontrolne również podlegają przeglądom prowadzonym przez członków zespołu i potencjalnych użytkowników

•      Dostępne są narzędzia wspierające proces prowadzenia przeglądów koleżeńskich, np. narzędzia do komunikacji, narzędzia do analizy danych i narzędzia do zarządzania procesem przeglądu

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Przeglądy koleżeńskie, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Przeglądy koleżeńskie.

Opracowanie

Wyznaczani są liderzy przeglądów odpowiedzialni za koordynację procesu Przeglądy koleżeńskie w ramach projektów.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Przeglądy koleżeńskie zgodnie z potrzebami.

Opracowanie

•      Liderzy przeglądów koleżeńskich i moderatorzy są szkoleni w zakresie prowadzenia przeglądów oraz zapewnienia skutecznego prowadzenia spotkań przeglądowych

Przykładowe tematy szkoleń dla liderów przeglądów i moderatorów:

•      Opracowanie podejścia do prowadzenia przeglądów koleżeńskich

•      Typy przeglądów

•      Zadania i obowiązki lidera przeglądu koleżeńskiego

•      Prowadzenie i organizowanie spotkań

•      Uzyskiwanie poparcia dla przeglądów

•      Metryki przeglądów koleżeńskich

•      Uczestnicy przeglądów koleżeńskich są szkoleni w zakresie ról wypełnianych w procesie przeglądów

Przykładowe tematy szkoleń dla uczestników przeglądów:

•      Cele przeglądów koleżeńskich i wynikające z nich korzyści

•      Typy przeglądów

•      Przeglądy koleżeńskie:      role i obowiązki

•      Przeglądy koleżeńskie:      ogólny opis procesu

•      Przeglądy koleżeńskie:      przygotowania

•      Reguły i listy kontrolne dotyczące dokumentów, np. związane z testowalnością

•      Przeglądy koleżeńskie:      spotkania

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Przeglądy koleżeńskie odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Podejście do prowadzenia przeglądów koleżeńskich

•      Dzienniki przeglądów i formularze przeglądów

•      Dane związane z przeglądem (baza danych)

•      Materiały szkoleniowe związane z przeglądami

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Przeglądy koleżeńskie zgodnie z planem.

Opracowanie

Wybór odpowiednich interesariuszy biorących udział w przeglądach spośród klientów, użytkowników końcowych, programistów, testerów, dostawców, sprzedawców, specjalistów ds. utrzymania i serwisu oraz przedstawicieli innych grup, których dotyczą lub mogą dotyczyć dane produkty (pracy).

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Przeglądy koleżeńskie (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Przeglądy koleżeńskie:

•      Liczba zaplanowanych i przeprowadzonych przeglądów koleżeńskich

•      Liczba produktów pracy poddanych przeglądom (w porównaniu z planem)

•      Liczba i typy defektów wykrytych podczas przeglądów

•      Harmonogram czynności związanych z procesem przeglądów koleżeńskich

(z uwzględnieniem szkoleń)

•      Pracochłonność przeglądów koleżeńskich (w porównaniu z planem)

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Przeglądy koleżeńskie oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Sprawdzenie, czy prowadzone są przeglądy koleżeńskie

•      Szkolenia dla liderów przeglądów i innych uczestników

•      Proces stosowany w trakcie przeglądów koleżeńskich, w tym kwestia przestrzegania zdefiniowanych kryteriów

•      Faktyczna realizacja działań do wykonania

•      Raporty z przeglądów dotyczące kompletności i poprawności

•      Używane listy kontrolne przeglądów koleżeńskich

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Przeglądy koleżeńskie z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Przeglądy koleżeńskie.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Przeglądy koleżeńskie, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Dane związane z przeglądami, np. średni czas przygotowania, średni łączny czas poświęcony na przegląd koleżeński i średnia liczba stron

•      Liczba defektów wykrytych w trakcie przeglądów koleżeńskich według fazy cyklu wytwarzania oprogramowania oraz ich poziomy ważności

•      Obliczenie zwrotu z inwestycji

Poziom TMMi 4: Mierzalny

Osiągnięcie celów 2. i 3. poziomu TMMi przynosi korzyści w postaci wprowadzenia infrastruktury technicznej, zarządczej i kadrowej, zdolnej do dokładnego testowania

i zapewniającej wsparcie w usprawnianiu procesów testowych. Dzięki tej infrastrukturze testowanie może stać się mierzalnym procesem, umożliwiającym dalszy rozwój

i doskonalenie. W organizacjach poziomu TMMi 4 testowanie jest dokładnie zdefiniowanym, dobrze uzasadnionym i mierzalnym procesem. Testowanie jest postrzegane jako ewaluacja; składa się ze wszystkich czynności w całym cyklu życia produktu odnoszących się do sprawdzania produktów i powiązanych produktów pracy.

W całej organizacji zostaje wprowadzony program pomiarów testów, który może być wykorzystany do oceny jakości procesu testowego, oceny wydajności i monitorowania usprawnień. W zbiorze danych pomiarowych organizacji uwzględniane są miary w celu wspierania podejmowania decyzji opartych na faktach. Program pomiarów testowania wspiera również przewidywania dotyczące wydajności i kosztów testów.

W odniesieniu do jakości produktu, obecność programu pomiarowego pozwala organizacji na wdrożenie procesu oceny jakości produktu poprzez zdefiniowanie potrzeb jakościowych, charakterystyk jakościowych i wskaźników jakości. Produkty (pracy) są oceniane przy użyciu ilościowych kryteriów dla charakterystyk jakościowych takich jak: niezawodność, użyteczność i utrzymywalność. Jakość produktu jest pojmowana z punktu widzenia ilościowego i jest zarządzana zgodnie z określonymi celami przez cały cykl życia produktu.

Przeglądy i inspekcje są uważane za część procesu testowego i wykorzystywane do pomiaru jakości produktu na wczesnym etapie cyklu życia oraz jako formalne bramki kontroli jakości. Przeglądy koleżeńskie jako technika wykrywania defektów są przekształcane

w technikę pomiaru jakości produktu, zgodnie z obszarem procesowym Ocena jakości produktu.

Poziom TMMi 4 obejmuje również ustanowienie skoordynowanego podejścia do testów pomiędzy przeglądami koleżeńskimi (testowanie statyczne) a testowaniem dynamicznym oraz wykorzystanie wyników i danych z przeglądów koleżeńskich w celu optymalizacji podejścia do testów tak, aby zwiększyć skuteczność i efektywność testowania. Przeglądy koleżeńskie są odtąd w pełni zintegrowane z procesem testowania dynamicznego, np. stanowią część strategii testów, planu testów i podejścia do testów.

Obszary procesowe na poziomie TMMi 4 są następujące:

4.1      Pomiar testów

4.2      Ocena jakości produktów

4.3      Zaawansowane przeglądy

Poszczególne obszary zostały dokładniej omówione w kolejnych rozdziałach

PA 4.1      Pomiar testów

Cel

Celem obszaru procesowego Pomiar testów jest zidentyfikowanie, zgromadzenie, przeanalizowanie i zastosowanie miar, które umożliwią organizacji obiektywną ocenę skuteczności i efektywności procesu testowego, produktywności testerów, końcowej jakości produktu i wyników doskonalenia testów. W ramach tego obszaru organizacja testowa opracowuje i utrzymuje możliwości pomiaru testów w celu zaspokojenia potrzeb związanych

z informacjami wspomagającymi zarządzanie.

Uwagi wstępne

Osiągnięcie celów 2. i 3. poziomu TMMi przynosi korzyści w postaci wprowadzenia infrastruktury technicznej, zarządczej i kadrowej, zdolnej do dokładnego testowania

i zapewniającej wsparcie w usprawnianiu procesów testowych. Dzięki tej infrastrukturze można wdrożyć formalny program pomiaru testów, umożliwiający dalszy rozwój

i doskonalenie.

Pomiar testów to ciągły proces identyfikowania, gromadzenia i analizowania danych dotyczących zarówno procesu testowego, jak i tworzonych produktów. Jego celem jest określenie skuteczności i efektywności procesów testowych, a potencjalnie również procesów wytwarzania oprogramowania, oraz udostępnienie informacji umożliwiających zwiększenie skuteczności i efektywności. Dążąc do skutecznego wdrożenia programu pomiaru testów, specyfikuje się metody pomiaru i analizy oraz procesy gromadzenia, przechowywania, pobierania i przekazywania danych. Warto podkreślić, że program pomiaru testów koncentruje się na dwóch obszarach: wspiera ocenę procesu testowego i jakości produktów oraz wspiera doskonalenie procesów.

Jeśli program ma być skuteczny, musi zostać powiązany z celami biznesowymi, polityką testów i strategią testów [Van Solingen i Berghout]. Cele biznesowe to punkt wyjścia do definiowania celów pomiaru testów oraz metryk. Z celów biznesowych wyprowadzane są cele standardowego procesu testowego organizacji. Pomyślnie wdrożony program pomiaru testów staje się integralną częścią kultury testowania, a pomiary praktyką przyjmowaną

i stosowaną przez wszystkie grupy i zespoły uczestniczące w testowaniu. Pomiar testów to ciągły proces identyfikowania, gromadzenia i analizowania danych w celu udoskonalenia procesu testowego i podniesienia jakości produktów. Powinien umożliwić organizacji m.in. lepsze zaplanowanie przyszłych projektów oraz skuteczniejsze przeszkolenie pracowników. Mierzone wielkości związane z testami to np. koszty testowania, liczba wykonanych przypadków testowych, dane dotyczące defektów oraz miary produktowe, np. średni czas pomiędzy awariami.

Obszar procesowy Pomiar testów obejmuje następujące działania:

● Określenie celów pomiaru testów w taki sposób, aby były zgodne ze zidentyfikowanymi potrzebami informacyjnymi i celami biznesowymi

● Określenie technik pomiaru, analizy i walidacji, a także mechanizmów gromadzenia, przechowywania, pobierania i przekazywania danych oraz uzyskiwania informacji zwrotnych

● Wdrożenie mechanizmów gromadzenia, przechowywania, analizy i raportowania danych

● Udostępnianie obiektywnych rezultatów, które można wykorzystać do podjęcia świadomych decyzji i wykonania odpowiednich działań.

Na niższych poziomach TMMi sugerowane jest rozpoczęcie gromadzenia przez organizację danych związanych z procesem testowym, np. wskaźników wydajności testów

w ramach obszaru Polityka i strategia testów. Zaleca się w szczególności rozpoczęcie na niższych poziomach TMMi gromadzenia informacji pomiarowych związanych z defektami

w postaci prostego repozytorium defektów. Organizacja dążąca do uzyskania poziomu TMMi 4 będzie mieć potrzeby związane z dodatkowymi miarami przydatnymi do zwiększenia dojrzałości procesu testowego. W związku z takimi potencjalnymi potrzebami TMMi zaleca ustanowienie formalnego programu pomiarów testów jako celu do osiągnięcia na poziomie TMMi 4. W przypadku większości organizacji praktycznym rozwiązaniem może okazać się wdrożenie takiego programu jako uzupełnienia ogólnego programu pomiarów.

Na poziomie TMMi 4 lub wyższym czynności związane z pomiarem testów wykonywane są na poziomie organizacji i służą zaspokojeniu potrzeb informacyjnych organizacji. Pomiary testów stanowią jednak również wsparcie dla poszczególnych projektów dzięki udostępnieniu danych, np. w celu planowania celów i szacowania. Ponieważ dane są udostępniane w wielu projektach, często przechowuje się je w organizacyjnym repozytorium pomiarów testów.

Zakres

Obszar procesowy Pomiar testów obejmuje czynności pomiarowe prowadzone na poziomie organizacji. Jeśli w organizacji funkcjonuje wiele grup lub zespołów testowych, pomiary będą prowadzone w identyczny sposób we wszystkich grupach i zespołach w ramach ogólnego programu pomiaru testów. Obszar obejmuje takie praktyki jak definiowanie celów pomiaru, tworzenie planu pomiarów testów, gromadzenie danych, analizowanie danych

i raportowanie wyników. Uwzględnia również działania organizacji związane z pomiarem testów zdefiniowane na niższych poziomach TMMi, np. definiowanie wskaźników wydajności testów (konkretnego typu miar testowych) w ramach obszaru Polityka i strategia testów oraz praktyki ogólnej 3.2 Zbieranie informacji o usprawnieniach. Niniejszy obszar procesowy wspiera także pomiary na potrzeby innych obszarów procesowych poziomu TMMi 4, tj. Ocena jakości produktów i Zaawansowane przeglądy. Czynności związane z pomiarami na poziomie projektu, np. w ramach obszaru Monitorowanie i kontrola testów, będą nadal realizowane na poziomie projektu, jednak pojawią się interakcje z organizacyjnym obszarem procesowym Pomiar testów.

Podsumowanie celów i praktyk szczegółowych

SG 1       Uzgodnienie działań dotyczących pomiaru testów i analizy

SP 1.1       Określenie celów pomiaru testów

SP 1.2       Specyfikacja miar testowych

SP 1.3       Specyfikacja procedur gromadzenia i przechowywania danych

SP 1.4      Specyfikacja procedur analizy

SG 2       Udostępnienie wyników pomiarów testów

SP 2.1      Gromadzenie danych z pomiarów testów

SP 2.2      Analiza danych z pomiarów testów

SP 2.3      Poinformowanie o wynikach

SP 2.4      Przechowywanie danych i wyników

Praktyki szczegółowe dla poszczególnych celów

SG 1       Uzgodnienie działań dotyczących pomiaru testów i analizy

Cele i działania związane z pomiarem testów są uzgadniane ze zidentyfikowanymi celami

i potrzebami informacyjnymi.

SP 1.1       Określenie celów pomiaru testów

Określane są i utrzymywane cele pomiaru testów ustalone na podstawie zidentyfikowanych potrzeb informacyjnych i celów biznesowych.

Przykładowe produkty pracy

1.      Cele pomiaru testów

2.      Macierz śledzenia powiązań między potrzebami informacyjnymi a celami pomiaru testów

Podpraktyki

1.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w identyfikowaniu potrzeb informacyjnych

2.      Zidentyfikowanie i udokumentowanie potrzeb informacyjnych i celów pomiaru testów

z wykorzystaniem informacji przekazanych przez interesariuszy oraz pochodzących

z innych źródeł

3.      Określenie priorytetów potrzeb informacyjnych i celów pomiaru testów

Powiązanie wszystkich początkowo zidentyfikowanych potrzeb informacyjnych

z pomiarem testów i analizą może okazać się niewykonalne lub niecelowe. Wskazane może być uwzględnienie ograniczonej dostępności zasobów i ustalenie priorytetów.

4.      Przegląd i aktualizacja celów pomiaru testów

Cele pomiaru testów podlegają przeglądowi ze strony kierownictwa i innych istotnych interesariuszy, a następnie są w miarę potrzeby aktualizowane. Wśród interesariuszy powinny się znaleźć nie tylko osoby zgłaszające potrzeby informacyjne, ale również użytkownicy wyników pomiarów i analizy testów, a potencjalnie także osoby, które dostarczają danych pomiarowych.

5.      Utrzymywanie możliwości śledzenia powiązań między celami pomiaru testów

a zidentyfikowanymi potrzebami informacyjnymi

Zawsze musi istnieć konkretna odpowiedź na pytanie: - Dlaczego mierzymy tę wartość?

SP 1.2       Specyfikacja miar testowych

Specyfikowane są miary testowe umożliwiające realizację celów pomiaru testów.

Miary testowe mogą być miarami podstawowymi lub pochodnymi. Wartości miar podstawowych uzyskiwane są w wyniku bezpośrednich pomiarów. Wartości miar pochodnych wynikają z innych danych; zwykle stanowią połączenie wartości co najmniej dwu miar podstawowych.

Przykładowe produkty pracy

1.      Specyfikacja miar testowych

Podpraktyki

1.      Określenie miar testowych na podstawie udokumentowanych celów pomiaru testów

Przykładowe często używane miary testowe:

•      Szacowane i rzeczywiste koszty testów i pracochłonność testów

•      Szacowana i rzeczywista liczba przypadków testowych

•      Liczba defektów według ważności i/lub priorytetu

•      Łączna liczba defektów

•      Wskaźnik wykrywania defektów

•      Gęstość defektów

•      Zakres pokrycia przez przeglądy koleżeńskie

•      Pokrycie strukturalne, np. pokrycie kodu

•      Pokrycie wymagań

•      Miary niezawodności, np. średni czas pomiędzy awariami (MTBF) i średni czas do naprawy (MTTR)

•      Miary postępu testowania, np. wskaźnik liczby wykonywanych przypadków testowych

w tygodniu

2.      Udokumentowanie miar testowych z uwzględnieniem powiązanego celu pomiaru testów

3.      Określenie dokładnych i jednoznacznych definicji operacyjnych zidentyfikowanych miar testowych

4.      Przegląd i aktualizacja specyfikacji miar testowych

Proponowane specyfikacje miar testowych są poddawane przeglądowi w celu uzgodnienia ich trafności z udziałem potencjalnych użytkowników końcowych i innych istotnych interesariuszy, a następnie aktualizowane zgodnie z potrzebami.

SP 1.3       Specyfikacja procedur gromadzenia i przechowywania danych

Specyfikowane są konkretne metody gromadzenia danych tak, aby właściwe dane mogły być zbierane w odpowiedni sposób. W celu zapewnienia późniejszego dostępu do danych określane są również procedury ich przechowywania i pobierania.

Przykładowe produkty pracy

1.      Procedury gromadzenia i przechowywania danych

2.      Narzędzia do gromadzenia danych

Podpraktyki

1.      Wskazanie aktualnie niedostępnych danych pomiarowych dla zidentyfikowanych miar testowych

2.      Zidentyfikowanie istniejących źródeł danych

Istniejące źródła danych mogły zostać już zidentyfikowane podczas specyfikowania miar testowych.

3.      Określenie sposobów gromadzenia i przechowywania danych dla każdej wymaganej miary

Zapadają konkretne ustalenia, w jaki sposób, gdzie, kiedy i przez kogo będą gromadzone dane. Specyfikowane są procedury gromadzenia poprawnych danych.

Przykładowe zagadnienia, które należy uwzględnić w procedurach gromadzenia

i przechowywania:

•      Częstotliwość gromadzenia

•      Punkty w procesie, w których następuje gromadzenie danych

•      Harmonogramy i reguły zabezpieczeń związane z przechowywaniem danych

•      Obowiązki związane z uzyskiwanie danych i przechowywaniem danych (w tym ich bezpieczeństwem)

•      Odsyłacze do narzędzi pomocniczych

4.      Utworzenie mechanizmów gromadzenia danych i wskazówek dotyczących procesu

Mechanizmy gromadzenia danych mogą obejmować formularze i szablony wypełniane ręcznie lub tworzone automatycznie. Osobom odpowiedzialnym za realizację procesu zostaje udostępniony przejrzysty, zwięzły opis poprawnych procedur.

W zależności od celów pomiaru, powiązanych miar testowych i niezbędnych danych pomiarowych, może okazać się konieczne opracowanie szczegółowego schematu klasyfikacji defektów na potrzeby procesu pomiaru testów. Więcej informacji na temat schematu klasyfikacji defektów zawiera opis praktyki SP 1.1 Zdefiniowanie parametrów wyboru defektów i schematu klasyfikacji defektów z obszaru procesowego Zapobieganie defektom na poziomie TMMi 5.

5.      Wsparcie automatycznego gromadzenia danych, jeśli jest to wykonalne i celowe

6.      Przegląd procedur gromadzenia i przechowywania danych

W trakcie przeglądu proponowanych procedur weryfikuje się ich trafność i wykonalność. W przeglądzie biorą udział osoby odpowiedzialne za dostarczanie, gromadzenie

i przechowywanie danych.

7.      Aktualizacja miar testowych i celów pomiaru testów zgodnie z potrzebami

Może zajść konieczność ponownego ustalenia priorytetów w zależności od pracochłonności wymaganej do uzyskania danych. Należy również ustalić, czy

w związku z uzyskiwaniem danych będą niezbędne nowe formularze, narzędzia lub szkolenia.

SP 1.4       Specyfikacja procedur analizy

Z wyprzedzeniem specyfikowane są procedury analizy danych w celu zapewnienia możliwości prowadzenia właściwych analiz i raportowania wiarygodnych danych pomiarowych (w związku z realizacją udokumentowanych celów pomiaru testów).

Przykładowe produkty pracy

1.      Procedury analizy danych

2.      Narzędzia do analizy danych

Podpraktyki

1.      Specyfikacja prowadzonych analiz i przygotowywanych raportów

Analiza powinna mieć bezpośredni związek z udokumentowanymi celami pomiaru testów. Sposób prezentacji wyników powinien być jasny i zrozumiały dla interesariuszy, którzy są odbiorcami danych. Może zajść konieczność ponownego ustalenia priorytetów w zależności od dostępności zasobów.

2.      Wybór odpowiednich metod i narzędzi do analizy danych

Przykładowe zagadnienia, które należy wziąć pod uwagę w trakcie wyboru odpowiednich metod analizy danych oraz narzędzi:

•      Zestaw elementów graficznych i innych sposobów prezentacji (np. wykresy kołowe, wykresy słupkowe, histogramy, wykresy liniowe, wykresy punktowe, tabele)

•      Zestaw odpowiednich statystyk opisowych (np. średnia arytmetyczna lub mediana)

•      Decyzje dotyczące kryteriów próbkowania statystycznego, jeśli sprawdzenie każdego elementu danych jest niemożliwe lub niecelowe

•      Decyzje dotyczące sposobu przeprowadzenia analizy w przypadku braku elementów danych

•      Wybór odpowiednich narzędzi analitycznych

•      Sposób analizy rozkładów określonych miar testowych

•      Sposób analizy powiązań między określonymi miarami testowymi

3.      Określenie procedur administracyjnych dotyczących analizowania danych

i informowania o wynikach

4.      Przegląd i aktualizacja proponowanej treści i formatu określonych procedur analizy oraz raportów informacyjnych

5.      Aktualizacja miar testowych i celów pomiaru testów zgodnie z potrzebami

Podobnie jak w przypadku potrzeb dotyczących pomiarów, które wpływają na zakres analiz, wyjaśnienie kryteriów analizy może mieć wpływ na prowadzone pomiary. Specyfikacja niektórych miar może zostać uszczegółowiona w oparciu o specyfikacje procedur analizy danych. Z kolei inne miary mogą się okazać zbędne albo pojawi się potrzeba utworzenia dodatkowych miar.

SG 2       Udostępnienie wyników pomiarów testów

Udostępniane są wyniki pomiarów testów istotne z punktu widzenia zidentyfikowanych potrzeb informacyjnych i celów.

SP 2.1       Gromadzenie danych z pomiarów testów

Uzyskiwane są dane z pomiarów testów niezbędne do przeprowadzenia analizy i następuje sprawdzenie ich kompletności oraz integralności.

Przykładowe produkty pracy

1.      Zestawy danych z pomiarów testów

2.      Rezultaty testów integralności danych

Podpraktyki

1.      Zgromadzenie danych pomiarowych z rejestrów projektu lub z innych źródeł

w organizacji

2.      Wygenerowanie danych na potrzeby pochodnych miar testowych i obliczenie wartości tych miar

3.      Przeprowadzenie kontroli integralności danych możliwie najbliżej źródła danych

Wszystkie pomiary mogą być obarczone błędem związanym z określaniem lub rejestrowaniem danych. W każdym przypadku zalecane jest zidentyfikowanie takich błędów i źródeł brakujących danych na wczesnych etapach cyklu pomiaru i analizy. Kontrola może polegać na wykrywaniu brakujących danych, wartości danych spoza zakresu, nietypowych wzorców

i braku korelacji między miarami.

SP 2.2       Analiza danych z pomiarów testów

Zgromadzone dane z pomiarów testów są analizowane zgodnie z planem. Jeśli to konieczne, prowadzona jest także dodatkowa analiza danych.

Przykładowe produkty pracy

1.      Wyniki analizy

2.      Robocze wersje raportów z pomiaru testów

Podpraktyki

1.      Przeprowadzenie wstępnej analizy, interpretacja wyników i wyciągnięcie wstępnych wniosków

2.      Przeprowadzenie dodatkowych pomiarów i analizy zgodnie z potrzebami oraz przygotowanie prezentacji wyników

Ze względu na uzyskane wyniki może pojawić się sugestia (lub konieczność) przeprowadzenia dodatkowej, nieprzewidzianej wcześniej analizy.

3.      Przegląd wstępnych wyników z udziałem odpowiednich interesariuszy

Wskazane jest dokonanie przeglądu wstępnej interpretacji wyników i sposobu ich prezentacji przed rozpowszechnieniem wyników i udostępnieniem informacji szerszemu gronu odbiorców. Przegląd tego rodzaju pozwoli uniknąć niepotrzebnych nieporozumień oraz usprawnić procesy analizy danych i informowania o wynikach.

SP 2.3       Poinformowanie o wynikach

Wyniki działań związanych z pomiarem testów są przekazywane wszystkim odpowiednim interesariuszom.

Przykładowe produkty pracy

1.      Raporty z pomiaru testów i powiązane wyniki analizy

Podpraktyki

1.      Informowanie odpowiednich interesariuszy o wynikach pomiarów testów w odpowiednim terminie

2.      Udzielenie odpowiednim interesariuszom pomocy w interpretacji wyników

Przykłady działań związanych z pomocą w interpretacji wyników:

•      Omówienie wyników z odpowiednimi interesariuszami na sesjach roboczych

•      Udostępnienie notatki informacyjnej prezentującej założenia i wyjaśnienia

•      Poinformowanie użytkowników o wynikach

•      Przeprowadzenie szkoleń na temat sposobów właściwego wykorzystania wyników pomiarów testów oraz ich znaczenia

3.      Zdefiniowanie działań naprawczych i usprawniających na podstawie przeanalizowanych wyników pomiarów testów

SP 2.4       Przechowywanie danych i wyników

Dane z pomiarów testów, specyfikacje miar i wyniki analizy są przechowywane i podlegają zarządzaniu.

Przykładowe produkty pracy

1.       Zapisana (i przechowywana) baza danych dotyczących pomiarów testów, zawierająca m.in. plany pomiarów, specyfikacje miar, zbiory zgromadzonych danych, raporty

z analizy i prezentacje

Podpraktyki

1.      Przegląd danych pomiarowych w celu sprawdzenia ich kompletności, integralności, poprawności i aktualności

2.      Przechowywanie danych z pomiarów testów zgodnie z procedurami przechowywania danych

3.      Ograniczenie dostępu do danych i przyznanie go tylko właściwym grupom i osobom

4.      Ochrona przechowywanych informacji przed niewłaściwym wykorzystaniem, np. za pomocą kontroli dostępu do danych z pomiarów testów

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Pomiar testów.

Opracowanie

Polityka określa oczekiwania organizacji dotyczące uzgodnienia celów pomiaru testów

i działań na poziomie organizacji ze zidentyfikowanymi potrzebami informacyjnymi i celami,

a także oczekiwania dotyczące udostępniania wyników pomiarów. Polityka pomiaru testów powinna określać takie elementy, jak cel procesu, cel pomiarów, osoby korzystające

z pomiarów, zakładane inwestycje organizacji w proces pomiaru testów, potencjalne korzyści, szczeble zarządzania wspierające proces oraz priorytet procesu pomiaru testów.

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Pomiar testów.

Opracowanie

Plan realizacji procesu pomiaru testów może zostać uwzględniony (lub przywołany) w planie doskonalenia procesu testowego (opisanym w ramach obszaru procesowego Organizacja testowa) lub w planie jakości organizacji.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Pomiar testów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

•      Zapewniono odpowiedni czas na wykonanie czynności związanych z pomiarem testów

•      Osoby zajmujące się pomiarami mogą być zatrudnione w pełnym lub niepełnym wymiarze czasowym. Może (ale nie musi) zostać powołana grupa ds. pomiaru testów

(w ramach organizacji testowej), wspierająca realizację czynności związanych

z pomiarem testów w wielu projektach.

•      Dostępne są narzędzia wspierające czynności związane z pomiarem testów

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Pomiar testów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Pomiar testów.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Pomiar testów zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

● Pojęcia związane z jakością i pomiarami

● Techniki statystyczne

● Procesy gromadzenia, analizy i raportowania danych

● Tworzenie miar związanych z celami (np. podejście Cel Pytanie Metryka)

● Problemy związane z osobami fizycznymi (ludzie zwykle nie chcą być przedmiotem pomiarów)

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Pomiar testów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Specyfikacje podstawowych i pochodnych miar testowych

•      Procedury gromadzenia i przechowywania danych

•      Zbiory danych związane z miarami podstawowymi i pochodnymi

•      Wyniki analizy i raporty

•      Narzędzia do analizy danych

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Pomiar testów zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Uzyskanie informacji o potrzebach informacyjnych i celach

•      Zdefiniowanie procedur

•      Przegląd i uzgodnienie definicji pomiarów

•      Ocena danych z pomiarów testów

•      Przekazywanie konkretnych informacji zwrotnych osobom odpowiedzialnym za dostarczanie surowych danych, od których zależy analiza i wyniki

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Pomiar testów (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Pomiar testów:

•      Odsetek projektów, które przekazują dane na potrzeby określenia miar testowych

•      Odsetek uwzględnionych celów pomiaru

•      Realizacja harmonogramu gromadzenia i przeglądu danych pomiarowych

•      Liczba przeprowadzonych sesji roboczych dotyczących wyników pomiarów testów

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Pomiar testów oraz wybranych produktów pracy

z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Uzgodnienie działań dotyczących pomiaru testów i analizy

•      Udostępnienie wyników pomiaru testów

•      Specyfikacje podstawowych i pochodnych miar testowych

•      Procedury gromadzenia i przechowywania danych

•      Wyniki analizy i raporty

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Pomiar testów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Pomiar testów.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Pomiar testów, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Przykładowe miary:

•      Status aktualności danych

•      Rezultaty testów integralności danych

•      Koszty narzędzi i szkoleń dotyczących pomiarów

•      Koszty utrzymywania bazy danych pomiarów testów

•      Poziom zadowolenia odbiorców z raportów dotyczących pomiarów

•      Stopień wykorzystania danych pomiarowych

PA 4.2      Ocena jakości produktów

Cel

Celem obszaru procesowego Ocena jakości produktów jest opracowanie ilościowego opisu jakości produktów i wsparcie realizacji konkretnych celów związanych z jakością produktów w poszczególnych projektach.

Uwagi wstępne

Ocena jakości produktów obejmuje definiowanie ilościowych celów związanych

z jakością produktów i tworzenie planów osiągnięcia takich celów. Jednym z elementów obszaru jest także definiowanie metryk jakości, umożliwiających przeprowadzenie oceny jakości produktu (pracy). Plany, produkty, wykonywane czynności i status jakości produktów podlegają monitorowaniu i są w miarę potrzeby aktualizowane. Ogólnym celem tych działań jest przyczynienie się do zaspokojenia potrzeb i spełnienia wymagań zgłaszanych przez klientów i użytkowników końcowych, a dotyczących jakości produktów.

Praktyki wskazane w obszarze Ocena jakości produktów opierają się na praktykach obszarów procesowych 2. i 3. poziomu dojrzałości TMMi. W ramach obszarów procesowych Projektowanie i wykonywanie testów, Monitorowanie i kontrola testów oraz Testowanie niefunkcjonalne ustanawiane są i wdrażane najważniejsze praktyki związane

z projektowaniem i pomiarem testów na poziomie projektu. Obszar Pomiar testów ustanawia ilościowy opis zdolności projektu do uzyskania pożądanych rezultatów z zastosowaniem standardowego procesu testowego organizacji.

W niniejszym obszarze procesowym określane są cele ilościowe dla produktów

w oparciu o potrzeby organizacji, klientów i użytkowników końcowych. Aby możliwe było osiągnięcie takich celów, organizacja opracowuje strategie i plany, a projekty odpowiednio dostosowują swoje zdefiniowane procesy testowe pod kątem celów związanych z jakością.

Zakres

Obszar procesowy Ocena jakości produktów obejmuje praktyki na poziomie projektu umożliwiające ilościowy opis tworzonych produktów i osiągnięcie wymiernych celów związanych z jakością tych produktów. Podczas definiowania celów i praktyk dla tego obszaru należy uwzględnić zarówno funkcjonalne, jak i niefunkcjonalne charakterystyki jakościowe. Obszar Ocena jakości produktów jest w znacznym stopniu wspierany przez obszar Pomiar testów, który pozwala stworzyć infrastrukturę pomiarów.

Podsumowanie celów i praktyk szczegółowych

SG 1       Określenie wymiernych celów projektu (z ustalonymi priorytetami) związanych

z jakością produktów

SP 1.1       Zidentyfikowanie potrzeb związanych z jakością produktów

SP 1.2       Zdefiniowanie ilościowych celów projektu związanych z jakością produktów

SP 1.3       Zdefiniowanie podejścia do mierzenia postępu realizacji celów projektu związanych z jakością produktów

SG 2       Ilościowe określenie rzeczywistego postępu realizacji celów projektu związanych z jakością produktów i zarządzanie postępem realizacji

SP 2.1       Ilościowy pomiar jakości produktów w trakcie całego cyklu wytwarzania

SP 2.2       Analiza pomiarów jakości produktu i porównywanie jej ze zdefiniowanymi celami ilościowymi

Praktyki szczegółowe dla poszczególnych celów

SG 1      Określenie wymiernych celów projektu (z ustalonymi priorytetami) związanych z jakością produktów

Określany jest i utrzymywany zestaw wymiernych celów związanych z jakością produktów

(z ustalonymi priorytetami).

SP 1.1       Zidentyfikowanie potrzeb związanych z jakością produktów

Identyfikowane są potrzeby związane z jakością produktów projektu i określane są ich priorytety.

Przykładowe produkty pracy

1.       Lista zidentyfikowanych potrzeb związanych z jakością produktów projektu

(z określonymi priorytetami)

Podpraktyki

1.      Przegląd celów organizacji związanych z jakością produktów

Celem przeglądu jest zrozumienie przez interesariuszy szerszego kontekstu biznesowego, w którym będzie realizowany projekt. Cele projektu związane z jakością produktów definiuje się w kontekście takich ogólnych celów organizacji.

2.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w identyfikowaniu potrzeb związanych z jakością produktów projektu

3.      Ustalenie potrzeb związanych z jakością produktów na podstawie informacji przekazanych przez interesariuszy i innych źródeł

Przykładowe sposoby ustalenia potrzeb związanych z jakością produktów:

•      Ankiety

•      Kwestionariusze [Pinkster], [Trienekens i Van Veenendaal]

•      Grupy fokusowe

•      Ocena produktu wykonywana przez użytkowników

•      Metoda Quality Function Deployment (metoda rozwinięcia funkcji jakości) [Hauser

i Clausing]

•      Burze mózgów

Przykładowe źródła informacji o potrzebach związanych z jakością produktów:

•      Wymagania, np. wymagania niefunkcjonalne

•      Cele organizacji związane z jakością produktów

•      Cele klienta związane z jakością produktów

•      Cele biznesowe

•      Badania rynku

•      Docelowe poziomy jakości zdefiniowane w polityce testów

•      Proces zapewnienia jakości i jego rezultaty

•      Umowy dotyczące poziomu usług

4.      Analiza i określenie priorytetów zidentyfikowanego zbioru potrzeb związanych z jakością produktów

5.      Rozstrzygnięcie konfliktów między poszczególnymi potrzebami (np. gdy jednej z nich nie da się zaspokoić bez uszczerbku dla realizacji innej potrzeby)

6.      Ustalenie możliwości śledzenia powiązań między potrzebami związanymi z jakością produktów projektu a ich źródłami

7.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności i priorytetu potrzeb związanych z jakością produktów

8.      Aktualizacja potrzeb związanych z jakością produktów w odpowiednim zakresie

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji potrzeb związanych z jakością produktów:

•      Nowe lub zmieniające się wymagania

•      Zmiana rozumienia potrzeb związanych z jakością produktów przez klientów

i użytkowników końcowych

•      Wyciągnięcie wniosków z występujących w projekcie problemów dotyczących jakości produktów

SP 1.2       Zdefiniowanie ilościowych celów projektu związanych z jakością produktów

Ilościowe cele projektu związane z jakością produktów są definiowane na podstawie potrzeb związanych z jakością produktów projektu.

Przykładowe produkty pracy

1.      Lista zidentyfikowanych ilościowych celów danego projektu związanych z jakością

(z ustalonymi priorytetami)

2.      Pośrednie ilościowe cele związane z jakością produktów (np. dla poszczególnych faz cyklu wytwarzania)

Podpraktyki

1.      Zidentyfikowanie atrybutów jakości produktów, które są wymagane do zaspokojenia potrzeb związanych z jakością produktów projektu

Przykładowe atrybuty jakości produktów [wg ISO/IEC 25010]:

•      Funkcjonalność

•      Wydajność

•      Kompatybilność

•      Funkcjonalność

•      Użyteczność

•      Niezawodność

•      Zabezpieczenia

•      Utrzymywalność

•      Przenaszalność

2.      Określenie priorytetów zidentyfikowanego zestawu charakterystyk jakościowych produktów na podstawie priorytetów potrzeb związanych z jakością produktów

3.      Zdefiniowanie celów ilościowych dla każdego z wybranych charakterystyk jakościowych produktów.

W ramach tej podpraktyki wybrane charakterystyki jakościowe produktu są często dzielone na atrybuty podrzędne. Dla każdego celu związanego z jakością identyfikuje się mierzalne wartości liczbowe na podstawie wartości wymaganych i pożądanych [Gilb]. Cele związane z jakością będą traktowane jako kryteria akceptacji projektu

4.      Ocena możliwości realizacji celów związanych z jakością produktów w ramach zdefiniowanego w projekcie procesu

5.      Zdefiniowanie pośrednich, ilościowych celów związanych z jakością produktów dla poszczególnych faz cyklu wytwarzania i odpowiednich produktów pracy (zgodnie

z potrzebami), w celu monitorowania postępu realizacji celów projektu związanych

z jakością produktów.

Pośrednie cele związane z jakością posłużą jako kryteria wyjścia z odpowiednich faz cyklu wytwarzania

6.      Przydzielenie celów związanych z jakością produktów projektu do odpowiednich podwykonawców (jeśli zachodzi taka potrzeba)

7.      Określenie dokładnych i jednoznacznych definicji operacyjnych zidentyfikowanych (pośrednich) celów związanych z jakością produktów

8.      Ustalenie możliwości śledzenia powiązań między ilościowymi celami projektu związanymi z jakością produktów a potrzebami związanymi z jakością produktów projektu

9.      Aktualizacja celów związanych z jakością produktów w odpowiednim zakresie

SP 1.3       Zdefiniowanie podejścia do mierzenia postępu realizacji celów projektu związanych z jakością produktów

Definiowane jest podejście do mierzenia stopnia realizacji zdefiniowanego zestawu celów związanych z jakością produktów.

Informacje na temat sposobów definiowania miar można znaleźć w opisie obszaru procesowego Pomiar testów.

Przykładowe produkty pracy

1.      Podejście do mierzenia jakości produktów

2.      Definicje używanych technik pomiaru (testów)

Podpraktyki

1.       Wybór technik pomiaru (testów) używanych do mierzenia postępu realizacji (pośrednich) celów związanych z jakością produktów

Przykładowe techniki pomiaru (testów):

•      Przeglądy koleżeńskie

•      Tworzenie prototypów

•      Analiza statyczna (kodu)

•      Testowanie dynamiczne

•      Liczba defektów wykrytych w ramach testowania wytwórczego (przewidywanie defektów wykrytych w późniejszych fazach cyklu wytwarzania)

2.      Zdefiniowanie punktów w ramach cyklu wytwarzania, takich jak poziomy testów,

w których zostaną zastosowane wybrane techniki pomiaru jakości produktów

3.      Specyfikacja procedur gromadzenia i przechowywania danych

Więcej informacji na temat procedur gromadzenia i przechowywania danych można znaleźć w opisie obszaru procesowego Pomiar testów.

4.      Wybór technik analizy używanych do analizowania danych pomiarowych dotyczących jakości produktów

5.      Określenie narzędzi wspierających pomiary (testów)

6.      Zidentyfikowanie istotnych ograniczeń definiowanego podejścia

Przykładowe ograniczenia definiowanego podejścia:

•      Ograniczenia związane z jakością danych źródłowych

•      Ograniczenia związane z harmonogramem pozyskiwania danych pomiarowych wynikające z równocześnie realizowanych etapów cyklu wytwarzania

•      Techniki pomiaru testów i/lub techniki analizy danych wymagające konkretnych kompetencji

•      Ograniczenia dotyczące budżetu i zasobów

•      Ograniczenia dotyczące środowiska testowego

7.      Przegląd i uzyskanie zgody interesariuszy w kwestii podejścia do mierzenia jakości produktów

8.      Aktualizacja podejścia do mierzenia jakości produktów zgodnie z potrzebami

SG 2       Ilościowe określenie rzeczywistego postępu realizacji celów projektu związanych z jakością produktów i zarządzanie postępem realizacji

Projekt podlega monitorowaniu w celu sprawdzenia, czy realizowane są cele związane

z jakością produktów, oraz określenia ewentualnych działań naprawczych.

SP 2.1       Ilościowy pomiar jakości produktów w trakcie całego cyklu wytwarzania

Jakość danego produktu i produktów pracy tworzonych w projekcie podlega pomiarom ilościowym zgodnie ze zdefiniowanym podejściem w trakcie całego cyklu wytwarzania.

Przykładowe produkty pracy

1.      Zestawy danych z pomiarów jakości produktów

2.      Rezultaty testów integralności danych dotyczących jakości produktów

Podpraktyki

1.       Wykonywanie pomiarów jakości produktów pracy zgodnie z wybranymi technikami pomiaru (testów) i zdefiniowanym podejściem, w zdefiniowanych punktach cyklu wytwarzania

Przykładowe produkty pracy:

•      Dokumentacja wymagań

•      Dokumentacja projektowa

•      Specyfikacje interfejsów

•      Prototypy

•      Kod

•      Poszczególne moduły

2.      Wykonywanie pomiarów jakości produktów zgodnie z wybranymi technikami pomiaru (testów) i zdefiniowanym podejściem

3.      Gromadzenie danych z pomiarów jakości produktów zgodnie z potrzebami

4.      Przegląd danych z pomiarów jakości produktów w celu zapewnienia ich jakości

Przykładowe atrybuty jakości danych pomiarowych:

•      Kompletność

•      Integralność

•      Poprawność

•      Aktualność

5.      Aktualizacja podejścia do mierzenia jakości produktów oraz miar jakości produktów zgodnie z potrzebami

SP 2.2       Analiza pomiarów jakości produktu i porównywanie jej ze zdefiniowanymi celami ilościowymi

Wyniki (pośrednich) pomiarów jakości produktów są analizowane i porównywane

z (pośrednimi) celami projektu związanymi z jakością produktów (okresowo i po wystąpieniu określonych zdarzeń).

Przykładowe produkty pracy

1.      Wyniki analizy

2.      Raport dotyczący pomiarów jakości produktów

3.      Udokumentowane wyniki przeglądu jakości produktów, np. protokoły ze spotkań

4.      Lista problemów związanych z jakością produktów, wymagających podjęcia działań naprawczych

Podpraktyki

1.      Przeprowadzenie wstępnej analizy (pośrednich) pomiarów jakości produktów

Więcej informacji na temat analizy danych można znaleźć w opisie obszaru procesowego Pomiar testów.

2.      Porównanie miar jakości produktów z celami projektu związanymi z jakością produktów i wyciągnięcie wstępnych wniosków

Jeśli wartość metryki wskazuje na niską jakość produktu, należy taką sytuację dokładniej przeanalizować.

3.      Przeprowadzenie dodatkowych pomiarów jakości produktów i analizy zgodnie

z potrzebami oraz przygotowanie wyników do opublikowania

4.      Przekazanie wyników pomiarów jakości produktów i informacji o poziomie realizacji (pośrednich) ilościowych celów związanych z jakością produktów odpowiednim interesariuszom we właściwym terminie

5.      Przegląd wyników pomiarów jakości produktów i informacji o poziomie realizacji (pośrednich) ilościowych celów związanych z jakością produktów z udziałem odpowiednich interesariuszy

6.      Zidentyfikowanie i udokumentowanie istotnych problemów dotyczących jakości produktów oraz ich wpływu

7.      Zdefiniowanie działań naprawczych podejmowanych na podstawie przeanalizowanych wyników pomiaru jakości produktów

8.      Zarządzanie działaniami naprawczymi do zamknięcia problemu

Więcej informacji na temat zarządzania działaniami naprawczymi do zamknięcia problemu zawiera opis celu SG 3 Zarządzanie działaniami naprawczymi do zamknięcia problemu z obszaru procesowego Monitorowanie i kontrola testów.

9.       Aktualizacja celów związanych z jakością produktów i podejścia do mierzenia jakości produktów zgodnie z potrzebami

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Ocena jakości produktów.

Opracowanie

Polityka dotycząca oceny jakości produktów zwykle zawiera następujące ustalenia:

•      Działania związane z oceną jakości produktów wspierają realizację zobowiązań organizacji do podnoszenia jakości produktów

•      W projekcie definiowane są miary i gromadzone są wartości pomiarów używane do oceny jakości produktów zgodnie ze zdefiniowanym procesem (testowym) projektu

•      W projekcie definiowane są ilościowe cele związane z jakością produktów i odbywa się monitorowanie rzeczywistego postępu ich realizacji

•      Definiowane są obowiązki związane z oceną jakości produktów, które przydzielane są grupie testowej i innym powiązanym grupom, np. osobom odpowiedzialnym za zapewnienie jakości i/lub zarządzanie konfiguracją

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Ocena jakości produktów.

Opracowanie

Zwykle plan realizacji procesu oceny jakości produktów jest uwzględniany w planie testów, co zostało opisane w obszarze procesowym TMMi o nazwie Planowanie testów. Czynności związane z oceną jakości produktów, np. definiowanie celów jakościowych oraz czynności związane z pomiarami (testów) są bezpośrednio uwzględniane w harmonogramie w ramach planu. Opcjonalnie plan realizacji procesu oceny jakości produktów może zostać uwzględniony w planie jakości projektu.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Ocena jakości produktów, wytworzenia produktów pracy testowania oraz realizacji usług związanych z procesem.

Opracowanie

•      Zapewniono odpowiedni czas na wykonanie czynności związanych z oceną jakości produktów

•      W trakcie definiowania celów i miar związanych z jakością oraz wyboru technik pomiaru (testów) może okazać się niezbędna pomoc specjalistów w dziedzinie pomiarów

i testowania niefunkcjonalnego (np. testowania wydajności, bezpieczeństwa

i niezawodności). Takie osoby mogą również pomagać w analizie i interpretacji zgromadzonych danych.

•      Dostępne są narzędzia wspierające czynności związane z oceną jakości produktów

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Ocena jakości produktów, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Ocena jakości produktów.

Podczas definiowania zakresu odpowiedzialności za ten obszar procesowy należy jasno określić rolę i zakres odpowiedzialności zespołu ds. zapewnienia jakości. Zespół ten standardowo zajmuje się definiowaniem celów związanych z jakością procesów i produktów oraz oceną realizacji takich celów w projekcie.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Ocena jakości produktów zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

•      Cele ilościowych metod zarządzania jakością produktów i związane z nimi korzyści

•      Pomiary jakości produktów

•      Metody definiowania i wyboru miar oraz gromadzenia wyników pomiarów

•      Charakterystyki jakościowe (np. wg ISO/IEC 25010)

•      Metody i techniki określania potrzeb związanych z jakością produktów

•      Techniki pomiaru jakości produktów

•      Pomocnicze narzędzia pomiarowe

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Ocena jakości produktów odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Dokumentacja potrzeb związanych z jakością produktów

•      Definicja celów związanych z jakością produktów, miar operacyjnych i punktów gromadzenia danych w procesach

•      Zgromadzone wyniki pomiarów

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Ocena jakości produktów zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Określanie potrzeb związanych z jakością produktów

•      Przeglądy potrzeb związanych z jakością produktów, celów jakościowych i podejścia do pomiaru testów

•      Ocena bieżącej jakości produktów w porównaniu z celami jakościowymi

•      Przegląd uzyskanej jakości produktów

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Ocena jakości produktów (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Ocena jakości produktów:

•      Odsetek celów jakościowych dotyczących produktów, które są realizowane w projektach

•      Odsetek celów jakościowych dotyczących produktów, które są mierzone w projektach

•      Harmonogram działań gromadzenia danych, raportowania i analizy związanych z celami jakościowymi dotyczącymi produktów

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Ocena jakości produktów oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Definicja ilościowych celów związanych z jakością produktów

•      Zgromadzone wyniki pomiarów

•      Informacje w planie testów dotyczące działań do wykonania związanych z oceną jakości produktów

•      Proces określania i monitorowania celów związanych z jakością produktów

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Ocena jakości produktów z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Ocena jakości produktów.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Ocena jakości produktów, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

Przykładowe miary:

•      Koszty związane z niską jakością produktów

•      Koszty realizacji celów związanych z jakością produktów

PA 4.3      Zaawansowane przeglądy

Cel

Celem obszaru procesowego Zaawansowane przeglądy, opartego na praktykach związanych z obszarem procesowym Przeglądy koleżeńskie określonym na poziomie TMMi 3, jest pomiar jakości produktów na wczesnych etapach cyklu życia oraz rozszerzenie strategii testów i podejścia do testów poprzez połączenie przeglądów koleżeńskich (testowania statycznego) z testowaniem dynamicznym.

Uwagi wstępne

Przyjęta definicja testowania wyraźnie stwierdza, że jest to „proces składający się ze wszystkich czynności cyklu życia, zarówno statycznych, jak i dynamicznych, skoncentrowany na planowaniu, przygotowaniu i ewaluacji oprogramowania oraz powiązanych produktów pracy”. Taki opis procesu wynikający z ewolucyjnego modelu testowania [Gelperin i Hetzel] podkreśla fakt, że testowanie powinno obejmować zarówno walidację, jak i weryfikację oraz zarówno analizę statyczną, jak i analizę dynamiczną. W związku z tym przeglądy są traktowane jako nieodłączny element procesu testowania, stanowiący technikę weryfikacji, walidacji i analizy statycznej. Na poziomie TMMi 4 ten punkt widzenia został uzupełniony

o skoordynowane podejście do zarządzania przeglądami koleżeńskimi (testowaniem statycznym) i testowaniem dynamicznym. Skoordynowane podejście do testów obejmujące testowanie statyczne i dynamiczne zwykle pozwala zwiększyć skuteczność i efektywność. Jest to rozszerzenie procesu przeglądów koleżeńskich w stosunku do poziomu TMMi 3, na którym przeglądy są wprawdzie prowadzone, jednak nie są skoordynowane z testowaniem dynamicznym.

Przeglądy koleżeńskie jako odrębny proces są skutecznym sposobem identyfikowania defektów i ryzyk produktowych, zanim dany produkt zostanie skonstruowany. Dzięki połączeniu przeglądów koleżeńskich i testowania dynamicznego wyniki wcześnie przeprowadzonego przeglądu i uzyskane dane mogą wpłynąć na przyjęte podejście do testów. Zgodnie z zasadą testowania dotyczącą kumulowania się defektów [Graham], analiza typów

i liczby defektów wykrytych podczas przeglądów może ułatwić wybór najskuteczniejszych testów i wpłynąć na podejście do testów, a nawet na cele testów. Zwykle w momencie osiągnięcia kamieni milowych projektu następuje ocena przyjętego podejścia do testów i jego ewentualna aktualizacja. Dane uzyskane w wyniku przeglądów koleżeńskich powinny być jednym z elementów branych pod uwagę w przypadku takiej aktualizacji.

Na poziomie TMMi 4 organizacja określa ilościowe cele dotyczące oprogramowania

i powiązanych produktów pracy. Przeglądy koleżeńskie odgrywają kluczową rolę w realizacji tych celów. Na poziomie TMMi 3 przeglądy prowadzi się głównie w celu wykrycia defektów, jednak tutaj najbardziej istotne staje się mierzenie jakości produktów (dokumentów). Prowadzenie przeglądów koleżeńskich, oparte na praktykach stosowanych na poziomie TMMi 3, zostaje wzbogacone o dodatkowe praktyki, takie jak próbkowanie, stosowanie kryteriów wyjścia i określanie reguł. W celu zwiększenia wiarygodności pomiarów stosowane są zaawansowane techniki wykrywania defektów, np. czytanie oparte na perspektywie [Veenendaal]. Wyniki pomiarów są również wykorzystywane przez kierownictwo (projektu) do kontrolowania jakości produktów na wczesnych etapach cyklu wytwarzania (więcej informacji na temat mierzenia jakości produktów i zarządzania nią można znaleźć w opisie obszaru procesowego Ocena jakości produktów).

Zakres

Obszar procesowy Zaawansowane przeglądy opiera się na praktykach obszaru procesowego Przeglądy koleżeńskie zdefiniowanego na poziomie TMMi 3. Obejmuje praktyki związane z ustanowieniem skoordynowanego podejścia do testów łączącego przeglądy koleżeńskie z testowaniem dynamicznym oraz wykorzystującego wyniki i dane z tych przeglądów w celu optymalizacji podejścia do testów. Na poziomie dojrzałości TMMi 4 przeglądy koleżeńskie są w pełni zintegrowane z procesem testowania dynamicznego i np. są częścią strategii testów, planu testów i podejścia do testów. Obszar procesowy Zaawansowane przeglądy uwzględnia także praktyki umożliwiające zmianę roli przeglądów, które przestają być jedynie techniką wykrywania defektów, a stają się techniką pomiaru jakości produktów zgodną z obszarem procesowym Ocena jakości produktów. Te praktyki to m.in. próbkowanie dokumentów, definiowanie reguł, ścisłe kryteria wyjścia i czytanie oparte na perspektywie.

Podsumowanie celów i praktyk szczegółowych

SG 1       Skoordynowanie podejścia do prowadzenia przeglądów koleżeńskich

z podejściem do testowania dynamicznego

SP 1.1       Powiązanie produktów pracy z elementami i funkcjami podlegającymi testowaniu

SP 1.2       Zdefiniowanie skoordynowanego podejścia do testów

SG 2       Mierzenie jakości produktów na wczesnych etapach cyklu wytwarzania

z wykorzystaniem przeglądów koleżeńskich

SP 2.1      Zdefiniowanie wytycznych dotyczących pomiarów w przeglądach koleżeńskich

SP 2.2      Zdefiniowanie kryteriów przeglądów koleżeńskich na podstawie celów związanych z jakością produktów

SP 2.3       Pomiar jakości produktów pracy za pomocą przeglądów koleżeńskich

SG 3       Modyfikacja podejścia do testów na podstawie wyników przeglądów na wczesnych etapach cyklu wytwarzania

SP 3.1       Analiza wyników przeglądów koleżeńskich

SP 3.2      Aktualizacja ryzyk produktowych zgodnie z potrzebami

SP 3.3      Aktualizacja podejścia do testów zgodnie z potrzebami

SG 1       Skoordynowanie podejścia do prowadzenia przeglądów koleżeńskich

z podejściem do testowania dynamicznego

Podejście do prowadzenia przeglądów koleżeńskich (testowania statycznego) jest uzgadniane z podejściem do testowania dynamicznego.

SP 1.1       Powiązanie produktów pracy z elementami i funkcjami podlegającymi testowaniu

Dla elementów i funkcji podlegających testowaniu zgodnie z ustalonym podejściem do testów identyfikowane są powiązane z nimi produkty pracy.

Przykładowe produkty pracy

1.      Macierz śledzenia elementów testowych i funkcji oprogramowania do produktów pracy

Podpraktyki

1.      Przegląd raportu dotyczącego ryzyka produktowego w projekcie

Raport dotyczący ryzyka produktowego w projekcie, wraz z odpowiednimi uzasadnieniem, jest poddawany przeglądowi w celu szczegółowej analizy zidentyfikowanych ryzyk produktowych i ustalenia znaczenia elementów i funkcji podlegających testowaniu.

Więcej informacji na temat analizy ryzyka produktowego zawiera opis celu SG 1 Wykonanie oceny ryzyka produktowego z obszaru procesowego Planowanie testów.

2.      Przegląd struktury podziału pracy nad produktami zdefiniowanej w planie projektu

Struktura podziału pracy nad produktami zdefiniowana w planie projektu jest poddawana przeglądowi w celu uzyskania szczegółowych informacji o zidentyfikowanych produktach pracy i ich związku z produktami końcowymi projektu, a w rezultacie z elementami

i funkcjami podlegającymi testowaniu.

3.      Ustalenie możliwości śledzenia powiązań między elementami a funkcjami podlegającymi testowaniu a produktami pracy

Produkty pracy stanowiące potencjalnie przedmiot przeglądów są łączone za pomocą macierzy śledzenia z elementami i funkcjami podlegającymi testowaniu zidentyfikowanymi w ramach analizy ryzyka produktowego w projekcie.

SP 1.2       Zdefiniowanie skoordynowanego podejścia do testów

Definiowane jest podejście do testów uwzględniające testowanie statyczne i testowanie dynamiczne.

Przykładowe produkty pracy

1.      Lista produktów pracy poddawanych przeglądom

2.      Skoordynowane podejście do testów udokumentowane w (głównym) planie testów

3.      Udokumentowane zobowiązania

Podpraktyki

1.      Zidentyfikowanie produktów pracy projektu i produktów pracy związanych

z testowaniem, które należy poddać przeglądom

Z listy produktów pracy wybierane do przeglądu są te produkty, z którymi wiążą się elementy i/lub funkcje o wysokim lub średnim poziomie ryzyka.

2.      Udokumentowanie poziomu i typu ryzyka na podstawie odpowiedniego elementu i/lub funkcji podlegającej testowaniu dla każdego zidentyfikowanego produktu pracy poddawanego przeglądowi

3.      Określenie priorytetów przeglądów zidentyfikowanych produktów pracy na podstawie powiązanych ryzyk produktowych

4.      Przegląd z udziałem interesariuszy dotyczący listy produktów pracy podlegających przeglądom (z określonymi priorytetami) i niepodlegających przeglądom

5.      Zdefiniowanie typu lub typów przeglądów stosowanych dla poszczególnych produktów pracy (na podstawie powiązanych poziomów i typów ryzyka), wraz z uzasadnieniem

Omówienie różnych typów przeglądów i opis innych aspektów podejścia do prowadzenia przeglądów koleżeńskich można znaleźć w opisie obszaru procesowego Przeglądy koleżeńskie.

6.      Weryfikacja podejścia do testowania dynamicznego

Należy zweryfikować podejście do testowania dynamicznego i ustalić, czy można zmniejszyć pracochłonność dzięki pokryciu ryzyka produktowego uzyskanemu

w testowaniu statycznym.

7.      Zidentyfikowanie istotnych ograniczeń dotyczących skoordynowanego podejścia do testów

Przykładowe ograniczenia dotyczące skoordynowanego podejścia do testów:

•      Dostępność osób na potrzeby przeglądów

•      Wiedza i umiejętności potencjalnych przeglądających

•      Terminy wyznaczone w projekcie

8.      Oszacowanie pracochłonności i kosztów wymaganych do realizacji skoordynowanego podejścia do testów

9.      Przegląd skoordynowanego podejścia do testów z udziałem interesariuszy

10.      Udokumentowanie skoordynowanego podejścia do testów w (głównym) planie testów

11.      Uzyskanie zobowiązań dotyczących skoordynowanego podejścia do testów ze strony kierownictwa

12.      Aktualizacja skoordynowanego podejścia do testów zgodnie z potrzebami

SG 2       Mierzenie jakości produktów na wczesnych etapach cyklu wytwarzania

z wykorzystaniem przeglądów koleżeńskich

Na wczesnych etapach cyklu wytwarzania jakość produktu podlega pomiarowi w odniesieniu do ustalonych kryteriów z wykorzystaniem przeglądów koleżeńskich.

SP 2.1       Zdefiniowanie wytycznych dotyczących pomiarów w przeglądach koleżeńskich

Definiowane są i dokumentowane wytyczne dotyczące zastosowania przeglądów koleżeńskich jako praktyki pomiarowej.

Przykładowe produkty pracy

1.      Reguły i listy kontrolne przeglądów

2.      Wytyczne dotyczące próbkowania

3.      Procedury czytania opartego na perspektywie

Podpraktyki

1.      Zdefiniowanie i udokumentowanie reguł i list kontrolnych przeglądów

Reguły określają zestaw ogólnych wymagań dotyczących treści i formatu dokumentów różnych typów. Zestaw reguł stanowi podstawę definiowania kryteriów przeglądów koleżeńskich i obiektywnego mierzenia jakości dokumentów. Listy kontrolne przeglądów to specjalne zestawy pytań opracowane z myślą o ułatwieniu przeglądającym wykrycia większej liczby defektów, zwłaszcza poważnych, dzięki sprawdzeniu zdefiniowanego zbioru reguł. Pytania umieszczane na listach kontrolnych stanowią interpretację konkretnych reguł. Wskazane jest ich definiowanie dla poszczególnych ról uczestników przeglądów. [Gilb i Graham]

2.      Zdefiniowanie i udokumentowanie wytycznych dotyczących próbkowania

Wykonywanie przeglądu wszystkich stron dokumentu w celu zmierzenia jakości danego produktu pracy jest nieefektywne i niecelowe. Sprawdzoną metodą poprawnego określania jakości produktów jest próbkowanie. W ramach próbkowania przeglądowi podlega jedynie pewna liczba stron dokumentu. Miary jakości wyznaczane są przez defekty, zdefiniowane w obiektywny sposób jako przypadki naruszenia reguł. Miarą może być np. liczba defektów na stronę. Jeśli zostanie wybrana poprawna próbka, pomiar jakości tej próbki można potraktować jako pomiar jakości całego dokumentu.

Przykładowe zagadnienia, które należy uwzględnić w wytycznych dotyczących próbkowania:

•      Wielkość próbki

•      Reprezentatywność próbki

•      Działania podejmowane na podstawie wyników przeglądu próbki, np. przekazanie informacji o wykrytych defektach

•      Szybkość sprawdzania (liczba stron przeglądanych w ciągu godziny)

3.      Zdefiniowanie i udokumentowanie procedur czytania opartego na perspektywie

Zastosowanie zdefiniowanego, systematycznego procesu indywidualnego wykrywania błędów (nazywanego techniką czytania) pozwala przeglądającym lepiej skoncentrować się na ważnych aspektach przeglądanego dokumentu. Co istotne, dzięki jawności procesu przeglądu techniki czytania umożliwiają jego adaptację w celu lepszego zaspokojenia potrzeb organizacji. Na przykład jeśli w trakcie przeglądów pewien konkretny typ defektu jest konsekwentnie pomijany, należy opracować procedurę identyfikowania defektów tego typu, którą co najmniej jedna osoba powinna zastosować podczas kolejnych przeglądów. Techniki czytania dają również możliwość uniezależnienia procesu od konkretnych osób oraz uzyskania większej powtarzalności wyników przeglądów i pomiarów jakości produktów. [Veenendaal]

4.      Przegląd wytycznych dotyczących pomiarów w przeglądach koleżeńskich (reguł, list kontrolnych przeglądów, wytycznych dotyczących próbkowania i procedur czytania opartego na perspektywie) z udziałem odpowiednich interesariuszy

5.      Optymalizacja wytycznych dotyczących pomiarów w przeglądach koleżeńskich na podstawie praktycznych doświadczeń

SP 2.2       Zdefiniowanie kryteriów przeglądów koleżeńskich na podstawie celów związanych z jakością produktów

Kryteria przeglądów koleżeńskich, zwłaszcza ilościowe kryteria wyjścia, są definiowane na podstawie (pośrednich) celów projektu związanych z jakością produktów.

Przykładowe produkty pracy

1.      Ilościowe kryteria wyjścia dla projektu

Podpraktyki

1.      Przegląd ilościowych (pośrednich) celów projektu związanych z jakością produktów

Potrzeby i cele projektu związane z jakością produktów są poddawane przeglądowi. Zadaniem uczestników przeglądu jest uzyskanie szczegółowych informacji o celach związanych z jakością produktów oraz o ich priorytetach.

Więcej informacji na temat celów związanych z jakością produktów można znaleźć

w opisie celu SG 1 Określenie wymiernych celów projektu (z ustalonymi priorytetami) związanych z jakością produktów (z obszaru procesowego Ocena jakości produktów).

2.      Zdefiniowanie ilościowych kryteriów wyjścia dla przeglądów koleżeńskich na podstawie (pośrednich) celów projektu związanych z jakością produktów

Więcej informacji na temat kryteriów wyjścia dla przeglądów koleżeńskich zawiera opis praktyki SP 1.2 Zdefiniowanie kryteriów przeglądów koleżeńskich (z obszaru procesowego Przeglądy koleżeńskie).

3.      Przegląd i uzgodnienie ilościowych kryteriów wyjścia z udziałem interesariuszy

4.      Dostosowanie wytycznych organizacji dotyczących pomiarów w przeglądach koleżeńskich na podstawie celów projektu związanych z jakością produktów oraz zdefiniowanych kryteriów wyjścia przeglądów koleżeńskich

Wytyczne organizacji dotyczące pomiarów w przeglądach koleżeńskich należy

w konkretnym projekcie stosować jedynie wówczas, gdy mają związek z realizacją tego projektu. Cele i wymagania zdefiniowane w projekcie decydują o zakresie stosowania wytycznych. Na przykład reguły i listy kontrolne dotyczące utrzymywalności i tworzenia dokumentacji mogą być nieistotne w przypadku niektórych typów projektów, m.in. polegających na tworzeniu produktów pośrednich, konwersji danych i migracji.

SP 2.3       Pomiar jakości produktów pracy za pomocą przeglądów koleżeńskich

Jakość produktów pracy jest mierzona na wczesnych etapach cyklu wytwarzania

z wykorzystaniem przeglądów koleżeńskich.

Przykładowe produkty pracy

1.      Dzienniki przeglądów koleżeńskich (lista wykrytych defektów)

2.      Działania do wykonania wynikające z przeglądu koleżeńskiego

3.      Dane związane z przeglądem koleżeńskim

4      Raporty z przeglądów koleżeńskich

Podpraktyki

1.       Wykonywanie przeglądów koleżeńskich wybranych produktów pracy z zastosowaniem wytycznych dotyczących pomiaru

Więcej informacji na temat prowadzenia przeglądów koleżeńskich zawiera opis praktyki SG 2 Wykonywanie przeglądów koleżeńskich (w obszarze procesowym Przeglądy koleżeńskie).

2.      Analiza danych i wyników przeglądu koleżeńskiego

3.      Porównanie wyników przeglądu koleżeńskiego ze zdefiniowanymi kryteriami wyjścia

4.      Określenie działań do wykonania i poinformowanie odpowiednich interesariuszy

o problemach i rezultatach

5.      Zapisanie danych związanych z przeglądem koleżeńskim

SG 3       Modyfikacja podejścia do testów na podstawie wyników przeglądów na wczesnych etapach cyklu wytwarzania

Na podstawie wyników przeglądów koleżeńskich wykonywanych na wczesnych etapach cyklu wytwarzania następuje odpowiednia modyfikacja podejścia do testów.

SP 3.1       Analiza wyników przeglądów koleżeńskich

Zgromadzone dane pomiarowe z przeglądów koleżeńskich dotyczących jakości produktów pracy są analizowane zgodnie z planem.

Przykładowe produkty pracy

1.      Wyniki analizy pomiarów z przeglądów koleżeńskich

2.      Raporty z przeglądów koleżeńskich dotyczące pomiarów jakości produktów pracy

Podpraktyki

1.      Przeprowadzenie analizy danych pomiarowych z przeglądów koleżeńskich dotyczących jakości produktów pracy

2.      Porównanie wyników analizy przeglądów koleżeńskich ze zdefiniowanymi kryteriami wyjścia i ryzykami produktowymi oraz wyciągnięcie wstępnych wniosków

3.      Przeprowadzenie dodatkowych pomiarów na przeglądach koleżeńskich i ich analizy zgodnie z potrzebami oraz przygotowanie wyników do opublikowania

4.      Informowanie odpowiednich interesariuszy o wynikach pomiarów na przeglądach koleżeńskich w odpowiednim terminie

5.      Udzielenie odpowiednim interesariuszom pomocy w interpretacji wyników

SP 3.2       Aktualizacja ryzyk produktowych zgodnie z potrzebami

Następuje ponowna ocena i określenie priorytetów ryzyk produktowych na podstawie danych pomiarowych z przeglądów koleżeńskich dotyczących jakości produktów pracy

z wykorzystaniem predefiniowanych kategorii i parametrów.

Przykładowe produkty pracy

1.       Zaktualizowana lista ryzyk produktowych z określeniem kategorii i priorytetu dla każdego ryzyka (i udokumentowanym uzasadnieniem zmian)

Podpraktyki

1.       Zidentyfikowanie nowych ryzyk produktowych i przegląd istniejących ryzyk, którym należy przypisać zmieniony poziom lub typ ryzyka

Na podstawie danych pomiarowych z przeglądów koleżeńskich dotyczących jakości produktów, a także liczby i typu wykrytych defektów, różnym obszarom produktów można przypisać wyższy lub niższy poziom ryzyka produktowego. Dotyczy to szczególnie prawdopodobieństwa podatności na defekty. Możliwe jest również zidentyfikowanie nowych ryzyk produktowych na podstawie zebranych informacji.

Dzięki wykorzystaniu najnowszych informacji na temat jakości produktów można zmienić główne obszary zainteresowania i odpowiednio dostosować testowanie, a w rezultacie zbudować skuteczniejszy i bardziej efektywny proces testowy.

2.      Analiza zidentyfikowanych ryzyk produktowych z wykorzystaniem predefiniowanych parametrów, np. prawdopodobieństwa i wpływu

Należy zaznaczyć, że analizie podlegają zarówno nowe, jak i wcześniej zidentyfikowane ryzyka produktowe.

3.      Ponowna kategoryzacja i pogrupowanie ryzyk produktowych zgodnie ze zdefiniowanymi kategoriami ryzyka

4.      Ponowne ustalenie priorytetów ryzyk produktowych na potrzeby ich łagodzenia

5.      Udokumentowanie uzasadnienia zmian na liście ryzyk produktowych w projekcie

6.      Przegląd i uzyskanie zgody interesariuszy w kwestii kompletności, kategorii i priorytetu zaktualizowanych ryzyk produktowych

7.      Aktualizacja zestawu ryzyk produktowych na podstawie danych pomiarowych

z przeglądów koleżeńskich w momencie osiągnięcia kamieni milowych projektu i po wystąpieniu określonych zdarzeń

SP 3.3       Aktualizacja podejścia do testów zgodnie z potrzebami

Na podstawie zidentyfikowanych ryzyk produktowych skoordynowane podejście do testów jest aktualizowane zgodnie z potrzebami i uzgadniane z interesariuszami.

Przykładowe produkty pracy

1.      Zaktualizowane podejście do testowania dynamicznego

Podpraktyki

1.      Aktualizacja listy elementów podlegających testowaniu (i ich poziomów ryzyka) oraz listy elementów niepodlegających testowaniu w oparciu o zaktualizowany zestaw ryzyk produktowych

2.      Aktualizacja listy funkcji podlegających testowaniu (i ich poziomów ryzyka) oraz listy funkcji niepodlegających testowaniu w oparciu o zaktualizowany zestaw ryzyk produktowych

3.      Przegląd zaktualizowanej listy elementów i funkcji podlegających i niepodlegających testowaniu (z udziałem interesariuszy)

4.      Aktualizacja skoordynowanego podejścia do testów zgodnie z potrzebami

Skoordynowane podejście do testów, uwzględniające zarówno testy dynamiczne (funkcjonalne i niefunkcjonalne), jak i przeglądy koleżeńskie, podlega weryfikacji

i aktualizacji zgodnie z potrzebami, w oparciu o zaktualizowaną listę elementów i funkcji podlegających i niepodlegających testowaniu.

Więcej informacji na temat definiowania podejścia do testów można znaleźć w opisie celu SG 2 Ustanowienie podejścia do testów (z obszaru procesowego Planowanie testów) oraz w opisie celu SG 2 Ustanowienie podejścia do testów niefunkcjonalnych

(z obszaru procesowego Testowanie niefunkcjonalne). Więcej informacji na temat definiowania podejścia do prowadzenia przeglądów koleżeńskich zawiera opis praktyki SG 1 Ustanowienie podejścia do prowadzenia przeglądów koleżeńskich (z obszaru procesowego Przeglądy koleżeńskie).

5.      Udokumentowanie zaktualizowanego skoordynowanego podejścia do testów

w (głównym) planie testów

6.      Przegląd zaktualizowanego skoordynowanego podejścia do testów z udziałem interesariuszy i uzyskanie zobowiązań dotyczących jego realizacji ze strony kierownictwa

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Zaawansowane przeglądy.

Opracowanie

Polityka dotycząca zaawansowanych przeglądów zwykle zawiera następujące ustalenia:

•      Przeglądy będą stosowane do mierzenia jakości produktów na wczesnych etapach cyklu wytwarzania oprogramowania

•      Przeglądy stanowią część procesu testowego i powinny zostać uwzględnione

w podejściu do testów, projekcie planu testów i raportach z testów

•      Przeglądy koleżeńskie są prowadzone przez przeszkolonych liderów przeglądu, którzy ponoszą ogólną odpowiedzialność za przeglądy. Przeszkoleni moderatorzy zapewniają efektywny przebieg spotkań przeglądowych.

•      Dane pomiarowe z przeglądów są gromadzone i wykorzystywane do zmodyfikowania podejścia do testowania dynamicznego, udoskonalenia procesu przeglądów

i prognozowania jakości produktów

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Zaawansowane przeglądy.

Opracowanie

Na poziomie TMMi 4 przeglądy koleżeńskie stanowią integralną część procesu testowego. Plan realizacji procesu Zaawansowane przeglądy jest uwzględniany w (głównym) planie testów.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Zaawansowane przeglądy, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

•      Zapewniono odpowiedni czas na wykonanie czynności związanych z zaawansowanymi przeglądami

•      Dostępni są przeszkoleni liderzy przeglądów koleżeńskich

•      Dostępne są sale konferencyjne na spotkania związane z przeglądami

•      Dostępne są pomocnicze artefakty, np. formularze do rejestrowania defektów

i formularze przeglądu, umożliwiające gromadzenie i analizę danych oraz tworzenie raportów

•      Tworzone są i utrzymywane reguły, listy kontrolne, procedury czytania i wytyczne dotyczące próbkowania

•      Dostępne są narzędzia wspierające proces prowadzenia zaawansowanych przeglądów, np. narzędzia do rejestrowania defektów, narzędzia do komunikacji, narzędzia pomiarowe i narzędzia do zarządzania procesem przeglądu koleżeńskiego

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Zaawansowane przeglądy, wytworzenia produktów pracy oraz realizacji usług związanych z tym procesem.

Opracowanie

Ponieważ na poziomie TMMi 4 przeglądy koleżeńskie są częścią procesu testowego, za koordynację procesu zaawansowanych przeglądów w projektach odpowiedzialni są kierownicy testów.

Liderzy przeglądów koleżeńskich wspierają kierowników testów i są odpowiedzialni za koordynację poszczególnych przeglądów związanych z mierzeniem jakości produktów.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Zaawansowane przeglądy zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń związanych z zaawansowanymi przeglądami:

•      Ocena ryzyka produktowego

•      Definiowanie skoordynowanego podejścia do testów

•      Typy przeglądów

•      Definiowanie ilościowych kryteriów wyjścia przeglądów koleżeńskich

•      Reguły i listy kontrolne dotyczące dokumentów

•      Próbkowanie

•      Czytanie oparte na perspektywie

•      Procesy gromadzenia, analizy i raportowania danych

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Zaawansowane przeglądy odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Skoordynowane podejście do testów

•      Raport z przeglądu skoordynowanego podejścia do testów

•      Plan testów

•      Dane związane z przeglądem (baza danych)

•      Dane pomiarowe z przeglądów koleżeńskich

•      Wyniki analizy pomiarów z przeglądów koleżeńskich i raporty

•      Materiały szkoleniowe związane z zaawansowanymi przeglądami

•      Dane związane z oceną ryzyka produktowego

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Zaawansowane przeglądy zgodnie z planem.

Opracowanie

Wybór odpowiednich interesariuszy biorących udział w zaawansowanych przeglądach spośród klientów, użytkowników końcowych, programistów, testerów, dostawców, sprzedawców, specjalistów ds. utrzymania i serwisu, przedstawicieli kierownictwa oraz przedstawicieli innych grup, których dotyczą lub mogą dotyczyć dane produkty (pracy).

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Wybór produktów pracy poddawanych przeglądom

•      Bezpośrednie udostępnienie zasobów zgodnie z potrzebami

•      Przegląd i zatwierdzenie skoordynowanego podejścia do testów

•      Wykonywanie przeglądów koleżeńskich

•      Ocena danych pomiarowych z przeglądów koleżeńskich

GP 2.8      Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Zaawansowane przeglądy (porównywanie

z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Zaawansowane przeglądy:

•      Porównanie rzeczywistej i planowanej pracochłonności przeglądów koleżeńskich

i testowania dynamicznego

•      Liczba zaplanowanych i przeprowadzonych przeglądów koleżeńskich

•      Liczba produktów pracy, których jakość została zmierzona (w porównaniu z planem)

•      Liczba wersji planu testów

•      Liczba nowych lub zmienionych ryzyk produktowych w poszczególnych wersjach

•      Liczba elementów testowych, w przypadku których w poszczególnych wersjach zmieniono poziom ryzyka

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Zaawansowane przeglądy oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Uwzględnienie skoordynowanego podejścia do testów w planie testów

•      Zgodność przeprowadzonych przeglądów koleżeńskich z wytycznymi dotyczącymi pomiarów

•      Skuteczność i efektywność wytycznych dotyczących pomiarów w przeglądach koleżeńskich

•      Wykorzystanie wyników przeglądów koleżeńskich do weryfikacji listy ryzyk produktowych

•      Skuteczność aktualizacji planów testów na podstawie wyników przeglądów koleżeńskich

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Zaawansowane przeglądy z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

Opracowanie

Przykładowe działania, informacje o statusie i wyniki procesu Zaawansowane przeglądy, które można uwzględnić w trakcie przeglądów z udziałem kierownictwa wyższego szczebla:

•      Liczba projektów, w których stosowane jest skoordynowane podejście do testów

•      Liczba zaplanowanych i przeprowadzonych przeglądów koleżeńskich

•      Wyniki przeprowadzonych przeglądów

•      Dane pomiarowe z przeprowadzonych przeglądów, np. skuteczność usuwania defektów oprogramowania i liczba defektów

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Zaawansowane przeglądy.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Zaawansowane przeglądy, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Zakres pokrycia przez przeglądy koleżeńskie

•      Gęstość defektów (na stronę) w dokumentach poddawanych przeglądom koleżeńskim

•      Odsetek planów testów uwzględniających podejście do prowadzenia przeglądów koleżeńskich

•      Odsetek przeglądów koleżeńskich przeprowadzonych z zastosowaniem technik czytania opartego na perspektywie

•      Liczba ryzyk produktowych zweryfikowanych w oparciu o wyniki przeglądów

•      Liczba planów testów i podejść do testów zaktualizowanych w oparciu o wyniki przeglądów

Poziom TMMi 5: Optymalizacja

Osiągnięcie wszystkich poprzednich celów doskonalenia testowania na poziomach TMMi od 1. do 4. tworzy infrastrukturę organizacyjną do testowania, która wspiera całkowicie zdefiniowany i mierzalny proces. Na 5. poziomie dojrzałości TMMi organizacja jest w stanie

w sposób ciągły doskonalić swoje procesy w oparciu o ilościowe zrozumienie procesów kontrolowanych statystycznie. Zwiększanie wydajności procesu testowego odbywa się poprzez przyrostowe i innowacyjne procesy oraz udoskonalenia technologiczne. Metody

i techniki testowania są zoptymalizowane, a nacisk kładziony jest na dokładne dostrajanie

i doskonalenie procesów. Zoptymalizowany proces testowy, zdefiniowany przez TMMi, to proces, który jest:

- zarządzany, zdefiniowany, mierzalny, wydajny i skuteczny,

- statystycznie kontrolowany i przewidywalny,

- skoncentrowany na zapobieganiu defektom,

- wspierany przez automatyzację w zakresie niezbędnym do efektywnego wykorzystania zasobów,

- zdolny do wspierania transferu technologii z przemysłu do organizacji,

- zdolny do wspierania ponownego wykorzystania zasobów testowych,

- skoncentrowany na zmianie procesu w celu osiągnięcia ciągłego doskonalenia.

W celu wspierania ciągłego doskonalenia infrastruktury procesu testowego oraz identyfikacji, planowania i wdrażania usprawnień tegoż procesu, powoływana jest stała grupa ds. usprawnienia procesu testowego. W jej skład wchodzą osoby, które przeszły specjalistyczne szkolenia w celu podniesienia poziomu swoich umiejętności i wiedzy niezbędnych do osiągnięcia sukcesu przez grupę. W wielu organizacjach grupa ta nazywana jest grupą procesu testowego. Wsparcie dla grupy procesu testowego rozpoczyna się formalnie na poziomie TMMi 3, kiedy wprowadzany jest obszar procesowy Organizacja testowa. Na 4. i 5. poziomie TMMi zakres odpowiedzialności grupy rośnie wraz

z wprowadzaniem praktyk na wyższym poziomie, np. w zakresie identyfikacji zasobów (procesu) testowego wielokrotnego użytku oraz rozwoju i utrzymania biblioteki zasobów (procesu) testowego.

Obszar procesowy Zapobieganie defektom został ustanowiony w celu identyfikacji i analizy typowych przyczyn defektów w całym cyklu wytwarzania oprogramowania oraz określenia działań zapobiegających występowaniu podobnych defektów w przyszłości. Przypadki zaburzeń wydajności procesu testowego, zidentyfikowane w trakcie kontroli jakości procesów, są analizowane w celu określenia ich przyczyn w ramach czynności zapobiegania defektom.

Proces testowy jest zarządzany statystycznie za pomocą obszaru procesowego Kontrola jakości. Statystyczne próbkowanie, pomiary poziomów zaufania, wiarygodności

i niezawodności stymulują proces testowy. Proces testowy charakteryzuje się pomiarem jakości opartym na próbkowaniu.

Na poziomie TMMi 5 w obszarze Optymalizacja procesu testowego wprowadzono mechanizmy precyzyjnego dostrajania i ciągłego doskonalenia testów. Istnieje ustalona procedura identyfikacji usprawnień procesu, jak również wyboru i oceny nowych technologii

w obszarze testowania. Narzędzia wspierają proces testowy w takim stopniu, w jakim jest on efektywny w fazie projektowania testów, wykonywania testów, testowania regresji, zarządzania przypadkami testowymi, zbierania i analizy defektów itp. Powszechną praktyką

w całej organizacji jest ponowne wykorzystanie procesu i testaliów. Jest to wspierane przez bibliotekę zasobów (procesu) testowego.

Trzy obszary procesowe na poziomie TMMi 5: Zapobieganie defektom, Kontrola jakości

i Optymalizacja procesu testowego zapewniają wsparcie dla ciągłego doskonalenia procesów. W praktyce te trzy obszary procesowe są ze sobą ściśle powiązane. Na przykład Zapobieganie defektom wspiera obszar Kontroli jakości poprzez analizę wartości odbiegających od norm wydajności procesu oraz poprzez wdrażanie praktyki analizy przyczyn powstawania defektów i zapobiegania ponownemu ich wystąpieniu. Kontrola jakości przyczynia się do Optymalizacji procesu testowego, a Optymalizacja procesu testowego wspiera zarówno Zapobieganie defektom, jak i Kontrolę jakości na przykład poprzez wdrażanie propozycji udoskonaleń testów. Wszystkie te obszary procesowe są z kolei wspierane przez praktyki, które zostały zastosowane podczas wdrażania obszarów procesowych niższego poziomu. Na poziomie TMMi 5 testowanie jest zdefiniowane jako proces mający na celu zapobieganie defektom.

Obszary procesowe na poziomie TMMi 5 są następujące:

5.1      Zapobieganie defektom

5.2      Kontrola jakości

5.3      Optymalizacja procesu testowego

Poszczególne obszary zostały dokładniej omówione w kolejnych rozdziałach.

PA 5.1      Zapobieganie defektom

Cel

Celem obszaru Zapobieganie defektom jest identyfikacja i analiza wspólnych przyczyn defektów w całym cyklu wytwarzania oprogramowania oraz określenie działań zapobiegających występowaniu podobnych defektów w przyszłości.

Uwagi wstępne

Zgodnie z ewolucyjnym modelem testowania [Gelperin i Hetzel] testowanie na poziomie TMMi 5 nie jest już procesem skoncentrowanym na wykrywaniu defektów, tylko na zapobieganiu ich wystąpieniu. W ramach tej koncepcji działania testerów skupiają się na zapobieganiu defektom, które mogłyby zostać wprowadzone do oprogramowania, a nie tylko na ich wykrywaniu w trakcie wykonywania czynności testowych. Obszar Zapobieganie defektom obejmuje analizę defektów, które wystąpiły w przeszłości, określanie ich przyczyn

i podejmowanie konkretnych działań w celu uniknięcia występowania defektów danego typu

w przyszłości. Wybór analizowanych defektów powinien opierać się na różnych czynnikach, m.in. na ryzyku. Należy zwrócić szczególną uwagę na obszary, w których zapobieganie defektom przynosi najwięcej dodatkowych korzyści (zwykle oznacza to ograniczenie kosztów lub ryzyka) i/lub w których defekty są najbardziej krytyczne. Należy uwzględnić istniejące typy defektów oraz nowe typy, np. niewystępujące do tej pory w organizacji, ale pojawiające się

w innych przedsiębiorstwach z danej branży. Działania związane z Zapobieganiem defektom są także mechanizmem umożliwiającym uwzględnienie w całej organizacji, np. w wielu projektach, wniosków wyciągniętych z dotychczasowych prac.

Dzięki uniemożliwieniu wprowadzenia defektów do tworzonych produktów organizacja może podnieść poziom jakości i produktywności. Z danych branżowych wynika, że podejście oparte na wykrywaniu występujących defektów zwykle nie jest opłacalne [Boehm]. Na ogół bardziej ekonomiczne okazuje się zapobieganie wprowadzeniu defektów do produktów dzięki integracji praktyk obszaru Zapobieganie defektom we wszystkich fazach projektu. Na poziomie TMMi 5 organizacja jest w stanie określić, które podejście jest bardziej opłacalne dla danego typu defektu. Wiele modeli doskonalenia procesów podkreśla zalety wykorzystania analizy przyczyn jako metody ustawicznego usprawniania możliwości procesu. Przykładowe metody analizy przyczyn to specjalne spotkania dotyczące analizy przyczyn, zastosowanie narzędzi takich jak analiza drzewa usterek i diagramy przyczynowo-skutkowe, retrospektywy projektu, analiza przyczyn wykonywana podczas przeglądów formalnych oraz zastosowanie standardowych schematów klasyfikacji defektów.

Mechanizm zapobiegania defektom polega na ocenie pełnego procesu wytwarzania

i zidentyfikowaniu najbardziej skutecznych usprawnień związanych z jakością produktów.

W ramach praktyk obszaru Zapobieganie defektom analizuje się trendy w celu monitorowania typów występujących defektów i miejsca ich wprowadzenia oraz w celu zidentyfikowania defektów, które z dużym prawdopodobieństwem mogą wystąpić ponownie. W organizacji funkcjonuje już proces pomiaru (testów), ponieważ został wprowadzony na poziomie 4. Można skorzystać z dostępnych miar, jednak do analizowania efektów zmian w procesach mogą okazać się niezbędne nowe miary. Dzięki zrozumieniu zdefiniowanych standardowych procesów wytwarzania i testowania w organizacji oraz sposobów ich implementacji można określić podstawowe przyczyny defektów i konsekwencje ich wystąpienia dla realizacji zadań w przyszłości. Definiuje się i podejmuje konkretne działania, które pozwalają zapobiec ponownemu wystąpieniu zidentyfikowanych defektów. Zapobieganie defektom to podstawowy element dojrzałego procesu testowego. Defekty wykryte w trakcie prac programistycznych lub testowych, a nawet w środowisku produkcyjnym, muszą być systematycznie analizowane. Należy określić ich priorytety i podjąć odpowiednie działania, aby nie pojawiły się ponownie. Za koordynowanie działań w ramach obszaru odpowiada organizacja testowa. Należy to robić w ścisłej współpracy z przedstawicielami innych obszarów, takich jak inżynieria wymagań, inżynieria systemów i/lub wytwarzanie oprogramowania, ponieważ działania usprawniające często mają wpływ na te obszary.

Zakres

Obszar procesowy Zapobieganie defektom obejmuje praktyki związane

z identyfikowaniem i analizą wspólnych przyczyn defektów oraz definiowaniem konkretnych działań, których celem jest zlikwidowanie przyczyn występowania defektów danego typu, zarówno w projekcie, jak i w całej organizacji. Zakresem obszaru procesowego objęte są wszystkie defekty niezależnie od miejsca ich wystąpienia (w środowisku programistycznym, testowym czy produkcyjnym). Defekty w procesie, które spowodowały powstanie anomalii

i spadek wydajności procesu poniżej oczekiwanej wartości, również mieszczą się w zakresie tego obszaru. Ponieważ Zapobieganie defektom wymaga użycia procesów pomiaru i danych pomiarowych, obszar ten został oparty na praktykach poziomu TMMi 4 związanych

z pomiarem oraz na dostępnych danych pomiarowych dotyczących wytwarzania oprogramowania, testowania i jakości produktów.

Podsumowanie celów i praktyk szczegółowych

SG 1       Ustalenie wspólnych przyczyn defektów

SP 1.1       Zdefiniowanie parametrów wyboru defektów i schematu klasyfikacji defektów

SP 1.2       Wybór defektów do analizy

SP 1.3       Analiza przyczyn wybranych defektów

SG 2       Zdefiniowanie systematycznych działań związanych z eliminowaniem podstawowych przyczyn defektów i określenie ich priorytetów

SP 2.1       Proponowanie rozwiązań w celu wyeliminowania wspólnych przyczyn defektów

SP 2.2       Zdefiniowanie propozycji działań i zgłoszenie propozycji udoskonaleń

Praktyki szczegółowe dla poszczególnych celów

SG 1       Ustalenie wspólnych przyczyn defektów

Wspólne przyczyny i podstawowe przyczyny wybranych defektów są systematycznie ustalane.

SP 1.1       Zdefiniowanie parametrów wyboru defektów i schematu klasyfikacji defektów

Definiowane są parametry wyboru defektów do analizy i szczegółowy schemat klasyfikacji defektów.

Przykładowe produkty pracy

1.      Parametry wyboru defektów

2.      Schemat klasyfikacji defektów

Podpraktyki

1.      Określenie parametrów wyboru defektów

Wybór defektów powinien opierać się na różnych czynnikach, m.in. na ryzyku. Należy zwrócić szczególną uwagę na obszary, w których zapobieganie defektom przynosi najwięcej dodatkowych korzyści i/lub w których defekty są najbardziej krytyczne.

Przykładowe kryteria wyboru defektów:

•      Potencjalne szkody związane z wystąpieniem defektu danego typu

•      Częstotliwość występowania defektu

•      Pracochłonność związana z usunięciem defektu

•      Oszacowanie pracochłonności zapobiegania ponownemu wystąpieniu defektu

•      Koszty wprowadzenia poprawki związanej z defektem

•      Zakres negatywnego wpływu defektu na wydajność procesu

2.      Przegląd i uzgodnienie zdefiniowanych parametrów wyboru defektów z udziałem odpowiednich interesariuszy

3.      Weryfikacja schematu klasyfikacji defektów

Spójna klasyfikacja defektów pozwala uzyskać statystyki dotyczące obszarów potencjalnych usprawnień w organizacji i poddać je analizie. Defekty do przeanalizowania są rejestrowane we wszystkich fazach cyklu życia oprogramowania, w tym w fazach utrzymania i eksploatacji. Zastosowanie schematu klasyfikacji defektów prowadzi do zrozumienia etapów projektu,

w których wprowadzane są defekty, działań projektowych występujących w przypadku wykrycia defektów, kosztów usunięcia defektów, a także do wskazania etapu, w którym defekt został zgłoszony, i etapu, w którym defekt powinien był zostać wykryty (zjawisko nazywane przenoszeniem defektów do następnych faz – ang. defect leakage) [ISTQB ITP],

Dla każdej fazy standard definiuje pewną liczbę atrybutów, których można użyć do klasyfikowania. Standard IEEE 1044 zawiera obszerne listy sposobów klasyfikacji

i powiązanych elementów danych, na przykład:

•      W fazie rozpoznania dostępne są m.in. następujące sposoby klasyfikacji (wraz

z powiązanymi elementami danych): działanie projektowe, faza, w której wykryto defekt, prawdopodobna przyczyna, powtarzalność, system, status produktu.

•      W fazie analizy dostępne są m.in. następujące sposoby klasyfikacji (wraz z powiązanymi elementami danych): rzeczywista przyczyna wystąpienia, źródło defektu, typ defektu.

Schemat klasyfikacji defektów zwykle jest wstępnie definiowany w obszarze procesowym Projektowanie i wykonywanie testów, a następnie zgodnie z potrzebami rozszerzany na późniejszych etapach, np. w ramach obszaru procesowego Pomiar testów. Niniejsza podpraktyka korzysta z tego schematu. Schemat klasyfikacji defektów podlega weryfikacji pod kątem omawianego obszaru procesowego – należy sprawdzić, czy rejestrowane są wszystkie dane niezbędne do skutecznej i efektywnej realizacji procesu zapobiegania defektom.

Należy zaznaczyć, że zweryfikowany schemat klasyfikacji defektów powinien zostać zastosowany podczas wykonywania czynności związanych z rejestrowaniem defektów, np. ujętych w praktyce SP 3.3 Raportowanie incydentów testowych (z obszaru procesowego Projektowanie i wykonywanie testów) oraz w praktyce SP 5.2 Raportowanie niefunkcjonalnych incydentów testowych (z obszaru procesowego Testowanie niefunkcjonalne).

4.      Przegląd i uzgodnienie zweryfikowanego schematu klasyfikacji defektów z udziałem odpowiednich interesariuszy

SP 1.2       Wybór defektów do analizy

Z repozytorium defektów wybierane są defekty do szczegółowej analizy.

Przykładowe produkty pracy

1.      Defekty wybrane do dalszej analizy (wraz z uzasadnieniem wyboru)

Podpraktyki

1.      Zidentyfikowanie i wybór interesariuszy, którzy powinni wziąć udział w procesie wyboru defektów

Uczestnikami mogą być przedstawiciele strony biznesowej, programiści, specjaliści

ds. utrzymania, osoby odpowiedzialne za zarządzanie usługami i wsparcie aplikacji, testerzy oraz odpowiednie osoby spoza projektu. Wyboru może również dokonywać standardowy zespół działający w ramach grupy procesu testowego, poszerzany w miarę potrzeby o odpowiednie osoby zajmujące się konkretnymi defektami.

2.      Przeprowadzenie spotkania inicjującego

Cele spotkania inicjującego:

● Omówienie procesu, który zostanie zastosowany podczas spotkania dotyczącego wyboru defektów

● Dokonanie konkretnych ustaleń dotyczących przygotowań do spotkania oraz jego terminu i miejsca

● Omówienie parametrów wyboru i schematu klasyfikacji

Jeśli wszyscy uczestnicy mają doświadczenie w zakresie wyboru defektów, przeprowadzenie spotkania inicjującego może nie być konieczne.

3.      Przygotowanie do wyboru defektów

Przykładowe działania wykonywane podczas przygotowań do wyboru defektów:

•      Opracowanie listy wszystkich defektów. Raporty o defektach mogą zostać zarejestrowane podczas testowania statycznego i dynamicznego, w trakcie eksploatacji produktu i w przypadku wystąpienia anomalii związanych z wydajnością procesu.

•      Przeprowadzenie wstępnego wyboru defektów z repozytorium defektów. W ramach tej czynności z listy usuwane są defekty, których prawdopodobieństwo wyboru jest niewielkie (np. drobne usterki). Identyfikuje się defekty zgodne z parametrami wyboru.

•      Wykonanie wstępnej analizy defektów, np. w celu zidentyfikowania typów defektów

o dużej liczbie wystąpień, z zastosowaniem technik takich jak analiza Pareto

i histogramy.

4.       Podjęcie przez interesariuszy decyzji o wyborze defektów (lub typów defektów), które będą podlegać szczegółowej analizie. W trakcie podejmowania tej decyzji brane są pod uwagę parametry wyboru defektów i inne przygotowane informacje. Należy zwrócić uwagę zarówno na już istniejące, jak i nowe typy defektów.

SP 1.3       Analiza przyczyn wybranych defektów

Wykonanie analizy przyczyn wybranych defektów w celu ustalenia ich podstawowych przyczyn oraz zidentyfikowania wspólnych przyczyn.

Przykładowe produkty pracy

1.      Podstawowe przyczyny wybranych defektów

2.      Wspólne przyczyny defektów

Podpraktyki

1.      Analiza wybranych defektów w celu ustalenia ich podstawowych przyczyn

Podstawową przyczynę defektu można znaleźć w konkretnej czynności w ramach fazy wytwarzania oprogramowania lub testowania, w której defekt się pojawił. Do ustalenia podstawowej przyczyny defektu służą metody pomocnicze. W przypadku dużej liczby defektów dobrym rozwiązaniem może okazać się ich pogrupowanie, np. według typu, przed rozpoczęciem analizy.

Przykładowe metody pomocnicze ułatwiające określenie podstawowych przyczyn defektów [ISTQB ITP]:

•      Diagramy przyczynowo-skutkowe

•      Diagramy Ishikawy (diagramy rybiej ości)

•      Analiza drzewa usterek

•      Analiza procesów

•      Zastosowanie klasyfikacji defektów

•      Listy kontrolne

•      Analiza przyczyn i skutków awarii (ang. FMEA – Failure Mode Effects Analysis)

•      Analiza interakcji między sprzętem a oprogramowaniem

2.      Określenie wspólnych przyczyn wybranych defektów

Wybrane defekty są grupowane na podstawie ich podstawowych przyczyn.

Przykładowe kategorie wspólnych podstawowych przyczyn defektów:

•      Proces

•      Ludzie (wiedza i umiejętności)

•      Organizacja (projektu)

•      Komunikacja

•      Architektura

•      Technologia, np. narzędzia, środowisko testowe

SG 2       Zdefiniowanie działań związanych z systematycznym eliminowaniem podstawowych przyczyn defektów i określenie ich priorytetów

Definiowane są działania związane z systematycznym eliminowaniem podstawowych

i wspólnych przyczyn defektów oraz określane są priorytety takich działań.

SP 2.1       Proponowanie rozwiązań w celu wyeliminowania podstawowych przyczyn defektów

Proponowane są rozwiązania umożliwiające wyeliminowanie podstawowych i wspólnych przyczyn defektów.

Przykładowe produkty pracy

1.      Możliwe rozwiązania

2.      Pogrupowane wspólne/podstawowe przyczyny defektów

Podpraktyki

1.      Pogrupowanie wspólnych przyczyn, które być może uda się wyeliminować za pomocą jednego lub większej liczby powiązanych rozwiązań

Na przykład wspólne przyczyny można pogrupować według fazy wytwarzania, technologii, cyklu wytwarzania lub obszaru.

2.      Określenie typu lub typów rozwiązań, które powinny być najbardziej przydatne do wyeliminowania wspólnej przyczyny

Przykładowe typy rozwiązań:

•      Proces

•      Standardy produktów pracy

•      Reguły dotyczące wymagań

•      Architektura

•      Szkolenia

•      Rekrutacja pracowników

•      Coaching

•      Struktura organizacyjna

•      Komunikacja i współpraca

•      Wyróżnienia dla pracowników

•      Przegląd działań

•      Strategia testów i/lub podejście do testów

•      Metody i techniki

•      Listy kontrolne

•      Standardy tworzenia kodu

•      Narzędzia

3.      Zdefiniowanie rozwiązań

Zdefiniowanie rozwiązań dla wspólnej przyczyny na podstawie zidentyfikowanych typów rozwiązań.

W celu określenia rozwiązań wybierane są potencjalnie odpowiednie metody, narzędzia i techniki. Właściwe metody, narzędzia i techniki umożliwiają organizacji zdefiniowanie spójnych rozwiązań, które zapobiegną ponownemu wystąpieniu defektów.

Z wykorzystaniem metod, narzędzi i technik można skonstruować rozwiązania, które do tej pory nie były wykorzystywane przez organizację lub nie były w niej znane.

Możliwe jest również, że najlepsze praktyki stosowane przez organizację staną się częścią tworzonych rozwiązań. Najlepsze praktyki stosowane w konkretnym projekcie lub w konkretnej części organizacji mogą ułatwić zdefiniowanie spójnych rozwiązań, dzięki którym defekty nie wystąpią ponownie.

4.      Ocena zaproponowanych rozwiązań

Ocena zaproponowanych rozwiązań w celu ustalenia, czy zapobiegają one ponownemu wystąpieniu wybranych defektów.

Przykładowe techniki stosowane do oceny zaproponowanych rozwiązań:

•      Prototyp

•      Przejrzenie

•      Przegląd techniczny

•      (Manualna) symulacja

5.       Określenie priorytetów zaproponowanych rozwiązań

Kryteria umożliwiające określenie priorytetów zaproponowanych rozwiązań to m.in.:

•      Wartość biznesowa

•      Stopień, w jakim rozwiązanie umożliwia wyeliminowanie wspólnych przyczyn defektów

•      Koszty wdrożenia rozwiązania i wpływ rozwiązania na działanie organizacji

•      Konsekwencje pozostawienia nieusuniętych defektów

•      Oczekiwany wpływ na jakość

SP 2.2       Zdefiniowanie propozycji działań i zgłoszenie propozycji udoskonaleń

Definiowane są propozycje działań umożliwiających wdrożenie zaproponowanych rozwiązań; są one następnie zgłaszane jako propozycje udoskonaleń.

Przykładowe produkty pracy

1.      Opracowane propozycje działań

2.      Zarejestrowane dane

3.      Zgłoszone propozycje udoskonaleń

Podpraktyki

1.      Opracowanie propozycji działań

Przykłady informacji podawanych w propozycji działania [CMMI]:

•      Osoba odpowiedzialna za wdrożenie

•      Opis obszarów, na które rozwiązanie ma wpływ

•      Osoba(-y) informowane o statusie realizacji

•      Najbliższy termin przeglądu statusu

•      Uzasadnienie najważniejszych decyzji

•      Opis zadań związanych z wdrożeniem

•      Szacowane koszty braku rozwiązania problemu, np. koszty zidentyfikowania i usunięcia defektu po jego ponownym wystąpieniu

2.      Przegląd propozycji działań z udziałem odpowiednich interesariuszy

Propozycje działań podlegają przeglądowi w celu oceny oczekiwanego ograniczenia ryzyka biznesowego i/lub technicznego oraz wykonalności i wpływu na organizację.

3.      Zarejestrowanie danych

Dane są rejestrowane, tak aby inne projekty i inne części organizacji mogły wdrożyć zdefiniowane rozwiązanie.

Przykłady rejestrowanych danych:

•      Dane dotyczące defektów i innych przeanalizowanych problemów

•      Uzasadnienie decyzji

•      Zaproponowane rozwiązania i ich priorytety

•      Zdefiniowane działania

•      Zdefiniowane rozwiązania

•      Dane z projektów pilotażowych lub testów

•      Ocena projektu po jego realizacji

•      Udoskonalenia rozwiązania

•      Koszty czynności związanych z analizą i rozwiązywaniem problemów

•      Miary zmian wydajności

4.      Zgłoszenie propozycji działania jako propozycji udoskonalenia

Propozycje działań i zarejestrowane dane są przekazywane zespołowi ds. doskonalenia procesów w celu ich wdrożenia. Propozycje udoskonaleń dotyczące procesu testowego są przekazywane grupie procesu testowego; propozycje udoskonaleń dotyczące innych obszarów są przekazywane zespołowi ds. doskonalenia odpowiedniego obszaru lub menedżerowi (wyższego szczebla) odpowiedzialnemu za ten obszar.

5.      Monitorowanie propozycji udoskonaleń

Postęp i efekty wdrożenia propozycji udoskonaleń powinny podlegać monitorowaniu. Jeśli postęp wdrożenia jest niezgodny z oczekiwaniami, powinni zostać o tym poinformowani odpowiedni interesariusze.

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Zapobieganie defektom.

Opracowanie

Polityka zapobiegania defektom zwykle zawiera następujące ustalenia:

● Cele organizacyjne procesu zapobiegania defektom

● Główne miary umożliwiające monitorowanie faktycznego postępu realizacji zdefiniowanych celów

● Oczekiwania organizacji dotyczące identyfikowania i systematycznego eliminowania podstawowych przyczyn defektów i innych problemów

● Długoterminowe zobowiązania dotyczące finansowania, obsady kadrowej

i udostępniania innych zasobów na potrzeby obszaru Zapobieganie defektom

● Określenie działań związanych z zapobieganiem defektom, które należy wdrożyć

w organizacji w celu udoskonalenia procesów i produktów

● Określenie działań związanych z zapobieganiem defektom, które powinny być koordynowane przez grupę procesu testowego lub zespół ds. doskonalenia procesów

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Zapobieganie defektom.

Opracowanie

Działania związane z zapobieganiem defektom, np. dotyczące identyfikowania i eliminowania podstawowych i wspólnych przyczyn defektów, są bezpośrednio planowane i tworzony jest ich harmonogram na poziomie organizacyjnym obejmującym wiele projektów.

Zwykle plan realizacji działań związanych z zapobieganiem defektom jest uwzględniany

w planie doskonalenia procesu testowego organizacji lub w nim przywoływany (plan ten został opisany w rozdziale poświęconym obszarowi procesowemu Organizacja testowa). Plan działań może być również odrębnym dokumentem odnoszącym się wyłącznie do procesu Zapobieganie defektom.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Zapobieganie defektom, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Zapobieganie defektom.

Opracowanie

Zapewniono odpowiedni czas i narzędzia pomocnicze umożliwiające wykonywanie działań związanych z zapobieganiem defektom.

Przykłady narzędzi wspierających działania związane z zapobieganiem defektom:

•      Systemy baz danych do rejestrowania i eksploracji danych historycznych

•      Pakiety do analizy statystycznej

•      Narzędzia, metody i techniki analityczne (np. diagramy Ishikawy, analiza Pareto, histogramy, grafy przyczynowo-skutkowe, narzędzia do modelowania procesów)

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Zapobieganie defektom, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Zapobieganie defektom.

Opracowanie

Definiowane są obowiązki związane z zapobieganiem defektom. Obowiązki te zwykle przydzielane są zespołowi analitycznemu ds. zapobiegania defektom, który może działać

w ramach grupy procesu testowego. Zespół taki zwykle składa się z przedstawicieli jednostek odpowiedzialnych za następujące obszary:

•      Zarządzanie

•      Tworzenie oprogramowania

•      Zapewnianie jakości

•      Doskonalenie procesów

•      Testowanie

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Zapobieganie defektom zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

•      Techniki zapobiegania defektom, np. diagramy przyczynowo-skutkowe, diagramy Ishikawy (diagramy rybiej ości), analiza Pareto, analiza drzewa usterek i analiza procesów.

•      Parametry wyboru defektów

•      Schematy klasyfikacji defektów

•      Prowadzenie analizy podstawowych przyczyn defektów

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Zapobieganie defektom odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Parametry wyboru defektów

•      Wybrane defekty

•      Zidentyfikowane podstawowe przyczyny i wspólne przyczyny defektów

•      Zapis analizy przyczyn

•      Proponowane rozwiązania

•      Propozycje działań

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Zapobieganie defektom zgodnie z planem.

Opracowanie

Przykładowe działania, w których mogą uczestniczyć interesariusze:

•      Definiowanie parametrów wyboru defektów

•      Definiowanie schematów klasyfikacji defektów

•      Wybór defektów do analizy

•      Wykonywanie analizy przyczyn

•      Ocena zaproponowanych rozwiązań

•      Opracowanie propozycji działań

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Zapobieganie defektom (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Zapobieganie defektom:

•      Koszty działań związanych z zapobieganiem defektom

•      Liczba przeanalizowanych defektów

•      Liczba zidentyfikowanych podstawowych przyczyn

•      Liczba niezrealizowanych propozycji działań i czas opóźnień

•      Liczba zgłoszonych propozycji działań

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Zapobieganie defektom oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Wybór defektów z wykorzystaniem parametrów wyboru

•      Analiza defektów z wykorzystaniem parametrów wyboru

•      Określanie przyczyn defektów

•      Analiza przyczyn defektów

•      Określanie rozwiązań

•      Zgłaszanie propozycji działań

•      Wdrażanie propozycji działań

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Zapobieganie defektom z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

Opracowanie

Przykładowe zagadnienia, które należy omówić z kierownictwem wyższego szczebla:

•      Status działań związanych z zapobieganiem defektom

•      Określone wspólne i podstawowe przyczyny defektów

•      Rezultaty działań związanych z zapobieganiem defektom, np. zgłoszone propozycje udoskonaleń

•      Rzeczywista pracochłonność i wykorzystanie innych zasobów w porównaniu z planem

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Zapobieganie defektom.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Zapobieganie defektom, w celu wsparcia wykorzystania procesów organizacji

i zasobów procesów w przyszłości oraz ich udoskonalenia.

Przykładowe miary:

•      Koszty powtarzających się defektów i rezultaty wdrożenia propozycji działań

•      Liczba i typy defektów wykrytych na poszczególnych etapach wytwarzania

•      Liczba i charakterystyka defektów wprowadzonych na poszczególnych etapach wytwarzania

PA 5.2      Kontrola jakości

Cel

Celem obszaru procesowego Kontrola jakości jest statystyczne zarządzanie i kontrola procesu testowego. Na tym poziomie wydajność procesu testowego jest w pełni przewidywalna i ustabilizowana w dopuszczalnych granicach. Testowanie na poziomie projektu odbywa się z zastosowaniem metod statystycznych opartych na reprezentatywnych próbach, co pozwala prognozować jakość produktów i zwiększyć efektywność testowania.

Uwagi wstępne

Obszar procesowy Kontrola jakości obejmuje procedury i praktyki stosowane w celu zapewnienia zgodności produktów pracy lub produktów projektu ze standardami lub wymaganiami. W szerszym kontekście procedury i praktyki obszaru Kontrola jakości mogą być również zastosowane w procesach tworzenia produktów, wskutek czego powstaje pętla sprzężenia zwrotnego zgodna z podejściem zorientowanym na zapobieganie defektom

i optymalizację charakterystycznym dla poziomu TMMi 5. Na poziomie TMMi 5 organizacje zarządzają procesem testowym w oparciu o kontrolę jakości.

Kontrola jakości procesu jest wspierana przez techniki i metody statystyczne. Podstawą kontroli jakości procesu jest reprezentacja procesu testowego jako ciągu kroków,

z których każdy również jest procesem z pewnym zestawem danych wejściowych

i wyjściowych. W idealnym przypadku wyniki poszczególnych kroków wyznaczone są przez reguły, procedury i/lub standardy określające sposób wykonania tych kroków. W praktyce wyniki danego kroku mogą być inne niż oczekiwane. Przyczyną takich różnic jest występowanie zmienności. Odchylenia mogą pojawić się m.in. na skutek błędu człowieka, działania czynników zewnętrznych w stosunku do procesu czy nieprzewidzianych zdarzeń, np. awarii sprzętu lub oprogramowania. Jeśli na przebieg kroku w procesie wpływa wiele nieprzewidzianych czynników zmienności, proces staje się niestabilny, nieprzewidywalny

i niemożliwy do kontrolowania. W przypadku nieprzewidywalnego procesu nie można mieć pewności, że jego wyniki będą się odznaczać odpowiednią jakością.

Organizacja, która kontroluje swoje procesy pod względem ilościowym, będzie w stanie osiągnąć następujące cele:

•      określić stabilność procesu,

•      określić wydajność procesu w zdefiniowanych naturalnych granicach,

•      wskazać nieprzewidywalne procesy,

•      zidentyfikować możliwości udoskonalenia istniejących procesów,

•      wskazać procesy o największej wydajności.

Kontrola jakości procesu obejmuje ustalenie celów związanych z wydajnością standardowego procesu testowego zdefiniowanego w ramach obszaru procesowego Cykl życia i integracja testów. Takie cele powinny zostać określone na podstawie zdefiniowanej polityki testów. Jak stwierdzono w opisie obszaru procesowego Cykl życia i integracja testów, do zaspokojenia potrzeb związanych z różnymi dziedzinami biznesowymi, poziomami testów, modelami cyklu życia, metodykami i narzędziami używanymi w organizacji można zastosować różne standardowe procesy testowe. Na podstawie pomiarów wydajności procesu testowego

w projektach wykonywana jest analiza, po której wprowadzane są odpowiednie korekty w celu utrzymania wydajności w dopuszczalnych granicach. Gdy wydajność procesu testowego mieści się w dopuszczalnych granicach, zdefiniowany proces testowy, powiązane pomiary

i określone granice są używane do utworzenia punktu odniesienia stosowanego do statystycznej kontroli wydajności procesu testowego. Możliwości standardowego procesu testowego organizacji, tj. oczekiwana wydajność procesu testowego w nowym projekcie, są wówczas w pełni przeanalizowane i znane. W związku z tym można na wczesnym etapie projektu podjąć spójne działania w przypadku wystąpienia zmienności, tak aby wydajność procesu mieściła się w wyznaczonych granicach. W oparciu o możliwości procesu testowego można określić jednoznaczne ilościowe cele w zakresie wydajności procesu dla danego projektu.

Kontrola jakości produktów opiera się na zastosowaniu profili operacyjnych [Musa]

i modelach użytkowania w docelowym środowisku. Na tej podstawie wyciągane są uzasadnione statystycznie wnioski i powstaje reprezentatywna próba przypadków testowych. Takie podejście, szczególnie przydatne na poziomie testów systemowych, wykorzystuje metody testowania statystycznego do prognozowania jakości produktów na podstawie reprezentatywnej próby. Innymi słowy, rezultaty uzyskane podczas testowania podzbioru możliwych przypadków reprezentowanych przez modele użytkowania lub profile operacyjne mogą posłużyć do wyciągnięcia wniosków dotyczących ogólnej wydajności produktu. Na poziomie TMMi 5 organizacja jest w stanie w sposób ilościowy określić poziomy zaufania

i wiarygodność, ponieważ istnieje infrastruktura pozwalająca odzwierciedlić najczęściej używane operacje oraz ścieżki za pomocą profilu operacyjnego z wykorzystaniem danych historycznych. W oparciu o dane testowe pochodzące z testów statystycznych buduje się różne modele, np. modele wzrostu niezawodności, dzięki którym można przewidzieć poziom zaufania i wiarygodność systemu. Poziom zaufania, wyrażany zwykle jako wartość procentowa, opisuje prawdopodobieństwo, że produkt jest wolny od defektów. Wiarygodność definiuje się jako prawdopodobieństwo, że w produkcie nie ma żadnych defektów, które spowodują awarię systemu. Zarówno poziom zaufania, jak i wiarygodność są zwykle używane do zdefiniowania kryteriów wyjścia w przypadku testowania statystycznego. Na poziomie TMMi 5 te czynniki brane są pod uwagę łącznie i stanowią zwykle główną przesłankę do określenia momentu zakończenia testów.

Należy zauważyć, że kontrola jakości produktów i testowanie statystyczne to dziedziny wymagające bardzo dobrej znajomości technik statystycznych, w tym modelowania, tworzenia modeli użytkowania, statystyk, testowania i pomiarów. Należy wybrać i przeszkolić odpowiednich specjalistów, którzy mają stać się liderami tego obszaru testowania.

Zakres

Obszar procesowy Kontrola jakości obejmuje praktyki związane z ustanowieniem statystycznie kontrolowanego procesu testowego (kontrola jakości procesów) oraz testowaniem opartym na metodach i technikach statystycznych (kontrola jakości produktów). Kontrola jakości procesów w znacznym zakresie wykorzystuje wdrożone praktyki pomiarowe określone na poziomie TMMi 4 w ramach obszaru procesowego Pomiar testów. Kontrola jakości produktów opiera się na wdrożonych praktykach określonych na poziomie TMMi 4

w ramach obszaru procesowego Ocena jakości produktów. Oba rodzaje kontroli jakości wykorzystują dostępne dane pomiarowe dotyczące jakości procesu testowego i jakości produktów uzyskane w obszarach procesowych poziomu TMMi 4.

Podsumowanie celów i praktyk szczegółowych

SG 1       Ustanowienie statystycznie kontrolowanego procesu testowego

SP 1.1       Określenie celów w zakresie wydajności procesu testowego

SP 1.2       Określenie miar wydajności procesu testowego

SP 1.3       Określenie punktów odniesienia wydajności procesu testowego

SP 1.4       Zastosowanie metod statystycznych do ustalenia przyczyn zmienności

SP 1.5       Monitorowanie wydajności wybranych procesów testowych

SG 2       Przeprowadzenie testów z wykorzystaniem metod statystycznych

SP 2.1       Opracowanie profili operacyjnych

SP 2.2       Wygenerowanie i wykonanie statystycznie wybranych przypadków testowych

SP 2.3       Zastosowanie statystycznych danych testowych do podjęcia decyzji

o zakończeniu testów

Praktyki szczegółowe dla poszczególnych celów

SG 1       Ustanowienie statystycznie kontrolowanego procesu testowego

Ustanawiany jest statystycznie kontrolowany proces testowy, w ramach którego tworzone są

i utrzymywane punkty odniesienia charakteryzujące oczekiwaną wydajność standardowych procesów testowych w organizacji.

SP 1.1       Określenie celów w zakresie wydajności procesu testowego

Określenie i utrzymywanie ilościowych celów w zakresie wydajności procesu testowego.

Należy zaznaczyć, że ta praktyka szczegółowa ma związek z praktyką SP 1.1 Określenie celów pomiaru testów z obszaru procesowego Pomiar testów na poziomie TMMi 4 i stanowi jej rozszerzenie.

Przykładowe produkty pracy

1.      Lista procesów testowych objętych analizą wydajności

2.      Cele ilościowe w zakresie wydajności procesu testowego w organizacji

Podpraktyki

1.      Analiza potrzeb biznesowych i celów związanych z jakością produktów i wydajnością procesu testowego

2.      Analiza polityki testów pod kątem zdefiniowanych celów testów i wskaźników wydajności testów

Więcej informacji na temat potrzeb i celów biznesowych, celów testów i wskaźników wydajności testów można znaleźć w opisie obszaru procesowego Polityka i strategia testów.

Należy z zestawu standardowych procesów testowych organizacji jawnie wybrać te procesy, które zostaną uwzględnione w zbiorze procesów testowych kontrolowanych statystycznie.

Zwykle zastosowanie statystycznych technik zarządzania do wszystkich standardowych procesów testowych organizacji nie będzie możliwe, celowe ani uzasadnione ekonomicznie. Wybór procesów testowych powinien być oparty na potrzebach i celach zarówno całej organizacji, jak i projektów.

3.      Zdefiniowanie celów ilościowych organizacji w zakresie wydajności procesu testowego we współpracy z odpowiednimi interesariuszami

Cele mogą być zdefiniowane bezpośrednio w odniesieniu do miar procesu testowego (np. pracochłonności testów i skuteczności usuwania defektów) lub pośrednio

w przypadku pomiarów jakości produktu (np. niezawodności) stanowiących rezultaty procesu testowego.

4.      Określenie priorytetów celów ilościowych organizacji w zakresie wydajności procesu testowego we współpracy z odpowiednimi interesariuszami, np. klientami lub użytkownikami końcowymi

5.      Rozstrzygnięcie konfliktów między poszczególnymi celami w zakresie wydajności procesu testowego (np. gdy jednego z nich nie da się osiągnąć bez uszczerbku dla realizacji innego celu)

6.      Aktualizacja celów ilościowych organizacji w zakresie wydajności procesu testowego zgodnie z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji celów ilościowych w zakresie wydajności procesu testowego:

•      Na podstawie wniosków i zaleceń wynikających ze standardowych ocen procesu testowego. Więcej informacji na temat oceny procesu testowego można znaleźć w opisie obszaru procesowego Organizacja testowa na poziomie TMMi 3. Należy zwrócić uwagę, że oceny procesu testowego na poziomie TMMi 5, zarówno formalne, jak i nieformalne, wykonywane są częściej.

•      W przypadku zmiany celów biznesowych organizacji

•      W przypadku zmiany procesów (testowych) organizacji

•      W przypadku występowania znacznych różnic między rzeczywistą wydajnością procesu testowego i określonymi celami

SP 1.2       Określenie miar wydajności procesu testowego

Określenie i utrzymywanie definicji miar, które mają zostać uwzględnione w analizach wydajności procesu testowego w organizacji.

Więcej informacji na temat wyboru i określania miar można znaleźć w opisie obszaru procesowego Pomiar testów na poziomie TMMi 4, a zwłaszcza w opisie praktyki SP 1.2 Specyfikacja miar testowych.

Przykładowe produkty pracy

1.      Definicje wybranych miar wydajności procesu testowego

Podpraktyki

1.      Wybór miar udostępniających odpowiedni zakres informacji o wydajności procesu testowego w organizacji

Może okazać się konieczny wybór miar pośrednich dla poszczególnych faz cyklu życia w celu monitorowania postępu realizacji celów.

2.      Zidentyfikowanie miar odpowiadających potrzebom zarządzania statystycznego, np. możliwych do kontrolowania

3.      Przegląd zestawu miar wydajności procesu testowego na potrzeby zarządzania statystycznego

4.      Uwzględnienie wybranych miar w zestawie wspólnych miar testowych organizacji

5.      Aktualizacja zestawu miar wydajności procesu testowego zgodnie z potrzebami

SP 1.3      Określenie punktów odniesienia wydajności procesu testowego

Utworzenie i utrzymywanie punktów odniesienia wydajności procesu testowego organizacji.

Punkty odniesienia wydajności procesu testowego organizacji służą do pomiaru wydajności testowego w ramach zestawu standardowych procesów testowych na odpowiednich poziomach szczegółowości. Mogą występować różne punkty odniesienia wydajności procesu testowego dla różnych podgrup w organizacji, np. dziedzin aplikacji, poziomów złożoności, wielkości projektów i modeli cyklu życia.

Przykładowe produkty pracy

1.       Dane punktu odniesienia związane z wydajnością procesu testowego

Podpraktyki

1.      Gromadzenie i analiza pomiarów z projektów

Więcej informacji na temat gromadzenia i analizowania danych można znaleźć w opisie obszaru procesowego Pomiar testów.

2.      Utworzenie i utrzymywanie punktów odniesienia wydajności procesu testowego

w organizacji na podstawie zgromadzonych wyników pomiarów oraz analizy

Punkty odniesienia wydajności procesu testowego (zwykle z określeniem minimalnej

i maksymalnej tolerancji) są tworzone w wyniku analizy zgromadzonych danych pomiarowych. Celem tego działania jest określenie rozkładu i zakresu wartości opisujących oczekiwaną wydajność wybranych procesów testowych stosowanych

w ramach pojedynczych projektów w organizacji.

3.      Przegląd poprawności punktów odniesienia wydajności procesu testowego i ich uzgodnienie z odpowiednimi interesariuszami

4.      Udostępnienie punktów odniesienia wydajności procesu testowego w całej organizacji

Punkty odniesienia wydajności procesu testowego używane są w projektach do oszacowania górnej i dolnej granicy wydajności procesu testowego. Opis praktyki SP 1.4 Zastosowanie metod statystycznych do ustalenia przyczyn zmienności zawiera więcej informacji na temat górnej i dolnej granicy wydajności procesu testowego.

5.      Aktualizacja zestawu punktów odniesienia wydajności procesu testowego zgodnie

z potrzebami

Przykładowe sytuacje, w których może zachodzić konieczność aktualizacji punktów odniesienia wydajności procesu testowego:

•      W przypadku zmiany celów biznesowych organizacji

•      W przypadku zmiany procesów (testowych) organizacji

•      W przypadku występowania znacznych różnic między rzeczywistą wydajnością procesu testowego a określonymi punktami odniesienia

SP 1.4       Zastosowanie metod statystycznych do ustalenia przyczyn zmienności

Określenie i utrzymywanie informacji o zmiennej wydajności wybranych procesów testowych z zastosowaniem wybranych miar.

Zmienność procesu można w pewnym zakresie określić dzięki zgromadzeniu i analizie wartości pomiarów. Pozwala to zidentyfikować (wspólne) przyczyny zmienności i je wyeliminować, a w rezultacie uzyskać przewidywalny poziom wydajności procesu.

Przykładowe produkty pracy

1.      Zgromadzone wyniki pomiarów

2.      Górne i dolne granice wydajności procesu testowego dla każdego mierzonego atrybutu poszczególnych procesów

3.      Wydajność procesu testowego w porównaniu z górnymi i dolnymi granicami wydajności dla każdego mierzonego atrybutu poszczególnych procesów

Podpraktyki

1.      Ustalenie próbnych wartości górnej i dolnej granicy (granic kontrolnych) wydajności procesu testowego z wykorzystaniem odpowiednich danych historycznych

Wartości graniczne atrybutu określają zakres, w którym standardowo występują różnice wartości. W przypadku wszystkich procesów będzie występować pewna zmienność wartości pomiarów za każdym razem, gdy są one wykonywane. Na ogół granice kontrolne (górna i dolna granica) ustalane są na dwa lub trzy odchylenia standardowe (2 lub 3 sigma). Można je również zawęzić do jednego odchylenia standardowego

(1 sigma); wyznaczony przedział jest wówczas najbardziej ograniczony. Dzięki wyznaczeniu granic kontrolnych grupa procesu testowego może łatwiej odróżnić sygnał od szumu. Zmienność punktów danych w ramach granic kontrolnych występuje na skutek zaburzeń w procesie (typowa przyczyna normalnych rozbieżności).

2.      Gromadzenie danych zgodnie z definicjami odpowiednich miar dla procesów testowych w trakcie ich wykonywania

Gromadzone i weryfikowane są dane z projektów realizowanych w organizacji zgodnie z wybranymi procedurami. Dane te są zapisywane w bazie pomiarów testowych.

3.      Obliczenie granic wydajności procesów testowych dla każdego mierzonego atrybutu

Przykłady narzędzi i metod, w których obliczane są granice kontrolne:

•      Karty kontrolne

•      Histogramy

•      Wykresy liniowe

•      Przedziały ufności

•      Przedziały predykcji

4.      Zidentyfikowanie przyczyn zmienności

Kryteria wykrywania przypadków zmienności opierają się na teorii statystyki

(np. wyznaczane są granice kontrolne zgodnie z regułą Trzech sigm), doświadczeniu

i aspektach ekonomicznych. Ważną czynnością wykonywaną w trakcie identyfikowania przyczyn zmienności jest ustalenie, czy jej źródłem są specyficzne okoliczności

(tzw. przyczyna przypisywalna albo szczególna), które można powiązać z konkretnym czasem lub miejscem, czy też występuje zmienność wynikająca z samego charakteru realizowanego procesu (tzw. przyczyna wspólna lub naturalna). Ogólnie rzecz ujmując zalecane jest zajęcie się najpierw przyczynami przypisywalnymi, ponieważ ich wyeliminowanie może częściowo ograniczyć występowanie przyczyn wspólnych.

5.      Analiza przyczyn zmienności w procesie testowym w celu ustalenia powodów wystąpienia anomalii

Przykłady technik analizy przyczyn zmienności:

•      Diagramy przyczynowo-skutkowe (diagramy rybiej ości)

•      Zaprojektowane eksperymenty

•      Karty kontrolne (stosowane do danych wejściowych lub bazowych podprocesów testowych)

•      Podział na podgrupy

Należy pamiętać, że niektóre anomalie mogą być po prostu ekstremami używanego rozkładu i nie muszą oznaczać problemów.

Więcej informacji na temat analizowania przyczyn wystąpienia anomalii można znaleźć

w opisie obszaru procesowego Zapobieganie defektom.

6.      Określenie działań naprawczych, które należy podjąć po zidentyfikowaniu przyczyn zmienności

Więcej informacji na temat podejmowania działań naprawczych można znaleźć w opisie obszaru procesowego Optymalizacja procesu testowego.

7.      Ponowne obliczenie górnych i dolnych granic dla każdego mierzonego atrybutu wybranych procesów testowych zgodnie z potrzebami

8.      Zarejestrowanie danych statystycznych dotyczących zarządzania w repozytorium danych pomiarowych organizacji

Więcej informacji na temat zarządzania danymi, definicjami miar i wynikami oraz przechowywania takich informacji można znaleźć w opisie obszaru procesowego Pomiar testów.

SP 1.5       Monitorowanie wydajności wybranych procesów testowych

Monitorowanie wydajności wybranych procesów testowych na potrzeby określenia ich zdolności do realizacji ustalonych celów w zakresie wydajności procesu oraz zidentyfikowania ewentualnych działań naprawczych.

Celem tej praktyki szczegółowej jest statystyczny opis działania danego procesu oraz ocena prawdopodobieństwa, że jest on w stanie zrealizować ustalone cele w zakresie wydajności.

Przykładowe produkty pracy

1.      Wydajność procesu dla każdego procesu testowego

2.      Granice wydajności procesu dla każdego wybranego procesu testowego w porównaniu z ustalonymi celami

3.      Dokumentacja działań niezbędnych do wyeliminowania ograniczeń wydajności (dla każdego procesu testowego)

Podpraktyki

1.      Porównanie wartości granicznych mierzonych atrybutów z celami w zakresie wydajności procesu testowego

Porównanie stanowi ocenę zdolności procesu testowego dla każdego atrybutu podlegającego pomiarowi.

2.      Okresowy przegląd wydajności każdego wybranego procesu testowego i możliwości zarządzania nimi metodami statystycznymi oraz ocena realizacji celów procesu testowego w zakresie wydajności

3.      Zidentyfikowanie i udokumentowanie ograniczeń zdolności procesu testowego

4.      Określenie i udokumentowanie działań niezbędnych do wyeliminowania ograniczeń wydajności procesu testowego

SG 2       Przeprowadzenie testów z wykorzystaniem metod statystycznych

Testy są projektowane i wykonywane z wykorzystaniem metod statystycznych opartych na profilach operacyjnych lub profilach użytkowania.

SP 2.1       Opracowanie profili operacyjnych

Profile operacyjne (lub modele użytkowania) są opracowywane na wczesnych etapach cyklu wytwarzania oprogramowania. Na ich podstawie tworzone są poprawne statystycznie próby przypadków testowych.

Przykładowe produkty pracy

1.      Profil operacyjny systemu podlegającego testowaniu

Podpraktyki

1.      Opracowanie profilu klientów

Klient to osoba, grupa lub organizacja, która nabywa wytwarzany produkt. Grupa klientów to zbiór klientów, którzy będą używać produktu w taki sam sposób. Profil klientów to pełny zbiór grup klientów oraz powiązany rozkład ich częstotliwości występowania w ramach profilu.

2.      Opracowanie profilu użytkowników

Profil użytkowników to pełny zbiór grup użytkowników (zbiorów rzeczywistych użytkowników, którzy będą korzystać z systemu w taki sam sposób) oraz powiązany rozkład ich częstotliwości występowania w ramach profilu.

3.      Opracowanie profilu trybu systemu

Profil trybu systemu to zbiór trybów systemu (zbiorów funkcji lub operacji zgrupowanych w celu analizy działania systemu) oraz powiązanych prawdopodobieństw ich wystąpienia.

4.      Opracowanie profilu funkcjonalnego

Profil funkcjonalny udostępnia ilościowe informacje (dla poszczególnych trybów systemu) o względnych wskaźnikach użycia poszczególnych funkcji systemu.

5.      Opracowanie profilu operacyjnego

Operacja to zadanie realizowane przez system. Końcowy profil operacyjny  powstaje

w wyniku wykonania ciągu kroków wykorzystujących informacje z profili, które zostały opracowane wcześniej. Obejmuje to m.in. [Musa]:

- Podział wykonania na przebiegi

- Zidentyfikowanie przestrzeni wejściowej (obszernej listy zmiennych wejściowych)

- Podział przestrzeni wejściowej na operacje

- Określenie prawdopodobieństwa wystąpienia operacji

6.      Przegląd i uzgodnienie profilu operacyjnego z udziałem interesariuszy

7.      Aktualizacja profilu operacyjnego zgodnie z potrzebami

SP 2.2       Wygenerowanie i wykonanie statystycznie wybranych przypadków testowych

Przypadki testowe są generowane na podstawie statystycznie wybranych prób obejmujących użycie produktu, a następnie są wykonywane.

Przykładowe produkty pracy

1.      Przypadki testowe

2.      Rezultaty testów

3.      Rejestr monitorowania reprezentatywności

Podpraktyki

1.      Wybór prób obejmujących użycie produktu na podstawie opracowanego modelu użytkowania lub profilu operacyjnego

2.      Wygenerowanie przypadków testowych na podstawie wybranych prób charakterystycznych dla sposobu eksploatacji produktu

Wygenerowane przypadki testowe odzwierciedlają prawdopodobieństwo określone

w modelu użytkowania lub profilu operacyjnym i reprezentują próbkę przestrzeni wejściowej zgodną ze wzorcami użytkowania.

3.      Przegląd i uzgodnienie przypadków testowych z udziałem interesariuszy

4.      Wykonanie przypadków testowych i zarejestrowanie rzeczywistych rezultatów

5.      Monitorowanie pokrycia testowego i sprawdzanie, czy reprezentuje rzeczywiste użycie systemu

Podczas testowania stosowane są narzędzia i metody pomiaru pozwalające na ustalenia, czy zestaw wykonywanych przypadków testowych reprezentuje rzeczywiste użycie systemu. Jedynie wówczas, gdy zespół testowy uzna, że testy w wystarczającym stopniu symulują oczekiwane działanie systemu w trakcie eksploatacji, rezultaty takich testów wraz z innymi danymi mogą posłużyć do podjęcia decyzji o zakończeniu testowania.

6.      Aktualizacja przypadków testowych zgodnie z potrzebami, jeśli pokrycie testowe rzeczywistego użycia nie jest wystarczające

7.      Analiza i wyciągnięcie wniosków statystycznych z rezultatów testów

W ramach tej podpraktyki na podstawie próby statystycznej wyciągane są wnioski dotyczące całej populacji klientów i użytkowników. Zwykle odbywa się to z wykorzystaniem modeli niezawodności. Typowe problemy, które należy rozstrzygnąć, obejmują odpowiedzi na pytania:

- W jakim tempie wzrasta jakość produktu?

- Czy testowanie można przeprowadzić z uwzględnieniem ograniczeń dotyczących projektu i zasobów testowych?

SP 2.3       Zastosowanie statystycznych danych testowych do podjęcia decyzji

o zakończeniu testów

Określane są oszacowania dotyczące niezawodności produktu oraz poziom zaufania odnośnie do jakości produktu. Na podstawie tych oszacowań podejmowane są decyzje o zakończeniu testów.

Przykładowe produkty pracy

1.      Definicja poziomów ważności awarii

2.      Cele związane z niezawodnością i poziomem zaufania

3.      Miary niezawodności i poziomu zaufania

4.      Udokumentowane wyniki przeglądu, np. protokoły ze spotkań dotyczących przeglądu

Podpraktyki

1.      Ustalenie poziomów ważności awarii

Ważne jest zidentyfikowanie różnych klas lub poziomów awarii oraz sposobów ich traktowania w przypadku pomiaru niezawodności produktu. Zwykle określa się wymagania dotyczące niezawodności dla poszczególnych poziomów awarii.

2.      Zdefiniowanie ilościowych celów związanych z niezawodnością, które będą używane jako kryteria wyjścia i kryteria podjęcia decyzji o zakończeniu testów

Przykładowe typy celów związanych z niezawodnością:

•      Niezawodność mierzona jako średni czas pomiędzy awariami (ang. Mean Time Between Failure - MTBF), średni czas do naprawy (ang. Mean Time To Repair - MTTR) i średni czas bezawaryjnej pracy (ang. Mean Time To Failure - MTTF)

•      Dostępność

•      Odtwarzalność

•      Wiarygodność

•      Poziom zaufania (jeśli poziomy zaufania są używane jako cele związane

z niezawodnością, w ramach procesu testowania statystycznego zwykle stosuje się technikę posiewu usterek)

3.      Przegląd i uzgodnienie celów związanych z niezawodnością z udziałem interesariuszy

4.      Wybór odpowiedniego modelu wzrostu niezawodności

Przykładowe typy modeli wzrostu niezawodności [Musa i Ackerman]:

•      Model statyczny, który najlepiej sprawdza się w przypadku oprogramowania niepodlegającego zmianom, z niezmiennym profilem operacyjnym

•      Model podstawowy, przydatny w przypadku modelowania wystąpień awarii

w oprogramowaniu podlegającym testowaniu i ciągłemu debugowaniu

•      Logarytmiczny model Poissona, który najlepiej sprawdza się przy założeniu, że niektóre defekty z większym prawdopodobieństwem powodują awarie i że w trakcie wprowadzania poprawek średni spadek częstotliwości występowania awarii maleje wykładniczo po wprowadzeniu każdej kolejnej poprawki.

5.      Gromadzenie danych statystycznych dotyczących awarii i czasu wykonywania systemu

6.      Obliczenie i oszacowanie miar niezawodności z wykorzystaniem modelu wzrostu niezawodności poprzez dopasowanie modelu i ekstrapolację na podstawie zgromadzonych danych

7.      Przegląd statusu realizacji celów związanych z niezawodnością z udziałem interesariuszy

8.      Udokumentowanie wyników przeglądów, działań do wykonania i decyzji o zakończeniu testów

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Kontrola jakości.

Opracowanie

Polityka określa cele i oczekiwania organizacji związane z określeniem punktów odniesienia wydajności dla zestawu standardowych procesów testowych organizacji oraz statystycznym zarządzaniem wybranymi procesami testowymi.

Polityka dotycząca kontroli jakości zwykle zawiera następujące ustalenia:

•      Pomiary wydajności procesu testowego w projekcie podlegają analizie w celu określenia i utrzymywania punktu odniesienia opisującego możliwości standardowego procesu testowego organizacji

•      Punkt odniesienia opisujący możliwości standardowego procesu testowego organizacji jest wykorzystywany w projektach do określania odpowiednich celów w zakresie wydajności procesu testowego

•      W testach wykorzystywane są metody statystyczne oparte na profilach operacyjnych,

a ich celem jest pomiar niezawodności produktu

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Kontrola jakości.

Opracowanie

Zwykle plan realizacji działań związanych z kontrolą jakości procesów jest uwzględniany

w planie doskonalenia procesu testowego organizacji lub w nim przywoływany (plan ten został opisany w rozdziale poświęconym obszarowi procesowemu Organizacja testowa). Plan działań może być również odrębnym dokumentem odnoszącym się wyłącznie do procesu Kontrola jakości.

Działania związane z prowadzeniem testowania statystycznego zwykle uwzględnia się

w planie testów. Plan testów obejmuje m.in. tworzenie i modyfikowanie profilu operacyjnego, uruchamianie testów oraz gromadzenie, katalogowanie i analizowanie danych dotyczących niezawodności.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Kontrola jakości, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

•      Zapewniono odpowiedni czas na wykonanie czynności związanych z tworzeniem profilu operacyjnego i przeprowadzeniem testowania statystycznego

•      Do utworzenia punktów odniesienia wydajności dla zestawu standardowych procesów testowych organizacji oraz do zdefiniowania technik zarządzania statystycznego wybranymi procesami testowymi może być niezbędna specjalistyczna wiedza

z dziedziny statystyki i statystycznej kontroli procesów

•      Wiedza z dziedziny statystyki może być również potrzebna do analizowania

i interpretowania wyników pomiarów na potrzeby zarządzania statystycznego

•      Istnieje program pomiaru testów w całej organizacji

•      Dostępne są narzędzia wspierające proces kontroli jakości

Przykładowe narzędzia:

•      Narzędzia do zarządzania bazami danych

•      Narzędzia do modelowania procesów

•      Pakiety do analizy statystycznej

•      Narzędzia do zarządzania incydentami

•      Narzędzia do analizy pokrycia

•      Pakiety do statystycznego zarządzania procesem i kontroli jakości

•      Narzędzia do pomiaru niezawodności

GP 2.4 Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Kontrola jakości, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Kontrola jakości.

Opracowanie

Aby można było osiągnąć cele związane z jakością procesów, różne grupy muszą ze sobą współpracować. Zalecane jest, by zespół ds. kontroli procesów działał wspólnie w ramach grupy procesu testowego. Członkowie zespołu mogą być wybierani z różnych jednostek funkcjonalnych, np. spośród programistów, testerów i specjalistów ds. zapewnienia jakości.

W pracach zespołu powinni uczestniczyć zarówno członkowie kierownictwa, jak i zwykli pracownicy.

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Kontrola jakości zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

•      Modelowanie i analiza procesów

•      Wybór, definiowanie, gromadzenie i weryfikacja danych z pomiarów procesów

•      Statystyczna kontrola procesów

•      Metody i techniki statystyczne (np. karty kontrolne, wykresy punktowe i analiza Pareto)

•      Testowanie statystyczne

•      Modele użytkowania i profile operacyjne

•      Zarządzanie niezawodnością (np. modelami niezawodności, miarami i modelami wzrostu niezawodności)

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Kontrola jakości odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Cele w zakresie wydajności procesu testowego w organizacji

•      Definicje wybranych miar wydajności procesu testowego wraz z punktami ich gromadzenia w procesach oraz sposoby określania integralności danych pomiarowych

•      Dane punktu odniesienia związane z wydajnością procesu testowego w organizacji

•      Zgromadzone w projektach wyniki pomiarów

•      Profile operacyjne

•      Zestaw wygenerowanych przypadków testowych

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Kontrola jakości zgodnie z planem.

Opracowanie

Przykłady zaangażowania interesariuszy:

•      Definiowanie celów organizacji w zakresie wydajności procesu testowego i określanie ich priorytetów

•      Przegląd celów organizacji w zakresie wydajności procesu testowego i rozwiązywanie problemów

•      Ocena wydajności wybranych procesów testowych

•      Identyfikowanie działań naprawczych, które należy podjąć

•      Definiowanie profili operacyjnych

•      Przegląd rezultatów testów

•      Podejmowanie decyzji o zakończeniu testów

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Kontrola jakości (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Kontrola jakości:

•      Trendy związane z wydajnością procesu testowego w organizacji wynikające ze zmian w produktach pracy i atrybutach zadań (np. pracochłonność testowania, czas wykonywania testów i jakość produktów)

•      Profil procesów testowych objętych zarządzaniem statystycznym (np. planowana liczba procesów objętych zarządzaniem statystycznym, aktualna liczba procesów objętych zarządzaniem statystycznym, liczba procesów stabilnych statystycznie)

•      Liczba zidentyfikowanych i wyeliminowanych przyczyn zmienności

•      Stopień, w jakim wykonywane testy reprezentują oczekiwany sposób użycia systemu

•      Trendy związane z niezawodnością

GP 2.9       Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Kontrola jakości oraz wybranych produktów pracy

z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Określenie punktów odniesienia wydajności procesu testowego

•      Cele w zakresie wydajności procesu testowego w organizacji

•      Definicje wybranych miar wydajności procesu testowego

•      Zarządzanie statystyczne wybranymi procesami testowymi

•      Zgromadzone wyniki pomiarów

•      Skuteczność i efektywność testowania statystycznego

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Kontrola jakości z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

GG 3      Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Kontrola jakości.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Kontrola jakości, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Górna i dolna granica gęstości defektów

•      Pracochłonność przeglądów jako odsetek łącznej pracochłonności prac wytwórczych

•      Pracochłonność testowania jako odsetek łącznej pracochłonności prac wytwórczych

•      Uzyskane pokrycie

•      Skuteczność testowania statystycznego, np. wyrażona jako odsetek wykrytych defektów – OWD (ang. Defect Detection Percentage - DDP).

PA 5.3       Optymalizacja procesu testowego

Cel

Celem obszaru procesowego Optymalizacja procesu testowego jest ciągłe usprawnianie istniejących procesów testowych stosowanych w organizacji, a także identyfikowanie nowych technologii testowania (np. narzędzi testowych i metod testowania), które mogą okazać się przydatne, oraz wdrażanie ich w organizacji w uporządkowany sposób. Optymalizacja procesu testowego wspiera również ponowne wykorzystanie zasobów testowych w organizacji. Usprawnienia przyczyniają się do realizacji celów organizacji dotyczących jakości produktów i wydajności procesów testowych, zdefiniowanych na podstawie celów biznesowych.

Uwagi wstępne

Na najwyższym poziomie TMMi proces testowy podlega stałemu doskonaleniu na poziomie poszczególnych projektów i całej organizacji. Proces testowy podlega pomiarom ilościowym i może być dostrajany, tak aby zwiększanie możliwości procesu odbywało się na bieżąco. Istnieje też infrastruktura organizacyjna, która wspiera taki ciągły rozwój. Infrastruktura ta obejmuje polityki, standardy, wyposażenie szkoleniowe, narzędzia i struktury organizacyjne, a do jej zbudowania przyczynia się realizacja procesów wchodzących w skład hierarchii TMMi. Optymalizacja procesu testowego to obszar, którego istotą jest zbudowanie systemu umożliwiającego ciągłe doskonalenie testowania. Optymalizacja procesu testowego obejmuje następujące działania:

•      Zdefiniowanie procedur oceny procesu testowego i jego doskonalenia oraz przypisanie odpowiedzialności z perspektywy kierownictwa

•      Zidentyfikowanie praktyk związanych z testowaniem o niewielkiej i o dużej skuteczności oraz zaproponowanie obszarów, z których można pozyskać zasoby procesu i które można ponownie wykorzystać

•      Wdrożenie przyrostowych, innowacyjnych udoskonaleń, które w wymierny sposób usprawniają działanie procesów testowych i technologii używanych w organizacji

•      Wybór i udostępnienie najlepszych praktyk organizacji

•      Ciągła ocena nowych narzędzi i technologii związanych z testami pod kątem możliwości wdrożenia

•      Wspieranie transferu technologii i wiedzy

•      Ponowne wykorzystanie zasobów testowych o wysokiej jakości

Ciągłe doskonalenie procesu testowego wiąże się z proaktywnym, systematycznym identyfikowaniem, oceną i wdrażaniem usprawnień w standardowym procesie testowym organizacji oraz w procesach zdefiniowanych w poszczególnych projektach. Potrzeba przeprowadzenia działań związanych z usprawnieniem procesu testowego często wynika również ze zmian zachodzących w otoczeniu, np. zmian kontekstu biznesowego, zmian samego środowiska testowego lub wdrożenia nowego cyklu wytwarzania oprogramowania. Działania tego rodzaju prowadzone są przy wsparciu sponsorskim kierownictwa wyższego szczebla. Tworzone są programy szkoleniowe i motywacyjne, których celem jest umożliwienie wszystkim pracownikom uczestnictwa w doskonaleniu procesu testowego i zachęcanie ich do takich działań. Po zidentyfikowaniu możliwości udoskonalenia procesu testowego następuje ich ocena pod kątem potencjalnego zwrotu z inwestycji, z uwzględnieniem celów biznesowych organizacji jako punktu odniesienia. Przed wprowadzeniem zmian w standardowym procesie organizacji realizowane są projekty pilotażowe, których celem jest ocena, pomiar i weryfikacja zaproponowanych zmian w procesie testowym.

Wsparcie optymalizacji procesu testowego zapewnia zwykle powołana przez organizację odpowiednia grupa, np. grupa procesu testowego, która we współpracy

z poszczególnymi projektami zajmuje się wprowadzaniem i oceną skuteczności nowych technologii z obszaru testowania (np. narzędzi testowych, metod i środowisk) oraz zarządzaniem zmianami w dotychczas stosowanych technologiach. Szczególny nacisk jest kładziony na zmiany technologii, które mogą zwiększyć możliwości standardowego procesu testowego organizacji (ustalonego w ramach obszaru procesowego Cykl życia i integracja testów). Dzięki śledzeniu innowacji technologicznych związanych z testowaniem, a także prowadzeniu systematycznej oceny takich rozwiązań i eksperymentów z ich wykorzystaniem, organizacja może wybrać odpowiednie technologie testowe w celu poprawy jakości swoich produktów i zwiększenia wydajności czynności testowych. Projekty pilotażowe są realizowane w celu oceny nowych i niesprawdzonych technologii przed ich ewentualnym uwzględnieniem w standardowych praktykach.

W organizacjach panuje obecnie przekonanie, że zarówno procesy testowe, jak i testalia są wartościowymi aktywami korporacyjnymi, a elementy o wysokiej jakości powinny zostać udokumentowane i zapisane w repozytorium procesów w formacie umożliwiającym modyfikowanie i ponowne wykorzystanie w kolejnych realizowanych projektach. Takie repozytorium, które mogło już powstać w nieco bardziej ograniczonym zakresie na poziomie TMMi 3, jest często nazywane biblioteką zasobów procesu testowego. Już na poziomie TMMi 3 może występować mechanizm ponownego wykorzystania testaliów, jednak ponowne wykorzystanie zasobów testowych jest ważnym celem definiowanym na poziomie TMMi 5. Warto zaznaczyć, że w tym kontekście ponowne wykorzystanie procesów oznacza zastosowanie opisu pewnego procesu testowego do utworzenia opisu innego procesu testowego.

Zakres

Obszar procesowy Optymalizacja procesu testowego obejmuje praktyki związane

z ciągłym identyfikowaniem usprawnień w procesach testowych, oceną i wyborem nowych technologii oraz ich wdrażaniem w ramach standardowego procesu testowego w organizacji, w tym planowaniem, realizacją, monitorowaniem, oceną i pomiarem działań związanych

z doskonaleniem testowania. Obejmuje także kwestie ponownego wykorzystania zasobów testowych o wysokiej jakości w całej organizacji. Ten obszar procesowy stanowi uzupełnienie i rozszerzenie procesów i praktyk zdefiniowanych w obszarach procesowych Organizacja testowa oraz Cykl życia i integracja testów na poziomie TMMi 3.

Podsumowanie celów i praktyk szczegółowych

SG 1       Wybór usprawnień procesu testowego

SP 1.1       Gromadzenie i analiza propozycji udoskonaleń procesu testowego

SP 1.2       Pilotaż propozycji udoskonaleń procesu testowego

SP 1.3       Wybór propozycji udoskonaleń procesu testowego przeznaczonych do wdrożenia

SG 2       Ocena nowych technologii testowych w celu określenia ich wpływu na proces testowy

SP 2.1       Identyfikowanie i analiza nowych technologii testowych

SP 2.2       Pilotaż nowych technologii testowych

SP 2.3       Wybór nowych technologii testowych przeznaczonych do wdrożenia

SG 3       Wdrożenie usprawnień procesu testowego

SP 3.1       Zaplanowanie wdrożenia

SP 3.2      Zarządzanie wdrożeniem

SP 3.3       Pomiar efektów usprawnień

SG 4       Stworzenie mechanizmów ponownego wykorzystania zasobów testowych

o wysokiej jakości

SP 4.1       Zidentyfikowanie zasobów testowych do ponownego wykorzystania

SP 4.2       Wybór zasobów testowych dodawanych do biblioteki zasobów do ponownego wykorzystania

SP 4.3       Wdrożenie zasobów testowych do ponownego wykorzystania

SP 4.4       Zastosowanie w innych projektach zasobów testowych do ponownego wykorzystania

Praktyki szczegółowe dla poszczególnych celów

SG 1       Wybór usprawnień procesu testowego

Wybierane są usprawnienia procesu testowego, które przyczyniają się do realizacji celów związanych z jakością produktów i wydajnością procesu testowego.

SP 1.1       Gromadzenie i analiza propozycji udoskonaleń procesu testowego

Ciągłe gromadzenie i analizowanie propozycji udoskonaleń standardowego procesu testowego w organizacji.

W ramach tej praktyki szczegółowej analizuje się propozycje gromadzone wewnątrz organizacji. Informacje na temat aktywnego wyszukiwania innowacyjnych i nowych technologii testowych na zewnątrz organizacji zawiera opis praktyki SP 2.1 Identyfikowanie i analiza nowych technologii testowych.

Przykładowe produkty pracy

1.      Przeanalizowane propozycje udoskonaleń procesu testowego

2.      Lista propozycji udoskonaleń procesu testowego, które powinny zostać objęte pilotażem

Podpraktyki

1.       Gromadzenie propozycji udoskonaleń procesu testowego

Propozycja udoskonalenia procesu testowego dokumentuje proponowane usprawnienia konkretnego procesu testowego.

Przykładowe źródła propozycji udoskonaleń procesu testowego:

•       Wnioski i zalecenia wynikające ze standardowych ocen procesu testowego. Więcej informacji na temat oceny procesu testowego można znaleźć w opisie obszaru procesowego Organizacja testowa na poziomie TMMi 3.

Należy zwrócić uwagę, że oceny procesu testowego na poziomie TMMi 5, zarówno formalne, jak i nieformalne, wykonywane są częściej.

•      Analiza danych dotyczących problemów klientów lub użytkowników końcowych, a także poziomu ich zadowolenia

•      Analiza danych dotyczących jakości produktów i wydajności procesu testowego

w odniesieniu do ustalonych celów

•      Analiza danych w celu określenia typowych przyczyn błędów, np. z obszaru Zapobieganie defektom

•      Dane operacyjne produktów

•      Pomiary skuteczności i efektywności czynności związanych z procesem testowym

•      Dokumenty dotyczące wyciągniętych wniosków (np. raporty z ukończenia testów)

•      Pomysły zgłaszane przez członków kierownictwa i pracowników

•      Spotkania dotyczące retrospektywy projektu

•      Oceny narzędzi testowych (narzędzia testowe są regularnie poddawane ocenie pod kątem realizacji zdefiniowanych celów)

Więcej informacji na temat propozycji udoskonaleń procesu testowego można znaleźć w opisie obszaru procesowego Organizacja testowa.

2.      Analiza kosztów i korzyści związanych z propozycjami udoskonaleń procesu testowego w odpowiednim zakresie

Propozycje udoskonaleń procesu testowego, z którymi nie wiąże się oczekiwany dodatni zwrot z inwestycji, są odrzucane.

Przykładowe kryteria oceny kosztów i korzyści:

•      Udział w realizacji celów organizacji związanych z jakością produktów i wydajnością procesu testowego

•      Wpływ na łagodzenie zidentyfikowanych ryzyk projektu testowego i ryzyk produktowych

•      Zdolność do szybkiego reagowania na zmieniającą się sytuację

•      Wpływ na powiązane procesy (testowe) i ich zasoby

•      Koszty definiowania i gromadzenia danych wspierających pomiary i analizę propozycji dotyczących procesu testowego

•      Oczekiwana trwałość rezultatów wdrożenia propozycji

3.      Analiza ryzyk projektowych związanych z propozycjami udoskonaleń procesu testowego

Przykładowe czynniki ryzyka, które mają wpływ na wdrażanie usprawnień procesu:

•      Złożoność usprawnienia

•      Kwalifikacje potencjalnych użytkowników

•      Jednoczesne wprowadzanie wielu zmian

•      Niejasne oczekiwania

•      Brak krótkoterminowych korzyści i widocznych sukcesów

•      Konsekwencje niewdrożenia lub tylko częściowego wdrożenia propozycji

4.      Oszacowanie kosztów, pracochłonności i harmonogramu wdrożenia poszczególnych propozycji udoskonalenia procesu

5.      Zidentyfikowanie propozycji udoskonaleń procesu, które powinny zostać objęte pilotażem przed wdrożeniem w całej organizacji; w zależności od potrzeb należy rozważyć także inne możliwości, np. eksperymenty kontrolowane, symulacje i analizy przykładów.

6.      Udokumentowanie wyników oceny poszczególnych propozycji udoskonaleń procesu

SP 1.2       Pilotaż propozycji udoskonaleń procesu testowego

Pilotaż propozycji udoskonaleń procesu testowego w celu wyboru usprawnień do wdrożenia.

Projekty pilotażowe są realizowane w celu oceny nowych i niesprawdzonych dużych zmian przed ich ewentualnym wdrożeniem w całej organizacji.

Przykładowe produkty pracy

1.      Raporty z oceny pilotażu

Podpraktyki

1.      Zaplanowanie pilotażu usprawnień procesu testowego

2.      Zdefiniowane celów pilotażu i kryteriów oceny rezultatów

3.      Przegląd planów pilotażu i uzyskanie zgody interesariuszy

4.      Szkolenie i wsparcie osób prowadzących pilotaż

5.      Realizacja poszczególnych projektów pilotażowych w środowisku wystarczająco reprezentatywnym dla środowiska, w którym ma nastąpić wdrożenie usprawnień procesu testowego

Na potrzeby projektów pilotażowych należy udostępnić dodatkowe zasoby, jeśli to konieczne.

6.      Śledzenie realizacji projektów pilotażowych w odniesieniu do planu

7.      Przegląd i udokumentowanie rezultatów poszczególnych projektów pilotażowych

Przegląd i udokumentowanie rezultatów projektu pilotażowego zwykle obejmuje następujące działania:

- Decyzja o zakończeniu projektu pilotażowego, ponownym zaplanowaniu

i kontynuacji pilotażu lub wdrożeniu danego usprawnienia procesu testowego

- Aktualizacja decyzji dotyczącej propozycji udoskonaleń procesu testowego weryfikowanej w ramach pilotażu

- Określenie nowych i aktualizacja dotychczasowych propozycji udoskonaleń procesu testowego, jeśli zachodzi taka potrzeba

- Określenie i udokumentowanie wniosków wyciągniętych z projektu pilotażowego oraz napotkanych problemów

SP 1.3       Wybór propozycji udoskonaleń procesu testowego przeznaczonych do wdrożenia

Wybór propozycji udoskonaleń procesu testowego przeznaczonych do wdrożenia

w organizacji.

Na podstawie ilościowych kryteriów opartych na celach w zakresie wydajności procesu testowego następuje wybór propozycji udoskonaleń procesu testowego przeznaczonych do wdrożenia w organizacji.

Przykładowe produkty pracy

1.      Propozycje udoskonaleń procesu testowego przeznaczone do wdrożenia

2.      Dokumentacja wyników procesu wyboru (wraz z uzasadnieniem podjętych decyzji)

Podpraktyki

1.       Określenie priorytetów potencjalnych udoskonaleń procesu testowego przeznaczonych do wdrożenia

Priorytet jest ustalany na podstawie oceny szacowanego zwrotu z inwestycji związanego z realizacją celów w zakresie wydajności procesu testowego.

Więcej informacji na temat celów w zakresie wydajności procesu testowego można znaleźć w opisie obszaru procesowego Kontrola jakości.

Przykładowe kryteria, których można użyć w trakcie określania priorytetów:

•      Udział w realizacji celów w zakresie wydajności testowania

•      Zgodność z modelem dojrzałości (np. w przypadku próby formalnego uzyskania poziomu dojrzałości)

•      Widoczność propozycji udoskonalenia

•      Koszty propozycji udoskonalenia

•      Łatwość wdrożenia propozycji udoskonalenia

•      Oczekiwany poziom akceptacji propozycji udoskonalenia (niektóre osoby mogą początkowo okazywać stanowczy sprzeciw wobec zmiany)

•      Złagodzenie ryzyka w wyniku wdrożenia propozycji udoskonalenia

2.      Wybór usprawnień procesu testowego przeznaczonych do wdrożenia

Wyboru usprawnień procesu testowego dokonuje się z uwzględnieniem ich priorytetów i dostępnych zasobów.

3.      Określenie podejścia dotyczącego poszczególnych wdrażanych usprawnień procesu testowego

Przykłady zagadnień uwzględnianych w ramach podejścia do wdrażania:

•      Zasoby procesu testowego w organizacji, których dotyczy zmiana

•      Objęcie zmianą wszystkich projektów w organizacji lub ich podzbioru

•      Objęcie zmianą wszystkich systemów w organizacji lub ich podzbioru

4.      Udokumentowanie wyników procesu wyboru

SG 2       Ocena nowych technologii testowych w celu określenia ich wpływu na proces testowy

Nowe technologie testowe, np. narzędzia, metody, techniki lub innowacje techniczne, są identyfikowane, wybierane i oceniane w celu określenia ich wpływu na standardowy proces testowy w organizacji.

SP 2.1       Identyfikowanie i analiza nowych technologii testowych

Ciągłe identyfikowanie i analizowanie innowacyjnych i nowych technologii testowych (np. nowych narzędzi testowych lub metod testowania), które mogą przyczynić się do wzrostu jakości i wydajności standardowego procesu testowego w organizacji.

Praktyka szczegółowa SP 1.1 Gromadzenie i analiza propozycji udoskonaleń procesu testowego wiąże się z analizą propozycji rejestrowanych wewnątrz organizacji. Celem niniejsze praktyki szczegółowej SP 2.1 jest aktywne poszukiwanie innowacyjnych i nowych technologii testowania na zewnątrz.

Przykładowe produkty pracy

1.      Lista nowych technologii testowych branych pod uwagę

2.      Lista przeanalizowanych nowych technologii testowych

3.      Propozycje udoskonaleń procesu testowego

4.      Lista technologii testowych, które powinny zostać objęte pilotażem

Podpraktyki

1.       Ciągłe sprawdzanie innowacyjnych i nowych technologii testowych

Przykładowe działania związane ze sprawdzaniem technologii:

•      Systematycznie śledzenie najważniejszych osiągnięć i trendów, np. poprzez udział

w konferencjach i webinariach oraz lekturę publikacji

•      Regularne poszukiwanie dostępnych na rynku innowacyjnych i nowych technologii testowych

•      Zapoznawanie się z nowymi standardami testowania i analizowanie możliwości ich zastosowania w organizacji

•      Systematyczne przeglądy procesów testowych, narzędzi i metod używanych poza organizacją i porównywanie ich z rozwiązaniami stosowanymi w organizacji

•      Prowadzenie testów porównawczych wydajności procesu testowego ze wskaźnikami wydajności w branży

•      Przeglądy przykładowych usprawnień procesu testowego wdrożonych w innych podmiotach

•      Udział w specjalistycznych grupach tematycznych związanych z testowaniem

•      Współpraca z uczestnikami innych inicjatyw doskonalenia w organizacji w celu zidentyfikowania potencjalnych korzyści dla testowania

2.      Analiza potencjalnych innowacyjnych i nowych technologii testowania (np. nowych narzędzi lub metod) w celu określenia ich wpływu na elementy procesu testowego

i przewidzenia konsekwencji ich zastosowania w procesie

W ramach analizy należy wziąć pod uwagę ograniczenia, priorytety potencjalnych funkcji, problemy dotyczące sprzętu i oprogramowania, doświadczenie dostawców, prezentacje przygotowane przez dostawców oraz kwestie integracji z istniejącymi technologiami i procesami.

3.      Analiza kosztów i korzyści związanych z potencjalnymi nowymi technologiami testowymi

Propozycje udoskonaleń procesu testowego, z którymi nie wiąże się oczekiwany dodatni zwrot z inwestycji, są odrzucane. Istotnym kryterium jest oczekiwany udział nowej technologii w osiągnięciu celów organizacji związanych z jakością produktów

i wydajnością procesu testowego.

Należy rozpatrzyć zarówno koszty krótkoterminowe, jak i cykliczne koszty długoterminowe (koszty utrzymania), a także uwzględnić zgodność nowej technologii testowej z polityką testów.

W ramach tej podpraktyki rozpatruje się również alternatywne rozwiązania, np. zmiany w procesie testowym, z którymi mogą wiązać się takie same korzyści uzyskiwane przy niższych kosztach.

4.      Utworzenie propozycji udoskonaleń dotyczących tych nowych technologii testowych, które mogą usprawnić działanie organizacji

W ramach propozycji należy oszacować koszty, pracochłonność i harmonogram wdrożenia nowej technologii testowej.

5.      Zidentyfikowanie nowych technologii testowych, które powinny zostać objęte pilotażem przed ich ewentualnym wdrożeniem w całej organizacji

Należy rozważyć także inne możliwości, np. eksperymenty kontrolowane, symulacje

i analizy przykładów.

6.      Udokumentowanie wyników oceny poszczególnych propozycji nowych technologii testowych

SP 2.2       Pilotaż nowych technologii testowych

Pilotaż nowych technologii testowych w celu wyboru rozwiązań do wdrożenia.

Projekty pilotażowe są realizowane w celu oceny nowych i niesprawdzonych technologii testowych przed ich ewentualnym wdrożeniem w całej organizacji. W szczególności dotyczy to rozwiązań, które mają istotny wpływ na działanie organizacji.

Przykładowe produkty pracy

1.      Raporty z oceny pilotażu

Podpraktyki

1.      Zaplanowanie pilotażu nowych technologii testowych

2.      Zdefiniowane celów pilotażu i kryteriów oceny rezultatów

3.      Przegląd planów pilotażu i uzyskanie zgody interesariuszy

4.      Szkolenie i wsparcie osób prowadzących pilotaż

Szkolenie i wsparcie może być realizowane przez wewnętrznych konsultantów

ds. testów, ewentualnie wspomaganych przez zewnętrznego dostawcę.

5.      Realizacja poszczególnych projektów pilotażowych w środowisku wystarczająco reprezentatywnym dla środowiska, w którym ma nastąpić wdrożenie nowej technologii testowej

Na potrzeby projektów pilotażowych należy udostępnić dodatkowe zasoby, jeśli to konieczne.

6.      Śledzenie realizacji projektów pilotażowych w odniesieniu do planu

7.      Przegląd i udokumentowanie rezultatów poszczególnych projektów pilotażowych

Więcej informacji na temat tej podpraktyki zawiera opis praktyki SP 1.2 Pilotaż propozycji udoskonaleń procesu testowego.

SP 2.3       Wybór nowych technologii testowych przeznaczonych do wdrożenia

Wybór nowych technologii testowych przeznaczonych do wdrożenia w organizacji.

Na podstawie ilościowych kryteriów opartych na celach w zakresie wydajności procesu testowego następuje wybór nowych technologii testowych przeznaczonych do wdrożenia

w organizacji.

Przykładowe produkty pracy

1.      Nowe technologie testowe wybrane do wdrożenia (wraz z uzasadnieniem podjętych decyzji)

2.      Dokumentacja wyników procesu wyboru

Podpraktyki

1.      Określenie priorytetów nowych technologii testowych do potencjalnego wdrożenia

Priorytet jest ustalany na podstawie oceny szacowanego zwrotu z inwestycji związanego z realizacją celów w zakresie wydajności procesu testowego.

Więcej informacji na temat celów w zakresie wydajności procesu testowego można znaleźć w opisie obszaru procesowego Kontrola jakości.

Przykładowe kryteria, których można użyć w trakcie określania priorytetów:

•      Udział w realizacji celów w zakresie wydajności testowania

•      Zgodność z modelem dojrzałości (np. w przypadku próby formalnego uzyskania poziomu dojrzałości)

•      Widoczność technologii testowych

•      Koszty technologii testowych

•      Łatwość wdrożenia technologii testowych

•      Oczekiwany poziom akceptacji technologii testowych (niektóre osoby mogą początkowo okazywać stanowczy sprzeciw wobec zmiany)

•      Złagodzenie ryzyka w wyniku wdrożenia technologii testowych

2.      Wybór technologii testowych do wdrożenia

Wyboru nowych technologii testowych dokonuje się z uwzględnieniem ich priorytetów

i dostępnych zasobów.

3.      Określenie podejścia dotyczącego poszczególnych wdrażanych nowych technologii testowych

Przykłady zagadnień uwzględnianych w ramach podejścia do wdrażania:

•      Zasoby procesu testowego w organizacji, których dotyczy zmiana

•      Objęcie zmianą wszystkich projektów w organizacji lub ich podzbioru

•      Objęcie zmianą wszystkich systemów w organizacji lub ich podzbioru

•      Wdrożenie jednorazowe lub przyrostowe; zazwyczaj preferowane jest podejście przyrostowe

•      Zakres wsparcia i konsultacji dla projektów i grup w ramach organizacji

4.      Udokumentowanie wyników procesu wyboru

SG 3       Wdrożenie usprawnień procesu testowego

Usprawnienia i odpowiednie nowe technologie testowe są wdrażane w organizacji w celu udoskonalenia procesu testowego.

Mierzy się uzyskiwane korzyści, a informacje o nowych rozwiązaniach są rozpowszechniane w organizacji.

SP 3.1       Zaplanowanie wdrożenia

Ustanowienie i utrzymywanie planu wdrożenia wybranych usprawnień procesu testowego

i technologii testowych.

Ta praktyka szczegółowa dotyczy planowania wdrożenia poszczególnych usprawnień procesu testowego i technologii testowych. Praktyka ogólna GP 2.2 Zaplanowanie procesu dotyczy kompleksowego planowania i uwzględnia wszystkie praktyki związane z tym obszarem procesowym.

Przykładowe produkty pracy

1.      Plan(-y) wdrożenia

Podpraktyki

1.      Określenie zmian niezbędnych do wdrożenia poszczególnych usprawnień procesu testowego i technologii testowych

Przykładowe obszary zmian niezbędnych do wdrożenia usprawnień procesu testowego

i technologii testowych:

•      Opisy procesów, standardów i procedur testowych

•      Środowiska testowe

•      Szkolenia, warsztaty i rozwój kompetencji

•      Obecny zakres zaangażowania kierownictwa

•      Czynności testowe realizowane obecnie w projektach

2.      Określenie sposobów rozwiązywania potencjalnych problemów związanych

z wdrażaniem poszczególnych usprawnień procesu testowego i technologii testowych

W trakcie definiowania planu należy zadbać o właściwe podejście uwzględniające zarówno potrzebę wprowadzenia zmian, jak i zapewnienia stabilnego działania organizacji. W celu zidentyfikowania potencjalnych problemów można przeprowadzić ocenę ryzyka. Dopuszczalna w poszczególnych projektach częstość wprowadzania zmian w procesie jest zależna od stosowanego modelu cyklu życia (np. sekwencyjnego, iteracyjnego lub zwinnego).

3.      Określenie działań związanych z zarządzaniem zmianami niezbędnych do skutecznego wdrożenia usprawnień procesu testowego

Przykładowe działania związane z zarządzaniem zmianami:

•      Prezentacje dla interesariuszy

•      Spotkanie inicjujące z udziałem wszystkich zainteresowanych stron

•      Sesje dyskusyjne

•      Publikacje, np. informacyjne lub komunikaty o osiągniętych sukcesach

•      Wyróżnienia dla pracowników

4.      Określenie celów i miar umożliwiających ocenę wartości poszczególnych usprawnień procesu testowego i technologii testowych w odniesieniu do celów w zakresie wydajności testowania w organizacji

Przykładowe miary służące do oceny wartości usprawnień procesu testowego i technologii testowych:

•      Zwrot z inwestycji

•      Okres zwrotu

•      Zmierzony poziom wzrostu jakości produktu

•      Zmierzony wzrost wydajności procesu testowego w projekcie

•      Liczba i typ złagodzonych ryzyk projektowych i produktowych

Więcej informacji na temat określania miar oraz procesu pomiaru i analizy zawiera opis obszaru procesowego Pomiar testów.

5.      Udokumentowanie planu wdrożenia poszczególnych usprawnień procesu testowego

i technologii testowych

6.      Przegląd planu wdrożenia poszczególnych usprawnień procesu testowego i technologii testowych oraz uzyskanie zgody odpowiednich interesariuszy

7.      Aktualizacja planu wdrożenia poszczególnych usprawnień procesu testowego

i technologii testowych zgodnie z potrzebami

SP 3.2       Zarządzanie wdrożeniem

Zarządzanie wdrożeniem wybranych usprawnień procesu testowego i technologii testowych.

Przykładowe produkty pracy

1.      (Zaktualizowane) materiały szkoleniowe

2.      Udokumentowane rezultaty działań związanych z wdrożeniem

3.      Zaktualizowane miary dotyczące usprawnień procesu testowego i technologii testowych, cele, priorytety i plany wdrożenia

Podpraktyki

1.      Monitorowanie wdrożenia usprawnień procesu testowego i technologii testowych

z wykorzystaniem planu wdrożenia

2.      Koordynowanie wdrożenia usprawnień procesu testowego i technologii testowych

w ramach organizacji i w poszczególnych projektach

W ramach działań koordynacyjnych tworzony jest zespół ds. wdrożenia, do którego zwykle należy sponsor ze strony kierownictwa.

3.      Uwzględnienie usprawnień procesu testowego i technologii testowych w zasobach procesu testowego w organizacji zgodnie z potrzebami

Więcej informacji na temat zasobów procesu testowego w organizacji można znaleźć

w opisie obszaru procesowego Cykl życia i integracja testów na poziomie TMMi 3.

4.      Przeprowadzenie odpowiednich konsultacji w celu wsparcia wdrożenia usprawnień procesu testowego i technologii testowych

5.      Udostępnienie (zaktualizowanych) materiałów szkoleniowych i przeprowadzenie zaplanowanych szkoleń

Więcej informacji na temat szkoleń i materiałów szkoleniowych można znaleźć w opisie obszaru procesowego Program szkoleń testerskich na poziomie TMMi 3.

6.      Wykonanie działań promocyjnych w zespole testowym i poza zespołem testowym w celu poinformowania o osiągniętych sukcesach oraz utrzymania zaangażowania i motywacji personelu, a także zmniejszenia sprzeciwu wobec zmian

7.      Potwierdzenie zakończenia wdrażania wszystkich usprawnień procesu testowego

i technologii testowych

8.      Monitorowanie zdolności zdefiniowanego procesu testowego do realizacji celów

w zakresie wydajności po wprowadzeniu usprawnień procesu testowego i technologii testowych oraz podejmowanie w razie potrzeby niezbędnych działań naprawczych

9.      Udokumentowanie i przegląd rezultatów wdrożenia usprawnień procesu testowego

i technologii testowych

Udokumentowanie i przegląd rezultatów wdrożenia usprawnień procesu testowego

i technologii testowych obejmuje zwykle następujące działania:

- Zidentyfikowanie i udokumentowanie wniosków wyciągniętych z wdrożenia oraz napotkanych problemów

- Zidentyfikowanie i udokumentowanie nowych propozycji udoskonaleń procesu testowego i technologii testowych

- Aktualizacja miar dotyczących usprawnień procesu testowego i technologii testowych, celów, priorytetów i planów wdrożenia

SP 3.3       Pomiar efektów usprawnień

Pomiar efektów wdrożenia usprawnień procesu testowego i technologii testowych.

Więcej informacji na temat określania miar, procesu pomiaru i analizy oraz raportowania wyników zawiera opis obszaru procesowego Pomiar testów.

Przykładowe produkty pracy

1.      Udokumentowane wyniki pomiarów efektów wdrożenia usprawnień procesu testowego

i technologii testowych

Podpraktyki

1.      Pomiar rzeczywistych kosztów i pracochłonności oraz ustalenie rzeczywistego harmonogramu wdrożenia poszczególnych usprawnień procesu testowego i technologii testowych

2.      Pomiar wartości poszczególnych usprawnień procesu testowego i technologii testowych

3.      Pomiar postępu realizacji celów organizacji w zakresie wydajności procesu testowego

4.      Analiza postępu realizacji celów organizacji w zakresie wydajności procesu testowego

i ewentualne podjęcie odpowiednich działań naprawczych

Więcej informacji na temat analizy wydajności procesu testowego można znaleźć

w opisie obszaru procesowego Kontrola jakości.

5.      Zapisanie wyników pomiarów w repozytorium pomiarów testów w organizacji

SG 4       Stworzenie mechanizmów ponownego wykorzystania zasobów testowych

o wysokiej jakości

Zarówno komponenty procesów testowych, jak i testalia, traktowane są jako zasoby i są ponownie wykorzystywane w organizacji w trakcie tworzenia nowych zasobów testowych.

SP 4.1       Zidentyfikowanie zasobów testowych do ponownego wykorzystania

Identyfikowane są zasoby testowe (komponenty procesów testowych oraz testalia) o wysokiej jakości, które mogą zostać ponownie wykorzystane w ramach organizacji.

Przykładowe produkty pracy

1.       Lista zidentyfikowanych zasobów testowych do ponownego wykorzystania

Podpraktyki

1.      Zidentyfikowanie zasobów testowych poddawanych ocenie pod kątem możliwości ponownego wykorzystania

Przykłady działań, w trakcie których można zidentyfikować zasoby do ponownego wykorzystania:

•      Retrospektywy projektu / sesje podsumowania doświadczeń

•      Raport z ukończenia testów

•      Ocena procesu testowego; zidentyfikowane w jej trakcie obszary należące do silnych stron często świadczą o występowaniu komponentów procesów testowych i/lub testaliów o wysokiej jakości, które potencjalnie można wykorzystać ponownie

•      Prace związane z doskonaleniem procesu testowego

2.      Udokumentowanie kontekstu dla poszczególnych zidentyfikowanych zasobów do ponownego wykorzystania

3.      Zgłoszenie propozycji grupie procesu testowego

SP 4.2       Wybór zasobów testowych dodawanych do biblioteki zasobów do ponownego wykorzystania

Z listy zidentyfikowanych zasobów testowych wybierane są zasoby, które zostaną umieszczone w bibliotece zasobów do ponownego wykorzystania.

Wyboru dokonuje się na podstawie kryteriów ilościowych opartych na polityce ponownego wykorzystania testów w organizacji.

Przykładowe produkty pracy

1.      Zasoby testowe wybrane do ponownego wykorzystania

Podpraktyki

1.      Określenie priorytetów potencjalnych zasobów testowych do ponownego wykorzystania

Priorytet jest określany na podstawie oceny dodatkowych korzyści związanych

z realizacją celów w zakresie wydajności procesu testowego oraz polityki ponownego wykorzystania testów w organizacji.

2.      Analiza potencjalnych zasobów testowych do ponownego wykorzystania

Potencjalne zasoby testowe do ponownego wykorzystania są poddawane analizie pod kątem zgodności z kryteriami ponownego wykorzystania.

Przykłady kryteriów ponownego wykorzystania zasobów testowych:

•      Zasób testowy powinien być zdefiniowany i udokumentowany zgodnie ze standardami organizacji

•      Zasób testowy powinien być zrozumiały i łatwy do wdrożenia

•      Powinny być dostępne miary powiązane z zasobem testowym (dotyczy to zwłaszcza komponentów procesów testowych)

•      Zasób testowy powinien być zasobem poddanym dokładnemu przeglądowi i pomyślnie zastosowanym, aby uzyskać pewność, że został odpowiednio przetestowany

•      Należy przeprowadzić ocenę ryzyka związanego z procesem testowym i ją udokumentować

•      Zasób testowy powinien mieć dobrze zdefiniowany interfejs do innych powiązanych procesów (dotyczy to zwłaszcza komponentów procesów testowych)

•      Zasób testowy powinien być elastyczny i modyfikowalny, tak aby można go było zastosować w różnych projektach

3.      Wybór zasobów testowych do ponownego wykorzystania przeznaczonych do wdrożenia

Wybór zasobów testowych do ponownego wykorzystania odbywa się na podstawie ich priorytetów, dostępności innych zasobów i zgodności z kryteriami ponownego wykorzystania.

4.      Udokumentowanie wyników procesu wyboru i poinformowanie interesariuszy

o podjętych decyzjach

SP 4.3       Wdrożenie zasobów testowych do ponownego wykorzystania

Zarządzanie wdrożeniem i przeprowadzenie wdrożenia wybranych zasobów testowych do ponownego wykorzystania (komponentów procesów testowych lub testaliów).

Przykładowe produkty pracy

1.      Zaktualizowana biblioteka procesu testowego

2.      Zasób testowy do ponownego wykorzystania

3.      Udokumentowane rezultaty działań związanych z wdrożeniem

Podpraktyki

1.       Uwzględnienie wybranych zasobów testowych do ponownego wykorzystania

w bibliotece zasobów procesu testowego w organizacji zgodnie z potrzebami

Aby zasób testowy nadawał się do umieszczenia w bibliotece zasobów procesu testowego, zwykle niezbędne jest wykonanie pewnych prac (patrz lista kryteriów ponownego wykorzystania w poprzedniej praktyce szczegółowej). Każdy zasób spełniający te kryteria powinien być reprezentowany przez pewien szablon ułatwiający jego ponowne wykorzystanie. Szablon powinien zawierać informacje umożliwiające dostosowanie zasobu testowego do potrzeb konkretnego projektu.

Przykładowe elementy szablonu zasobu do ponownego wykorzystania [Hollenbach i Frakes]:

•      Nazwa zasobu testowego

•      Informacje ogólne

•      Opis klienta

•      Opis interfejsu

•      Opis procedury

•      Opis kontekstu

•      Opis pomiaru

Więcej informacji na temat biblioteki zasobów procesu testowego można znaleźć

w opisie obszarów procesowych Organizacja testowa oraz Cykl życia i integracja testów na poziomie 3.

2.      Przegląd i przetestowanie zdefiniowanego zasobu testowego do ponownego wykorzystania w celu potwierdzenia możliwości jego wielokrotnego stosowania

3.      Wdrożenie zasobów testowych do ponownego wykorzystania w ramach organizacji

i w poszczególnych projektach

Przykładowe mechanizmy wdrożenia:

•      Zaprezentowanie na spotkaniu projektowym i/lub wewnętrznym (np. działu)

•      Rozpowszechnienie wiadomości e-mail z informacją lub zamieszczenie informacji

w okresowo rozsyłanym ogólnym biuletynie

•      Uwzględnienie zasobu we wstępnym programie szkoleń dotyczącym biblioteki zasobów procesu testowego

•      Udostępnienie informacji i samego zasobu w centralnym portalu

4.      Przeprowadzenie odpowiednich konsultacji w celu wsparcia wdrożenia nowego lub zaktualizowanego zasobu testowego do ponownego wykorzystania

5.      Udostępnienie (zaktualizowanych) materiałów szkoleniowych i przeprowadzenie odpowiednich szkoleń

6.      Wykonanie działań promocyjnych w zespole testowym i poza tym zespołem w celu poinformowania o sukcesach związanych z procesem ponownego wykorzystania zasobów oraz utrzymania zaangażowania i motywacji personelu

7.      Udokumentowanie i przegląd rezultatów wdrożenia zasobów testowych do ponownego wykorzystania

SP 4.4       Zastosowanie w innych projektach zasobów testowych do ponownego wykorzystania

Zdefiniowane zasoby testowe do ponownego wykorzystania przechowywane w bibliotece zasobów procesu testowego są używane w poszczególnych projektach.

Przykładowe produkty pracy

1.      Informacje o dostosowaniach zasobów testowych do ponownego wykorzystania i ich użyciu w projektach

2.      Wyniki pomiarów użycia zasobów testowych do ponownego wykorzystania

3.      Zmodyfikowane zasoby testowe do ponownego wykorzystania

Podpraktyki

1.      Dostosowanie zasobów testowych do ponownego wykorzystania pod kątem danego projektu

Dostosowanie polega na wyborze i pobraniu odpowiedniego zasobu testowego

(w postaci szablonu) z biblioteki zasobów procesu testowego i użyciu go w nowym projekcie. Może okazać się konieczne wprowadzenie pewnych zmian w celu realizacji wymagań i dopasowania do środowiska w nowym projekcie.

2.      Przeszkolenie uczestników projektu

Ogólny pakiet szkoleniowy związany z zasobem testowym jest dostosowywany do specyficznych potrzeb projektu. Pakiet szkoleniowy zawiera instrukcje dla uczestników projektu.

3.      Zastosowanie zasobu testowego w projekcie

Zasób testowy (po ewentualnym dostosowaniu) jest wdrażany (używany) w projekcie. Zasób jest monitorowany i kontrolowany z wykorzystaniem odpowiednich mechanizmów. Podczas wykonywania procesu testowego prowadzone są pomiary związane z zasobem testowym.

4.      Zmodyfikowanie zasobu testowego do ponownego wykorzystania

Na podstawie wyników pomiarów prowadzonych w trakcie wykonywania procesu ustala się, czy ponowne wykorzystanie zasobu testowego jest skuteczne i efektywne. Jeśli pojawiają się jakieś problemy, są one poddawane analizie, po której w definicji zasobu testowego wprowadzane są odpowiednie zmiany.

Praktyki ogólne dla poszczególnych celów

GG 2       Instytucjonalizacja procesu zarządzanego

GP 2.1       Ustanowienie polityki organizacyjnej

Ustanowienie i utrzymywanie polityki organizacyjnej w celu zaplanowania i realizacji procesu Optymalizacja procesu testowego.

Opracowanie

Polityka optymalizacji procesu testowego zwykle zawiera następujące ustalenia:

•      Doskonalenie procesu testowego odbywa się w sposób ciągły

•      W celu optymalizacji procesu testowego prowadzone są działania związane

z zapobieganiem defektom i kontrolą jakości

•      Definiowane są cele ilościowe związane z usprawnieniami procesu testowego, wydajnością procesu testowego i ponownym wykorzystaniem zasobów testowych

•      Postęp optymalizacji mierzy się w oparciu o zdefiniowane cele ilościowe

•      Określenie celów transferu technologii testowej

•      Usprawnienia procesu testowego są koordynowane przez grupę procesu testowego

•      Określana jest rola formalnych i nieformalnych ocen w ramach doskonalenia procesu testowego

•      Wszyscy testerzy i menedżerowie zatrudnieni w organizacji powinni brać udział

w doskonaleniu procesów testowych

•      Określenie kryteriów ponownego wykorzystania, na podstawie których wyznacza się priorytety zasobów przeznaczonych do wielokrotnego użytku

•      Zgodnie z potrzebami identyfikowane są zasoby do ponownego wykorzystania

•      Zasoby testowe są ponownie wykorzystywane w pracach związanych z projektowaniem procesów testowych oraz w projektach

GP 2.2       Zaplanowanie procesu

Ustanowienie i utrzymywanie planu realizacji procesu Optymalizacja procesu testowego.

Opracowanie

Plan, o którym mowa w tej praktyce ogólnej, tworzy się w celu kompleksowego zaplanowania wszystkich praktyk szczegółowych z tego obszaru procesowego wymaganych do realizacji celów szczegółowych. Plan obejmuje zagadnienia dotyczące gromadzenia i analizowania propozycji udoskonaleń, w tym pomiarów efektów usprawnień, a także ponownego wykorzystania zasobów testowych. Plan podlega przeglądowi koleżeńskiemu i jest weryfikowany przez zainteresowanych menedżerów.

Tworzenie planów wdrożenia jest przedmiotem praktyk szczegółowych z tego obszaru, a nie tej praktyki ogólnej.

GP 2.3       Zapewnienie zasobów

Zapewnienie odpowiednich zasobów w celu realizacji procesu Optymalizacja procesu testowego, wytworzenia produktów pracy oraz realizacji usług związanych z procesem.

Opracowanie

•      Dostępny jest roczny budżet przeznaczony na działania związane z doskonaleniem procesu testowego, w tym na ocenę, wdrożenie, badanie i analizę nowych technologii testowych

•      Utworzone i obsadzone są odpowiednie stanowiska administracyjne i kadrowe w celu określenia, obsługi i prowadzenia działań związanych z komunikacją oraz motywowaniem i wyróżnianiem pracowników; działania te są niezbędne do zachowania wysokiego poziomu zaangażowania i zadowolenia pracowników

•      Dostępne są odpowiednia infrastruktura i narzędzia na potrzeby realizacji działań związanych z optymalizacją procesu testowego, np. narzędzia do prototypowania, pakiety do symulacji, narzędzia do modelowania procesów, pakiety statystyczne

i biblioteka zasobów procesu testowego

•      Dostępne są osoby dysponujące dogłębną wiedzą specjalistyczną w dziedzinie doskonalenia procesu testowego, strategii ponownego wykorzystania i optymalizacji procesów

•      Dostępny jest roczny budżet przeznaczony na działania związane z ponownym wykorzystaniem zasobów testowych

GP 2.4       Przydzielenie odpowiedzialności

Przydzielenie obowiązków i uprawnień w celu realizacji procesu Optymalizacja procesu testowego, wytworzenia produktów pracy oraz realizacji usług związanych z procesem Optymalizacja procesu testowego.

Opracowanie

Za zarządzanie procesem testowym zwykle odpowiada grupa procesu testowego działająca

z pełnym poparciem kierownictwa organizacji. Kierownictwo rozumie znaczenie zmian

i udoskonaleń w procesach, dlatego gotowe jest zainwestować w działanie wykwalifikowanej grupy procesu testowego, która będzie prowadzić i koordynować związane z tym prace. Testerzy i zespoły testowe odpowiadają za stałe dostarczanie informacji zwrotnych

o używanych procesach i technologiach. Doskonalenie i optymalizacja procesu testowego jest obowiązkiem każdego testera.

Przykładowe obowiązki przydzielane członkom grupy procesu testowego:

•      Definiowanie celów organizacyjnych i planów pomiarów wydajności procesu testowego oraz prowadzenie przeglądów celów i planów z udziałem członków kierownictwa wyższego szczebla w celu uzyskania ich poparcia

•      Definiowanie procesów testowych

•      Kontrola jakości procesów testowych

•      Zarządzanie zmianami w procesach testowych, np. definiowanie i utrzymywanie procedur obsługi propozycji udoskonaleń procesu testowego oraz koordynowanie działań związanych z takimi propozycjami

•      Zarządzanie procesem zapobiegania defektom

•      Transfer technologii testowych

•      Ocena procesów testowych

•      Udział w pracach związanych ze zdefiniowaniem potrzeb szkoleniowych organizacji

w zakresie doskonalenia procesu testowego i ponownego wykorzystania zasobów testowych; wsparcie przygotowania i prezentacji materiałów szkoleniowych

•      Identyfikowanie zasobów testowych do wielokrotnego użytku

•      Utrzymywanie biblioteki zasobów procesu testowego

•      Udział w inicjatywach doskonalenia prowadzonych przez inne grupy w ramach organizacji oraz informowanie o takich inicjatywach

GP 2.5       Przeszkolenie ludzi

Przeszkolenie osób realizujących lub wspierających realizację procesu Optymalizacja procesu testowego zgodnie z potrzebami.

Opracowanie

Przykładowe tematy szkoleń:

•      Doskonalenie procesu testowego

•      Planowanie, projektowanie i realizacja projektów pilotażowych

•      Ocena procesu testowego

•      Analiza kosztów i korzyści

•      Proces wyboru i wdrażania narzędzi testowych

•      Analiza i modelowanie procesów

•      Strategie wdrażania

•      Transfer technologii

•      Zarządzanie zmianami

•      Tworzenie zespołu

•      Strategie i procesy ponownego wykorzystania

GP 2.6       Zarządzanie konfiguracją

Objęcie wybranych produktów pracy w procesie Optymalizacja procesu testowego odpowiednimi poziomami kontroli konfiguracji.

Opracowanie

Przykładowe produkty pracy obejmowane zarządzaniem konfiguracją:

•      Propozycje udoskonaleń procesu testowego i ich analizy

•      Udokumentowane wnioski wyciągnięte z projektów pilotażowych

•      Plany doskonalenia testów

•      Plany wdrożenia

•      Materiały szkoleniowe

•      Miary dotyczące usprawnień procesu testowego i technologii testowania

•      Zaktualizowany zestaw standardowych procesów testowych organizacji

•      Komponenty procesów testowych do ponownego wykorzystania

•      Testalia do ponownego wykorzystania

GP 2.7       Zidentyfikowanie i zaangażowanie właściwych interesariuszy

Zidentyfikowanie i zaangażowanie właściwych interesariuszy procesu Optymalizacja procesu testowego zgodnie z planem.

Opracowanie

Przykłady udziału interesariuszy:

•      Współpraca z kierownictwem wyższego szczebla w celu uzyskania zobowiązań dotyczących działania grupy procesu testowego; określanie celów długoterminowych

i udostępnianie zasobów na potrzeby doskonalenia procesu testowego, transferu technologii testowych i ponownego wykorzystania zasobów testowych

•      Przegląd propozycji udoskonaleń procesu testowego i technologii testowych z udziałem kierownictwa wyższego szczebla, użytkowników o konkretnych rolach i osób reprezentujących perspektywę techniczną

•      Przekazywanie informacji zwrotnych o statusie i rezultatach działań wdrożeniowych, m.in. związanych z transferem technologii testowych, kierownictwu wyższego szczebla i interesariuszom zajmującym się kwestiami eksploatacyjnymi

•      Rozpowszechnianie informacji o nowych technologiach testowych

GP 2.8       Monitorowanie i kontrola procesu

Monitorowanie i kontrola realizacji procesu Optymalizacja procesu testowego (porównywanie z planem jego realizacji) oraz podejmowanie odpowiednich działań.

Opracowanie

Przykłady miar używanych do monitorowania i kontroli procesu Optymalizacja procesu testowego:

•      Liczba ocenionych, wybranych i wdrożonych usprawnień procesu testowego

•      Liczba zidentyfikowanych, ocenionych i wdrożonych innowacji technologicznych

•      Rzeczywista pracochłonność i wykorzystanie innych zasobów, np. w trakcie opracowywania planów wdrożenia

•      Zmiana jakości produktów

•      Zmiana wydajności procesu testowego

GP 2.9            Obiektywna ocena przestrzegania zasad

Obiektywna ocena zgodności procesu Optymalizacja procesu testowego oraz wybranych produktów pracy z opisem procesu, standardami i procedurami, a także eliminowanie ewentualnych obszarów niezgodności.

Opracowanie

Przykładowe zagadnienia związane z oceną przestrzegania zasad poruszane w ramach przeglądu i/lub audytu:

•      Proces identyfikowania możliwości udoskonaleń procesu testowego

•      Planowanie i koordynowanie działań związanych z doskonaleniem testów

•      Proces wyboru, zakupu i wdrażania nowych technologii testowych

•      Plany doskonalenia testów

•      Ocena procesu testowego

•      Plany wdrożenia

•      Proces transferu technologii testowych

•      Wyniki pomiaru efektów wdrożenia usprawnień procesu testowego

•      Wyniki pomiarów dotyczących ponownego wykorzystania zasobów testowych

GP 2.10       Przegląd statusu z kierownictwem wyższego szczebla

Przegląd działań, statusu i rezultatów procesu Optymalizacja procesu testowego z udziałem kierownictwa wyższego szczebla oraz rozwiązywanie problemów.

Opracowanie

Przykładowe zagadnienia, które należy omówić z kierownictwem wyższego szczebla:

•      Status usprawnień opracowywanych przez zespoły zadaniowe

•      Rezultaty projektów pilotażowych i wdrożeń

•      Wyniki pomiarów wydajności procesu testowego

•      Rzeczywista pracochłonność i wykorzystanie innych zasobów w porównaniu z planem

•      Status realizacji głównych kamieni milowych, np. gotowości do formalnej oceny

•      Niezbędne zmiany strategii

•      Program transferu technologii testowych

•      Program ponownego wykorzystania zasobów testowych

GG 3       Instytucjonalizacja procesu zdefiniowanego

GP 3.1       Ustanowienie procesu zdefiniowanego

Ustanowienie i utrzymywanie opisu zdefiniowanego procesu Optymalizacja procesu testowego.

GP 3.2       Zbieranie informacji o usprawnieniach

Gromadzenie informacji związanych z procesem, wynikających z planowania i realizacji procesu Optymalizacja procesu testowego, w celu wsparcia wykorzystania procesów organizacji i zasobów procesów w przyszłości oraz ich udoskonalenia.

Opracowanie

Przykładowe miary:

•      Ogólna dynamika wprowadzania zmian w technologiach testowych, w tym liczba, typ

i wielkość zmian

•      Efekt wdrożenia zmiany technologii testowej w porównaniu z określonymi celami

•      Pracochłonność/koszty modyfikacji procesu testowego (zmian w procesie testowym)

•      Koszty doskonalenia i optymalizacji procesu testowego

•      Koszty utrzymywania biblioteki zasobów procesu testowego

•      Liczba zasobów testowych do ponownego wykorzystania

•      Koszty/pracochłonność związana z ponownym wykorzystaniem zasobu testowego

•      Koszty/pracochłonność utrzymywania grupy procesu testowego

Dodatek A Oceny i certyfikacja TMMi

A.1       Przegląd ocen

Wiele organizacji docenia znaczenie oceny przebiegu doskonalenia procesu testowego i/lub porównywania go z wzorcowymi parametrami, zarówno na wewnętrzne potrzeby, jak i dla dostawców i klientów zewnętrznych. Każda ocena procesu testowego koncentruje się na zidentyfikowaniu możliwości wprowadzenia usprawnień i określeniu stanu wdrożenia wybranego modelu lub standardu w danej organizacji. TMMi to bardzo dobry model odniesienia, z którego warto skorzystać podczas dokonywania takiej oceny. Zespoły oceniające badają zgodność działań jednostek organizacyjnych z wymaganiami modelu TMMi i na tej podstawie formułują wnioski i określają ich priorytety. Takie wnioski wraz z zaleceniami zdefiniowanymi przez praktyki TMMi mogą (i powinny) być wykorzystywane do planowania usprawnień w organizacji. Struktura oceny, czyli m.in. sposób oceny poszczególnych elementów w oparciu o model TMMi, nie jest zdefiniowana w ramach samego dokumentu modelu. Jednak aby model mógł skutecznie spełnić swoją funkcję, powinien być używany wraz z ogólną strukturą oceny, która z kolei powinna być częścią ogólnego procesu doskonalenia (patrz Dodatek B).

A.2       Struktura oceny

Model TMMi zawiera definicję różnych poziomów zdolności procesów testowych organizacji i procesów zarządzania jakością związanych z testowaniem, traktowanych jako część ogólnego systemu i procesu wytwarzania oprogramowania. Model jest opracowywany na podstawie różnych publikacji oraz informacji przekazanych przez szerokie grono specjalistów z całego świata. Zawiera najlepsze praktyki, zarówno nowe, jak i stosowane już od pewnego czasu. Ma być na tyle ogólny, by mógł zostać zastosowany do różnych modeli dostarczania, a jednocześnie na tyle szczegółowy, by zidentyfikować wszystkie potencjalne praktyki związane z testowaniem. Należy jednak pamiętać, że TMMi to „tylko” model odniesienia i jeśli zostanie użyty w środowisku o niskiej jakości, efekty jego zastosowania będą ograniczone. Ponadto nie określa gotowego rozwiązania; wybór optymalnego rozwiązania zależy od kontekstu działania organizacji oraz ustalenia, które elementy nadają się do realizacji celów i jednocześnie spełniają wymagania modelu. To kluczowy czynnik wpływający na interpretację modelu podczas dokonywania oceny.

Jeśli zachodzi potrzeba oceny zgodności z modelem TMMi, konieczne jest opracowanie lub zakup i wdrożenie struktury oceny (obejmującej m.in. sprawdzoną metodę, wykwalifikowanych specjalistów i narzędzia), która w skuteczny i efektywny sposób uwzględni model i przeanalizuje możliwości procesu organizacji. Dobry mechanizm oceny jest w stanie dostarczyć wartościowe wyniki w sposób spójny, powtarzalny i umożliwiający porównanie. Wyniki powinny być zrozumiałe i łatwe do wykorzystania. Podstawowym założeniem jest zdolność do przeprowadzenia oceny możliwości danej organizacji dzięki właściwej interpretacji wymagań modelu, z uwzględnieniem kontekstu działania tej organizacji (wielkości, branży, stosowanej metodyki wytwarzania oprogramowania itp.), a także do zinterpretowania uzyskanych wyników pod kątem przydatności do realizacji celów.

Ocena może mieć charakter formalny (zakończony przyznaniem certyfikatu) lub nieformalny (wyłącznie informacyjny). W punkcie Typy oceny przedstawiono bardziej szczegółowy opis różnych typów ocen. Proces oceny obejmuje trzy elementy, z których można skorzystać (w zależności od typu oceny):

1.      Model wzorcowy (np. TMMi), używany w trakcie każdej oceny do analizy procesów organizacji, procedur, działań i produktów, w tym organizacyjnych poziomów instytucjonalizacji, zarządzania, przestrzegania zasad i zapewnienia jakości

2.      Metoda oceny z określonym przepływem procesu, szczegółowymi procedurami, narzędziami i innymi elementami, zapewniająca spójność i mechanizmy kontroli

w trakcie oceny

3.      Przeszkolone, kompetentne osoby występujące w rolach oceniającego i głównego oceniającego, które dysponują kwalifikacjami niezbędnymi do zarządzania wszystkimi aspektami oceny zgodnie ze zdefiniowaną metodą

Pierwszym elementem jest w tym wypadku standardowy model wzorcowy TMMi.

W kolejnych rozdziałach przedstawiono informacje na temat sposobów uzyskania dostępu do akredytowanej metody oceny i wykształcenia akredytowanych oceniających zgodnie

z zaleceniami TMMi Foundation. Więcej informacji na temat metod oceny i akredytacji osób oceniających można znaleźć w serwisie internetowym TMMi Foundation.

A.3       Metoda oceny zgodna z wymaganiami TAMAR

Wymagania TAMAR (TMMi Assessment Method Accreditation Requirements) dotyczące ocen zgodności z modelem TMMi zostały opisane przez TMMi Foundation

w odrębnym dokumencie [TAMAR]. Wymagania te zostały oparte na standardzie ISO 15504 (dokument TAMAR zawiera kompletną tabelę definiującą korelacje z tym standardem). Uzyskanie konkretnego poziomu dojrzałości musi być rozumiane w ten sam sposób

w przypadku wszystkich ocenianych organizacji. Zasady umożliwiające zastosowanie spójnych mechanizmów oceny zostały przedstawione w dokumencie TAMAR. Dokument TAMAR zawiera również wskazówki dotyczące różnych rodzajów ocen.

Dzięki realizacji wymagań przedstawionych w dokumencie TAMAR metoda oceny może być:

•       wykonalna – ocena może zostać przeprowadzona w sposób odpowiadający przyjętym celom i zgodny z wymaganiami TMMi Foundation

•      powtarzalna – w ramach oceny są stosowane spójne wskaźniki porównawcze i jeśli ocena zostanie przeprowadzona przez inny zespół z wykorzystaniem tych samych danych, to przyniesie identyczne rezultaty i zostaną zidentyfikowane takie same mocne i słabe strony.

A.3.1       Typy oceny

Dokument TAMAR określa wymagania dla dwóch typów oceny, tj. nieformalnej

i formalnej.

Oceny nieformalne

Ocena nieformalna ma charakter informacyjny i wiąże się z nią mniejsza liczba wymagań dotyczących zgodności. Oznacza to, że na ogół jest bardziej elastyczna i mniej kosztowna do przeprowadzenia. Ponieważ nie ma potrzeby dostarczenia potwierdzających dowodów, czas niezbędny na wykonanie oceny jest znacznie krótszy. Dodatkowo zakres oceny nieformalnej można ograniczyć do konkretnej jednostki organizacyjnej. Oceny nieformalne służą jedynie do oszacowania poziomu dojrzałości organizacji i nie wiążą się

z formalnym uzyskaniem wskaźnika dojrzałości lub certyfikatu. Ocena nieformalna często jest wykonywana w celu zidentyfikowania najważniejszych usprawnień, które należy wprowadzić. Można z niej skorzystać również w celu określenia postępu wdrożenia modelu TMMi. Przeprowadzenie oceny nieformalnej w wielu sytuacjach jest dobrym sposobem wykonania wstępnej analizy, jednak można do tego zastosować także ocenę formalną.

Oceny formalne

Proces oceny formalnej musi być zgodny ze wszystkimi wymaganiami TAMAR

i odbywać się pod kierownictwem wykwalifikowanej osoby występującej w roli głównego oceniającego. Istnieją dwa obowiązkowe źródła danych: wywiady i artefakty (dowody w formie dokumentów). Dane pochodzące z wywiadów muszą zostać potwierdzone przez odpowiednie artefakty. Artefaktami mogą być dokumenty, szablony, zrzuty ekranów lub podobne elementy. Ocena formalna przeprowadzona z wykorzystaniem akredytowanej metody może zakończyć się formalnym uzyskaniem wskaźnika dojrzałości lub certyfikatu.

A.3.2       Zakres wymagań TAMAR

Wymagania TAMAR określają pewną liczbę zadań do wykonania w ramach kilku faz oceny. Definicja metody oceny musi spełniać te wymagania.

Planowanie i przygotowanie

W fazie planowania i przygotowania realizowane są wszystkie działania, które powinny zostać wykonane przed przeprowadzeniem właściwej oceny. Są to między innymi:

•      Uzgodnienie celów oceny

•      Uzgodnienie planu działań i dostarczanych produktów

•      Zorganizowanie wywiadów

•      Przygotowanie zespołu oceniającego i narzędzi

Gromadzenie danych

W fazie gromadzenia danych zespół oceniający prowadzi wywiady oraz zbiera informacje uzupełniające treść wywiadów w postaci artefaktów, kwestionariuszy lub ankiet. Wszystkie dane są gromadzone, rejestrowane i przechowywane zgodnie z wymaganiami dotyczącymi poufności i bezpieczeństwa.

Analiza danych i raportowanie

W fazie analizy danych i raportowania zgromadzone informacje są poddawane analizie,

a wyniki zapisywane w postaci raportów.

Analiza obejmuje następujące działania:

•      Zidentyfikowane mocnych stron procesu

•      Zidentyfikowane słabych stron procesu

•      Wykonanie czynności związanych z oceną wskaźników i określenie wskaźnika dojrzałości TMMi

•      Opracowanie planu doskonalenia procesu, jeśli jest to jednym z celów oceny

•      Raportowanie wyników oceny interesariuszom zgodnie z planem i wyznaczonymi celami

Zamknięcie oceny

Faza zamknięcia następuje po zakończeniu oceny. Najważniejsze działania to:

•      Zarchiwizowanie wszystkich danych związanych z oceną zgodnie z wymaganiami dotyczącymi poufności i bezpieczeństwa

•      Wypełnienie raportu przekazania danych (ang. DSR – Data Submission Report; patrz poniżej)

A.3.3       Raport przekazania danych (DSR)

Jednym z wymagań jest konieczność udokumentowania wyników wszystkich ocen (formalnych i nieformalnych) i przekazania ich TMMi Foundation. W tym celu należy wypełnić i przesłać raport DSR dla każdej oceny prowadzonej z wykorzystaniem akredytowanej metody. TMMi Foundation nadzoruje proces oceny, dążąc do tego, by wszystkie oceny zgodności

z modelem TMMi wykorzystujące akredytowane metody były prowadzone z zachowaniem należytej staranności. TMMi Foundation zastrzega sobie prawo do audytu dowolnej oceny

w jej trakcie lub po jej zakończeniu w celu zweryfikowania przestrzegania zasad przyjętych

w metodzie. Kluczowym elementem tego procesu jest raport DSR. Wymagania dotyczące raportu DSR można znaleźć w serwisie internetowym TMMi Foundation. Z raportem DSR wiążą się konkretne wymagania dotyczące przesyłania wyników oceny i informacji

o działaniach osób oceniających.

Dane związane z oceną

TMMi Foundation używa danych związanych z oceną do analizy trendów na rynku i poziomu dojrzałości w danej branży. Oczyszczone dane (dane pozbawione informacji wrażliwych) są przesyłane do TMMi Foundation, która wykonuje następujące działania:

•      Wstępne określenie spójności i kompletności ocen

•      Badania rynku (z wykorzystaniem oczyszczonych danych)

•      Weryfikacja wskaźników uzyskanych w ocenach formalnych i wystawienie odpowiednich certyfikatów

Dane dotyczące osób oceniających

Kryteria raportowania przez osoby oceniające zostały określone w wymaganiach dotyczących raportu DSR. Każda osoba oceniająca jest odpowiedzialna za utrzymywanie swoich indywidualnych zapisów działań, które muszą zostać przesłane do TMMi Foundation. Jest to konieczne do wykazania, że osoby oceniające nie tylko odznaczają się odpowiednimi umiejętnościami i doświadczeniem oraz odbyły szkolenia wymagane do akredytacji, ale również stosują te umiejętności w praktyce.

A.3.4       Dostęp do akredytowanych metod zgodnych z TAMAR

Standardowy model wzorcowy TMMi jest ogólnie dostępny, zatem każda organizacja może go użyć jako podstawy do doskonalenia, oceny i modyfikowania procesów. Konsultanci ds. testów, którzy nie są akredytowani przez TMMi Foundation, mogą przeprowadzić ocenę korzystając z nieakredytowanych metod oceny, a oceniana organizacja może opublikować jej wyniki, jednak ich interpretacja nie będzie jednoznaczna, ponieważ proces oceny i wybrana metoda nie podlegają nadzorowi. Nie ma w związku z tym gwarancji, że model został zastosowany w spójny sposób z wykorzystaniem zweryfikowanego, sprawdzonego procesu, a uzyskane wyniki są wiarygodne. TMMi Foundation udostępnia mechanizm weryfikacji metod oceny. Po akredytacji metody odbywa się niezależna weryfikacja zgodności metody

z poprawnym procesem opartym na opublikowanych standardach, a także jej wykonalności, powtarzalności i możliwości skontrolowania. Ponadto należy pamiętać, że dzięki skorzystaniu przez organizację z akredytowanej metody zwiększa się wiarygodność i możliwość zweryfikowana oceny. Dodatkowo organizacja może pochwalić się potwierdzeniem poziomu dojrzałości w ramach niezależnego, sprawdzonego procesu.

Istnieją trzy metody uzyskania dostępu do akredytowanej metody i uzyskania statusu akredytowanego dostawcy usług oceny procesu. Organizacja może skorzystać z metody oceny oferowanej przez TMMi Foundation lub opracować własną metodę lub skorzystać

z metody opracowanej przez stronę trzecią. Listy akredytowanych metod i akredytowanych dostawców usług oceny można znaleźć w serwisie internetowym TMMi Foundation. Niezależna Komisja ds. akredytacji działająca w ramach TMMi Foundation zarządza akredytacjami metod oceny. Akredytacja metody jest ważna przez trzy lata, a po upływie tego okresu metodę należy poddać ponownej akredytacji.

Metoda oceny opracowana przez TMMi Foundation (TAM)

TMMi Foundation opracowała i udostępniła własną metodę oceny. Metoda ta została zweryfikowana i uznana za zgodną z wymaganiami TAMAR. Jej utrzymywaniem zajmuje się TMMi Foundation. Organizacje mogą skorzystać z tej metody na warunkach licencji. Wiążą się z tym następujące korzyści:

•      Uzyskanie dostępu do akredytowanej metody oceny wymaga minimalnych nakładów.

•      Nie występują koszty badań, rozwoju i utrzymania ani koszty prac realizowanych przez dostawcę usług. Zadania te wykonuje TMMi Foundation.

•      Za pośrednictwem TMMi Foundation dostępne są zatwierdzone szkolenia dla osób oceniających (w tym głównych oceniających).

Metody oceny oferowane przez zewnętrznych dostawców

Dostawcy usług oceny mogą opracować własne pakiety metod i zgłaszać je do TMMi Foundation w celu uzyskania certyfikatu zgodności z wymaganiami TAMAR. Oczywiście korzystny jest fakt, że takie metody oceny są definiowane i kontrolowane przez dostawców oraz pozostają ich własnością. Potencjalnym problemem mogą być koszty i pracochłonność związane z opracowaniem, akredytacją i utrzymaniem pakietu metod. Może się to okazać poważną wadą takiego rozwiązania. Z kolei dodatkową zaletą jest możliwość dopasowania metody do konkretnych potrzeb organizacji, a także jej połączenia z innymi praktykami

(np. oceną zgodności z wymaganiami CMMI lub ISO 9000).

Metody oceny stron trzecich

Niektórzy dostawcy oceny udostępniają swoje akredytowane pakiety metod oceny i szkolenia osobom i organizacjom w celu licencjonowania w taki sam sposób, w jaki TMMi Foundation udostępnia TAM. Korzyści z tego są takie same jak w przypadku TAM.

A.4       Akredytacja osób oceniających (w tym głównych oceniających)

W poprzednim rozdziale przedstawiono wymagania dotyczące metody oceny. Podano również wskazówki dotyczące opracowania akredytowanej metody oceny zgodności

z modelem TMMi lub uzyskania odpowiedniej licencji. Trzeci rodzaj wymagań wiąże się

z koniecznością odpowiedniego przeszkolenia osób zajmujących się oceną zgodności

i uzyskania przez nie odpowiednich umiejętności, które umożliwią przeprowadzenie oceny

w spójny sposób, z zachowaniem wysokiego poziomu biegłości.

A.4.1       Kryteria akredytacji osób oceniających

TMMi Foundation zarządza mechanizmami oceny i akredytacji osób oceniających

(w tym głównych oceniających). Jeśli dostawca usług oceny zamierza prowadzić formalne oceny zakończone przyznaniem certyfikatu, muszą być one prowadzone przez akredytowanych głównych oceniających, a w zespole oceniającym powinna uczestniczyć co najmniej jedna akredytowana osoba oceniająca. Należy zaznaczyć, że akredytacja osób oceniających (w tym głównych oceniających) odbywa się w odniesieniu do konkretnej akredytowanej metody oceny (opracowanej przez TMMi Foundation lub należącej do zewnętrznego dostawcy). Wymagania dotyczące akredytacji osób występujących w obu rolach i formularze zgłoszeniowe można znaleźć w serwisie internetowym TMMi Foundation.

W poniższej tabeli przedstawiono podsumowanie wymagań.

Kryteria akredytacji osób oceniających

Specjalizacja

Główny oceniający (oceny formalne)

Oceniający (oceny nieformalne)

Testowanie

Wymagany certyfikat ISTQB® Poziom Zaawansowany – Kierownik Testów lub równoważny.

Wymagany certyfikat ISTQB® Foundation lub równoważny.

TMMi

Certyfikat TMMi Professional

Certyfikat TMMi Professional

Oceny

Należy ukończyć co najmniej 75 godzin uczestnictwa w co najmniej jednej (formalnej lub nieformalnej) ocenie TMMi.

Uznane szkolenie TMMi Assessor pomyślnie ukończone.

Tabela A.1: Kryteria akredytacji osób oceniających

Wszystkie wnioski są weryfikowane przez niezależną Komisję ds. akredytacji działającą w ramach TMMi Foundation. Jeśli dana osoba spełnia wymagania, zostanie akredytowana jako specjalista o odpowiednim doświadczeniu, wiedzy i wykształceniu wystarczającym do prowadzenia ocen zgodności z modelem TMMi z wykorzystaniem konkretnej akredytowanej metody. Komisja ds. akredytacji weźmie pod uwagę równoważne doświadczenie i/lub kwalifikacje. Akredytacja osoby oceniającej jest ważna przez trzy lata

i podlega odnowieniu pod warunkiem wykazania przez daną osobę, że nadal ma ona odpowiednie umiejętności i doświadczenie (np. poinformowania o wykonaniu odpowiedniej liczby działań lub poświęceniu odpowiedniego czasu na oceny). Lista wszystkich akredytowanych osób oceniających (w tym głównych oceniających) znajduje się w serwisie internetowym TMMi Foundation.

A.4.2       Szkolenie TMMi Professional

TMMi Foundation nie prowadzi szkoleń dotyczących struktury, zawartości i interpretacji modelu TMMi. Organizacja opublikowała jednak dokument zawierający cele nauczania, zatytułowany „TMMi Professional – TMMi model training”. Cele te muszą zostać uwzględnione w ramach każdego uznanego szkolenia TMMi Professional. Ponadto organizacja publikuje listę uznanych dostawców szkoleń dotyczących modelu TMMi; będzie również organizować niezależne egzaminy i przyznawać certyfikaty osobom, które zdadzą egzamin.

TMMi Foundation prowadzi zatwierdzone szkolenia dla osób oceniających (w tym głównych oceniających) stosujących metodę oceny należącą do tej organizacji. Jeśli dostawca usług oceny korzysta z własnej akredytowanej metody, musi wykazać, że przeprowadzono odpowiednie szkolenia spełniające wymagania Komisji ds. akredytacji działającej w ramach TMMi Foundation.

Więcej informacji na temat schematu certyfikacji TMMi Professional, uznanych dostawców szkoleń i dostawców egzaminów, sylabusa i przykładowych egzaminów można znaleźć na www.tmmi.org.

A.4.3       TMMi Assessor Training

Podobnie jak w przypadku szkoleń z modelu TMMi, Fundacja TMMi nie prowadzi szkoleń z zakresu oceny TMMi i samego TAMAR. Opublikowała jednak cele nauczania pod tytułem „Szkolenie asesorów TMMi", które muszą być objęte każdym uznanym szkoleniem TMMi Assessor. Ocena uczestników szkolenia TMMi Assessor musi być przeprowadzona za pomocą procesu oceniania wyników, w którym zadania kursu (szkolenia), ćwiczenia praktyczne lub testy są oceniane przez nauczyciela (tutor) na podstawie ich rozległych praktycznych doświadczeń (w zakresie oceny), wiedzy i umiejętności. Lista uznanych organizatorów kursów TMMi Assessor, w tym metoda oceny TMMi, której nauczają, jest dostępna na stronie internetowej TMMi

Aby zostać asesorem TMMi przy wykorzystaniu metody oceny TMMi (TAM) można ukończyć specjalistyczne szkolenie, które jest dostępne za pośrednictwem firmy TAM będącej partnerem outsourcingowym Fundacji TMMi.

Więcej informacji na temat programu szkoleniowego TMMi Assessors, uznanych dostawców szkoleń i sylabusa można znaleźć na www.tmmi.org.

.

Dodatek B Proces doskonalenia[3]

B.1       Wprowadzenie

Model TMMi stanowi przede wszystkim listę sprawdzonych praktyk i opis dojrzałego procesu testowego. Model nie oferuje standardowego podejścia do programu wprowadzania zmian

w organizacji. Na potrzeby wsparcia wdrożenia modeli takich jak CMMI ośrodek Software Engineering Institute (SEI) opracował model procesu wprowadzania zmian o nazwie IDEAL [IDEAL]. Okazał się on bardzo skutecznym podejściem ułatwiającym wdrożenie modelu TMMi. Model IDEAL stanowi rozbudowany, praktyczny standard odniesienia dotyczący procesów zmiany. Określa również działania niezbędne w przypadku wdrażania usprawnień związanych z modelem TMMi w organizacji. W modelu zdefiniowany jest cykl doskonalenia składający się z pięciu faz przedstawionych w poniższej tabeli.

Skrót

Faza

Cel

I

Inicjowanie

Określenie wstępnej infrastruktury umożliwiającej skuteczną realizację procesu doskonalenia.

D

Diagnozowanie

Określanie aktualnego stanu organizacji

w stosunku do stanu pożądanego.

E

Ustanawianie

Planowanie i określanie sposobów realizacji celów.

A

Działanie

Realizacja planu.

L

Uczenie się

Zdobywanie wiedzy na podstawie doświadczeń

i doskonalenie możliwości wdrażania zmian.

Tabela B.1: Model IDEAL – cykl doskonalenia składający się z pięciu faz

Organizacje mogą wybrać dowolne podejście usprawniające przy wdrażaniu modelu TMMi. Oprócz modelu IDEAL istnieją inne modele wdrażania mechanizmów doskonalenia procesów. Ogólnie rzecz biorąc, takie modele oparte są na zdefiniowanym przez Edwarda Deminga cyklu „zaplanuj – wykonaj – sprawdź – zastosuj” (plan – do – check – act). Cykl Deminga rozpoczyna się od opracowania planu określającego cele doskonalenia i sposoby ich osiągnięcia („zaplanuj”). Usprawnienia są następnie wdrażane („wykonaj”). Kolejnym etapem jest ustalenie, czy zostały osiągnięte planowane korzyści („sprawdź”). Na podstawie wyników takiej oceny podejmowane są dalsze działania zgodnie z potrzebami („zastosuj”).

W niniejszym dodatku przedstawiono omówienie poszczególnych faz i czynności wykonywanych w ramach procesu doskonalenia IDEAL.

B.2       Program zmian

Fazy programu doskonalenia zgodnego z modelem IDEAL przedstawiono na rysunku B.1.

Działanie

Ustanawianie

Diagnozowanie

Inicjowanie

Uczenie się

Bodziec do wprowadzenia zmiany

Propozycja działań w przyszłości

Analiza i ocena

Pełne wdrożenie rozwiązania

Ulepszenie rozwiązania

Wdrożenie pilotażowe/testowe rozwiązania

Tworzenie rozwiązania

Planowanie działań

Opracowanie podejścia

Ustalenie priorytetów

Opracowanie rekomendacji

Określenie kontekstu

Zdobycie sponsorów

Nakreślenie infrastruktury

Scharakteryzowanie stanów bieżącego i pożądanego

Rysunek В.1: Fazy programu doskonalenia zgodnie z modelem IDEAL [IDEAL]

Poniżej przedstawiono krótkie omówienie poszczególnych faz i działań.

B.2.1       I – Initiating: faza inicjowania

W fazie inicjowania ustanawiana jest infrastruktura umożliwiająca skuteczną realizację programu zmian. Definiuje się cele i oczekiwane wyniki związane ze zmianą oraz niezbędny wkład różnych stron, których zmiana dotyczy. Cele wdrożenia TMMi muszą być zgodne

z celami jakościowymi i celami organizacyjnymi. W tej fazie cele nie zawsze można sformułować zgodnie z metodą SMART (Specific, Measureable, Achievable, Realistic, Timebased – konkretne, mierzalne, osiągalne, realistyczne, terminowe), w związku z czym określa się je bardziej szczegółowo dopiero w fazie ustanawiania. Należy w tej fazie zwrócić szczególną uwagę na zaangażowanie kierownictwa. Jest ono wymagane w odniesieniu do kierownictwa zespołu testowego, osób odpowiedzialnych za infrastrukturę teleinformatyczną

i osób odpowiedzialnych za zarządzanie biznesowe. Faza inicjowania obejmuje następujące działania:

•      Zidentyfikowanie bodźca do wprowadzenia zmiany

•      Określenie kontekstu

•      Zdobycie sponsorów

•      Nakreślenie infrastruktury

Zidentyfikowanie bodźca do wprowadzenia zmiany

Przed rozpoczęciem właściwego projektu wprowadzenia zmiany organizacja musi ustalić, że wprowadzenie zmiany jest konieczne. Bodźcami do wprowadzenia zmiany mogą być na przykład niezadowolenie z wyników aktualnego procesu testowego, zmiana okoliczności zewnętrznych, inicjatywa kierownictwa wyższego szczebla, rezultat testu porównawczego, ocena zgodności z modelem TMMi, potrzeba zgłoszona przez klienta, trendy rynkowe oraz informacja pochodząca z wewnętrznego repozytorium pomiarów. Proponowana zmiana musi mieć wpływ na sukces całej organizacji oraz uzupełniać istniejące cele jakościowe i organizacyjne. Zakres zgodności zmiany z celami organizacyjnymi w dużej mierze decyduje o skuteczności wprowadzenia zmiany.

Określenie kontekstu

Kierownictwo musi określić miejsce prac związanych z wprowadzeniem zmiany

w strategii biznesowej i strategii zapewnienia jakości. Które cele organizacyjne zostaną zrealizowane lub wsparte dzięki wdrożeniu modelu TMMi? Jaki będzie wpływ usprawnienia na bieżące projekty? Jakie rezultaty powinny zostać uzyskane, np. jeśli chodzi o zmniejszenie liczby problemów i incydentów lub skrócenie czasu wykonywania testów? W trakcie projektu kontekst i potencjalne efekty zostaną określone w bardziej precyzyjny sposób, jednak istotne jest podanie możliwie najbardziej konkretnych ustaleń już na wczesnych etapach projektu.

Zdobycie sponsorów

Uzyskanie wsparcia od odpowiedzialnych menedżerów, czyli zdobycie sponsorów, jest wyjątkowo ważnym elementem projektów doskonalenia. Dotyczy to kierownictwa działu testów, kierownictwa działu informatyki i osób odpowiedzialnych za zarządzanie biznesowe, ponieważ zmiana ma wpływ na działania podejmowane właśnie przez tych interesariuszy. Wsparcie sponsorskie ma znaczenie przez cały czas realizacji projektu, jednak ze względu na niepewność związaną z wprowadzeniem zmian aktywne wsparcie jest istotne zwłaszcza na początku projektu. Ważnym elementem wsparcia sponsorskiego jest wspieranie programu doskonalenia, ale obejmuje ono również aktywny udział w projekcie i promowanie jego realizacji w obszarach, w których występuje sprzeciw wobec zmian.

Nakreślenie infrastruktury

Ostatnim elementem fazy inicjowania jest określenie sposobu realizacji projektu wprowadzenia zmiany. W tym celu tworzona jest odpowiednia infrastruktura. Musi zostać przedstawiony jej konkretny opis, ze wskazaniem zakresu odpowiedzialności i kwalifikacji.

Zwykle częścią tej infrastruktury jest zarząd projektu, który kieruje pracami kilku zespołów ds. doskonalenia. W skład zarządu projektu wchodzi jego sponsor, sponsorzy innych projektów doskonalenia (jeśli zachodzi taka potrzeba), kierownik programu doskonalenia oraz ewentualnie zewnętrzny konsultant. Oprócz nich w składzie zarządu znajduje się często miejsce dla (zewnętrznego) eksperta w dziedzinie modelu TMMi. Zarząd projektu ponosi ostateczną odpowiedzialność za realizację programu doskonalenia. Odpowiada za akceptację planów, kamieni milowych i końcowych rezultatów projektu. Zarząd projektu ma kompetencje do podejmowania ostatecznych decyzji i stanowi najwyższy poziom eskalacji.

B.2.2       D – Diagnosing: faza diagnozowania

W fazie diagnozowania następuje określenie aktualnego stanu organizacji w stosunku do stanu pożądanego. W tym celu przeprowadza się oceny, podczas których wyniki pomiarów porównywane są ze standardami wzorcowymi, np. poziomem TMMi 2. W jednoznaczny sposób zostaje opisany aktualny stan organizacji oraz pożądany stan przyszły. Faza diagnozowania obejmuje następujące działania:

•      Scharakteryzowanie stanów bieżącego i pożądanego

•      Opracowanie rekomendacji

Scharakteryzowanie stanów bieżącego i pożądanego

Do zdefiniowania stanu pożądanego może posłużyć model TMMi. W celu określenia stanu bieżącego przeprowadza się ocenę formalną lub nieformalną (rozdział 4). W trakcie oceny podczas ustalania poziomów dojrzałości procesów testowych można skorzystać z listy celów i praktyk w charakterze listy kontrolnej. Stan pożądany musi być zgodny z bodźcem do wprowadzenia zmiany określonym w fazie inicjowania oraz możliwy do osiągnięcia przez organizację.

Opracowanie rekomendacji

Rekomendacje opisują możliwe sposoby postępowania w kolejnych działaniach. Który obszar procesowy TMMi powinien zostać wdrożony jako pierwszy? Którą częścią danego obszaru procesowego należy się zająć i w jaki sposób? Rekomendacje są tworzone pod kierunkiem ekspertów w dziedzinie TMMi (wewnętrznych lub zewnętrznych) specjalizujących się w danych obszarach procesowych.

B.2.3       E – Establishing: faza ustanawiania

W tej fazie jest opracowywany szczegółowy plan wdrożenia modelu TMMi, obejmujący opracowane rekomendacje. Cele ogólne zarysowane w fazie inicjowania są uszczegóławiane zgodnie z metodą SMART. Określa się priorytety rekomendacji z uwzględnieniem różnych czynników, m.in. dostępności zasobów, widoczności, prawdopodobieństwa sprzeciwu

i stopnia realizacji celów organizacyjnych. Faza ustanawiania obejmuje następujące działania:

•      Ustalenie priorytetów

•      Opracowanie podejścia

•      Planowanie działań

Ustalenie priorytetów

Pierwszym działaniem w ramach tej fazy jest ustalenie priorytetów związanych

z wprowadzeniem zmiany. Na przykład próba jednoczesnego wdrożenia wszystkich pięciu obszarów procesowych na poziomie 2. nie ma większego uzasadnienia. Dzięki ustaleniu priorytetów można określić, które obszary procesowe i które elementy tych obszarów zostaną wdrożone jako pierwsze. Należy przy tym wziąć pod uwagę kilka czynników, m.in. dostępność zasobów, widoczność rezultatów, prawdopodobieństwo sprzeciwu wobec zmiany i udział

w realizacji celów organizacyjnych.

Opracowanie podejścia

Na podstawie rekomendacji i priorytetów tworzy się strategię uzyskania stanu docelowego i pożądanego poziomu TMMi, a także wskazuje zasoby niezbędne do ich uzyskania. Brane są pod uwagę czynniki techniczne, np. nowe metody, techniki i zasoby. Należy pamiętać o szkoleniach, opracowaniu opisów procesów i możliwości wyboru narzędzi. Wśród uwzględnianych czynników nietechnicznych są m.in. wiedza i doświadczenie uczestników, podejście do wdrożenia, sprzeciw wobec zmian, wsparcie, potrzeba pilnego wprowadzenia zmiany i kultura organizacyjna.

Planowanie działań

Po zdefiniowaniu podejścia można określić szczegółowe działania. Wraz

z informacjami pochodzącymi z poprzednich działań uwzględnia się je w planie zawierającym m.in. czynności do wykonania, harmonogram, kamienie milowe, punkty decyzyjne, zasoby, obowiązki, miary, mechanizmy śledzenia, ryzyka i strategię wdrożenia.

B.2.4       A – Acting: faza działania

Zgodnie z nazwą w tej fazie najistotniejsze są konkretne działania. Planowane podejście musi zostać zrealizowane, a poszczególne rekomendacje muszą zostać szczegółowo wyspecyfikowane i wdrożone. Oczywiście pracochłonność tej fazy jest największa, ponieważ zwykle z zaprojektowaniem rozwiązania wiąże się około 30% nakładu pracy, natomiast jego wdrożenie pochłania około 70% [Cannegieter]. Faza obejmuje następujące działania:

•      Tworzenie rozwiązania

•      Wdrożenie pilotażowe/testowe rozwiązania

•      Ulepszenie rozwiązania

•      Pełne wdrożenie rozwiązania

Tworzenie rozwiązania

Faza działania rozpoczyna się od wytworzenia rozwiązań umożliwiających wyeliminowanie ogólnie zarysowanych problemów. Takie rozwiązania powinny realizować cele i praktyki modelu TMMi oraz przyczyniać się do osiągnięcia stanu docelowego. Wśród rozwiązań mogą się znajdować procesy, szablony, narzędzia, wiedza, kwalifikacje (szkolenia), informacje i mechanizmy wsparcia. Rozwiązania mogą być dość złożone, a ich tworzeniem zajmują się często zespoły ds. doskonalenia, w których uczestniczą eksperci w dziedzinie modelu TMMi. Sprawdzonym podejściem opartym na zespołach ds. doskonalenia jest sztafeta zespołów. W takim modelu działania różne zespoły jeden po drugim opracowują i wdrażają

w krótkim czasie rozwiązania lub ich fragmenty. Wśród zalet takiego podejścia warto wymienić skrócenie czasu realizacji zadań w stosunku do czasu potrzebnego jednemu ogólnemu zespołowi ds. doskonalenia, szybkie uzyskiwanie rezultatów oraz możliwość skuteczniejszego kierowania procesem. Każdy zespół ds. doskonalenia musi mieć dobrze określony cel

i konkretne zadanie wyznaczone przez kierownictwo projektu. W opracowaniu rozwiązań powinna uczestniczyć możliwie największa liczba pracowników. Konsultant zewnętrzny może udzielić wskazówek i dostarczyć merytorycznych informacji.

Wdrożenie pilotażowe/testowe rozwiązania

Zgodnie z radą Toma Gilba – „jeśli nie wiesz, co robisz, nie rób tego na dużą skalę” – opracowane rozwiązanie powinno zostać najpierw zweryfikowane w jednym lub kilku projektach testowych. Czasami właściwe efekty rozwiązania można dostrzec dopiero

w praktycznym zastosowaniu. W ramach pilotażu tworzy się jeden lub kilka projektów, w których następuje wdrożenie i ocena usprawnień, zanim zostaną one zastosowane w dodatkowych projektach.

Ulepszenie rozwiązania

Dzięki skorzystaniu z rezultatów projektu testowego lub pilotażowego można zoptymalizować rozwiązanie. Do wypracowania zadowalającego rozwiązania, które sprawdzi się we wszystkich projektach, może być konieczne wykonanie kilku iteracji procesu optymalizacji testowania. Rozwiązanie powinno nadawać się do zastosowania; oczekiwanie na stworzenie „idealnego” rozwiązania może niepotrzebnie opóźnić wdrożenie zmian.

Pełne wdrożenie rozwiązania

Jeśli rozwiązanie zostanie uznane za nadające się do zastosowania, można je wdrożyć

w organizacji (testowej). Z tym działaniem zwykle wiąże się największy sprzeciw użytkowników. Można zastosować różne metody wdrożenia, m.in.:

•      Big Bang – wszystkie zmiany organizacyjne wdrażane są jednocześnie

•      Jeden projekt naraz – w każdym projekcie zmiana jest wdrażana w określonym momencie

•      Bezpośrednio przed wykonaniem – zmiana jest wdrażana w trakcie realizacji procesu

Żadna z tych metod nie stanowi uniwersalnego podejścia, które sprawdzi się w każdej sytuacji. Wybrany sposób wdrożenia powinien wynikać z charakteru zmiany i okoliczności działania organizacji. W przypadku dużej zmiany wdrożenie może wymagać dłuższego czasu, większych zasobów i pracochłonności, a także większego zaangażowania kierownictwa.

B.2.5       L– Learning: faza uczenia się

Faza uczenia się jest ostatnią fazą cyklu doskonalenia. Jednym z celów modelu IDEAL jest ciągłe zwiększanie zdolności do wdrażania zmian. W fazie uczenia się cały proces oparty na modelu IDEAL podlega przeglądowi. Organizacja sprawdza, co udało się osiągnąć i czy zrealizowano zakładane cele; próbuje również ustalić, co należy zrobić, aby w bardziej skuteczny i efektywny sposób wdrażać kolejne zmiany. Faza obejmuje następujące działania:

•      Analiza i ocena

•      Propozycja działań w przyszłości

Analiza i ocena

W ramach tego działania podejmuje się próbę odpowiedzi na pytania:

•      Jak udało się zrealizować program doskonalenia?

•      Co udało się osiągnąć? Czy początkowe cele zostały zrealizowane?

•      Co poszło dobrze?

•      Co można było zrobić skuteczniej lub w bardziej efektywny sposób?

Dzięki odpowiedziom na te pytania można zgromadzić wnioski, przeanalizować je, podsumować i udokumentować.

Propozycja działań w przyszłości

Na podstawie wyników poprzedniego działania formułowane są rekomendacje, których celem jest ulepszenie realizowanych w przyszłości programów doskonalenia (niekoniecznie opartych na modelu TMMi). Opracowane rekomendacje przekazywane są do analizy kierownictwu wyższego szczebla.

Glossary[4]

acceptance criteria

The criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [ISTQB]

acceptance testing

Testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorized entity to determine whether or not to accept the system.

action proposal

The documented action to be taken to prevent the future occurrence of common causes of defects or to incorporate best practices into test process assets.

actual result

The behavior produced/observed when a component or system is tested.

audit

An independent examination of a work product or process performed by a third party to assess whether it complies with specifications, standards, contractual agreements, or other criteria. [ISTQB]

availability

The degree to which a system or component is operational and accessible when required to use. [ISO 25010]

best practice

A superior method or innovative practice that contributes to the improved performance of an organization within a given context, usually recognized as ‘best’ by other peer organizations.

black-box testing

Testing, either functional or non-functional, without reference to the internal structure of the component or system.

black-box test design technique

Technique/procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.

boundary value analysis

A black box test design technique in which test cases are designed based on boundary values.

branch coverage

The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.

branch testing

A white box test design technique in which test cases are designed to execute branches.

Capability Maturity Model Integration

(CMMI)

An integrated model of best practices that enable business to improve performance by improving their processes. The CMMI provides a best-practice framework for building, improving and sustaining process capability. [CMMIV2]

capture/playback tool

A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.

cause-effect graphing

A black box test design technique in which test cases are designed from cause-effect graphs. [BS 7925/2]

checklist

Checklists are ‘stored wisdom’ aimed at helping to interpret the rules and explain their application. Checklists are used to increase effectiveness at finding major defects in a specification during a review. A checklist usually takes the form of a list of questions. All checklist questions are derived directly and explicitly from cross-referenced specification rules. [Gilb and Graham]

code coverage

An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed, e.g., statement coverage, decision coverage or condition coverage.

common causes

The underlying source of a number of defects of a similar type, so that if the root cause is addressed the occurrence of these types of defects is decreased or removed.

component

A part of a system that can be tested in isolation. [ISTQB]

component integration testing

Testing performed to expose defects in the interfaces and interaction between integrated components.

component testing

A test level that focuses on individual hardware or software components. [ISTQB]

condition coverage

The percentage of condition outcomes that have been exercised by a test suite. 100% condition coverage requires each single condition in every decision statement to be tested as True and False.

condition testing

A white box test design technique in which test cases are designed to execute condition outcomes.

confidence level

The likelihood that the software is defect-free. [Burnstein]

configuration

The composition of a component or system as defined by the number, nature, and interconnections of its constituent parts.

configuration baseline

The configuration information formally designated at a specific time during a solution or solution component’s life. Configuration baselines plus approved changes from those baselines constitute the current configuration information. [CMMIV2]

configuration control

The process of managing changes to a formal configuration baseline. The process consists of evaluating the change, coordinating any effects, approving or disapproving the change, and implementing the changes to configuration items in the baseline. [CMMIV2]

Configuration control board

(CCB)

A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes. Configuration control boards are also known as change control boards .  [CMMIV2]

configuration identification

An configuration management activity that involves selecting

a product’s configuration items, assigning them unique identifiers,  and recording their functional and physical characteristics in technical documentation. [CMMIV2]

configuration item

Work products designated for configuration management and treated as a single entity in the configuration management process. [CMMIV2]

configuration management

The process of managing the integrity of work products using configuration identification, version control, change control, and audits. [CMMIV2]

configuration management tool

A tool that provides support for the identification and control of configuration items, their status over changes and versions, and the release of baselines consisting of configuration items.

confirmation testing

A type of change-related testing performed after fixing a defect to confirm that a failure caused by that defect does not re-occur. [ISTQB]

continuous representation

A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within specified process areas. [CMMI]

coverage tool

A tool that provides objective measures of what structural elements, e.g., statements and/or branches, have been exercised by a test suite.

decision coverage

The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage.

decision table testing

A black-box test technique in which test cases are designed to exercise the combinations of conditions and the resulting actions shown in a decision table. [ISTQB]

decision testing

A white box test design technique in which test cases are designed to execute decision outcomes.

defect

An imperfection or deficiency in a work product where it does not meet its requirements or specifications. [ISTQB]

defect classification scheme

A set of categories, including phase, defect type, cause, severity, priority, to describe a defect in a consistent manner.

defect density

The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms, e.g., lines-of-code, number of classes or function points).

Defect Detection Percentage

(DDP)

The number of defects found by a test level, divided by the number found by that test level and any other means afterwards. [ISTQB]

defect management

The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact. [After ISTQB]

defect management tool

A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation, correction and confirmation testing of defects and provide reporting facilities. See also incident management tool.

defect prevention

The activities involved in identifying defects or potential defects, analyzing these defects to find their root causes and preventing them from being introduced into future products. [After Burnstein]

defect report

Documentation of the occurrence, nature, and status of a defect. [ ISO 29119-1]

defect taxonomy

A system of (hierarchical) categories designed to be a useful aid for reproducibly classifying defects.

defined process

The subset of organization process assets that are essential for any tailored or managed process. A fully defined process has enough detail that it can consistently performed by trained and skilled people and is both persistent and habitual. A defined process is necessary at TMMi level 3. [CMMIV2]

deliverable

Any (work) product that must be delivered to someone other than the (work) product’s author.

driver

A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [After TMap]

dynamic analysis tool

A tool that provides run-time information on the state of the software code. These tools are most commonly used to identify unassigned pointers, check pointer arithmetic and to monitor the allocation, use and de-allocation of memory and to flag memory leaks.

dynamic testing

Testing that involves the execution of the software of a component or system.

entry criteria

The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g., test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria. [Gilb and Graham]

equivalence partition

A portion of an input or output domain for which the behavior of

a component or system is assumed to be the same, based on the specification.

equivalence partitioning

A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.

error

A human action that produces an incorrect result. [ISTQB]

error guessing

A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made, and to design tests specifically to expose them.

exit criteria

The set of generic and specific conditions, agreed upon with the stakeholders, for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [After Gilb and Graham]

expected component

TMMi components that describe the activities that are important in achieving a required TMMi component, guiding those who implement improvements or perform appraisals.

expected result

The behavior predicted by the specification, or another source, of the component or system under specified conditions.

experienced-based test design technique

Procedure to derive and/or select test cases based on the tester’s experience, knowledge and intuition.

exploratory testing

An approach to testing whereby the testers dynamically design and execute tests based on their knowledge, exploration of the test item and the results of previous tests. [ISTQB]

failure

An event in which a component or system does not perform

a required function within specified limits. [ISTQB]

feature

An attribute of a component or system specified or implied by requirements documentation (for example reliability, usability or design constraints).

formal review

A type of review that follows a defined process with a formally documented output. [ISTQB]

Function Point Analysis

(FPA)

Method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources, and project control.

functional testing

Testing performed to evaluate if a component or system satisfies functional requirements. [ISTQB]

functionality

The degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions. [ISO 25010]

generic goal

A required model component that describes the characteristics that must be present to institutionalize the processes that implement

a process area. [CMMI]

generic practice

An expected model component that is considered important in achieving the associated generic goal. The generic practices associated with a generic goal describe the activities that are expected to result in achievement of the generic goal and contribute to the institutionalization of the processes associated with a process area. [CMMI]

Goal Question Metric (GQM)

An approach to software measurement using a three-level model: conceptual level (goal), operational level (question) and quantitative level (metric).

heuristic evaluation

A usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called “heuristics”).

higher level management

The person or persons who provide the policy and overall guidance for the process, but do not to provide direct day-to-day monitoring and controlling of the process. Such persons belong to a level of management in the organization above the intermediate level responsible for the process and can be (but are not necessarily) senior managers. [CMMI]

horizontal traceability

The tracing of requirements for a test level through the layers of test documentation (e.g., test plan, test design specification, test case specification and test procedure specification or test script). The horizontal traceability is expected to be bi-directional.

impact analysis

The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.

improvement proposal

A change request that addresses a proposed process or technology improvement and typically also includes a problem statement, a plan for implementing the improvement, and quantitative success criteria for evaluating actual results of the deployment within the change process managed by the Test Process Group.

Incident

Any event occurring that requires investigation. [ISTQB]

incident logging

Recording the details of any incident that occurred, e.g., during testing.

incident management

The process of recognizing, investigating, taking action and disposing of incidents. It includes logging incidents, classifying them and identifying the impact.

incydent management tool

A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation, correction and confirmation testing of incidents and provide reporting facilities. See also defect management tool.

incident report

Documentation of the occurrence, nature, and status of an incident. [ISO 29119-1]

independence of testing

Separation of responsibilities, which encourages the accomplishment of objective testing. [After DO-178C]

indicator

A measure that provides an estimate or evaluation of specified attributes derived from a model with respect to defined information needs. [ISO 25040]

informal review

A type of review that does not follow a defined process and has no formally documented output.   [ISTQB]

informative component

TMMi components that help model users understand TMMi required and expected components .

input

A variable (whether stored within a component or outside) that is read by a component.

inspection

A formal review of a work product to identify issues, which uses defined roles and measurement to improve the inspection process. [ISO 20246]

institutionalization

The ingrained way of doing business that an organization follows routinely as part of its corporate culture.

intake test

A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase. See also smoke test.

integration

The process of combining components or systems into larger assemblies.

integration testing

A test level performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing, system integration testing. [ISTQB]

level test plan

A test plan that typically addresses one test level. See also test plan.

maintainability

The degree of effectiveness and efficiency with which a product or system can be modified to improve it, correct it or adapt it to changes in environment, and in requirements. [ISO 25010]

managed process

A performed process that is recorded, followed, updated, and made persistent and habitual in use. A managed process is necessary at TMMi level 2. [CMMIV2]

management review

A systematic evaluation of software acquisition, supply, development, operation, or maintenance process, performed by or on behalf of management that monitors progress, determines the status of plans and schedules, confirms requirements and their system allocation, or evaluates the effectiveness of management approaches to achieve fitness for purpose. [ISTQB]

master test plan

A test plan that is used to coordinate multiple test levels or test types. [ISTQB]. See also test plan.

maturity level

A rating which describes the degree to which processes in an organization unit meet the intent and goals of a predefined set of process areas. [CMMIV2]

Mean Time Between Failures (MTBF)

The average time between failures of a component or system. [ISTQB].

Mean Time To Repair (MTTR)

The average time a component or system will take to recover from a failure. [ISTQB]

measure

Variable to which a value is assigned as the result of measurement. [ISO 25040]

measured process

A defined process whereby product quality and process attributes are consistently measured, and the measures are used to improve and make decisions regarding product quality and process-performance. A measured process is necessary at TMMi level 4.

measurement

Set of operations having the object of determining a value of

a measure.attribute [ISO 25040]

metric

A measurement scale and the method used for measurement. [ISTQB]

milestone

A point in time in a project at which defined (intermediate) deliverables and results should be ready.

moderator

The person that ensures effective running of review meetings. [ISO 20246]

non-functional testing

Testing the attributes of a component or system that do not relate to functionality, e.g., reliability, efficiency, usability, maintainability and portability.

non-functional test design techniques

Procedure to derive and/or select test cases for non-functional testing based on an analysis of the specification of a component or system without reference to its internal structure. See also black box test design technique.

operational profile

The representation of a distinct set of tasks performed by the component or system, possibly based on user behavior when interacting with the component or system, and their probabilities of occurrence. A task is logical rather than physical and can be executed over several machines or be executed in non-contiguous time segments.

operational profile testing

Statistical testing using a model of system operations (short duration tasks) and their probability of typical use. [Musa]

optimizing process

A quantitatively managed process that is continuously improved to improve its capability. These continuous improvements can be made through both incremental and innovative improvements. An optimizing process is necessary at TMMi level 5. [CMMIV2]

output

A variable (whether stored within a component or outside) that is written by a component.

Pareto analysis

A  statistical technique in decision making that is used for selection of a limited number of factors that produce significant overall effect. In terms of quality improvement, a large majority of problems (80%) are produced by a few key causes (20%).

pass/fail criteria

Decision rules used to determine whether a test item (function) or feature has passed or failed after testing. [SO 29119-1]

peer review

The examination of work products performed by similarly skilled personnel during the development of work products to identify defects for removal.

peer review leader

The person that takes overall responsibility for the review and decides who will be involved, organizes when and where it will take place, etc.. [ISO 20246]

performance indicator

Measurable criteria used to monitor towards quantitative objectives. Collectively, performance indicators provide a metric for determining success for the business or project. [CMMIV2]

phase test plan

A test plan that typically addresses one test phase. See also test plan.

portability

D egree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another. [ISO 25010]

post condition

The expected state of a test item and its environment at the end of test case execution. [ISTQB]

precondition

The required state of a test item and its environment prior to test case execution. [ISTQB]

priority

The level of (business) importance assigned to an item, e.g., defect.

process

A set of interrelated activities, which transform inputs into outputs. [ISO 12207]

process area

A cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvements in that area. [CMMI]

process assessment

A disciplined evaluation of an organization’s software processes against a reference model. [ISO 33061]

process capability

The recorded range of expected results that can be achieved by following a process. [CMMIV2]

process improvement

Tasks and activities planned, performed and used to improve an organization’s process capability and performance to achieve business objectives more effectively. {CMMIV2]

process performance

A measure of results achieved by following a process. [CMMIV2]

proces performance baseline

A record and description of historical process performance resulting from following a defined process, which can include central tendency, e.g., mean, medium, mode, variation, and reflects how the process is being performed. Process performance baselines can be used  as  benchmarks for comparing actual process performance to expected process performance and can be used in process performance models to predict future process performance. [CMMI]

proces performance objectives

Objectives and requirements for product quality, service quality and process performance.

product risk

A risk that a product may be defective in some specific aspect of its function, quality, or structure   See also risk.[ISO 29119-1]

project

A project is a unique set of coordinated and controlled activities with start and finish dates undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources. [ISO 9000]

project risk

A risk related to management and control of the (test) project, e.g., lack of staffing, strict deadlines, changing requirements, etc. See also risk. [ISO 29119-1]

project test plan

See master test plan.

quality assurance

Part of quality management focused on providing confidence that quality requirements will be fulfilled. [ISO 9000]

quality characteristic

Category of software quality attributes that bears on software quality [ISO 25010]

quantitatively managed process

A defined process evaluated and controlled using statistical and other quantitative techniques. [CMMIV2]

regression testing

Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.

release note

A document identifying test items, their configuration, current status and other delivery information delivered by development to testing, and possibly other stakeholders, at the start of a test execution phase.

reliability

Degree to which a system, product or component performs specified functions under specified conditions for a specified period of time. [ISO 25010]

reliability growth model

A model that shows the growth in reliability over time during continuous testing of a component or system as a result of the removal of defects that result in reliability failures.

required component

TMMi components that are essential to achieving process improvement in a given process area, implemented across the organization.

requirement

A  need or expectation that is stated, generally implied or obligatory. [ISO 9000]

requirements-based testing

An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements, e.g., tests that exercise specific functions or probe non-functional attributes such as reliability or usability.

requirements phase

The period of time in the software lifecycle during which the requirements for a software product are defined and documented.

result

The consequence/outcome of the execution of a test. It includes outputs to screens, changes to data, reports, and communication messages sent out. See also actual result, expected result.

resumption criteria

The testing activities that may have to be repeated when testing is re-started after a suspension. [After ISO 29119-3]

review

A type of static testing in which a work product or process is evaluated by one or more individuals to detect defects or to provide improvements. [ISTQB]

reviewer

The person involved in the review that identifies issues in the work product. A reviewer may be a subject matter expert, someone working on the project or any other stakeholder with an interest in the work product. [ISO 20246]

risk

A factor that could result in future negative consequences; usually expressed as impact and likelihood.

risk analysis

The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).

risk-based testing

Testing in which the management, selection, prioritisation, and use of testing activities and resources is consciously based on corresponding types and levels of analyzed risk. [ISO 29119-2]

risk identification

The process of finding, recognizing and describing risks using techniques such as brainstorming, checklists and failure history. [ISTQB]

risk level

The importance of a risk as defined by its characteristics, impact and likelihood. A risk level can be expressed either qualitatively (e.g., high, medium, low) or quantitatively. [ISTQB]

risk management

Systematic application of procedures and practices to the tasks of identifying, analyzing, prioritizing, and mitigating risk.

risk mitigation

The process through which decisions are reached and protective measures are implemented for reducing or maintaining risks to specified levels.

risk type

A set of risks grouped by one or more common factors. [ISTQB]

root cause

A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed.

root cause analysis

An analysis technique aimed at identifying the root causes of defects. By directing corrective measures at root causes, it is hoped that the likelihood of defect recurrence will be minimized.

rule

A rule is any statement of a standard on how to write or carry out some part of a systems engineering or business process. [Gilb and Graham]

sampling

A statistical practice concerned with the selection of an unbiased or random subset of individual observations within a population of individuals intended to yield some knowledge about the population of concern as a whole.

scribe

The person who – records information at the review meeting .  [ISO 20246]

severity

The degree of impact that a defect has on the development or operation of a component or system.

simulator

A device, computer program or system used during testing, which behaves or operates like a given system when provided with a set of controlled inputs. [DO-178C].

smoke test

A test suite that covers the main functionality of a component or system to determine whether it works properly before planned testing begins. [ISTQB] See also intake test.

software lifecycle

The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software lifecycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note these phases may overlap or be performed iteratively.

specific goal

A required model component that describes the unique characteristics that must be present to satisfy the process area. [CMMI]

specific practice

An expected model component that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. [CMMI]

specification

A document that specifies, ideally in a complete, precise and verifiable manner, the requirements, design, behavior, or other characteristics of a component or system, and, often, the procedures for determining whether these provisions have been satisfied.

staged representation

A model structure wherein attaining the goals of a set of process areas establishes a maturity level; each level builds a foundation for subsequent levels. [CMMI]

standard

F ormal, possibly mandatory, set of requirements developed and used to prescribe consistent approaches to the way of working or to provide guidelines (e.g., ISO/IEC standards, IEEE standards, and organizational standards). [After CMMI]

state transition testing

A black box test design technique in which test cases are designed to execute valid and invalid state transitions.

statement coverage

The percentage of the set of all executable statements of a test item that are covered by a test set. [ISO 29119-1]

statement testing

A white box test design technique in which test cases are designed to execute statements.

static analysis

Analysis of software artifacts, e.g., requirements or code, carried out without execution of these software artifacts.

static testing

Testing in which a test item is examined against a set of quality or other criteria without code being executed, e.g., reviews and static analysis. [ISO 29119-1]

statistical process control

Statistical that identifies common and special causes of process variation and seeks to maintain process performance within limits. [CMMIV2]

statistical technique

Mathematical techniques used with the collection, analysis, interpretation, and presentation of masses of numerical data to understand process variation and predict process performance, e.g., sampling techniques, analysis of variance, chi-squared tests, regression analysis, and process control charts. [CMMIV2]

statistical testing

A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases.

stub

A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component.

sub-practice

An informative model component that provides guidance for interpreting and implementing a specific or generic practice. Sub-practices may be worded as if prescriptive, but are actually meant only to provide ideas that may be useful for process improvement. [CMMI]

suspension criteria

Criteria used to (temporarily) stop all or a portion of the testing activities. [ISO 29119-1]

system

A collection of components organized to accomplish a specific function or set of functions.

System integration testing

A test level that focuses on interactions between systems. [ISTQB]

system testing

A test level that focuses on verifying that a system as a whole meets specified requirements. [ISTQB]

technical review

A type of formal review of a work product by a team of qualified personnel that examines the suitability of the work product for its intended use and identifies discrepancies from specifications and standards. [After ISO 20246]

test

A set of one or more test cases.

test approach

The implementation of the test strategy for a specific project. It typically includes the decisions made that consider the (test) project’s goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed.

test basis

Body of knowledge used as the basis for the design of tests and test cases. [ISO 29119-1]

test case

Set of test case preconditions, inputs (including actions, where applicable), and expected results, developed to drive the execution of a test item to meet test objectives. [ISO 29119-1]

test case specification

A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item. [ISO 29119-1]

test charter

A statement of test objectives, and possibly test ideas about how to test. Test charters are used in exploratory testing. See also exploratory testing.

test completion

During the test completion phase of a test process data is collected from completed activities to consolidate experience, test ware, facts and numbers. The test completion phase consists of finalizing and archiving the test ware and evaluating the test process, including preparation of a test completion report. See also test process.

test condition

Testable aspect of a component or system, such as a function, transaction, feature, quality characteristics, or structural element identified as a basis for testing. [ISO 29119-1]

test control

A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned. See also test management.

test cycle

An instance of the test process against a single identifiable version of the test object. [ISTQB]

test data

Data created or selected to satisfy the input requirements for executing one or more test cases, which may be defined in the Test Plan, test case or test procedure. [ISO 29119-1]

test data preparation tool

A type of test tool that enables data to be selected from existing databases or created, generated, manipulated and edited for use in testing.

test design

(1) See test design specification.

(2) The process of transforming general testing objectives into tangible test conditions and test cases.

test design specification

Documentation specifying the features to be tested and their corresponding test conditions. [ISO 29119-1]

test design technique

Activities, concepts, processes, and patterns used to construct a test model that is used to identify test conditions for a test item, derive corresponding test coverage items, and subsequently derive or select test cases. [ISO 29119-1]

test design tool

A tool that supports the test design activity by generating test inputs from a specification that may be held in a CASE tool repository, e.g., requirements management tool, from specified test conditions held in the tool itself, or from code.

test environment

Facilities, hardware, software, firmware, procedures, and documentation intended for or used to perform testing of software. [ISO 29119-1]

test estimation

An approximation related to various aspects of testing (e.g., effort spent, completion date, costs involved, number of test cases, etc.). [After ISTQB]

test completion report

A document produced at the end of the test process summarizing all testing activities and results. It also contains an evaluation of the test process and lessons learned. [ISO 29119-3]

test execution

The process of running a test on the component or system under test, producing actual result(s).

test execution phase

The period of time in a software development lifecycle during which the components of a software product are executed, and the software product is evaluated to determine whether or not requirements have been satisfied.

test execution schedule

A scheme for the execution of test suites within a test cycle.. The test scripts or procedures are included in the test execution schedule in their context and in the order in which they are to be executed.

test execution tool

A test tool that executes tests against a designated test item and evaluates the outcomes against expected results and postconditions. [ISTQB]

test implementation

The activity that prepares the testware needed for test execution based on test analysis and design, e.g., developing and prioritizing test procedures, creating test data and writing automated test scripts,

test improvement plan

A plan for achieving organizational test process improvement objectives based on a thorough understanding of the current strengths and weaknesses of the organization’s test processes and test process assets. A test improvement plan records the objectives, activities, resources, oversight, schedule and associated risks to improve test processes. [After CMMIV2]

test item

The individual element to be tested. There usually is one test object and many test items. See also test object.

test level

A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test, integration test, system test and acceptance test. [After TMap]

test log

A chronological record of relevant details about the execution of tests. [ISO 29119-3]

test logging

The process of recording information about tests executed into a test log.

test manager

The person responsible for project management of testing activities and resources, and evaluation of a test object.

test management

The planning, scheduling, estimating, monitoring, reporting, control and completion of test activities. [ISO 29119-1]

test management tool

A tool that provides support to the test management and control part of a test process. It often has several capabilities, such as test ware management, scheduling of tests, the logging of results, progress tracking, incident management and test reporting.

Test Maturity Model integration

(TMMi)

A five level staged framework for test process improvement, related to the Capability Maturity Model Integration (CMMI), which describes the key elements of an effective and efficient test process.

test monitoring

The activity that checks the status of testing activities, identifies any variances from planned or expected, and reports status to stakeholders. [ISTQB] See also test management.

test object

The component or system to be tested. See also test item.

test objective

A reason or purpose for designing and executing a test.

test performance indicator

A high level metric of effectiveness and/or efficiency used to guide and control progressive test development, e.g., Defect Detection Percentage (DDP).

test phase

A distinct set of test activities collected into a manageable phase of a project, e.g., the execution activities of a test level.

test plan

A detailed description of test objectives to be achieved and the means and schedule for achieving them, organized to coordinate testing activities for some test item or set of test items. [ISO 29119-1]

test planning

The activity of establishing or updating a test plan.

test policy

A high level document describing the principles, approach and major objectives of the organization regarding testing.

Test Point Analysis

(TPA)

A formula based test estimation method based on function point analysis. [TMap]

test procedure specification

A document specifying one or more test procedures, which are collections of test cases to be executed for a particular objective. The test cases in a test set are typically listed in their required order in the test procedure. Also known as a manual test script. A test procedure specification for an automated test run is usually called a test script. [ISO 29119-1]

test process

The set of interrelated activities comprising of test planning, test monitoring and control, test analysis, test design, test implementation, test execution, and test completion. [ISTQB]

test process asset library

A collection of test process asset holdings that can be used by an organization or project. [CMMI]

Test Process Group (TPG)

A person or team who hold a test process role and are responsible for developing, deploying, and updating the organization’s test process assets. [After CMMIV2]

test progress report

A type of test report produced at regular intervals about the progress of test activities against a baseline, risks, and alternatives requiring a decision. [ISTQB]

test run

Execution of a test suite on a specific version of the test object.

test schedule

A list of activities, tasks or events of the test process, identifying their intended start and finish dates and/or times, and interdependencies.

test script

Test procedure specification (sequence of instructions for the execution of a test) for manual or automated testing. [After ISO 29119-1]

test session

An uninterrupted period of time spent in executing tests. See also exploratory testing.

test specification

The complete documentation of the test design, test cases and test procedures for a specific test item.[ISO 29119-1]

test strategy

A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).

test suite

A set of test scripts or test procedures to be executed in a specific test run. [ISTQB]

test summary report

A type of test report produced at completion milestones that provides an evaluation of the corresponding test items against exit criteria. [ISTQB]

test tool

Software or hardware that supports one or more test activities. [ISTQB]

test type

A group of test activities aimed at testing a component or system focused on a specific test objective or quality characteristic, i.e. functional test, security test, usability test, regression test etc. [ISO 29119-1]

testability review

A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process. [After TMap]

tester

A person who performs testing. [ISTQB]

testing

The process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects.

testware

Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing. [ISO 29119-1]

traceability

The ability to identify related items in documentation and software, such as requirements with associated tests. See also horizontal traceability, vertical traceability.

trustworthiness

The probability that there are no defects in the software that will cause the system to fail catastrophically. [Burnstein]

unit testing

See component testing.

usability

Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. [ISO 25010]

V-model

A sequential development lifecycle model describing a one-for-one relationship between major phases of software development from business requirements specification to delivery, and corresponding test levels from acceptance testing to component testing. [ISTQB]

validation

Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. [ISO 9000]

verification

Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. [ISO 9000]

vertical traceability

The tracing of requirements through the layers of development documentation to components.

walkthrough

A type of review in which an author leads members of the review through a work product and the members ask questions and make comments about possible issues. [ISO 20246]

white-box test design technique

Technique/Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.

white-box testing

Testing based on an analysis of the internal structure of the component or system.

Wide Band Delphi

An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.

Odniesienia:

[Bach] J. Bach (2004), Exploratory Testing, w: E. van Veenendaal, The Testing Practitioner – 2nd edition, UTN Publishing

[Beizer] B. Beizer (1990), Software Testing Techniques, van Nostrand Reinhold

[Boehm] B.W. Boehm (1981), Software Engineering Economics, Prentice Hall

[BS7925-2] BS7925-2 (1998), Standard for Software Component Testing, British Standards Institution

[Burnstein]. I. Burnstein (2002), Practical Software Testing, Springer Professional Computing

[CMMI] M.B. Chrissis, M. Konrad and S. Shrum (2007), CMMI Second Edition, Guidelines for Process Integration and Product Improvement, Addison Wesley

[CMMIV2] ISACA, CMMI Model V2.0 – Overview (2018), Information Systems Audit and Control Association

[DO-178C] DO-178C (2011). Software Considerations in Airborne Systems and Equipment Certification (RTCA SC205),

[Fenton] N. Fenton (1991), Software Metrics: a Rigorous Approach, Chapman & Hall

[Fewster and Graham] M. Fewster and D. Graham (1999), Software Test Automation, Effective use of test execution tools, Addison-Wesley

[Freedman and Weinberg] D. Freedman and G. Weinberg (1990), Walkthroughs, Inspections, and Technical Reviews, Dorset House Publishing

[Gelperin and Hetzel] D. Gelperin and B. Hetzel (1998), “The Growth of Software Testing”, w: CACM, Vol. 31, No. 6, 1988, pp. 687-695

[Gerrard] P. Gerrard and N. Thompson (2002), Risk-Based E-Business Testing, Artech House Publishers

[Gilb] T. Gilb (1988), Principles of Software Engineering Management, Addison-Wesley

[Gilb and Graham] T. Gilb and D. Graham (1993), Software Inspection, Addison-Wesley

[Graham] D. Graham, R. Black i E. van Veenendaal (2019), Foundations of Software Testing, Foundations of Software Testing – ISTQB Certification - 4th edition, Cengage

[Hauser and Clausing] J.R. Hauser and D. Clausing (1988), The House of Quality, w: Harvard Business Review, Vol. 66, Nr 3, 1988

[Hetzel] W. Hetzel (1988), The complete guide to software testing – 2nd edition, QED Information Sciences

[Hollenbach and Frakes] C. Hollenbach and W. Frakes (1996), Software process re-use in an industrial setting, in: Proceedings Fourth International Conference on Software-Reuse, Orlando, April 1998, pp. 22-30

[IDEAL] SEI (1997), IDEAL: A Users Guide for Software Process Improvement, Software Engineering Institute

[ISO 9000] ISO 9000 (2015), Quality Management Systems – Fundamentals and Vocabulary, International Organization of Standardization

[ISO 12207] ISO/IEC 12207 (2017), Software and systems engineering – Software Lifecycle Processes, International Organization of Standardization

[ISO 15504] ISO 15504-9 (1998), Information Technology – Software Process Assessment – Part 9: Vocabulary, International Organization of Standardization

[ISO 20246] ISO/IEC 20246 (2017), Software and systems engineering – Work product reviews, International Organization of Standardization

[ISO 25010] ISO/IEC 25010 (2011), Software and systems engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models, International Organization of Standardization

[ISO 25040] ISO/IEC 25040 (2011), Software and systems engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Evaluation process, International Organization of Standardization

[ISO 29119-1] ISO/IEC 29119-1 (2013), Software and systems engineering – Software testing – Part 1: Concepts and definitions, International Organization of Standardization

[ISO 29119-2] ISO/IEC 29119-2 (2013), Software and systems engineering – Software testing – Part 2: Test processes, International Organization of Standardization

[ISO 29119-3] ISO/IEC 29119-3 (2013), Software and systems engineering – Software testing – Part 3: Test documentation, International Organization of Standardization

[ISO 33061] ISO/IEC 33061 (2021), Information Technology – Process assessment – Process assessment model for software life cycle processes, International Organization of Standardization

[ISTQB] ISTQB® (2020), Standard Glossary of Terms Used in Software Testing, V3.5, International Software Testing Qualifications Board

[Koomen and Pol] T. Koomen and M. Pol (1999), Test Process Improvement, Addison-Wesley

[Musa] J. Musa (1998), Software Reliability Engineering Testing, McGraw-Hill Education

[Musa and Ackerman] J. Musa and A. Ackerman (1989), Quantifying software validation: when to stop testing, w: IEEE Software, Vol. 6, No. 3, May 1989

[Pinster et al] I. Pinkster, B. van der Burgt, D. Janssen and E. van Veenendaal (2004), Successful Test Management, Springer

[Sogeti] Sogeti (2009), TPI-Next - Business Driven Test Process Improvement, UTN Publishing

[Survey] TMMi Foundation (2021), TMMi world-wide user survey 2021 V1.1, TMMi Foundation

[TAMAR] A. Goslin (ed.) (2011), TMMi Assessment Method Application Requirements V2.0, TMMi Foundation

[TMap] M. Pol, R. Teunissen, E. van Veenendaal (2002), Software Testing, A guide to the TMap Approach, Addison Wesley.

[TMMiAgile] E. van Veenendaal (ed.) (2020), TMMi in the Agile world V1.4, TMMi Foundation

[TMMiDevOps] Matthias Rasking, Jan-Jaap Cannegieter, Tim Moore and Paul Mowat (2018), How TMMi supports the Three Ways of DevOps, TMMi Foundation white-paper

[Trienekens and Van Veenendaal] J. Trienekens and E. van Veenendaal (1997), Software Quality from a Business Perspective, Kluwer Bedrijfsinformatie

[V2M2] QualityHouse (2006), V2M2; A Verification and Validation Maturity Model – Improving test practices and models

[Veenendaal] E. van Veenendaal (2004), The Testing Practitioner – 2nd edition, UTN Publishing

[Veenendaal en Cannegieter] E. van Veenendaal and J.J. Cannegieter (2011), The little TMMi – Objectives-Driven Test Process Improvement, UTN Publishing

[Van Solingen and Berghout] R. van Solingen and E. Berghout (1999), The Goal/Question/Metric method, McGraw-Hill

Notatki

[←1]

Przypis SJSI: z uwagi na różnice w sposobie definiowania niektórych terminów przez TMMi

w odniesieniu do Słownika terminów testowych ISTQB® nie zdecydowało się na tłumaczenie słownika. W przypadku terminów odnoszących się do testowania rekomendujemy korzystanie ze Słownika terminów testowych ISTQB® dostępnego pod adresem: https://glossary.istqb.org/. Terminologia używana w TMMi® z obszaru testowania w niektórych przypadkach nie pochodzi ze Słownika terminów testowych ISTQB®, a z innych źródeł lub definicja podana jako pochodząca z ISTQB® różni się od definicji ze Słownika terminów testowych ISTQB®. Przykłady:  źródło podane jako ISTQB® – inna definicja terminów:  defect management, black box test (design) technique, integration testing.

W terminie incident podano jako źródło ISTQB® (brak terminu w Słowniku terminów testowych ISTQB®). Inne źródła definicji terminów: TMap (termin driver występuje także w Słowniku terminów testowych ISTQB®, ale ma inną definicję), ISO 29119-1 (termin product risk, który także występuje w Słowniku terminów testowych ISTQB®, ale ma inną definicję), Gilb i Graham (terminy entry criteria, exit criteria). Dla definicji pochodzących ze Słownika terminów testowych ISTQB® nie podano synonimów terminów słownikowych.

[←2]

Zgodnie ze Słownikiem terminów testowych ISTQB® (https://glossary.istqb.org/) terminy „test wstępny” oraz „test potwierdzający” są synonimami podstawowego terminu „test dymny”

[←3]

Tekst niniejszego dodatku pochodzi z rozdziału 5 książki „The Little TMMi” [Veenendaal i Cannegieter] i został wykorzystany za zgodą autorów.

[←4]

SJSI z uwagi na różnice w sposobie definiowania niektórych terminów przez TMMi w odniesieniu do Słownika terminów testowych ISTQB® nie zdecydowało się na tłumaczenie słownika. W przypadku terminów odnoszących się do testowania rekomendujemy korzystanie ze Słownika terminów testowych ISTQB® dostępnego pod adresem: https://glossary.istqb.org/. Terminologia używana w TMMi®

z obszaru testowania w niektórych przypadkach nie pochodzi ze Słownika terminów testowych ISTQB®, a z innych źródeł lub definicja podana jako pochodząca z ISTQB® różni się od definicji ze Słownika terminów testowych ISTQB®. Przykłady: źródło podane jako ISTQB® – inna definicja terminów: defect management, black box test (design) technique, integration testing. W terminie incident podano jako źródło ISTQB® (brak terminu w Słowniku terminów testowych ISTQB®). Inne źródła definicji terminów: TMap (termin driver występuje także w Słowniku terminów testowych ISTQB®, ale ma inną definicję), ISO 29119-1 (termin product risk, który także występuje w Słowniku terminów testowych ISTQB®, ale ma inną definicję), Gilb i Graham (terminy entry criteria, exit criteria). Dla definicji pochodzących ze Słownika terminów testowych ISTQB® nie podano synonimów terminów słownikowych.

Table of Contents

Historia zmian

Test Maturity Model integration (TMMi)

1.1. Wprowadzenie

1.2. Kontekst i historia

1.3. Źródła

1.4. Zakres TMMi

1.4.1. Inżynieria oprogramowania i systemów

1.4.2. Poziomy testów

1.4.3. TMMi oraz CMMI

1.4.4. Cykl życia

1.4.5. Oceny

1.4.6. Podejście usprawniające

2. Poziomy dojrzałości TMMi

2.1. Opis ogólny

2.2. Poziom 1. Wstępny

2.3. Poziom 2. Zarządzany

2.4. Poziom 3. Zdefiniowany

2.5. Poziom 4. Mierzalny

2.6. Poziom 5. Optymalizacja

3. Struktura TMMi

3.1. Elementy wymagane, oczekiwane i informacyjne

3.1.1. Elementy wymagane

3.1.2. Elementy oczekiwane

3.1.3. Elementy informacyjne

3.2. Elementy składowe / komponenty TMMi

3.2.1. Poziomy dojrzałości

3.2.2. Obszary procesowe

3.2.3. Cel

3.2.4. Uwagi wstępne

3.2.5. Zakres

3.2.6. Cele szczegółowe

3.2.7. Cele ogólne

3.2.8. Praktyki szczegółowe

3.2.9. Przykładowe produkty pracy

3.2.10. Podpraktyki

3.2.11. Praktyki ogólne

3.2.12. Opracowanie praktyk ogólnych

3.2.13. Pomocnicze komponenty informacyjne

3.2.13.1. Uwagi

3.2.13.2. Przykłady

3.2.13.3. Odniesienia

3.3. Ogólne cele i praktyki

3.4. Obszary procesowe wspierające ogólne praktyki

3.5. Wsparcie obszarów procesowych CMMI dla TMMi

3.6. Obszary praktyk CMMI Weryfikacja, walidacja i przeglądy koleżeńskie

Poziom TMMi 2: Zarządzany

PA 2.1 Polityka i strategia testów

PA 2.2 Planowanie testów

PA 2.3 Monitorowanie i kontrola testów

PA 2.4 Projektowanie i wykonywanie testów

PA 2.5 Środowisko testowe

Poziom TMMi 3: Zdefiniowany

PA 3.1 Organizacja testowa

PA 3.2 Program szkoleń testerskich

PA 3.3 Cykl życia i integracja testów

PA 3.4 Testowanie niefunkcjonalne

PA 3.5 Przeglądy koleżeńskie

Poziom TMMi 4: Mierzalny

PA 4.1 Pomiar testów

PA 4.2 Ocena jakości produktów

PA 4.3 Zaawansowane przeglądy

Poziom TMMi 5: Optymalizacja

PA 5.1 Zapobieganie defektom

PA 5.2 Kontrola jakości

PA 5.3 Optymalizacja procesu testowego

Dodatek A Oceny i certyfikacja TMMi

Dodatek B Proces doskonalenia

Glossary

Odniesienia: