Od redaktora Jak ten czas leci, zanim się obejrzeliśmy, a tu juŜ 10 – jubileuszowy – numer naszego kwartalnika. Mam nadzieje, ze numer jubileuszowy jest równie ciekawy jak 9 poprzednich. W tym numerze cztery ciekawe artykuły: 1. Joanna Droździel o zarządzaniu zmianą – jest to kontynuacja jej pracy z poprzedniego numeru 2. Moty Aharonovitz o tym jak skutecznie usprawnić testowanie oparte na wymaganiach 3. Mateusz Bukowski i Paweł Paterek o obiektach pozornych, ciekawe rozwiązanie związane z metodologią TDD; autorzy bardzo dokładnie na przykładzie opisują na czym to polega 4. Maciej Dusza o pisaniu dokumentacji – coś czego większość z nas nie lubi, autor pokazuje jak robić to dobrze Zgodnie z rozpoczętym w numerze 8 kwartalnika cyklem zamieszczamy w tym numerze sprawozdanie z konferencji, które odbyły się ostatnio: Łukasz śebrowski był w Düsseldorfie na SQS Software & Systems Quality Conferences i relacjonuje nam to wydarzenie. W czasie tworzenia tego numeru odbyła się IV Konferencja Jakości Systemów Informatycznych. Na gorąco moŜna jedynie powiedziec, ze była bardzo ciekawa – więcej o niej w następnym numerze Testera.PL 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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Od redaktora Jak ten czas leci, zanim się obejrzeliśmy, a tu juŜ 10 – jubileuszowy – numer naszego
kwartalnika. Mam nadzieje, ze numer jubileuszowy jest równie ciekawy jak 9 poprzednich.
W tym numerze cztery ciekawe artykuły:
1. Joanna Droździel o zarządzaniu zmianą – jest to kontynuacja jej pracy
z poprzedniego numeru
2. Moty Aharonovitz o tym jak skutecznie usprawnić testowanie oparte na
wymaganiach
3. Mateusz Bukowski i Paweł Paterek o obiektach pozornych, ciekawe rozwiązanie
związane z metodologią TDD; autorzy bardzo dokładnie na przykładzie opisują na
czym to polega
4. Maciej Dusza o pisaniu dokumentacji – coś czego większość z nas nie lubi, autor pokazuje jak robić to dobrze
Zgodnie z rozpoczętym w numerze 8 kwartalnika cyklem zamieszczamy w tym numerze
sprawozdanie z konferencji, które odbyły się ostatnio: Łukasz śebrowski był w Düsseldorfie na
SQS Software & Systems Quality Conferences i relacjonuje nam to wydarzenie.
W czasie tworzenia tego numeru odbyła się IV Konferencja Jakości Systemów
Informatycznych. Na gorąco moŜna jedynie powiedziec, ze była bardzo ciekawa – więcej o niej
w następnym numerze Testera.PL
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 2 z 63
Zarządzanie problemem i incydentem
Joanna Droździel
Joanna Droździel jest absolwentem Informatyki na
Wydziale Elektrycznym Politechniki Warszawskiej. Obroniła pracę magisterską z zakresu metodyki ITIL. Posiada certyfikat ISEB Foundation.
Od października 2006 roku prowadzi blok wykładów „Zarządzanie usługami IT” na Podyplomowym Studium Prowadzenia Projektów Informatycznych na Politechnice Waszawskiej. Obecnie pracuje w firmie CS Stars na stanowisku starszego analityka do spraw zapewnienia jakości, biorąc udział w projektach dla klientów zagranicznych.
TESTER.PL
Strona 3 z 63
Zarządzanie zmian ą Joanna Droździel
Tak jak Ŝycie społeczne i cywilizacja poddane są nieustannej ewolucji, tak równieŜ i w
działalności firmy zmiany informatyczne są konieczne. To czy siły wywołujące zmiany mają
charakter ekonomiczny, techniczny, społeczny czy polityczny nie ma szczególnego znaczenia.
Zmiany wdraŜane w sektorze informatycznym dotyczą przede wszystkim infrastruktury oraz
oprogramowania, powstają najczęściej w trakcie standaryzacji działań produkcyjnych lub teŜ
wynikają z potrzeby zapanowania nad zgłoszeniami uŜytkowników. JeŜeli jeszcze klika lat temu
pomysł wykorzystania informatyki w projektach elektronicznej administracji spotykał się z
ogólnym niedowierzaniem, to teraz pomysł ten juŜ nikogo nie dziwi. Wręcz przeciwnie, uwaŜa
się Ŝe wykorzystanie informatyki w administracji przedsiębiorstwa nie będzie efektywne, jeŜeli w
projektach elektronicznej administracji nie będą uwzględnione zmiany, jakim we współczesnym
świecie ulega firma.
Proces zarządzania zmianą
Bez efektywnego procesu zarządzania zmianą dalszy rozwój cywilizacyjny byłby
niemoŜliwy. Dlatego jeŜeli w jakiejś dziedzinie Ŝycia nie spotkaliśmy się z koniecznością
wprowadzania zmian, to wcześniej czy później będziemy do tego zmuszeni. W wyniku
zachodzących na świecie przemian: społecznych, cywilizacyjnych, ekonomicznych czy
kulturowych zmieniają się takŜe obszary podległe działalności organizacji. Proces zarządzania
zmianami w sektorze usług informatycznych jest nieodłącznym elementem działalności
biznesowej przedsiębiorstwa. Gdy proces ten przebiega źle, wówczas oddziałuje to negatywnie
równieŜ na stronę biznesową. Bez efektywnie przeprowadzonych zmian informatycznych
zakłócona zostaje działalność biznesowa firmy. MenedŜer działu informatycznego często
twierdzi, Ŝe kierowany przez niego zespół jest przygotowany na realizację procesu zmian. Z
badań wynika, Ŝe nierzadko jest inaczej. MenedŜerowie radzą sobie z oceną i monitorowaniem
efektów wprowadzonych zmian. Gorzej jest jednak z wywołaniem kryzysu, czyli stworzeniem
impulsu do zmiany, czy teŜ z wprowadzeniem nowego porządku rzeczy, gdy sytuacja tego
wymaga.
TESTER.PL
Strona 4 z 63
KaŜda zmiana pociąga za sobą lawinę kolejnych. Dlatego ci, którzy ponieśli straty
finansowe, wiedzą jak waŜny jest dobrze przeprowadzony proces zarządzania zmianą. PomoŜe
on zbadać ryzyko wprowadzenia zmiany, oszacować ilość odpowiednich zasobów oraz
sprawdzić, czy czas wprowadzenia zmiany został właściwie określony. Mając na celu przede
wszystkim minimalizację liczby incydentów i problemów wynikających ze źle wprowadzonych
zmian. W pracach nad pozostałymi procesami menedŜerowie mogli skorzystać z pomocy
konsultantów, w przypadku procesu zarządzania zmianą pomoc ta moŜe okazać się
bezwartościowa. Wynika to z faktu iŜ tylko osoba przebywająca w danej organizacji jest w stanie
poznać realia rządzące firmą i dzięki temu określić kierunek koniecznych zmian.
Poznając procesy metodyki ITIL zauwaŜamy, iŜ kolejny proces zaleŜy od poprzedniego i
wpływa na następny, podobnie jest równieŜ z procesem zarządzania zmianą, który w większym
lub mniejszym stopniu korzysta, oddziałuje, wpływa na pozostałe procesy. Konieczność
zwiększenia pojemności usług lub teŜ utrzymanie jej na dotychczasowym poziomie (ale przy
większej liczbie uŜytkowników, bądź ilości danych oraz liczby transakcji), moŜe wymusić
konieczność wprowadzenia zmian.
Procesy te nie będą działać efektywnie bez poprawnie przeprowadzonego procesu
zarządzania zmianą, który w duŜej mierze zaleŜy od procesów zarządzania problemem oraz
incydentem. Wynika to z ilości zmian zgłoszonych przez uŜytkowników na skutek wykrytych
awarii, jak równieŜ powstałych na skutek działań proaktywnych w procesach zarządzania
incydentem i problemem.
Podstawą procesu zarządzania zmianą jest prośba o zmianę (RfC), od której rozpoczyna
się proces. Kluczem do efektywnego wdroŜenia zmiany jest odpowiednio wypełniony formularz
w wersji papierowej bądź elektronicznej. Wersja papierowa bardzo szybko okazała się
niepraktyczna, zwłaszcza w firmach, gdzie liczba zgłaszanych zmian jest bardzo duŜa.
Poszczególne etapy procesu odbywają się drogą elektroniczną za pomocą odpowiedniej
aplikacji.
Przystępując do procesu zarządzania zmianą warto tuŜ przed wdroŜeniem
zaplanowanego modelu postępowania zabezpieczyć aktualny stan aplikacji, sprzętu czy
konfiguracji. Z kaŜdej nieudanej zmiany moŜna się wycofać, ale tylko wtedy, gdy dysponujemy
szczegółami sprzed wprowadzenia zmian. Są jednak zmiany, które aby mogły być
zaimplementowane, wymagają jednak wielu konsultacji. NaleŜy wówczas skorzystać z pomocy
organu Rada Doradcza (CAB), w skład której wchodzą nie tylko menedŜer zmiany i
przedstawiciele zarządu, ale równieŜ osoby odpowiedzialne za pozostałe procesy metodyki ITIL.
Rozpoczynając wdroŜenie procesu w firmie warto rozpocząć od niewielkich, lekko
skomplikowanych zmian i dopiero wraz z upływem czasu sięgać po zmiany bardziej złoŜone.
TESTER.PL
Strona 5 z 63
Dzięki takiej postawie, menedŜerowie opanują zasady, jakimi kieruje się proces zarządzania
zmianą na tyle dobrze, by móc go przeprowadzać w sposób mechaniczny. Proces zarządzania
zmianą został przedstawiony na rysunku poniŜej.
Rysunek 1. Proces zarządzania zmianą.
Proces zarządzania zmianą funkcjonuje dzięki osobie odpowiedzialnej za jego poprawne
zaplanowanie oraz wdroŜenie. Tą osobą jest menedŜer zmiany a zarazem właściciel procesu.
MenedŜer zmiany odpowiada za realizację juŜ zaplanowanych zmian, planowanie następnych,
nadzór nad zmianami przeprowadzonymi, a więc generowanie raportów dla strony biznesowej
oraz przedstawienie argumentów potwierdzających potrzebę planowania zmian. Autorzy
metodyki ITIL warunkują sukces we wdroŜeniu metodyki od indywidualnych działań właściciela
procesu. Z reguły ilość pracy przekracza jednak moŜliwości jednej osoby. Dlatego teŜ waŜne jest
aby menedŜer dowolnego procesu zaangaŜował do pracy tyle osób, ile jest w danej chwili
niezbędnych (uwzględniając moŜliwości finansowe przedsiębiorstwa). Z reguły na etapie
planowania menedŜer korzysta z pomocy analityków a potrzebne informacje czerpie z Bazy
Konfiguracji. Natomiast na etapie wdroŜenia zmiany korzysta z pomocy programistów,
administratorów, testerów, a więc osób dostępnych w ramach codziennej działalności
organizacji.
Jednak nie wszystkie zmiany są wynikiem efektywnej pracy menedŜera zmiany, wiele
próśb o zmianę pochodzi bezpośrednio od uŜytkowników. Zaleca się by co pewien czas zapytać
uŜytkowników jakich zmian oczekują. Nawet jeŜeli w danej chwili brakuje moŜliwości ich
TESTER.PL
Strona 6 z 63
realizacji, mogą stać się pomocne na etapie planowania przyszłych zmian. Bardzo wiele zgłoszeń
nie moŜe zostać zrealizowanych ze względu na ograniczenia ustalone w umowie SLA pomiędzy
klientem a dostawcą usług informatycznych. Warto jednak wszystkie zgłoszenia zachowywać
poniewaŜ mogą one stać się źródłem bardzo cennej wiedzy w chwili wykonywania kolejnego
przeglądu umowy. Równie istotne dla procesu zmian są wyniki badań opinii klientów gdyŜ to ich
zdanie w decydującym stopniu powinno wyznaczać kierunek wewnętrznych zmian. Powinny to
być badania systematyczne, a ich rezultaty muszą być moŜliwie szybko uwzględniane w
projektach zmian, tak aby w efekcie przyniosły klientowi satysfakcję wcześniej, niŜ działania
rynkowe konkurencji
Komunikacja oraz informacja
W procesie zarządzania zmianą kluczową rolę odgrywa informacja oraz komunikacja. W
aspekcie związanym z informacją waŜne jest, by osoba odpowiedzialna za realizację procesu
dysponowała gruntownym przygotowaniem merytorycznym. MenedŜer odpowiedzialny za
proces zarządzania zmianą podejmując decyzję musi kierować się regułą: im więcej informacji
tym lepiej. Podobnie jest z drugą istotną kwestią w procesie zarządzania zmianą - komunikacją.
W przypadku niewielkiej zmiany, której wpływu uŜytkownik nie odczuje w swojej codziennej
pracy, aspekt ten nie odgrywa tak waŜnej roli. Nie chodzi bynajmniej o uświadomienie
uŜytkownika, Ŝe zmiana jest planowana, ale równieŜ o czynny jego udział w pracach nad
procesem. Tak naprawdę ludzie znacznie częściej przeciwstawiają się zmianom, niŜ je akceptują.
Dlatego by wywołać reakcje pozytywne, naleŜy zaangaŜować większą grupę pracowników w
proces zarządzania zmianą. Dzięki takiej postawie uzyskamy zrozumienie konieczności
wprowadzania zmian, a co za tym idzie, wiarę w powodzenie całej misji. By uniknąć
negatywnych reakcji uŜytkowników na wprowadzenie zmian bądź ich brak naleŜy poprawić
komunikację na linii uŜytkownik - zarząd. Tylko dzięki pełnej jasności i klarowności działań
uzyskamy lepsze zrozumienie sytuacji. Czasami jednak radykalna zmiana jest łatwiejsza do
zaakceptowania dlatego, Ŝe niewiele elementów nowej strategii przypomina stare procedury.
Istotnym czynnikiem wpływającym na reakcję na zmianę jest czas. Im wolniej przebiegają
zmiany, tym dotkliwiej są one odczuwane przez pracowników.
Ryzyko wprowadzanych zmian
Wielu dyrektorów słysząc słowo „zmiana” reaguje bardzo nieufnie. Zmiana kojarzy im się
ze stresem oraz chaosem w działalności przedsiębiorstwa. Tak być nie musi, wystarczy, Ŝe
więcej uwagi skierują na etap planowania, a nie jak to było zazwyczaj dopiero na etap realizacji.
TESTER.PL
Strona 7 z 63
W praktyce jednak rzadko zdarza się by wprowadzenie zmian było poprzedzone
formalnym procesem. Być moŜe jest to jedną z głównych przyczyn późniejszych negatywnych
skutków innowacji. Aby uniknąć niespodzianek warto przed wdroŜeniem zaplanować krok po
kroku sposób wprowadzania zmiany oraz opracować wszystkie warianty postępowania na
wypadek awarii.
Realizując proces zarządzania zmianą nie sposób nie otrzeć się o ryzyko poraŜki, kaŜda
zmiana moŜe bowiem zakończyć się niepowodzeniem i kaŜdy menedŜer zmiany musi mieć tego
świadomość. Co zrobić by tego uniknąć? Przede wszystkim wyeliminować sytuacje, w których
działamy w pośpiechu i w warunkach improwizacji. Zmiany powinny być planowane z
wyprzedzeniem. MenedŜer zmiany powinien opracować Plan Zmian (FSC) na okres np. jednego
miesiąca, w którym wskaŜe zarówno elementy konfiguracji i infrastruktury, jak i osoby, których
wprowadzane zmiany będą bezpośrednio dotyczyły. Tylko takie postępowanie daje szansę
uniknięcia ewentualnej poraŜki. Celem menedŜera zmian jest zablokowanie zmian
krótkowzrocznych, a więc takich, które w pierwszej chwili wydają się być dobrym rozwiązaniem,
jednak w szerszej perspektywie nie są nim.
Oczywiście takie postępowanie moŜe być skuteczne w przypadku zmian standardowych
czyli takich, które nie są wymuszone krótkim terminem wykonania. Co zrobić w przypadku zmian
pilnych? Jak wówczas uchronić organizację przed ryzykiem poraŜki? Przede wszystkim naleŜy
zachować zimną krew; nawet w krótkim okresie realizacji procesu zarządzania zmianą nie
powinno dojść do pominięcia Ŝadnego z etapów procesu. Pominięcie któregokolwiek z kroków
powoduje automatycznie wzrost ryzyka.
Słownik
CAB - Change Advisory Board
FSC - Forward Schedule of Changes
ITIL - Information Technology Infrastructure Library
SLA - Service Level Agreement
RfC - Request for Change
TESTER.PL
Strona 8 z 63
Jak skutecznie usprawni ć testowanie oparte na wymaganiach (Requirements Based Testing - RBT)
Moty Aharonovitz – Borland Software Corporation
Moty Aharonovitz pracuje jako senior director of Product Strategy w firmie Borland.
Ma ponad 15 lat doświadczenia w pracy nad rozwojem oprogramowania, dzięki czemu aktywnie
wspiera i rozwija wizję Optymalizacji Dostarczania Oprogramowania (SDO) w
przedsiębiorstwach i firmach informatycznych oraz czynnie wspiera rozwiązania z zakresu
Śledzenie zmian odgrywa takŜe istotną rolę w organizacjach wykorzystujących RBT - od
podtrzymywania stałego przepływu informacji o zmianach w stosunku do wymagań,
przypadków testowych i testów jest krytyczne. Te informacje są niezbędne dla prawidłowego
monitorowania postępu i stanu projektu, jak równieŜ do właściwego zarządzania zmianami
wymagań. Bez tej wiedzy trudne jest dokładne określenie, które przypadki testowe i testy
powinny zostać zmodyfikowane w przypadku zmiany w wymaganiach.
Nawet jeśli rozumiemy znaczenie śledzenia zmian, w wielu firmach tworzących oprogramowanie
ta wiedza wciąŜ pozostaje bardzo trudna do uchwycenia we właściwy sposób. Podstawowym
powodem tego jest to, Ŝe większość narzędzi dostępnych obecnie na rynku wymaga od niemal
wszystkich członków zespołów projektowych ręcznego wprowadzania i zarządzania śledzeniem
zmian. Z oczywistych powodów takie podejście jest raczej niemoŜliwe do zaakceptowania. Aby
podołać temu wyzwaniu, naleŜy powaŜnie zastanowić się nad rozwiązaniami umoŜliwiającymi
połączenia pomiędzy produktami poszczególnych faz wytwarzania oprogramowania.
Pierwszy krok do Zarządzania Jakością Cyklu śycia Aplikacji
Stosowanie solidnych praktyk RBT przez organizacje tworzące oprogramowanie bardzo szybko
dostarcza im odpowiednie narzędzia i procesy umoŜliwiające maksymalizację wartości
biznesowej działalności.
TESTER.PL
Strona 18 z 63
Zespoły wdraŜające podejście RBT poprzez fakt, Ŝe robią ten pierwszy krok w celu zwiększenia
jakości tworzonych produktów, stają się tym samym inicjatorami szeregu zmian prowadzących
do implementacji Zarządzania Jakością w Cyklu śycia Aplikacji (Lifecycle Quality Management –
LQM). Poprzez połoŜenie nacisku na zapewnienie jakości na wszystkich etapach wytwarzania
oprogramowania, a nie koncentrowanie się na jakości samego kodu, działania z obszaru LQM
zapewniają firmom podniesienie norm jakości i usług oraz systematyczną redukcję kosztów
związanych z wielokrotnym powtarzaniem tej samej pracy lub prób opanowania złoŜonych
projektów.
Ponadto, działania LQM znacząco przyspieszą ścieŜkę do Optymalizacji Procesu Dostarczania
Oprogramowania (Software Delivery Optimization - SDO), która z kolei pomaga przekształcić
tworzenie i rozwój oprogramowania w zarządzalny proces biznesowy, zapewniając tym samym
zwiększoną kontrolę, przewidywalność oraz wydajność w całym procesie dostarczania
oprogramowania.
TESTER.PL
Strona 19 z 63
Obiekt pozorny. A mo Ŝe coś innego ?
Kierunek rozwoju testów jednostkowych
Mateusz Bukowski i Paweł Paterek
Mateusz Bukowski jest absolwentem Akademii Górniczo Hutniczej w Krakowie, kierunku Informatyka na Wydziale Elektrotechniki, Automatyki, Informatyki i Elektroniki. Obecnie jest pracownikiem Motorola Polska Electronics Sp. z o.o. gdzie zajmuje się testowaniem systemu bezpieczeństwa publicznego TETRA. Jego zainteresowania to Ŝeglarstwo, cross country i rozwiązywanie łamigłówek logicznych.
Paweł Paterek jest absolwentem Wydziału Elektrotechniki, Automatyki, Informatyki i Elektroniki Akademii Górniczo-Hutniczej w Krakowie, kierunek Elektronika i Telekomunikacja. Obecnie jest pracownikiem firmy Motorola Polska Electronics Sp. z o.o., w której zajmuje się testowaniem oprogramowania systemów czasu rzeczywistego oraz systemów wbudowanych dla stacji bazowych w standardzie TETRA. Jego dziedziną zainteresowań jest modelowanie i ocena efektywności pracy sieci komputerowych.
TESTER.PL
Strona 20 z 63
Obiekt pozorny. A mo Ŝe coś innego ?
Kierunek rozwoju testów jednostkowych
Mateusz Bukowski i Paweł Paterek
W dzisiejszym świecie, dostarczenie produktu na czas, nie jest juŜ najwaŜniejszym
celem. DuŜo większe znaczenie, zaczyna odgrywać jakość dostarczanego oprogramowania.
PoniewaŜ testowanie zabiera coraz więcej czasu i wysiłku, niezbędne jest uproszczenie technik
testerskich przy jednoczesnym zachowaniu poziomu znajdowanych defektów. W tym artykule
zapoznamy się z obiektami pozornymi i zaślepkami, które wnoszą nową jakość do testów oraz
pokaŜemy, dlaczego warto korzystać z tych pierwszych.
Zanim przedstawimy nowe sposoby testowania, przypomnijmy, czego dotyczą testy
jednostkowe oraz czym jest programowanie sterowane testami.
Test jednostkowy (Unit test) to procedura mająca na celu walidację poprawności
działania danej jednostki kodu źródłowego. Przez jednostkę kodu źródłowego rozumiemy
najmniejszą i moŜliwą do przetestowania część oprogramowania. W programowaniu obiektowym
(ang. Object Oriented Programming) taką jednostkę kodu stanowi klasa [8]. Testy jednostkowe
odgrywają znaczącą rolę w procesie wytwarzania oprogramowania. UmoŜliwiają one wykrycie
wielu błędów w kodzie juŜ na etapie implementacji lub we wstępnej fazie testów. Pisane są
najczęściej przez te same osoby, które zajmują się tworzeniem danego fragmentu
oprogramowania.
Testy jednostkowe z załoŜenia są proste i szybkie w uruchomieniu. Testują
wyodrębnioną część funkcjonalności w całkowitej izolacji od reszty systemu. Pozwala to na
zautomatyzowanie znaczącej części procesu testowania. Tym samym pozwala to na częste
sprawdzanie czy wprowadzane zmiany w istniejącym kodzie nie powodują błędów.
Testy jednostkowe nie weryfikują wszystkich wymagań funkcjonalnych danego systemu.
Jest to zadanie testów akceptacyjnych wykonywanych przez odbiorcę oprogramowania [4],[10].
Ten rodzaj testów nie ma za zadania sprawdzać interakcji między róŜnymi obiektami, co wynika
wprost z ich definicji. Nie mogą wobec tego zastąpić testów integracyjnych i systemowych w
procesie testowania. Są jednak ich bardzo dobrym uzupełnieniem.
TESTER.PL
Strona 21 z 63
Bardzo często testowane klasy posiadają powiązania do innych klas. Utworzenie
referencji do takich obiektów w środowisku testowym niejednokrotnie jest niemoŜliwe. Jednym z
rozwiązań tego problemu są właśnie obiekty zastępcze powszechnie zwane obiektami pozornymi
(mock). Są to specjalnie przygotowane przez nas implementacje interfejsów mogące zastąpić
problematyczne części kodu oraz ułatwić wykonanie testów.
Ŝaden fragment oprogramowania nie powstanie zanim nie napiszemy do niego odpowiedniego
testu. Pisany kod musi spełnić wymagania testu, a następnie moŜna przeprowadzić na nim
odpowiedni refactoring1, który pozwoli na ustalenie ostatecznego nazewnictwa metod czy
obiektów. Stosowanie tej metodologii ma róŜne zalety, m.in. pisząc pełny zbiór testów przed
napisaniem właściwego kodu piszemy zarazem specyfikację jego działania, po czym sama
walidacja jest juŜ automatyczna. PoniewaŜ przed napisaniem kodu wszystkie testy kończą się
błędem, a w miarę jak nasz kod spełnia coraz więcej wymagań tych błędów jest mniej, to
otrzymujemy tym samym miarę, w jakim stopniu nasz kod realizuje załoŜenia projektowe
[6],[1].
TDD pozwala małymi krokami (poprzez napisanie najmniejszej części kodu, która
powoduje pomyślne przejście testu) na sukcesywne i skuteczne realizowanie danego projektu.
Jednocześnie tak napisany kod jest mniej skomplikowany, dostajemy wysokie pokrycie testami,
a odnajdywanie błędów staje się znacznie prostsze. Jednak, kiedy test dotyczy kodu
odwołującego się do baz danych, zdalnych obiektów lub połączeń sieciowych napisanie go moŜe
być bardzo problematyczne. Chcąc jednak być w zgodzie z koncepcją metodologii TDD i
testować równieŜ takie obiekty, musimy zastąpić obiekty, do których odwołuje się testowany
kod i zaimitować ich obecność w testowanym kodzie. Jednym z moŜliwych sposobów testowania
takiego kodu jest wykorzystanie wspomnianych wyŜej lekkich obiektów pozornych lub duŜo
cięŜszych zaślepek [11],[14].
W naszych rozwaŜaniach będziemy posługiwać się następującym przykładem. Mamy
bazę danych ksiąŜek. KaŜdy element opisany jest następującymi parametrami: autor, tytuł oraz
identyfikator. Ponadto w bazie przechowywana jest równieŜ liczba dostępnych egzemplarzy
kaŜdej ksiąŜki. Z bazą danych moŜemy połączyć się poprzez BookManager’a, z którego korzysta
BookClient.
TESTER.PL
Strona 22 z 63
public interface BookManager { public boolean connect(); public boolean disconnect(); public TreeMap<Book, Integer> bookList(); public boolean order(BookOrder bookOrder) throw s BookNotFoundException, NotEnoughBooksException; } public class BookClient { public static final String CONNECT_ERROR = "Dat abase connect error"; public static final String DISCONNECT_ERROR = " Database disconnect error"; public static final String BOOK_NOT_FOUND_ERROR = "Book not found error"; public static final String NOT_ENOUGH_BOOKS_ERR OR = "Not enough books error"; public static final String AVAILABLE_BOOKS = "A vailable books:"; public static final String ORDERED_BOOKS = "Ord ered books:"; public static final String BOOK_ORDER_FAIL = "B ook order failed error"; private BookManager bookManager; private String message; public BookClient() { bookManager = new DefaultBookManager(); message = ""; } public BookClient(BookManager bookManager) { this.bookManager = bookManager; message = ""; } public String getMessage() {
Implementacja pozostałych klas: Book, BookOrder, DefaultBookManager,
NotEnoughBooksException oraz BookNotFoundException nie jest istotna w naszych
rozwaŜaniach. Niezbędna jest implementacja funkcji equals, hashCode oraz compareTo w klasie
Book, poniewaŜ będziemy uŜywać tych obiektów jako kluczy w TreeMap’ie.
Testowaną klasą jest BookClient. BookManager jest interfejsem, który będą
implementować konkretne obiekty. Domyślnie jest to klasa DefaultBookManager. Na potrzeby
testów dodaliśmy drugi konstruktor, w którym przekazujemy specjalnie spreparowany
BookManager. Inną stosowaną praktyką jest równieŜ korzystanie z metod ‘set’.
Wspomniane wcześniej obiekty pozorne nie są jedyną moŜliwością na zastąpienie
prawdziwych obiektów w obiekcie testowanym. Często teŜ bywają mylone z podobnymi do nich
w zastosowaniu, lecz róŜniącymi się funkcjonalnie obiektami atrapami (ang. dummy
objects), obiektami falsyfikatami (ang. fake objects) oraz zaślepkami (ang. stubs).
Obiekty atrapy przekazywane są do obiektu testowanego, ale nigdzie nie są uŜywane i
zazwyczaj słuŜą jedynie do wypełnienia listy parametrów testowanej metody.
Falsyfikaty (w Ŝargonie informatycznym często nazywane fake’ami) posiadają
namiastkę działającej implementacji, najczęściej stworzoną ręcznie w ramach kodu testów (na
przykład w postaci klasy anonimowej). Implementacja ta jest zazwyczaj skrócona do minimum,
co sprawia, Ŝe nie nadają się one do uŜycia w prawdziwym kodzie. Wadami falsyfikatów są: czas
poświęcony na ich stworzenie, zwiększenie zawartości całego projektu, a takŜe konieczność ich
utrzymywania, w trakcie zmiany interfejsów kodu, z których one korzystają.
Zaślepki mogą być napisane ręcznie lub generowane automatycznie i są najczęściej
stosowane wtedy, gdy kod nie jest znany, nie jest gotowy na etapie testowania danego obiektu
lub, gdy nie ma moŜliwości dostępu do danej części kodu, co czasami znacznie ułatwia i
przyspiesza proces tworzenia oprogramowania [2], [5]. Zaślepki symulują zachowanie
prawdziwego kodu. W naszym przykładzie będzie łączył się z prawdziwą bazą danych. Innym
razem w celu dogłębnego przetestowania z uŜyciem tej techniki musielibyśmy uruchomić serwer
http. Zaślepki są bardzo kosztowne w utrzymaniu. Jeśli są stosowane we wczesnych fazach
testowania mogą później słuŜyć jako zaląŜki dla implementacji prawdziwych klas.
Obiektami pozornymi zajmiemy się dokładniej w dalszej części.
Implementacja BookManager’a moŜe być jednym z powyŜszych typów: falsyfikat,
zaślepka, obiekt pozorny.
Przyjrzyjmy się teraz konkretnym falsyfikatom i zaślepkom oraz odpowiadającym im
testom jednostkowym.
TESTER.PL
Strona 25 z 63
public class FakeBookManager implements BookManager { private TreeMap<Book, Integer> bookList; private int call; public FakeBookManager() { bookList = new TreeMap<Book, Integer>(); bookList.put(new Book(101, "Ernest Hemingwa y", "The Old Man and the Sea"), 3); bookList.put(new Book(102, "Gabriel Garcia Marquez", "One Hundred Years of Solitude"), 5); bookList.put(new Book(103, "Joanne Kathleen Rowling", "Harry Potter and the Deathly Hallows"), 27); call = 0; } public boolean connect() { return true; } public boolean disconnect() { return true; } public TreeMap<Book, Integer> bookList() { return bookList; } public boolean order(BookOrder bookOrder) throw s BookNotFoundException, NotEnoughBooksException { call++; switch (call % 8) { case 0: case 2: case 4: return true; case 1: case 3: case 5: return false; case 6: throw new BookNotFoundException(); case 7: throw new NotEnoughBooksException() ; default: return true; } } }
TESTER.PL
Strona 26 z 63
Jak widzimy nasz falsyfikat ma zaszytą namiastkę logiki. Wiedząc, który raz wywołujemy metodę
order(), moŜemy sprawdzić czy BookClient zachowuje się w poprawny sposób.
public class BookClientTestFakeBookManager extends TestCase { private TreeMap<Book, Integer> bookList; private static final Book QUO_VADIS = new Book( 1001, "Henryk Sienkiewicz", "Quo Vadis"); private static final Book PAN_TADEUSZ = new Boo k(2001, "Adam Mickiewicz", "Pan Tadeusz"); private static final Book CHLOPI = new Book(300 1, "Wladyslaw Reymont", "Chlopi"); @Override protected void setUp() throws Exception { super.setUp(); bookList = new TreeMap<Book, Integer>(); bookList.put(QUO_VADIS, 2); bookList.put(PAN_TADEUSZ, 3); bookList.put(CHLOPI, 5); } public void testOrderGlobal() { BookClient client; FakeBookManager fake; BookOrder bookOrder; String message; fake = new FakeBookManager(); client = new BookClient(fake); bookOrder = new BookOrder(); bookOrder.addBook(CHLOPI); client.orderBooks(bookOrder); message = BookClient.BOOK_ORDER_FAIL; assertEquals(message, client.getMessage()); client.orderBooks(bookOrder); message = BookClient.ORDERED_BOOKS + BookClient.bookListToString(bookOrder.getBookList() ); assertEquals(message, client.getMessage()); client.orderBooks(bookOrder); client.orderBooks(bookOrder); client.orderBooks(bookOrder); client.orderBooks(bookOrder); message = BookClient.BOOK_NOT_FOUND_ERROR; assertEquals(message, client.getMessage()); client.orderBooks(bookOrder); message = BookClient.NOT_ENOUGH_BOOKS_ERROR ; assertEquals(message, client.getMessage());
TESTER.PL
Strona 27 z 63
} }
W przykładzie z zaślepką uŜyliśmy najprostszego rozwiązania. Jako bazy danych uŜyliśmy
Accessa. UŜywanie tej aplikacji nie wymaga obszernej wiedzy z zakresu zarządzania bazami
danych. Access jest łatwy do konfiguracji, prosty w obsłudze i świetnie nadaje się do celów
testowych. Gdybyśmy chcieli symulować serwer http nie musimy mieć postawionego Apache’a.
MoŜemy uŜyć prostego symulatora Jetty, który jest prostą aplikacją javową.
Inne podejście do obiektów pozornych prezentują biblioteki takie jak EasyMock i jMock.
Tworzą one pewnego rodzaju proxy na podstawie przedstawionego interfejsu. Mechanizm
działania takiego testu wygląda w następujący sposób. Najpierw nagrywamy zachowanie
obiektu pozornego:
• jakie metody powinny być uruchomione i ile razy
• jakie wartości powinny być zwrócone lub rzucone wyjątki
Następnie uruchamiamy test i weryfikujemy zachowanie obiektu testowanego.
Na poniŜszych wydrukach kodu, te przedstawione metody są najbardziej ekonomiczne i
przyjazne w uŜyciu przez uŜytkownika.
public class BookClientTestEasyMock extends TestCa se { private TreeMap<Book, Integer> bookList; private static final Book QUO_VADIS = new Book( 1001, "Henryk Sienkiewicz", "Quo Vadis"); private static final Book PAN_TADEUSZ = new Boo k(2001, "Adam Mickiewicz", "Pan Tadeusz"); private static final Book CHLOPI = new Book(300 1, "Wladyslaw Reymont", "Chlopi");
message = BookClient.ORDERED_BOOKS + BookClient.bookListToString(bookOrder.getBookList() ); assertEquals(message, client.getMessage()); client.orderBooks(bookOrder); message = BookClient.ORDERED_BOOKS + BookClient.bookListToString(bookOrder.getBookList() ); assertEquals(message, client.getMessage()); client.orderBooks(bookOrder); message = BookClient.NOT_ENOUGH_BOOKS_ERROR ; assertEquals(message, client.getMessage()); EasyMock.verify(mock); } } public class BookClientTestJMock extends TestCase { private TreeMap<Book, Integer> bookList; private static final Book QUO_VADIS = new Book( 1001, "Henryk Sienkiewicz", "Quo Vadis"); private static final Book PAN_TADEUSZ = new Boo k(2001, "Adam Mickiewicz", "Pan Tadeusz"); private static final Book CHLOPI = new Book(300 1, "Wladyslaw Reymont", "Chlopi"); private BookClient client; private BookManager mock; private Mockery context; @Override protected void setUp() throws Exception { super.setUp(); bookList = new TreeMap<Book, Integer>(); bookList.put(QUO_VADIS, 2); bookList.put(PAN_TADEUSZ, 3); context = new Mockery(); mock = context.mock(BookManager.class); client = new BookClient(mock); } public void testDisconnectFail() { String message; context.checking(new Expectations() {{ one (mock).connect(); will(returnValue( true)); one (mock).connect(); will(returnValue( true));
TESTER.PL
Strona 42 z 63
one (mock).bookList(); will(returnValue (bookList)); one (mock).bookList(); will(returnValue (bookList)); one (mock).disconnect(); will(returnVal ue(true)); one (mock).disconnect(); will(returnVal ue(false)); }}); client.getBookList(); message = BookClient.AVAILABLE_BOOKS + BookClient.bookListToString(bookList); assertEquals(message, client.getMessage()); client.getBookList(); message = BookClient.DISCONNECT_ERROR; assertEquals(message, client.getMessage()); context.assertIsSatisfied(); } public void testForException() { String message; final BookOrder bookOrder; bookOrder = new BookOrder(); bookOrder.addBook(CHLOPI); try { context.checking(new Expectations() {{ one (mock).connect(); will(returnVa lue(true)); one (mock).order(bookOrder); will(t hrowException(new BookNotFoundException())); one (mock).disconnect(); will(retur nValue(true)); }}); } catch (BookNotFoundException e) { } catch (NotEnoughBooksException e) { } client.orderBooks(bookOrder); message = BookClient.BOOK_NOT_FOUND_ERROR; assertEquals(message, client.getMessage()); context.assertIsSatisfied(); } }
Główną zaletą uŜycia techniki obiektów zastępczych w porównaniu z innymi technikami
testowania jest moŜliwość weryfikacji zachowań (zarówno prawidłowości wywołań bądź ich
braku, liczby wywołań jak i wartości zwracanych) obiektu testowanego względem środowiska, w
którym pracuje, a nie jedynie weryfikacji zmiany samych stanów testowanego obiektu [4].
Dzięki jej zastosowaniu staramy się lepiej zrozumieć wymagania, które mają być realizowane
przez nasz kod, a tym samym mamy większą wiedzę na temat tego, co powinniśmy zrobić w
najbliŜszym etapie pracy.
TESTER.PL
Strona 43 z 63
Inne drugoplanowe zalety obiektów pozornych, pozwalające lepiej realizować koncepcję
testów jednostkowych to moŜliwość:
• testowania jeszcze mniejszych części kodu niŜ w przypadku pozostałych technik,
• tworzenia testów niezaleŜnych od siebie nawzajem,
• późniejszego podjęcia decyzji o pewnych fragmentach infrastruktury oraz zmniejszenie
ilości kodu testowego, kosztem nieco większej jego złoŜoności.
Zbyt ścisłe zrównoleglenie z kodem testowanym i potrzeba synchronizacji pomiędzy nimi jest
czasem uznawane za jedna z wad, choć w rzeczywistości zapewnia egzekwowanie
przestrzegania ścisłej zgodności z procesem tworzenia testów jednostkowych. Wadą moŜe być
za to bardzo wąski obszar danego scenariusza testowego z uŜyciem mocków, co w przypadku
nawet drobnych zmian w testowanym kodzie moŜe prowadzić do tego, Ŝe test szybciej stanie się
przestarzały i będzie wymagał od nas poprawek [3].
Obiekty zastępcze pozwalają w znacznym stopniu zautomatyzować tworzenie testów
jednostkowych (zwłaszcza, Ŝe istnieje wiele róŜnych narzędzi do ich tworzenia w wielu językach
programowania), a tym samym zwiększyć wydajność oraz przyspieszyć proces tworzenia testów,
powodując, Ŝe powstające oprogramowanie będzie znacznie lepszej jakości. W szczególności
technika ta pozwoli nam na większe zaufanie, co do jakości indywidualnych części naszego
oprogramowania. Pewnymi niedogodnościami mogą być narzędzia do tworzenia obiektów
pozornych (szczególnie dla rzadziej uŜywanych języków programowania), poniewaŜ są stale
rozwijane ze względu to, Ŝe sama idea powstała w miarę niedawno [2]. Oczywiste jest, Ŝe nie
ma jedynego słusznego sposobu na wykonanie testów, a tym samym nie zawsze istnieje
moŜliwość skorzystania z tej wybranej techniki, ale tych wyjątków w przypadku obiektów
zastępczych jest naprawdę niewiele.
Podsumowując obiekty pozorne są i będą waŜną gałęzią testów. Powinny one w
niedługim czasie znacznie się rozpowszechnić, co w połączeniu z technikami zwinnymi
(agile’owymi) będzie potęŜnym narzędziem w tworzeniu oprogramowania.
TESTER.PL
Strona 44 z 63
Bibliografia: [1] 2006. Techniques for Successful Evolutionary/Agile Database Development, artykuł internetowy, http://www.agiledata.org/essays/tdd.html [2] Bain S. 2006. Mocks, Fakes, and Stubs. Net Objectives, Vol. 3, No. 4, pp. 2-14. [3] Brown M., Tapolcsanyi E. 2003. Mock Object Patterns. Proceedings of The 10th Conference on Pattern Languages of Programs, Sept 8-12, USA. [4] Burke E. M., Coyner B. M. 2003. Java Extreme Programming Cookbook. O'Reilly and Associates. [5] Fowler M. 2007. Mocks Aren't Stubs. Artykuł ze strony internetowej autora, http://martinfowler.com/articles/mocksArentStubs.html. [6] Freeman S., Mackinnon T., Pryce N., Walnes J. 2004. Mock Roles Not Objects. Proceedings of 19th Ann. ACM SIGPLAN Conf. Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '04), ACM Press, pp. 236–246. [7] Freeman S., Pryce N. 2006. Evolving an embedded domain-specific language in Java. Proceedings of the 21th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, OOPSLA 2006, October 22-26, 2006, Portland, Oregon, USA, pp. 855-865. [8] 1999. IEEE Standard for Software Unit Testing: An American National Standard, ANSI/IEEE Std 1008-1987 in IEEE Standards: Software Engineering, Volume Two: Process Standards; The Institute of Electrical and Electronics Engineers, Inc. Software Engineering Technical Committee of the IEEE Computer Society. [9] Mackinnon T., Freeman S., Craig P. 2001. Endo-testing: Unit testing with mock objects. Proceedings of XP2000. Extreme Programming Examined, Addison-Wesley, Boston, MA, pp. 287-301. [10] Massol V., Husted T. 2003. JUnit in Action. Manning Publications. [11] Ryu H.-Y., Sohn B.-K., Park J.-H. 2005. Mock objects framework for TDD in the network environment. Proceedings of the Fourth Annual ACIS International Conference on Computer and Information Science (ICIS’05), pp. 430- 434. [12] Stewart S. 2004. Approaches to Mocking. An article from O'Reilly Network Site, http://www.onjava.com/pub/a/onjava/2004/02/11/mocks.html. [13] Thomas D., Hunt A. 2002. Mock Objects. IEEE Software, Vol. 19, No. 3, pp. 22-24. [14] Wirfs-Brock R.J. 2007. Driven to … Discovering Your Design Values. IEEE Software, Vol. 24, No. 1, pp. 9-11. [15] Keld H. Hansen Using Mock Objects in Java. Artykuł ze strony internetowej, http://javaboutique.internet.com/tutorials/mock_objects/ [16] EasyMock 2.2 Readme, http://www.easymock.org/EasyMock2_2_Documentation.html [17] The jMock Cookbook, http://www.jmock.org/cookbook.html
TESTER.PL
Strona 45 z 63
Dokumentacja – jak to si ę je?
Maciej Dusza
Maciej Dusza jest absolwentem informatyki na wydziale Matematyki,
Informatyki i Mechaniki Uniwersytetu Warszawskiego. W 1993r.
obronił pracę magisterską na temat "Tworzenie programów
współbieŜnych o sterowaniu zadanym strukturami przyczynowo-
skutkowymi". Od tego czasu pracował w kilku firmach w Polsce i USA,
pełniąc funkcje programisty, analityka, projektanta i testera, a przez
ostatnie trzy lata pracował w IMPAQ Sp. z o.o., na stanowisku
Starszego Analityka ds. Zapewnienia Jakości.
Kawaler. Jego hobby to nurkowanie.
TESTER.PL
Strona 46 z 63
Dokumentacja – jak to si ę je?
Maciej Dusza
Pisanie dokumentacji często traktowane jest przez programistów jak cięŜka kara i dopust
boŜy. Z nieco większym zrozumieniem odnoszą się do tego kierownicy projektów, zwłaszcza ci,
którzy kiedyś w połowie projektu stracili pracownika będącego „guru od
systemu/programu/modułu”, i musieli w trybie nagłym wdraŜać do pracy nową osobę,
przegryzając się przez tysiące linii nieudokumentowanego, i często pozbawionego komentarzy
kodu.
Ja osobiście lubię pisać dokumentację. Sprawia mi przyjemność opisywanie
poszczególnych elementów systemu w sposób dokładny, precyzyjny, i zrozumiały dla odbiorcy.
PoniŜej przedstawiam zbiór porad i uwag, które – mam nadzieję – przydadzą się zarówno
osobom piszącym „z potrzeby serca”, jak i tym, dla których jest to przykrym obowiązkiem.
Moje uwagi przedstawiam w postaci krótkich akapitów, odnoszących się do
poszczególnych zagadnień związanych z pisaniem dokumentacji. Opracowałem je na podstawie
własnych doświadczeń, oraz lektury kilku ksiąŜek, których tytuły wymieniam na końcu.
Cechy dobrej dokumentacji:
• jest dokładna i bezbłędna
• jest kompletna
• jest spójna
• jest napisana w sposób klarowny i jednoznaczny
• uŜytkownik moŜe łatwo znaleźć informację, której potrzebuje
• ma porządny, ładny wygląd.
Etapy tworzenia dokumentacji:
• zbieranie informacji na temat opisywanego systemu
• tworzenie projektu dokumentacji
• pisanie dokumentacji
• weryfikacja dokumentacji
• dokonywanie poprawek i uzupełnianie braków.
Dwa ostatnie etapy są zwykle powtarzane kilkakrotnie, aŜ do usunięcia wszystkich usterek. Informacje na temat opisywanego systemu, moŜna zbierać poprzez:
• The User Manual Manual : How to Research, Write, Test, Edit & Produce a Software
Manual, Michael Bremer, “UnTechnical Press”, 1999
TESTER.PL
Strona 57 z 63
SQS Software & Systems Quality Conferences
Düsseldorf 2007
Relacja z konferencji
Łukasz śebrowski
Software Quality Engineer w firmie GTECH EE, od prawie czterech lat zawodowo zajmuje się jakością oprogramowania specjalizując się m.in. w automatyzacji testów. Przewodniczący Komisji Akredytacyjnej SJSI.
TESTER.PL
Strona 58 z 63
SQS Software & Systems Quality Conferences
Düsseldorf 2007
Relacja z konferencji
Łukasz śebrowski
W dniach 25-27 kwietnia 2007 roku Düsseldorf po raz kolejny gościł osoby zajmujące się
jakością oprogramowania. Do Centrum Kongresowego Düsseldorf przybyło 810 uczestników
oraz ponad 40 wystawców. Podobnie jak to miało miejsce podczas ubiegłorocznej edycji
konferencji ICSTEST, zdecydowana większość uczestników pochodziła z Niemiec, lecz wśród
uczestników moŜna było spotkać równieŜ osoby m.in. z Finlandii, Francji, Hiszpanii, Holandii,
Indii, Korei Płd., USA i Wlk. Brytanii. Dwie prezentacje zostały poprowadzone przez naszych
rodaków, natomiast ja reprezentowałem Stowarzyszenie Jakości Systemów Informatycznych,
które jest członkiem wspierającym tej konferencji.
Rysunek 1. WybrzeŜe Renu w Düsseldorfie (fot. autora)
TESTER.PL
Strona 59 z 63
Ilość przybyłych gości, róŜnorodność branŜ, które reprezentowali oraz zagadnienia tam
prezentowane świadczą, Ŝe zagadnienie jakości oprogramowania jest waŜnym i coraz bardziej
docenianym działem inŜynierii oprogramowania.
Konferencja podzielona została na dwa obszary funkcjonalne: Zarządzanie Jakością oraz
Testowanie. W ramach kaŜdego z tych obszarów prowadzone były trzy równoległe bloki
tematyczne (a w przypadku Testowania drugiego i trzeciego dnia cztery równoległe bloki).
Zdecydowana większość prezentacji dotyczących Zarządzania Jakością wygłoszona była w jęz.
niemieckim i dotyczyła takich zagadnień jak: modele procesów zapewnienia jakości,