Certyfikowany Tester

Sylabus dla poziomu eksperckiego

Doskonalenie procesu testowego

(Wdrażanie doskonalenia i zmian)

2011

International Software Testing Qualifications Board®

© Stowarzyszenie Jakości Systemów Informatycznych

Informacja o prawach autorskich:

Dokument niniejszy może być kopiowany w całości lub publikowany w wybranych fragmentach z podaniem źródła.

Copyright © International Software Testing Qualifications Board (zwana dalej ISTQB®).

Grupa Robocza ds. poziomu eksperckiego: Erik van Veenendaal, Graham Bath, Isabel Evans 2006-2009.

Historia zmian

Wersja

Data

Uwagi

V2011 Wydanie

24.02.2021

Przegląd edytorski

V2011 Wydanie

1.11.2011

Oficjalne wydanie

V2009 Approved 1.0.2

16.4.2010

Błąd w druku na str. 72 linijki 14/15: zmieniona kolejność linijek K5/K6

V2009 Approved 1.0.1

19.03.2010

Redakcja techniczna

V2009 Approved 1.0.0

23.10.2009

Wersja zatwierdzona do wydania

V2009-Beta2

2.7.2009

Poprawki wprowadzone po przeglądzie Beta

V2009-Beta

25.5.2009

Przegląd Beta

Spis treści

Historia zmian

Spis treści

Podziękowania

1.      Wprowadzenie do sylabusa

1.1      International Software Testing Qualifications Board

1.2      Cel niniejszego dokumentu

1.3      Certyfikowany Tester Oprogramowania - Poziom Ekspercki

1.3.1      Poziom Wiedzy

1.3.2      Egzamin

1.3.3      Akredytacja

1.4      Części normatywne i informacyjne

1.5      Poziom uszczegółowienia

1.6      Układ sylabusa

1.7      Terminy i definicje

1.8      Cele nauki / Poziomy wiedzy (K)

1.9      Wymagania

2.      Kontekst doskonalenia     285 min.

2.1      Dlaczego należy doskonalić proces testowy?

2.2      Co można udoskonalić?

2.3      Poglądy dotyczące jakości

2.4      Ogólny proces doskonalenia

2.4.1      Cykl Deminga

2.4.2      Model doskonalenia IDEAL

2.4.3      Podstawowe koncepcje doskonałości

2.5      Przegląd podejść do doskonalenia

2.5.1      Przegląd podejść opartych na modelach

2.5.2      Przegląd podejść analitycznych

2.5.3      Podejścia hybrydowe

2.5.4      Inne podejścia do doskonalenia procesu testowego

3.      Doskonalenie oparte na modelach   570 minut

3.1      Wprowadzenie do podejść opartych na modelach

3.1.1      Pożądane cechy modeli doskonalenia procesu testowego

3.1.2      Reprezentacja ciągła i etapowa

3.1.3      Założenia w stosowaniu modeli

3.2      Modele doskonalenia procesu tworzenia oprogramowania

3.2.1      Model CMMI

3.2.2      ISO/IEC 15504

3.3      Modele doskonalenia procesu testowego

3.3.1      Model doskonalenia procesu testowego (TPI®)

3.3.2      Zintegrowany model dojrzałości testów (TMMi)

3.3.3      Porównanie modeli TPI Next i TMMi

3.4      Modele oparte o zawartość

3.4.1      STEP

3.4.2      Krytyczny Proces testowy (CTP)

4.      Doskonalenie oparte o analizę   555 minut

4.1      Wstęp

4.2      Analiza przyczyn

4.2.1      Diagramy przyczynowo-skutkowe

4.2.2      Analiza przyczyn podczas procesu inspekcji

4.2.3      Wykorzystanie Standardowych Klasyfikacji Anomalii

4.2.4      Wybór usterek do Analizy Przyczyn

4.3      Podejście GQM  (Cel-Pytanie-Metryka)

4.4      Analiza przy użyciu miar, metryk i wskaźników

4.4.1      Wstęp

4.4.2      Metryki efektywności testowania

4.4.3      Metryki efektywności / kosztów testowania

4.4.4      Metryki opóźnień

4.4.5      Metryki przewidywalności

4.4.6      Metryki Jakości Produktu

4.4.7      Metryki dojrzałości testów

5.      Wybór podejścia do doskonalenia procesu testowego  105 minut

5.1      Wybór podejść do doskonalenia procesu testowego

6.      Proces doskonalenia      900 minut

6.1      Wstęp

6.2      Rozpoczęcie procesu doskonalenia

6.2.1      Określenie potrzeby doskonalenia

6.2.2      Ustalenie celów doskonalenia testów

6.2.3      Ustalenie zakresu doskonalenia

6.2.4      Wpływ innych ludzi i kultury na fazę rozpoczęcia

6.3      Diagnoza aktualnej sytuacji

6.3.1      Planowanie oceny

6.3.2      Przygotowanie oceny

6.3.3      Przeprowadzanie wywiadów

6.3.4      Opinia wstępna

6.3.5      Analiza wyników

6.3.6      Wykonanie analizy rozwiązań

6.3.7      Rekomendowanie działań mających na celu doskonalenie

6.4      Tworzenie planu doskonalenia testów

6.4.1      Ustalenie priorytetów.

6.4.2      Opracowanie podejścia do wdrożenia.

6.4.3      Planowanie udoskonaleń

6.5      Działania związane z wdrożeniem usprawnień

6.5.1      Wybór i przeprowadzenie wdrożeń pilotażowych

6.5.2      Zarządzanie i kontrola wdrożenia

6.6      Uczenie się na podstawie doskonalenia

7.      Organizacja, role i umiejętności   465 minut

7.1      Organizacja

7.1.1      Grupa zajmująca się procesem testowym

7.1.2      Doskonalenie testów w zespołach zdalnych, offshoringowych i outsourcingowych

7.2      Poszczególne role

7.2.1      Osoba doskonaląca proces testowy

7.2.2      Role oceniających

7.3      Umiejętności osoby doskonalącej/oceniającej proces testowy

7.3.1      Umiejętność przeprowadzania wywiadów

7.3.2      Umiejętność słuchania

7.3.3      Umiejętność przygotowania prezentacji i raportów

7.3.4      Umiejętności analityczne

7.3.5      Umiejętność sporządzania notatek

7.3.6      Umiejętność perswazji

7.3.7      Umiejętność zarządzania

8.      Zarządzanie zmianą       285 minut

8.1      Wstęp

8.2      Podstawowy proces zarządzania zmianą

8.3      Czynnik ludzki w procesie zarządzania zmianą

9.      Krytyczne czynniki sukcesu    300 minut

9.1      Kluczowe czynniki sukcesu

9.2      Ustalenie kultury doskonalenia

10.      Przystosowywanie się do różnych modeli cyklu życia 60 minut

10.1      Przystosowanie do rożnych modeli cyklu życia

11.      Materiały źródłowe

11.1      Normy

11.1.1      [BS7925-2]

11.1.2      BS 7925-2 Software Component Testing

11.1.3      [IEEE 1044]

11.1.4      IEEE Std 1044™  IEEE Standard Classification for Software Anomalies

11.1.5      [ISO 25000]

11.1.6      ISO/IEC 25000:2005 Software engineering. Software product quality requirements and evaluation (SquaRE). Guide to SquaRE

11.1.7      [ISO/IEC 15504]

11.1.8      ISO/IEC 15504-5 ISO 15504 – SPICE (Software Process Improvement and Capability dEtermination), Part 5, Assessment Model [1998]

11.1.9      [ISO 9126]

11.1.10      ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality

11.1.11      [ISTQB-Glossary]

11.1.12      ISTQB Glossary of terms used in Software Testing, Version 2.1, available from [ISTQB-Web]

11.2      Znaki towarowe

11.3      Książki

11.4      Referaty i artykuły

11.5      Źródła internetowe

12.      Załącznik A – Uwagi dla prowadzących szkolenia

12.1      Czas przeznaczony na szkolenie

12.2      Zastosowane normy

12.3      Ćwiczenia praktyczne

12.3.1      Wskazówki dotyczące ćwiczeń praktycznych w miejscu pracy

12.4      Ogólne wskazówki dla prowadzących szkolenia dotyczące kryteriów

12.4.1      Kryteria dotyczące dostawców szkoleń dla poziomu eksperckiego

12.4.2      Kursy na poziomie eksperckim

12.4.3      Kryteria wstępne dla szkoleniowców

Indeks

Podziękowania

Niniejszy dokument przygotowany został przez zespół autorów Grupy Roboczej International Software Testing Qualifications Board dla poziomu Ekspert dla modułu „Doskonalenie procesu testowego”:

Graham Bath (przewodniczący zespołu)

Isabel Evans

Erik van Veenendaal

Autorzy wyrażają podziękowania dla zespołu recenzentów i wszystkich Rad Krajowych za sugestie i wsparcie.

W trakcie przygotowywania sylabusa dotyczącego poziomu eksperckiego dla niniejszego modułu, członkami Grupy Roboczej poziomu Ekspert byli (w porządku alfabetycznym):

Graham Bath            Beata Karpinska      Klaus Olsen

Rex Black             Caroline Molloy            Meile Posthuma

Isabel Evans            Silvio Moser            Maud Schlich

Matthias Hamburg      Thomas Müller            Erik van Veenendaal

Kari Kakkonen             Ingvar Nordstrom

Następujące osoby uczestniczyły w przeglądach, dodawaniu komentarzy i opiniowaniu niniejszego sylabusa (w porządku alfabetycznym):

Graham Bath            Beata Karpinska       Ingvar Nordstrom       Brian Wells

Rex Black             Kari Kakkonen             Klaus Olsen

Sigrid Eldh             Marcel Kwakernaak      Meile Posthuma

Isabel Evans             Judy McKay            Stuart Reid

Cheryl George             Caroline Molloy            Maud Schlich

Derk-Jan de Grood       Thomas Müller            Neil Thompson

Matthias Hamburg       Silvio Moser            Erik van Veenendaal

Dokument niniejszy został wydany przez Zgromadzenie Ogólne ISTQB® w dniu 1 listopada 2011 roku.

1. Wprowadzenie do sylabusa

1.1 International Software Testing Qualifications Board

Międzynarodową Radę ds. Kwalifikacji w Testowaniu Oprogramowania (zwaną dalej ISTQB®) tworzą ady Członkowskie reprezentujące kraje lub regiony z całego świata. Więcej informacji dotyczących struktury i członkostwa w ISTQB znajduje się na stronie [ISTQB-Web].

1.2 Cel niniejszego dokumentu

Sylabus niniejszy stanowi podstawę przygotowania do Międzynarodowej Kwalifikacji w Testowaniu Oprogramowania na poziomie eksperckim dla modułu „Doskonalenie procesu testowego”. ISTQB® zapewnia niniejszy sylabus w sposób opisany poniżej:

- Radom Członkowskim w celu jego przetłumaczenia na język lokalny i akredytacji dostawców szkoleń. Rady Krajowe mogą dostosować sylabus do wymagań swojego języka i zmodyfikować listę materiałów źródłowych, aby dostosować ją do lokalnych publikacji.

- Komisjom Egzaminacyjnym w celu ułożenia pytań egzaminacyjnych w ich lokalnym języku, dostosowanych do celów nauki dla każdego modułu.

- Dostawcom szkoleń w celu przygotowania materiałów szkoleniowych i określenia odpowiednich metod nauczania.

- Kandydatom w celu przygotowania się do egzaminu (jako część kursu przygotowującego lub w celu przygotowania samodzielnego).

- Międzynarodowej społeczności zajmującej się inżynierią oprogramowania i systemów w celu rozwijania zawodu testera oprogramowania i systemów, a także jako materiał wyjściowy do książek i artykułów.

ISTQB® może zezwolić innym podmiotom na wykorzystanie niniejszego sylabusa do innych celów, pod warunkiem uzyskania wcześniejszej pisemnej zgody.

1.3 Certyfikowany Tester Oprogramowania - Poziom Ekspercki

Do egzaminu na poziomie eksperckim mogą podchodzić osoby, które osiągnęły poziom zaawansowany w zawodzie testera oprogramowania i które pragną dalej rozwijać swoją wiedzę w określonym obszarze. Moduły dostępne na poziomie eksperckim obejmują szerokie spektrum zagadnień związanych z testowaniem.

Ekspert w dziedzinie testowania jest osobą posiadającą rozległą ogólną wiedzę na temat testowania oraz dogłębne zrozumienie określonego obszaru testowania. Dogłębne zrozumienie definiuje się jako posiadanie wystarczającej wiedzy z zakresu teorii i praktyki testowania umożliwiające umiejętne wpłynięcie na kierunek obierany przez organizację i/lub projekt podczas tworzenia, wdrażania i realizacji procesów testowania.

Aby przystąpić do egzaminu na poziomie eksperckim w zakresie modułu „Doskonalenie procesu testowego”, kandydaci muszą posiadać certyfikat na poziomie zaawansowanym z zakresu zarządzania testami.

Oprócz zdania egzaminu, przed otrzymaniem certyfikatu na poziomie eksperckim, należy przestawić dowód praktycznego doświadczenia w dziedzinie testowania w zakresie ogólnym, a w szczególności w dziedzinie przedstawionej w module z zakresu poziomu eksperckiego. Ponadto zastosowanie mają następujące wymagania:

- co najmniej pięć lat praktycznego doświadczenia w testowaniu (należy przedłożyć CV zawierające dwie referencje)

- co najmniej dwa lata doświadczenia w dziedzinie związanej z danym modułem dla poziomu eksperckiego (należy przedłożyć CV zawierające dwie referencje)

- napisanie i opublikowanie co najmniej jednego referatu LUB przedstawienie prezentacji na temat związany z dziedziną modułu poziomu eksperckiego na konferencji poświęconej testowaniu.

Osoby, które formalnie spełniają kryteria określone powyżej otrzymają oficjalny certyfikat ISTQB poziomu eksperckiego dotyczący określonego modułu. Osoby posiadające certyfikat ISTQB na poziomie eksperckim będą mogły również używać skrótu CTEL (Certyfikowany Tester, Poziom Ekspercki.

Posiadacze certyfikatu na poziomie eksperckim w dziedzinie określonego modułu powinni regularnie odnawiać swoją certyfikację poprzez uzyskiwanie minimalnej ilości punktów w ramach procesu Rozszerzenie Certyfikatu ISTQB [ISTQB-CEP]. Więcej informacji na temat tego procesu znajduje się na stronie [ISTQB-Web].

1.3.1 Poziom Wiedzy

Cele nauki dotyczące każdego rozdziału niniejszego sylabusa są podane na początku każdego rozdziału w celu łatwej identyfikacji.

1.3.2 Egzamin

Wszystkie egzaminy certyfikujące na poziomie eksperckim oparte będą na niniejszym sylabusie oraz module dotyczącym zarządzania testami zawartym w sylabusie dla poziomu zaawansowanego (zwłaszcza Rozdział 8 – „Standardy i Proces Doskonalenia Testowania”), a także sylabusie dla poziomu podstawowego. Odpowiedzi na pytania egzaminacyjne mogą wymagać zastosowania materiału opartego na więcej niż jednym dziale wyżej wymienionych sylabusów.

Format egzaminu zdefiniowany jest przez Wytyczne ISTQB dla Egzaminu na Certyfikowanego Testera Oprogramowania na poziomie Eksperckim [ISTQB-EL-EXAM].

Egzamin można zdawać jako część akredytowanego szkolenia lub indywidualnie (np. w centrum egzaminacyjnym). Egzamin można zdawać w wersji papierowej lub elektronicznej, ale musi być on nadzorowany/obserwowany (przez osobę wyznaczoną przez Radę Krajową lub Komisję Egzaminacyjną).

1.3.3 Akredytacja

Rada Członkowska ISTQB może akredytować dostawców szkoleń, których materiały szkoleniowe zgodne są z niniejszym sylabusem. Dostawcy szkoleń powinni uzyskać wytyczne dotyczące akredytacji od rady lub instytucji akredytującej. Akredytowany kurs uznaje się za zgodny z niniejszym sylabusem i może obejmować egzamin ISTQB jako część kursu.

1.4 Części normatywne i informacyjne

Części normatywne sylabusa są objęte egzaminem. Są to:

- Cele nauki

- Terminologia

- Wymagane ćwiczenia w miejscu pracy

Pozostała część sylabusa ma charakter informacyjny i stanowi rozwinięcie celów nauki.

1.5 Poziom uszczegółowienia

Poziom uszczegółowienia niniejszego sylabusa umożliwia prowadzenie szkoleń i egzaminów w spójny sposób na całym świecie.  Aby osiągnąć ten cel, niniejszy sylabus obejmuje:

- Ogólne cele szkoleniowe opisujące zamysł poziomu eksperckiego

- Cele nauki dotyczące każdego obszaru wiedzy, opisujące wiedzę zdobytą w wyniku procesu nauczania i wykształcony sposób myślenia (elementy normatywne)

- Spis informacji, których należy nauczyć, w tym opis kluczowych pojęć, które mają być przedmiotem nauczania, w tym materiały źródłowe, takie jak zatwierdzona literatura lub normy, a także odniesienia do dodatkowych materiałów źródłowych, jeśli jest to wymagane (elementy informacyjne)

Zawartość sylabusa nie jest opisem całego zakresu wiedzy dotyczącego doskonalenia procesu testowego; sylabus odzwierciedla poziom uszczegółowienia, który należy osiągnąć podczas akredytowanego kursu przygotowawczego do egzaminu na poziomie eksperckim.

1.6 Układ sylabusa

Sylabus podzielony jest na dziesięć rozdziałów głównych. Nagłówek najwyższego poziomu pokazuje czas, jaki należy przeznaczyć na opanowanie treści zawartych w rozdziale. Przykładowo:

2. Kontekst doskonalenia

180 min

pokazuje, że w Rozdziale 2 zaplanowano 180 minut na naukę materiału w nim zawartego. Cele nauki wymienione są na początku każdego rozdziału.

1.7 Terminy i definicje

Wiele terminów stosowanych w literaturze dotyczącej oprogramowania jest używanych zamiennie. Definicje stosowane w sylabusie dla poziomu eksperckiego są dostępne w Standardowym Słowniku Terminów Stosowanych w Testowaniu Oprogramowania, opublikowanym przez ISTQB [ISTQB-Glossary].

Każde ze słów kluczowych wymienionych na początku każdego rozdziału niniejszego sylabusa posiada swoją definicję w glosariuszu ISTQB [ISTQB-Glossary].

1.8 Cele nauki / Poziomy wiedzy (K)

Do niniejszego sylabusa mają zastosowanie wymienione poniżej cele nauki. Każde zagadnienie poruszone w niniejszym sylabusie będzie omawiane według przypisanego mu celu nauki.

Poziom 1: Zapamiętaj (K1)

Kandydat rozpoznaje, zapamiętuje i wymienia terminy lub koncepcje.

Terminologia: Zapamiętaj, wymień, rozpoznaj, poznaj

Przykład

Rozpoznaje definicję „błędu” jako:

- „niewykonanie usługi na rzecz użytkownika końcowego lub dowolnego innego interesariusza” lub

- „faktyczne odstępstwo komponentu lub systemu od oczekiwanego zachowania, usługi lub rezultatu”.

Poziom 2:  Zrozum (K2)

Kandydat potrafi wybrać uzasadnienia lub wyjaśnienia do stwierdzeń odnoszących się do zagadnienia, a także podsumować, rozróżnić, sklasyfikować i podać przykłady popierające fakty (np. porównać terminy), pojęć dotyczących testowania i procedur testowych (wyjaśnienie kolejności zadań).

Terminologia: podsumuj, sklasyfikuj, porównaj, przyporządkuj, znajdź różnice, podaj przykład, zinterpretuj, przetłumacz, przedstaw, wyciągnij wnioski, przydziel do grupy

Przykłady

Wyjaśnij, dlaczego testy należy planować na możliwie najwcześniejszym etapie:

- Aby znaleźć błędy, kiedy usunięcie ich jest mniej kosztowne

- Aby w pierwszej kolejności znaleźć najważniejsze błędy

Wyjaśnij podobieństwa i różnice pomiędzy testowaniem systemowym a integracyjnym:

- Podobieństwa: testowanie więcej niż jednego komponentu, można testować aspekty niefunkcjonalne

- Różnice: testowanie integracyjne skupia się na interfejsach i interakcjach, natomiast testowanie systemowe dotyczy aspektów całości systemu, jak całkowity czas przetwarzania

Poziom 3: Zastosuj (K3)

Kandydat potrafi wybrać poprawne zastosowanie pojęcia lub techniki i zastosować je w danym kontekście. Poziom K3 zwykle dotyczy wiedzy proceduralnej. Na tym poziomie nie występuje działanie twórcze, jak na przykład ewaluacja zastosowania oprogramowania lub stworzenie modelu dla oprogramowania. W przypadku, gdy mamy dany model i omawiamy etapy proceduralne w celu utworzenia przypadków testowych z modelu w sylabusie, mieści się to w zakresie poziomu K3.

Terminologia: wdrożyć, wykonać, użyć, wykonaj procedurę, zastosuj procedurę

Przykład

- Kandydat potrafi zidentyfikować wartości graniczne dla ważnych i nieważnych klas równoważności.

- Zastosuje procedurę ogólną do stworzenia przypadku testowego w celu uzyskania przypadków testowych z danego diagramu przejść stanów w celu pokrycia wszystkich przejść.

Poziom 4: Przeanalizuj (K4)

Kandydat potrafi podzielić informacje dotyczące procedury lub techniki na części składowe w celu lepszego zrozumienia oraz odróżnić fakty od wniosków. Typowym zastosowaniem jest analiza dokumentu, oprogramowania lub sytuacji związanej z projektem oraz zaproponowanie odpowiednich działań w celu rozwiązania problemu lub wykonania zadania.

Terminologia: przeanalizuj, wskaż różnice, wybierz, ustrukturalizuj, ukierunkuj, przyporządkuj, zdekonstruuj, dokonaj ewaluacji, osądź, monitoruj, skoordynuj, stwórz, dokonaj syntezy, wygeneruj, postaw hipotezę, zaplanuj, zaprojektuj, skonstruuj, przedstaw

Przykład

- Przeanalizuj ryzyka produktów i zaproponuj działania zapobiegawcze i naprawcze.

- Opisz, które części raportu incydentów przedstawiają fakty a które są wnioskami opartymi na wynikach.

Poziom 5: Oceń (K5)

Kandydat potrafi dokonywać osądów w oparciu o kryteria i standardy. Wykrywa niespójności lub błędy logiczne w ramach procesu bądź dotyczące produktu, określa czy proces lub produkt są wewnętrznie spójne i wykrywa efektywność procedury w miarę, jak jest implementowana (np. określa czy wnioski naukowca wynikają z zaobserwowanych danych).

Terminologia: dokonaj ewaluacji, skoordynuj, wykryj, monitoruj, wydaj osąd, przedstaw analizę krytyczną.

Przykład

- Osądź czy określony proces przeglądu został w danej sytuacji zastosowany efektywnie i skutecznie.

- Oceń wyniki testów i raporty problemów i zaproponuj interesariuszowi rekomendację czy wymagane jest dalsze testowanie.

- Oceń czy dany zestaw przypadków testowych uzyskał poziom pokrycia.

- Monitoruj działania mające na celu łagodzenie ryzyka, zaproponuj usprawnienia (obejmuje podsumowywanie rezultatów).

Poziom 6: Stwórz (K6)

Kandydat tworzy funkcjonalną lub spójną całość z kilku elementów. Typowym zastosowaniem jest reorganizacja elementów w celu ułożenia ich w nowy wzór lub strukturę, opracowanie procedury dla celów realizacji zadania lub wynalezienie produktu (np. zbudowanie środowiska do określonego celu).

Terminologia: wygeneruj, postaw hipotezę, zaplanuj, zaprojektuj, skonstruuj, przedstaw

Przykład

- Wygeneruj odpowiedni proces zarządzania ryzykiem, który zawiera elementy formalnie wymagane oraz nieformalne.

- Opracuj podejście do testowania dla projektu, które uwzględnia kontekst polityki firmy, projekt/produkt, cele testowania, ryzyko oraz oś czasową w celu sformułowania dynamicznej strategii, która będzie przeciwwagą dla strategii analitycznej.

- Opracuj proces przeglądu z elementów różnych typów przeglądu tak, aby stworzyć efektywny proces dla organizacji.

[Anderson] podaje więcej informacji na temat poziomów poznawczych celów nauki.

1.9 Wymagania

Cele nauki zawarte w niniejszym sylabusie mają na celu umożliwić uczestnikom spełnienie następujących wymagań:

- Udzielanie rad i informacji na temat doskonalenia procesu testowego

- Zagwarantowanie, że wprowadzenie udoskonaleń w procesie testowania w ich organizacji lub projekcie odbywa się w sposób efektywny i ma możliwie największe szanse powodzenia

- Pełnienie roli eksperta w swojej organizacji lub projekcie

Nie chodzi o to, żeby kandydaci, którzy zdobywają kwalifikacje na poziomie eksperckim, byli natychmiast uznawani za „światowych ekspertów” w dziedzinie doskonalenia procesu testowego. Oczekuje się, że wykwalifikowany certyfikowany tester-ekspert (ISTQB CTEL) w dziedzinie Doskonalenia Procesu Testowego będzie w stanie zapewnić wsparcie eksperckie, tak aby zainicjalizować, wdrożyć i wspierać doskonalenie procesu testowego w swojej organizacji lub projekcie.

2. Kontekst doskonalenia                         285 min.

Terminologia:

Cykl Deminga, model doskonałości EFQM, IDEAL, jakość w oparciu o wytwarzanie, jakość w oparciu o produkt, spotkanie retrospektywne, cykl życia oprogramowania, doskonalenie procesu tworzenia oprogramowania (SPI), standard, narzędzie testowe, zarządzanie przez jakość (TQM), jakość w oparciu o przekraczanie oczekiwań, jakość w oparciu o użytkownika, jakość w oparciu o wartość

Cele nauki dla rozdziału „Kontekst Doskonalenia”:

2.1 Dlaczego należy doskonalić proces testowy?

2.1.1      (K2) Kandydat portrafi podać przykłady typowych powodów doskonalenia procesu testowania oprogramowania.

2.1.2      (K2) Kandydat potrafi podać różnice pomiędzy doskonaleniem procesu testowego, a innymi celami i inicjatywami dotyczącymi procesu doskonalenia.

2.1.3      (K6) Kandydat potrafi sformułować w sposób zrozumiały dla wszystkich interesariuszy powody sugerowanych usprawnień procesu testowego; pokazać, w jaki sposób powody te połączone są z celami biznesowymi i wyjaśnić je w kontekście innych udoskonaleń procesów.

2.2 Co można udoskonalić?

2.2.1       (K2) Kandydat rozumie różne aspekty testowania, oraz inne powiązane aspekty, które mogą zostać udoskonalone.

2.3 Poglądy dotyczące jakości

2.3.1       (K2) Kandydat potrafi porównać różne poglądy dotyczące jakości.

2.3.2       (K2) Kandydat potrafi pokazać związki różnych poglądów dotyczących jakości z testowaniem.

2.4 Ogólny proces doskonalenia

2.4.1       (K2) Kandydat rozumie etapy cyklu Deminga.

2.4.2       (K2) Kandydat potrafi porównać dwie metody ogólne (cykl Deminga i model IDEAL) dotyczące doskonalenia procesów.

2.4.3      (K2) Kandydat potrafi podać przykłady dla każdej z podstawowych koncepcji doskonałości w odniesieniu do doskonalenia procesu testowego.

2.5 Przegląd podejść do procesu doskonalenia

2.5.1      (K2) Kandydat potrfi porównać cechy podejścia opartego na modelach z podejściami analitycznym i hybrydowym.

2.5.2      (K2) Kandydat rozumie konieczność stosowania podejścia hybrydowego.

2.5.3      (K2) Kandydat rozumienie potrzebę rozwijania kompetencji społecznych i potrafi wyjaśnić doskonalenie w zatrudnianiu, szkoleniu, doradzaniu i instruowaniu personelu testowego.

2.5.4      (K2) Kandydat rozumie sposób, w jaki wprowadzenie narzędzi testowych może usprawnić różne części procesu testowego.

2.5.5      (K2) Kandydat rozumie, na jakie inne sposoby można podejść do idei doskonalenia, na przykład, poprzez zastosowanie przeglądów okresowych podczas cyklu życia oprogramowania, poprzez zastosowanie podejść do testowania uwzględniających cykle doskonalenia (np. retrospektywy projektu w metodologii SCRUM), poprzez przyjęcie standardów, a także poprzez skoncentrowanie się na zasobach takich jak środowiska testowe i dane testowe.

2.1 Dlaczego należy doskonalić proces testowy?

Budowanie systemów, w których oprogramowanie jest dominującym elementem stawia coraz większe wymagania. Systemy takie odgrywają  coraz większą rolę w społeczeństwie. W coraz szerszym zakresie dostępne są nowe metody, techniki oraz narzędzia, które mają na celu zapewnienie wsparcia dla tworzenia oprogramowania i zadań związanych z jego utrzymaniem i pielęgnacją. Ponieważ oprogramowanie odgrywa istotną rolę w naszym życiu zarówno pod względem ekonomicznym jak i społecznym, na dziedzinę inżynierii oprogramowania wywierana jest presja zwrócenia większej uwagi na zagadnienia jakościowe. Niskiej jakości oprogramowanie nie jest już społecznie akceptowalne. Błędy oprogramowania mogą doprowadzić do poważnych strat finansowych, a nawet przyczynić się do katastrofy, np. utraty życia przez ludzi.

Doskonalenie procesu testowego powinno odbywać się w kontekście:

- aktualnych wyzwań biznesowych i organizacyjnych,

- wyzwań związanych z pielęgnacją aktualnie dostarczanych systemów,

- bieżących wyzwań związanych z testowaniem i zapewnieniem jakości.

W tym kontekście gwałtownie rośnie znaczenie dziedziny testowania, jako jednego z wielu dostępnych środków mających na celu zapewnianie jakości. Nierzadko w ramach projektu znaczna część budżetu przeznaczona jest na testowanie.

Każdego dnia przed organizacjami pojawiają się coraz to wyższe wymagania biznesowe, jak np. coraz krótszy czas na wprowadzenie produktu do sprzedaży, wyższa jakość i niezawodność przy obniżonych kosztach. Projektujemy i wytwarzamy coraz więcej produktów, w związku, z którymi przeważająca część kosztów ich opracowania dotyczy oprogramowania.  Jednocześnie możliwe jest tworzenie oprogramowania przez podmioty zewnętrzne lub we współpracy z innymi podmiotami w wielu lokalizacjach. Wraz z tendencją do zwiększonego ponownego wykorzystania i stosowania architektury platformowej, integracja i testowanie stają się kluczowymi działaniami mającymi bezpośredni wpływ nie tylko na jakość produktu, ale również na sprawne i skuteczne przeprowadzenie całego procesu projektowania i wytwarzania. Testerzy mogą testować oprogramowanie, produkty będące połączeniem oprogramowania i sprzętu, bądź też produkty będące połączeniem oprogramowania z innymi produktami w wielu różnych mediach.

Rola i rozmiar oprogramowania są coraz większe. Ilość oprogramowania w produktach konsumenckich podwaja się w przybliżeniu co 24 miesiące. To samo dotyczy złożoności aplikacji profesjonalnych. Poziom skomplikowania oprogramowania ma bezpośredni wpływ na ilość błędów na „jednostkę” oprogramowania (np. punkty funkcyjne). Ponieważ rynek wymaga coraz lepszych i bardziej niezawodnych produktów, zaprojektowanych i wytworzonych w krótszym czasie i przy ograniczonym budżecie, wyższa skuteczność i sprawność testowania nie są już tylko opcją a niezbędną częścią składową powodzenia.

Dostarczane systemy obejmują też inne produkty i usługi oraz kod programu. System może również obejmować sprzęt komputerowy, oprogramowanie warstwy pośredniej i oprogramowanie firmowe (firmware). W niektórych przypadkach, dostarczona usługa może obejmować nowe budynki, zmiany będących w użyciu praktyk oraz nową infrastrukturę. W rezultacie, dla całej organizacji testowanie może rozszerzyć się na ostatnie przygotowania przed przeniesieniem i na pierwsze dni funkcjonowania w nowej siedzibie.

Testowanie w swoim zakresie nie ogranicza się wyłącznie do oprogramowania. Co więcej, kupujący i korzystający z oprogramowania nie potrzebują jedynie kodu, ale też usług i produktów, takich jak procesy biznesowe, szkolenia, instrukcje użytkowania oraz wsparcie. Doskonalenie procesu testowego musi odbywać się w kontekście bardziej ogólnych celów dotyczących jakości – niezależnie od tego czy są to cele organizacji, jednej lub kilku organizacji konsumenckich bądź jednego lub kilku grup/zespołów IT.

Kontekst, w którego ramach ma miejsce doskonalenie procesu testowego obejmuje każdy przypadek doskonalenia procesu biznesowego/organizacyjnego a także doskonalenia procesu IT lub procesu tworzenia oprogramowania.

Typowe powody usprawnień biznesowych, które mają wpływ na testowanie, to:

- Firma posiada usługę testowania, która zapewnia wysokiej jakości podejście inżynierskie, które jest zbyt czasochłonne. Jeśli celem jest skrócenie czasu wprowadzenia produktu na rynek, ale konieczne jest zachowanie wysokiej jakości, działania z zakresu doskonalenia procesu testowego mogą koncentrować się na:

- Ograniczeniu czasu przeznaczonego na testowanie poprzez zwiększenie szybkości testowania bez zmniejszenia jego skuteczności

- Zwiększeniu aktywności na wcześniejszym etapie testowania (np. testowaniu statycznym) w celu ograniczenia czasu potrzebnego na naprawienie błędów na późniejszym etapie cyklu życia oprogramowania

- Konieczność poprawy jakości produktów w przypadku, gdy wydłużony czas i zwiększony koszt testowania mogą być uzasadnioną ceną w zamian za wyższą jakość.

- Chęć podniesienia umiejętności testerów w celu zapewnienia przewidywalności i lepszego raportowania.

- Obowiązek dla organizacji zapewniających zewnętrzne wsparcie w celu spełnienia wymagań klientów w stosunku do swoich dostawców, aby znajdowali się oni na określonym poziomie dojrzałości organizacyjnej,

- Konieczność oszczędzenia pieniędzy poprzez ograniczenie kosztów testowania.

- Chęć ograniczenia całkowitego czasu realizacji projektu poprzez zintegrowanie testowania z procesem tworzenia oprogramowania

- Chęć ograniczenia kosztów niepowodzenia przez usprawnienie procesu testowego

- Konieczność wykazania zgodności z odpowiednimi normami (Dział 2.5.4.5)

Doskonalenie procesu testowego może odbywać się w kontekście doskonalenia organizacyjnego i biznesowego. Procesem tym można zarządzać z wykorzystaniem:

- Zarządzania przez Jakość (TQM)

- Normy ISO 9000:2000

- Modelu doskonałości, jak np. Model Doskonałości Europejskiej Fundacji Zarządzania  Jakością (EFQM) ™ lub równoważnego

- Six Sigma

Doskonalenie procesu testowego może odbywać się w kontekście doskonalenia procesów IT lub procesu tworzenia oprogramowania. Procesem tym można zarządzać z wykorzystaniem:

- Zintegrowanego Modelu Dojrzałości Organizacyjnej (CMMI®) (Dział 3.2.1).

- Normy ISO/IEC 15504 (Dział 3.2.2)

- ITIL® [ITIL], [ITIL2]

- Zespołowego Procesu Tworzenia Oprogramowania (TSP)SM i Personalnego Procesu Tworzenia Oprogramowania (PSP)SM [Humphrey]

2.2 Co można udoskonalić?

Doskonalenie procesu tworzenia oprogramowania (SPI) to ciągłe podnoszenie jakości produktu, skuteczności i sprawności procesów, prowadzące do lepszej jakości oprogramowania.

Doskonalenie procesu testowego to ciągłe podnoszenie skuteczności i/lub sprawności procesu testowego w kontekście ogólnego procesu tworzenia oprogramowania. Kontekst ten oznacza, że ulepszenia procesu testowego mogą wykraczać poza sam proces testowy, na przykład, rozszerzyć się na infrastrukturę, organizację i umiejętności testerów. Ponadto, udoskonalenia procesu testowego mogą wskazywać, że obszar zarządzania wymaganiami i inne części procesu tworzenia oprogramowania potrzebują podobnych lub dodatkowych udoskonaleń. I odwrotnie, udoskonalenia procesu testowego mogą opierać się na ogóle działań z zakresu doskonalenia procesu tworzenia oprogramowania.

Cele testowania zawsze muszą być zgodne z celami biznesowymi. Dla organizacji lub projektu osiągnięcie maksymalnych poziomów dojrzałości procesu testowego nie zawsze jest optymalnym rozwiązaniem.

2.3 Poglądy dotyczące jakości

W jendym projekcie można stosować kilka definicji jakości, być może bez świadomości i wiedzy wszystkich osób biorących udział w projekcie. Ważne jest, aby zdawać sobie sprawę, że nie istnieje „właściwa” definicja jakości. W przypadku doskonalenia procesu testowego należy rozważyć, który z poglądów dotyczących jakości przedstawionych w niniejszym rozdziale jest najbardziej stosowny dla organizacji.

Trienekens i van Veenendaal [Trienekens, van Veenendaal 97] wyjaśniają, wraz z przykładami, pięć różnych punktów widzenia dotyczących jakości, w oparciu o referat Davida Garvina [Garvin Paper 84]. Są to:

- produkt,

- wytwarzanie,

- użytkownik,

- wartość,

- przekraczanie oczekiwań.

Jeśli chodzi o typy, poziomy i techniki, które mogą być użyte w trakcie procesu testowego, poglądy dotyczące jakości mogą zostać określone w trakcie testowania dynamicznego i statycznego poprzez wykorzystanie ról i reprezentatywnych punktów widzenia [przykład - Evans04].

Sposób, w jaki definiujemy „jakość” w odniesieniu do konkretnego produktu, usługi lub projektu zależy od kontekstu. W różnych gałęziach przemysłu funkcjonują różne poglądy dotyczące jakości. Produkty mające bezpośredni wpływ na bezpieczeństwo wymagają podkreślenia definicji jakości z punktu widzenia produktu i wytwarzania. Produkty służące rozrywce i gry wymagają definicji z punktu widzenia użytkownika, a także cech produktu nie branych pod uwagę w innych branżach – na przykład „Poziom zadowolenia” jako część użyteczności produktu. Oprogramowanie sprzedawane jako innowacyjny nowy produkt wymaga definicji opartej o wartość, ponieważ jeżeli więcej czasu przeznaczone będzie na uzyskanie lepszego produktu, można przegapić termin wprowadzenia go na rynek. W przypadku większości oprogramowania komercyjnego lub niestandardowego, najlepszym rozwiązaniem dla klienta jest zrównoważenie różnych aspektów jakości. W przypadku takich produktów należy się zapytać samego siebie: jaka jest największa liczba lub poziom atrybutów (jakość w oparciu o produkt), które możemy zapewnić w celu wsparcia zadań użytkownika (jakość w oparciu o użytkownika) przy zapewnieniu najlepszego bilansu kosztów i korzyści (jakość w oparciu o wartość), realizując powtarzalne procesy o zagwarantowanym poziomie jakości w ramach zarządzanego projektu (jakość w oparciu o wytwarzanie)?

Metryki, które mogą być powiązane z poglądami dotyczącymi jakości, o których mowa powyżej, omówione są w Rozdziale 4, Metody analityczne, i Rozdziale 6, Proces doskonalenia.

2.4 Ogólny proces doskonalenia

2.4.1 Cykl Deminga

Ciągłe doskonalenie oznacza wyznaczanie celów doskonalenia, podejmowanie kroków w celu ich osiągnięcia, a kiedy wyznaczone cele zostały osiągnięte – wyznaczenie nowych celów doskonalenia. Dla potwierdzenia tej koncepcji opracowano modele ciągłego doskonalenia.

Cykl Deminga jest użytecznym ogólnym schematem ilustrującym zasadę ciągłego doskonalenia i składa się z następujących etapów:

- Planowanie: cele są zdefiniowane dla cech jakości, kosztów i poziomów usług. Cele mogą początkowo być formułowane przez zarząd jako cele doskonalenia biznesowego i sukcesywnie rozbijane na pojedyncze „punkty kontrolne”, które powinny być sprawdzane (patrz niżej), aby upewnić się czy czynności zostały wykonane. Zdefiniowane cele powinny być mierzalne (więcej informacji zawiera Dział 4.4). Wykonywana jest analiza bieżących praktyk i umiejętności, po czym opracowuje się plany naprawcze w celu ulepszenia procesu testowego.

- Wykonanie: Po sporządzeniu planów, wykonywane są określone czynności. Etap ten obejmuje inwestycje w zasoby ludzkie, (np. szkolenie i coaching).

- Sprawdzenie: Punkty kontrole określone na etapie planowania są sprawdzone przy użyciu szczegółowych metryk a odstępstwa są notowane. W ramach każdej metryki można przewidzieć odstępstwa w odniesieniu do konkretnego okresu czasu i porównać z rzeczywistymi obserwacjami, aby udzielić informacji na temat różnic między oczekiwanymi a faktycznymi wynikami.

- Działanie (czasem nazywany „Analiza/Działanie”): Przy użyciu zebranych informacji określane i priorytetyzowane są możliwości usprawnienia wydajności.

Na pierwszych dwóch etapach („Planowanie” i „Wykonanie”) w centrum zainteresowania znajduje się wyczucie tego, co najważniejsze. Na dwóch kolejnych etapach, („Sprawdzenie” i „Działanie”) najczęściej używa się metod statystycznych i technik analizy systemów, aby umożliwić ustalenie statystycznego znaczenia, zależności i kolejnych obszarów doskonalenia.

2.4.2 Model doskonalenia IDEAL

Model doskonalenia IDEAL [IDEAL 96] jest dookreśleniem cyklu Deminga, o którym mowa powyżej. Przedstawia on strukturę doskonalenia obejmującą wymienione poniżej etapy i podetapy, które mogą być zastosowane w trakcie doskonalenia procesu testowego.

- Rozpoczęcie (Initiating)

- Określenie powodu doskonalenia

- Ustalenie kontekstu i zapewnienie sponsorowania

- Ustanowienie infrastruktury doskonalenia

- Diagnoza (Diagnosing)

- Ocena i charakterystyka bieżącej praktyki

- Opracowanie rekomendacji i dokumentowanie rezultatów etapu

- Ustanawianie (Establishing)

- Ustalenie strategii i priorytetów

- Założenie grupy zajmującej się procesem testowym (patrz Sekcja 7.1.1)

- Zaplanowanie działań

- Działanie (Acting)

- Zdefiniowanie procesów i miar

- Zaplanowanie i wykonanie działań pilotażowych

- Zaplanowanie, wykonanie i monitorowanie instalacji

- Nauka (Learning)

- Dokumentowanie i analiza zdobytego doświadczenia

- Korekta podejścia organizacyjnego

2.4.3 Podstawowe koncepcje doskonałości

Podstawowe koncepcje doskonałości wykorzystywane są na całym świecie w modelach doskonałości organizacyjnej do celu wykonania oceny organizacji według ośmiu kryteriów wymienionych poniżej. Europejska Fundacja Zarządzania Jakością (EFQM) podaje przykład dostępny na stronie [EFQM-Web], a bibliografia załączona do niniejszego sylabusa zawiera odniesienia do równoważnych modeli stosowanych poza Europą.

Podstawowe koncepcje doskonałości, (jak opisano na stronie [EFQM-Web]), są następujące:

- Zorientowanie na wyniki: „Doskonałość zależy od zrównoważenia i zaspokojenia potrzeb wszystkich stosownych interesariuszy (termin ten obejmuje pracowników, klientów, dostawców i w ogólnym sensie społeczeństwo, a także podmioty posiadające finansowe udziały w organizacji).”

- Ukierunkowanie na klienta: „Klient jest ostatecznym sędzią jakości produktu i usługi, a lojalność klienta i jego utrzymanie, a także wzrost udziału w rynku są najlepiej optymalizowane poprzez wyraźne ukierunkowanie na potrzeby aktualnych i przyszłych klientów.”

- Przywództwo i niezmienność celu: „Postępowanie przywódców organizacji tworzy jasność i jedność celu wewnątrz organizacji i środowisko, w którym organizacja i jej pracownicy mogą przodować.”

- Zarządzanie przez procesy i fakty: „Organizacje działają efektywniej, jeśli wszystkie wzajemnie powiązane działania są rozumiane i systematycznie zarządzane a decyzje dotyczące bieżących działań są zaplanowane. Udoskonalenia są wprowadzane przy użyciu rzetelnych informacji uwzględniających spostrzeżenia interesariuszy.”

- Rozwój i zaangażowanie kadr: „Pełen potencjał kadr organizacji uwalnia się przez wspólnie podzielane wartości oraz kulturę zaufania i stwarzania możliwości, co sprzyja zaangażowaniu wszystkich.”

- Ciągła nauka, innowacja i doskonalenie: „Działalność organizacji przynosi najlepsze wyniki, kiedy oparta jest na zarządzaniu wiedzą i dzieleniu się nią w kulturze ciągłej nauki, innowacji i doskonalenia.”

- Rozwój partnerstwa: „Organizacja funkcjonuje bardziej efektywnie, kiedy funkcjonują w niej wzajemnie korzystne relacje, zbudowane na zaufaniu, dzieleniu się wiedzą i integracji z jej partnerami.”

- Społeczna odpowiedzialność biznesu: „Długofalowym interesom organizacji i jej pracowników najlepiej sprzyja przyjęcie etycznego podejścia oraz przekraczanie oczekiwań i przepisów ogółu społeczeństwa.”

Inne inicjatywy dotyczące doskonałości i jakości organizacji, takie jak Six Sigma i Zrównoważona Karta Wyników również zapewniają sposób dyskutowania na temat celów dla organizacji, podejmowania decyzji dotyczących sposobu osiągnięcia tych celów i sprawdzania, czy zostały osiągnięte.

2.5 Przegląd podejść do doskonalenia

2.5.1 Przegląd podejść opartych na modelach

W celu podniesienia jakości produktów, branża tworzenia oprogramowania skoncentrowała się na doskonaleniu stosowanych procesów jego produkcji. Wytyczne, które są szeroko używane w celu ulepszenia procesu produkcji oprogramowania zawiera Model Dojrzałości Organizacyjnej. Model Dojrzałości Organizacyjnej (CMM®), jego kolejna wersja, Zintegrowany Model Dojrzałości Organizacyjnej(CMMI), a także ISO/IEC 15504 są często uznawane za standardy dotyczące doskonalenia procesu tworzenia oprogramowania.

Pomimo faktu, że testowanie może stanowić znaczną część budżetu projektu, różne modele doskonalenia procesu tworzenia oprogramowania, jak np. CMMI, poświęcają testowaniu niewiele uwagi. W odpowiedzi na taki stan rzeczy, społeczność testerów stworzyła uzupełniające modele doskonalenia.

Sylabus ISTQB dla poziomu zaawansowanego definiuje doskonalenie procesu testowego jako jeden z kluczowych obszarów w zawodzie testera i przedstawia dwa podstawowe podejścia oparte na modelach:

- Modele procesów definiują ogólne najlepsze praktyki testowania i określają, w jaki sposób udoskonalić różne aspekty testowania w zalecany stopniowy sposób. Przykładami są model Doskonalenia Procesu testowego (TPI Next®) oraz Zintegrowany Model Dojrzałości Testowej (TMMi®). Oba modele zostały opisane w Dziale 3.3. Sylabus ISTQB dla poziomu zaawansowanego opisuje też inne, rzadziej stosowane modele.

- Modele oparte na treści są nienormatywne; nie wymagają, aby udoskonalenia występowały w określonej kolejności. Zamiast tego, modele te definiują określone działania mogące przynieść korzyści dla procesu testowego, jeśli zostaną właściwie zastosowane. Proces systematycznego testowania i oceny (STEP) oraz Krytyczny Proces testowy (CTP) to dwa najważniejsze przykłady tego podejścia. Oba są opisane w Dziale 3.4.

2.5.2 Przegląd podejść analitycznych

Podejścia analityczne zwykle uwzględniają analizę określonych miar w celu oceny aktualnej sytuacji w procesie testowym, podjęcia decyzji dotyczących tego, jakie działania doskonalące podjąć i jak ocenić ich wpływ na proces testowy. Podejście Cel-Pytanie-Miara (GQM) stanowi typowy przykład podejścia analitycznego i zostało opisane w Dziale 4.3.

Podejścia analityczne dokładniej przedstawiono w Rozdziale 4.

2.5.3 Podejścia hybrydowe

Można zastosować podejście hybrydowe, w którym projekty, których rozwój osiągnął wcześniej wyższy poziom dojrzałości procesowej (z zastosowaniem podejść opartych na modelach, podejść analitycznych lub mieszanki obu z wyżej wymienionych), wykorzystuje się do ustalenia i pomiaru celów doskonalenia dla innych projektów.  Jest to zdroworozsądkowe podejście gwarantujące, że najlepsze praktyki, które sprawdzają się w danej organizacji mogą być przeniesione do innych podobnych projektów bez konieczności całkowitego polegania na predefiniowanych dobrych praktykach standardowego modelu procesów (patrz Dział 3.3).

2.5.4 Inne podejścia do doskonalenia procesu testowego

Proces testowy można udoskonalić poprzez skoncentrowanie się na poszczególnych aspektach opisanych poniżej. Aspekty te również opisano w kontekście metod, o których mowa w Dziale 2.5.1.

2.5.4.1 Doskonalenie procesu testowego poprzez rozwijanie umiejętności

Doskonalenie procesu testowego można wspierać poprzez zapewnienie lepszego zrozumienia, wiedzy i umiejętności osobom i zespołom wykonującym testy, kierującym testami lub podejmującym decyzje na podstawie testowania. Mogą to być testerzy, kierownicy testów, programiści i inni członkowie zespołów IT, inni menadżerowie, użytkownicy, klienci, audytorzy i inni interesariusze.

Poprawę umiejętności i kompetencji można zapewnić dzięki szkoleniom, sesjom uświadamiającym, mentoringowi, coachingowi, nawiązywaniu współpracy z grupami koleżeńskimi, wykorzystaniu repozytoriów zarządzania wiedzą, czytaniu i innym działaniom edukacyjnym.

Poziomy umiejętności mogą być związane ze ścieżkami kariery i awansu zawodowego, na przykład SFIA (Model Umiejętności w Erze Informacyjnej) [SFIA-Web].

Umiejętności i kompetencje, które należy udoskonalić, mogą mieścić się w zakresie testowania, innych umiejętności technicznych związanych z technologią informacyjną, umiejętności kierowniczych, umiejętności miękkich, bądź umiejętności związanych z daną dziedziną. Na przykład:

- Wiedza z zakresu testowania – zasady testowania, techniki, narzędzia, itd.

- Wiedza z zakresu inżynierii oprogramowania – oprogramowanie, wymagania, narzędzia do tworzenia oprogramowania, itd.

- Znajomość dziedziny – proces biznesowy, charakterystyka użytkownika, itd.

- Umiejętności miękkie – komunikacja, skuteczne sposoby pracy, raportowania, itd.

Umiejętności potrzebne doskonalącym proces testowy opisano dokładniej w Dziale 7.3. Niemniej jednak, opisane tam umiejętności są potrzebne nie tylko w zespole doskonalącym, ale w całym zespole testowym, zwłaszcza starszym testerom i kierownikom testów.

Zespoły zajmujące sie doskonaleniem powinny skoncentrować się na:

- Zwiększeniu świadomości korzyści i ograniczeń zadań testowych / ulepszeń testów dla procesu tworzenia oprogramowania i dla biznesu

- Zwiększeniu poziomu wiedzy i umiejętności w celu zapewnienia wsparcia dla działań w istniejących lub poprawionych procesach testowych

- Zwiększeniu kompetencji jednostek, aby umożliwić im wykonywanie zadań

- Ustaleniu jasno określonych ról i obowiązków związanych z testowaniem

- Poprawieniu korelacji pomiędzy zwiększaniem kompetencji i nagrodami, uznaniem i awansem zawodowym

- Motywowaniu pracowników

2.5.4.2 Doskonalenie procesu testowego poprzez zastosowanie narzędzi

Poprawę procesu testowego można osiągnąć przez udane wprowadzenie narzędzi. Poprawa taka może dotyczyć efektywności, skuteczności, jakości, bądź wszystkich tych obszarów. Na przykład:

- Narzędzia do zarządzania testami ujednolicają praktyki dotyczące dokumentacji przypadków testowych i rejestrowania błędów

- Narzędzia badające pokrycie kodu wspierają wdrożenie kryteriów wyjściowych na poziomie jednostkowym

Narzędzia do testowania są wdrażane z zamiarem zwiększenia efektywności testowania, zwiększenia kontroli nad testowaniem lub poprawienia jakości produktów. Wdrażanie narzędzi do testowania nie jest sprawą błahą. Powodzenie wdrożenia zależy od wybranego narzędzia, które ma coś konkretnego ulepszyć, oraz od procesu doskonalenia z użyciem narzędzi, które dobrze spełniają swoje zadanie. Zagadnienia te omówione zostały w sylabusach ISTQB dla poziomu podstawowego i zaawansowanego.

Zakres, zróżnicowanie i obszary zastosowania narzędzi do testowania znacznie rozszerzyły się w ostatnich latach. Badając możliwe usprawnienia procesów w dowolnej części procesu testowego i na każdym etapie cyklu życia oprogramowania, organizacja doskonaląca proces testowy powinna rozważyć czy wprowadzenie narzędzi do testowania przyczyni się do poprawy tego procesu. Przez analogię z CASE (Komputerowo Wspomagana Inżynieria Oprogramowania), CAST (Komputerowo Wspomagane Testowanie Oprogramowania) obejmuje różne dostępne narzędzia testowe, sklasyfikowane według zastosowania i platformy. Wykorzystanie takich narzędzi może często przynieść znaczącą poprawę produktywności procesu testowego.

Doskonalący proces może korzystać z narzędzi w celu wsparcia gromadzenia, analizy i raportowania danych, z uwzględnieniem wykonywania analiz statystycznych i modelowania procesów. Nie zawsze są to narzędzia do testowania.

Zadaniem zespołów doskonalących jest:

- Wybór i wdrożenie narzędzi w celu wsparcia działań zespołu doskonalącego, na przykład, narzędzi statystycznych oraz narzędzi służących do modelowania procesów.

- Wybór narzędzi zapewniających odpowiednie wsparcie dla określonego usprawnienia, na przykład narzędzi do analizy statycznej służących do oceny jakości kodu w trakcie testowania statycznego prowadzonego przez programistę.

- Usprawnienie procesu wyboru i wdrożenia narzędzia lub narzędzi, na przykład, po zakończeniu analizy przyczyn problemów występujących podczas fazy pilotażowej wdrożenia narzędzia lub narzędzi.

2.5.4.3 Doskonalenie procesu testowego w różnych podejściach do testowania

Etap zamknięcia testów jest jednym z najważniejszych etapów, podczas których może mieć miejsce retrospektywa projektu lub przegląd zdobytych doświadczeń.

Zastosowanie cykli ciągłego doskonalenia jest główną częścią wielu metod doskonalenia. Zarówno sekwencyjne jak i iteracyjne cykle życia mogą obejmować przeglądy powdrożeniowe, przeglądy na zakończenie etapu, spotkania dotyczące zdobytych doświadczeń, a także inne możliwości gromadzenia informacji o wynikach i wdrażania ulepszeń.

W metodykach iteracyjnych z krótkimi iteracjami (np. w metodykach zwinnych) cykle uzyskiwania informacji zwrotnych będą mieć miejsce z większą częstotliwością, dlatego też możliwości wdrożenia ulepszeń jest więcej. Na przykład, modele cyklu zwinnego tworzenia oprogramowania takie jak SCRUM wymagają cykli ciągłego doskonalenia jako części normalnych wejść procesu projektowego, z retrospektywą projektu i doskonaleniem procesów (w tym procesu testowego) na zakończenie każdej iteracji („sprintu”).

W testowaniu eksploracyjnym po każdej sesji testowania następuje ocena tego, jak najkorzystniej będzie ukierunkować testowanie, co uwzględnia cykl doskonalenia na zakończenie każdej sesji.

W skryptowym lub ustrukturalizowanym podejściu do testowania wysiłek włożony w sporządzenie strategii/planu/skryptów może osłabiać chęć do wdrażania ulepszeń w trakcie projektu testowego. Niemniej jednak, możliwe jest częstsze odbywanie przeglądów zdobytych doświadczeń lub innego przeglądu procesów i wykorzystanie ich do ponownego nakierowania i udoskonalenia procesu testowego. W szczególności, stosując podejście oparte na ryzyku, konieczna będzie zmiana (ulepszenie) testów opartych na ryzyku, aby odnieść się do nowych/zmienionych rodzajów ryzyka, jako że ryzyka biznesowe, ryzyka produktowe i projektowe ulegają zmianom w trakcie cyklu życia systemu.

2.5.4.4 Doskonalenie procesu testowego związane z przyjęciem standardów i regulacji

Doskonalenie procesów może być podyktowane standardami i regulacjami. Na przykład, wymogi standardów podyktowanych przez dziedzinę, takich jak Amerykańskiej Agencji ds. Żywności i Leków (FDA) lub regulacje takie, jak Ustawa Sarbanes-Oxley (sektor finansowy), mogą oznaczać, że wymagane są określone udoskonalenia w celu umożliwienia wykonywania pracy w tej dziedzinie.

Przestrzeganie standardów może być wymagane z powodów prawnych, regulacyjnych lub handlowych, lub w celu usprawnienia komunikacji pomiędzy zespołami, organizacjami, lub ponad granicami państw. Standardy mogą być również wykorzystywane do ustanawiania lub wykonywania pomiaru wewnętrznych procesów firmy i usprawnień w odniesieniu do wzorców ustanowionych przez inne organizacje.

Organizacje zajmujące się doskonaleniem procesu testowego mogą wprowadzić udoskonalenia poprzez wybór stosownych standardów (szczegółowe informacje na ten temat zawiera sylabus ISTQB dla poziomu zaawansowanego) oraz specyfikację sposobu korzystania ze standardów. Na przykład, standard może być wykorzystany do następujących celów :

- Do osiągnięcia zgodności i wskutek tego spełnienie wymogów audytu

- Jako wzorzec pomiarowy w celu porównania z innymi organizacjami

- Jako źródło pomysłów i przykładów mających wspierać dokonywanie wyborów w procesie doskonalenia

- Jako źródło ustandaryzowanych praktyk, które mogą zapewnić lepszą międzyperacyjność systemów i procesów w zmieniającej się sieci firm współpracujących

- Jako model procesu zmian

2.5.4.5 Doskonalenie procesu testowego skoncentrowane na określonych zasobach

Zarządzanie środowiskiem testowym, danymi testowymi, a także innymi zasobami technicznymi może być poza kontrolą zespołu testowego. Jeśli obszary te uważane są za centrum zainteresowania procesu doskonalenia, zespoły kontrolujące ww. zasoby będą musiały włączyć się w proces doskonalenia.

Procesy wymagane do ustanowienia i zarządzania środowiskiem testowym obejmują:

- Definicję wymagań dla środowiska

- Plan, budowę i weryfikację/test środowiska

- Odbiór środowiska

- Proces wdrożenia

- Planowanie wydajności

- Konfigurację i zarządzanie zmianą dla środowiska

- Procesy kontroli dostępu

- Rezerwację/Sporządzanie harmonogramu dotyczącego środowisk wewnątrz zespołów i pomiędzy zespołami

- Wycofanie/demontaż środowiska

Procesy wymagane w celu wsparcia projektu, pozyskania i zarządzania danymi testowymi obejmują:

- Analizę i projektowanie testów

- Implementowanie testów

- Procesy tworzenia kopii zapasowej, przywracania i archiwizowania

- Zarządzanie konfiguracją i zmianą w odniesieniu do określonych zbiorów danych

- Stosowne procedury bezpieczeństwa danych (może być wymagane przepisami prawa)

Udoskonalenia wymagane na poziomie organizacyjnym w odniesieniu do zasobów takich jak środowiska i dane mogą obejmować żądania obniżenia kosztów i ograniczeń zużycia energii, aby spełnić cele odpowiedzialności społecznej i ochrony środowiska dotyczące organizacji. Cele te mogą zostać zrealizowane przez efektywność wdrożenia i wykorzystywania środowisk oraz, przykładowo, wirtualizację środowisk.

Niektóre modele procesów (patrz Dział 3.3) otwarcie uwzględniają te zasoby w ocenie i rekomendacjach, ale jeśli na przykład stosowane jest podejście analityczne, takie jak analiza przyczyn źródłowych (patrz Rozdział 4), zasoby te mogą zostać uwzględnione jako czynniki, które należy wziąć pod uwagę.

Zespoły doskonalenia powinny skupić się na wymienionych poniżej kwestiach w odniesieniu do zasobów:

- Zidentyfikowanie obszarów doskonalenia będących poza kontrolą zespołu testowego

- Nawiązanie współpracy z zespołami ds. kontroli, poprzez eskalację za pośrednictwem kierownictwa, jeśli istnieje taka potrzeba

- Nawiązanie współpracy z zespołami nie zajmującymi się testowaniem w celu skoordynowania ulepszeń

- Identyfikacja i wdrożenie udoskonaleń wewnątrz zespołu testowego oraz w innych zespołach testujących w celu zapewnienia zasobów i zarządzania nimi

3. Doskonalenie oparte na modelach                  570 minut

Terminologia:

CTP, CMMI, reprezentacja ciągła, GQM, poziom dojrzałości, doskonalenie procesu tworzenia oprogramowania, reprezentacja etapowa, STEP, TPI, TMMi, model oparty o zawartość, model procesu

Cele nauki dla rozdziału „Doskonalenie oparte na modelach”:

3.1 Wprowadzenie do podejść opartych na modelach

3.1.1      (K2) Kandydat rozumie atrybuty modelu doskonalenia procesu testowego z najbardziej istotnymi atrybutami ogólnymi.

3.1.2      (K2) Kandydat potrafi porównać podejście etapowe i ciągłe z uwzględnieniem ich zalet i wad.

3.1.3      (K2) Kandydat potrafi podsumować założenia przyjmowane w związku z używaniem modeli w sensie ogólnym.

3.1.4      (K2) Kandydat potrafi porównać konkretne zalety stosowania podejścia opartego na modelach z jego wadami.

3.2 Modele doskonalenia procesu tworzenia oprogramowania

3.2.1      (K2) Kandydat rozumie aspekty modelu CMMI odnoszące się do testowania.

3.2.2      (K2) Kandydat potrafi porównać przydatność w doskonaleniu procesu testowego modelu CMMI i normy ISO/IEC 15504-5z modelami opracowanymi specjalnie na potrzeby doskonalenia procesu testowego.

3.3 Modele doskonalenia procesu testowego

3.3.1      (K2) Kondydat potrafi krótko opisać pochodzenie i strukturę modelu doskonalenia procesu testowego TPI Next.

3.3.2      (K2) Kandydat potrafi krótko opisać kluczowe obszary modelu doskonalenia procesu testowego TPI Next.

3.3.3      (K2) Kandydat potrafi krótko opisać pochodzenie i strukturę modeli doskonalenia procesu testowego TMMi.

3.3.4      (K2) Kandydat potrafi krótko opisać cele i obszary procesowe TMMi poziom 2.

3.3.5      (K2) Kandydat potrafi krótko opisać cele i obszary procesowe TMMi poziom 3.

3.3.6      (K2) Kandydat potrafi krótko opisać związki pomiędzy TMMi i CMMI.

3.3.7       (K5) Kandydat potrafi zarekomendować właściwy model w ramach podanego scenariusza: TPI Next lub TMMi.

3.3.8      (K3) Kandydat potrafi przeprowadzić nieformalną ocenę z zastosowaniem modelu doskonalenia procesu testowego TPI Next.

3.3.9      (K3) Kandydat potrafi przeprowadzić nieformalną ocenę z zastosowaniem modelu doskonalenia procesu testowego TMMi.

3.3.10      (K5) Kandydat potrafi wykonać ocenę organizacji testowej z zastosowaniem modelu TPI Next lub TMMi.

3.4 Modele oparte o zawartość

3.4.1      (K2) Kandydat potrafi krótko opisać pochodzenie i strukturę modelu STEP (proces systematycznego testowania i oceny).

3.4.2      (K2) Kandydat potrafi krótko opisać działania, produkty i role przedstawione w modelu STEP.

3.4.3      (K2) Kandydat potrafi krótko opisać model CTP.

3.4.4      (K2) Kandydat potrafi krótko opisać krytyczne procesy testowania w ramach modelu CTP.

3.4.5      (K2) Kandydat potrafi krótko opisać rolę metryk w ramach modelu CTP.

3.4.6       (K2) Kandydat potrafi porównać zastosowanie metryk w podejściu opartym o zawartość i podejściu analitycznym (Rozdział 4).

3.1 Wprowadzenie do podejść opartych na modelach

3.1.1 Pożądane cechy modeli doskonalenia procesu testowego

Modele doskonalenia procesu testowego można scharakteryzować za pomocą następujących atrybutów:

- są łatwe w użyciu,

- są publicznie dostępne,

- dostępne jest wsparcie konsultantów,

- nie są narzędziem marketingowym komercyjnej organizacji,

- są zatwierdzone przez profesjonalne instytucje,

- zakładają możliwość doskonalenia,

- zapewniają wiele małych ulepszeń o ewolucyjnym charakterze,

- opierają się na solidnych podstawach, tj. praktycznej, empirycznej, teoretycznej, są opublikowane i uzasadnione,

- zapewniają szczegóły dotyczące sposobu oceniania, identyfikowania oraz wprowadzania ulepszeń,

- ulepszenia są mierzalne

- mogą być dostosowywane do potrzeb (specyficzne dla projektu),

- zalecają określony stopień wykonania działań udoskonalających,

- wspierają ustalenie odpowiedniej kolejności ulepszeń,

- nie ma znaczenia czy ulepszenie jest reprezentowane w sposób etapowy, czy ciągły,

- stopień szczegółowości zawartości testów,

- oferują szeroki zakres i różnorodność sugerowanych rozwiązań dla określonych problemów testowych,

- zawierają stopień formalnej akredytacji wymagany dla oceniających (asesorów),

- możliwa jest certyfikacja dla organizacji.

3.1.2 Reprezentacja ciągła i etapowa

Modele procesów przedstawiają dojrzałość procesu za pomocą reprezentacji ciągłej lub etapowej.

Reprezentacja etapowa przedstawia systematyczne podejście „jeden krok naraz” do procesu doskonalenia. Struktura modelu zaleca etapy, przez które musi przejść organizacja, aby doskonalenie jej procesu testowego zachodziło w uporządkowany sposób. Osiągnięcie danego poziomu gwarantuje, że proces jest odpowiednio dojrzały (w TMMi, nazywa się to Poziomem Dojrzałości) przed przejściem do następnego poziomu. Zadaniem procesu doskonalenia jest osiągnięcie poszczególnych poziomów dojrzałości organizacyjnej dla predefiniowanego zestawu obszarów procesowych (np. Planowanie Testów i Środowisko Testowe w TMMi na poziomie 2), które są przypisane do Poziomu Dojrzałości (np. TMMi poziom 4). Poziom dojrzałości reprezentuje dobrze zdefiniowany stabilny poziom rozwoju zmierzający w kierunku osiągnięcia udoskonalonych procesów w danej organizacji.

Zalety modelu etapowego polegają głównie na prostocie koncepcji. Zapewnia ona klasyfikację poziomu dojrzałości, która jest często wykorzystywana w zewnętrznej komunikacji kierownictwa i w ocenie ofert (np. klient może wymagać, aby wszyscy potencjalni dostawcy osiągnęli minimalny poziom dojrzałości procesów, na przykład TMMi poziom 4). Problemem dotyczącym reprezentacji etapowej jest jej ograniczona elastyczność. Organizacja może osiągnąć stosunkowo wysoki poziom dojrzałości organizacyjnej w wielu wymaganych obszarach procesów, ale może nie osiągnąć ogólnego poziomu dojrzałości. Tendencja do używania podejścia etapowego jako podejścia typu „wszystko albo nic” albo „raz, a dobrze” może skończyć się nieosiągnięciem pożądanych celów biznesowych.

W ramach reprezentacji ciągłej nie istnieją zalecane poziomy dojrzałości, przez które musi przejść proces tworzenia oprogramowania. Model TPI Next wykorzystuje pewną formę reprezentacji ciągłej. (patrz Dział 3.3.1). Organizacja stosująca model reprezentacji ciągłej może wybrać określone obszary w celu doskonalenia z kilku różnych kategorii według szczególnych celów, jakie chce osiągnąć. Reprezentacja ciągła umożliwia osiągnięcie osobnych poziomów dojrzałości organizacyjnej dla każdego procesu/obszaru kluczowego. (np., w modelu TPI Next, kluczowy obszar „Strategia Testowa” może osiągnąć stopień dojrzałości na kilku rosnących poziomach).

Zalety reprezentacji ciągłej odnoszą się przede wszystkim do jej elastyczności, jak ukazano poniżej:

- Organizacja może podjąć decyzję o udoskonaleniu jednego „punktu zapalnego” lub grupy obszarów procesów/obszarów kluczowych ściśle związanych z celami biznesowymi organizacji

- Możliwe jest doskonalenie rożnych obszarów procesowych w różnym tempie i stopniu

- Unika się wady podejścia „wszystko albo nic” modelu etapowego

3.1.3 Założenia w stosowaniu modeli

Istnieje wiele założeń, które są domyślnie przyjmowane podczas realizacji procesu doskonalenia opartego na modelach:

- Modele opisują to, co ich autorzy uznają za „najlepsze praktyki”. Określenie to może być lepiej opisane jako „dobra praktyka”, której stosowanie przyniosło korzyści i udoskonaliło proces testowy. Osoba doskonaląca proces testowy odpowiada za rozstrzygnięcie, co oznacza sformułowanie „najlepsze” dla konkretnego projektu.

- Zastosowanie podejścia opartego na modelach zakłada, że w celu realizacji doskonalenia konieczne jest przestrzeganie „najlepszych praktyk”.

- Modele zakładają, że istnieją tak zwane „standardowe” projekt i/lub organizacja. Ponieważ wszystkie projekty w jakiś sposób różnią się od siebie, podejścia oparte na modelach nie zawsze w jednakowym stopniu będą miały zastosowanie do wszystkich projektów.

Stosowania modeli nie można uznać za czysto mechaniczną procedurę opartą na liście kontrolnej; w celu osiągnięcia maksymalnej korzyści należy zastosować własny osąd i doświadczenie. Modele ogólne wymagają interpretacji, aby uwzględnić specyficzne czynniki związane z projektem.

Poniższe przykłady przedstawiają niektóre czynniki, które mogą wymagać interpretacji modelu:

- zastosowany cykl życia (np. tradycyjny model V lub zwinny proces tworzenia oprogramowania),

- zastosowana technologia (np. technologia webowa, technologia zorientowana obiektowo),

- architektura systemu (np. systemy rozproszone, SOA - Architektura zorientowana na usługi, systemy wbudowane),

- poziom ryzyka (np. dla systemów krytycznych dla bezpieczeństwa w porównaniu z systemami dla biznesu),

- podejście do testowania (np., testowanie skryptowe kontra testowanie eksploracyjne),

- przydatność w kontekście jednostki organizacyjnej,

Mogą występować różne problemy w przypadku stosowania modeli w sensie ogólnym (nie tylko modeli doskonalenia procesów omawianych w niniejszym sylabusie). Są to między innymi:

- niewiedza autora modelu,

- zastosowany model może nadmiernie upraszczać przyczyny i skutki,

- model może zostać zastosowany w niewłaściwym kontekście,

- model jest stosowany bez wzięcia pod uwagę jego przydatności; uznawany jest za cel sam w sobie, a nie za instrument służący do udoskonalenia procesu,

- przekonanie użytkownika, że stosowanie modelu oznacza jego zrozumienie;

- brak doświadczenia lub umiejętności w stosowaniu modelu.

3.2 Modele doskonalenia procesu tworzenia oprogramowania

Modele doskonalenia procesu tworzenia oprogramowania (SPI) zazwyczaj tylko w sposób ogólny uwzględniają zagadnienia związane z testowaniem. Z tego powodu, modele doskonalenia procesu testowego, podobnie jak te opisane w Rozdziale 3.3 niniejszego sylabusa zostały opracowane specjalnie dla procesu testowego.

3.2.1 Model CMMI

Model CMMI można wdrożyć stosując dwa podejścia lub reprezentacje: reprezentację etapową lub ciągłą. W reprezentacji etapowej występuje pięć „poziomów dojrzałości”, a każdy poziom opiera się na obszarach procesowych ustalonych na wcześniejszych poziomach. W reprezentacji ciągłej, organizacja może skoncentrować swoje działania związane z doskonaleniem na podstawowych obszarach potrzeb, bez uwzględniania pozostałych obszarów.

Reprezentacja etapowa zapewnia organizacji dokładniejsze ukierunkowanie i jest najczęściej stosowana w branży. Gwarantuje ona również zgodność z modelem CMM i może być używana w celu obiektywnego pomiaru poziomu dojrzałości organizacji, natomiast reprezentację ciągłą uznaje się ogólnie za bardziej elastyczną.

W ramach modelu CMMI obszary procesowe Walidacji i Weryfikacji w szczególności odnoszą się zarówno do procesów testowania statycznego i dynamicznego. Obszary procesowe Rozwiązania Techniczne oraz Integracja Produktów również odnoszą się do zagadnień związanych z testowaniem.

Oprócz obszarów procesów związanych z testowaniem, niżej wymienione obszary procesowe również zapewniają wsparcie dla bardziej ustrukturalizowanego procesu testowego:

- Planowanie Projektu

- Monitorowanie Projektu i Kontrola

- Zarządzanie Ryzykiem

- Zarządzanie Konfiguracją

- Pomiar i Analiza

- Analiza Przyczyn i Rozwiązywanie Problemów

Pomimo tego, że związek pomiędzy tworzeniem oprogramowania i testowaniem omówiony jest w modelu CMMI, dedykowane modele procesów, takie jak CTP, STEP, TMMi, i TPI Next zapewniają więcej szczegółów dotyczących testowania i procesu testowego.

Związek pomiędzy CMMI i testowaniem jest bardziej uwidoczniony w modelu TMMi [TMMi-Foundation-Web].

3.2.2 ISO/IEC 15504

ISO/IEC 15504-5 jest międzynarodową normą doskonalenia procesu tworzenia oprogramowania, definiującą szereg kategorii procesu tworzenia oprogramowania, w tym Inżynieria, Zarządzanie, Organizacja, Klient-Dostawca oraz Wsparcie. Kategoria procesu „Wsparcie” (SUP) obejmuje poszczególne procesy, które są istotne dla procesu testowego, w tym Weryfikację i Walidację. Poziom dojrzałości każdego procesu jest oceniany przy użyciu predefiniowanego zestawu atrybutów procesu i wykorzystuje podejście reprezentacji ciągłej.

3.3 Modele doskonalenia procesu testowego

W Rozdziale 2.5.1. wstępnie omówiono różne rodzaje modeli doskonalenia procesów. Rozdział niniejszy oraz Rozdział 3.4 dokładniej opisują najważniejsze modele doskonalenia stosowane w praktyce.

3.3.1 Model doskonalenia procesu testowego (TPI®)

Sylabus dla egzaminu ISTQB na certyfikowanego testera na poziomie zaawansowanym opisuje model TPI [Koomen / Pol 99] oraz przedstawia cele nauczania, które dotyczą kierownika testów. W roku 2009 wydano kolejną wersję modelu: TPI Next [Sogeti 09].

Model TPI Next jest modelem procesów wskazującym wszystkie najistotniejsze aspekty procesu testowego. Odpowiednio, centralnymi elementami modelu TPI Next jest szesnaście kluczowych obszarów, z których każdy dotyczy określonego aspektu procesu testowego, jak strategia testowania, miary, narzędzia testowe oraz środowisko testowe.

Szczegółowa analiza kluczowych obszarów ma oparcie na różnych poziomach dojrzałości przypadających na każdy obszar kluczowy, z których każdy zdefiniowany jest przez określone punkty kontrolne. Zdefiniowane klastry punktów kontrolnych z wielorakich obszarów kluczowych składają się na małe etapy ulepszeń. Zastosowanie klastrów obniża ryzyko ulepszeń „jednostronnych” (np. nie zaleca się osiągania wysokich poziomów dojrzałości w obszarze kluczowym miary, zanim nie osiągnie się pewnych poziomów dojrzałości dla obszarów kluczowych, takich jak zarządzanie defektami i raportowanie). W rezultacie model TPI Next stosuje formę reprezentacji ciągłej, ale nadal zaleca pewne udoskonalenia procesowe dla obszarów kluczowych w określonej kolejności.

Za pomocą macierzy dojrzałości obejmującej wszystkie obszary kluczowe, zebrane dane są podsumowywane i wizualizowane. Po zebraniu i skonsolidowaniu rezultatów analizy wszystkich kluczowych obszarów, całemu procesowi testowania można przypisać poziom dojrzałości. Poziomy te nazwane są: wstępny, kontrolowany, skuteczny i optymalny.

Dostępne są liczne sugestie ulepszeń uporządkowanych pod względem ważności odzwierciedlające dobrą praktykę testowania, aby wspomagać definiowanie stosownej ścieżki rozwoju. Definicja celów ulepszeń i ich implementacja mogą być dopasowane do potrzeb i zdolności organizacji testowej.

Podejście ogólne uniezależnia TPI Next od jakiegokolwiek modelu SPI. Obejmuje ono zarówno aspekty inżynierii testowania, jak i wsparcie dla podejmowania decyzji przez kierownictwo.

Oryginalny model TPI został przystosowany do poszczególnych gałęzi przemysłu.  Przykładem takiego przystosowania jest „TPI dla przemysłu samochodowego”, które definiuje dodatkowy obszar kluczowy („integracja”) i został przyjęty przez niemieckich producentów samochodów.

Istnieje mapowanie pomiędzy modelem TPI Next, a modelami usprawniania procesów tworzenia oprogramowania CMMI i ISO/IEC 15504, o których była mowa w Rozdziale 3.2.

3.3.2 Zintegrowany model dojrzałości testów (TMMi)

Sylabus ISTQB Certyfikowany Tester – Poziom Zaawansowany opisuje model TMMi i określa cele nauczania dla kierownika testów.

Model TMMi [TMMi-Foundation-Web] posiada budowę etapową służącą doskonaleniu procesów. Definiuje następujące poziomy lub poziomy dojrzałości, przez które przechodzi organizacja w miarę, jak jej proces testowy ewoluuje od testowania ad-hoc:

- Początkowy

- Kierowany

- Zdefiniowany

- Zarządzanie i pomiar

- Optymalny

Pięć poziomów dojrzałości w modelu TMMi zaleca hierarchię dojrzałości i stopniową ścieżkę do poprawy procesu testowego. Osiągnięcie każdego etapu gwarantuje, że wprowadzono stosowne ulepszenia, na których będzie bazował kolejny etap. Wewnętrzna struktura modelu TMMi zawiera bogaty wybór praktyk testowania, których można się nauczyć i stosować w systematyczny sposób w celu wsparcia procesu testowania jakości, który udoskonalany jest przyrostowo.

Każdy poziom dojrzałości w modelu TMMi obejmuje zestaw obszarów procesowych, na których organizacja musi skoncentrować się w celu osiągnięcia stopnia dojrzałości na danym poziomie. Przykładowo, obszary procesów w modelu TMMi na poziomie 2, „Kierowany”, są następujące:

- Polityka i Strategia Testowania

- Planowanie testów

- Monitorowanie i kontrola testów

- Projektowanie i wykonanie testów

- Środowisko testowe

Struktura modelu TMMi jest w znacznym stopniu oparta na strukturze modelu CMMI. Jest to znacząca korzyść, ponieważ duża ilość ludzi/organizacji zna strukturę CMMI. Struktura CMMI wyraźnie rozróżnia praktyki, których wdrożenie jest wymagane (cele), a których zalecane (specyficzne praktyki, typowe produkty).

3.3.3 Porównanie modeli TPI Next i TMMi

Niniejszy dział zawiera krótkie porównanie dwóch modeli doskonalenia procesu testowego omawianych w sylabusie. W zależności od określonego kontekstu projektu i celów doskonalenia, do których należy dążyć, może być preferowany jeden z modeli.

Tabela poniżej ukazuje niektóre różnice pomiędzy TMMi a TPI Next:

Aspekt

TPI Next

TMMi

Typ

Reprezentacja ciągła

Reprezentacja etapowa

Metody testowe

Stosuje ogólne praktyki TMap (Next) jako punkt odniesienia.

Niezależny od metody testowania

Terminologia

Oparty na Tmap [Pol.M & Van Veenendaal. E 98]

Oparty na standardowej terminologii testowej

SPI

Brak formalnego związku z określonym modelem SPI; możliwa korelacja

Wysoce skorelowany z CMMI

Zorientowany na

16 kluczowych obszarów z ukierunkowaniem na testy. Szczegółowy widok każdego obszaru testowania, ogólny ogląd całego procesu testowego.

Szczegółowe ukierunkowanie na ograniczoną liczbę obszarów procesowych przypadających na poziom dojrzałości.

Również ukierunkowany na inne zagadnienia związane z testowaniem, takie jak przeglądy testowalności, kontrola jakości, zapobieganie usterkom, oraz program pomiaru testowego.

Podejście

Szczegółowe, odzwierciedlające potrzeby biznesu i inżynierii testowania

Silnie ukierunkowany na zaangażowanie kierownictwa

3.4 Modele oparte o zawartość

Modele oparte o zawartość umożliwiają doskonalenie procesów testowych poprzez zapewnienie ustrukturalizowanego opisu dobrych praktyk testowania wraz z ogólnym podejściem, którego należy przestrzegać. Modele oparte o zawartość opisane w niniejszym sylabusie to STEP i CTP.

3.4.1 STEP

Proces systematycznego testowania i oceny (STEP) [Craig02] nie wymaga, aby proces doskonalenia przebiegał w określonym porządku. W tym celu model oceny STEP może zostać połączony z modelem TPI (Next).

Metodyka STEP oparta jest na założeniu, że testowanie jest czynnością obejmującą cały cykl życia oprogramowania, rozpoczynającą się na etapie formułowania wymagań i trwającą do momentu wycofania systemu.

Sylabus ISTQB dla poziomu zaawansowanego zawiera szczegóły na temat:

- Podstawowych założeń metodyki

- Przykłady wykonywanych miar ilościowych

- Przykłady czynników jakościowych

3.4.2 Krytyczny Proces testowy (CTP)

Podstawowym założeniem modelu oceny Krytycznego Procesu testowego (CTP) [Black03] jest stwierdzenie, że pewne procesy testowania są krytyczne. Procesy te, jeśli wykonane prawidłowo, będą stanowić wsparcie dla prawidłowo funkcjonujących zespołów testowych. Model opisuje dwanaście krytycznych procesów testowych.

Ocena CTP opisuje, które procesy są słabo, a które dobrze rozwinięte, a także zapewnia zalecenia uporządkowane według priorytetów dotyczące doskonalenia w oparciu o potrzeby organizacji. Podczas oceny CTP badaniu poddaje się najczęściej kilka metryk ilościowych i jakościowych.

Kiedy w trakcie oceny zostaną zidentyfikowane słabe obszary, przygotowywane są plany doskonalenia. Model zapewnia ogólne plany doskonalenia dla każdego z krytycznych procesów testowych, ale zespół dokonujący oceny musi je w znacznym stopniu dostosować.

4. Doskonalenie oparte o analizę                  555 minut

Terminologia:

analiza przyczyn, diagram przyczynowo-skutkowy, graf przyczynowo-skutkowy, Odsetek Wykrytych Błędów, Analiza Przyczyn i Skutków Awarii, Analiza Drzewa Usterek, wskaźnik, inspekcja, pomiar, metryka, analiza Pareto

Cele nauki dla rozdziału „Doskonalenie oparte o analizę”:

4.2 Analiza przyczyn

4.2.1      (K2) Kandudat rozumie analizę przyczyn z zastosowaniem diagramów przyczynowo skutkowych.

4.2.2      (K2) Kandydat rozumie analizę przyczyn w trakcie procesu inspekcji.

4.2.3      (K2) Kandydat rozumie zastosowania standardowej klasyfikacji anomalii do analizy przyczyn.

4.2.4      (K2) Kandydat potrafi porównać metody analizy przyczyn.

4.2.5      (K3) Kandydat potrafi zastosować analizę przyczyn do danego opisu problemu.

4.2.6      (K5) Kandydat potrafi zarekomendować i wybrać czynności z zakresu doskonalenia procesu testowego w oparciu o rezultaty analizy przyczyn.

4.2.7      (K4) Kandydat potrafi wybrać usterki dla celów analizy przyczyn z zastosowaniem ustrukturalizowanego podejścia.

4.3 Podejście Cel-Pytanie-Miara (GQM)

4.3.1      (K2) Kandydat potrafi opisać podejście Cel-Pytanie-Miara (GQM).

4.3.2      (K3) Kandydat potrafi zastosować podejście Cel-Pytanie-Miara (GQM) do wyprowadzenia odpowiedniej metryki z celu doskonalenia procesu testowego.

4.3.3      (K3) Kandydat potrafi zdefiniować miary dla celu doskonalenia procesu testowego.

4.3.4      (K2) Kandydat rozumie etapy i wyzwania fazy gromadzenia danych.

4.3.5      (K2) Kandydat rozumie etapy i wyzwania fazy interpretacji.

4.4 Analiza z zastosowaniem miar, metryk i wskaźników

4.4.1      (K2) Kandydat potrafi podać przykłady różnych kategorii metryk i sposobu ich użycia w kontekście doskonalenia procesu testowego.

4.4.2      (K5) Kandydat potrafi zarekomendować odpowiednie metryki i wskaźniki dla celu śledzenia trendów w określonej sytuacji doskonalenia procesu testowego.

4.1 Wstęp

Podejścia analityczne oparte są na problemach. Udoskonalenia, jakie należy wprowadzić, oparte są na faktycznych problemach i celach, a nie na ogólnym modelu „najlepszych praktyk” stosowanym w podejściach opartych na modelach i podejściach opartych o zawartość, przedstawionych wRozdziale  3.

Analiza danych jest niezbędna dla celów obiektywnego doskonalenia procesu testowego. Jest także cennym wsparciem dla ocen czysto jakościowych, które w przeciwnym przypadku mogłyby skutkować nieprecyzyjnymi zaleceniami, które nie mają oparcia w danych.

Stosowanie podejścia analitycznego do procesu doskonalenia pociąga za sobą analizę procesu testowego w celu identyfikacji obszarów problemowych i ustalenia celów specyficznych dla projektu. Wymagane są definicja i pomiar parametrów kluczowych, aby ocenić czy działania związane z doskonaleniem powiodły się.

Podejścia analityczne mogą być stosowane razem z podejściem opartym o zawartość w celu weryfikacji rezultatów i zapewnienia różnorodności, tak jak w przypadku Krytycznych Procesów Testowych (CTP). Ponadto, podejścia oparte na modelach czasami określają podejścia analityczne jako jeden lub kilka osobnych obszarów kluczowych modelu, jak ma to miejsce w przypadku TMMi.

Ogólnie rzecz biorąc, podejścia analityczne można również zastosować do zadania kierowania testami. Kierownicy testów stosują je na poziomie projektu, natomiast doskonalący procesy testowe stosują je na poziomie procesu.

4.2 Analiza przyczyn

Analiza przyczyn to badanie problemów w celu zidentyfikowania ich ewentualnych przyczyn źródłowych. Umożliwia to znalezienie rozwiązań, które usuną przyczyny problemów, a nie tylko określą bezpośrednio widoczne symptomy. W przypadku, gdy nie stosuje się analizy przyczyn, próby doskonalenia procesu testowego mogą się nie udać, ponieważ faktyczne przyczyny źródłowe nie są określonei takie same lub podobne problemy powracają.

Wiele modeli doskonalenia procesu tworzenia oprogramowania podkreśla zastosowanie analizy przyczyn jako sposobu ciągłego podnoszenia dojrzałości procesu tworzenia oprogramowania.

Systematyczne metody analizy przyczyn wymienione poniżej są opisane w dalszej części niniejszego sylabusa jako przykłady:

- Diagramy przyczynowo-skutkowe (diagramy rybiej ości Ishikawy)

- Analiza przyczyn podczas procesu inspekcji

- Stosowanie standardowych klasyfikacji anomalii

Uwaga: dla celów analizy przyczyn dostępne są inne metody (patrz sylabus dla poziomu zaawansowanego); ponadto, listy kontrolne częstych przyczyn mogą być stosowane jako dane wejściowe do analizy przyczyn, na przykład podczas wykonywania analizy przyczyn błędów.

4.2.1 Diagramy przyczynowo-skutkowe

Diagramy przyczynowo-skutkowe (znane także jako diagramy rybiej ości Ishikawy) zostały opracowane dla przemysłu wytwórczego i innych gałęzi przemysłu [Ishikawa 91], a także zostały zaadaptowane dla branży IT [Juran]. Diagramy te zapewniają mechanizm identyfikacji i omówienia przyczyn źródłowych z zastosowaniem kilku nagłówków.

Kroki, które należy zastosować (wg [Robson 95]) opisane są następująco:

1. Po prawej stronie diagramu należy wypisać skutek

2. Następnie należy narysować elementy szkieletu ryby i opisać je zgodnie z ich kontekstem. Właścicielem szkieletu jest grupa robocza, a nie kierownictwo.

3. W następnej kolejności należy przypomnieć grupie roboczej o zasadach burzy mózgów:

- Brak krytyki – wszystkie pomysły są na tym etapie przyjmowane

- Przypadkowe, szalone pomysły są przyjmowane tak samo jak pomysły bazujące na pomysłach innych osób

- Ilość pomysłów – należy wygenerować dużą ilość pomysłów

- Wszystkie pomysły są zapisywane – także te przypadkowe, szalone i powtarzające się

- Nie należy oceniać pomysłów od razu – po ich zebraniu w burzy mózgów należy zrobić przerwę, zanim przystąpi się do ich oceny

4. Zastosować metodę burzy mózgów – możliwe przyczyny są zebrane podczas burzy mózgów i dodane do osi diagramu. Dla każdej przyczyny pierwszego poziomu, w celu zidentyfikowania zasadniczych przyczyn źródłowych, które mogą być zlokalizowane w różnych częściach diagramu, stosuje się listy kontrolne.

5. Pozwolić pomysłom dojrzewać przez pewien czas.

6. Dokonać analizy diagramu w celu odnalezienia skupisk przyczyn i objawów. Zastosować zasadę Pareto (80% zysku przy 20% wysiłku) w celu zidentyfikowania skupisk, które są kandydatami do rozwiązania.

Diagramy przyczynowo-skutkowe mogą być również zastosowane w celu dotarcia do przyczyn, wychodząc od skutków, wg [BS7925-2] i [Copeland 03].

4.2.2 Analiza przyczyn podczas procesu inspekcji

Proces inspekcji opisany jest w sylabusie ISTQB dla poziomu podstawowego i dokładniej przedstawiony w sylabusie ISTQB dla poziomu zaawansowanego. Wykorzystanie procesu inspekcji oprogramowania [Gilb & Graham] sugeruje podejście odmienne od analizy przyczyn.

Spotkanie poświęcone analizie przyczyn to nadzorowana dyskusja trwająca około dwóch godzin i prowadzona według ustalonego harmonogramu i formatu.

- Wyboru usterek, które będą wzięte pod uwagę, może dokonać lider inspekcji lub mogą one zostać wybrane w kontekście retrospektywy projektu. W przeciwnym razie, zagadnienia, które będą omawiane, mogą zostać zidentyfikowane w pierwszej części analizy.

- Część 1: Analiza usterek (90 minut) dotyczy określonych usterek i zajmuje się konkretnymi usterkami i ich przyczynami.

- Część 2: Analiza ogólna (30 minut) ukierunkowana jest na zidentyfikowanie ogólnych tendencji w odniesieniu do usterek. Zespół szuka tendencji, podobieństw oraz tego, co ostatnio się udało, ulepszyło lub pogorszyło. Taksonomie usterek (przedstawione w sylabusie dla poziomu zaawansowanego) mogą stanowić istotną pomoc w przypadku tego rodzaju analizy. Analiza ogólna może być również ukierunkowana na poszczególne usterki stwierdzone podczas testowania dynamicznego, w celu zapewnienia danych wejściowych opartych na ryzyku dla przyszłej strategii testowej.

- Dyskusja musi zagwarantować, że liczba i waga usterek branych pod uwagę maksymalizuje zwrot zainwestowanego czasu.

Podczas analizy usterek, każdej z nich jest nadawana kategoria uwzględniająca:

- Opis usterki – nie jest to objaw usterki, ale usterka jako taka

- Kategorię przyczyny - np. komunikacja, przeoczenie, wykształcenie, błąd transkrypcji, proces

- Opis przyczyny – dla przyczyny i dowolnego ciągu przyczyn

- Etap procesu, podczas którego powstała usterka – nie zawsze jest to miejsce, w którym została wykryta

- Sugerowane działania mające na celu usunięcie przyczyny – muszą one być konkretne i możliwe do osiągnięcia.

4.2.3 Wykorzystanie Standardowych Klasyfikacji Anomalii

Normy takie jak [IEEE 1044] umożliwiają wspólną klasyfikację anomalii pozwalając na określenie w których etapach projektu wprowadzane są usterki, w ramach jakich działań zostały one wykryte, koszt naprawy usterek, koszt awarii oraz fazę projektu w której usterka została zgłoszona w zderzeniu z momentem w którym została znaleziona (efekt nazywany również Wyciekiem Usterek).

Wspólna klasyfikacja pozwala na analizę statystyk dotyczących obszarów doskonalenia procesu testowego w całej organizacji. Klasyfikację tę należy wprowadzić drogą szkoleń, narzędzi i udzielania wsparcia tak, aby każda osoba używająca systemu zarządzania incydentami posiadała wiedzę dotyczącą tego, kiedy stosować klasyfikacje i jak je interpretować. Informacje te mogą być wykorzystane podczas doskonalenia procesu tworzenia oprogramowania oraz procesu testowego w celu zidentyfikowania obszarów, w których obrębie doskonalenie będzie opłacalne, a także w celu śledzenia sukcesu inicjatyw dotyczących doskonalenia. Usterki, które mają zostać poddane analizie będą rejestrowane na wszystkich etapach cyklu życia oprogramowania, w tym pielęgnacji i wykorzystania produkcyjnego.

4.2.4 Wybór usterek do Analizy Przyczyn

Zastosowanie metod opisanych powyżej może wymagać selekcji określonych usterek do analizy z potencjalnie dużego zbioru. Można zastosować kombinację podejść wymienionych poniżej w celu dokonania wyboru usterek do analizy:

- Analiza Pareto (20% usterek uznaje się za reprezentujące wszystkie usterki)

- Ekstremalne odchylenia od średniej w statystykach (np. używanie wartości wariancji statystycznej, takich jak 3-sigma, w odniesieniu do określonej miary)

- Retrospektywy projektu

- Stosowanie kategorii wagi defektów

4.3 Podejście GQM  (Cel-Pytanie-Miara)

W podejściu Cel-Pytanie-Metryka (GQM) [BasiliPapers], [Trienekens, van Veenendaal 97] stosowane są następujące kroki w celu zdefiniowania odpowiednich miar:

- wyznaczenie określonych celów,

- wywodzenie pytań, które dostarczą informacji dotyczących osiągnięcia celów po udzieleniu na nie odpowiedzi,

- wywodzenie miar, które po dokonaniu ich pomiaru, dostarczą odpowiedzi na postawione pytania.

Podejście Basiliego związane z GQM polega na dostarczeniu mechanizmu pomiaru dla celów uzyskania informacji zwrotnej i oceny. Podejście GQM pozwala na to, aby pomiar:

- ukierunkowany był na ustalenie określonych celów,

- można było stosować do wszystkich części produktów, procesów i zasobów cyklu życia oprogramowania,

- można było interpretować w oparciu o charakterystykę i zrozumienie kontekstu, środowiska i celów organizacji.

Dlatego też, pomiary stosowne w jednej organizacji mogą nie być odpowiednie dla innej. Określenie celów i pytań dopuszcza wybór lub zdefiniowanie odpowiednich miar, a w konsekwencji zgromadzenie i analizę właściwych danych.

Trzy poziomy stosowane w podejściu GQM to:

1. Poziom konceptualny – CELE organizacji, z uwzględnieniem jakości produktów, procesów i zasobów (uwaga: zasoby obejmują ludzi, lokale, sprzęt oraz oprogramowanie). Poziom ten może obejmować którąkolwiek z definicji jakości zawartych w Rozdziale 2, dlatego też produktywność, a także doskonałość wytwarzania mogą być celem. W celu zdefiniowania celów można zastosować formularze.

2. Poziom operacyjny – PYTANIA charakteryzujące produkty, procesy i zasoby w odniesieniu do ich jakości – Basili nazywa je przedmiotami pomiaru

3. Poziom ilościowy – MIARY, które mogą być obiektywne (ilościowa, faktyczna) lub subiektywne (jakościowa, punkty widzenia)

Cele mogą dać początek jednemu lub kilku pytaniom, a te mogą dać początek jednej lub kliku miarom. Cele, pytania i miary mogą być powiązane z poglądami na temat jakości opisanymi w Rozdziale 2, lub z pomiarem wyników wymaganym przez opisane w Rozdziale 2 metody doskonalenia organizacji oraz IT.

4.4 Analiza przy użyciu miar, metryk i wskaźników

4.4.1 Wstęp

Miary, metryki i wskaźniki są częścią wszystkich programów doskonalenia, niezależnie od tego czy udoskonalenia te są realizowane w sposób formalny, czy nieformalny. Nie jest istotne również czy dane są jakościowe, czy ilościowe, obiektywne bądź subiektywne. Odczucia osób, których dotyczy doskonalenie, są istotną miarą postępu w kierunku doskonalenia.

Miary, metryki i wskaźniki wstępnie pomagają zidentyfikować obszary i możliwości pod kątem doskonalenia. Są one ciągle wymagane w inicjatywach dotyczących doskonalenia w celu kontrolowania procesu doskonalenia i zapewnienia, że rezultatem zmian są pożądane usprawnienia.

Miary, metryki i wskaźniki mogą być gromadzone na wszystkich etapach cyklu życia oprogramowania, w tym tworzenia, pielęgnacji i użycia operacyjnego [Nance & Arthur 02]. Używane są również do wyprowadzania innych metryk i wskaźników. Należy zauważyć, że dla wszystkich pozycji wymienionych w Dziale 4.4.2 odnoszących się do usterek, ważne jest rozgraniczenie pomiędzy różnymi poziomami ważności priorytetów oraz wag stwierdzonych usterek. Określone miary, metryki i wskaźniki mogą być również zastosowane przez kierowników testów, w szczególności do zadań na poziomie projektu dotyczących szacowania testów oraz monitorowania postępów i kontroli. Osoby doskonalące proces testowy zastosują miary, metryki i wskaźniki na poziomie procesu.

4.4.2 Miary skuteczności testowania

4.4.2.1 Odsetek Wykrytych Błędów (OWB)

Pierwszym wskaźnikiem, który może zostać wykorzystany w prawie każdym procesie doskonalenia testowania i który jest wysoko oceniany przez większość ekspertów, jest Odsetek Wykrytych Błędów (OWB). Jeśli w trakcie testowania znaleziono większość (o ile nie wszystkie z) istotnych błędów, a użytkownicy/klienci znaleźli niewiele nowych błędów w trakcie codziennego użytkowania aplikacji, poziom testowania jest wysoki.

Odsetek Wykrytych Błędów definiuje się jako liczbę błędów znalezionych w trakcie testowania podzieloną przez ogólną liczbę znanych błędów. OWB można wyliczyć w odniesieniu do etapu testów (np. testowanie integracyjne, testowanie alfa, testowanie beta) lub dla wszystkich etapów testowania łącznie. OWB jest możliwą do wyliczenia metryką po zakończeniu projektu i upływie pewnego okresu czasu (np. 3 lub 6 miesięcy), w którym znaleziono śladowe ilości błędów.

4.4.2.2 Ilość błędów po wydaniu produktu

Wskaźnik ten określa się jako liczbę błędów stwierdzonych przez klientów podczas pewnego okresu po wydaniu produktu w przeliczeniu na tysiąc linii kodu (KLOC). Jeśli wielkość ta ulegnie zmniejszeniu, postrzegana przez klienta jakość produktu wzrośnie.

Uwaga: powyższe metryki błędów udzielają informacji zwrotnych dotyczących spojrzenia na jakość z punktu widzenia wytwarzania, jak omówiono w Rozdziale 2.

4.4.3 Miary efektywności / kosztów testowania

4.4.3.1 Organizacyjny Koszt Jakości

Aby „sprzedać” innym pomysł doskonalenia procesu testowego innym, trzeba pokazać korzyści z tego płynące. W tym celu należy wykazać korzyści kosztowe testowania i doskonalenia procesu testowego poprzez zmierzenie kosztu testowania i doskonalenia, jak również koszty braku testowania (tj., koszt awarii).

4.4.3.2 Współczynnik kosztu jakości

Współczynnik „całkowitej pracy poświęconej na testowanie statyczne (np. inspekcje i przeglądy)” do „całkowitej pracy poświęconej na testowanie dynamiczne (np. testowanie jednostkowe, integracyjne, testowanie systemu)”. W przypadku, gdy współczynnik ten wzrasta, efektywność procesu usuwania błędów również wzrasta.

4.4.3.3 Wczesne wykrywanie błędów

Jak stwierdzono w odniesieniu do poprzedniego współczynnika wydajności, efektywność procesu usuwania błędów wzrasta, jeśli te zostaną znalezione na wczesnym etapie procesu. Ma to zastosowanie nie tylko w sytuacji testowanie statyczne kontra testowanie dynamiczne, ale również w sytuacji testowanie jednostkowe i integracyjne w odniesieniu do testowanie systemu i testowanie akceptacyjne. Współczynnik wydajności „Wczesne Wykrywanie Błędów” mierzy całkowitą liczbę błędów wykrytych w trakcie testowania jednostkowego i integracyjnego (wczesne testowanie dynamiczne) w przeciwieństwie do całkowitej liczby błędów wykrytych w trakcie testowania dynamicznego.

4.4.3.4 Względna pracochłonność testów

Podstawowy wskaźnik jest ilorazem całkowitej pracochłoności testów (lub kosztu) i całkowitej pracochłonności projektu (lub kosztu) przed wydaniem produktu. Praca po wydaniu produktu poświęcona na czynności takie jak pielęgnacja i wsparcie posprzedażowe nie są brane pod uwagę.

4.4.3.5 Efektywność testowania

Wskaźnik ten jest oparty na liczbie i wadze wykrytych błędów w porównaniu z wykonanymi pracami testowymi (na poziom testów). Wskaźnik jest stosowany do określenia czy prace testowe ukierunkowane są na wykrycie błędów o wysokich wagach. Efektywność testowania może również być związana z wielkością zadania testowego, wyrażoną na przykład przy pomocy punktów testowych.

4.4.3.6 Poziom automatyzacji

Współczynnik ilości przypadków testowych wykonanych automatycznie przypadających na całkowitą liczbę wykonanych przypadków testowych (ręcznie i automatycznie).

4.4.3.7 Produktywność testów

Całkowita liczba przypadków testowych (lub projektu testów) dla produktu związana z wymaganą całkowitą pracochłonnością testów. Oczywiście, niniejszy wskaźnik wydajności może być mierzony w odniesieniu do fazy testowania.

Uwaga: powyższe metryki efektywności/kosztów dają informacje dotyczące spojrzenia na jakość z punktu widzenia „wartości”(patrz Rozdział 2).

4.4.4 Miary opóźnień

Opóźnienie testowania jest szczególnie istotne w trakcie wykonywania testów, jako że wykonywanie testów znajduje się na krytycznej ścieżce projektu. Opóźnienie definiuje się jako okres (w dniach lub tygodniach) pomiędzy dwoma kamieniami milowymi określającymi początek i koniec jednego lub kilku działań projektu. Wskaźnik czasu wykonania testów w celu przetestowania produktu powinien oczywiście być powiązany z rozmiarem produktu. Wskaźnik ten można również mierzyć w odniesieniu do fazy testowania, np. testowania alfa lub beta.

4.4.5 Miary przewidywalności

4.4.5.1 Opóźnienie w wykonywaniu testów

Jest to różnica pomiędzy faktycznym a szacowanym czasem testowania wymaganym dla jednej lub kilku faz testowania związanych z szacowanym czasem wykonania testów.

Dla celów doskonalenia, często ciekawą rzeczą jest pomiar opóźnienia w wykonywaniu testów w odniesieniu do szacunków wykonanych na początku projektu i w odniesieniu do szacunków wykonanych na początku fazy wykonywania testów.

4.4.5.2 Poślizg pracochłonności (lub kosztów)

Jest to różnica pomiędzy faktycznie wykonaną pracą (lub faktycznymi kosztami) a szacowaną pracochłonności (lub kosztami) wymaganą w jednej lub kilku fazach testowania podzielona przez szacowaną pracochłonność (lub koszt).

4.4.5.3 Poślizg w przypadkach testowych

Jest to różnica pomiędzy faktyczną i szacowaną liczbą przypadków testowych (lub projektów testów) wymaganą dla jednej lub kilku faz testowania w stosunku do szacowanej liczby przypadków testowych (lub projektów testów).

4.4.6 Miary Jakości Produktu

4.4.6.1 Miary dotyczące atrybutów jakości

Istnieje kilka atrybutów, za pomocą których można opisać jakość produktu (np. funkcjonalność, niezawodność, używalność, efektywność, pielęgnowalność, przenośność). Są one udokumentowane w standardzie [ISO 9126] i jego nowszej wersji, [ISO 25000]. Atrybuty i wskaźniki związane z nimi opisano w sylabusie ISTQB dla poziomu zaawansowanego. Na przykład, wskaźniki związane z cechą jakości oprogramowania, taką jak niezawodność mogą przyjąć formę Średniego Czasu Pomiędzy Awariami (ang. MTBF) i Średniego Czasu Naprawy (ang. MTTR).

Proces testowy jest jednym z podstawowych źródeł informacji potrzebnych do zmierzenia wyżej wymienionych atrybutów jakości oprogramowania. Możliwość dostarczenia znaczących i istotnych informacji na temat jakości produktu za pomocą procesu testowego może być uznana za obszar potencjalnego doskonalenia procesu testowego.

4.4.6.2 Wskaźniki pokrycia

Pokrycie wymagań i kodu uzyskane w drodze testowania mogą być wykorzystane jako wskaźniki jakości produktu (przy założeniu, że wyższa jakość produktu jest związana z wyższym stopniem pokrycia) w trakcie testowania.

Pokrycie wymagań definiuje się jako ilość przetestowanych wymagań w porównaniu z określoną ogólną liczbą wymagań. Stwierdzenie to można doprecyzować poprzez wprowadzenie rozróżnienia pomiędzy ilością przetestowanych wymagań i ilością wymagań przetestowanych z wynikiem pozytywnym. Jeśli poziom pokrycia wzrasta, testowanie staje się dokładniejsze i oczekuje się, że jakość produktu również wzrasta.

Pokrycie kodu definiowane jest jako procent całego kodu oprogramowania wykonanego w trakcie testowania. Sylabus ISTQB dla poziomu podstawowego opisuje różne poziomy pokrycia kodu.

Poziomy te dostarczają informacji na temat jakości z punktu widzenia produktu. (patrz Rozdział 2).

4.4.7 Miary dojrzałości testów

Miary te przedstawiają poziom dojrzałości procesu testowego organizacji przy użyciu sformułowań stosowanych w modelach, takich jak Model Dojrzałości Testów (TMMi) lub model Doskonalenia Procesu Testowego (TPI Next). Jeśli poziom dojrzałości rośnie, ryzyko niespełnienia celów testowania dotyczących jakości, opóźnienia i kosztów maleje. Sylabus dla poziomu zaawansowanego zawiera więcej szczegółów na ten temat.

Należy zwrócić uwagę, że miary te odnoszą się do poglądów dotyczących jakości z punktu widzenia wytwarzania, produktu i wartości opisanych w Rozdziale 2, ale nie są bezpośrednimi miarami poziomu jakości z punktu widzenia użytkownika. Dlatego też, kierownicy testów mogą chcieć dokonać pomiaru poziomu jakości z punktu widzenia użytkownika poprzez określone pomiary satysfakcji użytkownika / klienta, pomiar charakterystyk używalności (zwłaszcza w odniesieniu do poziomu skuteczności i/lub efektywności zadania), bądź przez pomiary jakości z punktu widzenia interesariuszy.

5. Wybór podejścia do doskonalenia procesu testowego

105 minut

Terminologia:

(brak)

Cele nauki:

5.1 Wybór podejść do doskonalenia procesu testowego

5.1.1      (K2) Kandydat potrafi podsumować powody najlepszego sposobu zastosowania podejścia do doskonalenia procesu testowego

5.1.2      (K5) Kandydat potrafi zarekomendować podejście do doskonalenia procesu testowego w ramach określonego scenariusza i dla danego zakresu doskonalenia

5.1 Wybór podejść do doskonalenia procesu testowego

Wybór podejścia zależy od:

- rozważenia krytycznych czynników sukcesu opisanych w Rozdziale 9

- rozważenia ogólnych wytycznych wymienionych poniżej

Poniższe listy podano w celu wsparcia procesu decyzyjnego. Nie należy ich traktować jako listy wymagań obowiązkowych bądź nienaruszalnych zasad. Rozpatrując modele doskonalenia procesu testowego, w momencie dokonywania wyboru pomocne może być też rozważenie listy ogólnych charakterystyk modeli opisanych w Dziale 3.1.1.

Modele procesowe (np. TMMi, TPI Next) najlepiej jest stosować, gdy:

- Proces testowy już istnieje, chociaż modele te mogą być również przydatne w celu ustanowienia procesu testowego

- Pomiędzy podobnymi projektami wymagane jest stosowanie porównań i wzorców

- Wymagana jest zgodność z modelami doskonalenia procesu tworzenia oprogramowania

- Polityka firmy wymaga osiągnięcia określonego poziomu dojrzałości (np. TMMi poziom 3)

- Konieczny jest dobrze zdefiniowany punkt wyjścia z uprzednio zdefiniowaną ścieżką doskonalenia

- Potrzebna jest miara dojrzałości testów, np. dla celów marketingowych

- W organizacji modele procesowe są przestrzegane i akceptowane

Modele oparte o zawartość (np. CTP, STEP) najlepiej jest stosować, gdy:

- Należy ustanowić proces testowy

- Potrzebna jest ocena mająca na celu zidentyfikowanie kosztów i ryzyk związanych z bieżącym procesem testowym

- Udoskonalenia nie muszą być wdrażane w kolejności określonej przez TMMi lub TPI Next, ale w kolejności określonej przez potrzeby biznesowe

- Wymagane jest dostosowanie w celu zapewnienia, że proces testowy pasuje do określonego kontekstu firmy

- Pożądane lub potrzebne są nieciągłe, szybkie udoskonalenia i zmiany w zakresie istniejącego procesu testowego

Podejścia analityczne najlepiej jest stosować, gdy:

- Należy skoncentrować się na określonych problemach

- Dostępne są miary i metryki bądź można je ustanowić i stosować

- Wymagane jest udowodnienie potrzeby istnienia procesu testowego

- Istnieje potrzeba porozumienia dotyczącego powodów zmian

- Przyczyna źródłowa problemu niekoniecznie znajduje się w strefie kontroli lub wpływu właściciela procesu

- Wymagane są lub zostały zaplanowane wydatki na ewaluację na niewielką skalę lub wdrożenie pilotażowe procesu

- Wymagane jest wdrożenie pilotażowe, aby stwierdzić czy istnieje potrzeba zakrojonego na szerszą skalę śledztwa lub programu doskonalenia

- Istnieje potrzeba sprawdzenia hipotez i zebrania dowodów dotyczących przyczyn, objawów i skutków problemów oraz sugerowanych udoskonaleń

- W kulturze organizacji pokłada się większe zaufanie w analizach opracowanych wewnętrznie w oparciu o lokalne dowody niż w modelach zbudowanych zewnętrznie (wzorcowych lub opartych o zawartość)

- Interesariusze wywodzący się z różnych dziedzin mają być osobiście zaangażowani w proces analizy (na przykład w sesjach burzy mózgów)

- Zespół kontroluje analizą

Można też stosować podejścia mieszane, takie jak stosowanie podejść analitycznych w ramach modelu procesowego lub opartego o zawartość, na przykład:

- Stosowanie analizy przyczyn podczas programu doskonalenia procesu testowego zgodnie z TMMi

- Stosowanie metryk podczas programu doskonalenia procesu testowego STEP

6. Proces doskonalenia                                    900 minut

Terminologia:

działanie, raport z oceny, zrównoważona karta wyników, korporacyjna tablica rozdzielcza, diagnozowanie, ustalanie, IDEAL, rozpoczęcie, uczenie się, ocena procesu, plan doskonalenia testów, polityka testów

Cele nauki dla rozdziału „Proces doskonalenia”:

Uwaga: aby osiągnąć cele tego rozdziału, należy zastosować konkretne umiejętności, które opisane są w Rozdziale 7. Konieczne mogą okazać się również informacje o zarządzaniu zmianą (Rozdział 8) oraz kluczowych czynnikach sukcesu (Rozdział 9) .

6.1 Wstęp

6.1.1      (K2) Kandydat potrafi krótko opisać kluczowe elementy polityki testów.

6.1.2      (K6) Kandydat potrafi stworzyć politykę (doskonalenia) testów.

6.2 Rozpoczynanie procesu doskonalenia

6.2.1      (K2) Kandydat potrafi podsumować działania fazy Rozpoczęcia w ramach modelu doskonalenia IDEAL.

6.2.2      (K4) Kandydat potrafi przeanalizować cele biznesowe (np. wykorzystywanie korporacyjnej tablicy rozdzielczej lub zrównoważonej karty wyników) w celu określenia właściwych celów testowych.

6.2.3      (K6) Kandydat potrawi stworzyć strategię doskonalenia (włącznie z określeniem zakresu doskonalenia procesu testowego) dla podanego scenariusza.

6.3 Diagnozowanie aktualnej sytuacji

6.3.1      (K2) Kandydat potrafi podsumować działania fazy Diagnozowania w ramach modelu doskonalenia IDEAL.

6.3.2      (K6) Kandydat potrafi zaplanować i wykonać wywiady ewaluacyjne przy użyciu określonego modelu opartego na procesie lub zawartości, z pokazaniem świadomości stylu przeprowadzania wywiadu oraz umiejętności interpersonalnych.

6.3.3      (K6) Kandydat potrafi stworzyć i przedstawić podsumowanie wniosków (w oparciu o analizę wyników) oraz wyniki oceny.

6.3.4      (K2) Kandydat potrafi krótko opisać podejście do analizy rozwiązań.

6.3.5      (K5) Kandydat potrafi zarekomendować działania mające na celu doskonalenie procesu testowego na podstawie wyników ewaluacji i przeprowadzonej analizy.

6.4 Ustanawianie planu doskonalenia testów

6.4.1      (K2) Kandydat potrafi krótko opisać działania fazy Ustanawiania w ramach modelu doskonalenia IDEAL.

6.4.2      (K4) Kandydat potrafi wybrać i uszeregować rekomendacje przy użyciu podanej listy kryteriów.

6.4.3      (K2) Kandydat potrafi porównać wstępujące podejście do doskonalenia z podejściem zstępującym.

6.4.4      (K2) Kandydat potrafi krótko opisać zawartość planu doskonalenia testów.

6.4.5      (K6) Kandydat potrafi stworzyć plan doskonalenia testów.

6.5 Działania mające na celu wprowadzenie udoskonaleń

6.5.1      (K2) Kandydat potrafi krótko opisać czynności fazy Działania w ramach modelu doskonalenia IDEAL.

6.5.2      (K4) Kandydat potrafi wybrać odpowiednie rozwiązanie pilotażowe z listy możliwych rozwiązań.

6.6 Uczenie się na podstawie doskonalenia

6.6.1      (K2) Kandydat potrafi krótko opisać czynności fazy Uczenia się w ramach modelu doskonalenia IDEAL.

6.1 Wstęp

Proces doskonalenia testów powinien mieć jasno określone cele zapisane w polityce testowania danej organizacji (por. Polityka Testów w sylabusie dla poziomu zaawansowanego). Polityka doskonalenia procesu testowego powinna opierać się na ogólnie rozumianej polityce testów. Skuteczne doskonalenie procesu testowego wymaga systematyczności. W Dziale 2.4 przedstawiono ogólny proces doskonalenia, wprowadzając pojęcia cyklu Deminga oraz modelu doskonalenia procesu IDEAL. W niniejszym rozdziale, proces doskonalenia został szczegółowo opisany przy użyciu modelu doskonalenia IDEAL [IDEAL 96]. Podejście to można zastosować do dowolnego modelu cyklu. Każda z sekcji opisanych poniżej odnosi się do poszczególnych podstawowych działań w ramach modelu IDEAL:

- Rozpoczęcia

- Diagnozowania

- Ustanawiania

- Działania

- Uczenia się

6.2 Rozpoczęcie procesu doskonalenia

Rozpoczęcie doskonalenia procesu jest chyba najważniejszym krokiem w procesie doskonalenia procesu testowego. Działania podjęte na tym etapie bezpośrednio wpływają na ostateczne wyniki procesu doskonalenia. Efektem źle rozpoczętego procesu doskonalenia mogą być dalekie od oczekiwań rezultaty oraz znacznie mniejsze perspektywy podjęcia jakichkolwiek inicjatyw doskonalenia w przyszłości.

Model IDEAL przedstawia następujące podstawowe działania, należące do fazy „Rozpoczęcia”:

- zidentyfikowanie bodźców dla doskonalenia,

- określenie kontekstu oraz zdobycie sponsorów,

- nakreślenie infrastruktury doskonalenia (tzn. organizacji).

W oparciu o podstawowe działania w ramach modelu IDEAL, należy na tym etapie uwzględnić następujące elementy:

- określić faktyczną potrzebę doskonalenia,

- zdefiniować cele i dopasować je do potrzeb biznesowych,

- ustalić zakres doskonalenia,

- wybrać strategię doskonalenia (por. Rozdział 5),

- uwzględnić wpływ czynnika ludzkiego i kultury.

6.2.1 Określenie potrzeby doskonalenia

Pierwszym krokiem w określeniu potrzeby doskonalenia powinno być uświadomienie sobie, czym jest doskonalenie procesu. Najbardziej oczywiste potrzeby doskonalenia procesu testowego wynikają z poważnych awarii oprogramowania, z których część związana jest z niedostatecznym procesem testowym. Jednakże motywacja do zmian może być różnoraka. Może ona pochodzić od przynajmniej jednego z niżej wymienionych interesariuszy:

- zarząd/ klient (np. skuteczniejsze testowanie, mniej problemów w wersji produkcyjnej),

- użytkownik (np. większa użyteczność),

- programista (np. lepsza pomoc w analizie błędów),

- tester (np. ustalenie większej systematyczności w testowaniu),

- utrzymanie (np. mniejsza ilość czasu potrzebna na testowanie zmian w oprogramowaniu).

Obszary podlegające doskonaleniu można określić i zdefiniować w oparciu o wstępną analizę i rozmowy z poszczególnymi interesariuszami (aby dowiedzieć się więcej o wymaganych umiejętnościach przeprowadzania wywiadów i analizy, patrz Dział 7.3). W ramach analizy może okazać się, że konieczne jest określenie bieżących wskaźników takich jak całkowity koszt jakości, w oparciu o całkowity koszt awarii w trakcie użycia operacyjnego oraz całkowity koszt testowania (patrz Dział 4.4.3.1, Organizacyjne koszty jakości, i Dział 6.2.2).

6.2.2 Ustalenie celów doskonalenia testów

Główne cele doskonalenia procesu testowego muszą zawsze być ustalone w odniesieniu do jakości, kosztu, czasu i wartości biznesowej. Czynność ta powinna składać się z trzech podstawowych kroków:

- ustalenia ogólnej wizji (leszej) przyszłości,

- wyznaczenia konkretnych celów,

- dopasowania doskonalenia testowania do celów biznesowych.

Zazwyczaj cele doskonalenia testów udokumentowane są w ramach polityki testów stosowanej przez organizację.

6.2.2.1 Ustalenie ogólnej wizji przyszłości

Doskonalenie procesu testowego powinno skupiać się na zyskach oczekiwanych przez sponsora oraz ogólnej wizji zamierzonych celów.

Wizja przyszłości, o której mowa, jest konieczna dla inicjatyw doskonalenia z następujących względów:

- Przed zapewnieniem potrzebnych środków, sponsorzy muszą mieć pewność, że osiągną oczekiwany zwrot z inwestycji

- Zarządzanie wszelkimi zmianami musi mieć odniesienie do ustalonych celów

Niezdefiniowanie wspólnej wizji może skutkować niepowodzeniem zaplanowanych udoskonaleń testowania (patrz Rozdział 9), ponieważ:

- Źle zdefiniowane cele mogą ukrywać nierozwiązane konflikty interesów

- Może okazać się, że skupiamy się na niewłaściwych lub nieosiągalnych celach, co może okazać się marnowaniem zasobów albo też sprawi, że proces doskonalenia zakończy się niepowodzeniem

6.2.2.2 Określenie szczegółowych celów

Konkretne, dobrze zdefiniowane cele są konieczne w każdym przypadku doskonalenia procesu testowego. Wynikają z tego następujące korzyści:

- Można podjąć właściwe działania

- Można określić kryteria powodzenia (lub niepowodzenia) podjętych działań związanych z doskonaleniem procesu testowego

Istnieje wiele możliwości przedstawienia celów:

- Cele jakościowe, często określone poprzez odpowiednie skale (np. od „bardzo źle” do „bardzo dobrze” lub „ulega poprawie” do „ulega pogorszeniu”) lub kwestionariusze

- Cele ilościowe, wykorzystujące metryki. Na przykład, podejście Cel, Pytanie, Miara (GQM, parz Dział 4.3) umożliwia definiowanie metryk i może być wykorzystywane do zestawienia celów z mierzalnymi rezultatami.

- Cele wyrażone w formie poziomów dojrzałości. Jeśli doskonalenie procesu testowego ma być przeprowadzone przy użyciu modelu procesu, cele mogą także zostać wyrażone w formie właściwej dla zastosowanego modelu. Zazwyczaj wymaga to zdefiniowania określonych docelowych poziomów dojrzałości, zarówno dla procesu testowego jako takiego, jak i dla jego poszczególnych aspektów.

6.2.2.3 Dostosowanie doskonalenia testowania do organizacji

Doskonalenie procesu testowego musi być dostosowane do:

- celów biznesowych

- wszelkich realizowanych ulepszeń procesu tworzenia oprogramowania

- ulepszeń organizacyjnych (patrz. Rozdział 2)

- struktuty organizacyjnej

Dzięki korporacyjnym tablicom rozdzielczym oraz zrównoważonym kartom wyników możliwe jest dostosowanie doskonalenia testowania do celów danej organizacji, takich jak:

- Cele finansowe – zwiększenie produktywności, dochodu, zysków, obrotu firmy, zgodnie z definicją jakości w oparciu o wartość

- Podwyższenie jakości produktu – zgodnie z definicjami jakości w oparciu o produkt, wytwarzanie i użytkownika

- Cele związane z klientami – zwiększenie udziału w rynku, zadowolenia klienta, usprawnienie procesów zarządzania ryzykiem, zgodnie z definicją jakości w oparciu o użytkownika

- Cele wewnętrzne – większa przewidywalność wyników danego projektu, mniej błędów w trakcie tworzenia oprogramowania, krótszy czas ukończenia projektu i zmniejszona pracochłonność/koszty, zgodnie z definicją jakości w oparciu o wytwarzanie. Także outsourcing i offshoring mogą być uważane za cele wewnętrzne, gdyż mogą wyjątkowo skutecznie zmniejszyć koszty procesu testowego i umożliwić firmom skoncentrowanie się na podstawowym obszarze kompetencji.

- Cele dotyczące doskonalenia i innowacji – nowe rynki/branże, zwiększona ilość nowych produktów wprowadzonych do obrotu, czas wprowadzenia produktu do obrotu oraz akredytacja procesów/modeli/norm (np. model CMMI lub norma przemysłowa), zgodnie z definicją jakości w oparciu o wartość

- Cele personalne – zadowolenie z pracy, fluktuacja kadr, zmniejszenie urlopów chorobowych lub innych rodzajów nieobecności, odnoszące się do dowolnej definicji jakości, a jednocześnie mogące mieć wpływ na jakość definiowaną w oparciu o przekraczanie oczekiwań (zaufanie, reputacja)

- Cele społeczne/polityczne - wpływ organizacji na środowisko, reputacja i reklama, które mogą odnosić się do dowolnej definicji jakości, a jednocześnie wpływające na pojęcie jakości w oparciu o przekraczanie oczekiwań (zaufanie, reputacja)

6.2.3 Ustalenie zakresu doskonalenia

Ustalenie zakresu doskonalenia procesu testowego wymaga uwzględnienia takich elementów jak:

- Ogólny zakres procesów - procesy znajdujące się poza zakresem procesu testowego

- Zakres procesu testowego - części procesu testowego, do których należy się odnieść

- Poziomy testów - ustalenie, które poziomy testów wchodzą w zakres programu doskonalenia

- Zakres projektu - ustalenie czy ramy zakresu obejmują projekt(y) czy organizację

6.2.3.1 Ogólny zakres procesu

Zakres doskonalenia może dotyczyć ogólnych aspektów procesu tworzenia oprogramowania, takich jak zarządzanie projektem, wymaganiami i konfiguracją. Ważne jest by uświadomić sobie czy założone cele doskonalenia mogą być rzeczywiście osiągnięte jedynie poprzez poprawę procesu testowego, czy też powinny zostać poprawione także inne procesy (np. zarządzanie usługami, tworzenie oprogramowania oraz procesy pomocnicze opisane w [ITIL]). W tym drugim przypadku, potrzebne będą dalsze zasoby i wiedza specjalistyczna.

6.2.3.2 Zakres procesu testowego

Poprawa tylko wybranych obszarów procesu testowego może być bardziej opłacalna niż zajmowanie się wszystkimi możliwymi obszarami. W zależności od potrzeb, można udoskonalić wszystkie aspekty procesu testowego lub skupić się na pojedynczych jego elementach (np. planowaniu testów).

Jeżeli zakres doskonalenia testów ogranicza się do wybranych aspektów, należy ze szczególną starannością zwrócić uwagę na wszystkie pozostałe zależności. Doskonalenie tylko wybranych aspektów może jednak prowadzić do suboptymalizacji. Przykładowo, czy ma sens, aby w ramach doskonalenia skupiać się na opracowywaniu programu metryk testowych skoro nie są one używane (np. nie są używane w raportowaniu testów)?

6.2.3.3 Zakres projektu

Doskonalenie testów może być zorganizowane w oparciu o potrzeby programu/projektu lub organizacji.

Doskonalenie zorientowane na program/projekt koncentruje się na indywidualnym projekcie lub pewnej grupie projektów (tj. programie). Procesy oceny, często też nazywane audytami, są zwykle przeprowadzane razem z zespołem testerów danego projektu (np. z testerami, kierownikami testów). Zakres uwzględnianych ulepszeń procesu testowego może być ograniczony do relatywnie małego zbioru zadań związanych z procesem, takich jak planowanie testów lub techniki testowania. Wąsko ukierunkowane programy doskonalenia mogą być wyjątkowo opłacalne, pod warunkiem, że zakres procesu testowego został starannie określony, jak już wspomniano o tym w Dziale 6.2.3.2.

Doskonalenie zorientowane na program/projekt może relatywnie szybko dać wynik, jednak może okazać się, że nie odnosi się do problemów na poziomie organizacyjnym. Udoskonalenia na poziomie organizacyjnym mogą mieć trwalsze wyniki i przynosić więcej korzyści, choć będą wymagały większych nakładów zarówno czasu, jak i finansów.

Doskonalenie zorientowane na organizację koncentruje się na organizacji, wydziale lub grupie testującej. Oprócz oceny poszczególnych projektów, ważna jest organizacja jako całość. Główny nacisk położony jest na te aspekty procesu testowego, które dotyczą wszystkich projektów (np. szkolenia, organizacja).

W pierwszej fazie modelu IDEAL – „Rozpoczęcie” - określa się infrastrukturę doskonalenia procesu [IDEAL 96]. Dotyczy ona sposobu zorganizowania struktury programu usprawniania testów. Kwestie te są szerzej omówione w Dziale 7.1.

6.2.4 Wpływ innych ludzi i kultury na fazę rozpoczęcia

Istnieje znaczna ilość czynników ludzkich, które mogą wpłynąć na osiągnięcie celów doskonalenia. Istotnymi czynnikami wpływającymi na krytyczny czynnik sukcesu w fazie rozpoczęcia są:

- poziom wiedzy,

- kultura organizacyjna,

- kultura ludzi,

- poziom akceptacji.

Dodatkowe informacje dotyczące umiejętności miękkich koniecznych w zespole doskonalącym oraz wpływu czynników ludzkich na zarządzanie zmianą oraz kulturą organizacyjną znajdują się w Rozdziałach 7, 8 i 9.

Rekomendacje dotyczące doskonalenia testów powinny uwzględnić kwestie ludzkie i w każdym momencie powinna istnieć możliwość zasugerowania alternatywnych strategii doskonalenia, w zależności od stylu, kultury i potrzeb ludzi w danej organizacji.

6.3 Diagnoza aktualnej sytuacji

Model IDEAL opisuje następujące podstawowe działania należące do fazy „Diagnozowania”:

- Ocena i charakterystyka bieżących praktyk

- Opracowanie rekomendacji i rezultatów etapu dokumentacji

Końcowym rezultatem tej fazy jest zwykle raport z oceny testów.

W oparciu o czynności wysokiego poziomu modelu IDEAL, na tym etapie należy uwzględnić następujące czynniki:

- Planowanie oceny

- Przygotowanie oceny

- Przeprowadzanie wywiadów

- Przekazanie informacji zwrotnej

- Analiza wyników

- Wykonanie analizy możliwych rozwiązań

- Rekomendacja działań związanych z doskonaleniem

Czynności wykonywane na tym etapie zależą od wybranego podejścia do doskonalenia procesu testowego (patrz Rozdział 5).

Jeśli przyjęte zostanie podejście w oparciu o analizę (patrz Rozdział 4), można zastosować różne techniki analizy przyczyn (Dział 4.2) oraz przeanalizować metryki, miary oraz wskaźniki (Dział 4.4).

Jeśli przyjmie się podejście w oparciu o model (patrz Rozdział 3), zostanie zaplanowana i przeprowadzona ocena. Kwestie te są szczegółowo omówione w Działach od 6.3.1 do 6.3.3.

6.3.1 Planowanie oceny

Plan oceny jasno określa i ustala czas wykonania takich czynności jak:

- Przygotowanie oceny

- Analiza  wstępna

- Przygotowanie materiałów do wywiadów, takich jak listy kontrolne

- Gromadzenie istniejących testaliów (np. plany testów, specyfikacje testowe)

- Przeprowadzenie wywiadów z osobami sprawującymi rożne role w procesie testowym:

- Tester

- Kierownik testów

- Programista

- Kierownik projektu

- Właściciele przedsiębiorstwa

- Analitycy biznesowi (eksperci z danej dziedziny)

- Specjaliści, tacy jak dyrektor ds. ochrony środowiska, kierownik ds. zarządzania defektami, kierownik wersji produktu, specjaliści automatyzacji testów

- Określenie zagadnień, które należy poruszyć w każdym z wywiadów

- Wstępne informacje zwrotne, które należy przekazać po zakończeniu oceny (terminy, formuły, oczekiwania)

- Informacje przedstawiane osobie, z którą przeprowadza się wywiad, dotyczące kolejnych kroków

W Planie Oceny należy zapewnić by wszystkie obszary testowe zostały sprawdzone zgodnie z celami (Dział 6.2.2) i zakresem (Dział 6.2.3) ustalonymi na etapie rozpoczęcia. Jest też wskazane, żeby dla niektórych obszarów ten sam temat był poruszony w różnych wywiadach, co umożliwi sprawdzenie spójności.

6.3.2 Przygotowanie oceny

Często, jeszcze przed przystąpieniem do wywiadów, wykonuje się wstępną analizę dokumentów. W przypadku, gdy zakres oceny jest na poziomie organizacyjnym, będą to takie dokumenty jak polityka testów, opis procesu testowego, dostępne szablony oraz główny plan testów. Jeśli będzie to poziom projektu/programu, należy wziąć pod uwagę plany testów, specyfikacje testowe i raporty z testów. Także dokumenty dostarczone przez pozostałych interesariuszy (programistyczne, biznesowe, etc.) mogą okazać się istotne, jeśli wchodzą w zakres oceny (patrz Dział 6.2.3).

Celem analizy jest:

- zrozumienie aktualnego procesu testowego przed przeprowadzeniem wywiadów z osobami w nim zaangażowanymi

- przygotowanie poszczególnych pytań na potrzeby wywiadów

- przeprowadzenie formalnych elementów oceny nie wymagających omówienia. Na przykład, można sprawdzić dokumenty pod kątem ich kompletności i zgodności ze standardami.

Przed rozpoczęciem wywiadów zaleca się przygotowanie odpowiedniego otoczenia. Takie otoczenie powinno być:

- wygodne

- bez zakłóceń

- dające poczucie prywatności

6.3.3 Przeprowadzanie wywiadów

Wywiady przeprowadzane są zgodnie z Planem oceny (patrz Dział 6.3.1). Treść wywiadu uzależniona jest od zastosowanego modelu (patrz Rozdział 3).

W większości przypadków wywiady są przeprowadzane pojedynczo, aby ankietowany mógł swobodnie wyrazić swoją opinię w poczuciu „bezpieczeństwa”. Osoba przeprowadzająca wywiad powinna zawsze przed oceną omówić jak ważne jest zachowanie dyskrecji dla ankietowanych i osób przekazujących informacje, zwłaszcza, jeśli poruszane będą delikatne kwestie. Z tego też powodu, zaleca się, aby nie przeprowadzać wywiadu w obecności przełożonych.

Wypowiedzi będą szczere, jeśli:

- zapewniona zostanie dyskrecja,

- pomysły udoskonalenia spotkają się z aprobatą,

- nie istnieje obawa przed karą lub porażką,

- ankietowani zostaną poinformowani, w jaki sposób mogą zostać wykorzystane informacje, które podadzą.

Aby móc skutecznie przeprowadzić wywiad, potrzebne jest wiele umiejętności, które szczegółowo zostały opisane w Dziale 7.3.1.

6.3.4 Opinia wstępna

Zaraz po zakończeniu wywiadów można wydać wstępną opinię, zwykle w formie krótkiej prezentacji lub przejrzenia. Jest to pomocne zwłaszcza w sytuacji potwierdzenia wyników wstępnej oceny z osobą ankietowaną, w celu wyjaśnienia wszystkich nieporozumień lub nakreślenia ogólnego zarysu najważniejszych punktów dla interesariuszy. Należy zwrócić szczególną uwagę, aby zachowana została zasada dyskrecji i aby uniknąć oskarżania za zidentyfikowane w trakcie wywiadu problemy.

6.3.5 Analiza wyników

W przypadku zastosowania analitycznego podejścia do procesu doskonalenia (Rozdział 4), bieżąca sytuacja może być analizowana poprzez wprowadzenie takich pojęć jak:

- Myślenie systemowe [Weinberg 92]

- Punkt krytyczny [Gladwell]

Myślenie systemowe pomaga analizować relacje pomiędzy elementami rożnych systemów (procesów) i przedstawiać je jako cykle stabilne (równoważące) lub cykle wzmacniające. Cykl wzmacniający może mieć wpływ negatywny („błędne koło”) lub pozytywny („koło sukcesu”).

Punkty krytyczne pomagają określić konkretne punkty systemu, dla których drobne i dobrze ukierunkowane udoskonalenie może przerwać błędne kolo i dać początek reakcji łańcuchowej kolejnych udoskonaleń.

Jeśli zastosowane jest podejście do doskonalenia procesu testowego w oparciu o model (Rozdział 3), dokonuje się porównania pomiędzy dojrzałością procesu w bieżącym momencie a pożądanymi celami określonymi w fazie rozpoczęcia.

O ile istnieje taka możliwość, do ewaluacji wyników należy wykorzystać odpowiednie wzorce, takie jak:

- wzorzec firmowy, reprezentujy całą organizację

- wzorzec branżowy, odnoszący się do tego samego segmentu biznesowego

- wzorzec projektowy, gdzie porównuje się do konkretnego projektu spełniającego oczekiwane cele

Jeśli ustalone zostały kluczowe wskaźniki wydajności (patrz Dział 4.4 i Dział 6.2.2), należy je także włączyć do analizy. Na przykład, jeśli odsetek wykrytych błędów (OWB) spada poniżej wymaganego poziomu, należy wykonać analizę usterek w trakcie użycia produkcyjnego w celu ewaluacji ich źródeł.

Wyniki ewaluacji powinny być wystarczające do stworzenia rekomendacji i kontynuowania procesu planowania (patrz Działy 6.3.7 i 6.4 poniżej).

6.3.6 Wykonanie analizy rozwiązań

Analiza rozwiązań wykorzystywana jest do określenia potencjalnych rozwiązań danych problemów, a następnie wybrania konkretnego rozwiązania. Jakiekolwiek ulepszenie lub rozwiązanie może być wybrane na wiele sposobów:

- Z góry przyjęte właściwe rozwiązanie dotyczące ulepszenia - już zadecydowaliśmy, jakie jest rozwiązanie danego problemu, np. „zautomatyzujmy wszystko”. W takim przypadku etap analizy rozwiązań nie jest w ogóle wykonany. Wadą takiego rozwiązania jest fakt, że zbyt szybko przyjęte rozwiązanie może nie odnosić się do przyczyn źródłowych problemu i może nawet pogorszyć sytuację.

- Zalecone rozwiązania mogą być częścią modelu zastosowanego do oceny jako kluczowe praktyki/obszary. Zaletą jest zewnętrzny dowód na to, że dostępna praktyka jest użyteczna. Wadą jest fakt, że „następna w kolejności przyjęcia praktyka” tego modelu może w pewnych okolicznościach nie odnosić się do przyczyn źródłowych problemu, a nawet pogorszyć sytuację.

- Wymagania ze strony klienta lub interesariusza - np. klient może wymagać od wszystkich dostawców by spełniali normę ISO9001:2008. Dobrą stroną takiej sytuacji są jasno sprecyzowane zamierzenia i cele, złą - fakt, że wymagane zmiany w procesie mogą nie gwarantować doskonalenia lub mogą kolidować z innymi zaplanowanymi ulepszeniami.

- W oparciu o analizę rozwiązań w odniesieniu do dostępnych informacji o problemie. Dobrą stroną jest fakt, że zarówno negatywne i pozytywne konsekwencje każdego zaproponowanego rozwiązania są omówione, a co za tym idzie, wybrane rozwiązania są możliwie najkorzystniejsze a ich efekty uboczne możliwie najbardziej zminimalizowane. Minusem tej opcji jest fakt, że proces analizy wymaga czasu, zasobów i pieniędzy.

- Dopasowana do sytuacji metoda wybierania rozwiązania, łącząca powyżej przedstawione opcje, np. interesariusz wymaga przyjęcia Zintegrowanego Modelu Dojrzałości Testów (TMMi) na poziomie 4, przeprowadzona zostaje analiza kosztów i korzyści, i na tej podstawie podjęta zostaje decyzja o częściowym przyjęciu modelu TMMi na poziomie 3. Zaletą takiego podejścia jest to, że analiza rozwiązań jest ukierunkowana, wadą - fakt, że proces analizy wymaga czasu, zasobów i pieniędzy.

W zależności od wybranej metody, proces analizy rozwiązań zawiera jeden lub więcej  następujących elementów:

- ustalenie hierarchii problemów i ich przyczyn źródłowych w celu wybrania odpowiednich rozwiązań

- określenie korzyści ekonomicznych i innych korzyści, z uwzględnieniem ryzyka związanego z niewdrożeniem rozwiązania

- określenie kosztów, ryzyka i negatywnych efektów wprowadzenia danego rozwiązania

- określenie ograniczeń we wdrażaniu rozwiązań

- określenie konfliktów, takich jak rozwiązania wzajemnie się wykluczające lub niekompatybilne

- analiza cykli informacji zwrotnej (zarówno błędnych kół, jak i kół sukcesu)

- ocena i ustalenie kolejności rozwiązań

- przeprowadzenie analizy luki rynkowej na podstawie informacji i metryk zebranych podczas wcześniejszych działań

- przeprowadzenie analizy kosztów i korzyści w celu oszacowania zwrotu kosztów inwestycji

- zbudowanie diagramów rybiej ości, na których oś użyta w analizie przyczyn źródłowych jest odwrócona, a wspólnie zaproponowane rozwiązania są zestawione z tą osią odpowiednio do konkretnych, wcześniej zidentyfikowanych przyczyn źródłowych. Można dodać też odpowiednie nagłówki dla ograniczeń, jak na przykład ograniczenia budżetowe, ograniczenia zasobów oraz czasowe.

6.3.7 Rekomendowanie działań mających na celu doskonalenie

Raport z oceny musi odnosić poszczególne rezultaty do określonych celów doskonalenia procesu testowego. Raport ten powinien być przedstawiony zaraz po ukończeniu oceny, jeśli to możliwe w wersji wstępnej, która później będzie zastąpiona kompletnym raportem.

Każdy raport z oceny musi zawierać przynajmniej następujące elementy:

- Raport dla zarządu, odnoszący się do wizji firmy (patrz Dział 6.2.2.1)

- Deklarację zakresu i celów

- Wyniki analizy, w tym:

- aspekty pozytywne

- aspekty wymagające poprawy

- kwestie otwarte

- Listę rekomendacji ulepszeń

O ile to możliwe, rekomendacje powinny być przedstawione jako wymagania udoskonaleń (np. „dostarczyć narzędzia wpierające system śledzenia defektów”), które będą mogły być wdrożone na wiele różnych sposobów (np. „zastosować narzędzie XYZ i zapewnić szkolenie”). Zadanie wdrażania rekomendacji jest omówione w Dziale 6.5.

Rekomendacja dotycząca doskonalenia powinna zawierać następujące informacje:

- unikatowy identyfikator (w celu utrzymania kontroli)

- wpływ rekomendacji na co najmniej jeden z określonych celów (o ile to możliwe z wykorzystaniem skali, aby wskazać stopień spełnienia celu jako „minimalny”, „częściowy”, „całkowity” lub jako wartość procentowa)

- oszacowane koszty i korzyści

- okres wdrożenia (np. krótko-, średnio-, długoterminowe)

- ryzyko wdrożenia (np. spodziewany duży opór wobec procesu zmian, ryzyko związane ze zrealizowaniem poszczególnych ulepszeń)

- zależności i założenia (np. założenie, że stosowana jest też inna rekomendacja)

Planowanie i kontrola ogólnych rekomendacji może być łatwiejsza, jeślizalecenia zostaną podzielone na pomniejsze etapy doskonalenia z wymiernymi rezultatami.

Pewne modele procesów, takie jak Doskonalenie Procesu Testowego (TPI Next), zawierają określone sugestie dotyczące doskonalenia, aby pomóc w zadaniu tworzenia rekomendacji.

6.4 Tworzenie planu doskonalenia testów

Model IDEAL opisuje następujące podstawowe działania w ramach fazy „Ustanawiania”:

- ustalenie priorytetów,

- opracowanie podejścia,

- zaplanowanie działań.

Końcowym rezultatem tego etapu jest zwykle plan doskonalenia testów.

W oparciu o wyżej wymienione ogólne działania według modelu IDEAL, należy uwzględnić na tym etapie następujące czynniki:

- ustalenie priorytetów,

- opracowanie podejścia do wdrożenia,

- planowanie działań potrzebnych do doskonalenia.

6.4.1 Ustalenie priorytetów.

Rekomendacje z etapu „ustanawiania” zostają uszeregowane zgodnie z listą kryteriów, według ich ważności w kontekście potrzeby doskonalenia i w zależności od zaangażowanych interesariuszy.

Konieczne kryteria, które należy wziąć pod uwagę to:

- Czas trwania doskonalenia - należy dążyć do równowagi pomiędzy doskonaleniem krótko- i długoterminowym. Przewagą doskonalenia krótkoterminowego (łatwego do wdrożenia) jest to, że szybko widać zwrot kosztów inwestycji i może ono spełniać silną funkcję motywacyjną dla zespołu wdrożeniowego. Doskonalenie długoterminowe odnosi się do zasadniczych modyfikacji w procesie testowym, w tym kwestii kulturowych i organizacyjnych.

- Ryzyko wdrożeniowe - wiele ulepszeń wymaga zmiany istniejących praktyk testowych. Każda taka zmiana wiąże się z konkretnym ryzykiem. Należy zatem uwzględnić następujące czynniki:

- Możliwość odstąpienia od doskonalenia i powrotu do istniejącego stanu

- Ogólny wpływ „kluczowych” ulepszeń na cały program doskonalenia, zwłaszcza jeśli pozostałe ulepszenia są zależne od powodzenia tego konkretnego sposobu

- Możliwość rzeczywistego wdrożenia doskonalenia. Czy są dostępne wystarczające zasoby? Czy kluczowi członkowie zespołu wdrożeniowego mogą przyjąć inne zadania? Czy można zidentyfikować ryzyko w ramach procesu zmian (patrz Rozdział 8), takie jak opór wobec określonych zmian?

- Koszty/korzyści zaproponowanych ulepszeń (najlepiej wyrażone jako wartość zwrotu kosztu inwestycji)

- Odniesienie do celów - czy można wykazać jasny związek pomiędzy zaproponowanymi ulepszeniami a określonymi celami biznesowymi?

- Zdolność skutecznego wywierania nacisku - jaki będzie wpływ danego ulepszenia na określone cele (np. duży, średni, mały)?

6.4.2 Opracowanie podejścia do wdrożenia.

Rekomendacje dotyczące doskonalenia są uwzględniane i szeregowane przez interesariuszy. Dzięki temu można wybrać określone podejście do wdrożenia zmian, ściśle związane z zakresem doskonalenia określonym na etapie rozpoczęcia. Wyróżnia się dwa główne podejścia:

- Zstępujące

- Wstępujące

Podejście zstępujące charakteryzuje się następującymi cechami:

- Zakres doskonalenia zwykle dotyczy poszczególnych projektów lub całej organizacji

- Właścicielem procesu doskonalenia może być specjalnie stworzony do tego zespół

- Konieczna jest szczegółowa analiza wyników w celu określenia cech wspólnych (dobrych i złych praktyk) łączących różne projekty

- Szczególnie ważne są umiejętności prezentacji i negocjacji dla osiągnięcia porozumienia w sprawie celów i rekomendacji

- Do szczególnie ważnych krytycznych czynników sukcesu należą (więcej - patrz Rozdział 9):

- Efektywne zarządzanie kadrami

- Umiejętność zdobycia sponsorów

- Zarządzanie oczekiwaniami

Podejście wstępujące charakteryzuje się następującymi cechami:

- Zakres doskonalenia dotyczy zwykle tylko jednego lub dwóch projektów

- Wybrane podejście jest często mniej formalne. Na przykład, pojedyncze projekty mogą stosować podejście analityczne, zamiast wprowadzania bardziej formalnego podejścia opartego na modelu, takiego jak TPI Next.

- Właścicielem procesu doskonalenia jest zwykle osoba należąca do zespołu danego projektu

- Najczęstszym celem jest prototypowanie poszczególnych ulepszeń w celu zdobycia doświadczenia i stworzenia wsparcia

- Podejście to może być zastosowane w przypadku posiadania ograniczonego budżetu na program doskonalenia testowania, a istnieje konieczność przedstawienia kosztów/korzyści

- Wyniki strategii wstępującej mogą być wykorzystane do następującego później zstępującego wprowadzenia sprawdzonych środków doskonalenia

6.4.3 Planowanie udoskonaleń

Główne działania w zakresie planowania to:

- Uzgodnienie konkretnych środków w oparciu o rekomendacje

- Ustanowienie wymaganych wskaźników wydajności (patrz Rozdziały 2, 4 oraz 6)

- Ustalenie hierarchii oraz pogrupowanie ulepszeń w pakiety (doskonalenie etapowe)

- Zestawienie zagadnień dotyczących doskonalenia z rekomendacjami i wymaganymi wskaźnikami wydajności, które należy osiągnąć, np. poprzez założenie bazy danych ulepszeń

- Wybór podejścia do procesu doskonalenia (patrz Dział 6.4.2)

- Stworzenie harmonogramu zmian

- Powołanie grup lub zespołów mających wdrożyć ulepszenia (patrz Dział 7.1.1)

- Przydzielenie zadań

- Dokumentowanie wyżej wymienionych elementów w ramach planu doskonalenia testów

Model IDEAL opisuje dwa możliwe plany działania:

- Strategiczny plan działania o następujących cechach:

- Okres trwania od trzech do pięciu lat

- Obejmuje on całościowe doskonalenie procesu testowego w organizacji i łączy je z innymi działaniami dotyczącymi poprawy procesu tworzenia oprogramowania oraz pozostałymi zaplanowanymi lub realizowanymi inicjatywami zarządzania poprzez jakość (TQM).

- Taktyczny plan działania o następujących cechach:

- Krótki okres trwania, zwykle nie dłużej niż rok

- Ukierunkowanie na szczegółowy plan działań grupy zajmującej się procesem testowym (grupy odpowiedzialnej za wdrożenie ulepszeń). Więcej informacji na ten temat przedstawia Dział 7.1.1.

6.5 Działania związane z wdrożeniem usprawnień

Model IDEAL opisuje następujące podstawowe działania należące do fazy „Działania”:

- Stworzenie rozwiązania

- Wdrożenie pilotowe/testowe rozwiązania

- Ulepszenie rozwiązania

- Pełne wdrożenie rozwiązania

W oparciu o wyżej wymienione działania, należy koniecznie uwzględnić na tym etapie następujące czynniki:

- Wybór i przeprowadzenie wdrożeń pilotowych

- Zarządzanie i kontrolowanie zmianą

6.5.1 Wybór i przeprowadzenie wdrożeń pilotażowych

Wdrożenia pilotażowe zaproponowanych ulepszeń są skutecznym sposobem na zminimalizowanie ryzyka niepowodzenia, nabycie doświadczenia, stworzenie wsparcia i zredukowanie możliwości niepowodzenia wdrożenia. Jest to szczególnie ważne w przypadku, kiedy ulepszenia wiążą się ze znacznymi zmianami sposobu pracy lub wymagają wiele zasobów.

Wybór rozwiązania pilotażowego powinien uwzględniać:

- Realizm - czy pilotaż przestawia  „realny świat”? Należy uważnie wybierać projekty pilotażowe, aby uniknąć wyborów nierealistycznych projektów, motywowanych tylko tym, że są szybkie i łatwe do wykorzystania.

- Skalowalność rozwiązania - czy pilotażowe wyniki mogą być wykorzystywane we wszystkich kontekstach? Jeśli wdrożenie pilotażowe nie jest reprezentatywne w odniesieniu do złożoności i rozmiarów prawdziwych projektów, pojawia się ryzyko, że wprowadzone ulepszenie nie będzie odzwierciedlało prawdziwej skali.

- Wpływ na bieżące projekty - wdrożenia pilotażowe nie powinny być wykonywane na bieżących projektach, chyba  że ich wpływ będzie do zaakceptowania. Szczególnej uwagi wymaga sytuacja, kiedy istniejące praktyki mają być zastąpione na czas pilotażu ulepszonymi praktykami. Lepszym rozwiązaniem jest wprowadzenie nowych praktyk równolegle z już istniejącymi, co może jednak spowodować problemy z zasobami (nie można oczekiwać, że osoby pracujące w projekcie będą wykonywać to samo zadanie dwa razy z powodu wdrożenia pilotażowego).

- Ryzyko niepowodzenia - chociaż zastosowanie rozwiązań pilotażowych jest środkiem zmniejszającym ryzyko, należy też ocenić ryzyko niepowodzenia wdrożenia pilotażowego. Wyżej wymienione aspekty są istotnymi czynnikami w ocenie wdrożenia pilotażowego i powinny uwzględniać zarówno finansowe, jak i motywacyjne ryzyko niepowodzenia wpływające na cały projekt doskonalenia.

6.5.2 Zarządzanie i kontrola wdrożenia

Wdrożenie planu doskonalenia testów jest przeprowadzane, monitorowane, a postęp w osiągnięciu celów doskonalenia jest raportowany. Miary, metryki i wskaźniki określone w planie doskonalenia testów są gromadzone ii porównywane z ustalonymi celami.

Jeśli analiza zdbytych podczas wdrożenia pilotażowego doświadczeń daje wynik pozytywny, można podjąć decyzję wprowadzwnia ulepszenia do innych części organizacji lub innych projektów. Wdrażanie ulepszeń powinno przebiegać według określonego procesu, zwłaszcza, jeśli zmiany dotyczą całej organizacji. Ten decydujący aspekt doskonalenia procesu testowego jest opisany w Rozdziale 8.

6.6 Uczenie się na podstawie doskonalenia

Model IDEAL opisuje następujące podstawowe działania należące do fazy „Uczenia się”:

- Analiza i ocena

- Proponowanie przyszłych rozwiązań

Podczas trwania i po wdrożeniu planu doskonalenia testów, razem z interesariuszami wykonuje się retrospektywy projektu, podczas których analizowane są osiągnięte cele. Retrospektywy, zwykle w formie warsztatów, zarządzane są przez organizację lub osobę, która wdrażała ulepszenia.

W zależności od wyników retrospektywy, można określić przyszłe działania, w tym, między innymi, przeprowadzenie nowego cyklu doskonalenia, np. rozpoczęcie etapu diagnozowania (Dział 6.2).

7. Organizacja, role i umiejętności                  465 minut

Terminologia:

oceniający, zachowanie współzależne, inteligencja emocjonalna, główny oceniający, mapa myśli, grupa zajmująca się procesem testowym (TPG), osoba doskonaląca proces testowy, analiza transakcyjna

Cele nauki dla rozdziału „Organizacja, Role i Umiejętności”:

Dostawcy szkoleń powinni uwzględnić cele w oparciu o umiejętności (Dział 7.3) oraz cele z Rozdziału 6.

7.1 Organizacja

7.1.1      (K2) Kandydat rozumie role, zadania i obowiązki grupy zajmującej się procesem testowym w ramach programu doskonalenia procesu testowego.

7.1.2      (K4) Kandydat potrafi ocenić przydatnosć różnych struktur organizacyjnych do przeprowadzenia programu doskonalenia procesu testowego.

7.1.3      (K2) Kandydat rozumie wpływ outsourcingu lub offshoringu działań deweloperskich na organizację programu doskonalenia procesu testowego.

7.1.4      (K6) Kandydat potrafi stworzyć strukturę organizacyjną dla podanego zakresu programu doskonalenia procesu testowego.

7.2 Poszczególne Role

7.2.1      (K2) Kandydat rozumie poszczególne role w zakresie programu doskonalenia procesu testowego.

7.3 Umiejętności

7.3.1      (K2) Kandydat rozumie umiejętności konieczne do wykonania oceny.

7.3.2      (K5) Kandydat potrafi ocenić osoby zajmujące się testami (np. potencjalnych członków grupy zajmującej się procesem testowym lub technicznej grupy roboczej) ze szczególnym uwzględnieniem ewentualnych braków podstawowych umiejętności miękkich potrzebnych do przeprowadzenia oceny.

7.3.3      (K3) Kandydat wykorzystuje umiejętności przeprowadzania rozmów, słuchania oraz sporządzania notatek podczas oceny, np. w trakcie wykonywania wywiadów na etapie „Diagnozowania bieżącej sytuacji”.

7.3.4      (K3) Kandydat wykorzystuje zdolności analityczne w trakcie oceny, np. podczas analizowania wyników na etapie „Diagnozowania bieżącej sytuacji”.

7.3.5      (K2) Kandydat rozumie umiejętności prezentowania i raportowania w trakcie programu doskonalenia procesu testowego.

7.3.6       (K2) Kandydat rozumie umiejętności perswazji w programie doskonalenia procesu testowego.

7.1 Organizacja

Wdrożenie doskonalenia procesu testowego może być skuteczniejsze, jeśli stworzy się organizację gwarantującą poprawne wdrożenie ulepszeń oraz będącą „właścicielem” procesu doskonalenia (patrz Dział 9.1). Dotyczy to w szczególności programów doskonalenia realizowanych na poziomie całej organizacji. W przypadku programów doskonalenia o mniejszej skali, należy rozważyć czy warto ponosić koszty osobnej organizacji doskonalącej.

Przydatne informacje na temat organizacji doskonalącej proces testowy podają [Burnstein 03] oraz [IDEAL 96].

7.1.1 Grupa zajmująca się procesem testowym

Według definicji [Burnstein 03] grupa zajmująca się procesem testowym (TPG) to grupa osób, które mogą współpracować z innymi organizacjami zajmującymi się jakością, takimi jak grupa ds. procesów inżynierii oprogramowania (SEPG).

Grupa TPG powinna być stałą częścią organizacji, nie jedynie doraźnym rozwiązaniem. Wynika to z następujących powodów:

- Zakres doraźnych grup doskonalących jest często zawężony do pojedynczego projektu lub zakresu danego problemu. Stała grupa TPG ma szerszy zakres działania i może łatwiej zidentyfikować i zaproponować ulepszenia dotyczące organizacji.

- Wdrażanie zaproponowanych środków doskonalących jest lepiej kontrolowane przez stałą grupę TPG. W przypadku doraźnej grupy doskonalącej istnieje ryzyko, że może ona rozwiązać się zanim zostaną całkowicie wdrożone wszystkie ulepszenia. Brak odpowiedniej kontroli może uniemożliwić osiągnięcie lub odnotowanie ustalonych celów.

- W wyspecjalizowanej grupie najlepiej rozwijają się liczne i zróżnicowane umiejętności konieczne do przeprowadzenia skutecznej doskonalenia procesu testowego.

- Stała grupa TPG może funkcjonować jako „właściciel” procesu testowego i stanowi ważny kanał komunikacyjny dla głównych interesariuszy.

- Wiele modeli dojrzałości (np. TMMi) zakłada obecność stałej grupy TPG, jako wskaźnika większej dojrzałości procesu testowego.

[Burnstein 03] podaje, że w skład skutecznej grupy TPG mogą wchodzić uznane osobistości z różnych dziedzin (np. zarządzania, rozwoju, testowania) i które można uznać za praktyków. Dzięki temu proces testowy wzbogacony zostaje o cenne spostrzeżenia, zwłaszcza w zakresie jego złożoności oraz wzrasta poziom akceptacji wobec zaproponowanych sugestii doskonalenia (zdanie uznanych praktyków jest lepiej postrzegane niż opinia czystych teoretyków).

Model IDEAL [IDEAL 96] opisuje następujące jednostki wchodzące w skład organizacji doskonalenia procesu:

- Zarząd Główny (EC)

- Występuje w większych organizacjach

- Zajmuje się kwestiami strategii i kierownictwa

- Grupa sterująca zarządzaniem (MSG)

- W jej skład wchodzą kierownicy wyższego szczebla wywodzący się z istniejących już w organizacji struktur zarządzania

- Wyznacza cele, kryteria powodzenia i priorytety

- Kieruje wdrożeniami w organizacji

- Zapewnia zasoby

- Wyznacza techniczne grupy robocze do określonych aspektów doskonalenia procesów

- Techniczna grupa robocza (TWG)

- Działa doraźnie, kiedy zachodzi potrzeba wypełnienia określonych celów

- Bada problemy i proponuje rozwiązania grupie sterującej zarządzaniem

- Przeprowadza prototypowanie

- Poprawia taktyczny plan działania na podstawie wniosków z prototypowania

Model IDEAL przewiduje przykładowe statuty dla każdej z tych jednostek organizacyjnych.

Organizacja zajmująca się poprawą procesu testowego skupia sie przede wszystkim na procesie, ale powinna wziąć na siebie także obowiązki związane ze szkoleniem. Stała poprawa procesu może zostać osiągnięta tylko wtedy, kiedy zaangażowane w nią osoby stale się dokształcają. Cele organizacji, jej członkowie, role, obowiązki i główne płaszczyzny współpracy z innymi częściami organizacji powinny zostać jasno określone i dopasowane do polityki testów (patrz sylabus poziomu zaawansowanego).

7.1.2 Doskonalenie testów w zespołach zdalnych, offshoringowych i outsourcingowych

Dużo łatwiej jest zorganizować i przeprowadzić wszystkie etapy procesu doskonalenia w sytuacji, kiedy zespoły zaangażowane w doskonalenie pracują w tej samej organizacji, w tym samym miejscu, niż w sytuacji, kiedy należą one do różnych organizacji czy pracują w różnych lokalizacjach.

Jeśli jakakolwiek część cyklu życia oprogramowania jest podzlecona firmie zewnętrznej lub offshoringowej, mogą pojawić się trudności w komunikowaniu problemów, przyczyn źródłowych, rozwiązań, oraz dowodów i planów na wprowadzenie zmian. W takim przypadku zespoły zajmujące się doskonaleniem powinny uwzględnić następujące czynniki:

- Wszelkie ewentualne polityczne, kulturowe lub wynikające z umowy nieporozumienia, które mogą wymagać ulepszenia, mogą blokować lub zniechęcać do zaproponowanych usprawnień, lub w wyniku których doskonalenie może nie być odpowiednio zrozumiane lub może dotknąć drażliwych problemów

- Rozplanowanie czasowe komunikacji, uwzględniające kolejność informowania o zmianach, a także lokalne święta, dni wolne, różne strefy czasowe, itp.

- Informowanie i zaangażowanie wszystkich stron we wszystkie etapy - od rozpoczęcia procesu doskonalenia, przez zbieranie informacji, wybór rozwiązań, wdrożeń pilotażowych i programów zmian

- Uzyskiwanie od wszystkich stron informacji zwrotnej dotyczących powodzenia (lub jego braku) programu doskonalenia.

Potencjalne problemy mogą pojawić się w następujących sytuacjach:

- Macierzysty zespół testowy ma inny poziom dojrzałości procesów, wydajności i skuteczności w porównaniu do zespołu offshoringowego/outsourcingowego.

- Oczekiwania grup są rozbieżne, jeśli chodzi o proces, komunikację i kulturę jakości

- Założone procesy nie są do siebie dopasowane

•  Próby doskonalenia lub wprowadzenia zmian podejmowane przez którąkolwiek ze stron prowadzą do nieporozumień kulturowych i komunikacyjnych.

7.2 Poszczególne role

7.2.1 Osoba doskonaląca proces testowy

Osoba doskonaląca proces testowy powinna być w stanie przeprowadzić wszystkie zadania zgodnie z wytycznymi tego sylabusa.

Istnieje granica zmian, których dokonać może osoba doskonaląca proces testowy. Jeśli, na przykład, kierownicy ds. tworzenia oprogramowania lub klienci sami kontrolują swoje testy, nie leży to w kompetencjach doskonalącego proces testowy i wszelkie konieczne zmiany tych procesów testowych wykraczają poza jego zakres obowiązków.

Osoby doskonalące proces testowy powinny właściwie zrozumieć zakres, do którego mogą wprowadzać ulepszenia i jeśli zachodzi taka potrzeba, powinny zwracać się o pomoc do kierownictwa i innych grup. Ich rola może się ograniczyć jedynie do sugerowania pewnych ulepszeń procesu testowego niż do rzeczywistego wprowadzania ich. W organizacyjnych programach doskonalenia, osoba doskonaląca proces testowy podlega ogólnemu kierownikowi ds. zmian.

7.2.2 Role oceniających

Ponieważ wykonywanie oceny może wymagać wielu technicznych i miękkich umiejętności (por. Dział 7.3), konieczne jest być przypisanie konkretnej roli oceniającego.

Jeśli przyjęte zostanie podejście oparte na modelu, ocena powinna być wykonana przez osobę posiadającą specjalistyczną wiedzę dotyczącą zastosowanego modelu. W niektórych przypadkach (np. TMMi, CMMI, ISO/IEC 15504, EFQM) osoba taka musi przejść odpowiednie szkolenia i posiadać określone certyfikaty. Na przykład, podstawowy poziom Zintegrowanego Modelu Dojrzałości Testów (TMMi) odróżnia oceniających od głównych oceniających (więcej informacji o tych rolach i potrzebnych wymaganiach by stać się akredytowanym oceniającym można znaleźć na stronie internetowej [TMMi-Foundation-Web]).

7.3 Umiejętności osoby doskonalącej/oceniającej proces testowy

Powodzenie doskonalenia procesu testowego zależy od wielu umiejętności. Mogą to być umiejętności techniczne, takie jak analiza, lub nietechniczne, umiejętności interpersonalne, często określane mianem umiejętności miękkich. Poniższe umiejętności są istotne zarówno dla osób doskonalących proces testowych, jak i tych, które go oceniają:

- umiejętność przeprowadzania wywiadów,

- umiejętność słuchania,

- umiejętność prezentacji i raportowania,

- umiejętności analityczne,

- umiejętność sporządzania notatek.

Dla osób doskonalących proces testowy ważne są też następujące dodatkowe umiejętności:

- umiejętność perswazji,

- umiejętność zarządzania.

Wszystkie te umiejętności są wymagane dla osób dokonujących oceny. Poszczególne umiejętności mogą być również wymagane dla członków grupy zajmującej się procesem testowym lub technicznej grupy roboczej.

7.3.1 Umiejętność przeprowadzania wywiadów

Przeprowadzenie wywiadu można przedstawić jako proces opisany poniżej:

- otwarcie - określenie celów,

- zadawanie pytań,

- słuchanie - gromadzenie informacji (patrz Dział 7.3.1.4),

- podsumowywanie - przeprowadzane regularnie dla wszystkich spójnych części informacji,

- potwierdzanie - pogłębianie poziomu zrozumienia pomiędzy osobą prowadzącą wywiad a ankietowanym, poprzez zadawanie nowych pytań w oparciu o dokonane podsumowanie,

- zamknięcie - wyjaśnienie następnych etapów.

Umiejętność przeprowadzania wywiadów jest szczególnie ważna w gromadzeniu informacji i efektywnym ocenianiu. Dobry styl przeprowadzania wywiadów charakteryzuje się:

- zadawaniem otwartych pytań, na które nie można odpowiedzieć jedynie „tak” lub „nie”,

- nie ograniczaniem się jedynie do odczytywania kwestionariusza słowo po słowie,

- zachęcaniem do dyskusji, w której ankieter wykorzysta umiejętności interpersonalne (opisane w niniejszym dziale) w celu uwzględnienia w rozmowie wymaganych zagadnień

Interakcje pomiędzy ankieterem a ankietowanym są często złożone i bez niezbędnych umiejętności mogą prowadzić do nieporozumień, co skutkuje odmową podania informacji lub nawet podaniem mylnych lub błędnych informacji. Ankieterzy nie muszą być psychologami, powinni jednak posiadać ważne umiejętności interpersonalne, wynikające ze zrozumienia takich koncepcji jak:

- inteligencja emocjonalna [Mayer 04],

- analiza transakcyjna [Wagner 91],

- zachowanie współzależne [Copeland Paper 01].

7.3.1.1 Inteligencja emocjonalna

Inteligencja emocjonalna (EI) może pomóc zrozumieć i pokierować otoczeniem społecznym [Mayer 04]. Zaproponowany przez Petera Salovey’a i Johna D. Mayer’a model w oparciu o możliwości sugeruje, że pojedyncze osoby mogą różnić się pod względem zdolności przetwarzania informacji o charakterze emocjonalnym. Dla osób doskonalących proces testowy zdolność ta może być pomocna w przeprowadzaniu wywiadów, gdyż fakty są często tylko jednym z aspektów przekazu.

Model proponuje cztery typy zdolności mieszczące się w ramach inteligencji emocjonalnej:

- Postrzeganie emocji - umiejętność odgadywania i interpretowania emocji z twarzy i brzmienia głosu ankietowanego oraz zdolność określania własnych emocji

- Wykorzystywanie emocji - umiejętność wykorzystania emocji do rozważenia i analizy problemów.  Osoba doskonaląca proces testowy charakteryzująca się inteligencją emocjonalną potrafi obrócić na własną korzyść zmiany nastroju mające miejsce podczas wywiadu, aby uzyskać konkretne informacje lub poglądy ankietowanego.

- Rozumienie emocji - umiejętność zdania sobie sprawy ze złożonych relacji pomiędzy emocjami i tego, w jaki sposób mogą się one zmieniać w czasie

- Zarządzanie emocjami - umiejętność kontrolowania emocji zarówno własnych, jak i innych osób. Osoba doskonaląca proces testowy posiadająca inteligencję emocjonalną potrafi kierować emocjami w celu osiągnięcia zamierzonych celów wywiadu.

Możliwy jest pomiar inteligencji emocjonalnej zgodnie z modelem w oparciu o zdolność, jednak nie jest to umiejętność wymagana od osób doskonalących proces testowy.

7.3.1.2 Analiza transakcyjna

Idea analizy transakcyjnej w kontekście organizacji czy biznesu to według opisu Abe Wagnera [Wagner 91] koncepcja, według której każda osoba składa się z sześciu różnych „wewnętrznych osobowości”. Podzielone są one na dwie grupy - „skuteczną” i „nieskuteczną”.

Komunikacja z „osobowościami skutecznymi” jest uważana za pozytywną i konstruktywną.

- Dziecko Naturalne zachowuje się spontanicznie, wyraża swoje emocje i ma potrzebę uznania, struktury i stymulacji.

- Dorosły jest logiczny i rozsądny. Żyje raczej faktami niż emocjami

- Rodzic Opiekuńczy jest stanowczy, ale też pełen zrozumienia, wrażliwy i troskliwy

Komunikacja z „osobowościami nieskutecznymi” jest zwykle uważana za mało pomocną dla uzyskania jakichkolwiek informacji.

- Rodzic Krytyczny używa mowy ciała, gestów i tonu głosu, aby „zbesztać” innych, często w formie sarkazmu, pokazania palcem lub przez podniesienie głosu

- Zbuntowane Dziecko szybko się gniewa i trwa w gniewie, jest negatywnie nastawione, nie słucha, może specjalnie zaniedbywać lub odkładać pewne rzeczy na później

- Dziecko Uległe oskarża samo siebie, mówi cichym głosem, jest płaczliwe, bardzo ostrożne i samozachowawcze

Osoby doskonalące proces testowy, które rozumieją zasady analizy transakcyjnej są w stanie usprawnić swoje umiejętności prowadzenia wywiadów oraz rozróżnić prawdziwe wiadomości od podejrzanych informacji podawanych przez ankietowanych, sugerując przeredagowanie pytania lub (w bardziej skrajnych przypadkach) zmianę podejścia do wywiadu.

7.3.1.3 Zachowanie współzależne

Termin „współzależność” opisuje niepożądany wzór interakcji ludzkich, w których braki lub słabości jednej osoby są kompensowane przez inną osobę. Cytując Lee Copelanda [Copeland Paper 01]: „Robimy to, co złe, z dobrych pobudek”. Cechuje nas niezdrowe zainteresowanie potrzebami innych i czasem nawet przyjmujemy odpowiedzialność za zachowanie innych lub nawet je „rekompensujemy”.

Uświadomienie sobie współzależności jest ważne w doskonaleniu procesów testowych, gdyż takie chorobliwe współzależne interakcje mogą ukrywać prawdziwe powody poszczególnych problemów lub też, same w sobie, mogą stanowić problem.

Lee Copeland podaje charakterystyczne przykłady współzależności w kontekście produkcji oprogramowania:

- Programiści zgadzają się zaimplementować system bez jasnego zrozumienia potrzeb użytkowników

- Jeśli testerzy otrzymują nierealne harmonogramy pracy od kierownictwa, starają się „zrobić co możliwe”, testując jak najwięcej w dostępnym czasie

Przykłady te pokazują schemat nieodpowiednich zachowań (programistów, kierownictwa) i współzależnych reakcji. Na krótką metę, reakcje takie mogą być korzystne, jednak w dłuższej perspektywie, ich konsekwencje mogą być szkodliwe, gdyż wysyłana jest zła informacja - „nie dbamy o użytkowników” lub „estymacje testów są zawsze zawyżone”.

Osoby doskonalące proces testowy powinny znać typowe wskaźniki współzależności pojawiające się podczas wywiadu:

- Odpowiedzi typu „Staram się najlepiej jak mogę” (chociaż wiem, że to nieprawda)

- Odpowiedzi typu „Nieważne” (wymaga to poprawek, ale udaję, że jest dobrze)

- Odrzucanie ryzyka (może to doprowadzić do katastrofy, ale mógłbym mieć nieprzyjemności, jeśli o tym wspomnę)

- Odpowiedzi, w których ankietowany stara się przekonać ankietera, że zachowania w sposób oczywisty niepoprawne, są w jakimś stopniu „normalne”

Na dłuższą metę, osoby współzależne stają się ofiarami. Denerwuje je to, że wciąż muszą przyjmować sytuacje, które uważają za złe. Może pojawić się uczucie rezygnacji, kiedy zaczynają tolerować nienormalne, niezdrowe i niewłaściwe zachowania.

Osoby doskonalące proces testowy powinny docenić, że testerzy oprogramowania chcą być pomocni. Jednocześnie powinni starannie porównać krótkoterminowe korzyści zachowania współzależnego z długoterminowymi problemami przez takie zachowanie spowodowanymi. Sugestie ulepszeń powinny koncentrować się na kwestiach długoterminoych i na pomocy osobom współzależnym.

7.3.2 Umiejętność słuchania

Umiejętność słuchania jest przydatna do wydobywania konkretnych informacji z tego, co zostało powiedziane i do przygotowywania możliwych odpowiedzi. „Słuchanie aktywne” jest techniką, która, koncentruje się na osobie, do której się mówi, i która stanowi uporządkowane podejście do słuchania i udzielania odpowiedzi. [Atwater 81]

7.3.3 Umiejętność przygotowania prezentacji i raportów

Umiejętność przygotowania prezentacji i raportów jest ważna, by:

- uzyskać akceptację dla doskonalenia procesu testowego,

- w jasny sposób pokazać wyniki interesariuszom,

- sugerować konkretne ulepszenia.

Umiejętność prezentowania streszczeń dla zarządu pomaga skoncentrować się na kluczowych elementach na właściwym poziomie abstrakcji, bez uwzględniania mało istotnych szczegółów. Skuteczne zastosowanie takich umiejętności wymaga od prezentera:

- dokonania selekcji i wyboru jedynie kilku kluczowych pomysłów,

- konkretnego przedstawienia tego, w jaki sposób pomysły te będą funkcjonowały w kontekście własnym (lub klienta),

- realistycznego podejścia do czasu dostępnego na doskonalenie,

- posługiwania się językiem kierownictwa,

- przewidywania możliwych pytań.

Osoby doskonalące proces testowy są świadome, do kogo mówią podczas prezentowania i relacjonowania informacji. Definicje jakości przedstawione w Dziale 2.3 pomagają określić rodzaj i zakres przedstawianej informacji. Na przykład, sponsorzy zwykle przyjmują definicję jakości w oparciu o wartość, dlatego też należy przedstawić im takie informacje ogólne (np. sugestie ulepszeń), które wpłyną na ich biznes.

Można wymienić następujące szczegółowe umiejętności prezentacji i raportowania (patrz [Few 08]),[Tufte 90] i [Tufte 97]):

- projektowanie informacji,

- zdolność wybrania odpowiednich środków przekazu dla danych słuchaczy,

- zrozumienie właściwego użycia danych z metryk i statystyk,

- zrozumienie właściwego użycia diagramów, wykresów i ilustracji,

- skuteczne przemawiania na forum publicznym,

- umiejętność uzyskania komentarza od słuchaczy.

7.3.4 Umiejętności analityczne

Rozdział 4 opisuje serię technik odnoszących się do analitycznego podejścia do doskonalenia. Poniżej wymieniono ogólne umiejętności analizy wymagane do zastosowania takich technik:

- umiejętność podsumowania zebranych informacji,

- umiejętność określania trendów i wzorców informacji,

- umiejętność przekształcania informacji w inne formy, np. tekst na diagram przepływu procesu, mapę myśli na prezentację, etc.,

- uświadomienie sobie, kiedy analiza statyczna jest właściwa, a kiedy nie (patrz [Huff 93]),

- zrozumienie i rozróżnienie: (1) przyczyny i skutku, (2) korelacji i (3) przypadku podczas analizowania i raportowania danych,

●       zrozumienie zastosowania i analizy informacji statystycznych.

7.3.5 Umiejętność sporządzania notatek

Umiejętność ta pozwalają na skuteczne uchwycenie istotnych informacji. Jest to szczególnie ważne, na przykład, podczas przeprowadzania wywiadów.

Mapa myśli [Buzan 95] jest naturalną i łatwo przyswajalną techniką służącą do przygotowywania i kontrolowania wywiadów, ustalania związków pomiędzy poszczególnymi tematami oraz notowania. Wykorzystuje zasadę związków pomiędzy elementami wizualnymi (ilustracje) i tekstem. Dzięki temu można osiągnąć następujące korzyści:

- Można skutecznie uchwycić „obraz całokształtu”

- Robienie notatek jest szybsze i lepiej zorganizowane

- Łatwiej jest streścić prezentację

- Łatwiej jest nakreślić związek treści z pomysłami

- Łatwiej przypomnieć sobie główne punkty

Należy jednak pamiętać, że decyzja o zastosowaniu map myśli należy do prowadzącego wywiad. Niektórym ankieterom może przeszkadzać tworzenie map myśli podczas wywiadu, ze względu na konieczność przedwczesnej analizy. Alternatywnymi rozwiązaniami może być:

- zastosowanie naturalnego tekstu, aby zachować rzeczywiste odpowiedzi podane w wywiadzie,

- wykorzystanie form stenograficznych, takich jak słowa klucze,

- korzystanie z diagramów i schematów blokowych.

Może okazać się, że podczas sporządzania notatek, laptop będzie stanowił barierę pomiędzy ankieterem a ankietowanym, co może prowadzić nawet do niewypełnienia celów wynikających z umiejętności słuchania i przeprowadzania wywiadów. Dlatego też decyzja o robieniu notatek przy użyciu komputera powinna być dobrze przemyślana i uzgodniona z ankietowanym.

Niektórzy ankieterzy nagrywają swoich rozmówców w formie audio lub video i później przepisują rozmowę. Może być to przydatne, jednak konieczna jest zgoda ankietowanego i ustalenie tego, w jaki sposób później informacje te będą wykorzystane oraz kiedy i jak nagranie zostanie zniszczone, jeśli będzie to konieczne. Należy pamiętać jednak, że nagrywanie może wywołać u ankietowanych pewne skrępowanie, nawet, jeśli wcześniej wyrazili zgodę na podjęcie takich środków.

W niektórych sytuacjach, takich jak warsztaty grupowe, lepiej jest zebrać i pokazać notatki publicznie, wykorzystując na przykład tablice, samoprzylepne karteczki i oznakowane karty. Kiedy wszyscy zgromadzeni widzą notatki i mogą dodać do nich coś od siebie, łatwiej jest osiągnąć porozumienie i uzyskać akceptację sporządzonych notatek.

7.3.6 Umiejętność perswazji

Umiejętność te ważna jest dla osoby doskonalącej proces testowy, w przypadku, gdy trzeba przekonać głównych interesariuszy do konkretnego ulepszenia i ustalić wizję na przyszłość. Przykładem może być sytuacja, kiedy pojawia się pewien opór wobec zmian lub kiedy czas na zapoznanie się z problemami i podjęcie decyzji jest w jakiś sposób ograniczony.

Frank Milo [Frank 90] opisuje przydatną technikę, którą można zastosować w takiej sytuacji. Obejmuje ona następujące kroki:

- określ cele

- wybierz słuchaczy (o ile nie jest to oczywiste)

- wybierz podejście

- zastosuj element, który przyciąga uwagę

- poznaj temat

- poproś o cel (lub kolejny krok w celu osiągnięcia ich)

Techniki perswazji są także częścią technik sprzedaży i marketingu, o czym pisze Robert Cialdini [Cialdini] i przed czym ostrzega Ilene Burnstein [Burnstein 03].

7.3.7 Umiejętność zarządzania

Dla osoby doskonalącej proces testowy ważnych jest wiele umiejętności zarządzania związanych z konkretnymi zadaniami doskonalenia testów, jednakże ich szczegółowy opis nie wchodzi w zakres niniejszego sylabusa. Do takich umiejętności mogą należeć:

- planowanie,

- estymowanie,

- podejmowanie decyzji,

- zarządzanie ryzykiem.

8. Zarządzanie zmianą                                     285 minut

Terminologia:

zarządzanie zmianą

Cele nauki dla rozdziału „Zarządzanie zmianą”:

8.2 Podstawowy proces zarządzania zmianą

8.2.1      (K2) Kandydat potrafi krótko opisać podstawowy proces zarządzania zmianą.

8.2.2      (K6) Kandydat potrafi stworzyć plan doskonalenia testowania uwzględniający kwestie zarządzania zmianą oraz odpowiednie kroki i działania.

8.3 Czynnik ludzki w procesie zarządzania zmianą

8.3.1      (K2) Kandydat potrafi krótko opisać rolę czynnika ludzkiego w procesie zarządzania zmianą.

8.3.2      (K4) Kandydat potrafi przeanalizować podejście ludzi do zmiany i odniesieść je do modelu Satir

8.3.3      (K5) Kandydat potrafi zalecić środki w celu akceptacji zmian przez osoby zaangażowane w proces.

8.1 Wstęp

Doskonalenie procesu nie powiedzie się bez zarządzania zmianą. Większość inwestycji w doskonalenie znajduje się po stronie praktycznego wdrażania systemu. W niniejszym rozdziale zaprezentowano proces zarządzania zmianą jako serię kroków i działań.

8.2 Podstawowy proces zarządzania zmianą

Zmiany wymagane w ramach doskonalenia procesu z pewnością nie odniosą sukcesu, jeśli nie zostaną przeprowadzone w kontekście procesu zarządzania zmianą. Kotter i Rathgeber  [Kotter & Rathgeber 05] opisują osiem kroków przeprowadzania zmian, które mogą być zastosowane do jakiekolwiek dziedziny informatyki, w tym do doskonalenia procesu testowego.

Przygotowanie gruntu

Krok 1. Stworzenie poczucia pilnej potrzeby

- Określenie potrzeby doskonalenia (patrz Dział 6.2.1), najlepiej, jeśli wyrażona jest ona przez obiektywne pomiary i poparta stwierdzeniem ryzyka (np. ryzyka pojawiającego się w sytuacji niewprowadzenia zaproponowanych zmian)

- Wyjaśnienie, jakie zmiany będą miały miejsce, w jakiej kolejności oraz przedstawienie ich czasowego rozplanowania

- Otrzymanie widocznego wsparcia kierownictwa i potrzebnych środków

Krok 2. Zebranie grupy przewodzącej procesowi (np. grupa zajmująca się procesem testowym, Dział 7.1.1)

- Zaangażowanie użytkowników-pionierów jako orędowników zmiany

- Nadanie tym osobom roli „mnożnika” (tzn. pierwsze osoby będą przekazywać wiedzę i motywować następnych)

Decyzja, co robić

Krok 3. Stworzenie wizji i strategii zmiany

- Kierowanie oczekiwaniami (jasno wyznaczone cele oraz ich zakres - „nie zmieniamy całego świata”)

- Ustalenie strategii (por. Dział 6.2.2)

Urzeczywistnienie

Krok 4. Porozumienie w celu osiągnięcia zrozumienia i zaangażowania

- Dostarczenie informacji (prezentacje, pokazy, newslettery, itp.) nawiązujących do następujących kwestii:

- W jaki sposób podjęte środki zgadzają się z celami wyznaczonymi dla organizacji (strategia, polityka, wyzwania, etc.)

- W jaki sposób środki będą korzystne dla pracowników i jak pomogą im usprawnić ich pracę

- Poprzednie sukcesy i niepowodzenia, z zaznaczeniem, jakie różnice zostały wprowadzone tym razem

- Prototypowanie pomysłów (na początku wstępująca strategia doskonalenia w projekcie o małym ryzyku może wspierać prototypowanie)

- Motywowanie wszystkich osób, których zmiany dotyczą (patrz [Maslow], aby dowiedzieć się więcej na temat „Hierarchii potrzeb”)

Krok 5. Upoważnienie innych do działania

- Zapewnienie wsparcia kierownictwa w celu umożliwienia wprowadzenia zmian (np. poprzez pomoc w usunięciu przeszkód wobec zmian)

- Zapewnienie mechanizmu informacji zwrotnych dla osób, których zmiana dotyczy. W zależności od kultury może być wymagane zachowanie anonimowości.

Krok 6. Osiągnięcie krótkookresowych sukcesów

- Popieranie prostych osiągnięć - nagłaśnianie i nagradzanie ich - dzięki czemu nabiera się tempa i motywuje pracowników

- Uszeregowanie wszelkich prostych osiągnięć, co do których można spodziewać się, że ich efekt będzie bardziej dalekosiężny i nie będą musiały one być wycofane po szerszym rozważeniu ich

Krok 7. Wytrwałość

- Upewnienie się, że zstępujące strategie doskonalenia są wspierane przez oddzielny zespół doskonalący (np. grupa zajmująca się procesem testowym, Dział 7.1.1), który jest właścicielem procesu doskonalenia i zapewni, że zmiany zostaną wdrożone zgodnie z planem doskonalenia

Połączenie wszystkich elementów

Krok 8. Stworzenie nowej kultury

- Stopniowe wdrażanie i, o ile to możliwe, unikanie wielkich i nagłych zmian

- Określenie czy wprowadzane zmiany przyczyniły się do doskonalenia. Należy rozważyć każdy sukces jako możliwość oparcia się na tym, co było dobrze i określenie rzeczy, które jeszcze mogą być usprawnione.

- Nagłośnienie osiągnięcia celów („rób dobre rzeczy i mów o tym”). Może być to osiągnięte na podstawie metryk ilościowych lub skali jakościowej (np. na podstawie takich pytań jak - „Czy sytuacja się poprawia?”)

- Jeśli jakieś cele nie zostały osiągnięte, należy zapewnić analizę i poświadczenie powodów oraz wyciągnąć odpowiednie wnioski

- Zapewnienie, że wsparcie kierownictwa jest dostępne w przypadku jakichkolwiek problemów podczas wprowadzania zmian

- Zapoczątkowanie kultury ciągłego doskonalenia

8.3 Czynnik ludzki w procesie zarządzania zmianą

Dział ten odnosi się do różnego rodzaju sposobów podejścia ludzi do zmian oraz potrzeby uczenia się. Reakcja pojedynczego człowieka lub całej grupy wobec zmian zależy od ich wcześniejszych doświadczeń z wprowadzaniem zmian, ich stosunku do zmiany, poziomu zaufania organizacji i zakresu, w jakim zespół jest właścicielem zmian.

Proces zarządzania zmianą musi pozwalać na uświadomienie sobie, dyskutowanie i różne podejścia do zmian podczas planowania wdrożenia doskonalenia.

Przydatne informacje o aspektach ludzkich w kontekście zmian opisane są w [Karten 09] i [Kübler-Ross 07].

Kwestie poruszone przez Karten [Karten 09] odnoszą się do modelu Satir [Satir 91] i dotyczą ludzkiego aspektu zmian ze szczególnym odniesieniem do projektów informatycznych. Model Satir opisuje wpływ zmiany na wydajność lub produktywność poszczególnych ludzi lub grup i składa się z następujących elementów zmiany:

- Stare status quo - obecny, „normalny” stan

- Wprowadzenie wydarzenia zakłócającego („obcy element”)

- Chaos - reakcja na wydarzenie zakłócające

- Przekształcanie idei - droga wyjścia z chaosu

- Praktyka i integracja – przystosowanie się do zmiany

- Nowy status quo - nowy, „normalny” stan

Model Elizabeth Kübler-Ross [Kübler-Ross 07] bada etapy żałoby po bolesnej stracie i spodziewanej stracie, co może być wykorzystane w kontekście zmian biznesowych jako metafora tego, jak ludzie radzą sobie w praktyce ze zmianami. Później dodano także dodatkowe etapy (oznaczone gwiazdką *) [Adams et al]. Można wymienić następujące etapy:

- Ulga* - „w końcu wiem, co się dzieje”

- Szok lub zaskoczenie* - uczucie niedowierzania

- Wyparcie - całkowity brak akceptacji zmiany i próba udowodnienia sobie, że „to się nie dzieje”, połączona z nadzieją, że „to przeminie”

- Gniew - doświadczenie złości i frustracji

- Targowanie się - próba uniknięcia tego, co nieuniknione

- Depresja - „dół” i reagowanie na wszystko z apatią i smutkiem

- Akceptacja - przyjęcie rzeczywistości

- Eksperymentowanie* - po wewnętrznej akceptacji, pojawia się myśl, że może jest jeszcze „coś poza tym”

- Odkrycie* - odkrycie, że może rzeczywistość nie jest tak straszna jak wydawało się na początku

Warto zauważyć, że chociaż zarówno model Satir, jak i Kübler-Ross opisują etapy w procesie zmian, nie są to etapy, które następują po sobie liniowo. Ludzie, którzy doświadczają zmian niekoniecznie przechodzą przez wszystkie etapy w podanej kolejności. Także niektóre etapy mogą się powtarzać lub mogą w ogóle nie występować. „Etapy” są po prostu opisem emocjonalnych odpowiedzi na zmiany.

[Honey&Mumford 02], [Kirton web], i [Myers&Briggs 95] podają więcej informacji na temat:

- typów osobowości (np. wskaźnik typów osobowości Myers-Briggs),

- motywacji jednostek do zmiany i doskonalenia,

- kwestii, czy zmiana będzie przyjęta, czy odrzucona,

- kwestii, czy zespoły będą pionierami, czy ostatnimi użytkownikami doskonalenia,

- kwestii, czy będą przygotowani do eksperymentowania i przyjęcia niepowodzenia zmian, czy będą czekać do momentu aż zostanie zaproponowane „idealne” rozwiązanie,

- różnych stylów uczenia się preferowanych przez pojedyncze osoby, a co za tym idzie, dostępnych oraz interesujących sposobów prezentowania zaproponowanych zmian [Honey & Mumford],

•      indywidualnych preferencji dotyczących zmian poprzez adaptację istniejących metod lub przez innowację nowych metod [Kirton Web].

9. Krytyczne czynniki sukcesu                        300 minut

Terminologia:

krytyczne czynniki sukcesu, manifest poprawiania procesu testowego

Cele nauki dla rozdziału „Krytyczny czynnik sukcesu”:

9.1 Kluczowe czynniki sukcesu

9.1.1      (K2) Kandydat potrafi wyjaśnić ryzyka w przypadku nieuwzględnienia krytycznych czynników sukcesu.

9.1.2      (K5) Kandydat potrafi ocenić krytyczne czynniki sukcesu na potrzeby projektu doskonalenia procesu testowego.

9.1.3      (K5) Kandydat potrafi polecić odpowiednie środki łagodzące zidentyfikowane ryzyka projektowe.

9.2 Ustanowienie kultury doskonalenia

9.2.1      (K2) Kandydat rozumie czynniki ważne dla ustanowienia kultury doskonalenia.

9.2.2      (K6) Kandydat potrafi stworzyć plan doskonalenia testów uwzględniający czynniki kulturowe.

9.1 Kluczowe czynniki sukcesu

W Rozdziale 8 przedstawiono proces zarządzania zmianą jako kluczowy czynnik sukcesu podczas wprowadzania doskonalenia procesu testowego. W tym rozdziale omówione są, jako dwie oddzielne grupy, dodatkowe czynniki.

„Rozpoczęcie”

Pierwsza grupa czynników sukcesu odnosi się głównie do początkowego etapu projektu doskonalenia i może być związana z fazami „Rozpoczęcia” i „Diagnozowania” w ramach modelu doskonalenia IDEAL (Dział 2.4.2).  Są to:

- jasne, mierzalne i realistyczne cele wyznaczone dla procesu doskonalenia

- zaangażowanie kierownictwa i możliwość uzyskania sponsorowania

- doskonalenie testów zorganizowane jako formalny projekt

- wszystkie zaangażowane osoby mają wystarczającą ilość czasu na udział w projekcie

- ambicje zamapowane na dojrzałość organizacji (produkującej oprogramowanie)

- działający proces zarządzania zmianą (patrz Rozdział 8)

„Wykonanie”

Druga grupa czynników sukcesu nawiązuje do etapów wdrożenia projektu doskonalenia.  Można wymienić tu następujące czynniki:

- jasne ramy czasowe ulepszeń i zdefiniowane okresy cyklu podawania informacji zwrotnej; nie mogą być zbyt rozciągnięte, aby można było zachować właściwe tempo.

- jasne, mierzalne i realistyczne cele dla każdego cyklu

- Określona i zorganizowana własność procesu

- Kontrola i monitoring wszystkich kroków w procesie zarządzania zmianą (patrz Rozdział 8)

- Udział specjalistów ds. testowania podczas definiowania i wprowadzania ulepszeń

- Udział innych interesariuszy w przypadku, kiedy problemy znajdują się poza zakresem testowania, np. jakość specyfikacji, procesy zarządzania zmianą i wersją

- Opanowanie oporów wobec zmian, wykonanie działań marketingowych, np. poziom sprzeciwu będzie zależał od sukcesu lub niepowodzenia wcześniejszych prób doskonalenia

- Istniejące praktyki, o ile takie istnieją, są wykorzystywane - nie należy zmieniać dla samej idei zmieniania. Jeśli jakaś istniejąca praktyka nie jest wykorzystywana, należy najpierw zbadać przyczyny takiej sytuacji.

- Stały zorganizowany zespół projektowy, który dobrze współpracuje i angażuje się w zmianę/wizję

- Uwzględnione użycie narzędzii wspierających lub umożliwiających ulepszenia testów (por. Dział 2.5.4.2)

- Uwzględniona dostępna wiedza i umiejętności zaangażowanych osób. Dotyczy to nie tylko ogólnego testowania, ale też obszarów związanych z procesem doskonalenia i umiejętności używanych w podejściach do doskonalenia (np. specyficzne modele i techniki analizy)

- Czynniki ludzkie, takie jak style uczenia się, typy osobowości i postawy

- Zewnętrzni konsultanci zatrudniani w miarę potrzeb, np. kiedy potrzebna jest konkretna wiedza i umiejętności. Nie należy jednak oddawać im całkowitej kontroli nad projektem doskonalenia

- Świadomość zewnętrznych standardów, które mogą być obowiązujące, np. standardy Agencji ds. Żywności i Leków (FDA) w amerykańskim przemyśle medycznym

- Całokształt procesu i terminologii jasno zdefiniowane w celu zapewnienia, że różne elementy strategii doskonalenia są dopasowane do siebie i są częścią większej struktury

- Zbudowane relacje pomiędzy wszystkimi interesariuszami, których sytuacja dotyczy, np. specjalistami ds. doskonalenia procesu tworzenia oprogramowania, wydziałami zapewnienia jakości i zarządzania zasobami ludzkimi

- Wyraźnie pokazywany postęp

- Wewnętrzna akceptacja lub zastosowanie procesów regulacyjnych

- Zapewniona synchronizacja z innymi inicjatywami doskonalenia

•       Dojrzałość  rozwoju oprogramowania i testowania pozostają zasadniczo na równym poziomie w celu uniknięcia potencjalnych niespójności procesu

9.2 Ustanowienie kultury doskonalenia

Ulepszenia powinny być dostosowane do kontekstu kulturowego organizacji, czego przykładem mogą być:

- Kultura zarządzania (zarządzanie i kontrola, ukierunkowana na konsultacje i pracę zespołową) wpływać będzie na łatwość akceptowania zaproponowanego podejścia

- Położenie geograficzne organizacji (np. niektóre modele i podejścia do doskonalenia są lepiej przyjmowane w Stanach, inne np. w Azji)

- Cele, polityka i strategia oraz stosunek do doskonalenia (np. kwestia czy dane podejście do doskonalenia jest już wykorzystywane w organizacji i czy odnosi sukces)

- Relacje pomiędzy wydziałami, np. w momencie fuzji dwóch firm, może pojawić się niechęć wobec aspektów takich jak zmiany czy ulepszone procedury, jeśli te postrzegane są jako pochodzące z tej „drugiej” organizacji

- Zastosowany model cyklu życia (sekwencyjny, iteracyjny, zwinny, „domorosły” lub brak procesu) wpływać będzie na częstotliwość zmian procesu, które będą akceptowalne dla projektów

- Zastosowane podejście do testów (zautomatyzowane, manualne, skryptowe, eksploracyjne, łączone, ad hoc) wpływać będzie na łatwość zaakceptowania zasugerowanego rodzaju zmiany

Przykładem konkretnego podejścia jest manifest poprawiania procesu testowego [van Veenendaal Paper 08], który wzoruje się na manifeście Agile i proponuje rozważenie poniższych punktów:

Elastyczność ponad szczegółowe procesy - sugeruje, że organizacje będą musiały angażować się w zmiany i reagować na nie szerszym zakresem profili ryzyka. Potrzeba elastyczności oznacza też uznanie, że testerzy są pracownikami wiedzy i powinni przemyśleć, adaptować i stosować rożne procesy w zależności od określonego kontekstu danego projektu. Elastyczność i dowolność w procesie wskazuje na zaufanie pokładane w pracownikach i będzie motywować ich do dalszego doskonalenia.

Najlepsze praktyki w miejsce szablonów - pokazuje, że szablony mogą być przydatne, jednak przykłady są znacznie lepsze, gdyż pokazują jak korzystać z szablonów. Przykłady najlepszych praktyk nie muszą być standardem w branży - są one po prostu najlepszym rozwiązaniem w danych okolicznościach, zatem można oczekiwać kilku różnych przykładów do wyboru.

Ukierunkowanie na praktykę ponad ukierunkowanie na procesy - Samo budowanie procesów jest proste, problemy mogą pojawić się w momencie ich praktycznego wprowadzenia w życie, tak by ulepszenia zostały odpowiednio wykorzystane. Najważniejsze w doskonaleniu procesów jest zarządzanie zmianą. Znakomita większość inwestycji w proces doskonalenia to inwestycje w faktyczne zastosowanie praktyczne.

Przeglądy techniczne zamiast (departamentów) Zarządzania Jakością - wskazuje na istotność komunikacji i informacji zwrotnych dla powodzenia projektu. Dokładnie taka jest rola dobrze przeprowadzanych przeglądów koleżeńskich. Prowadzący przeglądy z działu Zapewnienia Jakości mogą być zbyt oddaleni od zespołu testowego, by na bieżąco dostarczać cennych komentarzy. Cykle informacji zwrotnej są najbardziej przydatne, gdy są lokalne i szybkie.

Ukierunkowanie na biznes a nie na model - przypomina, że doskonalenie ma być korzystne dla biznesu, a nie tylko dostosowywać się do zewnętrznych standardów.

Opisane powyżej podejście do doskonalenia może być przyjęte w organizacji przychylnej podejściom skierowanym na zespoły, stosującej zwinne metody tworzenia oprogramowania i testowanie eksploracyjne. Trudniej będzie wprowadzić je w organizacji zarządzanej poprzez polecenia i kontrolę, silnie polegającej na szczegółowych procesach i testowaniu skryptowym.

10. Przystosowywanie do różnych modeli cyklu życia      60 minut

Terminologia:

Agile, testowanie zwinne, programowanie ekstremalne, model cyklu życia, Scrum, retrospektywa projektu, RUP

Cele nauki dla rozdziału „Przystosowywanie do różnych modeli cyklu życia”:

10.1 Przystosowanie się do rożnych modeli cyklu życia

10.1.1      (K2) Kandydat rozumie czynniki wpływające na sposób, w jaki zorganizowane jest doskonalenie oraz faktu, że jest ono zawsze zależne od kontekstu.

10.1.2      (K2) Kandydat potrafi krótko opisać podejścia do doskonalenia testowania w środowiskach zwinnych.

10.1.3      (K2) Kandydat potrafi krótko opisać podejścia do doskonalenia testowania w środowiskach iteracyjnych.

10.1.4      (K2) Kandydat potrafi podać przykłady sytuacji, w których wymagane jest zaadaptowanie modeli doskonalenia procesu testowego w celu dopasowania ich do zwinnych lub iteracyjnych cykli życia.

10.1 Przystosowanie do rożnych modeli cyklu życia

Opisane wcześniej w niniejszym sylabusie metody doskonalenia nie są ograniczonene do jakiejkolwiek metodologii cyklu życia. Niemniej jednak, doskonalenie powinno być zawsze dokonane w określonym kontekście, na przykład:

- Kultura zarządzania w organizacji (skierowana na zarządzanie i kontrolę, konsultacje, pracę zespołową) wpływać będzie na łatwość przyjęcia zaproponowanego podejścia.

- Zastosowany model cyklu życia (sekwencyjny, iteracyjny, zwinny, „domorosły” lub brak procesu) wpływać będzie na częstotliwość cyklu zmian procesu, które będą akceptowalne dla projektów

- Zastosowane podejście do testowania (zautomatyzowane, manualne, skryptowe, eksploracyjne, łączone, ad hoc) wpływać będzie na łatwość zaakceptowania zasugerowanego rodzaju zmiany

Na przykład, przyjęcie cyklu zwinnego tworzenia oprogramowania oznacza:

- Nacisk na samozarządzające się zespoły, które mogą zmieniać własne procesy w miarę potrzeb

- Należy rozważyć związek podejść z kategorii lean, szczególnie na poziomie organizacyjnym

Czynniki te mogą wpłynąć na wybór metod doskonalenia, które preferowane są w lean managment, na przykład krótkie cykle Deminga i wykorzystanie diagramów przyczynowo–skutkowych. Nie oznacza to, że techniki te nie mogą być stosowane w innych modelach cyklu życia lub że podejścia w oparciu o model nie mogą być zastosowane dla organizacji lub projektów wykorzystujących zwinne cykle życia. Wybór cyklu życia nie powinien narzucać wyboru metody doskonalenia.

Każdy model procesu tworzenia oprogramowania lub testowania może być zastosowany jako punkt odniesienia do tego, jak rzeczywiście doskonalić te elementy, które ocenione zostały jako wymagające poprawy. W kontekstach zwinnych lub iteracyjnych wiele alternatywnych pomysłów prowadzi do różnych ścieżek doskonalenia, w przeciwieństwie do tradycyjnych modeli cyklu życia, które najczęściej mają przeważnie mają charakter sekwencyjny.

W kontekście iteracyjnym można wykorzystać pomysły używane w ramach RUP (Rational Unified Process), a w kontekście środowisk zwinnych – pomysły stosowane w ramach metodologii Scrum, takie jak retrospektywy na koniec każdego sprintu w celu zapewnienia szybkich cykli informacji zwrotnych i możliwości realizacji doskonalenia procesu co kilka dni. W projektach zwinnych wiele ścieżek doskonalenia modeli opartych o zawartość o charakterze sekwencyjnym musi być w znacznym stopniu odpowiednio dostosowywana. Testowanie zwinne, w kontekście określonym przez Scrum lub programowanie ekstremalne i inne powiązane rozwijające się praktyki testowania, może także zapewnić strukturę testowania, która będzie bardziej odpowiadała procesom zwinnym.

Modele sekwencyjne, takie jak model V zakładają cykle informacji zwrotnej w celu sprawdzenia zgodności i dopasowania do potrzeb produktu i procesu na końcu każdego z etapów (weryfikacja i walidacja). Na podstawie takich przeglądów na końcu etapu można przedstawić proponowane ulepszenia procesu testowego, wykorzystując dowolną metodę opisaną w tym rozdziale.

W przypadku, gdy założono określony poziom dojrzałości jako docelowy, na przykład CMMi, nie przeszkadza to w zastosowaniu dowolnego podejścia do doskonalenia testów, ani nie narzuca żadnego konkretnego modelu cyklu życia.

Główne zadania zespołu doskonalącego to:

- Określenie czy wybrany model cyklu życia sprzyja wyborowi konkretnego procesu doskonalenia

- Określenie poprawnego podejścia do metody doskonalenia procesu w danym kontekście

- Określenie właściwej struktury i praktyk testowych dla danego kontekstu

11. Materiały źródłowe

11.1 Normy

Oznaczenie

Norma referencyjna

11.1.1 [BS7925-2]

11.1.2 BS 7925-2 Software Component Testing

11.1.3 [IEEE 1044]

11.1.4 IEEE Std 1044™  IEEE Standard Classification for Software Anomalies

11.1.5 [ISO 25000]

11.1.6 ISO/IEC 25000:2005 Software engineering. Software product quality requirements and evaluation (SquaRE). Guide to SquaRE

11.1.7 [ISO/IEC 15504]

11.1.8 ISO/IEC 15504-5 ISO 15504 – SPICE (Software Process Improvement and Capability dEtermination), Part 5, Assessment Model [1998]

11.1.9 [ISO 9126]

11.1.10 ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality

11.1.11 [ISTQB-Glossary]

11.1.12 ISTQB Glossary of terms used in Software Testing, Version 2.1, available from [ISTQB-Web]

11.2 Znaki towarowe

W niniejszym dokumencie wykorzystano następujące znaki towarowe i usługowe:

CMM®, CMMI®, Model Doskonałości EFQM ™, TMM™, TMMi®, IDEALSM, ISTQB®, PSPSM, TMap®, TPI®, TPI Next® oraz TSPSM

- CMM i CMMI są  zarejestrowane w  Amerykańskim Urzędzie Patentowym przez Carnegie Mellon University

- Model Doskonałości EFQM jest znakiem towarowym Europejskiej Fundacji Zarządzania Jakością.

- IDEAL jest znakiem usługowym Software Engineering Institute (SEI), Carnegie Mellon University

- ISTQB jest zarejestrowanym znakiem towarowym International Software Testing Qualifications Board

- ITIL jest zarejestrowanym znakiem towarowym oraz zarejestrowanym społecznościowym znakiem towarowym Office of Government Commerce i jest zarejestrowany w Amerykańskim Urzędzie Patentowym.

- PSP i TSP są znakami usługowymi Software Engineering Institute (SEI), Carnegie Mellon University

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

- TMMi jest zarejestrowanym znakiem towarowym TMMi Foundation

- TPI jest zarejestrowanym znakiem towarowym Sogeti Nederland B.V.

- TPI Next jest zarejestrowanym znakiem towarowym Sogeti Nederland B.V.

11.3

Książki

Odnośnik

Opis książki

[Adams et al]

Adams, Hayes and Hopson, “Transition: Understanding & managing personal change”, 1976

[Anderson 01]

Anderson, L. W. and Krathwohl, D. R. (eds) (2001). „A Taxonomy for Learning, Teaching, and Assessing: A Revision of Bloom’s Taxonomy of Educational Objectives”, Allyn & Bacon.

[Atwater 81]

Eastwood Atwater, „I Hear You”. Prentice-Hall, 1981, ISBN: 0-13-450684-7

[Bernstein]

Bernstein A. J., „Emotional Vampires: Dealing With People Who Drain You Dry” McGraw-Hill Professional; ISBN: 978-0071381673

[Black03]

Rex Black, “Critical Testing Processes”, Addison-Wesley, 2003, ISBN: 0-201-74868-1

[Burnstein 03]

Ilene Burnstein, “Practical Software Testing”, Springer, 2003, ISBN: 0-387-95131-8

[Buzan 95]

Tony Buzan, „The Mindmap Book”, BBC-Books, 1995, ISBN: 0-563-37101-3

[Cialdini]

Cialdini, R, “Influence: The Psychology of Persuasion”, Harper Business ISBN: 978-0061241895

[Craig02]

Craig, Rick David; Jaskiel, Stefan P., “Systematic Software Testing”, Artech House, 2002, ISBN: 1-580-53508-9

[Copeland 03]

Lee Copeland, “A Practitioner’s Guide to Software Test Design”, Artech House, 2003, ISBN: 1-58053-791-X

[Evans04]

Isabel Evans, “Achieving Software Quality through Teamwork”, Artech House, 2004,  ISBN: 978-1580536622

[Few 08]

Few, S., „Information Dashboard Design: The Effective Visual Communication of Data”; ISBN: 978-0596100162

[Frank 90]

Milo O. Frank, “How to get your point across in 30 seconds or less”, Simon & Schuster 1990, ISBN: 0-552-13010-9

[Gilb & Graham]

Gilb, T., and Graham, D., „Software Inspection”, Addison Wesley 1993, ISBN: 0-201-63181-4

[Gladwell]

Gladwell, M., „The Tipping Point: How Little Things Can Make a Big Difference”; ISBN: 978-0349113463

[Honey&Mumford 02]

Honey, P. and Mumford, A., „The Learning Styles Helper’s Guide”, Peter Honey Publications, 2002, wyd. Peter Honey Publications Limited, 10 Linden Avenue, Maidenhead, Berks SL6 6HB lub strona [Honey-Web]

[Humphrey]

Humphrey, W.

„Introduction to the Team Software Process”, Massachusetts: SEI, 2000

„Introduction to the Personal Software Process”, Massachusetts: SEI, 1997

[Huff 93]

Darrell Huff, „How to Lie with Statistics”, W.W. Norton, 1993, ISBN: 0-393-31072-8

[ISTQB-CEP]

ISTQB Certified Tester Expert Level, Certification Extension Process, Version 1.0, June, 17th 2008. Dostępne pod adresem [ISTQB-Web]

ISTQB-EL-EXAM

ISTQB Exam Guidelines for Expert Level, Version 1.0, Dostępne pod adresem [ISTQB-Web]

[ITIL]

ITIL, Best Practice for Service Support, Office of Government Commerce, 2002

[ITIL2]

ITIL, Best Practice for Service Delivery, Office of Government Commerce, 2002

[IDEAL 96]

Bob McFeeley /Software Engineering Institute (SEI),  „IDEAL: A User’s Guide for Software Process Improvement”, 1996, CMU/SEI-96-HB-001

[Ishikawa 91]

„What Is Total Quality Control?  The Japanese Way”, Prentice Hall Business Classics, ISBN:013952441X

[Juran]

Quality Handbook (McGraw-Hill International Editions,  Industrial Engineering Series) ISBN: 0071165398

[Karten 09]

Naomi Karten, „Changing How You Manage and Communicate Change:

Focusing on the Human Side of Change”, IT Governance Publishing, 2009, ISBN: 978-1905356942

[Kotter & Rathgeber 05]

John Kotter and Holger Rathgeber, „Our Iceberg is Melting”, Pan Macmillan, 2005, ISBN: 978-0-230-01420-6

[Koomen/Pol 99]

Tim Koomen, Martin Pol, “Test Process Improvement”, Addison-Wesley, 1999,ISBN: 0-201-59624-5

[Kübler-Ross 07]

Elisabeth Kubler-Ross & David Kessler, „On Grief and Grieving: Finding the Meaning of Grief Through the Five Stages of Loss”, Scribner Book Company; Reprint edition, 5 Jun 2007, ISBN :978-0743266291

[Maslow]

Maslow, A H,

“Toward a Psychology of Being”, ISBN: 978-0471293095, Wiley 1998

“Maslow on Management”,  ISBN: 978-0471247807, Wiley, 1998

[Mayer 04]

Mayer, J.D., „Emotional intelligence: Key readings on the Mayer and Salovey model”, 2004, ISBN: 1-867943-72-2

[Myers&Briggs 95]

Myers, Isabel Briggs (1980). „Understanding Personality Type”.  Davies-Black Publishing; Reprint edition ,1995,  ISBN: 0-89106-074-X

[Nance & Arthur 02]

„Managing Software Quality: A Measurement Framework for Assessment and Prediction”, Springer, 2002, ISBN: 1852333936

[Page 08]

Page, A, Johnston, K, Rollinson B,  „How we test software at Microsoft”, pub Microsoft, 2008, ISBN: 978-0-7356-2425-2

[Pol.M & Van Veenendaal. E 98]

Pol.M and van Veenendaal. E, „Structured testing of information systems: an introduction to Tmap ®”, Kluwer, 1998, ISBN: 90-267-2910-3

[Robson 95]

„Problem Solving in Groups”, Gower, 1995, ISBN: 0-566-07415-x

[Satir 91]

Satir V., Banmen, J., Gerber J., Gomori M. „The Satir model: Family therapy and beyond”, Science and Behavior Books, Inc. 1991, ISBN 978-0-831400-78-1

[Sogeti 09]

Sogeti, “TPI Next – Business Driven Test Process Improvement”, UTN Publishing, 2009, ISBN 90-72194-97-7

[Trienekens & van Veenendaal 97]

Trienekens and van Veenendaal, “Software Quality from a Business Perspective”, Kluwer, 1997

[Tufte  90]

Tufte, E., „Visual Explanations”, Graphics Press, 1990, ISBN: 0-961-39214-2

[Tufte 97]

Tufte, E., „Envisioning Information”, Graphics Press, 1997, ISBN 0-961-39211-8

[Wagner 91]

„The Transactional Manager”, Spiro Press, ISBN: 978-185835496, 1996

[Weinberg 92]

Weinberg, G, „Quality Software Management, Vol. 1”, (92), Dorset House, 1992, ISBN: 0-932633-22-6

11.4 Referaty i artykuły

Odnośnik

Referat / artykuł

[Basili Papers]

- V.R. Basili, „Software Modeling and Measurement: The Goal Question Metric Paradigm,” Computer Science Technical Report Series, CS-TR-2956 (UMIACS-TR-92-96), University of Maryland, College Park, MD, wrzesień, 992.

- V.R. Basili, H. D. Rombach, „The TAME Project: Towards Improvement-Oriented Software Environments,” IEEE Transactions on Software Engineering, vol.SE-14, no.6, czerwiec 1988, pp.758-773.

- V.R. Basili, R.W. Selby, „Data Collection and Analysis in Software Research and Management,” Proceedings of the American Statistical Association and Biomeasure Society, Joint Statistical Meetings, Philadelphia, PA, sierpień 1984.

- R. Basili, D. M. Weiss, „A Methodology for Collecting Valid Software Engineering Data,” IEEE Transactions on Software Engineering, vol. SE-10, no.6, listopad 1984, pp. 728-738.

[Copeland Paper 01]

Lee Copeland, “When helping doesn’t help”, SQE Magazine, styczeń 2001

[Garvin Paper 84]

Garvin, D., “What does product quality really mean?”, Sloan Management Review, Vol. 26, No. 1, 1984

[Hackman and Oldman Paper 76]

J. R. Hackman, G. R. Oldham (1976). „Motivation through design of work”. Organizational behaviour and human performance 16: 250–279.

[van Veenendaal Paper 08]

van Veenendaal, E., „Test Process Improvement Manifesto”,  Testing Experience, grudzień 2008

11.5 Źródła internetowe

Źródła niniejsze zostały sprawdzone w momencie publikacji sylabusa dla poziomu eksperckiego, ISTQB nie podnosi odpowiedzialności w przypadku, gdy materiały te nie są już dostępne.

Odnośnik

Źródło

Link

[ISTQB-Web]

Strona internetowa International Software Testing Qualifications Board. Strona zawiera najnowszą wersję glosariusza i sylabusów ISTQB.

www.istqb.org.

[EFQM-Web]

Strona internetowa Europejskiej Fundacji Zarządzania Jakością (EFQM).

Uwaga: strona EFQM zawiera linki do modeli właściwych dla krajów/kontynentów, opartych na podstawowych koncepcjach doskonałości dla innych członków grupy GEM – Globalnego Modelu Doskonałości, w której skład wchodzą kraje członkowskie z Ameryki Północnej, Ameryki Łacińskiej, Australii i Singapuru.

Model EFQM jest tylko jednym z wielu przejawów stosowania tych koncepcji i podany jest w niniejszym dokumencie jako przykład.

www.efqm.org

[Honey -Web]

Strona internetowa Petera Honey’a

www.peterhoney.com

[Kirton -Web]

McHale, J., Innovators Rule OK-or do they?

www.kaicentre.com

[SEI-Web]

Strona internetowa Software Engineering Institute, dla publikacji CMM i CMMi oraz innych publikacji Software Engineering Institute

www.sei.cmu.edu

[SFIAWeb]

Strona internetowa SFIA Foundation (Skills Framework for the Information Age)

www.sfia.org.uk

[TMMi-Foundation-Web]

Strona internetowa Fundacji TMMi

www.TMMifoundation.org

12. Załącznik A – Uwagi dla prowadzących szkolenia

12.1 Czas przeznaczony na szkolenie

Na każdy rozdział niniejszego planu przeznaczono określoną liczbę minut. Celem tego zabiegu jest zarówno udzielenie wskazówek dotyczących względnej ilości czasu, który należy przeznaczyć na każdy z działów akredytowanego kursu, oraz podanie przybliżonej minimalnej ilości czasu na naukę każdego działu.

Prowadzący szkolenia mogą przeznaczyć więcej czasu na szkolenie niż wskazano, a kandydaci mogą przeznaczyć więcej czasu na lekturę i własne badania. Plan szkolenia nie musi naśladować kolejności rozdziałów niniejszego planu.

Nie wymaga się, aby kurs był prowadzony w jednym ciągłym bloku czasowym.

Zastosowano następujące wytyczne:

Poziom celu nauki

Minut (średnio)

K2

15

K3

60

K4

75

K5

90

K6

90

W tabeli poniżej przedstawiono wskazówki dotyczące czasu przeznaczonego na naukę i ćwiczenia dla każdego rozdziału. Osobno podano czas na wykonanie ćwiczeń, które mogą być przeprowadzone w miejscu pracy (wszystkie wartości podano w minutach). Ćwiczenia wykonywane w miejscu pracy mogą być również zrealizowane jako część kursu oferowanego przez prowadzącego szkolenie (patrz Dział 12.3.1 poniżej).

Nr

Rozdział

Szkolenie i ćwiczenia

Ćwiczenia w miejscu pracy

Razem

(minut)

1

Wstęp

60

0

60

2

Kontekst doskonalenia

285

0

285

3

Doskonalenie w oparciu o modele

390

90

570

44

Doskonalenie w oparciu o analizę

465

90

555

5

Wybór podejścia do doskonalenia procesu testowego

15

90

105

6

Proces doskonalenia

465

435

900

7

Organizacja, role i umiejętności

375

90

465

8

Zarządzanie zmianą

195

90

285

9

Krytyczne czynniki sukcesu

120

180

300

10

Przystosowywanie do różnych modeli cyklu życia

60

0

60

Total

2520

1065

3585

W tabeli poniżej przedstawiono całkowitą długość kursu w dniach, przyjmując średnio siedem godzin na dzień roboczy.

Element kursu

Dni

Godziny

Minuty

Nauka i ćwiczenia

6

0

0

Ćwiczenia w miejscu pracy

2

3

45

Ogółem:

8

3

45

12.2 Zastosowane normy

Niniejszy sylabus zwiera odniesienia do ustalonych norm (patrz Dział 11.1), które należy zastosować podczas przygotowywania materiałów szkoleniowych. Każda norma musi być zastosowana w wersji wymienionej w aktualnym wydaniu niniejszego sylabusa. Można również stosować i powoływać się na inne publikacje, wzorce lub normy, które nie są wymienione w niniejszym sylabusie, ale nie będą one przedmiotem egzaminu.

12.3 Ćwiczenia praktyczne

Zadania praktyczne należy uwzględnić w odniesieniu do wszystkich aspektów, w przypadku których od kandydatów oczkuje się zastosowania wiedzy (cele nauki z obszaru K3 lub wyższe). Wykłady i ćwiczenia powinny być oparte na celach nauki i opisie tematów w treści sylabusa.

12.3.1 Wskazówki dotyczące ćwiczeń praktycznych w miejscu pracy

Niektóre cele nauki można zrealizować przeprowadzając ćwiczenia praktyczne w miejscu pracy. W tabeli poniżej przedstawiono cele nauki, które można uwzględnić jako ćwiczenia w miejscu pracy:

Obszar

Odnośne cele nauki

Doskonalenie oparte na modelach

LO-3.3.10

(K5) Dokonanie oceny organizacji testowej z zzastosowaniem modelu TPI Next lub TMMi

Doskonalenie oparte na analizie

LO 4.4.2

(K5) Zarekomendowanie odpowiednich metryk i wskaźników pod kątem śledzenia tendencji dotyczących doskonalenia w określonej sytuacji związanej z wprowadzaniem ulepszeń

Wybór podejść do doskonalenia procesu testowego

LO 5.1.2

(K5) Zarekomendowanie podejścia do doskonalenia procesu testowego w konkretnym scenariuszu i z uwzględnieniem określonego zakresu doskonalenia

Proces doskonalenia

LO 6.3.2

(K6) Zaplanowanie i przeprowadzenie rozmów dotyczących oceny z zastosowaniem określonego modelu opartego na zawartości lub procesie; podczas rozmowy należy wykazać się znajomością stylu prowadzenia wywiadu i umiejętności interpersonalnych

LO 6.3.3

(K6) Sporządzenie i przedstawienie streszczenia wniosków (na podstawie analizy wyników) oraz ustaleń wynikających z oceny

LO 6.3.4

(K2) Podsumowanie podejścia do analizy rozwiązań

LO 6.3.5

(K5) Zarekomendowanie działań z zakresu doskonalenia procesu testowego na podstawie wyników oceny oraz przeprowadzonej analizy

LO 6.4.5

(K6) Sporządzenie planu doskonalenia testowania

LO 6.5.2

(K4) Dokonanie wyboru odpowiednich działań pilotażowych z listy dostępnych możliwości

Organizacja, role i umiejętności

LO 7.3.2

(K5) Dokonanie oceny profesjonalistów z dziedziny testowania (np. potencjalnych członków grupy zajmującej się procesem testowym / technicznej grupy roboczej) z uwzględnieniem ich braków w podstawowych umiejętnościach miękkich potrzebnych do przeprowadzenia oceny

Zarządzanie zmianą

LO 8.2.2

(K6) Sporządzenie planu doskonalenia testowania z uwzględnieniem zagadnień z zakresu zarządzaniem zmianą, zawierającego odpowiednie kroki i działania

Krytyczne czynniki sukcesu

LO 9.1.2

(K5) Dokonanie oceny krytycznych czynników sukcesu dla projektu doskonalenia testowania

LO 9.1.3

(K5) Zarekomendowanie odpowiednich działań w celu złagodzenia zidentyfikowanych ryzyk projektowych

Zastosowanie mają następujące wytyczne:

1. Prowadzący szkolenia mają obowiązek przedstawienia wszelkich wymogów dotyczących ćwiczeń praktycznych  w miejscu pracy przed rozpoczęciem kursu.

2. Prowadzący szkolenie ma obowiązek przyjęcia propozycji złożonegych przez uczestników przed rozpoczęciem ćwiczenia praktycznego.

3. Prowadzący szkolenie ma obowiązek zapewnić, że stosowna część szkolenia została przeprowadzona przed wykonaniem przez uczestnika kursu ćwiczenia praktycznego.

4. Pomiędzy prowadzącym szkolenie a uczestnikiem szkolenia musi buc zapewniona komunikacja w celu udzielania odpowiedzi na pytania i sprawdzania postępów w nauce.

5. Wyniki ćwiczenia praktycznego należy przekazać prowadzącemu szkolenie. Zaleca się, aby wyniki te zostały zaprezentowane, a przynajmniej udostępnione innym uczestnikom kursu.

12.4 Ogólne wskazówki dotyczące kryteriów dla prowadzących szkolenia

12.4.1 Kryteria dotyczące dostawców szkoleń dla poziomu eksperckiego

Dostawca szkoleń musi złożyć w Radzie Krajowej wniosek. Rada Krajowa udziela dostawcy szkoleń prawa prowadzenia szkoleń ISTQB na poziomie eksperckim w zakresie danego modułu poziomu eksperckiego na podstawie następujących kryteriów:

- Ogólnym wymogiem dla dostawcy szkoleń jest również posiadanie akredytacji do prowadzenia następujących kursów ISTQB:

- kurs na poziomie podstawowym

- poziom zaawansowany, moduł „Zarządzanie Testowaniem”

- Dopuszczalne są opcje alternatywne, jeśli Rada otrzyma odpowiednio sformułowane uzasadnienie

- Dostawcy szkoleń powinni posiadać przynajmniej dwóch szkoleniowców poziomu eksperckiego do modułu zatwierdzonych przez Radę Krajową. Posiadanie tylko jednego szkoleniowca może być zatwierdzone według uznania Rady.

- Dostawcy szkoleń posiadają uznany status w zakresie testowania (jako dostawca szkoleń lub inny), zwłaszcza w zakresie „Doskonalenia procesu testowego”

12.4.2 Kursy na poziomie eksperckim

Dostawca szkoleń musi przedłożyć Radzie Krajowej wniosek w celu uzyskania akredytacji materiałów szkoleniowych. Rada Krajowa zatwierdza materiały szkoleniowe w oparciu o następujące kryteria:

- Materiały szkoleniowe dla poziomu eksperckiego są zgode z sylabusem

- Ramy czasowe są zgodne z wartościami określonymi w Dziale 12.1 „Czas przeznaczony na szkolenie„

- Czas przeznaczony na omówienie ćwiczeń podczas kursu oraz zadań opartych na pracy nie może być krótszy niż podany w Dziale 12.1 „Czas przeznaczony na szkolenie”

- Maksymalna wielkość grupy: 10 osób (aby umożliwić osobisty kontakt szkoleniowca z kursantem)

- Musi zawierać przynajmniej stosowne terminy opisane w aktualnym glosariuszu ISTQB.

12.4.3 Kryteria wstępne dla trenerów

Na poziomie eksperckim ma miejsce formalna akredytacja wykładowców. Trenerzy muszą przedłożyć Radzie Krajowej wniosek o akredytację. Trener musi umieć rozwinąć wiedzę i umiejętności nauczone na poprzednich poziomach certyfikatów ISTQB. Szkoleniowiec musi również umieć przekazać swoje doświadczenie uczestnikom kursu w sposób efektywny i umożliwiający uczenie się. Powyższe można ocenić za pomocą następujących kryteriów:

- Trener zaliczył z wynikiem pozytywnym przynajmniej wymagane moduły egzaminu ISTQB na poziomie zaawansowanym określone przez kryteria wstępne lub równoważny egzamin (np. egzamin ISEB Practitioner, wersja 1.1 – 4 września 2001)

- Jest wysoce zalecane, aby wykładowcy posiadali pełen certyfikat ISTQB na poziomie zaawansowanym.

- Wysoce zalecane jest posiadanie dyplomu uczelni wyższej, doświadczenia w nauczaniu, bycie uznanym jako ekspert oraz posiadanie dużego doświadczenia. Ponieważ spełnienie wszystkich powyższych warunków często jest niewykonalne, można zrekompensować brak jednego warunku innym. Dlatego też, szkoleniowiec musi dodatkowo spełniać przynajmniej dwa z niżej wymienionych kryteriów:

- Szkoleniowiec posiada duże doświadczenie w nauczaniu (pięć lat pracy z przynajmniej trzema grupami w ogólnym wymiarze pięciu dni nauczania na rok) oraz doświadczenie w nauczaniu w zakresie przedmiotowym (trzy lub więcej grup nauczanych w zakresie przedmiotowym, którego dotyczy moduł poziomu eksperckiego)

- Szkoleniowiec jest uznanym liderem w dziedzinie testowania, mówcą konferencyjnym, autorem lub pełni równoważną funkcję

- Szkoleniowiec posiada wyższy stopień uniwersytecki związany z testowaniem (np. tytuł licencjata, magistra lub doktora)

- Szkoleniowiec posiada przynajmniej sześcioletnie doświadczenie w zakresie testowania i dwuletnie doświadczenie w zakresie, którego dotyczy dany moduł

Jeśli kryteria te nie zostaną spełnione, Rada może wyznaczyć szkoleniowca na stanowisko szkoleniowca stażysty na kursach na poziomie eksperckim, pod warunkiem, że szkoleniowiec taki posiada pełen certyfikat ISTQB na poziomie zaawansowanym i spełnia przynajmniej jedno kryterium z listy kryteriów dodatkowych. Po trzech kursach prowadzonych razem ze szkoleniowcem poziomu eksperckiego, szkoleniowiec stażysta może ponownie złożyć podanie i uzyskać pełen status szkoleniowca według uznania Rady.

Indeks

“CMMI”

“CTP”

“Organization”

“Skills”

“STEP”

“TMMi”

, “TMMi”

“Tools”

(DDP)”

15504”

actions”

AgileAgile

analysis”

, analysis”

, analysis”

Approach”

approaches”

, approaches”

attributes”

behavior”

change”

cost)”

Cycle”

Detection”

diagrams”

Efficiency”

Effort”

Excellence”

exercises”

factors”

, factors”

framework”

Group”

improvement”

, improvement”

indicators”

intelligence”

interviews”

Level”

management”

Model V

models”

Myślenie systemowe

Next”

persuasion”

Plan doskonalenia testówPlandoskonaleniatestów

Plan oceny

, Plan oceny

Planning”

Preparation”

Process”

process”

Productivity”

Punkty krytyczne

quality”

, quality”

Rate”

Ratio”

results”

Role”

roles”

SCRUMSCRUM

Sigma”

situation”

Skills”

skills”

, skills”

, skills”

, skills”

, skills”

, skills”

slip”

slippage”

Strategiczny plan działania

Struktura doskonalenia IDEALStrukturadoskonaleniaIDEAL

syllabus”

Taktyczny plan działania

times”

Zarządzanie zmianą

model Satir

proces

Table of Contents

Historia zmian

Spis treści

Podziękowania

1. Wprowadzenie do sylabusa

1.1 International Software Testing Qualifications Board

1.2 Cel niniejszego dokumentu

1.3 Certyfikowany Tester Oprogramowania - Poziom Ekspercki

1.3.1 Poziom Wiedzy

1.3.2 Egzamin

1.3.3 Akredytacja

1.4 Części normatywne i informacyjne

1.5 Poziom uszczegółowienia

1.6 Układ sylabusa

1.7 Terminy i definicje

1.8 Cele nauki / Poziomy wiedzy (K)

1.9 Wymagania

2. Kontekst doskonalenia 285 min.

2.1 Dlaczego należy doskonalić proces testowy?

2.2 Co można udoskonalić?

2.3 Poglądy dotyczące jakości

2.4 Ogólny proces doskonalenia

2.4.1 Cykl Deminga

2.4.2 Model doskonalenia IDEAL

2.4.3 Podstawowe koncepcje doskonałości

2.5 Przegląd podejść do doskonalenia

2.5.1 Przegląd podejść opartych na modelach

2.5.2 Przegląd podejść analitycznych

2.5.3 Podejścia hybrydowe

2.5.4 Inne podejścia do doskonalenia procesu testowego

3. Doskonalenie oparte na modelach 570 minut

3.1 Wprowadzenie do podejść opartych na modelach

3.1.1 Pożądane cechy modeli doskonalenia procesu testowego

3.1.2 Reprezentacja ciągła i etapowa

3.1.3 Założenia w stosowaniu modeli

3.2 Modele doskonalenia procesu tworzenia oprogramowania

3.2.1 Model CMMI

3.2.2 ISO/IEC 15504

3.3 Modele doskonalenia procesu testowego

3.3.1 Model doskonalenia procesu testowego (TPI®)

3.3.2 Zintegrowany model dojrzałości testów (TMMi)

3.3.3 Porównanie modeli TPI Next i TMMi

3.4 Modele oparte o zawartość

3.4.1 STEP

3.4.2 Krytyczny Proces testowy (CTP)

4. Doskonalenie oparte o analizę 555 minut

4.1 Wstęp

4.2 Analiza przyczyn

4.2.1 Diagramy przyczynowo-skutkowe

4.2.2 Analiza przyczyn podczas procesu inspekcji

4.2.3 Wykorzystanie Standardowych Klasyfikacji Anomalii

4.2.4 Wybór usterek do Analizy Przyczyn

4.3 Podejście GQM (Cel-Pytanie-Metryka)

4.4 Analiza przy użyciu miar, metryk i wskaźników

4.4.1 Wstęp

4.4.2 Metryki efektywności testowania

4.4.3 Metryki efektywności / kosztów testowania

4.4.4 Metryki opóźnień

4.4.5 Metryki przewidywalności

4.4.6 Metryki Jakości Produktu

4.4.7 Metryki dojrzałości testów

5. Wybór podejścia do doskonalenia procesu testowego 105 minut

5.1 Wybór podejść do doskonalenia procesu testowego

6. Proces doskonalenia 900 minut

6.1 Wstęp

6.2 Rozpoczęcie procesu doskonalenia

6.2.1 Określenie potrzeby doskonalenia

6.2.2 Ustalenie celów doskonalenia testów

6.2.3 Ustalenie zakresu doskonalenia

6.2.4 Wpływ innych ludzi i kultury na fazę rozpoczęcia

6.3 Diagnoza aktualnej sytuacji

6.3.1 Planowanie oceny

6.3.2 Przygotowanie oceny

6.3.3 Przeprowadzanie wywiadów

6.3.4 Opinia wstępna

6.3.5 Analiza wyników

6.3.6 Wykonanie analizy rozwiązań

6.3.7 Rekomendowanie działań mających na celu doskonalenie

6.4 Tworzenie planu doskonalenia testów

6.4.1 Ustalenie priorytetów.

6.4.2 Opracowanie podejścia do wdrożenia.

6.4.3 Planowanie udoskonaleń

6.5 Działania związane z wdrożeniem usprawnień

6.5.1 Wybór i przeprowadzenie wdrożeń pilotażowych

6.5.2 Zarządzanie i kontrola wdrożenia

6.6 Uczenie się na podstawie doskonalenia

7. Organizacja, role i umiejętności 465 minut

7.1 Organizacja

7.1.1 Grupa zajmująca się procesem testowym

7.1.2 Doskonalenie testów w zespołach zdalnych, offshoringowych i outsourcingowych

7.2 Poszczególne role

7.2.1 Osoba doskonaląca proces testowy

7.2.2 Role oceniających

7.3 Umiejętności osoby doskonalącej/oceniającej proces testowy

7.3.1 Umiejętność przeprowadzania wywiadów

7.3.2 Umiejętność słuchania

7.3.3 Umiejętność przygotowania prezentacji i raportów

7.3.4 Umiejętności analityczne

7.3.5 Umiejętność sporządzania notatek

7.3.6 Umiejętność perswazji

7.3.7 Umiejętność zarządzania

8. Zarządzanie zmianą 285 minut

8.1 Wstęp

8.2 Podstawowy proces zarządzania zmianą

8.3 Czynnik ludzki w procesie zarządzania zmianą

9. Krytyczne czynniki sukcesu 300 minut

9.1 Kluczowe czynniki sukcesu

9.2 Ustalenie kultury doskonalenia

10. Przystosowywanie się do różnych modeli cyklu życia 60 minut

10.1 Przystosowanie do rożnych modeli cyklu życia

11. Materiały źródłowe

11.1 Normy

11.1.1 [BS7925-2]

11.1.2 BS 7925-2 Software Component Testing

11.1.3 [IEEE 1044]

11.1.4 IEEE Std 1044™ IEEE Standard Classification for Software Anomalies

11.1.5 [ISO 25000]

11.1.6 ISO/IEC 25000:2005 Software engineering. Software product quality requirements and evaluation (SquaRE). Guide to SquaRE

11.1.7 [ISO/IEC 15504]

11.1.8 ISO/IEC 15504-5 ISO 15504 – SPICE (Software Process Improvement and Capability dEtermination), Part 5, Assessment Model [1998]

11.1.9 [ISO 9126]

11.1.10 ISO/IEC 9126-1:2001, Software Engineering – Software Product Quality

11.1.11 [ISTQB-Glossary]

11.1.12 ISTQB Glossary of terms used in Software Testing, Version 2.1, available from [ISTQB-Web]

11.2 Znaki towarowe

11.3 Książki

11.4 Referaty i artykuły

11.5 Źródła internetowe

12. Załącznik A – Uwagi dla prowadzących szkolenia

12.1 Czas przeznaczony na szkolenie

12.2 Zastosowane normy

12.3 Ćwiczenia praktyczne

12.3.1 Wskazówki dotyczące ćwiczeń praktycznych w miejscu pracy

12.4 Ogólne wskazówki dla prowadzących szkolenia dotyczące kryteriów

12.4.1 Kryteria dotyczące dostawców szkoleń dla poziomu eksperckiego

12.4.2 Kursy na poziomie eksperckim

12.4.3 Kryteria wstępne dla szkoleniowców

Indeks