To po prostu bzdura!

To po prostu bzdura!
© NewQuality
Wyznania sfrustrowanego trenera jakości
Ludzie przychodzą na zajęcia z testowania oprogramowania, aby nauczyć się czegoś
nowego o tym jak wykonywać swoją pracę testera. Takie nowe umiejętności to albo
metody, techniki lub podejścia, o których nie mieli pojęcia, że istnieją, albo nowe
perspektywy tego, co już właściwie znają, ale o lepszej strukturze, bardziej spójne,
prawdziwsze – a więc bardziej użyteczne.
My, instruktorzy, powinniśmy zrobić to, co w naszej mocy, aby dać im to czego chcą i
czego potrzebują.
Czasem nie mamy pełnej kontroli nad naszym programem nauczania: tak się dzieje
wtedy, kiedy uczymy na kursach akredytowanych, które się odbywać według z góry
określonego programu zajęć.
Jak do tej pory jest nieźle: w mojej opinii, międzynarodowe programy zajęć – czy to
prawdziwie międzynarodowe, jak ISTQB, czy de facto akceptowane na forum
międzynarodowym, jak ISEB – są wspaniałe. Rzeczywiście ich istnienie wymusza
podnoszenie umiejętności testowania na wyższy poziom akredytacja zapewnia
homogeniczne poziomy jakości pomiędzy sprzedawcami szkoleń, i w końcu,
certyfikacja ma także pewną liczbę pozytywnych efektów.
Podczas nauczania, najgorsza rzecz, jaka może się przytrafić, to zobaczyć jak
uczestnicy kursu ziewają. Druga, najgorsza rzecz to zobaczyć rodzaj sennego,
zamglonego spojrzenia w ich oczach, co wskazuje, że to, co tłumaczysz jakoś nie
pasuje do ich ram odniesienia. To spojrzenie może oznaczać dwie rzeczy: ocenę „zbyt
teoretycznie” na twoich arkuszach ocen i, oczywiście, nieumiejętność uczestników
kursu zastosowania ich nowych umiejętności w praktyce.
Pozwólcie mi na szczerość: widziałem to spojrzenie w oczach moich słuchaczy wiele
razy. Niespodzianka! To się zdarza szczególnie często, kiedy tylko próbuję uczyć
czegoś, co po prostu nie jest prawdziwe. A co jest takiego nieprawdziwego w
programie zajęć, zarówno w ISEB jak i ISTQB? Przykro to stwierdzić, ale pewne bardzo
podstawowe rzeczy. To nie jest po prostu prawdą, co oni mówią!
Według ISEB i ISTQB…
…rzeczywistość – w kilku słowach – wygląda następująco.
Strona 1 (9)
Istnieją dwa podstawowe obszary testowania: dynamiczne techniki testowania i
testowanie statyczne (ISEB). ISTQB stoi trochę wyżej, przynajmniej nie musisz
tłumaczyć swoim zdziwionym słuchaczom (których masz, kiedy trzymasz się
programu zajęć ISEB ), że:
•
„dynamiczne” nie koniecznie oznacza „wysoką adrenalinę”;
•
dlaczego dynamiczne testowanie ma swoje techniki a statyczne najwyraźniej ich
nie ma;
•
że „techniki testowania” nie oznaczają technik wykonania testu, lecz wyłącznie
techniki projektowania testu.
W terminologii ISTQB istnieją „techniki statyczne” i „techniki projektowania testu”.
Zdecydowanie ładniejsze nazwy, niemniej jednak możesz ciągle być zmuszony do
zapewniania ludzi, że termin „statyczne techniki” nie oznacza po prostu nie robienia
niczego. Czyściutko, schludnie bloki budowli wpadają ładnie na swoje miejsce:
przeglądy i statyczna analiza, czarna skrzynka i biała skrzynka, podział na klasy
równoważności i analiza wartości granicznych, zgadywanie błędu (ISEB) i techniki
uwzględniające doświadczenie (ISTQB). Ja zdecydowanie wolę terminologię ISEB,
ponieważ zawsze mamy sporo zabawy zgadując czy to w rzeczywistości oznacza
zgadywanie awarii, zgadywanie pomyłki czy naprawdę zgadywanie defektu. W obu
przypadkach, czy to u ISEB czy też u ISTQB, te techniki są schowane na samym dnie
polecenia: opisz OSTATNIĄ spośród technik, co w rzeczywistości oznacza PIERWSZĄ.
Nieźle.
Jednak, kiedy przyjrzysz się lepiej programowi zajęć ISTQB, ten mały zły duszek
powraca: Pod dumną postacią „testowania z uwzględnieniem doświadczenia” ukrywa
się „pisanie przypadków testowych z uwzględnieniem […] wiedzy o […] defektach”.
Ponieważ „defekty” w języku ISTQB są tym samym, co „błędy” w języku ISEB, jakiś
śmielszy uczeń zawsze podniesie swoją małą rączkę i zapyta mnie: „Proszę Pana,
ostatnio projektowałem kilka przypadków testowych opartych na mojej wiedzy o
niepowodzeniach, a nie defektach. Proszę Pana, czy to było źle?”
Zapewniam go, że nie. W ten sposób więcej ośmielonych małych rączek podnosi się
do góry. Lekko onieśmielona dziewczynka pyta: „Proszę pana, kiedyś projektowałam
przypadek testowy w oparciu o moją wiedzę, że stos programu był przechowywany w
rejestrze na mikroprocesorze, i było 256 rejestrów, i kiedy potrzeba było więcej
stosu, został zamieniony w RAM…Proszę Pana, jaki kolor miało to testowanie? Czy to
było być może testowanie bezbarwne, proszę Pana? Bo w przeciwnym wypadku, co
może być bielsze niż białe?”.
Strona 2 (9)
Zanim zdołałem upomnieć ją za zadawanie niewłaściwych pytań, niezbyt bystry
chłopiec wymamrotał: „Co za głupek ze mnie, przepraszam Pana, szczerze,…nie
wiedziałem, że to było źle, zastosowałem partycjonowanie klasy równoważności do
zaprojektowania pewnych przypadków testowych żeby sprawdzić czy moja obsługa
parametru C++ była OK., ale nie widziałem, że to jest niedozwolone ponieważ to była
technika czarnej skrzynki,… naprawdę, będę się starał pamiętać o tym następnym
razem…” Gdyby ta klasa była prowadzona zgodnie z programem ISTQB, mógłbym mu
tylko powiedzieć żeby był bardziej uważny w przyszłości („ niektóre techniki wpadają
wyraźnie do pojedynczej kategorii; inne mają elementy więcej niż jednej kategorii”).
Ale ponieważ było to według ISEB, powiedziałem mu żeby przyprowadził swoich
rodziców do szkoły następnego dnia na rozmowę.
Obawiam się, że trochę mnie poniosło z moją narracją. Na te kursy uczęszczają
dorośli profesjonaliści w dziedzinie testowania i oni nie mówią do mnie „Proszę
Pana”. Na tym etapie, oni przestają być zainteresowani, robią się śpiący,
zdezorientowani, źli, a ja stoję tam przed grupą ludzi tak samo przestraszony ich
znudzeniem (złe arkusze ocen!) i ich złością (jest ich więcej i zazwyczaj są dwa razy
młodsi ode mnie). Ale to, co mnie naprawdę paraliżuje to, to, że zawsze znajdzie się
ktoś kto może mnie spytać: „No cóż, Panie Mądralo, my właściwie nie używamy
żadnej z twoich pięknych technik. Nie zgadujemy żadnych błędów, jakie by nie były,
ponieważ nie jesteśmy czarodziejami, więc nie mamy pojęcia gdzie one mogą być. My
po prostu projektujemy przypadki testowe, które pokryją wymagania naszego
systemu, ale one są czystym tekstem, a nie praktycznymi przypadkami lub
automatami skończonymi. I teraz, niech Pan mi powie Panie Mądralo, jakie my
wykonujemy testowanie?”
Będąc tchórzem, używam starej sztuczki wszystkich tchórzy i próbuję przyłączyć się
do moich dręczycieli i stać się jednym z nich. Dlatego też mamroczę coś o programie
nauczania będącym kompromisem, albo koniecznym uproszczeniem.
Prawdopodobnie, mógłbym odnieść się do potrzeby pewnych zabawnych wyborów,
żeby pytania egzaminacyjne mogły być sformułowane prościej (jeśli to jest kurs ISEB,
całkowita i kompletna bezużyteczność włączenia indeksu McCabe’a do programu
stanowi dla mnie dużą pomoc w osiągnięciu tego celu).
Jednak, nawet tchórze mogą mieć dosyć i zechcą stawić czoła rzeczywistości zamiast
jej unikać. Spójrzmy prawdzie w oczy: zawiłe klasyfikacje obu programów nauczania
obejmują wiele użytecznych faktów i technik, ale one wyjątkowo źle odzwierciedlają
rzeczywistość przemysłu oprogramowania. To nie jest po prostu tak jak oni mówią!
Jak wybiera się przypadki testowe w rzeczywistości?
Tak, testowanie naprawdę uwzględnia ryzyko, nawet, jeśli nienawidzę powtarzania
tego stereotypu. Projektowanie przypadków testowych oznacza wybór stu lub tysiąca
Strona 3 (9)
najważniejszych z 101000 teoretycznie możliwych przypadków. A co naprawdę oznacza
„najważniejszy”?
Kompletny schemat jak podejmować decyzję o ważności możliwych przypadków
testowych znajduje się poniżej na rysunku.
1. Ważność przypadku testowego
2. Testowalność
4. Koszty
i wykonalność
3. Ważność awarii
5. Konsekwencje
awarii
6. Prawdopodobieństwo
awarii
7. Profil
użycia
8. Prawd.
defektu
9. Wiedza
biznesowa
10. Modele
zastosowania
11. Domyślanie się
błędów i defektów
Ilustracja 1 Estymacja wagi testu
A oto wyjaśnienie rysunku, z odniesieniami do numerów węzłów.
Pod warunkiem, że przypadki testowe są w przybliżeniu jednakowo łatwe do
wykonania [2], ważniejsze [1] są te, które stanowią zabezpieczenie przed
ważniejszymi awariami [3], gdzie całe drzewo poniżej [3] wyjaśnia, od czego
naprawdę zależy „ważna awaria”.
Jednak, kiedy awarie mają w przybliżeniu równe znaczenie [3], raczej przedłożysz
przypadki testowe [1], które można łatwiej przetestować [2] nad te, które nie dają
wiarygodnych rezultatów z powodu trudności wykonania lub możliwości
obserwacji[4], albo tych, których wykonanie jest zbyt drogie [5].
Znaczenie awarii [3] jest, tak samo jak w tradycyjnym podejściu, funkcją jej
konsekwencji lub ceny [5] i jej prawdopodobieństwa [6]. W jaki sposób znamy cenę
awarii? No cóż, w zasadzie to nie jest rzecz do testowania, to dotyczy biznesu [9]. Jeśli
ładnie zapytasz, na pewno ci powiedzą, … ale strzeż się, mogą odpłacić się pytając
ciebie, jakie awarie są możliwe. Prawdopodobieństwo awarii[6] jest funkcją
prawdopodobieństwa błędu [8] i prawdopodobieństwa użycia [7] ( zwanego częściej
częstością użycia). Prawdopodobieństwo błędu [8] jest określone przez pewną liczbę
Strona 4 (9)
czynników[11], które są skrzętnie wymienione w wielu książkach na temat
testowania. A propos, „ zgadywanie błędu” (ISEB) czy „zgadywanie defektu” ( ISTQB)
jest po prostu: szacowaniem prawdopodobieństwa błędu [8]. Faktyczne „techniki
uwzględniające doświadczenie” (ISTQB) oznaczałyby estymację całego, powyższego
drzewa: oszacowania wszystkich wartości i sił (kształty funkcji) ich niezależności. Z
jakiegoś powodu, niedającego się zrozumieć, ISTQB wybrał jeden mały listek [11] z
całego drzewa i nazwał go „testowanie uwzględniające doświadczenie”!
Nie mogę się oprzeć pokusie gry słownej: „zgadywanie błędu” wg ISEB, jeżeli
potraktujesz znaczenie słowa „błąd” zgodnie z jego definicją BS 7925-1,
zdecydowanie byłoby częścią faktycznego „zgadywania defektu”. No wiesz, tak jak
zgadywanie czy wszystko jest w porządku z małżeństwem Jane (jeżeli nie jest, to jest
bardziej prawdopodobne, że ona zrobi błąd), itd.
Pozbądźmy się ostatniej części rysunku, o której jeszcze nie wspominałem: żeby
oszacować prawdopodobieństwo użycia [7] potrzebujesz pewnego rodzaju wymyślonego lub opartego na doświadczeniu – modelu użycia dla tej konkretnej
funkcji, dla której obliczasz znaczenie awarii.
Zauważ: rysunek powyżej ( zdecydowanie może potrzebować uzupełnienia o kilka
szczegółów w najniższym poziomie) jest jedyną zasadą, której potrzebujesz, aby
rozmawiać o priorytetyzacji przypadków testowych.Całe pozostałe oratorstwo na
ten temat, tak powszechne do tej pory, nie jest już potrzebne. Po prostu powiedz
swojemu klientowi żeby kupił narzędzie BBN (Bayesian Relief Nets) i rozpoczął
zbieranie danych!
Znajdź w wyszukiwarce co to jest BBN, jeśli tego nie wiesz.
Pełny obraz
Rozwiązanie opisane wcześnie ma jeden mały haczyk w sobie: powinno być
stosowane do „ wybierania stu albo tysiąca najważniejszych przypadków spośród
101000 teoretycznie możliwych”. Jedno takie drzewo jak na Rysunku 1 dla każdego z
nich i wkrótce jesteśmy gotowi!
Dlatego dodatkowe metody wybierania przypadków testowych są konieczne. I oto
nagle nasze dumne drzewo z wszechmocnego i ostatecznego narzędzia do
projektowania testowania zostaje zredukowane – z powodu wagi liczb – do
ostatecznego narzędzia dla dużo bardziej ograniczonego obszaru, mianowicie do
priorytetyzacji tych przypadków testowych, które zostały wybrane w inny sposób.
Wobec tego, w jaki sposób? Są dwa podejścia: intuicyjne i systematyczne. Z jakiegoś
powodu ISEB i ISTQB opisują tylko systematyczne techniki projektowania testów,
odsyłając intuicyjne w zapomnienie ( całkowicie lekceważąc fakt, że ponad 70%
Strona 5 (9)
światowej populacji przypadków testowych jest zaprojektowana przy pomocy
środków intuicyjnych), albo redukując je do maleńkiej partykuły zwanej albo
„zgadywaniem błędu” albo testowaniem z uwzględnieniem doświadczenia”, w
rzeczywistości mając na myśli „oszacowanie prawdopodobieństwa awarii”, co z kolei
jest patetycznie nieadekwatne.
Dla zarówno intuicyjnego jak i systematycznego podejścia istnieją dwie podstawowe
filozofie projektowania testów: czarna skrzynka i biała skrzynka. Zdecydowanie,
czarno-biała skala jest jednakowo ważna dla intuicyjnego jak i systematycznego
podejścia, w przeciwieństwie do wrażenia, jakie odnosisz z programów nauczania
ISEB/ISTQB, w których taki podział występuje tylko w technikach systematycznych.
Zauważ również, że czarne- białe jest zaledwie dwuwartościową dyskretną skalą, jak
to jest często prezentowane. To jest raczej skala, która rozpoczyna się od 100% czerni
(coś się kryje za tą ścianą, co daje odpowiedzi na twoje pytania, a ty nie wiesz lub jest
ci wszystko jedno czy to istota ludzka czy komputer) do 100% bieli projektujesz
przypadki testowe biorąc pod uwagę poziom elektronicznego wejścia), poprzez różne
odcienie szarości.
W każdym razie, poprawna (nieco uproszczona) macierz podejścia/filozofii
testowania wygląda jak na poniższym rysunku:
Systematyczne
Intuicyjne
Czarnej
skrzynki
Białej
skrzynki
Ilustracja 2 Klasyfikacja metod projektowania testów
Strzałki na slajdzie symbolizują fakt, że nie ma technik czysto czarno-skrzynkowych i
czysto biało-skrzynkowych, lecz jest to pewne kontinuum. Podobnie rzecz ma się z
kontinuum na skali intuicyjne – formalne.
To nie jest koniec historii. W przeciwieństwie (znowu) do tego, co udaje program
nauczania, nie ma żadnego pojęciowego kanionu pomiędzy statycznym i
Strona 6 (9)
dynamicznym testowaniem. Nazywanie ”przeglądu” techniką statyczną jest tym
samym, co nazywanie „wykonania testu” techniką dynamiczną. Bez wątpienia projekt
przypadku testowego jest wymagany nawet w testowaniu statycznym, chociaż
oczywiście to, co tworzy ważny przypadek testowy, różni się. W testowaniu
statycznym, tak samo jak w dynamicznym, musisz najpierw przejść przez etap
projektowania testu – na przykład, decydując wystarczająco szczegółowo, co
przeglądać i jak – przed wykonaniem faktycznego przeglądu.
Dlatego też, ostateczny, kompletny i pozbawiony jakichś sztucznych granic, zestaw
klas projektów testów jest trójwymiarowy, składający się z ośmiu elementów, jak
pokazano na rys.2.
static
systematic
black-box
dynamic
systematic
black-box
static
intuitive
black-box
dynamic
intuitive
black-box
static
systematic
white-box
dynamic
systematic
white-box
static
intuitive
white-box
dynamic
intuitive
white-box
Ilustracja 3 Pełna klasyfikacja metod projektowania i wykonywania testów
Zauważ, że słowa „techniki testowania” nie zostało jeszcze wypowiedziane, ponieważ
prawdziwym zagadnieniem są klasy projektu testu, których jest około ośmiu (…około,
ponieważ, jak wspomniałem uprzednio, w rzeczywistości jest więcej niż tylko dwie
wartości na czarno-białej skali).
Przyczyna, dla której ISEB/ISTQB kładą nacisk na techniki testowania ma oczywiście
charakter dydaktyczny: zasadniczym celem podstawowego kursu testowania jest
nauczenie testerów technik projektowania testów, które będą potrafili zastosować w
tym, w co najczęściej stosują, tj. w testowaniu dynamicznym. Jednakże, nie ma
powodu, żeby konstruować całą fałszywą, koncepcyjną strukturę, aby osiągnąć ten
praktyczny cel! Poza tym, praktyka i zdrowy rozsądek są i tak złożone na ołtarzu…
trudno powiedzieć, czego, ponieważ techniki intuicyjne, z którymi większość testerów
pracuje na co dzień, są całkowicie odrzucone. Znów, można domyśleć się, jakie
racjonalne uzasadnienie się za tym kryje: i tak wszystkie projekty testują intuicyjnie,
ale w wielu z nich brakuje zastosowania niektórych, rozsądnych technik
Strona 7 (9)
systematycznych. I znowu, to racjonalne uzasadnienie jest wątpliwe: nie ma potrzeby
budowania modelu, który nie jest prawdziwy w porównaniu z rzeczywistością, aby
osiągnąć bardziej rozpowszechnione zastosowanie systematycznych technik
testowania. I ostatni, choć nie najmniej ważny wniosek: testowanie intuicyjne
również potrzebuje ulepszenia, tak, więc dlaczego zaniedbywać je zupełnie?
W końcu: przykład
Zobaczmy jak model przedstawiony na rys.3 działa w prawdziwych technikach
projektowania testowania. Weźmy trzy techniki: (1) testowanie stanu przejścia, (2)
testowanie z uwzględnieniem doświadczenia z przeszłości, związanego z rozkładem
błędów podobnego systemu i (3) testowanie oparte na instrukcji albo innym pokryciu
kodu.
Przejście staanu
Doświadczenie
Pokrycie kodu
Obszar najbardziej
powszechnego użycia
Nie do zastosowania
Sprawdzenie czy
używane są wszystkie
metody (ale nie, czy
wszystkie kody
wewnątrz metod). OK.,
to jest szare, a nie
zdecydowanie czarne
Dynamiczna
systematyczna biała
skrzynka
Np. testowanie
obiektu w pewnej
liczbie stanów
Nie do zastosowania
Obszar najbardziej
powszechnego użycia
Dynamiczna
intuicyjna czarna
skrzynka
Nie do zastosowania
Podobne raporty
były złe w przeszłości
Nie do zastosowania
Nie do zastosowania
Znalezienie błędu w
podobnym,
sortującym
algorytmie zabrało
nam 3 dni
Nie do zastosowania
Dynamiczna
systematyczna
czarna skrzynka
Dynamiczna
intuicyjna biała
skrzynka
Statyczna
systematyczna
czarna skrzynka
Projektowanie state
machine do
weryfikacji
napisanych wymagań
Strona 8 (9)
Inspekcja kodu, aby
upewnić się, że będące
w przygotowaniu
środowisko testowe
będzie w stanie
przywołać wszystkie
stany; znowuto jest
szare, a nie
zdecydowanie czarne.
Statyczna
systematyczna biała
skrzynka
Statyczna intuicyjna
czarna skrzynka
Projektowanie state
machine do
weryfikacji opisu
funkcji niższego
szczebla
Inspekcja kodu, aby
zmierzyć możliwe
pokrycie trudnej do
wykonania części kodu.
Nie do zastosowania
W tym obszarze
wymagania
użytkownika były
bardzo mgliste
Nie do zastosowania
Nie do zastosowania
Spójrz, ten facet
używa trampoliny
zamiast ponownego
przywołania
właściwej funkcji!
Nie do zastosowania
Statyczna intuicyjna
biała skrzynka
Tabela 1 Przykłady testów wg powyższej klasyfikacji
To działa! I jesteśmy dumni z dokonania małego odkrycia, nawet, jeżeli jest dość
oczywiste (chociaż jakoś odmienne od programu nauczania ISEB/ISTQB): oczywiście
nie ma „czarnych” technik czy „białych” technik, ale są techniki systematyczne albo
intuicyjne. Jakaś technika nie może być jednocześnie niesystematyczna i
systematyczna.
Miejmy nadzieję, że ten artykuł nie będzie przeszkodą w żadnej przyszłej akredytacji
dla mojej firmy1.
1
Nie było - 2008
Strona 9 (9)