Tester.pl - Numer 6

Click here to load reader

  • date post

    28-Nov-2014
  • Category

    Documents

  • view

    1.141
  • download

    4

Embed Size (px)

description

 

Transcript of Tester.pl - Numer 6

  • 1. TESTER.PL Witam Was Drodzy Czytelnicy Tydzie temu w Katowicach Natura brutalnie przetestowaa projekt jednego z budynkw, jakich wiele wok nas. Nie zwracaem zwykle na to uwagi, ale po tym zdarzeniu jako tester zadaem sobie kilka pyta: Czy wszystkie te konstrukcje, hale, supermarkety, stadiony kto wystarczajco przetestowa? Czy zweryfikowa projekt w fazie testw statycznych dokumentacji? Jakie byy zaoenia do testw wydajnociowych? Z drugiej strony czy przypadkiem nie zaniedbano fazy utrzymania nagromadzone due iloci niegu przypominaj troch krytyczne przecienie systemu, tyle e w IT skutki bywaj zazwyczaj duo agodniejsze. Wydawaoby si, e budowlanka to dziedzina duo bardziej zaawansowana i dojrzalsza projektowo i procesowo ni projekty IT. A jednak okazuje si, e i tutaj zdarzaj si tragiczne pomyki. Z kadego nawet tego najtragiczniejszego dowiadczenia trzeba wycign wnioski i nauk. Niech ta katastrofa uwiadomi nam, e w rzeczywistoci od nas jako twrcw software (a szczeglnie testerw) moe zalee czyje ycie. Wszystkim czytelnikom, ktrych w jaki sposb dotkna ta tragedia, oraz osobom z Katowic, Chorzowa, caego lska skadam gbokie wyrazy wspczucia. Ostatnio mielimy troch zmian wewntrz Stowarzyszenia, a wiadczy to m. in. te o tym, e SJSI yje i rozwija si. 15 grudnia 2005 roku odbyo si Nadzwyczajne Walne Zebranie Czonkw SJSI. W wyniku gosowania do Zarzdu przyjto Joann Nowakowsk i Piotr Kauskiego. Podczas ostatniego Zebrania Zarzdu Joanna i Piotr zostali powoani na stanowiska V-ce Prezesa i Sekretarza Zarzdu SJSI. Nominowanym serdecznie gratuluj! Korzystajc z okazji chciabym podzikowa Adamowi Suskiewiczowi, za bardzo duy wkad, jaki wnis do SJSI bdc czonkiem-zaoycielem i Sekretarzem Zarzdu. Ju dzisiaj chciabym Was zaprosi na konferencj organizowan wsplnie z tygodnikiem Computerworld w dniach 22-24 maja. Zapowiada si interesujce spotkanie. Wicej informacji wewntrz numeru. Z pozdrowieniami, Wojciech Jaszcz Prezes SJSI Strona 1 z 39
  • 2. TESTER.PL Od redaktora Wraz z pocztkiem Nowego Roku (w poowie lutego ) dostajecie kolejny ju szsty - numer kwartalnika TESTER.PL. W tym numerze tylko (a!!) dwie pozycje: 1. Bogdan Bereza Jarociski o niezgodnociach w nazewnictwie przy szkoleniach testerskich 2. Joanna Nowakowska o doskonaleniu procesu testowego za pomoc modeli TMM i TPI rzecz majca bardzo due praktyczne zastosowanie Numer otwiera zaproszenie na III Konferencj Systemw Informatycznych, tym razem wsplny produkt tygodnika Computerworld i naszego Stowarzyszenia. Zapraszamy wszystkich w dniach 22 24 maja 2006. Poczenie wysikw ze strony tygodnika Computerworld i SJSI powinno zapewni, e bdzie to konferencja jeszcze ciekawsza od poprzednich. Gorco namawiam do uczestnictwa!!. Ze wzgldu na nasze kontakty midzynarodowe w numerze take zaproszenie do: Dusseldorfu, na ICSTEST2006. Na tej konferencji na pewno bdziemy reprezentowani, wystarczy zajrze na stron Konferencji, a kilka znajomych nazwisk na pewno znajdziecie Berlina, na CONQUEST2006. Jeeli macie troch czasu kocem wrzenia, warto go zarezerwowa i wybra si na t konferencj zapowiada si bardzo ciekawie. Poniewa SJSI jest organizacj wspierajc tej konferencji moemy liczy na istotne zniki wpisowego Na ostatnich stronach Testera.pl informacja o kolejnej edycji kursu Certyfikowany Test Manager wsplnego przedsiwzicia IIR i SJSI Zamieszczamy tez informacje o szkoleniach organizowanych przez BBJTest. Dla chccych si podszkoli wietna okazja. Rwnoczenie chciabym kolejny raz - gorco zachci wszystkich czytelnikw tego periodyku do aktywnej wsppracy. Cay czas czekamy na Pastwa uwagi, artykuy, felietony wszystko, co Was interesuje, co chcielibycie przeczyta, czego si dowiedzie. Jeeli tylko bdziemy mogli, postaramy si zrealizowa Pastwa postulaty. Strona 2 z 39
  • 3. TESTER.PL III Konferencja Jakoci Systemw Informatycznych * CEL Celem konferencji jest przekaz wiedzy i publiczny dyskurs dotyczcy jakoci w kontekcie systemw IT. Zawarto wystpie bdzie si koncentrowaa wok wieloaspektowego spojrzenia na jako oprogramowania i systemw informatycznych w procesach ich tworzenia, kontraktowania, utrzymania i audytu. KIEDY I GDZIE 22-24 maja 2006 r., okolice Warszawy. DLA KOGO Tematyka konferencji bdzie interesujca zarwno dla reprezentantw firm IT oraz software housew, jak i przedstawicieli korporacyjnych oraz instytucjonalnych uytkownikw rozwiza informatycznych. Tym pierwszym zaley na zapewnieniu wysokiej jakoci dostarczanych rozwiza - oprogramowania i caych systemw informatycznych. Ci drudzy nadzoruj, bd prowadz dziaania zwizane z tworzeniem oprogramowania, wdraaniem systemw informatycznych, ich zamawianiem, odbiorem i audytem (np. operatorzy telekomunikacyjni, banki, firmy ubezpieczeniowe, zakady przemysowe, najwiksze urzdy centralne i in.). * Przedsiwzicie jest organizowanie wsplnie przez tygodnik Computerworld i Stowarzyszenie Jakoci Systemw Informatycznych konferencja powstaa z poczenia dwch osobnych konferencji, z ktrych kada miaa ju swoje dwie edycje Krajowej Konferencji Jakoci Systemw Informatycznych oraz Konferencji Stowarzyszenia Jakoci Systemw Informatycznych. Strona 3 z 39
  • 4. TESTER.PL KTO BDZIE WYSTPOWA Wystpowa bd specjalici i menederowie, ktrzy bd prezentowa przede wszystkim swoje osobiste, praktyczne dowiadczenie. Podstawowym zaoeniem konferencji jest jej mocny wymiar praktyczny konferencja ma by prowadzona pod hasem "przez praktykw dla praktykw". KOMITET PROGRAMOWY Jerzy Bielec, CIO (d. PKN Orlen) Tomasz Byzia, StrictWise Marcin Sikorski, Politechnika Gdaska Lucjan Stapp, Politechnika Warszawska Lilianna Wierzcho, Computerland ZAOENIA PROGRAMOWE Konferencja ma umoliwi przekazanie wiedzy, dowiadcze, informacji pomocnych w budowie rozwiza i sposobw organizacji pracy gwarantujcych uzyskanie i utrzymanie wysokiej jakoci aplikacji i systemw IT. Moliwe jest przedstawienie metodyk oraz rnych metod kontroli jakoci tworzonego oprogramowania. Uytkownicy rozwiza informatycznych z kolei bd mogli si dowiedzie, w jaki sposb wybra dobrego dostawc i system o wysokiej jakoci; jak sprawdzi, czy spenia on przyjte zaoenia oraz jak go prawidowo wdroy. TEMATYKA Automatyzacja testowania Czynnik ludzki w jakim stopniu jako zaley od personelu Czynniki decydujce o jakoci systemw IT (powizanie z kultur biznesow firmy, ad korporacyjny, IT Governance) Ergonomia i uyteczno jako czynniki wpywajce na satysfakcj uytkownika Etyka biznesu a jako systemw IT Jako i testowanie w rednich i maych projektach Jako w organizacji i projekcie Jako we wdraaniu systemw COTS i tych realizowanych na zamwienie Metodyki testowania Metodyki prowadzenia projektw a jako Narzdzia informatyczne i rozwizania organizacyjne wspomagajce osiganie i utrzymanie wysokiej jakoci (w tym narzdzia wspomagajce procesy specyfikacji, tworzenia i weryfikacji oprogramowania) Outsourcing testw Prawne aspekty jakoci w IT Rola standardw i instytucji atestujcych, jakociowe standardy formalne a standardy de facto Systemy zapewnienia jakoci w procesach wytwarzania, kontraktowania i odbioru oprogramowania Usugi IT, SLA, outsourcing w kontekcie poziomu i zapewnienia jakoci Wymagania a jako Strona 4 z 39
  • 5. TESTER.PL Zarzdzanie procesem testowym Metody pomiaru kosztw testowania FORMA WYSTPIE Prezentacje standardowo maj trwa 45 minut (30 minut wykadu plus 15 minut dyskusji). HARMONOGRAM 25 stycznia 2006 (roda) ostateczny termin nadsyania formularzy zgoszeniowych 7 luty 2006 (wtorek) termin wstpnej akceptacji zgoszonych propozycji wystpie, kontakt z wybranymi autorami (Rada Programowa) 20 marca 2006 (poniedziaek) ostateczny termin na nadsyanie penych abstraktw (prelegenci) 2 kwietnia 2006 (niedziela) termin weryfikacji nadesanych abstraktw, wstpny harmonogram, kontakt z wybranymi autorami 20 kwiecie 2006 (czwartek) ostateczny termin nadsyania materiaw do materiaw konferencyjnych (abstrakt lub slajdy) 5 maja 2006 (pitek) termin przesania uwag autorom prezentacji (Rada Programowa) 15 maja 2006 (poniedziaek) ostateczny termin nadsyania finalnych wersji materiaw (do druku) Serdecznie zapraszamy! Zarzd Stowarzyszenia Jakoci Systemw Informatycznych Strona 5 z 39
  • 6. TESTER.PL Tekst Sponsorowany Strona 6 z 39
  • 7. TESTER.PL Tekst Sponsorowany Strona 7 z 39
  • 8. TESTER.PL To oczywicie nieprawda!1 Wyznanie nauczyciela testerw Bogdan Bereza-Jarociski bbjTest Bogdan Bereza-Jarociski Psycholog z Uniwersytetu Warszawskiego i Londyskiego, informatyk z uniwersytetu w Lund. Testowa, zarzdza, automatyzowa, koordynowa lub ulepsza procesy testowe zarwno w zastosowaniach wbudowanych (telekomunikacja Ericsson, sygnalizacja kolejowa Bombardier) jak i otwartych (bazodanowe, Java). Lubi udziela si na midzynarodowych konferencjach i prowadzi szkolenia z dziedziny testowania. Od 2002 roku prowadzi w Polsce szkolenia m. in. na certyfikat ISEB. 1 Pierwotna wersja tego artykuu - w wersji angielskiej - ukazaa si w Professional Tester, w numerze z listopada 2005 Tumaczenie pochodzi od redakcji, zmiany i poprawki od autora. Uwaga: autor zdy dokona tylko niektrych poprawek i ma wraenie, e wersja przetumaczona jest miejscami niejasna i bardziej zawia od oryginau. Zwaszcza razi autora stosowanie terminw skaza oraz usterka na okrelenie poczciwego bdu (defektu). S one wprawdzie zgodne z oficjalnym tumaczeniem Glossary ISTQB, ale wprowadzaj w bd Strona 8 z 39
  • 9. TESTER.PL To oczywicie nieprawda! Wyznanie nauczyciela testerw Bogdan Bereza-Jarociski bbjTest Ludzie przychodz na kursy testowania oprogramowania, by nauczy si czego nowego o tym, jak wykonywa sw (testera) prac. Te nowe umiejtnoci to np. nowe metody, techniki lub podejcia, o ktrych istnieniu nic nie wiedzieli lub nowe zastosowania znanych im idei: bardziej strukturalne, bardziej konsekwentne, bardziej prawdziwe, a wic bardziej uyteczne. My, instruktorzy, robimy co moemy, by da im to co chc i potrzebuj. Czasami nie mamy jednak penej kontroli nad programami nauczania, ma to miejsce wtedy gdy prowadzimy autoryzowane kursy, ktre musz spenia zdefiniowane uprzednio konspekty. Jak na razie nie jest le: w mojej opinii midzynarodowe konspekty - albo w peni midzynarodowe, np. ISTQB, lub de facto akceptowane jako midzynarodowe, np. ISEB - s wspaniae, Ich istnienie wymusza podniesienie umiejtnoci testowania na wyszy poziom, akredytacja zapewnia jednolity poziom jakoci rnych dostawcw kursw i - wreszcie - certyfikat ma take wiele pozytywnych efektw. Podczas uczenia, najgorsz rzecz jest obserwowa znudzenie suchaczy. Drug w kolejnoci najgorsz rzecz to ujrzenie w ich oczach marzycielskiego, mistycznego spojrzenia, oznaczajcego e to co wyjaniasz dopasowuje si w ich oczekiwa. Takie spojrzenie oznacza dwie ze rzeczy: zaznaczenie "zbyt teoretyczne" w arkuszu ocen Twego kursu, oraz niepowodzenie uczestnika kursu, gdy wdraa t now umiejtno w praktyce. Bd szczery: widziaem ten lnicy bysk w oczach moich kursantw wiele razy. I tu niespodzianka: zdarza si to najczciej, 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 OCZYWICIE NIEPRAWDA!. Zgodnie z ISEB i ISTQB realne spojrzenie - w skrcie - jest nastpujce: S dwa podstawowe obszary testowania: techniki testw dynamicznych i testw statycznych. ISTQB punktuje nieco lepiej: przynajmniej nie naley wyjania Twoim zdumionym suchaczom (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 testw" nie oznaczaj np. technik wykonania, ale techniki projektowania. W terminologii ISTQB istniej "techniki statyczne" i techniki projektowania testw. Zdecydowanie adniejsze nazwy, tym niemniej naley w dalszym cigu zapewnia suchaczy, e okrelenie "technika statyczna" nie oznacza po prostu nic-nie- robienia. Strona 9 z 39
  • 10. TESTER.PL Porzdnie zbudowane bloki ustawiaj si porzdnie na miejscu: przegldy i analiza statyczna, czarna skrzynka i biaa skrzynka, podzia na klasy rwnowanoci i analiza wartoci brzegowych, "odkrywanie bdw" (ISEB) i "techniki oparte o dowiadczenie" (ISTQB). Zdecydowanie wol okrelenie ISEB, bo to zawsze jest zabawne zgadywanie co obecnie znaczy "znajdowanie skaz", "znajdowanie awarii" lub po prostu "zgadywanie bdw". W obu przypadkach, zarwno w konspekcie ISEB jak i w ISTQB, te techniki wbijane s na samym kocu: opisuj NA KOCU t technik, ktra w rzeczywistoci jest PIERWSZA. W peni oczywiste. Jeeli przyjrzymy si bliej konspektowi ISTQB, nasz may krasnoludek powraca: wspaniaa nazwa "testowanie oparte na dowiadczeniu" ukrywa si w "pisanie przypadkw testowych w oparciu o [...] wiedz o [..] skazach". Poniewa "skaza" w jzyku ISTQB oznacza to samo co ""awaria" w jzyku ISEB, wic mielszy ucze zawsze podnosi sw maa rczk i pyta "przepraszam panie psorze, ale ostatnim razem projektowaem moje przypadki testowe w oparciu o moja wiedz o awariach, nie o skazach. Czy to bardzo le?" Oczywicie zapewniam go, e nie. Tak zachceni, nastpni podnosz rce. Zawstydzona maa dziewczynka pyta " Przepraszam panie psorze, ale raz zaprojektowaam przypadki testowe w oparciu o moj wiedz o tym, e stos programu jest przechowywany w pliku rejestru na mikroprocesorze, i e jest 256 rejestrw, i kiedy potrzebuj wicej stosu, wymieniam go z RAMem...Jakiego koloru jest to testowanie? By moe to jest silikonowe testowanie, panie psorze? Bo poza wszystkim innym, co jest bielsze od bieli?" Zanim zdyem j zgani za zadawanie niewaciwych pyta, odrobin wolniej mylcy chopiec wymamrota: " a ja zawsze jestem taki gupi, panie psorze ale ja naprawd nie wiedziaem e to le, uyem podziau na klasy rwnowanoci przy projektowaniu przypadkw testowych, by sprawdzi czy prawidowo obsuguj parametry w C++, ale naprawd, prosz pana, nie wiedziaem, e to nie jest dozwolone, bo to technika czarno-skrzynkowa, sowo daje, bd o tym pamita nastpnym razem...". Jeeli ten kurs by prowadzony zgodnie z konspektem ISTQB, mgbym mu jedynie powiedzie, eby bardziej uwaa w przyszoci ("pewne techniki wpadaj tylko do jednej kategorii, inne maj elementy z wicej ni jednej kategorii"). Gdyby to by kurs zgodny z ISEB, powiedziabym mu, ze ma jutro przyj do szkoy z rodzicami. Wydaj si, e troch przesadziem z narrativum. Na kursy przychodz doroli profesjonalici, nie mwi do mnie " przepraszam, panie psorze". Na tym etapie, albo si wyczaj i pi, albo s zmieszani albo li, a ja stoj przed nimi, na rwni bojc si ich znudzenia (za ocena w arkuszu oceniania) jak ich zoci (jest ich zdecydowanie wicej i s duo modsi ode mnie). Ale to co powoduj, e kamieniej, to sytuacja, gdy kto moe mnie spyta: No dobrze, panie Mdrala, my nie uywamy adnej z paskich piknych technik. My nie zgadujemy bdw, jakiekolwiek one s, bo nie jestemy czarodziejami, i nie mamy zielonego pojcia gdzie one mog by. My po prostu projektujemy przypadki testowe tak by pokryway wymagania na nasz system, ale robimy to w jzyku naturalnym, nie uywamy przypadkw uycia ani maszyn skoczonych. I prosz mi powiedzie, panie Mdrala, jakie testy robimy?" Bdc tchrzem, uywam starego triku tchrzy i staram si skrci moje mczarnie. Mrucz wic co o konspekcie bdcym kompromisem lub koniecznym uproszczeniem. Mam te moliwo odwoania si do pewnych miesznych wyborw Strona 10 z 39
  • 11. TESTER.PL by pytania egzaminacyjne byo sformuowane atwiej (np. w kursie ISEB zupenie niepotrzebne jest wczenie wyliczania indeksu McCabe do konspektu uatwia mi prociej osign mj cel). Jednak nawet tchrz ma czasami do i chciaby stan w twarz rzeczywistoci zamiast j omija. Spjrzmy prawdzie w twarz: pokrcone kwalifikacja z obu konspektw zawiera multum niepotrzebnych i bezuytecznych faktw i technik, co wicej le one si odzwierciedlaj w rzeczywistoci przemysu oprogramowania. A mwi nam co zupenie przeciwnego! Jak naprawd dobiera si przypadki testowe? Tak, testowanie jest oparte na ryzyko, mimo e nienawidz powtarza ten frazes. Projektowanie przypadkw testowych oznacza wybr setki lub tysica tych najbardziej istotnych z 101000 teoretycznie moliwych. I co naprawd oznacza okrelenie najbardziej istotnych? Na rysunku1 poniej podano kompletny diagram umoliwiajcy decyzj o wanoci moliwego przypadku testowego. Rysunek 1 Poniej zaprezentuj pene wyjanienie, odwoujc si do numerw wzw. Przy zaoeniu, e przypadki testowe s rwnie atwe do wykonania [2], bardziej istotne [1] s te ktre mog spowodowa powaniejsze awarie [3], przy czym cae poddrzewo poniej [3] opisuje od czego waniejsze awarie zale. Tym niemniej, kiedy awarie maja podobny poziom wanoci [3], raczej wybierzemy te przypadki testowe [1], ktre atwiej wykona [2] ni takie ktre nie daj Strona 11 z 39
  • 12. TESTER.PL wiarygodnych rezultatw z powodu kopotw przy wykonaniu lub sabej obserwowalnoci [4] czy te takich, ktrych wykonanie jest drogie [4] Wano awarii [3] jest - tak jak w podejciu tradycyjnym - funkcj swych konsekwencji lub ceny [5] lub jej awarii prawdopodobiestwa [6]. Jak pozna cen awarii? W zasadzie to nie jest problem testw, ale biznesu [9]. Jeeli ich grzecznie zapyta, to na pewno grzecznie odpowiedz , ...naley si wystrzega, by nie zapytali Ciebie, jakie awarie s moliwe. Prawdopodobiestwo awarii [6] jest funkcj prawdopodobiestwa skaz[9] i uycia [7] (czciej nazywanym czstotliwoci wystpienia). Prawdopodobiestwo skazy jest zdefiniowane jako liczba czynnikw [11], ktre s dokadnie podane w wielu ksikach dotyczcych testowania. Przy okazji zgadywanie bdw (ISEB) czy znajdowanie skaz (ISTQB) to wanie to: estymacja prawdopodobiestwa wystpienia skazy [8]. To, co w ISTQB nazywa si technik opart na dowiadczeniu mogoby oznacza uycie caego powyszego drzewa: estymacja wszystkich wartoci i siy ich wzajemnych zalenoci. Z niewiadomego powodu, ISTQB wybiera tylko jeden li[11] z caego drzewa i nazywa go testowaniem opartym na dowiadczeniu! Nie mog si tu powstrzyma od pewnej gry sw: ISEBowe zgadywanie bdw zgodnie z definicj bdu z BS 7925 1, bdzie tylko czci szukania skaz. Na podobnej zasadzie, jak zgadywanie, czy wszystko jest w porzdku w maestwie Anki (jeli nie, to wiksze jest prawdopodobiestwo popenienia przez ni bdu). Rzumy jeszcze okiem na fragment drzewa o ktrym dotd nie wspomniaem: by wyliczy prawdopodobiestwo uycia [7] musisz mie jaki rodzaj - wymylony lub oparty na dowiadczeniu modelu uycia dla tej maej funkcji, dla ktrej obliczasz wano wystpienia awarii. Uwaga: powyszy rysunek (ktry powinien by uszczegowiony na najniszym poziomie) jest tylko podstaw do omawiania zasad nadawania przypadkom testowym ich priorytetw. Dalsze omawianie tego problemu , tak powszechne do tej pory, nie jest wicej potrzebne. Wystarczy jak Twoi dostawcy kupi sobie narzdzie do sieci bayesowskich BBN i rozpoczn zbieranie danych! Uyj Googlea jeli nie wiesz co to BBN (Bayesian Belief Net). Peny obraz Rozwizanie podane powyej ma tylko jeden may haczyk: powinno by uywane do wyboru setki lub tysica tych najbardziej istotnych z 101000 teoretycznie moliwych przypadkw testowych. Jedno drzewo z rys. 1 dla kadego z nich, szybkie podstawienie, i ju jestemy gotowi . Dlatego tez potrzebujemy dodatkowych metod do wyboru przypadkw testowych. Nagle nasze wspaniae drzewo z wszechmocnego i ostatecznego narzdzia do wyboru przypadkw testowych jest ograniczane z powodu czystych operacji na liczbach do kocowego narzdzia przy bardzo ograniczonym zakresu, do ostatecznego wyboru przypadkw testowych z ju wybranych innymi sposobami. Jakimi innymi sposobami? Tak naprawd s dwa podejcia: intuicyjne i systematyczne. Z jakich powodw, zarwno ISEB jak i ISTQB opisuja tylko techniki systematyczne, kierujc techniki intuicyjne w zapomnienie (majc w pogardzie fakt, e 70 % tworzonych na wiecie przypadkw testowych jest tworzonych w sposb intuicyjny) lub redukujc je do drobnej czstki zwanej Strona 12 z 39
  • 13. TESTER.PL zgadywaniem bdw lubtechnik oparta na dowiadczeniu a oznaczajc ustalanie prawdopodobiestwa skazy, co jest zdecydowanie nieadekwatne. Dla obu tych podej: intuicyjnego i systematycznego, s dwie podstawowe filozofie projektowania przypadkw testowych: biao skrzynkowa i czarno skrzynkowa. Podejcie czarno biae podejcie ma sens zarwno do intuicyjnego jak i systematycznego podejcia, w przeciwiestwie do wraenia, jakie mona odnie z konspektw ISEB/ISTQB gdzie ten podzia istnieje tylko do technik systematycznych. Naley tu zauway, ze biao czarny podzia nie jest tak naprawd dwuwartociow skala dyskretna, jak to jest czsto 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 czowiek) do 100 % bieli (projektujc przypadki testowe bierzesz pod uwag poziom bramek elektronicznych) poprzez rne odcienie szaroci. Prawidowa (lekko uproszczona) tabela przedstawiajca podejcie do testw / ich filozofi jest przedstawiona na rys. 2 Systematyczne Czarno skrzynkowe Biao skrzynkowe Systematyczne czarno skrzynkowe Systematyczne biao skrzynkowe Rysunek 2. Intuicyjne Intuicyjne czarno skrzynkowe Intuicyjne biao skrzynkowe To jeszcze nie jest koniec. W przeciwiestwie (znowu) do tego, co jest w konspektach. Nie istnieje konceptualny wwz rozdzielajcy testy statyczne i dynamiczne. Nazwanie przegldem techniki statycznej to to samo co nazwanie wykonaniem testw techniki dynamicznej. Bez wtpienia, projektowanie przypadkw testowych jest potrzebne take w testach statycznych, aczkolwiek wystpuje rnica w tym, co tworzy test. W testach statycznych, tak jak i w dynamicznych, najpierw musisz przej przez projektowanie testw np. zdecydowa w istotnych szczegach co przeglda i jak przed wykonaniem przegldu. Std, kocowy, peny i pozbawiony sztucznych ogranicze zbir klas do projektowania przypadkw testowych jest trzy wymiarowy, skad si z omiu elementw, jak pokazano na rys. 3 Strona 13 z 39
  • 14. 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. Naley zauway, e okrelenie techniki testowe nie byo jeszcze nawet wypowiedziane, poniewa podstawow spraw s klasy projektowania przypadkw testowych, ktrych jest w przyblieniu 8 ( w przyblieniu, bo jak ju wspomniano, mamy wicej ni dwie wartoci na czarno biaej skali) Powd nacisku na techniki testowe w konspektach ISEB/ISTQB jest oczywicie dydaktyczny: podstawowym celem podstawowego kursu jest nauczenie testerw technik projektowania testw, ktre bd oni mogli stosowa w swojej podstawowej pracy, tzn. w testowaniu dynamicznym. Nie ma jednak potrzeby budowania caej faszywej konceptualnej struktury by osign ten praktyczny cel. Praktyk i zdrowy rozsdek oferuj alternatyw do ... ciko powiedzie do czego, poniewa techniki intuicyjne, z ktrymi tester pracuje na co dzie, s zupenie lekcewaone. Mona sprbowa zgadn, jakie racje si za tym kryj: wszystkie projekty s testowane intuicyjnie, ale pewne uycie technik systematycznych bardzo by si przydao w wielu z nich. Oczywicie, ta racjonalno jest podejrzana: nie ma potrzeby budowy nieprawdziwego modelu, tylko po to by zapewni szerokie stosowanie systematycznych technik testowych. Wreszcie, testy intuicyjne take potrzebuj ulepszania, wic dlaczego w peni je zaniedbywa? Wreszcie: przykad Przyjrzyjmy si, jak model opisany na rys. 3 sprawdza si dla rzeczywistych technik projektowania testw. Rozpatrzmy trzy takie techniki: (1) testowanie metod zmiany stanw, (2) testowanie w oparciu o wiedze o rozkadzie bdw w podobnym systemie oraz (3) testowanie w oparciu o instrukcj lub inne pokrycie kodu. Strona 14 z 39
  • 15. TESTER.PL Zmiana stany dynamiczne systematyczne czarno skrzynkowe dynamiczne systematyczne biao skrzynkowe dynamiczne intuicyjne czarno skrzynkowe dynamiczne intuicyjne biao skrzynkowe statyczne systematyczne czarno skrzynkowe statyczne systematyczne biao skrzynkowe Dowiadczenie Najczciej stosowane [nie stosuje si] Np. Testowanie zachowania obiektu w pewnej iloci jego stanw [nie stosuje si] [nie stosuje si] [nie stosuje si] Podobny raport okaza si by niepotrzebny w przeszoci Zajo nam 3 dni na szukanie bdu w podobnym algorytmie sortujcym Zaprojektowanie automatu skoczonego do weryfikacji spisanej specyfikacji wymaga [nie stosuje si] Zaprojektowanie automatu skoczonego do weryfikacji [nie stosuje si] statyczne intuicyjne czarno skrzynkowe [nie stosuje si] statyczne intuicyjne biao skrzynkowe [nie stosuje si] W tej dziedzinie wymagania uytkownika byy ostatnio bardzo oglnikowe Ten facet uywa skokw zamiast waciwego wywoania funkcji! Strona 15 z 39 Pokrycie kodu Sprawdzenie, czy wszystkie metody s uywane (ale nie cay kod w tych metodach). OK. to jest szare, nie cakiem czarne Najczciej stosowane [nie stosuje si] [nie stosuje si] Inspekcja kodu by upewni si, e przygotowywane rodowisko testowe zapewni wywoanie wszystkich stanw; to znowu jest szare, nie cakiem czarne Inspekcja kodu by zmierzy moliwe pokrycie ciko wykonywalnych fragmentw kodu [nie stosuje si] [nie stosuje si]
  • 16. TESTER.PL To dziaa. I jestemy dumni z tego maego odkrycia, mimo e jest zupenie oczywiste (jakkolwiek nieco obce dla konspektw ISEB/ISTQB); oczywicie to nie s techniki czarne ani techniki biae, ale s techniki systematyczne lub intuicyjne. Technika nie moe by w tym samym momencie nie systematyczna i systematyczna. I na kocu miejmy nadzieje, e ten artyku nie przeszkodzi mojej firmie akredytowa si w przyszoci . Strona 16 z 39
  • 17. TESTER.PL Tekst Sponsorowany Strona 17 z 39
  • 18. TESTER.PL Tekst Sponsorowany Wielu klientw uznaje stworzenie architektury ukierunkowanej na usugi (ang. Service Oriented Architecture, SOA) za jedn z piciu najwaniejszych inwestycji strategicznych. Sposb realizacji tego rodzaju architektury ma znaczcy wpyw na podejmowane decyzje dotyczce zakupu rozwiza technicznych. W zwizku z tym dostawca powinien uczestniczy w rozmowach na ten temat i stara si zdoby zaufanie klienta jako partner oferujcy rozwizania w zakresie nadzoru nad systemami, kontroli jakoci oraz przestrzegania umw dotyczcych poziomu usug, ktre pozwol sprawnie wdroy architektur ukierunkowan na usugi w rodowisku klienta. W ramach architektury SOA aplikacje tworzy si w taki sposb, aby funkcjonalno oprogramowania bya dostpna w postaci wspdzielonych usug wielokrotnego uytku. Kada z tych usug odpowiada stosunkowo autonomicznej funkcji merytorycznej lub technicznej. Najwaniejsze korzyci dla przedsibiorstw, wynikajce z zastosowania architektury ukierunkowanej na usugi to: ograniczenie kosztw integracji infrastruktury informatycznej i szybsze reagowanie na potrzeby; zwikszenie elastycznoci i efektywnoci dziaania w obliczu takich wyzwa, jak fuzje i przejcia, konsolidacja oraz konieczno przestrzegania przepisw i regulacji prawnych; uproszczenie procesu tworzenia, serwisowania i eksploatacji niezawodnych aplikacji oraz obnienie zwizanych z tym kosztw; zapewnienie dziaowi IT elastycznoci pozwalajcej sprosta stale zmieniajcym si potrzebom przedsibiorstwa. Pojcie architektura ukierunkowana na usugi nie jest tylko chwytliwym hasem w oparciu o tego rodzaju architektur dziaaj aplikacje w wielu duych, zoonych przedsibiorstwach. Niektre z nich wdraaj tego rodzaju rozwizania stopniowo, inni natomiast od samego pocztku dokonuj gruntownych zmian. Niemal kady niezalenie od tego, czy wdraa ju tak architektur przyznaje, e w najbliszej przyszoci aplikacje bd rozwija si wanie w tym kierunku. Podstaw dziaania architektury ukierunkowanej na usugi jest wykorzystanie usug. Oprcz typowych trudnoci zwizanych z testowaniem autonomicznych usug (penicych rol swego rodzaju miniaturowych aplikacji), pojawiaj si nowe problemy wynikajce z faktu, e kada usuga jest powizana z innymi usugami, zoonymi aplikacjami oraz systemami stanowicymi podstaw jej dziaania. Jeli zachodzi potrzeba zmiany danej usugi, zmiana ta musi zosta przetestowana przez wszystkich uytkownikw tej usugi. Dlatego w przypadku architektury ukierunkowanej na usugi proces testowania jest jeszcze bardziej zoony ni w tradycyjnych rodowiskach aplikacyjnych, co stwarza ogromne moliwoci dla rozwiza w zakresie kontroli jakoci i testowania wydajnoci. Strona 18 z 39
  • 19. TESTER.PL Ramy dziaania architektury ukierunkowanej na usugi wyznaczaj umowy dotyczce poziomu usug (ang. service level agreement, SLA). W odniesieniu do kadej usugi wykorzystywanej przez aplikacje dzia IT musi uzgodni i okreli odpowiedni poziom jej realizacji. Ponadto poziomy usug wymagaj staego monitorowania i raportowania jest to warunkiem szybkiego i sprawnego korygowania wszelkich ewentualnych niedocigni w zakresie wydajnoci i dostpnoci. Klienci korzystajcy z architektury ukierunkowanej na usugi bd take potrzebowali narzdzi umoliwiajcych rozpoznawanie problemw oraz tworzenie raportw na temat przestrzegania umw dotyczcych poziomu usug z dokadnoci do poszczeglnych usug lub warstw infrastruktury. Oprcz tego niezbdne jest monitorowanie prewencyjne, ktre pozwala rozpoznawa zachodzce tendencje oraz porwnywa faktyczn i wymagan jako dziaania. Firma Mercury oferuje trzy kluczowe elementy niezbdne do sukcesu architektury ukierunkowanej na usugi: 1. mechanizmy nadzoru nad systemami umoliwiajce kontrol nad procesem tworzenia regu dziaania architektury ukierunkowanej na usugi oraz stosowania tych regu; 2. mechanizmy kontroli jako i wydajnoci umoliwiajce weryfikowanie funkcjonalnoci i wydajnoci pojedynczych i skoordynowanych usug oraz zoonych aplikacji; 3. mechanizmy zarzdzania umowami dotyczcymi poziomu usug umoliwiajce definiowanie umw dotyczcych poziomu usug oraz pomiar zgodnoci z tymi umowami, raportowanie w tym zakresie (w odniesieniu do usug i zoonych aplikacji). Strona 19 z 39
  • 20. TESTER.PL Doskonalenie procesu testowego za pomoc modeli TMMSW i TPI Joanna Nowakowska Rodan Systems S.A. Dyrektor Dziau Zarzdzania Jakoci SJSI Wiceprezes Joanna Nowakowska jest dyrektorem Dziau Zarzdzania Jakoci w firmie Rodan Systems S.A. W 2005 roku jako pierwsza osoba w Polsce uzyskaa tytu ISTQB Certified Tester, Full Advanced Level. Wspzaoyciel i wiceprezes Stowarzyszenia Jakoci Systemw Informatycznych i Polish Testing Board, czonek German Testing Board. Strona 20 z 39
  • 21. TESTER.PL Doskonalenie procesu testowego za pomoc modeli TMMSW i TPI Joanna Nowakowska Rodan Systems S.A. / SJSI Dyrektor Dziau Zarzdzania Jakoci / Wiceprezes Streszczenie Jako to cige doskonalenie wszystkich procesw Dr W. E. Deming. W popularnych modelach dojrzaoci i standardach (CMM, CMMI, BOOTSTRAP, SPICE, ISO 9001) niestety nie powicono wystarczajcej uwagi kwestii testowania, std w latach 90-tych XX wieku powstao kilka modeli sucych ocenie i usprawnieniu wycznie procesu testowania. Dwa z nich zdecydowanie najwaniejsze zostay omwione w niniejszym artykule. Pierwszym jest Software Testing Maturity Model (TMMSW) z Illinois Institute of Technology, drugim Test Process Improvement (TPI) powstay w IQUIP Informatica B.V. Netherlands (SOGETI). Na kocu artykuu znalazo si rwnie krtkie porwnanie 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 wsppracownikw. Model TMMSW postrzegany jest jako odpowiednik, bd nawet rozwinicie jednego z najbardziej popularnych modeli dojrzaoci organizacyjnej Capability Maturity Model (CMM) i jego kolejnych wersji. TMMSW le zaoenia historycznego modelu ewolucyjnego (ang. historical evolutionary model) sformuowanego przez D.Gelperin i B.Hetzel, w ktrym to wyszczeglniono cztery fazy testowania [1]: faza debugowania (ang. debugging-oriented phase), w ktrej testowanie jest postrzegane jako czynno uatwiajca usuwanie bdw, faza destrukcji (ang. destruction-oriented phase), w ktrej testowanie jest ukierunkowane na znajdowanie bdw w implementacji, faza oceny (ang. evaluation-oriented phase), w ktrej testowanie jest wykonywane we wszystkich etapach wytwarzania, czynnoci testowe s zintegrowane z czynnociami wytwarzania, a samo testowanie jest ukierunkowane na znajdowanie nieprawidowoci w wymaganiach, projekcie i w implementacji, faza prewencji (ang. prevention-oriented phase), w ramach ktrej nacisk pooony zostaje na przegldy, a celem czynnoci testowych jest zapobieganie nieprawidowociom na rnych etapach wytwarzania. U podstaw Zgodnie z historycznym modelem ewolucyjnym, testowanie w kadej organizacji przechodzi przez te cztery wymienione etapy. Oceniajc wybrane cechy procesu Strona 21 z 39
  • 22. TESTER.PL testowego, jestemy w stanie okreli jego poziom dojrzaoci oraz wprowadza stopniowe usprawnienia w tym zakresie. Na TMMSW skadaj si dwa gwnej komponenty, a mianowicie model dojrzaoci i model oceny. Kady z tych modeli zosta opisany pokrtce poniej. Model dojrzaoci Model dojrzaoci TMMSW definiuje pi poziomw dojrzaoci, a dla kadego poziomu dodatkowo rwnie: cele (ang. maturity goals), pod-cele (ang. maturity subgoals) cele czstkowe, uatwiajce osiganie celw gwnych, oraz czynnoci, zadania i odpowiedzialnoci (tak zwane ATRs od: activities, tasks & responsibilities), podzielone pomidzy trzy perspektywy (tzw. critical views), czyli trzech kluczowych uczestnikw procesu testowego (menaderw, programistw/testerw oraz uytkownikw/klientw). Struktur modelu ilustruje Rysunek 1, poszczeglne poziomy dojrzaoci Rysunek 2. Wszystkie poziomy (ang. levels) s powizane z poziomami w modelu CMM, kady poziom okrela stopie dojrzaoci procesu testowego i jego waciwoci. Rysunek 1 Struktura modelu dojrzaoci TMM Poziom 1 (Initial). Testowanie wykonywane jest w sposb chaotyczny, po fazie kodowanie, i jest ukierunkowane na potwierdzenie, e testowany system w ogle dziaa. Na tym poziomie nie wyrniamy ustrukturalizowanego procesu testowego, niezalenego zespou testowego, nie s wykorzystywane rwnie systematyczne techniki projektowania przypadkw testowych, a samo testowanie nie jest wykonywane w sposb automatyczny. Mona by Strona 22 z 39
  • 23. TESTER.PL stwierdzi, e kada organizacja posiada dojrzao okrelan przez poziom 1 za darmo. Poziom 2 (Phase Definition). Na tym poziomie rozrniamy pierwsze cele, zaczynamy rozrnia pomidzy testowaniem a debugowaniem a take definiujemy osobne cele dla tych obu czynnoci. Posiadanie procesu testowego na poziomie 2 oznacza, e wyrniona zostaa czynno planowania testw, w ramach ktrej okrelony zosta cel testowania, wykonana analiza ryzyka, zastosowano podstawowe systematyczne techniki projektowania przypadkw testowych oraz proste narzdzia automatyzujce testowanie. Poziom 3 (Integration). Testowanie na tym poziomie nie jest jedynie czynnoci uatwiajc lokalizowanie bdw implementacyjnych czy sprawdzenie, e oprogramowanie w ogle dziaa. Na poziomie 3 testowanie zaczyna by ukierunkowane na znajdowanie bdw w wymaganiach, w projekcie i w kodzie, std czynnoci testowe s zintegrowane z czynnociami wytwrczymi w caym cyklu ycia oprogramowania. Dodatkowo tworzona jest organizacja testowa, dla ktrej planowane s szkolenia merytoryczne z zakresu testowania, ktra zaczyna wykonywa rwnie testy negatywne (ang. negative/robustness tests) i monitoruje proces testowy. Poziom 4 (Management & Measurement). Testowanie postrzegane jest jako mierzalny proces wzbogacony o rozwinity program przegldowy oraz miar. Poziom 5 (Optimization/Defect prevention & quality control). Najwyszy poziom dojrzaoci procesu testowego, w ramach ktrego proces jest kontrolowany, zarzdzany i oceniany na kadym kroku pod wzgldem skutecznoci, kosztw i moliwoci optymalizacji. Przykad Chcc lepiej wyobrazi sobie, czym s cele, pod-cele i ATRs, przyjrzyjmy si drugiemu poziomowi dojrzaoci modelu TMMSW: Aby zaklasyfikowa proces testowy na poziom 2 (Phase Definition) wszystkie cele dla tego poziomu powinny by osignite. Dla poziomu 2 zdefiniowano nastpujce trzy cele gwne: Develop Testing & Debugging Goals and Policies. Initiate a Test Planning Process. Institutionalize Basic Testing Techniques and Methods. Przyjrzyjmy si pod-celom dla drugiego celu gwnego 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 przekada na czynnoci, zadania i odpowiedzialnoci dla wyodrbnionych trzech perspektyw? Dla menaderw: Ensure that test planning policy statements are distributed and approved. Strona 23 z 39
  • 24. TESTER.PL (...). Dla programistw / testerw: Assist project (test) manager in determining test goals, test risks and test costs for planning (). (). Dla uytkownikw / klientw: 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 zdolnoci procesu wykorzystuje si kwestionariusze oceny oraz przeprowadza wywiady z pracownikami organizacji. Model oceny TMMSW skada si z nastpujcych elementw: procedura oceny (ang. Assessment Procedure) wytyczne wykorzystywane przez zesp dokonujcy oceny, ktre powinny pomc im w zbieraniu, analizie i ocenie danych, a w konsekwencji uatwia okrelenie poziomu dojrzaoci danego procesu testowego; kwestionariusz oceny (ang. Assessment Questionnaire) zestaw pyta odpowiadajcych celom, ktre w powizaniu z informacjami z wywiadw, prezentacji i przegldw odpowiednich dokumentw s podstaw oceny; kryteria wyboru zespou i szkolenia (ang. Assessment Training & Team Selection Criteria) program szkole dla osb zaangaowanych w proces oceny (zaadaptowany ze SPICE). Rysunek 2 Poziomy dojrzaoci z wyszczeglnieniem celw Dla tych, ktrzy chc szybko sprawdzi zdolno procesu testowego w swojej organizacji, Erik van Veenendaal w jednym ze swoich artykuw opublikowa krtki Strona 24 z 39
  • 25. TESTER.PL kwestionariusz tzw. quick scan [2]. Odpowiadajc na zawarte w nim pytania, jestemy w stanie szybko sprawdzi, czy nasz proces testowy jest bardziej czy mniej dojrzay ni ten wymagany dla poziomu 2 (zob. Rysunek 3). Rysunek 3 Quick scan Strona 25 z 39
  • 26. TESTER.PL Test Process Improvement Test Process Improvement (TPI) to model oceny i poprawy procesu testowego, sformuowany w 1997 roku przez Sogeti Nederland B.V. [3], oferujcy rodowisko do identyfikowania sabych i mocnych stron procesu testowego oraz list moliwych do wprowadzenia usprawnie. Model TPI skada si z nastpujcych elementw: model dojrzaoci (ang. Maturity Model); macierz dojrzaoci (ang. Test Maturity Matrix), zawierajca obszary kluczowe dla procesu testowania (ang. Key Areas), poziomy dojrzaoci (ang. Maturity Levels) oraz skala dojrzaoci (ang. maturity scale); punkty kontrolne (ang. Checkpoints); lista usprawnie (ang. Improvement Suggestions). Model dojrzaoci Opisywany tutaj model dojrzaoci skada si z trzech nastpujcych poziomw: Kontrolowany proces testowy (ang. Controlled test process). Czynnoci testowe wykonywane w ramach kontrolowanego procesu testowego uwzgldniane s w harmonogramach projektowych i w budecie. Mimo i wykonywane s wycznie testy wysokiego poziomu (ang. high-level tests), w ramach ktrych przypadki projektowane s w oparciu o systematyczne techniki, wszystkie prace s na bieco kontrolowane i dopasowywane do potrzeb projektu. Monitorowanie procesu testowego polega na zbieraniu miar dotyczcych produktu i raportowaniu postpu prac (kosztw, krokw milowych, liczby zgosze wraz z priorytetami). Na tym poziomie wykorzystywane s rwnie narzdzia wspomagajce proces planowania i kontroli projektu (w tym rwnie projektu testowego). Skuteczny proces testowy (ang. Efficient test process). Na tym poziomie organizacji zostaje narzucone tworzenie strategii nie tylko dla testw wysokiego poziomu, lecz rwnie dla testw niskiego poziomu (ang. low-level tests). Samo testowanie powinno rozpoczyna si ju na etapie definiowania wymaga. Chcc oceni skuteczno procesu testowego naley zbiera informacje z funkcjonowania procesu, a planowanie opiera na danych statystycznych. Dodatkowo na tym poziomie zespoy testowe wykorzystuj w wikszym zakresie narzdzia wspierajce wykonanie i analiz wynikw z testowania, rozpoczyna si rwnie proces zarzdzania testaliami (ang. testware). Optymizowany proces testowy (ang. Optimizing test process), to proces, ktry zainicjowany zostaje ju razem z rozpoczciem projektu wytwrczego, w ktrym istnieje moliwo ledzenia wymaga na oprogramowanie w caym cyklu wytwarzania i odwzorowanie tych wymaga na przypadki testowe a nawet zgoszenia z testw. Na tym poziomie mamy do czynienia z poczon Strona 26 z 39
  • 27. TESTER.PL strategi dla wszystkich poziomw testw i oceny, a zbierane miary odnosz si do caej organizacji i su dziaaniom usprawniajcym proces testowy. Struktura modelu TPI Struktura modelu widoczna jest na rysunku poniej. Rysunek 4 Struktura modelu TPI Obszary kluczowe (ang. Key Areas): T.Koomen i M.Pol autorzy modelu TPI - wyrnili 20 obszarw kluczowych dla sprawnego procesu testowego. Idea stojca za wyszczeglnionymi obszarami jest taka, e kady proces testowy charakteryzuje pewien zestaw atrybutw (obszarw), ktrymi naley zarzdza, ktre naley kontrolowa i sukcesywnie usprawnia, chcc eby cay proces w konsekwencji funkcjonowa bardziej efektywnie. Std do obszarw kluczowych zaliczamy wszystkie, moim zdaniem bardzo wane, aspekty zapewnienia jakoci, takie jak: strategia testowania (ang. test strategy), model cyklu ycia (ang. life-cycle model), czas rozpoczcia testw (ang. moment of involvement), estymacja i planowanie (ang. estimationg & planning), techniki projektowania przypadkw 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), zaangaowanie i motywacja (ang. commitment & motivation), funkcje i odpowiedzialnoci oraz szkolenia (ang. testing functions & training), zakres metodologii (ang. scope of methodology), komunikacja (ang. communication), raportowanie (ang. reporting), zarzdzanie zgoszeniami (ang. defect management), zarzdzanie procesem testowym (ang. test process management), Strona 27 z 39
  • 28. TESTER.PL ocena (ang. evaluation), testowanie niskiego poziomu (ang. low-level testing). W samym modelu kady z obszarw kluczowych zosta oczywicie dodatkowo dokadniej opisany. Taki opis dla dwch wybranych przykadowo obszarw kluczowych strategii testowania oraz czasu rozpoczcia testw ilustruje Rysunek 5. Rysunek 5 Definicje obszarw kluczowych TPI Poziomy dojrzaoci (ang. Maturity Levels): Dla obszarw kluczowych wyrniamy nastpujce poziomy dojrzaoci: 0 (proces nie spenia wszystkich wymaga dla poziomu A), i od A do D. Nie kady obszar kluczowy musi mie dokadnie 4 poziomy dojrzaoci (zwykle obszar kluczowy ma przyporzdkowane 3 poziomy). Na Rysunek 6 widoczne s pewne wymagania dla poszczeglnych poziomw dojrzaoci w obszarze strategii testowania i czasu rozpoczcia testowania. Rysunek 6 Definicje poziomw dojrzaoci Punkty kontrolne (ang. Checkpoints): Model TPI dostarcza prostego narzdzia pomiarowego. Wymagania na kady poziom dojrzaoci danego obszaru kluczowego zdefiniowane s w formie punktw kontrolnych (zob. Rysunek 7 Przykad punktw kontrolnych (dla obszaru strategia testowania) pyta, na ktre naley udzieli twierdzcej odpowiedzi, jeeli chcemy zaklasyfikowa nasz proces testowy na dany poziom. Punkty kontrolne si kumuluj, Strona 28 z 39
  • 29. TESTER.PL tzn. chcc zaklasyfikowa proces testowy do poziomu B w ramach danego obszaru kluczowego, nie tylko wszystkie wymagania na ten poziom musz by spenione, lecz rwnie wszystkie wymagania na poziom A. Rysunek 7 Przykad punktw kontrolnych (dla obszaru strategia testowania) Usprawnienia (ang. Improvement Suggestions): Autorzy wraz z modelem dostarczaj list podpowiedzi usprawnie, ktre, mimo i nie s wymagane, uatwiaj osiganie wyszych poziomw dojrzaoci procesu testowego. Macierz dojrzaoci (ang. Test Maturity Matrix) Ze wzgldu na fakt, e nie wszystkie obszary kluczowe s jednakowo istotne, oraz dlatego, e istniej zalenoci pomidzy poszczeglnymi obszarami, autorzy modelu stworzyli list zalenoci midzyobszarowych oraz tzw. macierz dojrzaoci. Na Rysunek 8 przedstawiony zosta przykad zalenoci pomidzy obszarami kluczowymi modelu. Std, chcc zaklasyfikowa proces testowy na poziom A w obszarze strategii testowania naley mie proces testowy zaklasyfikowany na poziomie A dla 5. obszaru kluczowego, ktrym jest obszar techniki projektowania przypadkw testowych (5a) oraz na poziomie A dla 11. obszaru zaangaowania 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 (...) (...) (...) przypadkw testowych Zaangaowanie i Przydzielenie budetu i czasu (...) (...) (...) motywacja Rysunek 8 Przykad zalenoci pomidzy obszarami kluczowymi Wszystkie tego typu zalenoci widoczne s w macierzy dojrzaoci (zob. Rysunek 9). W lewej kolumnie macierzy znajduje si lista obszarw kluczowych, w nagwkach tzw. skala dojrzaoci. Z zaoenia, miejsce umiejscowienia liter okrelajcych dojrzao obszarw kluczowych ujawniaj wag danego poziomu i obszaru Strona 29 z 39
  • 30. TESTER.PL (podstawowe i najwaniejsze obszary znajduj si bardziej na lewo w macierzy wymagania na te obszary powinny by spenione w pierwszej kolejnoci). Jak wypeniona macierz przenosi si na jeden z trzech poziomw dojrzaoci samego procesu testowego? Autorzy modelu przyjli zaoenie, e jeeli proces testowy spenia wymagania zawarte na skali od 1 do 5 to jest to kontrolowany proces testowy, od 6 do 10 skuteczny proces testowy, powyej 10 optymizowany (zob. Rysunek 10). Rysunek 9 Przykad wypenionej macierzy dojrzaoci W przypadku, gdy cho jeden z obszarw zosta zaklasyfikowany do poziomu 0, cay nasz proces ma poziom 0. Strona 30 z 39
  • 31. TESTER.PL Rysunek 10 Macierz dojrzaoci a poziom dojrzaoci procesu testowego Strona 31 z 39
  • 32. TESTER.PL Wsparcie narzdziowe Dodatkowym atutem modelu TPI jest moliwo skorzystania z darmowego narzdzia, ktre w znaczcy sposb uatwia analiz stanu procesu testowego. TPI Scoring Tool [5] zawiera opis wszystkich obszarw kluczowych modelu, punkty kontrolne i list usprawnie (zob. Rysunek 11). Odpowiadajc na pytania zawarte w punktach kontrolnych, tabelka z rezultatami oceny oraz macierz dojrzaoci aktualizowane s w sposb automatyczny (zob. Rysunek 12). Rysunek 11 Tabela wynikw oceny (narzdzie TPI Scoring Tool) Strona 32 z 39
  • 33. TESTER.PL Rysunek 12 Macierz dojrzaoci w narzdziu TPI Scoring Tool Porwnanie modeli Cel modelu Praktycznie oba modele maj podobny cel, ktrym jest identyfikacja sabych i mocnych stron procesu testowego (czyli de facto ocena stanu procesu testowego). Mimo to, mona powiedzie, e model TPI jest bardziej ukierunkowany na wprowadzanie usprawnie, gdy posiada list usprawnie, ktre mog by wykorzystane przez kad organizacj. Struktura TMMSW ma struktur podobn do struktury modelu CMM. TPI nie posiada struktury poziomowej. Zawarto merytoryczna TMMSW nie uwzgldnia nastpujcych obszarw (ktre uwzgldnia TPI): rodowisko testowe, rodowisko biurowe, raportowanie, zarzdzanie zgoszeniami, Strona 33 z 39
  • 34. TESTER.PL zarzdzanie testaliami. Procedura oceny TMMSW posiada kwestionariusz oceny, TPI - punkty kontrolne. Jest wicej punktw kontrolnych ni pyta w kwestionariuszu. TPI nie posiada wytycznych do wyboru zespou kontrolujcego ani zalece szkoleniowych. Formalna certyfikacja (zewntrzna) Nie ma moliwoci uzyskania certyfikatu na posiadanie procesu testowego o danej dojrzaoci, na zgodno z adnym modelem. Dodatkowe porwnanie zawiera Rysunek 13 Porwnanie obu modeli [6]Rysunek 13. Rysunek 13 Porwnanie obu modeli [6] Strona 34 z 39
  • 35. 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 Porwnania: 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
  • 36. TESTER.PL Tekst sponsorowany Strona 36 z 39
  • 37. TESTER.PL Strona 37 z 39
  • 38. TESTER.PL Strona 38 z 39