Plan minimum

Postanowiłem spróbować ponownie uregulować tego bloga...  sformułowałem plan minimum.  Co najmniej 6 wpisów na rok... . Co pokaże rzeczywistość...? To się okaże.

Tak czy inaczej postanowiłem przekreślić zawieszenie co uczyniłem w nagłówku tego bloga.

Pozdrawiam serdecznie wszystkich wytrwałych i przygodnych czytelników.

Czy to już Ameryka czy jeszcze Indie czyli słów kilka o śledzeniu pokrycia testowego.

Artykuł ten oryginalnie pojawił się na stronie microtest.pl. Następnie zwrócił się do mnie portal z testerzy.pl czy nie byłbym zainteresowany ponowną publikacją tego artykułu. Po drobnych zmianach i korektach edytorskich ze strony portalu zdecydowałem się na opublikowanie wersji drugiej tego artykułu zarówno na testerzy.pl jak i na tym blogu.

Projekt informatyczny przypomina trochę – nie będę oryginalny – wyprawę żaglowcem przez morza i oceany. Poza celem podróży, większość rzeczy jest nieznana; pogoda, aktualność map, czego oczekiwać na miejscu, itp. Co najgorsze, nie wiemy po czym poznać, czy to już Indie czy Ameryka. Tak na marginesie dodam, Karol Olgierd Borchardt w znakomitej książce „Znaczy kapitan” kilkakrotnie wyjaśniał przyczyny, dla których na żaglowcach nazwę portu przeznaczenia wpisywało się w dzienniku pokładowym po osiągnięciu tego portu.

Właśnie ten "syndrom wyprawy Kolumba", który chciał dotrzeć do Indii a odkrył Amerykę, należy – moim zdaniem – do największych wyzwań w projektach IT. Dzieje się tak przede wszystkim ze względu na materię. Nie jest ona fizyczna i mierzalna więc jedynym sposobem zweryfikowania, czy jesteśmy w "Indiach" czy w "Ameryce", jest weryfikacja pośrednia.

Wiele jest metodyk umożliwiających weryfikację. W tym miejscu jednak, chciałbym uciec do dyskusji o szkołach i wyższości jednych świąt nad drugimi. Chcę zastanowić się nad uzasadnieniem tezy, że warto jest w testach śledzić pokrycie wymagań oraz zaproponować pewien prosty mechanizm.

Z ogólnie pojętych względów „higienicznych” zakładam, że proces testów jest uruchamiany możliwie najwcześniej. Zakładam też – na użytek tego tekstu –  że sama jakość pokrycia wymagań przypadkami testowymi - ergo jakość testów - zależy zarówno od jakości samych wymagań, jak również od kunsztu testera projektującego przypadki testowe. A więc odbijamy...

Po co nam mapa... to znaczy po co śledzić pokrycie wymagań? Tak naprawdę udało mi się zidentyfikować dwa twarde cele. Pierwszy i zasadniczy to zapewnienie, że komplet wymagań zostanie przetestowany. Jeśli wykonanie testów ma nam dowieść, że oprogramowanie, które otrzymaliśmy, jest tym, które zamawialiśmy, to ta metoda wydaje się jedną z najbardziej rozsądnych.

Drugim celem wynikającym pośrednio z pierwszego jest przygotowanie i zaprojektowanie przypadków testowych. Tutaj skłaniam się do opinii mówiącej, że dopóki faza projektowania testów nie zostaje osadzona w kontekście konkretnych wymagań, dopóty projektowanie przypadków opiera się o ogólne pojęcie na temat "co to ma robić".

Z drugiej strony można pokusić się o tezę, że jeśli wymagania na oprogramowanie wyczerpują istniejące i nowe ale zdefiniowane procesy biznesowe, to testując te procesy jednocześnie weryfikujemy poprawność dostawy. Moim zdaniem sposób ten nie jest lepszy. Procesy biznesowe są czymś żywym, co nie zawsze odzwierciedla pierwotne oczekiwania i założenia.

Przy zderzeniu z oprogramowaniem „obsługującym” ten proces takie zjawiska trudno przyporządkować do kategorii błędów procesu lub oprogramowania.

Rynek oprogramowania komercyjnego, jak również społeczność oprogramowania wolnego, oferuje przeróżne mechanizmy śledzenia pokrycia. Od prostego pliku tekstowego, przez pakiety biurowe typu arkusz kalkulacyjny, po zaawansowane systemy do zarządzania wymaganiami lub testami, aż po wielkie kombajny do zarządzania całymi procesami wytwórczymi.

Czegokolwiek byśmy nie użyli, w początkowej fazie i tak wszystko opiera się na deklaracji człowieka, że dany przypadek testowy pokrywa dane wymaganie. Żaden system informatyczny na świecie nie potrafi odpowiedzieć na to pytanie sam z siebie. Potrafi natomiast ostrzec nas jeśli zmieni się cokolwiek w jednym lub drugim bycie, wpływając na relację między przypadkiem a wymaganiem, co znakomicie ułatwia pracę.

W takiej sytuacji wielokrotnie sprawdziła się matryca przygotowana w arkuszu kalkulacyjnym, którą nazywam RTM, od angielskiego Requirements Traceability Matrix. Zakładając, że wymagania są spisane w jakiejkolwiek formie, proces przygotowania można przedstawić w następujących krokach:

1. Wierne przekopiowanie treści wymagań do drugiej kolumny arkusza. Staram się w tym kroku dzielić wymagania na "atomowe" porcje rokujące szanse na możliwość indywidualnego przetestowania. Staram się także zachować strukturę nagłówków w dokumencie źródłowym.
2. Każdemu wierszowi nadaję unikalny identyfikator umieszczony w pierwszej kolumnie.
3. Oznaczam te wpisy, których nie da się przetestować. Z reguły są to tytuły rozdziałów, opisy otoczenia, itp.
4. Organizuję sobie cykl życia... czyli po prostu robię założenie, że pojedyncze wymaganie może być w jednym ze zdefiniowanych z góry statusów wpisanych do trzeciej kolumny, np.:
   
   - Nie testowalne - opisane powyżej
   
   - Nie pokryte - wymaganie wymaga testowania, ale nie ma żadnego przypadku, który by je pokrywał
   
   - Pokryte - istnieje przynajmniej jeden przypadek testowy, sprawdzający ten konkretny zapis
   
   - Poza zakresem - wymaganie zostało "wyjęte" z zakresu projektu
    
5. Zostawiam miejsce na dane statystyczne.
6. W pierwszym wolnym wierszu wolnej kolumny zaczynam wpisywać identyfikatory przypadków. Na skrzyżowaniu przypadku z wymaganiem stawiam literę:
   
   - "P", oznaczający, iż ten przypadek pokrywa to konkretne wymaganie testem pozytywnym
   
   - „N”, oznaczający, iż ten przypadek pokrywa to konkretne wymaganie testem negatywnym

Przygotowanie, a potem utrzymanie takiego pliku, wymaga pracy i cierpliwości, dlatego nie zawsze przygotowanie takiego dokumentu ma sens. Mi udało się określić kilka uzasadniających zastosowanie RTM okoliczności:

• warto to zrobić na zatwierdzonej i ostatecznej wersji wymagań. Inaczej nieustannie będziemy musieli przerabiać nasz plik, a kontrola "zmian do zmian" jest zawsze trudna
• aby ten mechanizm był adekwatny, musi istnieć oficjalny mechanizm kontroli zmian, dostarczający informacji co i jak się zmieniło na poziomie wymagań
• zdecydowanie nie warto stosować RTM jeśli zakres projektu nie jest szeroki i np. da się go przetestować testami regresyjnymi lub mechanizmem "Test to fail"
• nie istnieje bezpośrednia komunikacja pomiędzy dostawcą i odbiorcą oprogramowania i propagacja zmian wymagań jest powolna

No dobrze, ale skoro stworzenie i utrzymanie takiego pliku jest mozolne, to po co w ogóle robić coś takiego? Pierwsza i oczywista odpowiedź brzmi: "po to, aby określić dokładnie zakres testów, jeśli ten zakres jest mierzony liczbą przypadków testowych". Znajdują tutaj oczywiście zastosowanie przeróżne metody szacowania, jednak założeniem z gatunku "twardych" jest to, że minimalna liczba przypadków testowych jest równa liczbie ponumerowanych unikalnie wymagań w statusach „nie pokryte” i „pokryte”.

Innym oczywistym celem jest kontrolowanie zawartości dostaw. W tym aspekcie przydatność tego mechanizmu jest nieoceniona. Pozwala sprowadzić wszelkie dyskusje o tzw. ograniczeniach technologicznych, projektowych, itp. do twardych konkretów, gdzie podjecie decyzji skojarzone jest z konkretną zmianą i ewentualnym ubytkiem funkcjonalności.

Odseparowanie poszczególnych wymagań ułatwia także wyłowienie tych uwarunkowań, które wymagają testów negatywnych. Testów, które czasami postrzegane są jako nadmiarowe lub zbędne, a które również pozwalają dowieść, że jesteśmy w Indiach a nie w Ameryce.

Konsekwencją pożytków wymienionych powyżej jest ogromne ułatwienie pozwalające kontrolować ekonomię testów, czyli dobrać w efekcie tyle przypadków testowych, ile jest niezbędne do zbadania danego zakresu. Pozwala na bardziej dokładne planowanie.

Inną zaletą rozebrania tekstu wymagań na czynniki pierwsze jest ujawnienie nieścisłości, dwuznaczności lub rozbieżności, które w inny sposób trudniej wychwycić. To z kolei pozwala na przygotowanie wkładu do wymagań od strony jakości. Z tej też przyczyny, uważam, że rozpoczęcie fazy analizy testowej wymagań powinno zacząć się niezwłocznie po ich zatwierdzeniu.

"Światek IT" do znudzenia powtarza tezę, że defekt wcześnie wykryty jest tańszy w naprawie, niż defekt wykryty późno. Śledzenie wymagań także w tym przypadku przychodzi nam z pomocą. Mając informację o tym, co jest pokryte przez przypadki testowe, i które z tych przypadków zostały wykonane z jakim wynikiem - możemy podjąć decyzję, czy dana dostawa spełnia wymagania akceptacji. Jeśli pokrycie jest kiepskie ze względu na zakres lub wyniki wykonania, to łatwo jest dowieść, że nie spełnia ona kryteriów akceptacji. Pozwala to uniknąć zjawiska, które nazywam "eksplozją dostawy", polegającym na „objawieniu się”  dużej liczby defektów o wysokiej ważności na poziomie testów akceptacyjnych będących z reguły testami biznesowymi.

W dzisiejszych czasach coraz częściej liczy się koszty. Także w przypadku procesu śledzenia pokrycia one się pojawiają. Przede wszystkim będzie potrzebny czas projektowy dla przygotowania, realizacji i utrzymania takiej procedury. Dotyczy to również zasobów projektowych.

Jeśli z góry wiemy, że mechanizm RTM nie będzie wykorzystywany w dalszych etapach projektu, należy zaniechać go w ogóle. Przestarzała i nieaktualna informacja o pokryciu może stać się bardziej niebezpieczna niż jej brak. Z drugiej strony, aktualizacja takiej informacji wymaga nieustannego śledzenia zmian pochodzących z wszelkich możliwych źródeł (klient, development, zarząd, kierownik projektu, itp).

Nie oceniłbym śledzenia pokrycia jako procesu istotnego z punktu widzenia projektu, jednak jest niezwykle istotny z punktu widzenia ścieżki testowej. Samo śledzenie nie zapewni nam wysokiej jakości w poszczególnych wydaniach. Należy pamiętać, że śledzenie pokrycia odbywa się na linii rezultat oczekiwany w postaci kodu programu komputerowego a zasięg testów. W żaden sposób nie sięga do sposobu i zakresu implementacji, a tym bardziej do sposobu w jaki przygotowane będą testy.

A więc nadal – chcąc przetestować rozwiązanie – potrzebni nam będą wykwalifikowani testerzy z dostępem do wiedzy i dokumentacji oraz wszelkie narzędzia i metody konstruowania poprawnych testów.

Mechanizm RTM nie przyniesie nam także oszczędności w samym projekcie - przynajmniej na początku. Jednak w fazie wykonania testów pozwala ograniczyć zakres wykonywanych testów do niezbędnego minimum, uwzględniając przy tym testy negatywne.

To może - skoro próba śledzenia pokrycia jest tak mozolna - lepiej zrezygnować z takiej metody? Ta decyzja z pewnością otwiera przed nami inny zestaw możliwości definicji pokrycia, o których tutaj nie będziemy szerzej mówić (np. definiowanie zakresu jako zbioru procesów biznesowych (przydatne na  końcowym etapie ATP), testy "end-to-end" weryfikujące tylko wejście i wyjście, itp.).

Przy takim jednak podejściu mam wrażenie, sama ekonomia testów jest zagrożona ze względu na ryzyko nadmiarowych lub brakujących przypadków testowych.

Śledzenie pokrycia zdaje mi się także odporne na generowanie fałszywych przypadków - oczywiście przy założeniu, że zajmuje się tym zawodowy tester.

Szczególnie groźna jawi mi się w tym aspekcie tendencja do testowania wymagań całościowo. Zdarzało mi się spotykać wymagania, które brzmiały w sposób następujący "Codzienna sprzedaż kontrolowana będzie raportem". Ponadto brakowało jakiejkolwiek wzmianki na temat tego, jakie informacje mają znajdować się w raporcie, z jakich danych ma korzystać ten raport, jakie są stosowane agregacje, itp. Co gorsze, zadając te pytania ludziom odpowiedzialnym za projekt, widziałem po ich reakcji, że nie widzą w braku tych informacji, żadnego powodu do zmartwienia. Taki drobny brak umknął w dyskusji o bardziej istotnych funkcjonalnościach, co jest naturalne.

Rezygnacja ze śledzenia pokrycia przynosi z drugiej strony korzyści takie jak zaoszczędzenie na zasobach i czasie projektu w obrębie danej fazy projektu. Otwartym pozostaje pytanie, co z takimi oszczędnościami dzieje się w następnych częściach projektu.

Rezygnacja ze mechanizmu RTM w żaden sposób nie eliminuje możliwości przetestowania danego rozwiązania, gdyż nadal dysponujemy innymi metodami szacowania zakresu i weryfikowania dostaw.

Jak wspomniałem powyżej, wyzwaniem w tym mechanizmie wydaje się śledzenie zmian do wymagań - wynika to z bezpośredniego przełożenia zmiany na testy. Właściwie odważyłbym sie postawić tezę, że każda zmiana wymagań wymaga ponownej analizy pokrycia w zakresie zmiany. Należy tutaj pamiętać, iż o ile na poziomie wymagań zmiana przestaje być zmianą w chwili jej akceptacji, o tyle na poziomie testów taka zmiana jest zmianą dopóki jej pokrycie nie zostanie przeanalizowane.

Podsumowując ten przydługi wywód, zastosowanie proponowanej metody stanowi świetny pretekst do szczegółowej dyskusji na temat poszczególnych wymagań. Dostarcza świetnego mechanizmu monitorowania zasięgu zmian dokonywanych na poziomie wymagań. A ponad wszystko, stanowi logiczną i mierzalną platformę projektowania przypadków testowych.

World Quality Report 2012-2013

Capgemini, HP i Sogeti - ci od "Test Process Improvement Model" - opublikowali "World Quality Report" dostępny na stronach Capgemini.

W tej samej sekcji "Insights & Resources", można znaleźć także wiele innych ciekawych publikacji na temat jakości.

howtotest.it

Jak sugeruje podtytuł tego bloga, w zawodach - cytując klasyka - "gołe klaty ninja solo" z czasem niestety przegrałem. Ostatnio zwrócił się do mnie twórca HowToTestIT z propozycją współpracy w ramach tego portalu. Pomyślałem, że skoro nie mam czasu samemu pisać na tyle aby miało to jakąś ciągłość i oferowało czytelnikom atrakcyjność, może połączenie sił przyniesie spodziewany efekt. Od czasu do czasu na „łamach” (?) czy też stronach HowToTestIT będzie można znaleźć moje wynurzenia na temat kontroli jakości w IT.

Statystyki z bloga wskazują, ze są jeszcze cierpliwi ludzie sprawdzający od czasu do czasu czy coś się zmieniło tutaj. Chciałem im bardzo podziękować i zaprosić na HowToTestIT.

rzemiosło / umiejętność / sztuka

Taka myśl mi przyszła do głowy:

Testowanie jest rzemiosłem mówiącym jak definiować rezultaty oczekiwane. Jest umiejętnością generowania rezultatów bieżących z wykorzystaniem testowanego rozwiązania. Jest także sztuką interpretacji obydwu tych wartości w kontekście projektu rozwiązania.

Jeśli ktoś, gdzieś to już wcześniej widział to bardzo będę wdzięczny za wskazanie.

wszyscy znaczy nikt

Powszechny jest nasz autostereotyp, że wszyscy znają się na polityce i medycynie. Nie jestem do końca przekonany czy tylko stereotypem – a nie faktem – jest przeświadczenie światka IT, że wszyscy znają się na testach i testowaniu. Z drugiej strony mojej doświadczenie z różnych projektów podpowiada mi nieustannie pytanie „Skoro tylu się zna to dlaczego tak niewielu potrafi to zrobić poprawnie!?”. I bynajmniej mam tutaj na myśli zarówno aspekt zarządzania, projektowania jak również implementacji testów.

Na pierwszy rzut oka odpowiedź na to pytanie wydaje się prosta; „bo testy to taki bufor czasowy”, „bo testy to dobra praktyka, ale rzeczywistość wymusza co innego”, itd. Z mojego punktu widzenia wygląda to trochę inaczej.

Testowanie z punktu widzenia zarządzania jest to sport dla spadochroniarzy. Z punktu widzenia zaś projektowania i implementacji (wykonanie) jest to dyscyplina przeznaczona dla jednostek specjalnych gdzie liczy się wytrwałość, dokładność szczegółowość oraz doskonałe rozpoznanie terenu.

Mówiąc spadochroniarstwo mam na myśli fakt, że zaplanowanie testów jest możliwe w pełni, kiedy mamy specyfikację lub wymagania zamknięte na jakimś zasadniczym etapie oraz harmonogram całego projektu.

Praktyka, z którą się spotykam w nielicznych przypadkach pozostawia jakikolwiek wpływ kierownikowi testów na termin ostateczny projektu. Jest to jedno z zasadniczych ograniczeń powodujących, że musi on szukać czasu w fazach wcześniejszych a więc musi sobie zapewnić wpływ na kolejność realizacji poszczególnych etapów projektu. Bez wpływu na etapy realizacji lub termin oddania do produkcji jedyne, co pozostaje to maksymalne wykorzystanie dostępnego czasu co oznacza potrzebę zwiększenia ekonomiczności testów (ścisła kontrola nakładów testowych względem testowanego obszaru czyli mówiąc trywialnie mało przypadków testowych testujących możliwie dużo). W tym punkcie związane jest to bezpośrednio z projektowaniem przypadków testowych, o czym pisywałem już wcześniej.

W kwestii projektowania i implementacji ważne jest poznanie produktu, przeanalizowanie jego ekstremów oraz podjęcie decyzji (bardzo często biznesowej) o tym co będzie testowane a co nie. Tak czy siak, testowaną aplikację trzeba atakować systematycznie, ale nigdy metodą szerokiego natarcia. Mnóstwo informacji na ten temat można znaleźć w Internecie i prawie zawsze będą to warstwy interfejsów lub całych przepływów.

Niestety większość kierowników projektów zdaje się nie dostrzegać tej ścisłej relacji czas/kwalifikacje zespołu testów odpychając to argumentem „też kiedyś testowałem”. I rzeczywiście, prawdopodobnie jest to prawdą jednak dłuższy czy krótszy angaż w zespole testów nie stanowi o tym, że jest się testerem lub nie. Znam testerów pracujących jako programiści, integratorzy, architekci a znam też testerów którzy tylko pracują w tym zawodzie.

Przyczyną, dla której użyłem powyżej porównań do wojskowości jest fakt, że testy zdają się „wybuchać” raz po raz. Na początku dla kierownika projektu ważne jest, aby po prostu zrealizować projekt. Walcząc z podstawowymi problemami w projekcie nikt nie zastanawia się nad jakością projektu. Ale nagle, kiedy data finalna projektu jest blisko a sam produkt dobrze rokuje pojawia się problem testowania. „Ktoś przecież musi to przetestować” i tutaj następuje festiwal pomysłów, w którym prym wiedzie kompletna ślepota na ograniczenia czasowe. Ci sami kierownicy projektów którzy z troską pochylali się nad zaplanowaniem poszczególnych zadań w projekcie nagle w stosunku do testów szerokim gestem stosują „czasopodwajacz” i „czasowstrzymywacz” niczym detektyw As oranżadę w „Hydrozagadce”.

W takim ujęciu istotne jest, aby kierownik testów nie tylko pełnił swoją explicite opisaną rolę, lecz również niczym niewolnik powtarzający do swojego wodza „Hominem te memento” powtarzał kierownikowi testów „Testy to też czas i ludzie”.

Reasumując mam wrażenie, że coraz częściej kierownicy testów zmuszani są do walki o uznanie, iż testy są integralnym etapem projektu.

Letarg

Ponieważ czuję się zobowiązany wobec cierpliwych i wytrwałych czytelników jak również tych zaglądających tutaj przypadkowo, muszę jasno i jednoznacznie stwierdzić, że obowiązki rodzinne i zawodowe uniemożliwiają mi regularne prowadzenie tego blogu, czego dowodem jest ostatnie kilka miesięcy. Nie oznacza to jednak, że nie będę tutaj pisywał. Od czasu do czasu, zapewne coś napiszę...

Serdecznie dziękuję tym wszystkim, którzy mieli siłę i cierpliwość czytać teksty umieszczane tutaj jak również je komentować. Wszystkim życzę powodzenia i ciekawych projektów.

Wartści graniczne - przegląd

Na http://www.stsc.hill.af.mil/crosstalk/2008/04/0804Coe.html znalazłem ciekawy artykuł na temat techniki testowania wartościami granicznymi. Jest to przegląd zarówno samej techniki jak i sposobów w jaki można ja stosować.

Kiedy nie przestać testować...

Kilka tygodni temu... w związku z Nowym Rokiem, tradycyjnie już postanowiłem rzucić palenie. Decyzja trudna i bolesna gdyż palić lubię nadal i sprawia mi to dużą przyjemność... ale jak to mówią albo rybka albo ...

Tak więc zaparłem się i trzymam... podszedłem do tego trochę jak do testów wydajności; "ile wytrzymam bez palenia". Ale oczywiście pojawił się problem oczekiwanych rezultatów lub wskaźników wydajności. Czyli mówiąc, krótko "w którym momencie mogę stwierdzić, że rzuciłem palenie"!?

Jeśli odpowiedzią jest, fakt iż już nigdy nie zapalę, to czy gdy zdarzy mi się po 20 latach zapalić dla towarzystwa 1 papierosa oznaczać to będzie, że w ogóle nie rzuciłem?

A może podejść do tego relatywnie... "tak naprawdę rzucę palenie, kiedy przestanę liczyć ile czasu już nie palę"... ale czy wtedy znaczy, że mogę zapalić...

Wesołych Świąt i szczęśliwego Nowego Roku

Wszystkim tym, którzy mają cierpliwość czytać tego bloga - bez względu na to czy się ze mną zgadzają czy nie - życzę wszystkiego najlepszego, dużo radości, ciekawych prezentów i miłych chwil.

A na nadchodzący 2008 rok, pełnej dokumentacji :-), ciekawych defektów oraz przede wszystkim zdrowia.

Wszystkiego najlepszego.