TESTER.PL

Strona 1 z 39

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

TESTER.PL

Strona 2 z 39

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.

TESTER.PL

Strona 3 z 39

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.

TESTER.PL

Strona 4 z 39

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ść

TESTER.PL

Strona 5 z 39

• 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

TESTER.PL

Strona 6 z 39

Tekst Sponsorowany

TESTER.PL

Strona 7 z 39

Tekst Sponsorowany

TESTER.PL

Strona 8 z 39

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

TESTER.PL

Strona 9 z 39

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.

TESTER.PL

Strona 10 z 39

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

TESTER.PL

Strona 11 z 39

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ą

TESTER.PL

Strona 12 z 39

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

TESTER.PL

Strona 13 z 39

„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 Intuicyjne Czarno skrzynkowe Systematyczne

czarno skrzynkowe Intuicyjne czarno skrzynkowe

Biało skrzynkowe Systematyczne biało skrzynkowe

Intuicyjne biało skrzynkowe

Rysunek 2.

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

TESTER.PL

Strona 14 z 39

staticsystematic black-box

staticintuitive

black-box

staticintuitive

white-box

staticsystematic white-box

dynamicsystematic black-box

dynamicintuitive

black-box

dynamicintuitive

white-box

dynamicsystematic 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.

TESTER.PL

Strona 15 z 39

Zmiana stany Doświadczenie Pokrycie kodu dynamiczne systematyczne czarno skrzynkowe Najczęściej

stosowane [nie stosuje się]

Sprawdzenie, czy wszystkie metody są używane (ale nie cały kod w tych metodach). OK. to jest szare, nie całkiem czarne

dynamiczne systematyczne biało skrzynkowe

Np. Testowanie zachowania obiektu w pewnej ilości jego stanów

[nie stosuje się] Najczęściej stosowane

dynamiczne intuicyjne czarno skrzynkowe [nie stosuje się]

Podobny raport okazał się być niepotrzebny w przeszłości

[nie stosuje się]

dynamiczne intuicyjne biało skrzynkowe [nie stosuje się]

Zajęło nam 3 dni na szukanie błędu w podobnym algorytmie sortującym

[nie stosuje się]

statyczne systematyczne czarno skrzynkowe

Zaprojektowanie automatu skończonego do weryfikacji spisanej specyfikacji wymagań

[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

statyczne systematyczne biało skrzynkowe

Zaprojektowanie automatu skończonego do weryfikacji

[nie stosuje się]

Inspekcja kodu by zmierzyć możliwe pokrycie ciężko – wykonywalnych fragmentów kodu

statyczne intuicyjne czarno skrzynkowe [nie stosuje się]

W tej dziedzinie wymagania użytkownika były ostatnio bardzo ogólnikowe

[nie stosuje się]

statyczne intuicyjne biało skrzynkowe [nie stosuje się]

Ten facet używa skoków zamiast właściwego wywołania funkcji!

[nie stosuje się]

TESTER.PL

Strona 16 z 39

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 ☺.

TESTER.PL

Strona 17 z 39

Tekst Sponsorowany

TESTER.PL

Strona 18 z 39

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.

TESTER.PL

Strona 19 z 39

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).

TESTER.PL

Strona 20 z 39

Doskonalenie procesu testowego za pomocą modeli TMMSW i TPI®

Joanna Nowakowska

Rodan Systems S.A. SJSI Dyrektor Działu Zarządzania Jakością 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.

TESTER.PL

Strona 21 z 39

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. U podstaw 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.

Zgodnie z historycznym modelem ewolucyjnym, testowanie w każdej organizacji przechodzi przez te cztery wymienione etapy. Oceniając wybrane cechy procesu

TESTER.PL

Strona 22 z 39

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

TESTER.PL

Strona 23 z 39

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”.

TESTER.PL

Strona 24 z 39

• (...). 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

TESTER.PL

Strona 25 z 39

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

TESTER.PL

Strona 26 z 39

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ą

TESTER.PL

Strona 27 z 39

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),

TESTER.PL

Strona 28 z 39

• 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ą,

TESTER.PL

Strona 29 z 39

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 Obszar kluczowy Poziom A B C D 1 Strategia testowania Strategia dla pojedynczego

testu wysokiego poziomu (5a, 11a)

(...) (...) (...)

5 Techniki projektowania przypadków testowych

Techniki nieformalne (...) (...) (...)

11 Zaangażowanie i motywacja

Przydzielenie budżetu i czasu (...) (...) (...)

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

TESTER.PL

Strona 30 z 39

(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”.

TESTER.PL

Strona 31 z 39

Rysunek 10 Macierz dojrzałości a poziom dojrzałości procesu testowego

TESTER.PL

Strona 32 z 39

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)

TESTER.PL

Strona 33 z 39

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,

TESTER.PL

Strona 34 z 39

• 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]

TESTER.PL

Strona 35 z 39

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.tanstia-

fnf.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

TESTER.PL

Strona 36 z 39

Tekst sponsorowany

TESTER.PL

Strona 37 z 39

TESTER.PL

Strona 38 z 39