2. TESTER.PL
Witam Was Drodzy Czytelnicy
Tydzień temu w Katowicach Natura brutalnie „przetestowała” projekt jednego
z budynków, jakich wiele wokół nas. Nie zwracałem zwykle na to uwagi, ale po tym
zdarzeniu jako tester zadałem sobie kilka pytań:
Czy wszystkie te konstrukcje, hale, supermarkety, stadiony ktoś wystarczająco
przetestował?
Czy zweryfikował projekt w fazie „testów statycznych dokumentacji”?
Jakie były założenia do „testów wydajnościowych”?
Z drugiej strony czy przypadkiem nie zaniedbano „fazy utrzymania” – nagromadzone
duże ilości śniegu przypominają trochę krytyczne przeciążenie systemu…, tyle że
w IT skutki bywają zazwyczaj dużo łagodniejsze.
Wydawałoby się, że „budowlanka” to dziedzina dużo bardziej zaawansowana
i dojrzalsza projektowo i procesowo niż projekty IT. A jednak okazuje się, że i tutaj
zdarzają się tragiczne pomyłki. Z każdego nawet tego najtragiczniejszego
doświadczenia trzeba wyciągnąć wnioski i naukę. Niech ta katastrofa uświadomi
nam, że w rzeczywistości od nas jako twórców software (a szczególnie testerów)
może zależeć czyjeś życie.
Wszystkim czytelnikom, których w jakiś sposób dotknęła ta tragedia, oraz osobom
z Katowic, Chorzowa, całego Śląska składam głębokie wyrazy współczucia.
Ostatnio mieliśmy trochę zmian wewnątrz Stowarzyszenia, a świadczy to m. in. też
o tym, że SJSI żyje i rozwija się. 15 grudnia 2005 roku odbyło się Nadzwyczajne
Walne Zebranie Członków SJSI. W wyniku głosowania do Zarządu przyjęto Joannę
Nowakowską i Piotr Kałuskiego. Podczas ostatniego Zebrania Zarządu Joanna i Piotr
zostali powołani na stanowiska V-ce Prezesa i Sekretarza Zarządu SJSI.
Nominowanym serdecznie gratuluję!
Korzystając z okazji chciałbym podziękować Adamowi Suskiewiczowi, za bardzo duży
wkład, jaki wniósł do SJSI będąc członkiem-założycielem i Sekretarzem Zarządu.
Już dzisiaj chciałbym Was zaprosić na konferencję organizowaną wspólnie
z tygodnikiem Computerworld w dniach 22-24 maja. Zapowiada się interesujące
spotkanie. Więcej informacji wewnątrz numeru.
Z pozdrowieniami,
Wojciech Jaszcz
Prezes SJSI
Strona 1 z 39
3. TESTER.PL
Od redaktora
Wraz z początkiem Nowego Roku (w połowie lutego ☺) dostajecie kolejny – już
szósty - numer kwartalnika TESTER.PL.
W tym numerze tylko (aż!!) dwie pozycje:
1. Bogdan Bereza Jarociński o niezgodnościach w nazewnictwie przy szkoleniach
testerskich
2. Joanna Nowakowska o doskonaleniu procesu testowego za pomocą modeli
TMM i TPI – rzecz mająca bardzo duże praktyczne zastosowanie
Numer otwiera zaproszenie na III Konferencję Systemów Informatycznych, tym
razem wspólny „produkt” tygodnika Computerworld i naszego Stowarzyszenia.
Zapraszamy wszystkich w dniach 22 – 24 maja 2006. Połączenie wysiłków ze strony
tygodnika Computerworld i SJSI powinno zapewnić, że będzie to konferencja jeszcze
ciekawsza od poprzednich. Gorąco namawiam do uczestnictwa!!.
Ze względu na nasze kontakty międzynarodowe w numerze także zaproszenie do:
• Dusseldorfu, na ICSTEST’2006. Na tej konferencji na pewno będziemy
reprezentowani, wystarczy zajrzeć na stronę Konferencji, a kilka znajomych
nazwisk na pewno znajdziecie
• Berlina, na CONQUEST’2006. Jeżeli macie trochę czasu końcem września,
warto go zarezerwować i wybrać się na tą konferencję – zapowiada się
bardzo ciekawie. Ponieważ SJSI jest organizacją wspierającą tej konferencji –
możemy liczyć na istotne zniżki wpisowego
Na ostatnich stronach Testera.pl informacja o kolejnej edycji kursu „Certyfikowany
Test Manager” wspólnego przedsięwzięcia IIR i SJSI Zamieszczamy tez informacje o
szkoleniach organizowanych przez BBJTest. Dla chcących się podszkolić – świetna
okazja.
Równocześnie chciałbym – kolejny raz - gorąco zachęcić wszystkich czytelników tego
periodyku do aktywnej współpracy. Cały czas czekamy na Państwa uwagi, artykuły,
felietony – wszystko, co Was interesuje, co chcielibyście przeczytać, czego się
dowiedzieć. Jeżeli tylko będziemy mogli, postaramy się zrealizować Państwa
postulaty.
Strona 2 z 39
4. TESTER.PL
III Konferencja Jakości Systemów Informatycznych
*
CEL
Celem konferencji jest przekaz wiedzy i publiczny dyskurs dotyczący jakości w
kontekście systemów IT. Zawartość wystąpień będzie się koncentrowała wokół
wieloaspektowego spojrzenia na jakość oprogramowania i systemów informatycznych
w procesach ich tworzenia, kontraktowania, utrzymania i audytu.
KIEDY I GDZIE
22-24 maja 2006 r., okolice Warszawy.
DLA KOGO
Tematyka konferencji będzie interesująca zarówno dla reprezentantów firm IT oraz
„software house’ów”, jak i przedstawicieli korporacyjnych oraz instytucjonalnych
użytkowników rozwiązań informatycznych. Tym pierwszym zależy na zapewnieniu
wysokiej jakości dostarczanych rozwiązań - oprogramowania i całych systemów
informatycznych. Ci drudzy nadzorują, bądź prowadzą działania związane z
tworzeniem oprogramowania, wdrażaniem systemów informatycznych, ich
zamawianiem, odbiorem i audytem (np. operatorzy telekomunikacyjni, banki, firmy
ubezpieczeniowe, zakłady przemysłowe, największe urzędy centralne i in.).
*
Przedsięwzięcie jest organizowanie wspólnie przez tygodnik Computerworld i Stowarzyszenie
Jakości Systemów Informatycznych – konferencja powstała z połączenia dwóch osobnych konferencji,
z których każda miała już swoje dwie edycje – Krajowej Konferencji Jakości Systemów
Informatycznych oraz Konferencji Stowarzyszenia Jakości Systemów Informatycznych.
Strona 3 z 39
5. TESTER.PL
KTO BĘDZIE WYSTĘPOWAŁ
Występować będą specjaliści i menedżerowie, którzy będą prezentować przede
wszystkim swoje osobiste, praktyczne doświadczenie.
Podstawowym założeniem konferencji jest jej mocny wymiar praktyczny konferencja ma być prowadzona pod hasłem "przez praktyków dla praktyków".
KOMITET PROGRAMOWY
Jerzy Bielec, CIO (d. PKN Orlen)
Tomasz Byzia, StrictWise
Marcin Sikorski, Politechnika Gdańska
Lucjan Stapp, Politechnika Warszawska
Lilianna Wierzchoń, Computerland
ZAŁOŻENIA PROGRAMOWE
Konferencja ma umożliwić przekazanie wiedzy, doświadczeń, informacji pomocnych
w budowie rozwiązań i sposobów organizacji pracy gwarantujących uzyskanie i
utrzymanie wysokiej jakości aplikacji i systemów IT. Możliwe jest przedstawienie
metodyk oraz różnych metod kontroli jakości tworzonego oprogramowania.
Użytkownicy rozwiązań informatycznych z kolei będą mogli się dowiedzieć, w jaki
sposób wybrać dobrego dostawcę i system o wysokiej jakości; jak sprawdzić, czy
spełnia on przyjęte założenia oraz jak go prawidłowo wdrożyć.
TEMATYKA
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Automatyzacja testowania
Czynnik ludzki – w jakim stopniu jakość zależy od personelu
Czynniki decydujące o jakości systemów IT (powiązanie z kulturą biznesową
firmy, ład korporacyjny, IT Governance)
Ergonomia i użyteczność jako czynniki wpływające na satysfakcję użytkownika
Etyka biznesu a jakość systemów IT
Jakość i testowanie w średnich i małych projektach
Jakość w organizacji i projekcie
Jakość we wdrażaniu systemów COTS i tych realizowanych na zamówienie
Metodyki testowania
Metodyki prowadzenia projektów a jakość
Narzędzia informatyczne i rozwiązania organizacyjne wspomagające osiąganie
i utrzymanie wysokiej jakości (w tym narzędzia wspomagające procesy
specyfikacji, tworzenia i weryfikacji oprogramowania)
Outsourcing testów
Prawne aspekty jakości w IT
Rola standardów i instytucji atestujących, jakościowe standardy formalne a
standardy de facto
Systemy zapewnienia jakości w procesach wytwarzania, kontraktowania i
odbioru oprogramowania
Usługi IT, SLA, outsourcing w kontekście poziomu i zapewnienia jakości
Wymagania a jakość
Strona 4 z 39
6. TESTER.PL
•
•
Zarządzanie procesem testowym
Metody pomiaru kosztów testowania
FORMA WYSTĄPIEŃ
Prezentacje standardowo mają trwać 45 minut (30 minut wykładu plus 15 minut
dyskusji).
HARMONOGRAM
•
•
•
•
•
•
•
25 stycznia 2006 (środa) – ostateczny termin nadsyłania formularzy
zgłoszeniowych
7 luty 2006 (wtorek) – termin wstępnej akceptacji zgłoszonych propozycji
wystąpień, kontakt z wybranymi autorami (Rada Programowa)
20 marca 2006 (poniedziałek) – ostateczny termin na nadsyłanie pełnych
abstraktów (prelegenci)
2 kwietnia 2006 (niedziela) – termin weryfikacji nadesłanych abstraktów,
wstępny harmonogram, kontakt z wybranymi autorami
20 kwiecień 2006 (czwartek) – ostateczny termin nadsyłania materiałów do
materiałów konferencyjnych (abstrakt lub slajdy)
5 maja 2006 (piątek) – termin przesłania uwag autorom prezentacji (Rada
Programowa)
15 maja 2006 (poniedziałek) – ostateczny termin nadsyłania finalnych wersji
materiałów („do druku”)
Serdecznie zapraszamy!
Zarząd Stowarzyszenia Jakości Systemów Informatycznych
Strona 5 z 39
9. TESTER.PL
To oczywiście nieprawda!1
Wyznanie nauczyciela testerów
Bogdan Bereza-Jarociński
bbjTest
Bogdan Bereza-Jarociński
Psycholog z Uniwersytetu Warszawskiego i Londyńskiego,
informatyk z uniwersytetu w Lund. Testował, zarządzał,
automatyzował, koordynował lub ulepszał procesy
testowe zarówno w zastosowaniach wbudowanych
(telekomunikacja – Ericsson, sygnalizacja kolejowa –
Bombardier) jak i otwartych (bazodanowe, Java). Lubi
udzielać się na międzynarodowych konferencjach i
prowadzić szkolenia z dziedziny testowania. Od 2002 roku
prowadzi w Polsce szkolenia m. in. na certyfikat ISEB.
1
Pierwotna wersja tego artykułu - w wersji angielskiej - ukazała się w Professional Tester, w numerze
z listopada 2005
Tłumaczenie pochodzi od redakcji, zmiany i poprawki od autora.
Uwaga: autor zdążył dokonać tylko niektórych poprawek i ma wrażenie, że wersja przetłumaczona jest
miejscami niejasna i bardziej zawiła od oryginału. Zwłaszcza razi autora stosowanie terminów „skaza”
oraz „usterka” na określenie poczciwego błędu (defektu). Są one wprawdzie zgodne z oficjalnym
tłumaczeniem „Glossary ISTQB”, ale wprowadzają w błąd
Strona 8 z 39
10. TESTER.PL
To oczywiście nieprawda!
Wyznanie nauczyciela testerów
Bogdan Bereza-Jarociński
bbjTest
Ludzie przychodzą na kursy testowania oprogramowania, by nauczyć się
czegoś nowego o tym, jak wykonywać swą (testera) pracę. Te nowe umiejętności to
np. nowe metody, techniki lub podejścia, o których istnieniu nic nie wiedzieli lub
nowe zastosowania znanych im idei: bardziej strukturalne, bardziej konsekwentne,
bardziej prawdziwe, a więc bardziej użyteczne.
My, instruktorzy, robimy co możemy, by dać im to co chcą i potrzebują.
Czasami nie mamy jednak pełnej kontroli nad programami nauczania, ma to miejsce
wtedy gdy prowadzimy autoryzowane kursy, które muszą spełniać zdefiniowane
uprzednio konspekty.
Jak na razie nie jest źle: w mojej opinii międzynarodowe konspekty - albo w
pełni międzynarodowe, np. ISTQB, lub de facto akceptowane jako międzynarodowe,
np. ISEB - są wspaniałe, Ich istnienie wymusza podniesienie umiejętności testowania
na wyższy poziom, akredytacja zapewnia jednolity poziom jakości różnych
dostawców kursów i - wreszcie - certyfikat ma także wiele pozytywnych efektów.
Podczas uczenia, najgorszą rzeczą jest obserwować znudzenie słuchaczy.
Drugą w kolejności najgorszą rzeczą to ujrzenie w ich oczach marzycielskiego,
mistycznego spojrzenia, oznaczającego że to co wyjaśniasz dopasowuje się w ich
oczekiwań. Takie spojrzenie oznacza dwie złe rzeczy: zaznaczenie "zbyt teoretyczne"
w arkuszu ocen Twego kursu, oraz niepowodzenie uczestnika kursu, gdy wdraża tą
nową umiejętność w praktyce.
Będę szczery: widziałem ten lśniący błysk w oczach moich kursantów wiele
razy. I tu niespodzianka: zdarza się to najczęściej, gdy staram się nauczyć ich
czegoś, co po prostu nie jest prawdą. A co jest nieprawdziwe w konspektach ISEB i
ISTQB? Przykro to stwierdzić, ale podstawy. Rzeczywistość wcale nie jest taka jak w
ich konspektach i to co proponowane jest w konspektach to OCZYWIŚCIE
NIEPRAWDA!.
Zgodnie z ISEB i ISTQB…
… realne spojrzenie - w skrócie - jest następujące:
Są dwa podstawowe obszary testowania: techniki testów dynamicznych i testów
statycznych. ISTQB punktuje nieco lepiej: przynajmniej nie należy wyjaśniać Twoim
zdumionym słuchaczom (a musisz to robić na kursach zgodnych z konspektem ISEB),
że
• “dynamiczny” nie oznacza "z wysoką adrenaliną"
• dlaczego testy dynamiczne mają techniki, a testy statyczne widocznie nie
• że "techniki testów" nie oznaczają np. technik wykonania, ale techniki
projektowania.
W terminologii ISTQB istnieją "techniki statyczne" i techniki projektowania testów.
Zdecydowanie ładniejsze nazwy, tym niemniej należy w dalszym ciągu zapewniać
słuchaczy, że określenie "technika statyczna" nie oznacza po prostu nic-nie- robienia.
Strona 9 z 39
11. TESTER.PL
Porządnie zbudowane bloki ustawiają się porządnie na miejscu: przeglądy i analiza
statyczna, czarna skrzynka i biała skrzynka, podział na klasy równoważności i analiza
wartości brzegowych, "odkrywanie błędów" (ISEB) i "techniki oparte o
doświadczenie" (ISTQB). Zdecydowanie wolę ☺ określenie ISEB, bo to zawsze jest
zabawne zgadywanie co obecnie znaczy "znajdowanie skaz", "znajdowanie awarii"
lub po prostu "zgadywanie błędów". W obu przypadkach, zarówno w konspekcie
ISEB jak i w ISTQB, te techniki wbijane są na samym końcu: opisują NA KOŃCU tą
technikę, która w rzeczywistości jest PIERWSZA. W pełni oczywiste.
Jeżeli przyjrzymy się bliżej konspektowi ISTQB, nasz mały krasnoludek
powraca: wspaniała nazwa "testowanie oparte na doświadczeniu" ukrywa się w
"pisanie przypadków testowych w oparciu o [...] wiedzę o [..] skazach". Ponieważ
"skaza" w języku ISTQB oznacza to samo co ""awaria" w języku ISEB, więc śmielszy
uczeń zawsze podnosi swą mała rączkę i pyta "przepraszam panie psorze, ale
ostatnim razem projektowałem moje przypadki testowe w oparciu o moja wiedzę o
awariach, nie o skazach. Czy to bardzo źle?"
Oczywiście zapewniam go, że nie. Tak zachęceni, następni podnoszą ręce.
Zawstydzona mała dziewczynka pyta " Przepraszam panie psorze, ale raz
zaprojektowałam przypadki testowe w oparciu o moją wiedzę o tym, że stos
programu jest przechowywany w pliku rejestru na mikroprocesorze, i że jest 256
rejestrów, i kiedy potrzebuję więcej stosu, wymieniam go z RAMem...Jakiego koloru
jest to testowanie? Być może to jest silikonowe testowanie, panie psorze? Bo poza
wszystkim innym, co jest bielsze od bieli?"
Zanim zdążyłem ją zganić za zadawanie niewłaściwych pytań, odrobinę wolniej
myślący chłopiec wymamrotał: " a ja zawsze jestem taki głupi, panie psorze ale ja
naprawdę nie wiedziałem że to źle, użyłem podziału na klasy równoważności przy
projektowaniu przypadków testowych, by sprawdzić czy prawidłowo obsługuję
parametry w C++, ale naprawdę, proszę pana, nie wiedziałem, że to nie jest
dozwolone, bo to technika czarno-skrzynkowa, słowo daje, będę o tym pamiętał
następnym razem...". Jeżeli ten kurs był prowadzony zgodnie z konspektem ISTQB,
mógłbym mu jedynie powiedzieć, żeby bardziej uważał w przyszłości ("pewne
techniki wpadają tylko do jednej kategorii, inne mają elementy z więcej ni ż jednej
kategorii"). Gdyby to był kurs zgodny z ISEB, powiedziałbym mu, ze ma jutro przyjść
do szkoły z rodzicami.
Wydaj się, że trochę przesadziłem z narrativum. Na kursy przychodzą dorośli
profesjonaliści, nie mówią do mnie " przepraszam, panie psorze". Na tym etapie, albo
się wyłączają i śpią, albo są zmieszani albo źli, a ja stoję przed nimi, na równi bojąc
się ich znudzenia (zła ocena w arkuszu oceniania) jak ich złości (jest ich
zdecydowanie więcej i są dużo młodsi ode mnie). Ale to co powoduję, że kamienieję,
to sytuacja, gdy ktoś może mnie spytać: „No dobrze, panie Mądrala, my nie
używamy żadnej z pańskich pięknych technik. My nie zgadujemy błędów,
jakiekolwiek one są, bo nie jesteśmy czarodziejami, i nie mamy zielonego pojęcia
gdzie one mogą być. My po prostu projektujemy przypadki testowe tak by pokrywały
wymagania na nasz system, ale robimy to w języku naturalnym, nie używamy
przypadków użycia ani maszyn skończonych. I proszę mi powiedzieć, panie Mądrala,
jakie testy robimy?"
Będąc tchórzem, używam starego triku tchórzy i staram się skrócić moje męczarnie.
Mruczę więc coś o konspekcie będącym kompromisem lub koniecznym
uproszczeniem. Mam też możliwość odwołania się do pewnych śmiesznych wyborów
Strona 10 z 39
12. TESTER.PL
by pytania egzaminacyjne było sformułowane łatwiej (np. w kursie ISEB zupełnie
niepotrzebne jest włączenie wyliczania indeksu McCabe do konspektu – ułatwia mi
prościej osiągnąć mój cel).
Jednak nawet tchórz ma czasami dość i chciałby stanąć w twarz rzeczywistości
zamiast ją omijać. Spójrzmy prawdzie w twarz: pokręcone kwalifikacja z obu
konspektów zawiera multum niepotrzebnych i bezużytecznych faktów i technik, co
więcej źle one się odzwierciedlają w rzeczywistości przemysłu oprogramowania. A
mówią nam coś zupełnie przeciwnego!
Jak naprawdę dobiera się przypadki testowe?
Tak, testowanie jest oparte na ryzyko, mimo że nienawidzę powtarzać ten frazes.
Projektowanie przypadków testowych oznacza wybór setki lub tysiąca tych
najbardziej istotnych z 101000 teoretycznie możliwych. I co naprawdę oznacza
określenie „najbardziej istotnych”?
Na rysunku1 poniżej podano kompletny diagram umożliwiający decyzję o ważności
możliwego przypadku testowego.
Rysunek 1
Poniżej zaprezentuję pełne wyjaśnienie, odwołując się do numerów węzłów.
Przy założeniu, że przypadki testowe są równie łatwe do wykonania [2], bardziej
istotne [1] są te które mogą spowodować poważniejsze awarie [3], przy czym całe
poddrzewo poniżej [3] opisuje od czego „ważniejsze awarie” zależą.
Tym niemniej, kiedy awarie maja podobny poziom ważności [3], raczej wybierzemy
te przypadki testowe [1], które łatwiej wykonać [2] niż takie które nie dają
Strona 11 z 39
13. TESTER.PL
wiarygodnych rezultatów z powodu kłopotów przy wykonaniu lub słabej
obserwowalności [4] czy też takich, których wykonanie jest drogie [4]
Ważność awarii [3] jest - tak jak w podejściu tradycyjnym - funkcją swych
konsekwencji lub ceny [5] lub jej – awarii – prawdopodobieństwa [6]. Jak poznać
cenę awarii? W zasadzie to nie jest problem testów, ale biznesu [9]. Jeżeli ich
grzecznie zapytać, to na pewno grzecznie odpowiedzą ☺ , ...należy się wystrzegać,
by nie zapytali Ciebie, jakie awarie są możliwe. Prawdopodobieństwo awarii [6] jest
funkcją prawdopodobieństwa skaz[9] i użycia [7] (częściej nazywanym
częstotliwością wystąpienia). Prawdopodobieństwo skazy jest zdefiniowane jako
liczba czynników [11], które są dokładnie podane w wielu książkach dotyczących
testowania. Przy okazji „zgadywanie błędów” (ISEB) czy „znajdowanie skaz” (ISTQB)
to właśnie to: estymacja prawdopodobieństwa wystąpienia skazy [8]. To, co w
ISTQB nazywa się „techniką opartą na doświadczeniu” mogłoby oznaczać użycie
całego powyższego drzewa: estymacja wszystkich wartości i siły ich wzajemnych
zależności.
Z niewiadomego powodu, ISTQB wybiera tylko jeden liść[11] z całego
drzewa i nazywa go „testowaniem opartym na doświadczeniu”!
Nie mogę się tu powstrzymać od pewnej gry słów: ISEB’owe „zgadywanie
błędów” – zgodnie z definicją „błędu” z BS 7925 –1, będzie tylko częścią „szukania
skaz”. Na podobnej zasadzie, jak zgadywanie, czy wszystko jest w porządku w
małżeństwie Anki (jeśli nie, to większe jest prawdopodobieństwo popełnienia przez
nią błędu).
Rzućmy jeszcze okiem na fragment drzewa o którym dotąd nie wspomniałem:
by wyliczyć prawdopodobieństwo użycia [7] musisz mieć jakiś rodzaj - wymyślony lub
oparty na doświadczeniu – modelu użycia dla tej małej funkcji, dla której obliczasz
ważność wystąpienia awarii.
Uwaga: powyższy rysunek (który powinien być uszczegółowiony na najniższym
poziomie) jest tylko podstawą do omawiania zasad nadawania przypadkom
testowym ich priorytetów. Dalsze omawianie tego problemu , tak powszechne do
tej pory, nie jest więcej potrzebne. Wystarczy jak Twoi dostawcy kupią sobie
narzędzie do sieci bayesowskich BBN i rozpoczną zbieranie danych! Użyj Google’a
jeśli nie wiesz co to BBN (Bayesian Belief Net).
Pełny obraz
Rozwiązanie podane powyżej ma tylko jeden mały haczyk: powinno być
używane do „wyboru setki lub tysiąca tych najbardziej istotnych z 101000 teoretycznie
możliwych” przypadków testowych. Jedno drzewo z rys. 1 dla każdego z nich, szybkie
podstawienie, i już jesteśmy gotowi ☺.
Dlatego tez potrzebujemy dodatkowych metod do wyboru przypadków
testowych. Nagle nasze wspaniałe drzewo z wszechmocnego i ostatecznego
narzędzia do wyboru przypadków testowych jest ograniczane – z powodu czystych
operacji na liczbach – do końcowego narzędzia przy bardzo ograniczonym zakresu,
do ostatecznego wyboru przypadków testowych z już wybranych innymi sposobami.
Jakimi innymi sposobami? Tak naprawdę są dwa podejścia: intuicyjne i
systematyczne. Z jakichś powodów, zarówno ISEB jak i ISTQB opisuja tylko
techniki systematyczne, kierując techniki intuicyjne w zapomnienie (mając w
pogardzie fakt, że 70 % tworzonych na świecie przypadków testowych jest
tworzonych w sposób intuicyjny) lub redukując je do drobnej cząstki zwanej
Strona 12 z 39
14. TESTER.PL
„zgadywaniem błędów” lub„techniką oparta na doświadczeniu a oznaczającą
„ustalanie prawdopodobieństwa skazy”, co jest zdecydowanie nieadekwatne.
Dla obu tych podejść: intuicyjnego i systematycznego, są dwie podstawowe
filozofie projektowania przypadków testowych: biało skrzynkowa i czarno
skrzynkowa. Podejście czarno – białe podejście ma sens zarówno do intuicyjnego
jak i systematycznego podejścia, w przeciwieństwie do wrażenia, jakie można
odnieść z konspektów ISEB/ISTQB gdzie ten podział istnieje tylko do technik
systematycznych. Należy tu zauważyć, ze biało – czarny podział nie jest tak
naprawdę dwuwartościową skala dyskretna, jak to jest często przedstawiane. To jest
raczej skala od 100% czerni (coś jest ukryte za gipsową ścianą, odpowiada na Twoje
pytania, ale nie jest dla Ciebie istotne, czy to komputer czy człowiek) do 100 % bieli
(projektując przypadki testowe bierzesz pod uwagę poziom bramek elektronicznych)
poprzez różne odcienie szarości.
Prawidłowa (lekko uproszczona) tabela przedstawiająca podejście do testów / ich
filozofię jest przedstawiona na rys. 2
Systematyczne
Czarno skrzynkowe
Biało skrzynkowe
Systematyczne
czarno skrzynkowe
Systematyczne
biało skrzynkowe
Rysunek 2.
Intuicyjne
Intuicyjne
czarno skrzynkowe
Intuicyjne
biało skrzynkowe
To jeszcze nie jest koniec. W przeciwieństwie (znowu) do tego, co jest
w konspektach. Nie istnieje konceptualny wąwóz rozdzielający testy statyczne
i dynamiczne. Nazwanie „przeglądem” techniki statycznej to to samo co nazwanie
„wykonaniem testów” techniki dynamicznej. Bez wątpienia, projektowanie
przypadków testowych jest potrzebne także w testach statycznych, aczkolwiek
występuje różnica w tym, co tworzy test. W testach statycznych, tak jak i w
dynamicznych, najpierw musisz przejść przez projektowanie testów – np.
zdecydować w istotnych szczegółach co przeglądać i jak – przed „wykonaniem”
przeglądu.
Stąd, końcowy, pełny i pozbawiony sztucznych ograniczeń zbiór klas do
projektowania przypadków testowych jest trzy wymiarowy, skład się z ośmiu
elementów, jak pokazano na rys. 3
Strona 13 z 39
15. TESTER.PL
static
systematic
black-box
dynamic
systematic
black-box
static
intuitive
black-box
dynamic
intuitive
black-box
static
systematic
white-box
dynamic
systematic
white-box
static
intuitive
white-box
dynamic
intuitive
white-box
Rysunek 3.
Należy zauważyć, że określenie “techniki testowe” nie było jeszcze nawet
wypowiedziane, ponieważ podstawową sprawą są klasy projektowania przypadków
testowych, których jest w przybliżeniu 8 ( w przybliżeniu, bo jak już wspomniano,
mamy więcej niż dwie wartości na czarno – białej skali)
Powód nacisku na techniki testowe w konspektach ISEB/ISTQB jest oczywiście
dydaktyczny: podstawowym celem podstawowego kursu jest nauczenie testerów
technik projektowania testów, które będą oni mogli stosować w swojej podstawowej
pracy, tzn. w testowaniu dynamicznym. Nie ma jednak potrzeby budowania całej
fałszywej konceptualnej struktury by osiągnąć ten praktyczny cel. Praktykę i zdrowy
rozsądek oferują alternatywę do ... ciężko powiedzieć do czego, ponieważ techniki
intuicyjne, z którymi tester pracuje na co dzień, są zupełnie lekceważone. Można
spróbować zgadnąć, jakie racje się za tym kryją: wszystkie projekty są testowane
intuicyjnie, ale pewne użycie technik systematycznych bardzo by się przydało w wielu
z nich. Oczywiście, ta racjonalność jest podejrzana: nie ma potrzeby budowy
nieprawdziwego modelu, tylko po to by zapewnić szerokie stosowanie
systematycznych technik testowych. Wreszcie, testy intuicyjne także potrzebują
ulepszania, więc dlaczego w pełni je zaniedbywać?
Wreszcie: przykład
Przyjrzyjmy się, jak model opisany na rys. 3 sprawdza się dla rzeczywistych
technik projektowania testów. Rozpatrzmy trzy takie techniki: (1) testowanie metodą
zmiany stanów, (2) testowanie w oparciu o wiedze o rozkładzie błędów w podobnym
systemie oraz (3) testowanie w oparciu o instrukcję lub inne pokrycie kodu.
Strona 14 z 39
16. TESTER.PL
Zmiana stany
dynamiczne
systematyczne
czarno
skrzynkowe
dynamiczne
systematyczne
biało skrzynkowe
dynamiczne
intuicyjne czarno
skrzynkowe
dynamiczne
intuicyjne biało
skrzynkowe
statyczne
systematyczne
czarno
skrzynkowe
statyczne
systematyczne
biało skrzynkowe
Doświadczenie
Najczęściej
stosowane
[nie stosuje się]
Np. Testowanie
zachowania
obiektu w pewnej
ilości jego stanów
[nie stosuje się]
[nie stosuje się]
[nie stosuje się]
Podobny raport
okazał się być
niepotrzebny w
przeszłości
Zajęło nam 3 dni
na szukanie błędu
w podobnym
algorytmie
sortującym
Zaprojektowanie
automatu
skończonego do
weryfikacji
spisanej
specyfikacji
wymagań
[nie stosuje się]
Zaprojektowanie
automatu
skończonego do
weryfikacji
[nie stosuje się]
statyczne
intuicyjne czarno
skrzynkowe
[nie stosuje się]
statyczne
intuicyjne biało
skrzynkowe
[nie stosuje się]
W tej dziedzinie
wymagania
użytkownika były
ostatnio bardzo
ogólnikowe
Ten facet używa
skoków zamiast
właściwego
wywołania funkcji!
Strona 15 z 39
Pokrycie kodu
Sprawdzenie, czy
wszystkie metody są
używane (ale nie
cały kod w tych
metodach). OK. to
jest szare, nie
całkiem czarne
Najczęściej
stosowane
[nie stosuje się]
[nie stosuje się]
Inspekcja kodu by
upewnić się, że
przygotowywane
środowisko testowe
zapewni wywołanie
wszystkich stanów;
to znowu jest szare,
nie całkiem czarne
Inspekcja kodu by
zmierzyć możliwe
pokrycie ciężko –
wykonywalnych
fragmentów kodu
[nie stosuje się]
[nie stosuje się]
17. TESTER.PL
To działa. I jesteśmy dumni z tego małego odkrycia, mimo że jest zupełnie
oczywiste (jakkolwiek nieco obce dla konspektów ISEB/ISTQB); oczywiście to nie są
“techniki czarne” ani “techniki białe”, ale są techniki systematyczne lub intuicyjne.
Technika nie może być w tym samym momencie nie systematyczna i systematyczna.
I na końcu miejmy nadzieje, że ten artykuł nie przeszkodzi mojej firmie
akredytować się w przyszłości ☺.
Strona 16 z 39
19. TESTER.PL
Tekst Sponsorowany
Wielu klientów uznaje stworzenie architektury ukierunkowanej na usługi (ang. Service
Oriented Architecture, SOA) za jedną z pięciu najważniejszych inwestycji strategicznych.
Sposób realizacji tego rodzaju architektury ma znaczący wpływ na podejmowane decyzje
dotyczące zakupu rozwiązań technicznych. W związku z tym dostawca powinien
uczestniczyć w rozmowach na ten temat i starać się zdobyć zaufanie klienta jako partner
oferujący rozwiązania w zakresie nadzoru nad systemami, kontroli jakości oraz przestrzegania
umów dotyczących poziomu usług, które pozwolą sprawnie wdrożyć architekturę
ukierunkowaną na usługi w środowisku klienta.
W ramach architektury SOA aplikacje tworzy się w taki sposób, aby funkcjonalność
oprogramowania była dostępna w postaci współdzielonych usług wielokrotnego użytku.
Każda z tych usług odpowiada stosunkowo autonomicznej funkcji merytorycznej lub
technicznej.
Najważniejsze korzyści dla przedsiębiorstw, wynikające z zastosowania architektury
ukierunkowanej na usługi to:
• ograniczenie kosztów integracji infrastruktury informatycznej i szybsze reagowanie
na potrzeby;
• zwiększenie elastyczności i efektywności działania w obliczu takich wyzwań, jak
fuzje i przejęcia, konsolidacja oraz konieczność przestrzegania przepisów i
regulacji prawnych;
• uproszczenie procesu tworzenia, serwisowania i eksploatacji niezawodnych
aplikacji oraz obniżenie związanych z tym kosztów;
• zapewnienie działowi IT elastyczności pozwalającej sprostać stale zmieniającym
się potrzebom przedsiębiorstwa.
Pojęcie „architektura ukierunkowana na usługi” nie jest tylko chwytliwym hasłem —
w oparciu o tego rodzaju architekturę działają aplikacje w wielu dużych, złożonych
przedsiębiorstwach. Niektóre z nich wdrażają tego rodzaju rozwiązania stopniowo, inni
natomiast od samego początku dokonują gruntownych zmian. Niemal każdy — niezależnie
od tego, czy wdraża już taką architekturę — przyznaje, że w najbliższej przyszłości aplikacje
będą rozwijać się właśnie w tym kierunku.
Podstawą działania architektury ukierunkowanej na usługi jest wykorzystanie usług.
Oprócz typowych trudności związanych z testowaniem autonomicznych usług (pełniących
rolę swego rodzaju miniaturowych aplikacji), pojawiają się nowe problemy wynikające z
faktu, że każda usługa jest powiązana z innymi usługami, złożonymi aplikacjami oraz
systemami stanowiącymi podstawę jej działania. Jeśli zachodzi potrzeba zmiany danej usługi,
zmiana ta musi zostać przetestowana przez wszystkich użytkowników tej usługi. Dlatego w
przypadku architektury ukierunkowanej na usługi proces testowania jest jeszcze bardziej
złożony niż w tradycyjnych środowiskach aplikacyjnych, co stwarza ogromne możliwości dla
rozwiązań w zakresie kontroli jakości i testowania wydajności.
Strona 18 z 39
20. TESTER.PL
Ramy działania architektury ukierunkowanej na usługi wyznaczają umowy dotyczące
poziomu usług (ang. service level agreement, SLA). W odniesieniu do każdej usługi
wykorzystywanej przez aplikacje dział IT musi uzgodnić i określić odpowiedni poziom jej
realizacji. Ponadto poziomy usług wymagają stałego monitorowania i raportowania — jest to
warunkiem szybkiego i sprawnego korygowania wszelkich ewentualnych niedociągnięć w
zakresie wydajności i dostępności. Klienci korzystający z architektury ukierunkowanej na
usługi będą także potrzebowali narzędzi umożliwiających rozpoznawanie problemów oraz
tworzenie raportów na temat przestrzegania umów dotyczących poziomu usług z
dokładnością do poszczególnych usług lub warstw infrastruktury. Oprócz tego niezbędne jest
monitorowanie prewencyjne, które pozwala rozpoznawać zachodzące tendencje oraz
porównywać faktyczną i wymaganą jakość działania.
Firma Mercury oferuje trzy kluczowe elementy niezbędne do sukcesu architektury
ukierunkowanej na usługi:
1. mechanizmy nadzoru nad systemami — umożliwiające kontrolę nad procesem
tworzenia reguł działania architektury ukierunkowanej na usługi oraz stosowania tych
reguł;
2. mechanizmy kontroli jakość i wydajności — umożliwiające weryfikowanie
funkcjonalności i wydajności pojedynczych i skoordynowanych usług oraz złożonych
aplikacji;
3. mechanizmy zarządzania umowami dotyczącymi poziomu usług —
umożliwiające definiowanie umów dotyczących poziomu usług oraz pomiar zgodności z
tymi umowami, raportowanie w tym zakresie (w odniesieniu do usług i złożonych
aplikacji).
Strona 19 z 39
21. TESTER.PL
Doskonalenie procesu testowego
za pomocą modeli TMMSW i TPI®
Joanna Nowakowska
Rodan Systems S.A.
Dyrektor Działu Zarządzania Jakością
SJSI
Wiceprezes
Joanna Nowakowska jest dyrektorem Działu Zarządzania Jakością w
firmie Rodan Systems S.A. W 2005 roku jako pierwsza osoba w
Polsce uzyskała tytuł ISTQB Certified Tester, Full Advanced Level.
Współzałożyciel i wiceprezes Stowarzyszenia Jakości Systemów
Informatycznych i Polish Testing Board, członek German Testing
Board.
Strona 20 z 39
22. TESTER.PL
Doskonalenie procesu testowego
za pomocą modeli TMMSW i TPI®
Joanna Nowakowska
Rodan Systems S.A. / SJSI
Dyrektor Działu Zarządzania Jakością / Wiceprezes
Streszczenie
„Jakość to ciągłe doskonalenie wszystkich procesów” – Dr W. E. Deming. W
popularnych modelach dojrzałości i standardach (CMM, CMMI, BOOTSTRAP, SPICE,
ISO 9001) niestety nie poświęcono wystarczającej uwagi kwestii testowania, stąd w
latach 90-tych XX wieku powstało kilka modeli służących ocenie i usprawnieniu
wyłącznie procesu testowania. Dwa z nich – zdecydowanie najważniejsze – zostały
omówione w niniejszym artykule. Pierwszym jest Software Testing Maturity Model
(TMMSW) z Illinois Institute of Technology, drugim – Test Process Improvement®
(TPI®) powstały w IQUIP Informatica B.V. Netherlands (SOGETI). Na końcu artykułu
znalazło się również krótkie porównanie obu modeli.
Testing Maturity Model
Software Testing Maturity Model (TMMSW) został stworzony w 1996 roku w Illinois
Institute of Technology przez Ilene Burnstein, C.R. Carlson i ich współpracowników.
Model TMMSW postrzegany jest jako odpowiednik, bądź nawet rozwinięcie jednego z
najbardziej popularnych modeli dojrzałości organizacyjnej – Capability Maturity Model
(CMM) – i jego kolejnych wersji.
TMMSW leżą założenia historycznego modelu ewolucyjnego (ang.
historical evolutionary model) sformułowanego przez D.Gelperin i B.Hetzel, w którym
to wyszczególniono cztery fazy testowania [1]:
• faza debugowania (ang. debugging-oriented phase), w której testowanie jest
postrzegane jako czynność ułatwiająca usuwanie błędów,
• faza destrukcji (ang. destruction-oriented phase), w której testowanie jest
ukierunkowane na znajdowanie błędów w implementacji,
• faza oceny (ang. evaluation-oriented phase), w której testowanie jest
wykonywane we wszystkich etapach wytwarzania, czynności testowe są
zintegrowane z czynnościami wytwarzania, a samo testowanie jest
ukierunkowane na znajdowanie nieprawidłowości w wymaganiach, projekcie i
w implementacji,
• faza prewencji (ang. prevention-oriented phase), w ramach której nacisk
położony zostaje na przeglądy, a celem czynności testowych jest zapobieganie
nieprawidłowościom na różnych etapach wytwarzania.
U podstaw
Zgodnie z historycznym modelem ewolucyjnym, testowanie w każdej organizacji
przechodzi przez te cztery wymienione etapy. Oceniając wybrane cechy procesu
Strona 21 z 39
23. TESTER.PL
testowego, jesteśmy w stanie określić jego poziom dojrzałości oraz wprowadzać
stopniowe usprawnienia w tym zakresie.
Na TMMSW składają się dwa głównej komponenty, a mianowicie – model dojrzałości i
model oceny. Każdy z tych modeli został opisany pokrótce poniżej.
Model dojrzałości
Model dojrzałości TMMSW definiuje pięć poziomów dojrzałości, a dla każdego poziomu
dodatkowo również: cele (ang. maturity goals), pod-cele (ang. maturity subgoals) –
cele cząstkowe, ułatwiające osiąganie celów głównych, oraz czynności, zadania i
odpowiedzialności (tak zwane ATRs – od: activities, tasks & responsibilities),
podzielone pomiędzy trzy perspektywy (tzw. critical views), czyli trzech kluczowych
uczestników procesu testowego (menadżerów, programistów/testerów oraz
użytkowników/klientów). Strukturę modelu ilustruje Rysunek 1, poszczególne
poziomy dojrzałości – Rysunek 2. Wszystkie poziomy (ang. levels) są powiązane z
poziomami w modelu CMM, każdy poziom określa stopień dojrzałości procesu
testowego i jego właściwości.
Rysunek 1 Struktura modelu dojrzałości TMM
•
Poziom 1 („Initial”). Testowanie wykonywane jest w sposób chaotyczny, po
fazie kodowanie, i jest ukierunkowane na potwierdzenie, że testowany system
w ogóle działa. Na tym poziomie nie wyróżniamy ustrukturalizowanego
procesu testowego, niezależnego zespołu testowego, nie są wykorzystywane
również systematyczne techniki projektowania przypadków testowych, a samo
testowanie nie jest wykonywane w sposób automatyczny. Można by
Strona 22 z 39
24. TESTER.PL
•
•
•
•
stwierdzić, że każda organizacja posiada dojrzałość określaną przez poziom 1
„za darmo”.
Poziom 2 („Phase Definition”). Na tym poziomie rozróżniamy pierwsze cele,
zaczynamy rozróżniać pomiędzy testowaniem a debugowaniem – a także
definiujemy osobne cele dla tych obu czynności. Posiadanie procesu
testowego na poziomie 2 oznacza, że wyróżniona została czynność planowania
testów, w ramach której określony został cel testowania, wykonana analiza
ryzyka, zastosowano podstawowe systematyczne techniki projektowania
przypadków testowych oraz proste narzędzia automatyzujące testowanie.
Poziom 3 („Integration”). Testowanie na tym poziomie nie jest jedynie
czynnością ułatwiającą lokalizowanie błędów implementacyjnych czy
sprawdzenie, że oprogramowanie w ogóle działa. Na poziomie 3 testowanie
zaczyna być ukierunkowane na znajdowanie błędów w wymaganiach, w
projekcie i w kodzie, stąd czynności testowe są zintegrowane z czynnościami
wytwórczymi w całym cyklu życia oprogramowania. Dodatkowo tworzona jest
„organizacja testowa”, dla której planowane są szkolenia merytoryczne z
zakresu testowania, która zaczyna wykonywać również testy negatywne (ang.
negative/robustness tests) i monitoruje proces testowy.
Poziom 4 („Management & Measurement”). Testowanie postrzegane jest jako
mierzalny proces wzbogacony o rozwinięty program przeglądowy oraz miar.
Poziom 5 („Optimization/Defect prevention & quality control”). Najwyższy
poziom dojrzałości procesu testowego, w ramach którego proces jest
kontrolowany, zarządzany i oceniany na każdym kroku pod względem
skuteczności, kosztów i możliwości optymalizacji.
Przykład
Chcąc lepiej wyobrazić sobie, czym są cele, pod-cele i ATRs, przyjrzyjmy się
drugiemu poziomowi dojrzałości modelu TMMSW: Aby zaklasyfikować proces testowy
na poziom 2 („Phase Definition”) wszystkie cele dla tego poziomu powinny być
osiągnięte.
Dla poziomu 2 zdefiniowano następujące trzy cele główne:
• Develop Testing & Debugging Goals and Policies.
• Initiate a Test Planning Process.
• Institutionalize Basic Testing Techniques and Methods.
Przyjrzyjmy się pod-celom dla drugiego celu głównego – Initiate a Test Planning
Process:
• „Test plan templates for all levels of testing are developed, recorded and
distributed to project managers and developers/testers for use in
organizational projects (…)”.
• „Basic planning tools and test measurements are evaluated, and applied”.
• (...).
Jak to się przekłada na czynności, zadania i odpowiedzialności dla wyodrębnionych
trzech perspektyw?
Dla menadżerów:
• „Ensure that test planning policy statements are distributed and approved”.
Strona 23 z 39
25. TESTER.PL
• (...).
Dla programistów / testerów:
• „Assist project (test) manager in determining test goals, test risks and test
costs for planning (…)”.
• (…).
Dla użytkowników / klientów:
• „Supply input and consensus to the acceptance test plan. The required
functional and performance-related attributes that are expected by the
client/users should be specified clearly and quantitatively if possible.”
• (…).
Model oceny
W TMMSW , tak jak w CMM, do oceny zdolności procesu wykorzystuje się
kwestionariusze oceny oraz przeprowadza wywiady z pracownikami organizacji.
Model oceny TMMSW składa się z następujących elementów:
• procedura oceny (ang. Assessment Procedure) – wytyczne wykorzystywane
przez zespół dokonujący oceny, które powinny pomóc im w zbieraniu, analizie
i ocenie danych, a w konsekwencji ułatwiać określenie poziomu dojrzałości
danego procesu testowego;
• kwestionariusz oceny (ang. Assessment Questionnaire) – zestaw pytań
odpowiadających celom, które w powiązaniu z informacjami z wywiadów,
prezentacji i przeglądów odpowiednich dokumentów są podstawą oceny;
• kryteria wyboru zespołu i szkolenia (ang. Assessment Training & Team
Selection Criteria) – program szkoleń dla osób zaangażowanych w proces
oceny (zaadaptowany ze SPICE).
Rysunek 2 Poziomy dojrzałości z wyszczególnieniem celów
Dla tych, którzy chcą szybko sprawdzić zdolność procesu testowego w swojej
organizacji, Erik van Veenendaal w jednym ze swoich artykułów opublikował krótki
Strona 24 z 39
26. TESTER.PL
kwestionariusz – tzw. quick scan [2]. Odpowiadając na zawarte w nim pytania,
jesteśmy w stanie szybko sprawdzić, czy nasz proces testowy jest bardziej czy mniej
dojrzały niż ten wymagany dla poziomu 2 (zob. Rysunek 3).
Rysunek 3 Quick scan
Strona 25 z 39
27. TESTER.PL
Test Process Improvement
Test Process Improvement (TPI®) to model oceny i poprawy procesu testowego,
sformułowany w 1997 roku przez Sogeti Nederland B.V. [3], oferujący środowisko do
identyfikowania słabych i mocnych stron procesu testowego oraz listę możliwych do
wprowadzenia usprawnień.
Model TPI® składa się z następujących elementów:
• model dojrzałości (ang. Maturity Model);
• macierz dojrzałości (ang. Test Maturity Matrix), zawierająca obszary kluczowe
dla procesu testowania (ang. Key Areas), poziomy dojrzałości (ang. Maturity
Levels) oraz skala dojrzałości (ang. maturity scale);
• punkty kontrolne (ang. Checkpoints);
• lista usprawnień (ang. Improvement Suggestions).
Model dojrzałości
Opisywany tutaj model dojrzałości składa się z trzech następujących poziomów:
•
Kontrolowany proces testowy (ang. Controlled test process). Czynności
testowe wykonywane w ramach kontrolowanego procesu testowego
uwzględniane są w harmonogramach projektowych i w budżecie. Mimo iż
wykonywane są wyłącznie testy wysokiego poziomu (ang. high-level tests), w
ramach których przypadki projektowane są w oparciu o systematyczne
techniki, wszystkie prace są na bieżąco kontrolowane i dopasowywane do
potrzeb projektu. Monitorowanie procesu testowego polega na zbieraniu miar
dotyczących produktu i raportowaniu postępu prac (kosztów, kroków
milowych, liczby zgłoszeń wraz z priorytetami). Na tym poziomie
wykorzystywane są również narzędzia wspomagające proces planowania i
kontroli projektu (w tym również projektu testowego).
•
Skuteczny proces testowy (ang. Efficient test process). Na tym poziomie
organizacji zostaje narzucone tworzenie strategii nie tylko dla testów
wysokiego poziomu, lecz również dla testów niskiego poziomu (ang. low-level
tests). Samo testowanie powinno rozpoczynać się już na etapie definiowania
wymagań. Chcąc ocenić skuteczność procesu testowego należy zbierać
informacje z funkcjonowania procesu, a planowanie opierać na danych
statystycznych. Dodatkowo na tym poziomie zespoły testowe wykorzystują w
większym zakresie narzędzia wspierające wykonanie i analizę wyników z
testowania, rozpoczyna się również proces zarządzania testaliami (ang.
testware).
•
Optymizowany proces testowy (ang. Optimizing test process), to proces, który
zainicjowany zostaje już razem z rozpoczęciem projektu wytwórczego, w
którym istnieje możliwość śledzenia wymagań na oprogramowanie w całym
cyklu wytwarzania i odwzorowanie tych wymagań na przypadki testowe a
nawet zgłoszenia z testów. Na tym poziomie mamy do czynienia z połączoną
Strona 26 z 39
28. TESTER.PL
strategią dla wszystkich poziomów testów i oceny, a zbierane miary odnoszą
się do całej organizacji i służą działaniom usprawniającym proces testowy.
Struktura modelu TPI®
Struktura modelu widoczna jest na rysunku poniżej.
Rysunek 4 Struktura modelu TPI®
Obszary kluczowe (ang. Key Areas):
T.Koomen i M.Pol – autorzy modelu TPI® - wyróżnili 20 obszarów kluczowych dla
sprawnego procesu testowego. Idea stojąca za wyszczególnionymi obszarami jest
taka, że każdy proces testowy charakteryzuje pewien zestaw atrybutów (obszarów),
którymi należy zarządzać, które należy kontrolować i sukcesywnie usprawniać, chcąc
żeby cały proces w konsekwencji funkcjonował bardziej efektywnie. Stąd do
obszarów kluczowych zaliczamy wszystkie, moim zdaniem bardzo ważne, aspekty
zapewnienia jakości, takie jak:
• strategia testowania (ang. test strategy),
• model cyklu życia (ang. life-cycle model),
• czas rozpoczęcia testów (ang. moment of involvement),
• estymacja i planowanie (ang. estimationg & planning),
• techniki projektowania przypadków testowych (ang. test specification
techniques),
• statyczne techniki testowania (ang. static test techniques),
• miary (ang. metrics),
• automatyzacja testowania (ang. test automation),
• środowisko testowe (ang. test environment),
• środowisko biurowe (ang. office environment),
• zaangażowanie i motywacja (ang. commitment & motivation),
• funkcje i odpowiedzialności oraz szkolenia (ang. testing functions & training),
• zakres metodologii (ang. scope of methodology),
• komunikacja (ang. communication),
• raportowanie (ang. reporting),
• zarządzanie zgłoszeniami (ang. defect management),
• zarządzanie procesem testowym (ang. test process management),
Strona 27 z 39
29. TESTER.PL
•
•
ocena (ang. evaluation),
testowanie niskiego poziomu (ang. low-level testing).
W samym modelu każdy z obszarów kluczowych został oczywiście dodatkowo
dokładniej opisany. Taki opis dla dwóch wybranych przykładowo obszarów
kluczowych – strategii testowania oraz czasu rozpoczęcia testów ilustruje Rysunek 5.
Rysunek 5 Definicje obszarów kluczowych TPI®
Poziomy dojrzałości (ang. Maturity Levels):
Dla obszarów kluczowych wyróżniamy następujące poziomy dojrzałości: „0” (proces
nie spełnia wszystkich wymagań dla poziomu A), i od A do D. Nie każdy obszar
kluczowy musi mieć dokładnie 4 poziomy dojrzałości (zwykle obszar kluczowy ma
przyporządkowane 3 poziomy). Na Rysunek 6 widoczne są pewne wymagania dla
poszczególnych poziomów dojrzałości w obszarze strategii testowania i czasu
rozpoczęcia testowania.
Rysunek 6 Definicje poziomów dojrzałości
Punkty kontrolne (ang. Checkpoints):
Model TPI® dostarcza prostego narzędzia pomiarowego. Wymagania na każdy
poziom dojrzałości danego obszaru kluczowego zdefiniowane są w formie punktów
kontrolnych (zob. Rysunek 7 Przykład punktów kontrolnych (dla obszaru „strategia
testowania”) – pytań, na które należy udzielić twierdzącej odpowiedzi, jeżeli chcemy
zaklasyfikować nasz proces testowy na dany poziom. Punkty kontrolne się kumulują,
Strona 28 z 39
30. TESTER.PL
tzn. chcąc zaklasyfikować proces testowy do poziomu B w ramach danego obszaru
kluczowego, nie tylko wszystkie wymagania na ten poziom muszą być spełnione, lecz
również wszystkie wymagania na poziom A.
Rysunek 7 Przykład punktów kontrolnych (dla obszaru „strategia testowania”)
Usprawnienia (ang. Improvement Suggestions):
Autorzy wraz z modelem dostarczają listę podpowiedzi usprawnień, które, mimo iż
nie są wymagane, ułatwiają osiąganie wyższych poziomów dojrzałości procesu
testowego.
Macierz dojrzałości (ang. Test Maturity Matrix)
Ze względu na fakt, że nie wszystkie obszary kluczowe są jednakowo istotne, oraz
dlatego, że istnieją zależności pomiędzy poszczególnymi obszarami, autorzy modelu
stworzyli listę zależności międzyobszarowych oraz tzw. macierz dojrzałości. Na
Rysunek 8 przedstawiony został przykład zależności pomiędzy obszarami kluczowymi
modelu. Stąd, chcąc zaklasyfikować proces testowy na poziom „A” w obszarze
„strategii testowania” należy mieć proces testowy zaklasyfikowany na poziomie „A”
dla 5. obszaru kluczowego, którym jest obszar „techniki projektowania przypadków
testowych” (5a) oraz na poziomie „A” dla 11. obszaru – „zaangażowania i
motywacji”.
Nr
1
5
11
Obszar kluczowy
Strategia testowania
Poziom A
B
C
D
Strategia dla pojedynczego
(...) (...) (...)
testu wysokiego poziomu (5a,
11a)
Techniki projektowania Techniki nieformalne
(...) (...) (...)
przypadków testowych
Zaangażowanie i
Przydzielenie budżetu i czasu
(...) (...) (...)
motywacja
Rysunek 8 Przykład zależności pomiędzy obszarami kluczowymi
Wszystkie tego typu zależności widoczne są w macierzy dojrzałości (zob. Rysunek 9).
W lewej kolumnie macierzy znajduje się lista obszarów kluczowych, w nagłówkach –
tzw. skala dojrzałości. Z założenia, miejsce umiejscowienia liter określających
dojrzałość obszarów kluczowych ujawniają wagę danego poziomu i obszaru
Strona 29 z 39
31. TESTER.PL
(podstawowe i najważniejsze obszary znajdują się bardziej na lewo w macierzy –
wymagania na te obszary powinny być spełnione w pierwszej kolejności).
Jak wypełniona macierz przenosi się na jeden z trzech poziomów dojrzałości samego
procesu testowego? Autorzy modelu przyjęli założenie, że jeżeli proces testowy
spełnia wymagania zawarte na skali od 1 do 5 to jest to kontrolowany proces
testowy, od 6 do 10 – skuteczny proces testowy, powyżej 10 – optymizowany (zob.
Rysunek 10).
Rysunek 9 Przykład wypełnionej macierzy dojrzałości
W przypadku, gdy choć jeden z obszarów został zaklasyfikowany do poziomu „0”,
cały nasz proces ma poziom „0”.
Strona 30 z 39
33. TESTER.PL
Wsparcie narzędziowe
Dodatkowym atutem modelu TPI® jest możliwość skorzystania z darmowego
narzędzia, które w znaczący sposób ułatwia analizę stanu procesu testowego. TPI
Scoring Tool [5] zawiera opis wszystkich obszarów kluczowych modelu, punkty
kontrolne i listę usprawnień (zob. Rysunek 11). Odpowiadając na pytania zawarte w
punktach kontrolnych, tabelka z rezultatami oceny oraz macierz dojrzałości
aktualizowane są w sposób automatyczny (zob. Rysunek 12).
Rysunek 11 Tabela wyników oceny (narzędzie TPI Scoring Tool)
Strona 32 z 39
34. TESTER.PL
Rysunek 12 Macierz dojrzałości w narzędziu TPI Scoring Tool
Porównanie modeli
Cel modelu
Praktycznie oba modele mają podobny cel, którym jest identyfikacja słabych i
mocnych stron procesu testowego (czyli de facto ocena stanu procesu testowego).
Mimo to, można powiedzieć, że model TPI® jest bardziej ukierunkowany na
wprowadzanie usprawnień, gdyż posiada listę usprawnień, które mogą być
wykorzystane przez każdą organizację.
Struktura
TMMSW ma strukturę podobną do struktury modelu CMM. TPI® nie posiada struktury
poziomowej.
Zawartość merytoryczna
TMMSW nie uwzględnia następujących obszarów (które uwzględnia TPI®):
• środowisko testowe,
• środowisko biurowe,
• raportowanie,
• zarządzanie zgłoszeniami,
Strona 33 z 39
35. TESTER.PL
•
zarządzanie testaliami.
Procedura oceny
TMMSW posiada kwestionariusz oceny, TPI® - punkty kontrolne. Jest więcej punktów
kontrolnych niż pytań w kwestionariuszu. TPI® nie posiada wytycznych do wyboru
zespołu kontrolującego ani zaleceń szkoleniowych.
Formalna certyfikacja (zewnętrzna)
Nie ma możliwości uzyskania certyfikatu na posiadanie procesu testowego o danej
dojrzałości, na zgodność z żadnym modelem.
Dodatkowe porównanie zawiera Rysunek 13 Porównanie obu modeli [6]Rysunek
13.
Rysunek 13 Porównanie obu modeli [6]
Strona 34 z 39
36. TESTER.PL
Bibliografia
[1] D. Gelperin, B.Hetzel, 1988. The growth of software testing. Communications of
the Association of Computing Machinery 31, no.6: 687-695.
[2] Guidelines for Testing Maturity, Part 2: Test Maturity Model level 2, published:
Professional Tester, Volume Three, Issue No. 2, June 2002,
http://www.improveqs.nl/pdf/TMM%20testing%20professional%20part%202.pdf
[3] Sogeti Nederland B.V.: http://www.sogeti.nl
[4] T.Koomen, M.Pol, Improvement of the Test Process Using TPI, Sogeti Nederland
B.V., Diemen 1998.
[5] TPI Scoring Tool: http://www.sogeti.nl/images/ACFISItp9_tcm6-1829.xls
[6] R. Swinkels, A comparison of TMM and other Test Process Improvement models
Literatura dodatkowa:
Testing Maturity Model:
• TMMi™ Foundation: http://www.tmmifoundation.org/
• Wind Ridge International LLC: www.WindRidgeInternational.com
• Practical Software Testing: Ilene Burnstein, Springer-Verlag, New York 2003
• Burnstein I., Suwannasart T., Carlson C.R., “Developing a Testing Maturity
Model: Part I”, http://www.stsc.hill.af.mil/crosstalk/1996/08/developi.asp
• Burnstein I., Suwannasart T., Carlson C.R., “Developing a Testing Maturity
Model: Part I”, http://www.stsc.hill.af.mil/crosstalk/1996/09/developi.asp
• Staab T., “Using SW-TMM to Improve The Testing Process”,
http://www.stsc.hill.af.mil/crosstalk/2002/11/staab.pdf
• “Is a Testing Maturity Model In Your Future?”, http://www.tanstiafnf.com/CMTUpload/ CourseMaterials/sw-tmm_staab11111.pdf
• “Software Testing Maturity Model (SW-TMM)”,
http://www.cs.umd.edu/~atif/Teaching/ Fall2002/StudentSlides/Duy.pdf
• Epic Programs (Presentation): http://epic.onion.it/workshops/w06/slides01/
Test Process Improvement:
• Sogeti Nederland: http://www.sogeti.nl
• TPI Scoring Tool: www.sogeti.nl/images/ACFISItp9_tcm6-1829.xls
• Koomen T., Pol M., “Test Process Improvement. A practical step by step to
structured testing.”, Addison-Wesley, 1999
• Andersin J., “TPI – a model for Test Process Improvement”,
http://www.cs.helsinki.fi/u/paakki/Andersin.pdf
• Jacobs J., van Moll J., Stokes T., “The Process of Test Process Improvement”,
http://www.improveqs.nl/pdf/Jacobs,%20Moll,%20Stokes.pdf
Porównania:
• Swinkels R., „A comparison of TMM and other Test Process Improvement
Models”, http://is.tm.tue.nl/research/v2m2/wp1/12-4-1-FPdef.pdf
Strona 35 z 39
