TESTER.PL

Strona 2 z 37

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

conferences.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:

TESTER.PL

Strona 3 z 37

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

TESTER.PL

Strona 4 z 37

CONQUEST 2007 – This year with EuroSPI 2

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 in Software Technology, CONQUEST, is going to be “business processes engineering (BPE)”. The European Systems & Software Process Improvement and Innovation, EuroSPI2, is going to put emphasis on “Success Factors with SPI in a Global Competitive Environment - New Research, Methods and Experiences”.

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:

TESTER.PL

Strona 5 z 37

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 high-quality 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.

TESTER.PL

Strona 6 z 37

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

TESTER.PL

Strona 7 z 37

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.

TESTER.PL

Strona 8 z 37

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.

TESTER.PL

Strona 9 z 37

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

TESTER.PL

Strona 10 z 37

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.

TESTER.PL

Strona 11 z 37

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,

TESTER.PL

Strona 12 z 37

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

wydaniu oprogramowania, w danym okresie2).

Aby przybliŜyć zastosowanie tej metryki, posłuŜę się przykładem (po modyfikacjach)

z opracowania [3]:

Faza, w której popełniono błąd

Faza, w której wykryto błąd Analiza Projekt Kodowanie RAZEM

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%

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

TESTER.PL

Strona 13 z 37

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 Po wdroŜeniu

DD

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.

TESTER.PL

Strona 14 z 37

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

TESTER.PL

Strona 15 z 37

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:

TESTER.PL

Strona 16 z 37

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.

TESTER.PL

Strona 17 z 37

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)

TESTER.PL

Strona 18 z 37

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

TESTER.PL

Strona 19 z 37

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.

TESTER.PL

Strona 20 z 37

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

TESTER.PL

Strona 21 z 37

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

TESTER.PL

Strona 22 z 37

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

TESTER.PL

Strona 23 z 37

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

TESTER.PL

Strona 24 z 37

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

TESTER.PL

Strona 25 z 37

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.

TESTER.PL

Strona 26 z 37

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

TESTER.PL

Strona 27 z 37

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

TESTER.PL

Strona 28 z 37

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

TESTER.PL

Strona 29 z 37

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.

TESTER.PL

Strona 30 z 37

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,

TESTER.PL

Strona 31 z 37

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

6 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

TESTER.PL

Strona 32 z 37

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.

TESTER.PL

Strona 33 z 37

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.

TESTER.PL

Strona 34 z 37

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.

TESTER.PL

Strona 35 z 37

Spotkanie International Software Testing Qualificat ion 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).

TESTER.PL

Strona 36 z 37

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 Izraelem w kwestii wymiany pytań egzaminacyjnych dla poziomu ISQTB Foundation Level.

Od lewej: Thomas Mueller (Swiss Testing Board), Wojciech Jaszcz (SJSI), Hans Schaefer

(Norwegian Testing Board), Yaron Tsubery (Izrael Testing Certification Board)

TESTER.PL

Strona 37 z 37

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