Ciąg Fibonacciego a klasy równoważności

Parę dni temu przyszło mi do głowy pytanie czy ciąg Fibonacciego jest dyskretną czy ciągłą klasą równoważności? Jeśli potraktujemy do dosłownie to jest dyskretną klasą równoważności. Ale jeżeli jako jednostkę w tym ciągu zdefiniujemy dynamicznie wynik obliczenia kolejnej wartości to czy otrzymamy wtedy klasę ciągłą...?

Testowalność - lista kontrolna

Testowalność (testability) jest dosyć dziwnym pojęciem oznaczającym generalnie łatwość bycia testowanym. Jeśli ktoś jest zainteresowany, tutaj znajduje się lista rzeczy które ułatwiają testowanie.

Czy czarna skrzynka jest taka czarna?

Czy rzeczywiście czarna skrzynka jest taka czarna? Określenie "czarna skrzynka" jest używane jako metafora testów nie wymagających znajomości wewnętrznych struktur i konstrukcji oprogramowania. Kompetencja czytania i rozumienia kodu nie jest potrzebna.

Założenie jest następujące: wystarczy mieć wymagania klienta, skonstruować na tej podstawie przypadki testowe, sformułować oczekiwane rezultaty i na końcu porównać wyniki testu ze zdefiniowanymi rezultatami.

Tutaj pojawia się moja wątpliwość... Ponieważ testowanie wszystkich przypadków jest niemożliwe, korzystamy z różnych technik celem ograniczenia ich liczby do rozsądnych rozmiarów. Jedną z takich technik jest "klasa równoważności", ale równie dobrze może być tutaj podstawiona każda inna.

Przy stosowaniu klas równoważności (generalizując pewne zbiory parametrów), automatycznie zakładamy (na jakiej podstawie?), że kod jest zaimplementowany zgodnie z założeniami tzw. "dobrych praktyk"...

A co jeśli nie? A co jeśli kod jest pisany przez programistę, który nie ma doświadczenia lub inaczej niż my rozumie to wymaganie? Prawdopodobieństwo popełnienia błędu jest bardzo duże, tak samo jak prawdopodobieństwo, że utworzony w tym miejscu defekt nie zostanie wykryty.

W tej sytuacji istnieją dwie możliwości:

• dopisujemy dodatkowe przypadki testowe
• zaglądamy do kodu

Pierwszy punkt zdaje się być bardzo atrakcyjny. Ale jest niezgodny z "tao" projektowania przypadków testowych!? Przecież po to zastosowaliśmy np. "klasy równoważności" aby zredukować liczbę przypadków. A teraz, ponieważ zastosowaliśmy klasy równoważności, musimy zwiększyć liczbę przypadków!? Absurd!

Drugi przypadek także eliminuje czarną skrzynkę, bo przecież zaglądamy do kodu. Ale uważam, że to podejście jest lepsze!

Na przykład:
Programista implementując zestaw wymagań obmyślił sobie, że jego podstawowym bytem będą szklanki. Z góry było wiadomo, że oprócz szklanek potrzebne będą także słoiki i dzbanki. Ale nasz inżynier sobie pomyślał: >>przecież słoiki i dzbanki to to samo co szklanka (służą do przechowywania cieczy) tylko inaczej skonfigurowane. Tak więc słoik i dzbanek to po prostu specjalne przypadki szklanki<<. Niestety... zespół testowy - ze względu na zupełnie inną obsługę dzbanków, inną obsługę szklanek i inną obsługę słoików - potraktował to jako zupełnie osobne byty. Testy zakończyły się pomyślnie a defekty pojawiły się dopiero w produkcji. Gdyby zespól testowy miał świadomość tego jak wygląda implementacja kodu, testy zostałyby dobrze skrojone.

Po pierwsze znając kod wiemy jak go "otestować" przypadkami, po drugie rozumiemy nie tylko jak program ma działać ale także jak działa przez co jesteśmy w stanie identyfikować łatwiej źródła defektów.

Oczywiście wadą jest fakt, iż czasami dostęp do kodu nic nie da bo ze względu na "włoski makaron" lub rozproszenie źródeł, zrozumienie go zajmie więcej czasu niż czas potrzebny na "czarną skrzynkę" plus dodatki. W takim wypadku jednak można zorganizować spotkanie z szefem architektów aby wyjaśnił zamierzenia architektoniczne oraz spotkanie z szefem programistów aby wyjaśnił jak te zamierzenia zostały zaimplementowane.

Przyszłość testów wg. Bacha

Niedawno na amerykańskich stronach "Dr. Dobb's Portal" z cyklu "The book of testing" w ramach bloga Michaela Huntera pojawił się wywiad zatytułowany "Five Questions With James Bach".

W tym krótkim tekście "ojciec założyciel" testów eksploracyjnych zawiera wiele zdań, które mogą być szokujące ale jednocześnie spójne z koncepcją metodyk lekkich. Np. na pytanie co jest najbardziej zaskakujące w testowaniu odpowiada

"[...] zaskakuje mnie, iż prawie cały światek testowy bezwarunkowo akceptuje fakt, iż większość testów powinna być spisana w formie procedury."

Dodając wcześniej - muszę przyznać dosyć trywialnie - że:

"[...] testowanie głównie jest procesem myślenia i wyobrażania sobie [...]"

Jako swoją najcenniejszą lekcję, Bach wspomina defekt - znaleziony przez niego w jego własnym programie - który poprzez nieprawidłową obsługę pamięci powodował przesunięcie wyświetlanej grafiki w prawo. Defekt, zignorowany przez niego na początku, okazał się lekcją trącącą trochę filozofią Georgea Berkeleya, że wszystko jest wrażeniem. Sam Bach streszcza ją w następujący sposób:

"[...] relacja pomiędzy przyczyną i skutkiem w komputerze może być do tego stopnia pogmatwana i skomplikowana, że nigdy nie możemy być pewni, że wiemy na co patrzymy kiedy obserwujemy uruchomiony program."

Zdanie to wydaje mi się bardzo znamienne w dzisiejszych czasach, kiedy coraz częściej zaczyna liczyć się czas dostarczenia produktu na rynek a nie jego jakość, kiedy najczęstszym kryterium wypuszczenia oprogramowania nie są nomen omen inżynierskie kryteria ale po prostu polecenie zarządu. W kontekście tego stwierdzenia może się okazać, że zaczną pojawiać się na rynku produkty-zombie. Produkty, które w zamierzeniach producentów miały być ulepszone jak tylko "zdobędą" rynek, a nie da się ich ulepszyć ze względu na tą niepewność, omyłkowo wziętą przez zarząd za pewność i w rzeczywistości objawiającą się jako defekt krytyczny.

Dla polskiego czytelnika - gdzie tak naprawdę standaryzacja branży rodzi się dopiero w bólach - szczególnie interesujące może być zdanie:

"Myślę, że programy certyfikacji ISEB czy ISTQB są pomyłką. Mam nadzieję, że nikt nie przykłada do nich większej wagi."

Osoby głębiej zainteresowane zapewne spotkały się z podobną opinią Kema Kanera na temat certyfikacji i uzasadnienia dlaczego komercyjni "certyfikatorzy" nie spełniają do końca swojej roli sygnatariuszy kompetencji. W polskich i europejskich warunkach wygląda to znacznie bardziej skomplikowanie. Firmy poszukując podstawowego przynajmniej zapewnienia sobie, że zatrudniona osoba jest kompetentna pytają o certyfikaty. Czy jednak otrzymując pozytywną odpowiedź na to pytanie, otrzymują także odpowiedź na swoje pytanie?

Na koniec Bach zapytany o największe wyzwanie stojące przed dziedziną testów w okresie 5 najbliższych lat, wymienia trzy:

• naukę jak testować
• naukę jak szkolić testerów
• odrzucenie fałszywych profetów certyfikacji

Pierwsze wyjaśnia się chyba samo przez się. Tutaj naprawdę jest jeszcze mnóstwo do zrobienia a uwzględniając polskie warunki - zwłaszcza brak własnego słownictwa - zadanie jest naprawdę ambitne.

Drugie nie wymaga nawet komentarza... Mizeria na tym polu na polskim rynku jest porażająca.

Natomiast co do trzeciego wyzwania to mam mieszane uczucia. Zdaje się, że otwarta forma certyfikacji mogłaby rzeczywiście zapewnić wiedzę "jak testować" na minimalnym poziomie. Lecz tutaj podjęte są słabe próby. Z drugiej strony... tak jak napisałem wyżej, firmy oczekują jakiegoś zaświadczenia, że jesteś testerem i umiesz testować.

Czy dane testowe są już test casem i dlaczego nie

Czy szklanka jest od połowy pusta czy do połowy pełna? Tak samo chyba jest z pytaniem czy dane testowe stanowią same w sobie przypadek testowy...?

W codziennej pracy, pisząc przypadki testowe, bardzo często piszemy jedną procedurę a do niej wybieramy kilka zestawów danych. Czy w takim wypadku każdy z tych zestawów jest przypadkiem testowym czy dopiero w połączeniu z procedurą testową stanowią takowy?

Z punktu widzenia kierownika testów oraz projektanta przypadków skłaniałbym się raczej do tego, że jest to jeden przypadek testowy (a raczej jego szczególny przypadek).

Z punktu widzenia inżyniera uruchamiającego testy skłaniałbym się do pierwszej definicji. Każdy zestaw danych wymusza uruchomienie jednej i tej samej procedury ale kilkakrotnie z różnymi danymi więc i wyniki mogą być różne. Do tego możemy jeszcze - w niektórych przypadkach - doliczyć czas potrzebny na czyszczenie środowiska.

Ogólnie rzecz biorąc jest to bardzo częsty przykład stosowania "brztwy Ockhama" w testach. Jakież było moje zdziwienie gdy okazało się, iż żaden z czołowych produktów do zarządzania testami nie wspiera tej prostej funkcjonalności? Okazuje się, iż próba wygenerowania w "run-time" wielu przypadków testowych na podstawie jednej procedury i kilku zestawów danych definiowanych w "design-time" dla tej procedury jest niemożliwe.

Czyli... zamiast ułatwiać utrzymywalność zasobów przypadków testowych poprzez minimalizowanie ich liczby jesteśmy skazani - korzystając z tych narzędzi - na większe nakłady pracy związane z utrzymywaniem środowiska testowego.

A przecież korzyść z takiej implementacji była by oczywista; mniej przypadków testowych do utrzymania.

Wyrocznia w miarę... czyli testowanie dokumentacji

Wielu testerów myśląc o swoim zawodzie myśli o oprogramowaniu, choć rzeczywistość wymaga od nich znacznie więcej. Rzeczywistość wymaga przede wszystkim zrozumienia celu, dla którego oprogramowanie zostało stworzone i dla jakiego działa.

Zaczynając naszą pracę machinalnie rzucamy się na dostępną dokumentację. W moim przypadku najczęściej są to wymagania i wysokopoziomowy opis architektury, rzadziej dokumenty funkcjonalne lub dokumentacja niskopoziomowa... gdyż ona z reguły (złej) jest tworzona post factum.

Ale skąd wiemy że ta dokumentacja jest poprawna? Dlaczego zakładamy - my testerzy - że nie ma ona błędów. Przecież dokumentacja:

• tak jak testowana aplikacja tworzona jest przez wielu ludzi
• tak jak testowana aplikacja musi mieć problemy z interfejsami
• inaczej niż testowana aplikacja nie podlega formalnej weryfikacji merytorycznej (kompilacji) ponieważ nie ma kompilatorów rozumiejących ludzki język

Dlaczego w związku z tym traktujemy ten byt projektu jako wyrocznię? Odpowiedzi jest wiele ale wszystkie one sprowadzają się do podstawowego problemu: jest to jedyne w miarę pełne, źródło naszej wiedzy o systemie (drugim takim źródłem są oczywiście rozmowy z zainteresowanymi uczestnikami projektu).

Ale skoro jest ono "w miarę" to dlaczego go nie przetestować aby określić tę miarę? Wielu testerów robi to automatycznie, czytając i sporządzając notatki, które następnie klarują z programistami. Jednak moje doświadczenie pokazuje, że w znacznej mierze dokumentacja traktowana jest jak pismo objawione. A jeśli nawet testerzy próbują testować dokumentację to tak naprawdę większość standardowych procesów realizacji projektu kompletnie nie wie co zrobić z raportowanymi incydentami.

Główny problem z testowaniem dokumentacji polega na tym, że weryfikujemy stronę merytoryczną a nie logiczną jak to zazwyczaj ma miejsce w przypadku testowania samego oprogramowania. W tym miejscu bardzo często podnosi się argumenty, że testerzy nie są architektami, nie znają się na programowaniu itd, itp. Nie ma znaczenia czy to jest prawda czy nie! Faktem jest, że dokumentację można przetestować przyjmując "na wejściu" konkretne kryteria.

Według mnie lista 5 kryteriów jest zupełnie wystarczająca do osiągnięcia celu testowania dokumentacji:

• spójność
• mierzalność
• jednoznaczność
• łatwość implementacji
• testowalność

Spójność:	Jest to kryterium, które ma nam udzielić odpowiedzi na pytanie czy tester czytając tą dokumentację nie natrafił na oczywiste niespójności na poziomie interfejsów (np. przekazywanie boolina do wskaźnika typu integer), na poziomie logiki (np. tworzenie dodatkowego indeksu sztucznie dla jednej transakcji) lub na poziomie interfejsu użytkownika (np. przetwarzanie danej, która nie jest wymagana przez GUI).
Mierzalność:	To kryterium ma odpowiedzieć na pytanie czy w trakcie wykonywania testów będziemy w stanie weryfikować otrzymane wyniki. Przykładem defektów w tej kategorii będą zdania typu "system ma działać niezawodnie" lub "system ma obsługiwać wielu użytkowników".
Jednoznaczność:	To kryterium pozwoli na "przefiltrowanie" treści dokumentacji pod względem wszelkich opisów mogących generować jedno lub więcej rozwiązanie lub pozostawiają opracowanie rozwiązania na barkach programisty, np. "akceptacja danych następuje po wypełnieniu pól na formatce".
Łatwość implementacji:	To kryterium identyfikuje potencjalnie niebezpieczne i ryzykowne obszary. "Wyłapuje" wszelkie opisy, które są zagmatwane, napisane skomplikowanym językiem lub po prostu nie zrozumiałe dla testera.
Testowalność:	Ostatnie kryterium odnosi się do tzw "pozostałych". Jego celem jest zgrupowanie wszelkich "dziwnych", "podejrzanych", "pokręconych" fragmentów w stosunku do których odpowiedź na pytanie "jak to przetestować" nie jest oczywista i prosta.

Ta lista kryteriów w sposób oczywisty nie nadaje się do testowania podręczników użytkownika czy innych materiałów wchodzących w zakres gotowego produktu.

Jaki jest cel testowania dokumentacji? To co zwykle..., zidentyfikowanie ryzykownych obszarów i wyeliminowanie ich zanim jeszcze projekt przejdzie do fazy implementacji. Oznacza to, że praca testerów w tym zakresie powinna zacząć się jak tylko powstanie finalna wersja wymagań i powinna obejmować przynajmniej wymagania i dokumentację wysokiego poziomu.

No dobrze..., ale co zyskamy inwestując czas i zasoby w takie przedsięwzięcie. Do głowy przychodzi mi poniższa lista:

• testerzy uzyskują przekrojową wiedzę nt. projektu i produktu oraz natury tych dwóch bytów
  
• testerzy poznają z góry o wiele więcej tak zwanych "ryzykownych" obszarów
• architekci uzyskują pierwszą opinię i uwagi, których naprawa kosztuje czas poświęcony na przeredagowanie kilku paragrafów (czasami kilkuset)
• programiści po prostu dostają lepszą dokumentację
• zarząd minimalizuje koszty bo zmiany są bardzo tanie (no dobra tu się można kłócić) oraz sam produkt ma szansę na znaczenie lepszą jakość już od samego startu
  
• kierownictwo projektu wiedzę pozwalającą lepiej szacować kolejne etapy projektu oraz identyfikować wąskie gardła już teraz, gdy daty w projekcie zdają się być jeszcze odległe
• utrzymanie gdyż projekt posiada mniej defektów związanych z architekturą
  

Dodam dla równowagi, że wady to:

• konieczność zatrudnienia zespołu testerów znacznie wcześniej niż standardowo
  
• konieczność wypracowania sposobu obsługiwania incydentów tego typu
  

W jaki sposób testować dokumentację? Jedynym znanym mi sposobem jest lektura dokumentacji, spisanie uwag a następnie dyskusja wewnętrzna w zespole testów. To jednak jest ideał. W rzeczywistości wygląda to w sposób bardzo nieformalny; specjalista od jakości nie rozumie fragmentu, więc znajduje autora i wyjaśnia z nim te kwestie. Oczywiście w takim wypadku cała wiedza pozostaje na linii tester - autor i prawdopodobnie nikt więcej nie będzie o tym wiedział.

Osobiście testy dokumentacji wykonywałem gdy oprogramowanie znajdowało się już w fazie implementacji. Robiłem to we własnym zakresie gdyż nikt nie był zainteresowany tym zagadnieniem. 90% defektów zgłoszonych do dokumentacji zostało zamkniętych bez konkretnego komentarza (chyba, że komentarzem uznamy "brak czasu"). Ale z drugiej strony gdy przeszedłem do testowania samego oprogramowania, lista obszary określonych przeze mnie jako "ryzykowne" w większości wypadków okazywała się wielką pomocą w znajdowaniu siedlisk defektów i szczerze mówiąc szkoda, że nikt nie pomyślał, że mogły być tańsze.

BetaBlog

Ponieważ zdałem sobie ostatnio sprawę, że tak naprawdę zupełnie nie wiem co wypali z tego przedsięwzięcia jakim jest ten blog. Postanowiłem dopisać mu w tytule "Beta" i dać pół roku na rozwinięcie się.

Jako cel lub raczej zasadność istnienia tego blogu widzę generalnie pojętą wymianę doświadczeń związanych z testowaniem oprogramowania. Przy czym chciałbym aby działo się to w języku polskim. Mnóstwo jest miejsc w Internecie, w których zawarte są informacje o testowaniu w języku angielskim natomiast moje próby znalezienia sensownych informacji na ten temat w języku polskim spełzły na nic nie znaczących ogólnikach.

Tak więc jeśli ktoś czyta "tutejsze" teksty i ma ochotę skomentować to lub owo, to bardzo zachęcam. Wymiana myśli, spostrzeżeń i doświadczeń zawsze poszerza horyzonty.

Jeśli natomiast nikt tego nie czyta oprócz mnie to pól roku to chyba dostatecznie dużo aby zostać znalezionym w Internecie!? Przekonajmy się...

Filozofia testowania

No to teraz będzie chyba z grubej rury. Większość poznanych przeze mnie ludzi kształconych w naukach ścisłych, słysząc o filozofii czy historii lub sztuce mówi w sposób, który dobrze określa słowo "uczłowieczacz". Czyli generalnie jest to coś co ma być dodatkiem do głównego nurtu wykształcenia...

W tym kontekście polecam wpis James'a Bacha na jego blogu "Philosophers of testing".

Najmocniejsze dwa zdania - oczywiście według mojej oceny to:

Philosophy doesn’t find bugs for me, but it improves my ability to search for them. I have more patience for the search because philosophy has taught me tolerance for ambiguity, an appreciation for complexity, and a mistrust of appearances.
[...]
Philosophy doesn’t evaluate or report my bugs, but it does make my evaluations and reports better.

Czarna szkrzynka +/- biała skrzynka = szara skrzynka

Coraz częściej - chyba dlatego, że programiści zabierają się za testowanie ;-) - można spotkać się z rozumieniem zagadnienia testowania w kontekście rywalizacji pomiędzy białą skrzynką a czarną skrzynką. Trudno jest udowodnić taką tezę! Jest to problem typu "kura czy jajko"!

Przykładem tego jest artykuł "Testing, fun? Really?"! Sam artykuł nie wnika subtelne różnice pomiędzy testami czarnej skrzynki a testami białej skrzynki. I chyba rzeczywiście tak powinno być. Test to test! Dobry tester powinien radzić sobie zarówno z kodem jak i z binarką. Na pewno nie powiem nic nowego stwierdzając, że czarna i biała skrzynka to uzupełniające się sposoby na przetestowanie oprogramowania. Problem polega na tym, że czarna skrzynka znajduje innego typu błędy niż biała skrzynka. Oznacza to oczywiście, że nie znajdziemy pewnych błędów stosując dajmy na to tylko test czarnej skrzynki.

Czy biała skrzynka oznacza konieczność stosowania testów jednostkowych? Według mnie nie! To co jest potrzebne to na pewno znajomość architektury danego rozwiązania oraz generalną strukturę organizacji kodu. W mojej opinii doskonałym rozwiązaniem jest korzystanie z kodu jak z podpowiedzi lub swojego rodzaju przewodnika. Na tej podstawie można w łatwy sposób zlokalizować potencjalne obszary ryzyka. Dodatkowo można spróbować określić techniczną naturę tego ryzyka i w zależności od tego zastosować techniki biało lub czarno skrzynkowe.

Testy jednostkowe to tylko jedno z zastosowań testów przeprowadzanych bezpośrednio na kodzie źródłowym i powinny być wykonywane przez autorów tego kodu. Testerzy natomiast nie powinni być odcinani od kodu. Obcując z nim, czytając, poznając architekturę rozumieją w jaki sposób system działa, są w stanie w łatwiejszy sposób zidentyfikować obszary wymagające bardziej intensywnych testów.

Nie pamiętam kto, powiedział, że prawdziwy haker to taki człowiek, który potrafi - mając zdefiniowane zadanie - określić, który język programowania będzie pasował najlepiej do realizacji tego zadania. Podobnie jest z testerami. Posiadając wiedzę na temat systemu, sposobu jego działania, sposobu w jaki jest budowany, architektury, itp. jest w stanie określić, które metody testowe będą najbardziej wydajne w stosunku do których obszarów (typów defektów).

Oczywiście dostęp do kodu powinien być przeznaczony dla osób, które posiadają odpowiednie kompetencje. Ale czy trzeba być programistycznym guru aby to robić? I znowu, wg. mnie wystarczy podstawowa wiedza dotycząca konkretnego języka, sposobu budowania funkcji, deklarowania i rzutowania zmiennych, tzw. "best practices". Podręcznik do C jest chyba inaczej czytany przez programistę a inaczej przez testera. Programista skupiony jest na zagadnieniu "jak coś zrobić" (przynajmniej tak mi się wydaje), tester natomiast skupiony jest na "obszarach potencjalnie niebezpiecznych".

Generyczne przypadki testowe

Każda firma produkująca oprogramowanie dąży do stworzenia zasobów generycznych pozwalających na szybkie i elastyczne generowanie nowych produktów - przynajmniej ich dużą część. W ten sposób powstają przeróżne biblioteki, repozytoria, snippety, interfejsy i inne takie. Po krótkim czasie okazuje się, że tak naprawdę jest to osobny projekt wymagający osobnego kierownika, planu, zdefiniowanych celów itd. Czy automatycznie rzutuje to na dział testów?

Zdecydowanie tak! I to na wielu płaszczyznach które chyba najlepiej wyrazić pytaniami.

• co to znaczy generyczność?
• jak przetestować projekt generyczny?
• czy do generycznego projektu powinny powstać generyczne przypadki testowe?
• co to znaczy, że przypadek testowy jest generyczny?
• do kiedy jest generyczny a od kiedy już nie?

Roztrząsając pewne techniczne zagadnienia związane z integracją TestDirectora z CQ, wraz z kilkoma osobami z działu zajmującego się zarządzaniem konfiguracją i integracją środowiska, doszliśmy do zaskakującego wniosku:

"Istnieje na rynku wiele narzędzi do zarządzania artefaktami projektu takimi jak defekty, przypadki testowe, kod źródłowy, wymagania, specyfikacja czy dokumentacja projektowa. Większość z nich - biorąc pod uwagę przydatność biznesową szeroko rozumianą - kosztuje bardzo drogo. Każdy producent wychwala jak to jest elastyczne i integrowalne ale w rzeczywistości brakuje tym systemom wsparcia generyczności co prawdopodobnie spowodowane jest architekturą opartą o projekt."

Większość architektur takich rozwiązań przewiduje projekt jako kontekst projektu*. Z kolei projekt zdefiniowany jest jako jednotorowy - na ogólnym poziomie - proces wytwarzania oprogramowania. I tutaj pojawia się pierwszy problem! W środowiskach wieloprojektowych rozumienie generyczności jest inne niż w środowisku dużego projektu. W pierwszym przypadku oznacza to "zakres" kodu, możliwy do użycia przy założeniu prac konfiguracyjnych do różnych projektów. Natomiast w środowisku dużego projektu lub - dla jasności nazwijmy go jednoprojektowym - generyczność oznacza reużywalność ale nie względem projektów tylko modułów (stąd chyba bliżej do czystej obiektowości!?)

Oto prosty przykład: programiści pracują w kontekście projektu specyficznego i generycznego równocześnie, testerzy natomiast pracują tylko w kontekście konkretnego projektu (z przyczyn oczywistych). Tak więc defekty zgłoszone przez testerów do projektu "S" są potem przekierowywane przez programistów do projektu "G", kiedy natura defektu okazuje się generyczna. Następnie naprawione defekty wracają do testerów w celu weryfikacji i weryfikacja wszystkich defektów - nawet tych z projektu "G" - odbywa się na projekcie "S". Wystarczy teraz dodać, że testerzy pracują w swoim środowisku a programiści w swoim. Z systemu zarządzania testami raportowane są defekty do zintegrowanego systemu rejestracji defektów. Problem pojawia się w momencie przepisania defektu z projektu "S" do projektu "G". Po prostu w systemie do zarządzania przypadkami widoczne są defekty tylko dla konkretnego projektu. Więc analityk do spraw jakości nie ma dostępu do pełnej informacji tylko do jej części.

Chciałbym podkreślić w tym miejscu, że opisywany przeze mnie tutaj problem chyba w mniejszym zakresie dotyczy środowisk jednoprojektowych. A przynajmniej w środowisku wieloprojektowym objawia się znacznie intensywniej.

Skoro istnieje już projekt generyczny z generycznym kodem, który prawdopodobnie nie da się skompilować w łatwy sposób, to przed testerem powstaje poważne zagadnienie: "jak przetestować tą generyczność zawartą w generycznym projekcie?"

Odpowiedzi oczywiście jest kilka i pewnie poniższe nie pokrywają całości:

1. Testować niejawnie poprzez implementację fragmentów generycznych w modułach/projektach.
2. Zbudować sztuczne projekty - najlepiej na początku fazy stabilizacji kiedy kod jest już gotowy - wygenerowane w głównych mutacjach użycia i przetestować je. Następnie przeprowadzić analizę porównawczą wyników dla poszczególnych projektów. Tam gdzie pokrywają się i wynik jest pozytywny, generyczność jest zaimplementowana.
3. Określić wszystkie możliwe konfiguracje modułu/projektu, wygenerować je w postaci binarki i poddać moduły testom integracyjnym a projekty testom systemowym (oczywiście w ograniczonym zakresie) . Oczywiście procedura jest jednakowa dla wszystkich mutacji.
   

Innym podejściem do testowania generyczności może buć przygotowanie generycznych przypadków testowych. Tutaj jednak powstaje nasze czwarte pytanie (na trzecie odpowiedziałem w poprzednim zdaniu) "co to znaczy, że przypadek testowy jest generyczny?":

1. da się go uruchomić na każdym projekcie z rodziny "G"?
2. da się go uruchomić bez zmiany parametrów?
3. jest reużywalny jako zamknięta część - bez konieczności zmian?
4. wskazuje jedynie co powinno być przetestowane?

Pierwsze pytanie sugeruje szansę sukcesu ale tak naprawdę poważnie ogranicza zakres pokrycia testami. Oznacza to, sukces ale bardzo maleńki.

Drugie pytanie dotyczy tak naprawdę zagadnienia; co określa przypadek testowy jako generyczny? Ja jestem gorącym zwolennikiem oddzielenia danych testowych od procedury. Pozwoliło by to na bardzo dużą elastyczność:

• dynamiczne generowanie przypadków testowych w oparciu o jedną procedurę i wiele zestawów danych, co pokryłoby w łatwy sposób:
  
• klasy równoważności
  
• dziedziny
• wartość graniczne
• przepływ danych
• przepływ sterowania
  
• kontrolę potrzebną głównie na poziomie danych
• dużą przenaszalność samych procedur.
  

Pytania 3 i 4 wskazują chyba na zasadniczy konflikt. Mowa jest o tym, iż albo mamy bardzo szczegółową procedurę, która powinna mieć wynik pozytywny na każdym projekcie z rodziny albo nie mamy właściwie nic oprócz listy kontrolnej, którą następnie uzupełniamy jako implementację instancji przypadku testowego na konkretnym projekcie. Pierwsze wyjście powoduje, ze nasze zasoby generycznych przypadków testowych są bardzo ograniczone i tak naprawdę testują tylko standardowe funkcjonalności lub przypadki użycia. Ale za to uzyskujemy krótki czas przygotowania testów.

Drugie rozwiązanie pozwala na znacznie szerszy zakres testów ale czas do uruchomienia jest znacznie dłuższy.

Odpowiedź na ostanie pytanie: "do kiedy przypadek jest generyczny a od kiedy już nie" jest mocno uzależniona od tego jak zdefiniowana zostanie sama generyczność. Ja po prostu polecałbym zdrowy rozsądek i metodę drobnych kroczków. Najpierw należy zbudować zbiór przypadków, które udowodnią swoją generyczność (przy naprawdę minimalnych zmianach wykorzystywane będą na szeroką skalę). Każdy w miarę doświadczony tester ma podręczny zestaw takich przypadków (obsługujących takie obszary jak logowanie, wylogowywanie, walidowanie danych, itd). Następnie na tej podstawie należy spróbować określić co oznacza w danym wypadku "generyczność" i skorzystać z tego jako z kryterium przy wybieraniu następnych przypadków testowych. Jednak definicja generyczności powinna być nieustannie weryfikowana.

* Właściwie to nie znam systemu przeznaczonego do opisanych zastosowań, który nie używał by projektu jako kontekstu opisującego całość.

Książka o testowaniu po polsku

Wyszła książka napisana przez Berezę i Wiszniewskiego zatytułowana "Teoria i praktyka testowania oprogramowania" nakładem wydawnictwa PWN (Mikom). Link do księgarni to: http://mikom.pwn.pl/4776_pozycja.html.

Jeszcze nie czytałem więc trudno mi cokolwiek powiedzieć...

Jak zostać ekspertem od testowania czyli "Becoming a Software Testing Expert" na Google Video

Świetny wykład Jamesa Bacha na temat jak się stać ekspertem od testów. Rzeczywiście zawiera kilka wskazówek, których warto posłuchać.

"Becoming a Software Testing Expert" na Google Video
Opis: Google TechTalks, 13 Lipca 2006, James Bach

"Pracuję z zespołami projektowymi i poszczególnymi inżynierami aby pomóc im zaplanować proces zapewniania jakości oprogramowania (SQA), kontrolowania zmian oraz procesów testowych pozwalającym im zrozumieć i kontrolować ryzyka związane z niedziałaniem produktu. Większa część mojego doświadczenia związana jest z firmami nastawionymi na rynek z Doliny Krzemowej takimi jak Apple Computer czy Borland, więc techniki, których się nauczyłem i rozwinąłem zostały zaprojektowane tak aby korzystać z nich w warunkach napiętych harmonogramów, wysokiego wskaźnika zmian, technologii opartej na komponentach lub ubogiej specyfikacji."

STRESZCZENIE: "Jesteście doświadczonymi testerami. Wiecie jak zaprojektować testy i raportować defekty. A teraz co? Czujecie się ekspertami? Na nieszczęście, jeśli chcecie stać się bardzo dobrymi w testowaniu, to nie macie wielu kursów lub programów do wyboru, które by wam pomogły. Oznacza to, że musicie edukować się sami. Ten przewodnik jest o tym jak znaleźć przejście z doświadczenia do bycia ekspertem. Bazuje on na szkole metodologii testowania "kierowania się kontekstem" (context-driven). Skupia się na tym co oznacza myśleć jak tester i jak projektować i krytykować praktyki testerskie (bardziej niż na tym aby po prostu kopiować co mówią wam "guru"). Pokażę wam także strategie samouczenia się i metody rozwoju sieci koleżeńskich. Jest to idealny kurs jeśli testowanie jest waszą karierą i zamierzacie się w nim doskonalić."

Bezpośredni link: http://video.google.com/videoplay?docid=6852841264192883219&pr=goog-sl