Wróćmy do podmiejskiego lasu. Doświadczony grzybiarz szuka grzybów tam, gdzie zwykle rosną, ale niekoniecznie tam, gdzie będzie ich szukać nasza Nadzwyczajna Komisja. Jeśli członkowie Komisji są łagodnymi, leniwymi grubasami, zadowolą się pobieżnym sprawdzeniem bezpośredniej okolicy wygodnych ścieżek i tam właśnie - wbrew instynktowi grzybiarza - trzeba przeszukać teren szczególnie starannie. Jeśli w skład Komisji wchodzą ambitne, młode wilki, będą się starać wykazać szukając w nietypowych miejscach - niechże więc grzybiarze strwożonego Naczelnika Jednostki na wszelki wypadek przepatrzą miejsca pod kamieniami, wśród gęstych krzaków czy w innych miejscach, dokąd podejrzewamy, że chętnie skierują się młode wilki.

Przenosząc się na chwilę z powrotem w dziedzinę oceny jakości aplikacji, należy oceniać przede wszystkim to, czym najczęściej posługują się użytkownicy końcowi. Skoro nie ma się do dyspozycji dostatecznie dużo czasu, aby ocenić wszystko, warto skoncentrować się na obszarach, gdzie - z racji intensywnego użytkowania - prawdopodobieństwo awarii, jeśli są tam błędy - jest najwyższe. Dzięki temu jakość aplikacji - mierzona średnim czasem między awariami - będzie wyższa, oczywiście przy założeniu, że znalezione podczas oceniania błędy będą też usuwane.

Grzyb grzybowi nierówny. Doniesiono Naczelnikowi Jednostki, że Komisja jest szczególnie uczulona na muchomory sromotnikowe, pewnie ze względu na ich kształt. Dlatego Naczelnik uczula swoich grzybiarzy, aby szukali - wbrew swoim naturalnym, grzybiarskim instynktom - właśnie sromotników. Tak samo przy szybkiej ocenie jakości aplikacji koncentrujemy się na tych błędach, których skutki z punktu widzenia użytkowników są szczególnie złe, a mniej czasu poświęcamy błędom, o których wiadomo, że - jeśli nawet gdzieś są - nie będą dla użytkowników zbyt dotkliwe.

W środku lasu jest ostaniec - pionowa, kilkunastometrowa skała. Może na jej szczycie też rosną jakieś grzyby, a któryś z członków Komisji uprawia sporty ekstremalne i tam się wdrapie? Może, ale z drugiej strony, spenetrowanie wierzchołka skały wymagałoby drabin, straży pożarnej, kto wie, czy nie helikoptera, co pochłonęłoby znaczną część środków przeznaczonych na szybką ocenę jakości lasu, przez co gorzej zostałyby spenetrowane jego łatwiej dostępne rejony. W tej sytuacji chyba rozsądniej jednak będzie zostawić w spokoju skałę. Tłumaczyć się potem, że w lesie wprawdzie jest pełno grzybów, ale za to wolny jest od nich trudnodostępny ostaniec - to nie będzie brzmiało dobrze.

Stąd wypływa kolejny wniosek dla oceniania jakości aplikacji - jeśli mamy ograniczone zasoby, a słowo "szybko" oznacza, że brakuje nam najcenniejszego z nich, czyli czasu - wtedy uwzględnić trzeba, na ile trudne i kosztowne są pewne testy, tak żeby dostępne środki rozdysponować raczej równomiernie, a nie tylko w jednym, szczególnie zasobochłonnym obszarze.

Testowanie uwzględniające ryzyko

Powyższe rozważania są streszczeniem podejścia, zwanego jako testowanie uwzględniające ryzyko (risk-based testing). Jeśli jakość musimy ocenić szybko, testujemy (oceniamy, mierzymy) przede wszystkim to, co najważniejsze, uwzględniając cztery kluczowe parametry:

• prawdopodobieństwo błędu (szkoda czasu, aby szukać błędów, tam gdzie być może ich nie ma);

• konsekwencje awarii (przy ocenie jakości należy szukać raczej awarii katastrofalnych, niż niegroźnych, kosmetycznych);

• prawdopodobieństwo zastosowania (trafniej ocenimy jakość, oceniając przede wszystkim to, czym użytkownicy posługują się na co dzień, niż to, z czego korzystają raz do roku lub wcale);

• łatwość testowania (przy szybkiej ocenie warto też wziąć po uwagę, by - o ile nie chodzi o awarie katastrofalne - raczej unikać wikłania się w próby oceny tego, czego pomiar jest zbyt kosztowny i czasochłonny).

Jakie to łatwe

Warum einfach? Kompliziert geht es auch! - powiadają jakoby nasi zachodni sąsiedzi. Popełniam zdaje się błąd, przedstawiając łatwo zrozumiałą przypowieść o grzybach zamiast epatowania licznymi skomplikowanymi nazwami i trzyliterowymi skrótami. Przeczytawszy wstępną wersję artykułu, ktoś powiedział "to całe testowanie jest w gruncie rzeczy bardzo proste". Owszem - jeśli wiemy, gdzie rosną grzyby (znamy się dobrze na informatyce, na testowaniu i na projektach informatycznych), jeśli znamy dziedzinę zastosowania (ocena częstości zastosowania oraz konsekwencji awarii) oraz technologię testów (ocena łatwości testowania). Przydaje się też niezła znajomość technik pomiaru oraz analizy ich wyników, trochę statystyki... POZA TYM cała reszta to rzeczywiście odrobina zdrowego rozsądku.

Bilet do Davos

Całe kosze usuniętych z lasu grzybów wywieziono daleko - czy można Inspekcji wyczekiwać spokojnie? Czy może mimo wszystko lepiej zarezerwować dla siebie i rodziny miejsca w samolocie do Szwajcarii i skromny apartament w Davos, na wypadek gdyby Nadzwyczajna Komisja jakiś duży grzyb jednak wykryła?

Trudno powiedzieć - testowanie uwzględniające ryzyko pozwala skutecznie znajdować błędy, nawet w pośpiechu dość trafnie ocenić jakość aplikacji, ale nigdy nie wie się, na ile jest ono dokładne: czy czasem - mimo starań - jakaś funkcja nie została pominięta, jakaś część systemu zapomniana? Żeby tę pewność uzyskać, należałoby - wróćmy do historii o lesie - wziąć dokładną mapę lasu, podzielić ją na kwadraty i cały las systematycznie przeczesać. Wprawdzie wiele z miejsc zidentyfikowanych tym sposobem byłoby zupełnie bezsensownych, na przykład plaża, gdzie jako żywo grzyby nie rosną, lub środek bagna, gdzie komisja nigdy nie dotrze, ale jest to koszt systematyczności, cena za ubezpieczenie od skutków przeoczenia lub zapomnienia.

W odniesieniu do oceny jakości aplikacji odpowiednikiem mapy jest model działania lub struktury aplikacji, a odpowiednikiem dzielenia mapy na kwadraty - projektowanie testów z modelu za pomocą algorytmu. To jest konieczne, aby móc ocenić tak zwane pokrycie testowe, a więc oszacować niezawodność wykonanych ocen, ale na to przy ocenie szybkiej nie mamy zwykle czasu. Jedno jest więc pewne - ocena szybka jest zawsze mniej pewna niż ocena spokojna, oczywiście pod warunkiem staranności jednakowej w obu wypadkach.

Jak śpieszyć się powoli

Śpiesząc się, nie trzeba rezygnować z myślenia. Nie chodzi przecież o to, by wykonywać mnóstwo szybkich, nerwowych ruchów, głośno krzyczeć przez kilka na raz telefonów i pracować - nieefektywnie - po dwadzieścia godzin na dobę tylko po to, by mimo pośpiechu pozostać skutecznym i skoncentrowanym na celu.

Pogodzić pośpiech ze spokojną systematycznością usiłują metodyki "systematycznego testowania w pośpiechu" (tak celnie określił je dr Lucjan Stapp z Politechniki Warszawskiej w swym wystąpieniu na jednym z zebrań Stowarzyszenia Jakości Systemów Informatycznych).

Jedna z nich to testowanie eksploracyjne (exploratory testing): zespół technik wspomagających testerów w sytuacji na pozór beznadziejnej, kiedy jednocześnie trzeba uczyć się aplikacji, wykonywać testy i projektować nowe zadania testowe. Za pomocą wielu kreatywnych sposobów - przydatnych także wówczas, gdy pośpiech nie jest aż tak wielki - projektuje się nowe testy na podstawie obserwacji i analizy wyników testów właśnie wykonywanych. Jednym słowem, podejście eksploracyjne poprawia skuteczność testów, wtedy gdy nie ma czasu, by je starannie zaplanować, tylko trzeba strzałem z biodra szybko ocenić jakość aplikacji.

Częściowo odmienne podejście prezentuje testowanie zwinne (agile testing). Jego podstawa to zasada testowania parami: testerzy pracują w dwuosobowych zespołach, testy wykonują wspólnie. Takie podejście budzi uzasadnione wątpliwości, czy nie jest po prostu dublowaniem kosztów, ale praktyczne doświadczenia sugerują, że faktycznie pozwala na większą skuteczność.

Kilka lat temu głośno było o metodyce programowania ekstremalnego (extreme programming), gdzie programiści pracują w parach, zamieniając się pisaniem kodu i przygotowywaniem (automatycznych) testów dla tworzonego właśnie kodu. Programowanie ekstremalne postuluje ponadto ograniczenie do minimum tradycyjnej, ciężkiej dokumentacji, bliską współpracę programistów z przedstawicielami klienta, częste - nawet kilka razy na dzień - budowanie całego systemu. Z jednej strony programowanie ekstremalne obiecuje wprawdzie mniejszą czasochłonność projektów, czym pasuje do naszego tematu; z drugiej strony - postuluje przygotowywanie testów oceniających jakość jeszcze zanim powstanie kod, co nie do końca już zgadza się z paradygmatem "szybkiej oceny jakości aplikacji".

Wszystkim, którzy szukają cudownych dróg na skróty i sposobów, jak szybko wykonać to, co najlepiej wykonywać spokojnie, dobrze w tym miejscu przypomnieć bajkę o żółwiu i zającu.

Bogdan Bereza-Jarociński jest założycielem i kierownikiem Centrum Jakości Oprogramowania ObbjTest; [email protected] ;http://www.bbjtest.com