Tester.pl - Numer 9

TESTER.PL

Od redaktora
Minął kolejny rok, pracowita jesień i połowa bardzo nietypowej, ciepłej „jesieniozimy”.
Wszystko to wpłynęło na opóźnienie prac związanych z tym numerem. A tak naprawdę to dwie
sprawy:
1. Konferencja SJSI – będzie czy nie w tym roku?
2. Rozpoczęcie

przez

Komisję

Egzaminacyjną

SJSI

egzaminów

w

zakresie

„Certyfikowany tester – poziom podstawowy”
Pierwsza sprawa jest – wg stanu na dzień dzisiejszy – ciągle otwarta. Drugą moŜemy
uznać za zakończony sukcesem projekt, trwający prawie cztery lata (od prac związanych z
polską wersja słownika poprzez tłumaczenie sylabusa do prac akredytacyjnych). W następnych
numerach spróbujemy tą sprawą zająć się dokładniej.
Zgodnie z rozpoczętym w poprzednim numerze cyklem zamieszczamy w tym numerze
sprawozdanie z dwóch konferencji, które odbyły się jesienią: CMMI – Dlaczego powinno Cię to

obchodzić - zapraszaliśmy na nią w poprzednim numerze oraz z TESTWAREZ.
W numerze dwie ciekawe pozycje:
Kamila Dec pisze z intrygującym tytułem Wystarczająco dobry jest lepszy o Good
Enough Quality
Joanna Droździel przedstawia typowe sytuacje przy Zarządzaniu incydentem

i problemem
Prócz tego Joanna Nowakowska przedstawia, co działo się na sesji ISTQB w grudniu
w ParyŜu.
Równocześnie zamieszczamy zaproszenia na trzy ciekawe konferencje organizowane
w naszej części Europy:
1. Software & Systems Quality Conferences 2007 w Dusseldorfie (www.sqsconferences.com/de)
2. CONQUEST 2007 w sierpniu w Poczdamie (poniŜej znajdziecie CfP na tą
konferencję)
3. Quality Assurance Management and Technologies QAMT w końcu września w
Kijowie (http://www.qamt.net).
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.
Z ostatniej chwili:

Strona 2 z 37

TESTER.PL
zapraszamy teŜ na Test Management Summit – Warsaw w Warszawie, 25 marca 2007.
Program wygląda bardzo ciekawie. Więcej szczegółów na stronie:
http://www.bbjtest.com/tms/index.html#programme

Strona 3 z 37

TESTER.PL

CONQUEST 2007 – This year with EuroSPI2
September 26–28, 2007, Potsdam, Germany

Call for Papers
The Call for Papers of the CONQUEST and EuroSPI2 are out now. Both take place as partner
conferences from September 26th to 28th, 2007 in Potsdam (near the German capital Berlin).
The main topic of the 10th Conference on Quality Engineering
CONQUEST, is going to be “business processes engineering (BPE)”.
Software Process Improvement and Innovation, EuroSPI2, is going to
Factors with SPI in a Global Competitive Environment - New
Experiences”.

in Software Technology,
The European Systems &
put emphasis on “Success
Research, Methods and

Submission Details
Contributions may cover any quality related aspect of software engineering, but should be
classified by choosing the topics below, which characterize the contribution best:

Strona 4 z 37

TESTER.PL
Business processes engineering (BPE), Model driven engineering (MDE),
Requirements engineering (RE), Verification and validation (V&V), Testing, Metrics
and measurements of system quality and of development processes, Analytical
models of software engineering, Project management (PM), Configuration
management (CM), IT security

Contributions related to industrial experiences are particularly welcomed. Proposals should be
submitted electronically to the Program Committee by March 30, 2007.
Since 1997, CONQUEST has been the platform for software professionals bringing together the
software engineering community to discuss software quality aspects, to see how quality
engineering methods and techniques are used in both industrial and research environments, to
see the latest tools, to share experiences on projects and representative case studies, and to
hear about future directions.

CONQUEST 2007 will feature tutorials and presentations of invited speakers and from members
of the quality and software engineering community. It provides a full picture of software quality
in theory and practice. This year special emphasis is given to business process engineering
(BPE) – how domain specific business processes can be modelled and engineered, how highquality IT infrastructure can be developed for specific business processes, how the business
processes are continuously evolved and improved. Papers on the overall quality of business
processes are appreciated in particular.

Strona 5 z 37

TESTER.PL

Please find more information about both Call for Papers at the following websites:
www.conquest-conference.org and http://2007.eurospi.net/

Strona 6 z 37

TESTER.PL

Wystarczająco dobry jest lepszy
Kamila Dec

WINUEL SA

Absolwentka Wydziału Elektrycznego Politechniki Poznańskiej,
kierunek Informatyka. Obecnie jest pracownikiem firmy WINUEL SA. Jako
analityk – konsultant uczestniczyła w wielu przedsięwzięciach zarządzając
nimi, pełniąc rolę analityka, projektanta, biorąc udział w testowaniu
funkcjonalnym dostarczanych rozwiązań, wdraŜaniu ich oraz szkoleniach
uŜytkowników końcowych. W 2003 roku zdobyła ISEB Software Testing
Foundation Certificate. Interesuje się analizą biznesową, testowaniem oraz
projektowaniem interakcji.

Strona 7 z 37

TESTER.PL

Wystarczająco dobry jest lepszy
Kamila Dec

WINUEL SA

Doskonałości teŜ przyda się umiar.
Tadeusz Kotarbiński

Wprowadzenie
Zainspirowana sformułowaniem „Good Enough Quality”, pochodzącym z Rational Unified
Process (RUP), chciałabym poświęcić kilka chwil zarówno pojęciu „Quality”, jak i „Good Enough”,
z naciskiem na to drugie.
Kiedy nasz produkt jest juŜ „wystarczająco dobry”, aby przekazać go klientowi? I jakie
ryzyko niesie ze sobą zgoda na zastąpienie „po prostu dobry” przez „wystarczająco dobry”?
W praktyce na pierwsze pytanie najczęściej odpowiada za nas rzeczywistość, dyktowana
zobowiązaniami kontraktowymi, terminami i prawami rynku. Wydanie oprogramowania rzadko
kiedy jednak oznacza koniec jego rozwoju (a nie jest tak, jeśli produkt, zamiast do archiwum,
trafia do rąk klienta), więc świadomość ryzyka, która jest pierwszym krokiem do zaradzenia mu,
jest w tej sytuacji praktycznie konieczna.
W literaturze i Internecie moŜna przeczytać o wielu metrykach i bazujących na nich
metodach, które słuŜą róŜnym celom, np. pozwalają oszacować pracochłonność przedsięwzięcia,
a przez to czas i koszt jego realizacji (np. model COCOMO, ang. COnstructive COst MOdel,
metoda punktów funkcyjnych, itd.). W niniejszym artykule chciałabym jednak skupić się tylko na
tych metrykach i metodach1, które prowadzą do osiągnięcia następującego celu – pozwalają
uzyskać odpowiedź na pytanie czy nasz produkt jest „wystarczająco dobry”, a więc na
metrykach jakości oprogramowania i metodach szacowania liczby ukrytych błędów. NaleŜy
zwrócić uwagę, Ŝe na tę odpowiedź składają się dwa elementy:
ocena jakości procesu testowania – poniewaŜ to proces testowania dostarcza
nam danych do oceny jakości oprogramowania, musimy mieć pewność, Ŝe dane
te są wiarygodne, a proces skuteczny;

1

Muszę tu jednocześnie zaznaczyć, Ŝe są to tylko wybrane metryki i metody.

Strona 8 z 37

TESTER.PL
ocena jakości produktu, jakim jest oprogramowanie (na podstawie wiarygodnych
wyników dostarczonych przez proces testowania).

Do doskonałości brakowało jej tego, Ŝe nie miała wad.
Karl Klaus

W poszukiwaniu jakości
Według autorów [2] pojęcie „jakość” jest synonimem relacji pomiędzy człowiekiem
a rzeczą. Nawet, jeśli produkt pozostaje niezmienny, ludzie i otoczenie się zmieniają, zmienia się
więc postrzeganie jakości. Dodatkowo sprawę komplikuje fakt, Ŝe definicja jakości zaleŜy
w duŜym stopniu od dziedziny problemu; co innego oznacza to pojęcie dla NASA, a zupełnie co
innego oznacza ono w kontekście oprogramowania do zastosowań medycznych, gier
komputerowych czy oprogramowania sklepu internetowego.
Podobno pojęcie „jakość” po raz pierwszy zdefiniował Platon jako „pewien stopień
doskonałości”. I ta definicja jest chyba najlepsza na potrzeby niniejszego artykułu.
Encyklopedia Wikipedia podaje równieŜ inną ciekawą definicję:
„Właściwość

jednostki

odnosząca

się

do

jej

zdolności

zaspokojenia

wymagań

jakościowych”, przy czym przez „wymagania jakościowe” rozumiem tu:
Funkcjonalność – zdolność systemu (przy załoŜonych warunkach uŜytkowania) do
realizacji funkcji, które odpowiadają stwierdzonym i przewidywanym potrzebom
uŜytkownika.
Niezawodność – zdolność systemu (przy załoŜonych warunkach uŜytkowania) do
utrzymania określonego poziomu bezawaryjności (odporność systemu na awarie).
Efektywność – zdolność systemu (przy załoŜonych warunkach uŜytkowania) do
osiągania efektów odpowiednich do stopnia zuŜycia zasobów.
UŜyteczność – łatwość zrozumienia, nauki i uŜytkowania systemu oraz
zapewnienie satysfakcji uŜytkownika (przy załoŜonych warunkach uŜytkowania).
Przenośność – zdolność systemu do przenoszenia pomiędzy środowiskami.
Pielęgnowalność – zdolność systemu do modyfikacji.
Definicja jakości według normy ISO 9000 brzmi następująco:
„Ogół cech i właściwości wyrobu lub usługi, które decydują o zdolności wyrobu lub usługi
do zaspokojenia stwierdzonych lub przewidywanych potrzeb uŜytkownika produktu”.
Przytaczam ją tutaj, ze względu na pewien dodatkowy aspekt, nie uwzględniony
w pozostałych definicjach: „zdolność do zaspokojenia przewidywanych potrzeb”. Wrócę do tego
problemu w dalszej części artykułu.

Strona 9 z 37

TESTER.PL

Doskonałość absolutna, w czymkolwiek by się przejawiała, jest symptomem śmierci.
Antoine de Saint-Exupery

Produkt „wystarczająco dobry”
PoniŜej omówiłam wybrane metryki jakości oprogramowania, biorąc pod uwagę zarówno
aspekt jakości procesu testowania produktu, jak i jakość samego produktu. Co prawda decyzja
dotycząca tego czy produkt jest „wystarczająco dobry”, a więc czy moŜna juŜ zakończyć
testowanie i przekazać go klientowi, jest podejmowana na podstawie róŜnych kryteriów
(i w dodatku z róŜną wagą dla kaŜdego z nich), mimo to przy kaŜdej metryce pokusiłam się
o określenie jej potencjalnego wpływu na tę decyzję.

Jakość procesu testowania
Pokrycie wymagań
Metryka

pokrycia

wymagań

pozwala

stwierdzić

jaka

część

wymagań

została

przetestowana lub przeszła testy z wynikiem pozytywnym. WyraŜona jest następującym
wzorem:
Pokrycie wymagań = Liczba wymagań (P, I, W, S) / Liczba wymagań (A, T)
Metrykę tę moŜna wykorzystywać na róŜnych etapach procesu testowania, do oceny
pokrycia wymagań przez planowane (P), zaimplementowane (I) lub wykonane (W) zadania
testowe. Badając ocenę jakości produktu moŜna równieŜ w oparciu o tę metrykę szacować
odsetek wymagań, które przeszły testy z wynikiem pozytywnym (S), przy czym liczbę tych
wymagań moŜna zarówno odnosić do liczby wszystkich wymagań (A), jak i do liczby wymagań
przetestowanych (T).
W naszym przypadku (do oceny jakości procesu testowania) metryka pokrycia wymagań
jest interesująca jako współczynnik mówiący o tym, ile wymagań zostało faktycznie
przetestowanych, czyli:
Pokrycie wymagań = Liczba wymagań przetestowanych / Liczba wszystkich wymagań
Jak wspomniałam wcześniej, norma ISO mówi o zdolności wyrobu lub usługi do
zaspokojenia stwierdzonych lub przewidywanych potrzeb uŜytkownika produktu. Tak naprawdę
nigdy nie mamy pewności czy uŜytkownik wyartykułował wszystkie swoje wymagania odnośnie
produktu, czy Specyfikacja Wymagań jest kompletna, czy nie pominięto w niej Ŝadnych sytuacji
wyjątkowych lub odwołań do standardów, które oprogramowanie musi spełniać. W związku
z tym, przez „Liczbę wszystkich wymagań” w powyŜszym wzorze, naleŜy rozumieć nie tylko
wymagania udokumentowane, ale równieŜ wymagania przewidywane.

Strona 10 z 37

TESTER.PL
Dobrze zdefiniowany zbiór wymagań charakteryzuje się między innymi tym, Ŝe
wymagania są w nim ułoŜone według waŜności. Z punktu widzenia osoby podejmującej decyzję
o zakończeniu procesu testowania idealna jest sytuacja, gdy pokrycie wymagań wynosi 100%,
jednak w praktyce współczynnik ten moŜe mieć niŜsze wartości (choćby dlatego, Ŝe nie zawsze
testowanie wszystkich wymagań jest „opłacalne”). W takich przypadkach przydatna moŜe
okazać się informacja o pokryciu wymagań według ich wagi. Zupełnie czymś innym jest fakt
przetestowania 70% wymagań, z czego wszystkich krytycznych i waŜnych, a tylko części
uŜytecznych, niŜ sytuacja przetestowania 90% wymagań, z czego wszystkich uŜytecznych
i waŜnych, a tylko części krytycznych. Z mojego punktu widzenia korzystniejsza moŜe okazać się
sytuacja pierwsza.

Pokrycie kodu
Metryka pokrycia kodu pozwala stwierdzić jaka część kodu źródłowego została wykonana
podczas testów. WyraŜona jest następującym wzorem:
Pokrycie kodu = Liczba wykonanych jednostek kodu / Liczba wszystkich jednostek kodu,
gdzie „liczba jednostek kodu” moŜe być rozumiana jako:
liczba linii kodu (LOC – ang. lines of code),
liczba ścieŜek (instrukcja if then else stanowi dwie moŜliwe ścieŜki do przejścia –
jedną przy spełnionym warunku i drugą, gdy warunek nie jest spełniony), itp.
Kod

źródłowy

naleŜy

traktować

jako

dokumentację

wyobraŜenia

programisty

o wymaganiach wobec oprogramowania. Na wyobraŜenie to składa się to czego klient naprawdę
oczekuje po przejściu przez filtr wyobraŜeń analityka, projektanta i w efekcie – samego
programisty. Co więcej – kod źródłowy moŜe być obarczony dodatkowo takimi uchybieniami jak
– implementacja funkcji, których klient nie potrzebuje oraz brak funkcji wymaganych. Stąd
informacja o pokryciu kodu, choć uŜyteczna w róŜnych zastosowaniach, niewiele wnosi przy
próbie odpowiedzi na pytanie czy nasz produkt jest „wystarczająco dobry”. Nawet jeśli będziemy
wiedzieli, Ŝe przetestowano cały kod i co więcej – nie znaleziono w nim Ŝadnego błędu, nie
będziemy wiedzieli zbyt duŜo o zdolności produktu do zaspokojenia stwierdzonych lub
przewidywanych potrzeb jego uŜytkownika.

Efektywność usuwania błędów
Efektywność usuwania błędów (ang. Defect Removal Effectiveness) jest wyraŜona
następującym wzorem (przytaczam jedną z kilku interpretacji tej metryki):
DRE = Liczba błędów znalezionych w czasie testów/ Liczba wszystkich znalezionych
błędów,

Strona 11 z 37

TESTER.PL
gdzie Liczba wszystkich znalezionych błędów jest to suma liczby błędów znalezionych
w czasie testów i liczby błędów znalezionych po testach (w szczególności – przez klienta, po
2

wydaniu oprogramowania, w danym okresie ).
Aby przybliŜyć zastosowanie tej metryki, posłuŜę się przykładem (po modyfikacjach)
z opracowania [3]:
Faza, w której popełniono błąd

RAZEM

Faza, w której wykryto błąd

Analiza

Projekt

Kodowanie

Analiza

10

-

-

10

Projekt

3

18

-

21

Kodowanie

0

4

26

30

Błędy wykryte po wdroŜeniu
oprogramowania (przez klienta i
wewnętrznie)

1

2

7

10

RAZEM

14

24

33

71

Efektywność dla fazy analizy = 10/ 14 = 71%
Efektywność dla fazy projektowania = 21/ (14 + 24 - 10) = 75%
Efektywność dla fazy kodowania = 30/ (14 + 24 + 33 – 10 – 21) = 75%
Efektywność całkowita = (10 + 21 + 30)/ (14 + 24 + 33) = 86%
Metryka ta mówi o tym jak efektywny jest nasz proces testowania i jak skuteczny
w wykrywaniu/ usuwaniu błędów. Do oszacowania efektywności całkowitej niezbędna jest
jednak informacja o liczbie błędów wykrytych po wdroŜeniu oprogramowania, czego w naszej
sytuacji jeszcze nie wiemy. Podstawą w tym przypadku są więc dane historyczne. Jeśli je
posiadamy, wiemy jak kształtowały się współczynniki efektywności w innych przedsięwzięciach
(np. przy produkcji poprzedniej wersji tego samego oprogramowania) dla zespołu testerów
o takich samych lub podobnych kompetencjach i przy takim samym lub podobnym przebiegu
procesu testowania. W takich warunkach moŜna załoŜyć, Ŝe efektywność usuwania błędów
kształtuje się na podobnym poziomie.
Dla modelu CMM określono wartości DRE osiągane przez organizację na kaŜdym z pięciu
poziomów dojrzałości. Przytaczam je tutaj za [1]:
Poziom dojrzałości według CMM

Defect Removal Effectiveness

Poziom 5

95%

Poziom 4

93%

Poziom 3

91%

Autor ksiąŜki „Metrics and Models in Software Quality Engineering”, Stephen H. Kan twierdzi, Ŝe znaczna większość błędów
zostaje wykryta w ciągu dwóch lat od wydania oprogramowania. Najczęściej przyjmuje się jednak okres sześciu miesięcy.
2

Strona 12 z 37

TESTER.PL
Poziom dojrzałości według CMM

Defect Removal Effectiveness

Poziom 2

89%

Poziom 1

85%

Jakoś produktu
Metryka częstości błędów
Metryka częstości błędów (ang. Defect Density) jest wyraŜona następującym wzorem:
DD = Liczba znanych błędów/ Rozmiar kodu,
gdzie Rozmiar kodu jest to „liczba okazji do popełnienia błędów” [1] wyraŜona jako
liczba KLOC (ang. 1000 Lines of Code) lub liczba punktów funkcyjnych.
Istnieje wiele róŜnych definicji LOC. Linią kodu w tym znaczeniu moŜe być kaŜda fizyczna
linia

kodu,

kaŜda

wykonywalna

linia

kodu,

z uwzględnieniem

komentarzy

lub

bez,

z uwzględnieniem definicji danych lub bez, itd. W wielu przypadkach jest to wartość, którą
trudno zmierzyć, i która zaleŜy od uŜytej technologii (potrzeba więcej linii kodu w asemblerze niŜ
w C#, aby zaimplementować tę samą funkcjonalność). Z powodu róŜnic w interpretacji metryki
LOC i trudnościach w oszacowaniu jej wartości wielu autorów sugeruje metrykę punktów
funkcyjnych.3
Metryka

częstości

błędów

ma

kilka

zastosowań.

MoŜe

być

między

innymi

wykorzystywana do porównywania jakości róŜnych komponentów, co pozwoli zidentyfikować te
o większym współczynniku błędów i w porę podjąć działania zaradcze. MoŜe równieŜ, co jest
najbardziej interesujące z naszego punktu widzenia, być stosowana do oceny czy produkt jest
wystarczająco dobry, przy czym w tym przypadku konieczne jest posiadanie danych
historycznych, a im więcej ich jest, tym lepiej. Steve McConnell w swoim artykule [4] omawia
następujący przykład (podaję go po drobnych modyfikacjach):
Liczba znanych błędów
KLOC

Przed
wdroŜeniem

DD

Po wdroŜeniu

Wydanie 1

100

650

50

7,0

Wydanie 2

50

400

75

9,5

Wydanie 3

100

600

X

ZałóŜmy, Ŝe musimy podjąć decyzję o tym czy jesteśmy gotowi do trzeciego wydania.
Biorąc pod uwagę współczynniki DD dla poprzednich dwóch wydań, moŜemy się spodziewać
(pod warunkiem, Ŝe nie dokonaliśmy jakichś rewolucyjnych zmian w naszym procesie produkcji),

3

Swoją drogą, oszacowanie liczby punktów funkcyjnych równieŜ jest zadaniem nietrywialnym i często wymaga
zaangaŜowania eksperta.

Strona 13 z 37

TESTER.PL
Ŝe dla tego wydania osiągniemy równieŜ od 7 do 10 błędów/ KLOC. ZałóŜmy, Ŝe jako kryterium
przyjęliśmy usunięcie 95% błędów przed publikacją oprogramowania.
Dla współczynnika DD = 7,0 mamy:
(600 + X) / 100 = 7,0
X = 100
Łączna liczba błędów wynosi 600 + 100, co oznacza, Ŝe aby spełnić nasze kryterium
(95%), musimy wykryć 665 błędów przed publikacją oprogramowania (w takim razie pozostało
jeszcze 65).
Dla współczynnika DD = 10,0 mamy natomiast:
(600 + X) / 100 = 10,0
X = 400
Łączna liczba błędów wynosi 600 + 400, co oznacza, Ŝe aby spełnić nasze kryterium
(95%), musimy wykryć 950 błędów przed publikacją oprogramowania (pozostało jeszcze 350 –
duŜo pracy przed nami).

Niezawodność oprogramowania - średni czas międzyawaryjny
Zanim omówię tę metrykę, zdefiniuję dwa podstawowe pojęcia, którymi będę się
posługiwać: błąd i awaria4. Awaria to nieoczekiwane zachowanie systemu, które wystąpiło
w czasie jego pracy i zostało zauwaŜone przez uŜytkowników. Błąd to pomyłka prowadząca do
niepoprawnego zapisu w kodzie źródłowym. Nie kaŜdy błąd musi skutkować awarią
oprogramowania, ponadto jeden błąd moŜe powodować kilka róŜnych awarii. W duŜym stopniu
zaleŜy to od profilu uŜycia systemu – jeśli błąd występuje w funkcji częściej uŜywanej przez
uŜytkowników, istnieje większe prawdopodobieństwo, Ŝe się objawi w postaci awarii.
Średni czas międzyawaryjny (ang. Mean Time Between Failures) oznacza czas
pomiędzy awariami mierzony w określonych jednostkach (najczęściej godzinach, ale równieŜ
dniach, miesiącach lub latach).
MoŜna więc przyjąć, Ŝe nasze oprogramowanie jest „wystarczająco dobre”, gdy
współczynnik MTBF osiągnie w testach (pod warunkiem ich prowadzenia w odpowiedni sposób)
poŜądaną wartość.
Autor ksiąŜki [1], Stephen H. Kan twierdzi, Ŝe, dla systemów, które nie mają typowego
profilu uŜycia, metryka ta jest trudna do implementacji i moŜe nie być reprezentatywna. Poza
tym, gromadzenie danych o czasie pomiędzy wystąpieniem awarii jest bardzo kosztowne
i wymaga metod statystycznych. Dlatego teŜ metryka ta jest bardzo rzadko stosowana do oceny

4

W literaturze róŜne pojęcia mają te same definicje. Przyjęłam więc dwa z nich, dla porządku.

Strona 14 z 37

TESTER.PL
jakości

(niezawodności)

oprogramowania

komercyjnego

(częściej

jednak

do

oceny

oprogramowania o krytycznym znaczeniu dla bezpieczeństwa).

Inne techniki szacowania liczby ukrytych błędów
We wspomnianym juŜ przeze mnie artykule [4] jego autor, Steve McConnell, omawia
jeszcze dwie ciekawe techniki, o których chciałabym napisać kilka słów:
1. Defect Pooling
Wszystkie błędy znalezione podczas testów naleŜy podzielić na dwa zbiory, A i B.
Kryterium podziału jest dowolne, przy czym kaŜdy z tych zbiorów powinien obejmować cały
zakres funkcjonalny testowanego produktu. Autor proponuje, aby do jednego zbioru przypisać
np. wszystkie błędy znalezione w poniedziałki, środy i weekendy, a do drugiego – błędy
znalezione w pozostałe dni. MoŜna równieŜ dokonać podziału według testerów – błędy
znalezione przez jedną połowę zespołu testującego przypisać do jednego zbioru, a błędy drugiej
połowy – do drugiego. W omawianej technice istotna jest:
liczba błędów w zbiorze A (we wzorze oznaczona symbolem A),
liczba błędów w zbiorze B (we wzorze oznaczona symbolem B),
liczba błędów w części wspólnej zbioru A i B (we wzorze oznaczona symbolem
A&B).
Liczba wszystkich błędów (znalezionych i pozostających do znalezienia) jest szacowana
z następującego wzoru:
Całkowita liczba błędów = (A * B)/ A&B
Przy stałej liczbie błędów w zbiorze A i B, im mniejsza będzie część wspólna tych
zbiorów, tym większa przewidywana całkowita liczba błędów.
2. Defect Seeding
Technika ta polega na celowym umiejscowieniu w kodzie źródłowym programu błędów.
Informacja o tym ile z tych błędów zostało wykrytych podczas testowania pozwala przewidywać
ile błędów z tych, które były pierwotnie w oprogramowaniu, pozostaje jeszcze do wykrycia.
Technika ta jest najbardziej skuteczna, jeśli błędy celowo umieszczone w kodzie źródłowym
obejmują cały zakres funkcjonalny oraz są róŜnej wagi – od błędów krytycznych po
kosmetyczne.
Przyjmę następujące oznaczenia:
PZnalezione – Liczba znalezionych błędów pierwotnych
PWszystkie – Liczba wszystkich błędów pierwotnych
CZnalezione – Liczba znalezionych błędów celowo umiejscowionych w kodzie
CWszystkie – Liczba wszystkich błędów celowo umiejscowionych w kodzie
W technice tej przyjmuje się, Ŝe liczba znalezionych błędów pierwotnych jest równa:

Strona 15 z 37

TESTER.PL
PZnalezione = (CZnalezione / CWszystkie) * PWszystkie
stąd liczba wszystkich błędów pierwotnych jest równa:
PWszystkie = PZnalezione * (CWszystkie / CZnalezione)
Jeśli więc w kodzie programu umiejscowiono celowo 40 błędów, z czego wykrytych
zostało 30, a pierwotnych błędów wykryto 500, to moŜna się spodziewać, Ŝe łączna liczba
błędów pierwotnych wynosi:
PWszystkie = 500 * (40 / 30) = 667
Znaleźliśmy więc dopiero 75% błędów. ZałóŜmy, Ŝe jako kryterium przyjęliśmy usunięcie
95% błędów przed publikacją oprogramowania, co stanowi ok. 630 błędów. Mamy więc jeszcze
sporo do zrobienia.
Technika ta jest przydatna, lecz ma kilka wad:
Celowe umiejscowienie błędów w kodzie programu jest kosztowne, wymaga
dodatkowych nakładów pracy.
MoŜna zapomnieć o usunięciu tych błędów, a przy ich usuwaniu – zrobić kolejne.

Ideały są jak gwiazdy. Jeśli nawet nie moŜemy ich osiągnąć, to naleŜy się według nich
orientować.
George Bernard Shaw

Podsumowanie
PowyŜej omówiłam wybrane metryki i techniki, które mogą być przydatne przy ocenie
czy produkt jest „wystarczająco dobry” do wdroŜenia. Postawienie sobie takiego pytania
wymaga pewnej dojrzałości organizacji, jeszcze większej natomiast wymaga świadoma na nie
odpowiedź. Autorzy ksiąŜki [2] proponują taki test – jeśli chcesz wiedzieć co organizacja
naprawdę

myśli

o

jakości,

obserwuj

trzy

ostatnie

dni

kaŜdego

sześciomiesięcznego

przedsięwzięcia – zobacz co się stanie, jeśli ostatniego dnia zostanie zgłoszony nowy problem.
Osobiście wyznaję w takich sytuacjach zasadę: „lepszy znany wróg niŜ nieznany przyjaciel”.
Wykrycie i usunięcie wszystkich błędów jest niemoŜliwe, a jeden błąd zazwyczaj stanowi nikły
procent całości. Pochopne usuwanie go w ostatniej chwili moŜe z kolei spowodować całą lawinę
błędów, które wykryje dopiero niezadowolony klient. Trzeba pogodzić się ze świadomością, Ŝe
za kaŜdym razem kiedy publikujemy oprogramowanie, dajemy uŜytkownikom do ręki produkt
z błędami5 (choć i tak to uŜytkownicy będą mieli większą trudność z pogodzeniem się z tym
faktem). Dobrze jest jednak wiedzieć jak wadliwy jest to produkt i czy wydanie go tu i teraz
przysporzy więcej korzyści czy problemów.

5

Stąd właśnie wymagania dotyczące dostępności i niezawodności są podgrupą wymagań niefunkcjonalnych.

Strona 16 z 37

TESTER.PL
W niniejszym opracowaniu omówiłam tylko wybrane metryki i techniki szacowania liczby
ukrytych błędów oparte na danych dostarczonych przez proces testowania (liczba znalezionych
błędów). Pomijam tematykę modeli niezawodności, równieŜ bazujących na tych danych, których
zastosowanie wymaga pewnej wiedzy statystycznej. W literaturze moŜna takŜe przeczytać
o wielu innych metodach, na przykład opartych na miarach rozmiaru programu (bazujących na
związku pomiędzy rozmiarem programu, a liczbą ukrytych w nim błędów). Większość z tych
metod, między innymi z racji tego, Ŝe operują pojęciem błędu zamiast awarii (róŜnice między
nimi – patrz rozdział dotyczący metryki MTBF), a więc tak naprawdę nie mówią za duŜo
o niezawodności oprogramowania, spotyka się z szeroko zakrojoną krytyką. Stąd trwają prace
nad wykorzystaniem w tym obszarze drzew decyzyjnych czy sieci Bayesa, które pozwalają
bazować na wielu róŜnych kryteriach będących wyznacznikiem niezawodności. Więcej informacji
moŜna znaleźć w [1] oraz wielu artykułach dostępnych w Internecie.

Literatura
KsiąŜki:
[1] Metrics and Models in Software Quality Engineering, 2nd Edition, Stephen H. Kan,
Addison Wesley Professional, 2003
[2] The Rational Unified Process Made Easy, A Practitioner’s Guide to the RUP, Per Kroll,
Philippe Kruchten, Pearson Education Inc., 2003
Artykuły:
[3] Defect Removal Effectiveness, Linda Westfall (dostępne w Internecie pod adresem:
http://www.westfallteam.com/Papers/defect_removal_effectiveness.pdf)
[4] Gauging Software Readiness With Defect Tracking, Steve McConnell (artykuł
dostępny pod adresem: http://www.stevemcconnell.com/ieeesoftware/bp09.htm)
[5] An overview of software quality concepts and management issues, Claude Y.
Laporte, 2005 (artykuł dostępny w Internecie pod adresem:
http://profs.logti.etsmtl.ca/claporte/Publications/Publications/Duggan_Chapter_SQA.pdf)

Strona 17 z 37

TESTER.PL

Software & Systems Quality Conferences 2007
We would like to invite you to join colleagues and associates from the Software &
Systems Quality Management and Testing profession at the industry’s most important
conference in 2007.
The programme has been carefully designed by our independent programme committee
to fulfill the comments and feedback gathered from delegates at our conferences and seminars
throughout the year. We have selected presentations that offer new answers to obstacles and
problems we face today and case studies wherever possible.
We have had a tremendous response to the call for papers this year and we are grateful
to everyone for communicating their ideas for the 2007 conference.
The SQC conference provides solutions, state-of-the-art best practices and services to IT
professionals. The mission of this must attend conference, now in its 12th year is to:
•

help make sense of trends, technologies, and strategies in the Software &
Systems Quality world today

•

learn about the latest developments in outsourcing, process models and
optimization, test management and test automation, embedded systems

•

learn about testing in SOA and agile project environment, and model-based
testing

Exhibitors are also preparing to show their latest offerings to you at the most
comprehensive exhibition in this field in 2007. So come along and see the latest tools and
services from the leading suppliers in software testing and quality.
Prepare yourself for three interesting days packed with lectures, workshops, and
tutorials as well as the accompanying exhibition and an evening event in Dusseldorf. Get to
know the latest trends and innovative solutions, discuss the issues that matter to your business,
swap experience and information with experts.
For further information please have a look at www.sqs-conferences.com/de

Strona 18 z 37

TESTER.PL

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. 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 IMPAQ na stanowisku analityka
do spraw zapewnienia jakości, biorąc udział w projektach dla
klientów w kraju, jak równieŜ dla klientów zagranicznych. W
obecnej pracy wykorzystuje głównie procesy z zakresu Service
Support, zarządzania problemem oraz incydentem.

Strona 19 z 37

TESTER.PL

Zarządzanie problemem i incydentem
Joanna Droździel

1. Service Desk
W

większości

przedsiębiorstw

wyodrębniony

został

oddział

odpowiedzialny

za

bezpośredni kontakt z uŜytkownikiem. Najpopularniejszą jednostką realizującą to zadanie jest
Help Desk, ale pojawiają się równieŜ inne rozwiązania takie jak: Call Center, Customers Service
Center oraz Customer Hotline. Bez względu na bardzo rozbudowane obowiązki, jednostki te
mają jedno wspólne zadanie do wykonania: jak najszybsze rozwiązanie awarii oraz incydentów
zgłaszanych przez uŜytkowników. Działania całego działu informatycznego postrzegane są przez
działalność Help Desku, poniewaŜ stanowi on pierwszy i jedyny bezpośredni kontakt dla
uŜytkownika. Z badań Forrester Research wynika, Ŝe prawie połowa z 2000 badanych
uŜytkowników jest niezadowolona z jakości świadczonych usług. Narzekają przede wszystkim na
wydłuŜający się czas rozwiązywania zgłoszonych incydentów.
MenedŜerowie działów informatycznych oraz przedstawiciele zarządu prześcigają się w
wymyślaniu coraz to ciekawszych nazw dla jednostek odpowiedzialnych za bezpośredni kontakt
z uŜytkownikiem. Chcą tym samym zamknąć epokę nie lubianych działów Help Desk. Jednak nie
w nazwie tkwi problem ale w sposobie organizacji pracy. Dlatego metodyka ITIL wychodzi z
propozycją Service Desku. Jego zadaniem jest nie tylko szybka reakcja na zgłoszenie czyli
realizacja procesu zarządzania incydentem, ale równieŜ wspieranie procesów zarządzania
problemem, zmianą, konfiguracją, wersją, dostępnością oraz procesu zarządzania poziomem
usług. Na czym polega unikalność działu Service Desk? Przede wszystkim na poprawnie
określonych zadaniach, procesach a w szczególności na pełnej odpowiedzialności, poniewaŜ od
efektywności pracy działu Service Desk zaleŜy poprawność pozostałych procesów Service
Support. Jednak by działania te przebiegały sprawnie i efektywnie, potrzeba zrozumiałych dla
wszystkich zasad. Wytyczne muszą być jasne zarówno dla pracowników działu, uŜytkowników
jak i przede wszystkim dla osób odpowiedzialnych za poprawną realizację pozostałych procesów
Service Support. Informacje uzyskane dzięki cięŜkiej i efektywnej pracy zespołu Service Desk
przekazywane są osobom odpowiedzialnym za realizacje pozostałych procesów omawianego
obszaru. Błędnie wykorzystane mogą skutkować załamaniem się całego obszaru Service

Strona 20 z 37

TESTER.PL
Support. Dlatego współpraca na linii Service Desk - pozostałe procesy musi być rozwinięta na
bardzo wysokim poziomie.

2. Zarządzanie incydentem
Jednym z głównych zadań pracowników Service Desk jest zagwarantowanie stałej
dostępności usługi informatycznej (Zarządzanie dostępnością). Jednak nawet w sytuacji, gdy
firma dysponuje sprzętem najnowszej generacji, trudno wykluczyć moŜliwość wystąpienia
awarii. Dlatego pracownicy tego działu powinni być gotowi na szybką reakcję.
UŜytkownicy kaŜdego dnia zgłaszają do działu Service Desk kilkadziesiąt a niekiedy i
kilkaset awarii. Proces, który jako pierwszy przychodzi z pomocą w sytuacji awaryjnej to proces
zarządzania incydentem. Na wstępie warto zapoznać się z pojęciem incydentu. OtóŜ incydent według metodyki ITIL - to kaŜde zdarzenie (które nie jest częścią normalnego działania)
powodujące lub mogące spowodować przerwę w dostarczeniu usługi. Powodów wystąpienia
incydentów moŜe być bardzo wiele. Zasadniczo incydenty ze względu na powód wystąpienia
podzielone zostały na dwie grupy: incydenty wynikające z awarii sprzętu (awaria drukarki,
monitora) oraz incydenty wynikające z awarii oprogramowania (brak dostępu do bazy danych,
aplikacji). Cykl Ŝycia incydentu od momentu wykrycia do momentu zamknięcia został omówiony
w podrozdziale przedstawionym poniŜej.

Proces zarządzania incydentem
Celem procesu jest jak najszybsze przywrócenie usługi oraz zminimalizowanie
niekorzystnego wpływu na działalność biznesu. Nie ma tutaj miejsca ani czasu na szukanie
przyczyn wystąpienia awarii. Na tym etapie stosuje się gotowe i wypróbowane procedury
przywracające usługę informatyczną. KaŜdy wykryty incydent powinien zostać zgłoszony
i zarejestrowany przez osobę z działu Service Desk. Metodyka ITIL nie podaje jednej konkretnej
drogi zgłoszenia incydentu, więc nie jest waŜne czy odbywa się to drogą telefoniczną, za
pomocą poczty elektronicznej czy teŜ osobiście. Istotną kwestią na tym etapie procesu jest
stworzenie takiego klimatu pracy by uŜytkownicy wykrywając awarię nie bali się zgłaszać jej
pracownikom Service Desku. WaŜne teŜ jest by nie doszło do takiej sytuacji gdy kaŜdy
uŜytkownik w obawie przed trudnymi pytaniami informatyków podejmuje próbę samodzielnej
naprawy awarii, co w rezultacie moŜe doprowadzić do jeszcze większych szkód. Dlatego by
uniknąć takich zachowań, pracownik działu Service Desk, przyjmując zgłoszenie o awarii,
powinien zadawać tylko pytania potrzebne do identyfikacji obszaru czy części infrastruktury.
UŜytkownik zgłaszając awarię nie musi znać numeru seryjnego uszkodzonego monitora czy

Strona 21 z 37

TESTER.PL
drukarki; wystarczy, Ŝe wskaŜe miejsce, gdzie dana część infrastruktury się znajduje. W tym
przypadku wystarczy informacja, iŜ drukarka znajduje się w dziale księgowym a wszystkimi
pozostałymi potrzebnymi informacjami powinien dysponować Service Desk. Informacje te
powinny znajdować się w Bazie Konfiguracji - CMDB, która zawiera najdrobniejsze szczegóły o
danym sprzęcie i oprogramowaniu oraz relacjach miedzy nimi. Po przyjęciu zgłoszenia ma
miejsce określenie przyczyny wystąpienia incydentu. Pełen cykl obsługi incydentu przedstawiono
na rysunku 1.

Rysunek 1. Cykl Ŝycia incydentu.

Z reguły Service Desk jest przeciąŜony pracą poniewaŜ uŜytkownicy generują setki
zgłoszeń dziennie. WaŜne jest by w gąszczu błahych awarii nie zostały przeoczone zdarzenia,
dla których kaŜda minuta zwłoki przynosi działalności biznesowej wysokie straty. Dlatego bardzo
pomocne na tym etapie pracy jest właściwe określenie priorytetu zgłoszenia przez pracownika
przyjmującego informację o awarii. Osoba przyjmująca zgłoszenie powinna posiadać
odpowiednią wiedzę techniczną niezbędną w szybkim naprawianiu awarii, ale równieŜ powinna
znać realia działania przedsiębiorstwa oraz hierarchię priorytetów określoną w ramach umowy

Strona 22 z 37

TESTER.PL
SLA tak, by swoją decyzją nie naraŜała firmy na niepotrzebne koszty. Po określeniu priorytetu
incydentu następuje przypisanie do odpowiedniej grupy wsparcia. Rysunek 2 przedstawia
strukturę grup wsparcia wymienionych przez autorów metodyki ITIL. JeŜeli jest to awaria dobrze
znana pracownikom Service Desku oraz dysponują oni gotową do realizacji procedurą
naprawienia, wówczas zgłoszenie jest kierowane na pierwszą linie obsługi incydentu.

Rysunek 2. Linie wsparcia procesu zarządzania incydentem.

JeŜeli natomiast ma miejsce sytuacja, gdzie pracownik Service Desk nie potrafi określić
przyczyny wystąpienia awarii, wówczas takie zgłoszenie kierowane jest do drugiej linii wsparcia
odpowiedzialnej za poszukiwanie rozwiązania. Wskazane jest aby przed przekierowaniem
zdarzenia do drugiej grupy wsparcia udało się je naprawić, nie czyniąc tym samym szkód
finansowych dla działalności biznesowej przedsiębiorstwa. Jednak przypadków, które zostały
naprawione bez poznania przyczyny ich powstania jest niewiele. Z reguły na drugą linię
wsparcia trafiają nierozwiązane problemy, których bez wnikliwego procesu zarządzania
problemem nie sposób naprawić. Dlatego wielu praktyków metodyki ITIL uwaŜa, iŜ druga i

Strona 23 z 37

TESTER.PL
trzecia linia wsparcia w procesie zarządzania incydentem realizuje załoŜenia procesu zarządzania
problemem (będzie o tym mowa w rozdziale następnym). Niekiedy pracownicy drugiej linii
wsparcia nie mogąc znaleźć rozwiązania problemu, korzystają z pomocy trzeciej linii wsparcia,
którą z reguły stanowią konsultanci z firm zewnętrznych.
W procesie zarządzania incydentem nie ma czasu na szukanie przyczyny wystąpienia
awarii. Na tym etapie prac w obszarze Service Support stosuje się procedury oraz rozwiązania
stanowiące Bazę Wiedzy. Zawiera ona scenariusze postępowania na wypadek konkretnych
awarii. Gdy brakuje w bazie danego rozwiązania, wówczas jest to jednoznaczne z sytuacją, iŜ
pracownicy Service Desk mają do czynienia z nowym typem awarii, dotychczas nieopisanym. W
takiej sytuacji incydent staje się problemem i trafia do procesu zarządzania problemem.
Zarówno uŜytkownicy jak i pracownicy Service Desku wiedzą, jak wiele awarii
naprawianych jest na bieŜąco. Jest jednak równieŜ grupa nierozwiązanych incydentów, dlatego
Service Desk powinien cały czas śledzić oraz monitorować przebieg realizacji incydentów. Nie
moŜe dojść do sytuacji, w której pracownicy zapomną o naprawieniu awarii, co w rezultacie
narazi przedsiębiorstwo na straty finansowe. By tego uniknąć wiele firm, których uŜytkownicy
generują setki zgłoszeń dziennie, decyduje się na zakup dodatkowego oprogramowania
pomocnego w obsłudze incydentów.
Po określeniu procedury w Bazie Wiedzy następuje etap naprawienia incydentu i w
efekcie jego zamknięcie. Według autorów metodyki ITIL Service Desk powinien rozwiązać 85%
wszystkich zgłoszeń juŜ w pierwszej linii wsparcia, bez korzystania z pomocy pozostałych grup.

Działania proaktywne procesu zarządzania incydentem
Zadaniem działu Service Desk nie jest tylko naprawianie zgłaszanych awarii ale przede
wszystkim podjęcie działań eliminujących awarie drobne, błahe. Wiadomo, Ŝe nie sposób
przeszkolić wszystkich uŜytkowników tak, by nie generowali niepotrzebnych zgłoszeń ale warto
czasami zwrócić uwagę na błędy popełniane przez uŜytkowników. Zazwyczaj uŜytkownicy z
braku wiedzy, bojąc się zapytać pracowników działu informatycznego, drogą prób i błędów
poznają tajniki nowej aplikacji bądź sprzętu. Częściej jednak poszerzają swoją wiedzę drogą
popełnianych błędów, za które strona biznesowa zmuszona jest płacić, a Service Desk
naprawiać. Dlatego warto przyjrzeć się zachowaniom uŜytkowników oraz ich starym, złym
nawykom. Jeden szybki telefon do działu Service Desk z krótkim zapytaniem uchroni organizację
przed niepotrzebnymi kosztami. Jako przykład negatywnego zachowania uŜytkownika moŜe
posłuŜyć problem drukowania na foliach. Wystarczyło aby uŜytkownik wykonał jeden telefon do
Service Desku z zapytaniem, na której drukarce moŜna w ten sposób drukować. Uchroniłoby to
firmę przed niepotrzebną wymianą drukarki. Jednak nie wszystkie awarie wynikają z

Strona 24 z 37

TESTER.PL
nieprofesjonalnych zachowań uŜytkowników, tego typu awarie stanowią niewielką część
wszystkich incydentów. Zdecydowana większość awarii wynika z przestarzałego sprzętu
zalegającego w wielu przedsiębiorstwach. Zasada, Ŝe im starsze tym lepsze sprawdza się w
przypadku wina. W przypadku komputerów jest odwrotnie - trzyletnia maszyna moŜe juŜ
spowodować właścicielowi niemałe kłopoty. Amerykańscy specjaliści wyliczyli, iŜ koszt obsługi
starego komputera jest od 3 do 5 razy większy niŜ zakup nowego sprzętu. Dlatego strona
biznesowa nie powinna ograniczać funduszy na zakup nowej infrastruktury informatycznej.
Zwłaszcza, Ŝe przestarzały sprzęt wymusza na uŜytkownikach bardzo groźne dla całej
infrastruktury działania. UŜytkownicy aby przyśpieszyć działanie komputerów wyłączają
programy antywirusowe, co sprowadza na przedsiębiorstwo kolejne straty finansowe
spowodowane incydentami

naruszeń bezpieczeństwa informatycznego.

Według

raportu

magazynu CIO oraz firmy PricewaterhauseCoopers, opracowanego w roku 2003, w 17% firm
miało miejsce powyŜej 10 wypadków dotyczących naruszeń bezpieczeństwa firmy w ciągu roku,
co było równoznaczne z przestojem w pracy o całkowitym wymiarze od 4 do 8 godzin. Dlatego
zamiast wydawać pieniądze na „gaszenie poŜarów”, warto zainwestować w działania
profilaktyczne eliminujące moŜliwość wystąpienia takiego poŜaru. Dzięki takiej postawie ilość
zakłóceń w normalnej pracy zarówno dla pracowników Service Desku, jak i uŜytkowników
zostanie zmniejszona do niezbędnego minimum.

3. Zarządzanie problemem
MenedŜerowie róŜnych działów informatycznych mieli zapewne niejednokrotnie do
czynienia z sytuacją, uznawaną przez nich za sytuację bez wyjścia: co zrobić w wypadku, gdy
następuje przerwa w dostawie usługi z przyczyn nie rozpoznanych przez personel Service
Desku. Z pomocą moŜe przyjść proces zarządzania problemem. NiezaleŜnie od tego Service
Desk powinien próbować przywrócić usługę w stopniu, na jaki pozwalają realia zaistniałej awarii.
JeŜeli podjęte działania nie przyniosły oczekiwanych rezultatów naleŜy poddać problem
szczegółowej analizie. Względy formalne określają, iŜ awarie zgłoszone przez uŜytkowników
stają się problemami wówczas, gdy pierwsza linia wsparcia Service Desk nie dysponuje
gotowym rozwiązaniem bądź procedurą. W takiej sytuacji incydent staje się problemem.
Efektywne zarządzanie problemem zaleŜy w duŜym stopniu od poprawnej implementacji procesu
zarządzania incydentem.

Strona 25 z 37

TESTER.PL

Proces zarządzania problemem
Proces zarządzania incydentem miał na celu jak najszybsze przywrócenie usługi,
natomiast proces zarządzania problemem odpowiada za minimalizowanie niekorzystnego
wpływu na działalność biznesową incydentów i problemów.
Nie ma określonej kolejności wdraŜania procesu zarządzania problemem; najlepszym
rozwiązaniem jest wdraŜanie go równolegle z procesem zarządzania incydentem. Zazwyczaj na
proces zarządzania problemem nakłada się kilka incydentów, dlatego teŜ warto spojrzeć na to
zagadnienie z szerszej perspektywy. Pracownicy Service Desku obserwują kaŜdy indywidualny
incydent; w procesie zarządzania problemem jest czas by przejrzeć się całej grupie.
Proces zarządzania problemem składa się z dwóch podprocesów: kontroli problemu oraz
kontroli błędu. Podproces kontroli problemu ma za zadanie przekształcić nieznaną awarię w
znany błąd, natomiast podproces kontroli błędu ma za zadanie rozwiązać znane błędy
przygotowując tym samym RfC dla procesu zarządzania zmianą.
Service Desk nie posiada gotowych scenariuszy postępowania w przypadku kaŜdej
moŜliwej awarii. W procesie zarządzania problemem następuje więc identyfikacja przyczyn
występowania incydentów oraz poszukiwanie rozwiązań. Dana awaria kierowana jest do grupy
pracowników odpowiedzialnych za proces zarządzania problemem. Zespół ten pracuje w
bardziej komfortowych warunkach, niŜ te z jakimi mają do czynienia pracownicy Service Desku.
Przede wszystkim działania w procesie zarządzania problemem nie mają określonych ram
czasowych, toteŜ pośpiech jest tutaj wręcz niewskazany. NaleŜy jednak zachować w tej kwestii
zdrowy umiar. Grupa poszukująca rozwiązania dla danego problemu powinna mieć szczególnie
na uwadze względy finansowe, starając się wykluczyć sytuacje naraŜające stronę biznesową na
jakiekolwiek dodatkowe straty. Dlatego bardzo waŜne jest aby zespół składał się zarówno z
osób bardzo dobrze wyszkolonych technicznie, jak równieŜ osób posiadających konieczną
wiedzę biznesową. Z reguły problemy, które kierowane są do tej grupy, wymagają bardzo
wnikliwej analizy. WaŜne by w trakcie procesu korzystano z róŜnych technik pomocnych w
analizie problemu. Do najczęściej stosowanych naleŜą:
−

Ankiety eksperckie - cechą charakterystyczną tej metody jest jej prostota. Polega
na

zidentyfikowaniu

właściwego

eksperta

w

danej

dziedzinie

projektu

informatycznego, np.: oprogramowaniu, którego zadaniem jest przygotowanie
ankiety w oparciu o przekazane informacje. Następnie w rozmowie z szefem działu
IT konsultanci posługują się gotowymi zestawami pytań. Dane otrzymane z ankiet
dotyczą ryzyka związanego z harmonogramem, kosztami i wydajnością.

Strona 26 z 37

TESTER.PL
−

Burza mózgów - zwana twórczą dyskusją, umoŜliwia przeprowadzenie otwartej,
dynamicznej rozmowy na tematy związane z wykrytym problemem. Pozwala spojrzeć
na problem w sposób nowatorski, co byłoby niemoŜliwe przy wykorzystaniu innych
metod. Technice tej towarzyszy sporo emocji. Praca odbywa się w zespole.
Rozwiązania które powstają w czasie spotkania od razu są utrwalane, by po
spotkaniu udostępnić je upowaŜnionym osobom w firmowym Intranecie.

−

Analiza załoŜeń - zadaniem tej techniki jest przeanalizowanie wszystkich aspektów
i ich weryfikacja prowadząca do zatwierdzenia lub odrzucenia sposobu rozwiązania
problemu. Takie działanie prowadzi do powszechnego zrozumienia warunków i
własności projektu.

Proces zarządzania problemem rozpoczyna się od identyfikacji oraz wstępnej klasyfikacji
problemu. Po określeniu przyczyn wystąpienia problemu naleŜy zaproponować scenariusz
postępowania zmierzający do naprawy problemu. Bardzo waŜne aby takich scenariuszy było
kilka, tak by osoby odpowiedzialne za realizację podprocesu kontroli błędu mogły wybrać
rozwiązanie optymalne zarówno dla strony informatycznej jak i biznesowej. Na tym etapie
procesu zarządzania problemem jest wystarczająco duŜo czasu by opracować klika wariantów
naprawy problemu. Po wykryciu przyczyny wystąpienia awarii zadaniem osoby odpowiedzialnej
za podproces zarządzania problemem jest opracowanie dokumentacji, tak by stanowiła ona
podstawę do reakcji dla pracowników Service Desk. Nie chodzi tutaj o produkowanie zbędnej
dokumentacji, ale o udokumentowanie rozwiązania, z którego w przyszłości mogliby korzystać
pracownicy mający bezpośredni kontakt z uŜytkownikiem. Takie działania mają na celu
zwiększenie liczby rozwiązywanych przez Service Desk awarii juŜ na pierwszej linii wsparcia.
Podprocesy składające się na proces zarządzania problemem przedstawiono na rysunku 3.

Strona 27 z 37

TESTER.PL

Rysunek 3. Proces zarządzania problemem.

Gdy działania w podprocesie zarządzania problemem zakończą się sukcesem rozpoznany
problem zostaje przekazany do podprocesu zarządzania błędem, który ma na celu wdroŜenie
opracowanych procedur. Osoby odpowiedzialne za podproces kontroli błędu zmuszone są
korzystać z pomocy grupy realizującej proces zarządzania zmianą. Naprawa błędu wymaga
wprowadzenia dodatkowych zmian, które muszą być wdroŜone poprawnie. Dlatego proces
zarządzania problemem zaleŜy nie tylko od efektywności procesu zarządzania incydentem ale
równieŜ od skuteczności procesu zarządzania zmianą.
Jednak na zamknięciu błędu proces się nie kończy. Przed osobami odpowiedzialnymi za
realizację procesu zarządzania problemem stoi dodatkowe zadanie: sprawdzenie naprawionych
elementów. O ile w przypadku małych incydentów wystarczy telefon do uŜytkownika z
zapytaniem o sposób rozwiązania, to juŜ w przypadku duŜych problemów taka forma nadzoru
moŜe nie wystarczyć. Dlatego konieczny jest formalny przegląd sprawdzający załoŜone cele oraz

Strona 28 z 37

TESTER.PL
sposób ich realizacji. Tak przeprowadzony proces pomoŜe w usystematyzowaniu procesów
zasilających Bazę Wiedzy w rekordy o znanych błędach i sposobie ich rozwiązania.

Działania proaktywne procesu zarządzania problemem
Proces zarządzania problemem przez niektórych praktyków metodyki ITIL uwaŜany jest
za przedłuŜenie procesu zarządzania incydentem. Ma on na celu nie tylko opracowanie strategii
naprawy problemu, ale przede wszystkim podejmuje działania proaktywne, polegające na
analizie infrastruktury informatycznej oraz raportów pochodzących z aplikacji wsparcia.
Proaktywne działania zmierzające do realizacji procesu zarządzania problemem muszą mieć
poparcie w danych zgromadzonych przez proces zarządzania incydentem. JeŜeli proces
zarządzania incydentem będzie prowadzony bardzo chaotycznie, bez moŜliwości sprawdzenia
całej historii zdarzenia, wówczas proaktywny proces zarządzania problemem nie będzie przynosił
oczekiwanych rezultatów. W rzeczywistości będzie sprowadzony do koniecznego minimum, a w
ostateczności całkowicie zaniknie.
Działania proaktywne realizują załoŜenia ustalone w procesach zarządzania
dostępnością oraz ciągłością (Proces zarządzania dostępnością) oraz (Proces zarządzania

pojemnością).
Nie tylko zdarzenia na które brakuje scenariuszy w Bazie Wiedzy trafiają do procesu zarządzania
problemem; kieruje się tam równieŜ i te incydenty, które udało się naprawić, ale przyczyna ich
wystąpienia jest nadal nieznana. Wówczas rekord dotyczący tego incydentu zostaje zamknięty w
procesie zarządzania incydentem, a w jego miejsce zostaje otwarty rekord w procesie
zarządzania problemem.

Warto

nie tylko

rozwiązanie kaŜdego

problemu przedstawić

pracownikom Service Desku ale równieŜ opracować wstępny koszt naprawy takiego problemu
oraz strat finansowych, jakie poniósł biznes z racji wystąpienia. NaleŜy takie oszacowanie
przedstawić stronie biznesowej na jednym z licznych spotkań. Przedstawiony raport napewno
przekona stronę biznesową do inwestycji w działania proaktywne zapobiegające wystąpieniu
problemów. Tylko takie działania mogą uchronić firmę przed zwiększającą się liczbą incydentów
mających negatywny wpływ na działalność biznesową, co jest równoznaczne z poprawieniem
jakości świadczonych usług.

Strona 29 z 37

TESTER.PL

CMMI – Dlaczego powinno Cię to obchodzić
Relacja z konferencji
Kamila Dec

Wprowadzenie
27 września 2006 w Warszawie odbyła się konferencja „CMMI – Dlaczego powinno Cię to
obchodzić” zorganizowana przez firmy: Software Mind i Kugler Maag CIE. Konferencja związana
była z zagadnieniami Capability Maturity Model Integration, przy czym prelegenci dzielili się
zarówno wiedzą teoretyczną na ten temat, jak i, co szczególnie cenne – praktycznymi
doświadczeniami, nie zawsze zakończonymi sukcesem, zdobytymi podczas usprawniania
procesów produkcji oprogramowania w swoich firmach.
Konferencję rozpoczęli: Christophe Debou z Kugler Maag CIE oraz Jay Douglass z SEI
Europe, którzy wprowadzili nas w zagadnienia związane z CMMI oraz Software Process
Improvement.
Później wystąpili przedstawiciele takich firm, jak: Deutsche Bank, Motorola, AXA Belgium,
Software Mind oraz DaimlerChrysler Financial Services opowiadając o sukcesach i poraŜkach,
czyli doświadczeniach zdobytych podczas wspinania się na kolejne poziomy dojrzałości CMMI.
Co ciekawe – wszystkie te firmy aktualnie osiągnęły drugi i/ lub starają się osiągnąć trzeci
poziom dojrzałości. Najbardziej zaawansowana jest w tym względzie Motorola, która co prawda
osiągnęła poziom piąty, jednak w modelu CMM, i równieŜ stoi przed mniej lub bardziej Ŝmudną
drogą przejścia na model CMMI. Dzięki temu, jak sądzę, prelegenci i uczestnicy konferencji mieli
okazję osiągnąć wysoki poziom zrozumienia własnych bolączek i problemów związanych
z usprawnieniem procesów produkcji oprogramowania.

Dlaczego powinno Cię to obchodzić
Jak mówił w swoim wystąpieniu Jay Douglass z SEI Europe, jakość produktu w duŜym
stopniu zaleŜy od jakości procesu, w którym ten produkt powstaje. Dla jakości produktu bardzo
istotne jest więc, aby:
1. dokładnie zdefiniować ten proces,
2. mierzyć jego efektywność,
3. ciągle szukać sposobów na jego usprawnienie.
To właśnie jest podstawą Process Improvement.
Capability Maturity Model Integration stanowi kompendium dobrych praktyk, które
pozwalają osiągnąć cele biznesowe związane z kosztami przedsięwzięć, harmonogramami,

Strona 30 z 37

TESTER.PL
produktywnością, jakością i satysfakcją klienta. I liczby to potwierdzają. NaleŜy przy okazji
pamiętać, Ŝe CMMI mówi o tym CO robić, nie mówi jednak JAK (co pewnie stanowi podstawową
trudność w jego wdroŜeniu, choć Jay Douglass o tym nie wspominał).
Jak piszą organizatorzy konferencji w jej podsumowaniu, podobno Jay Douglass tak
skomentował temat spotkania „CMMI – Dlaczego powinno Cię to obchodzić”: Bo jeśli nie, to

Twoja firma będzie ponosić dodatkowe koszty, a konkurencja Cię wyprzedzi. Niby proste,
a jednak…

Do… czterech razy sztuka
Firma AXA Belgium przeszła długą drogę zanim udało jej się osiągnąć drugi poziom
dojrzałości według modelu CMMI. Rozpoczęła ją w roku 2001, aby po czterech próbach,
w listopadzie 2005 roku, zostać ocenioną jako organizacja na drugim poziomie dojrzałości.
Z historii opowiedzianej przez prelegenta wynika ogromne samozaparcie i ciągła nauka na
własnych błędach, co w końcu doprowadziło do szczęśliwego zakończenia (choć „zakończenie”
nie jest tu dobrym sformułowaniem, choćby z racji tego, Ŝe usprawnianie procesów, jak mówili
wszyscy prelegenci, to ciągła praca, a osiąganie kolejnych poziomów dojrzałości, nie jest celem,
jest tylko środkiem). Jakie błędy popełnione zostały przy kolejnych próbach? Główne,
wymieniane przez prelegenta, to:
brak zrozumienia i zaangaŜowania ze strony uczestników programu,
pracowników i osób decyzyjnych,
zbyt

teoretyczne

podejście,

wypracowane

metody

były

trudne

do

zastosowania w praktyce.
Mimo tej dość skomplikowanej historii nie da się ukryć, Ŝe ze wszystkich firm
reprezentowanych na konferencji (pomijając Motorolę, u której przejście na model CMMI pewnie
okaŜe się formalnością), wyłącznie o AXA Belgium moŜna powiedzieć z całą pewnością, Ŝe jej
poziom dojrzałości jest wyŜszy niŜ pierwszy.

Liczby na drodze do trzeciego poziomu dojrzałości
Firma DaimlerChrysler Financial Services zmierza do trzeciego poziomu dojrzałości
(z pominięciem poziomu drugiego) i planuje osiągnąć go w maju 2007 roku. Program Software
Process Improvement rozpoczęła we wrześniu 2005 roku. W ramach programu opracowywany
jest Quality Management System, który będzie miał około pięćdziesięciu uŜytkowników.
W pogram zaangaŜowanych jest łącznie 30 pracowników6 wewnętrznych i 1,5 konsultantów

Nicole Neckermann posługiwała się w swojej prezentacji określeniem FTE (ang. Full-time equivalent). Biorąc pod uwagę jednak
rozmiar zespołu (zarówno uŜytkowników QMS – ok. 50 osób, jak i twórców QMS – 31,5 osoby) oraz czas trwania programu (2

6

Strona 31 z 37

TESTER.PL
zewnętrznych. Struktura organizacyjna programu podzielona jest na cztery zespoły robocze,
kaŜdy zespół pracuje nad czterema procesami, ma pięciu członków i jednego właściciela
procesów.
W ramach programu na dzień dzisiejszy przygotowanych zostało 14 procesów oraz 119
dokumentów. Przeprowadzono 36 szkoleń wewnętrznych, a 10 jest jeszcze planowanych. Ponad
310 godzin spędzono nad przeglądami (wraz z przygotowaniem), opracowano ponad 630 wersji
dokumentów.
Mimo podanych liczb świadczących o ogromnym zaangaŜowaniu środków w program
Software

Process

Improvement,

Nicole

Neckermann

podsumowała

swoją

prezentację

następującymi słowami:

Quality is not for free – but it is cheaper than the alternatives!

Dostawca i klient – jak moŜemy się od siebie uczyć
Marcin Politowicz z firmy Software Mind swoją prezentację poświęcił zagadnieniom
współpracy organizacji o róŜnym poziomie dojrzałości. Współpraca taka moŜe się nie powieść
z wielu powodów, między innymi z braku zrozumienia i cierpliwości, braku chęci znajdowania
kompromisów czy braku elastyczności i otwartości na zmiany procesów. UwaŜa jednak, Ŝe jest
to jednocześnie wielka okazja dla obu organizacji – najprostszy i najszybszy sposób na wzrost
dojrzałości obu stron. Dla organizacji mniej dojrzałej – szansa na rozwój, dla organizacji bardziej
dojrzałej – szansa sprawdzenia swoich procesów w innym otoczeniu. Nie da się ukryć, Ŝe
współpraca organizacji o wysokim poziomie dojrzałości zwiększa prawdopodobieństwo sukcesu.
Poza tym, co jest optymistycznym przesłaniem tego wystąpienia – organizacje mogą sobie
pomagać w jej wzroście. Trzeba jednak pamiętać, Ŝe poprawa dojrzałości jest procesem, który
wymaga czasu, cierpliwości i wielu kompromisów, a „Quality is not an act, it is a habit.”
(Arystoteles)

Podsumowanie
Dobór prelegentów, osób, które od jakiegoś czasu zmagają się z niełatwą sztuką
usprawniania procesów produkcji oprogramowania, spowodował, Ŝe konferencja obfitowała
w dobre praktyki wyniesione z tych doświadczeń. Prelegenci podsumowywali swoje wystąpienia
analizą sukcesów i poraŜek, popełnionych błędów i zdobytej w ich następstwie nauki. Jako
kluczowe wszyscy wymieniali następujące elementy (nie są uporządkowane według waŜności):
1. Osiągnięcie określonego poziomu dojrzałości nie moŜe być celem samym w sobie. Cele
programu SPI muszą być skorelowane z celami biznesowymi organizacji.
lata) i łączną liczbę godzin spędzonych nad przygotowaniem dokumentacji (310), zakładam, Ŝe miała na myśli liczbę osób
(zaangaŜowanych z róŜnym nakładem pracy), a nie liczbę FTE.

Strona 32 z 37

TESTER.PL
2. Konieczność zaangaŜowania w prace nad programem zarządu, osób decyzyjnych.
Przykład musi iść z góry.
3. Konieczność jak najszybszego wprowadzenia metryk, zbierania danych, które pozwolą na
kaŜdym etapie oceniać jak blisko jesteśmy celu, czy zmierzamy w jego kierunku. WaŜne
jest równieŜ uświadamianie wszystkim, Ŝe celem pomiarów nie jest atak na jednostki.
4. Kluczowym

elementem

jest

komunikacja.

Trzeba

bez

przerwy

przekonywać

pracowników, Ŝe nowy sposób działania jest lepszy i przyniesie mierzalne rezultaty
w przyszłości. NaleŜy na bieŜąco wyjaśniać wszystkie wątpliwości.
5. Jak kaŜdy inny projekt, program SPI wymaga planowania i dyscypliny. Zespół musi
wiedzieć, Ŝe to co robi jest waŜne, a wszystkie jego działania są zaplanowane
i ograniczone ustalonymi z góry terminami.
Na pocieszenie (raczej wątpliwe) dla wszystkich, którzy podjęli walkę w celu zwiększenia
satysfakcji klienta poprzez usprawnienie swoich procesów oraz zarządzanie nimi w sposób
systematyczny i metodyczny, Marek Rydzy z krakowskiej Motoroli przytacza w swojej prezentacji
następujące słowa:

There is nothing more difficult to take in hand, more perilous to conduct, or more
uncertain in its success than to take the lead in the introduction of a new order of things.
(Nicolo Machiavelli, The Prince)
I to jest wyzwanie.

Strona 33 z 37

TESTER.PL

TESTWAREZ
Relacja z konferencji
Lucjan Stapp
TESTWAREZ to krótka, jednodniowa konferencja zorganizowana przez Infovide – Matrix
i IBM Polska przy patronacie merytorycznym naszej organizacji. Na konferencji przedstawiono 5
referatów, tworzących tzw. ścieŜkę główną oraz 3 sesje warsztatowe, tworzące ścieŜkę
warsztatową konferencji.
ŚcieŜkę główną moŜna podzielić na dwie części: w jednej Michał Bugowski z IBM Polska
przedstawił dwa referaty: Platforma IBM Rational oraz Jakość wg IBM Rational. W sumie
prezentowały one całą ofertę zez IBM Rational, wspierających proces testowy: od ideologii IBM
Rational (oczywiście RUP) poprzez narzędzie do zarządzania wymaganiami i zarządzania
procesem testowym (TestManager) do narzędzi testowych (PurifyPlus, Functional Tester,
Performance Tester). W ramach odbywających się równolegle z sesja główną warsztatów moŜna
było te narzędzia zobaczyć i przekonać się samemu, Ŝe tworzą one zintegrowane środowisko
testerskie.
Trzy pozostałe referaty przedstawili:
Jan Sabak (Infovide-Matrix) - Podstawowe narzędzia testera
Szymon Kuliński (Infovide Matrix) – Dynamiczny Generator Danych Testowych
Piotr Ślęzak (SJSI) – Wymagania jako narzędzia testera
W pierwszym referacie Jan Sabak przedstawił pięć podstawowych imperatywów pracy
testera: komunikacja, planowanie testów, dane testowe, przeglądy i automatyzacja. By
zapewnić sobie współpracę słuchaczy, prezenter przygotował drobne upominki (czekoladki) za
prawidłowe zgadywanie, czego dotyczą kolejne punkty jego prezentacji.
Szymon Kuliński zaprezentował narzędzie o nazwie Dynamit – Dynamiczny Generator
Danych Testowych, zaprezentował jego moŜliwości oraz jak współpracuje on z narzędziami IBM
Rational (w tym wypadku Rational Robot).
Piotr Ślęzak w swojej prezentacji Wymagania jako narzędzia testera pokazał jak w miarę
prosty sposób, korzystając z nazrzędzi IBM Rational (głównie Requisite Pro) moŜna sprawnie
zarządzać wymaganiami, śledzić ich zmiany, budować zaleŜności pomiędzy wymaganiami
a testami i – co najwaŜniejsze – śledzić, które testy powinny być moŜe ulec zmianom, gdy
zmieniają się wymagania.
Po zakończeniu konferencji odbyło się bardzo miłe spotkanie integracyjne. Prócz duŜej
ilości jedzenia i piwa organizatorzy zapewnili takŜe dostęp do kręgielni. Spowodowało to, Ŝe ta –
nieformalna cześć konferencji przeciągnęła się do późnych godzin wieczornych.

NaleŜy mieć nadzieję, Ŝe TESTWAREZ będzie kontynuowany w roku 2007.
Strona 34 z 37

TESTER.PL

Spotkanie International Software Testing Qualification
Board w ParyŜu
Joanna Nowakowska
SJSI
3 grudnia 2007 w ParyŜu miało miejsce kolejne spotkanie przedstawicieli organizacji
International Software Testing Qualification Board. Na spotkaniu pojawili się przedstawiciele
wielu krajów z całego świata, m.in. ze Stanów Zjednoczonych, Japonii, Chin, Nowej Zelandii,
Norwegii, Francji, Niemiec, Wielkiej Brytanii, a takŜe z Polski. Stanowisko polskie z ramienia SJSI
reprezentowali Joanna Nowakowska i Wojciech Jaszcz. Spotkanie w zastępstwie prezydenta
ISTQB – Rex’a Black’a poprowadził Erik van Veneendal.

Dyskutowano jak zwykle długo i burzliwie. Dzień rozpoczęto od raportów poszczególnych
working parties, podjęto rozmowę na temat przyszłej konstytucji organizacji ISTQB, która
wreszcie będzie podmiotem prawnym, a skończono na przyjęciu kolejnych organizacji
narodowych (Malezja, Nigeria, Czechy i Słowacja).

Strona 35 z 37

TESTER.PL

Krótkie podsumowanie prac oraz plany dla poszczególnych niektórych roboczych zostały
przedstawione w tabelce poniŜej.
Po spotkaniu SJSI podpisało umowę ze Szwajcarią, Norwegią i
wymiany pytań egzaminacyjnych dla poziomu ISQTB Foundation Level.

Izraelem w kwestii

Od lewej: Thomas Mueller (Swiss Testing Board), Wojciech Jaszcz (SJSI), Hans Schaefer
(Norwegian Testing Board), Yaron Tsubery (Izrael Testing Certification Board)

Strona 36 z 37

TESTER.PL

Zestawienie działalności poszczególnych working parties
Foundation Level
Stan na dziś to zatwierdzony sylabus dla poziomu podstawowego. Do sylabusa parę
organizacji narodowych zgłosiło swoje uwagi, które poddane zostały głosowaniu. Pełna,
nowa wersja sylabusa będzie gotowa pod koniec kwietnia 2007.

Advanced Level (Practitioner)
Powstała pierwsza wersja sylabusa Advanced Level. W grudniu 2006 odbył się pierwszy
przegląd sylabusa, do kwietnia 2007 sylabus zostanie poddany przeglądowi przez członków
Advanced Working Party, i zostanie rozesłany jako draft do dostawców szkoleń. Wydanie
końcowej wersji sylabusa planowane jest na lipiec 2007.

Expert Level
Toczą się prace nad nowym poziomem certyfikacji. Do tej pory zdefiniowano kryteria wejścia
i wyjścia dla robiących certyfikat, toczą się prace nad zakresem certyfikatu.

Expansion Working Group
Cel – obecność 36 krajów w ramach struktur ISTQB niedługo zostanie osiągnięty. ISTQB
pracuje teraz nad rozpoczęciem współpracy z przedstawicielami następujących państw:
Singapur, Węgry, Afryka Południowa, Meksyk, Włochy, Litwa, Pakistan, Sri Lanka, Grecja,
Macedonia

Strona 37 z 37

Tester.pl - Numer 9

More Related Content

Similar to Tester.pl - Numer 9 (20)

More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)

Tester.pl - Numer 9