niedziela, 23 grudnia 2007

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.

piątek, 7 grudnia 2007

Procesowość procesu

Na rynku dostępne są całe lasy literatury poświęconej procesom. Można je sobie oglądać z punktu widzenia zapewniania jakości, zarządzania projektem, SCM, czy testów.

Nie chcę tutaj pochylać się nad oczywistościami. Z całą pewnością dobrze zdefiniowany proces ułatwia skupienie się na samym projekcie, minimalizując elementy niezaplanowane i nieoczekiwane. Z drugiej strony każdy proces jest pewną generalizacją dokonywaną na podstawie przypadków konkretnych i reprezentatywnych. Oznacza to, że rzeczywistość jest bardziej ciekawa niż to może się wydawać krojniczym takiego procesu. Zawsze!

Bardzo często, mechanizmami obronnymi takiego procesu jest rozrost administracji w skrajnych wypadkach prowadzący do jakiejś formy tego, co Max Weber nazwał "złotą klatką racjonalizmu". W skrajnych przypadkach dla małych projektów, większa część czasu jest przeznaczona na obsługę samego procesu a nie na obsługę projektu.

Nie wchodząc w szczegóły poczyniłem następujące spostrzeżenia:
  • Działanie procesu w dużej mierze nie zależy na konstrukcji samego procesu ale na procesie zarządzania nim (np. zmuszanie programistów do pisania dokumentacji).
  • Każdy proces powinien być definiowany na potrzeby konkretnej organizacji. Kopiowanie na wprost w tym zakresie zawsze się zemści!
  • Każdy proces opracowany na potrzeby konkretnej organizacji musi być skalowalny (mini dla małych projektów, midi dla średnich projektów i maxi dla dużych projektów
  • każdy proces musi mieć określony cel i powinien być wykorzystywany tylko w kierunku realizacji tylko tego celu. Każde nadużycie tej zasady może prowadzić do zmiany działającego procesu. W myśl zasady "lepsze" jest wrogiem "dobrego" efekt wcale nie musi być zachwycający.
  • Materiał wyjściowy i wejściowy z i do procesu powinien być generowany możliwie najczęściej automatycznie minimalizując nakład ręcznego przygotowywania dokumentów
  • Potrzebny jest miernik na jakim poziomie projekt powinien być opisany. Dla projektów run-and-forget powinien być to minimalny opis natomiast dla projektów o szerokim horyzoncie utrzymaniowym taki opis powinien być możliwie szczegółowy
  • Role powinny być odseparowane. Developer woli programować niż pisać a technical writter woli pisać niż programować
  • Jeden wspólny język dla całego procesu

środa, 7 listopada 2007

Oczywiste oczywistości czyli o podstawach kompletnych testów

Tym razem chciałbym napisać o rzeczach, które uważam za kompletne podstawy... . Chciałem zdanie dokończyć 'testowania oprogramowania' ale uzmysłowiłem sobie, że to nie dotyczy wyłącznie testowania. A więc... chcę napisać o kompletnych i podstawowych zabiegach, stosowanych w szeroko pojętej inżynierii w mocnym kontekście testów oprogramowania, odchylonych - z kolei - mocno w stronę automatyzacji i/lub powtarzalności.
  • Parametryzacja - separacja danych od logiki ich przetwarzania. Duża część testów polega na mnipulacji samymi danych (klasy równoważności, wartość graniczne, dziedziny itd). W związku z tym o wiele łatwiej jest zarządzać tymi danymi mając je "na zewnątrz" skryptu.
  • Atomizacja - rozbijanie złożonych problemów na proste. Informatyka jest pod tym kątem szczególnie łaskawą dziedziną. Praktycznie każdy złożony problem składa się z mniejszych i prostszych. Trzeba tylko umieć wyłowić powiązania prostych problemów w kontekście złożonego. Dodatkowo, "testowo" obsłużone proste problemy mogą być re-używalne.
  • Logika - nie testować w oparciu o nazwy kontrolek ale w oparciu o logiczne przepływy danych. Każde oprogramowanie składa się z warstwy prezentacyjnej (interfejs użytkownika), warstwy przetwarzania (middleware) i warstwy sterowania (sterowniki). Dobrze napisane oprogramowania ma te warstwy mocno odseparowane co pozwala na wydajne testowanie logiki w oderwaniu od kontrolek i zasilaniu logiki bezpośrednio z zestawów danych testowych np. poprzez API.
  • Narzędzia - co może za nas zrobić narzędzie to niech to zrobi. Pytanie tylko czy potrafimy tym narzędziem się posłużyć. Narzędzi jest całe mnóstwo i nie problem znaleźć takie, które wydaje się przydatne ale wcześniej trzeba wiedzieć do czego chce się wykorzystać takie narzędzie.
  • Abstrakcja - nie związywanie procedur testowych z konkretną wersją (wyglądem) testowanego oprogramowania ale raczej z jego przeznaczeniem. Np. przypadki testowe odwołujące się do konkretnych nazw kontrolek muszą być aktualizowane gdy zmieni się wersja GUI. A z drugiej strony, skoro przypadki już są gotowe to po co czekać i nie uruchomić procedur testowych od razu. Przecież kontrolki na interfejsie użytkownika można potraktować jako swojego rodzaju dane, które się weryfikuje (czy kontrolka jest, wartości kontrolki, funkcjonalności kontrolki).
  • Elastyczność - łatwość rozbudowywania i dostosowywania do konkretnych potrzeb. W przypadku automatyzacji chodzi np. o możliwość zestawiania poszczególnych skryptów czy przypadków testowych w różnych sekwencjach.
  • Generowalność - generowanie scenariuszy i generowanie rezultatów testów. Wybudowanie środowiska testowego pozwalającego na swobodne generowanie scenariuszy testowych o jasno określonym celu jest bardzo trudne jeśli wręcz nie możliwe. Jakkolwiek, należy budować przypadki testowe w taki sposób aby na ich podstawie móc generować scenariusze. Drugą stroną jest możliwość generowania wyników z testów. Każdy przeprowadzony test kończy się określonym wynikiem. Dobrze jest jeśli takie wyniki odnotowywane są automatycznie w sposób umożliwiający ich dalszą weryfikację.

środa, 24 października 2007

Portal MS o testowaniu

Firma Microsoft uruchomiła na MSDNie "Tester Center", które można znaleźć pod adresem http://msdn2.microsoft.com/en-us/testing/default.aspx.

Interesujące jest to, że to przedsięwzięcie firmują takie nazwiska jak James A. Whittaker czy Michael "The Braidy Tester" Hunter co jest gwarancją zachowania wysokiego poziomu merytorycznego.

wtorek, 11 września 2007

Pytać czy nie pytać eksperta!?

W życiu każdego testera następuje chwila, w której musi sobie odpowiedzieć na pytanie "zapytać o 'to' czy nie zapytać?". Po przełamaniu pierwszych lodów i odkryciu jak potężnym jest to narzędziem, sięgamy po nie coraz częściej. Chyba, że napotykamy na mur deadlocków... to znaczy, kiedy częściej uzyskujemy odpowiedź "nie teraz", "za chwilę", "teraz nie mam czasu" niż tą o którą nam chodziło.

Z drugiej strony zauważyłem, że istnieje wielu testerów, którzy wolą po prostu grzebać samemu "na czuja" niż zasięgnąć porady u eksperta. Wynika to, zapewne z wcześniejszych doświadczeń typu "nie mam czasu" jak i obietnicy ogromnej satysfakcji, "że sam odkryłem".

Oczywiście wybór drogi należy do każdego testera osobiście. Ja chciałem się tylko podzielić swoimi spostrzeżeniami na ten temat.

Bezpośrednia rozmowa z ekspertem ma niewątpliwie tę ogromną zaletę, że uczy bardzo szybko wielu rzeczy związanych z testowanym systemem. Z drugiej jednak strony ma tę ogromną wadę, że w sposób zasadniczy zależy od 'interfejsu' eksperta. Po prostu, kiedy spotykamy człowieka otwartego i gotowego do pomocy to pracuje się nam z nim przyjemniej niż z człowiekiem, którego trzeba wiecznie "błagać" o skrawek wiedzy. Powoduje to, że 'user-friendly' eksperci są bardziej oblegani niż Ci 'z konsolą znakową'. Często sami eksperci, przeciążeni pracą, zaczynają ograniczać swoją uprzejmość bo po prostu zajęci są swoimi obowiązkami.

Aby rozmowa z ekspertem była owocna, należy przede wszystkim się do niej przygotować (nas też denerwuje jak ktoś ciągle przychodzi do nas i zadaje pytania na które swobodnie możemy odpowiedzieć sławetnym "RTFM"). A jak się przygotować? Przede wszystkim przeczytać dostępna dokumentację aby upewnić się, ze mamy doczynienia z prawdziwym problemem
(zasada taka sama jak przy zgłaszaniu incydentów), następnie sprawdzić logi. Bardzo często ten krok jest pomijany a on tymczasem dostarcza w wielu wypadkach odpowiedzi na nasze pytania. Po to przecież logi są implementowane aby odpowiadać na pytania co poszło źle.

Jeśli pójdziemy do eksperta z pytaniem "dlaczego to nie działa" to jest to tak samo jakbyśmy zgłosili incydent "system nie działa". Zadając pytanie ekspertowi trzeba wiedzieć co konkretnie nie działa, umieć to nazwać. A jeśli nie potrafimy - bo n.p. jesteś w nowej organizacji - to należy zaznaczyć to na wstępie, że nie umiemy tego nazwać ale utknęliśmy na takim to a takim kroku (określić punkt w procesie).

Inną pomocną rzeczą są koledzy obok. Jeśli jest to zespół doświadczonych testerów to na pewno tam znajdziemy odpowiedź a jeśli nie to i tak warto zapytać bo prawdopodobnie, ktoś wcześniej trafił na podobny problem. Przynajmniej powie nam do kogo powinniśmy udać się z podobnym problemem.

Pozostaje jeszcze problem "wydłubywania" czegoś samodzielnie. Testerzy - chyba z natury rzeczy - są ludźmi uwielbiającymi dłubać. Jeśli napotykają problem n.p. z uruchomieniem jakiegoś procesu, to próbują na wszelkie znane im sposoby, uruchomić go. Problem polega na tym że:
  • nawet jeśli uda nam się uruchomić taki proces to i tak nie wiemy do końca czy jest to poprawny sposób uruchamiania
  • często po prostu nie udaje nam się go uruchomić bo brakuje nam wiedzy o jednym, małym, sekretnym parametrze
W obydwu wypadkach może to być stratą czasu co jest luksusem, na który rzadko można sobie pozwolić. Oczywiście, z drugiej strony jest to czas, w którym tester uczy się generalnie systemu co nie jest czasem straconym i dlatego nie jestem i nie potępiam tego sposobu w czambuł. Jakkolwiek, w sytuacjach, w których jest mało czasu polecam konsultacje u ekspertów zamiast dłubaniny jako bardziej pewnej drogi.

Tutaj jednak problemami, które przełamywać powinien przede wszystkim kierownik testów są:
  • zwykła, naturalna nieśmiałość członków zespołu
  • nieznajomość organizacji
  • obawa przed dyskredytacją lub odsłonięciem naszej niewiedzy*
  • przeszkody fizyczne, n.p. oddzielne lokalizacjae testerów i ekspertów
  • postawa osoby odpowiedzialnej za testy
Działy IT nie należą do 'zagłębia' ludzi komunikatywnych. Większość z członków tych zespołów woli trójkąt 'ja - problem - komputer' zamiast czworokąta 'ja - problem - inni - komputer'. Zasada ta dotyczy także testerów co w znaczny sposób przekłada się na komunikację z innymi zespołami.

Czasami problemem bywa nieznajomość organizacji. Tester po prostu nie wie do kogo się udać. A nawet jak zdobędzie nazwisko danej osoby to nie wie gdzie może ją znaleźć. Jest to zasadnicze pole działania dla osoby kierującej testami. To ona powinna w takich sytuacjach przejmować obowiązek 'biura matrymonialnego' komunikując testera z odpowiednim ekspertem.

Testerzy nie są wszechwiedzący. Część funkcjonalności systemu znają lepiej na niskim poziomie a część - zwłaszcza tą której nie testowali bezpośrednio - znają na wyższym poziomie. Większość problemów przeważnie dotyczy tego wysokiego poziomu. Mamy więc sytuację kiedy człowiek z oględną wiedza na temat danej dziedziny usiłuje skonsultować się z ekspertem. Powoduje to, ze 'ekspert' czasami wykorzystuje sytuację dając do zrozumienia, ze pytanie jest głupie. Dzieje się tak gdyż 'ekspert' nie potrafi wyobrazić sobie świata bez swojego poletka, któremu przypisuje najprawdopodobniej mistyczne niemal przymioty. Jest to smutna sytuacja, która de facto obróci się przeciw 'ekspertowi'. W efekcie ekspert otrzyma gorzej przetestowany system, co wynika z reglamentowanie informacji.

Rozdzielenie lokalizacji ekspertów i testerów, jest w mojej opinii jednym z najpoważniejszych błędów. Pracowałem w projekcie, w którym testerzy siedzieli w lokacji oddalonej od ekspertów o setki kilometrów. Żadna telefonia, komunikatory ani maile nie są w stanie tego skompensować. Duża porcja informacji ginie co odbija się na jakości systemu.

Jeśli kierownik testów lub inna osoba odpowiedzialna za działa kontrolujące jakość systemów informatycznych jest mało komunikatywna powoduje to, ze i członkowie zespołu nie będą się komunikować z innymi zespołami. W skrajnych przypadkach kierownicy testów budują mit o jakości oprogramowania którą rujnują niedouczeni, niekompetentni, leniwi i gnuśni programiści. Jest to odwrócenie sytuacji eksperta z nieprzyjaznym 'interfejsem'. Skoro testerzy wykorzystują byle pretekst do pomstowania na ekspercie i jego rodzinie 7 pokoleń wstecz to dlaczego tenże ekspert ma być otwarty i uprzejmy. Posunę się nawet do twierdzenia, iż zarząd firmy w której funkcjonuje taki kierownik testów, powinien niezwłocznie usunąć taką osobę zanim ta choroba rozprzestrzeni się na cały zespól testów.

Reasumując chciałem powiedzieć, że wszyscy uczestnicy projektu powinni traktować się z szacunkiem bez względu na zajmowane w nim pozycje. Kierownictwo i zarząd firmy powinny dbać o kreowanie i rozwijanie takich postaw a napiętnować postawy zamknięte.

* Zdarzyło mi się pracować w środowisku, w którym tak zwani eksperci wykorzystywali niedoświadczenie testerów, drwiąc z nich. Zakończyło się to prawie całkowitym zerwaniem komunikacji testerzy - eksperci co z kolei - w mojej ocenie - było jedną z zasadniczych przyczyn niskiej jakości dostarczanego rozwiązania.

poniedziałek, 10 września 2007

Polski blog o testowaniu

Dzisiaj znalazłem w sieci polski blog o testowaniu oprogramowania. Można go znaleźć pod http://testerzy.org/.

Z kilkoma artykułami umieszczonymi tam nie zgadzam się z innymi się zgadzam ale to tak naprawdę nie jest istotne... istotne jest, że powstaje kolejna strona o testowaniu w języku polskim.

Oby tak dalej

piątek, 27 lipca 2007

Wakacje

No i sezon ogórkowy! Ale niestety nie u mnie. Mam mnóstwo pracy co niestety powoduje, że trochę zaniedbałem bloga ale mam nadzieję, że niedługo się wykaraskam z opałów i znowu będę mógł coś napisać.

Tym czasem chciałem polecić dwie książki - niestety po angielsku - odnośnie testowania:
Niestety nie są to tanie książki, więc może porozmawiać z pracodawcą czy nie udzielił by dotacji!?

Zaletą tych książek jest to, że opisują proces testowania od A do Z i współdzielą doświadczenie testowe.

czwartek, 24 maja 2007

Guide to the SWEBOK

Celem projektu Guide to the Software Engineering Body of Knowledge jest (jak wskazują autorzy):
  • opisanie treści dokumentu "Software Engineering Body of Knowledge";
  • umożliwienie dostępu tematycznego do dokumentu "Software Engineering Body of Knowledge";
  • promowanie spójnego spojrzenia na inżynierię oprogramowania;
  • wyjaśnienie miejsca oraz ustalenie granic inżynierii oprogramowania w stosunku do innych dyscyplin takich jako informatyka, zarządzanie projektem, inżynieria informatyczna czy matematyka;
  • utworzenie podstaw rozwoju materiałów szkoleniowych, certyfikacyjnych i licencyjnych
Z punktu widzenia testów szczególnie interesujących jest rozdział 5 zatytułowany "Software Testing". Można w nim znaleźć podstawowe informacje na temat testowania oraz definicji rozróżnianych przez SWBOK poziomów testowania. Dla doświadczonych testerów może on służyć jako materiał referencyjny a dla początkujących jako bardzo dobry pakiet startowy :-).

Ale oczywiście zachęcam do poznania całego dokumentu. Pozwala on na poznanie podstaw takich gałęzi inżynierii oprogramowania jak zarządzanie wymaganiami, projektowanie i konstruowanie oprogramowania, utrzymanie czy zarządzanie konfiguracją lub jakością.

A wszystko to dostępne pod adresem: Guide to the SWEBOK

czwartek, 17 maja 2007

Data Driven Test Automation Frameworks

Zaczynając budowę automatycznego środowiska testowego, bardzo pomocne jest zdefiniowanie podstaw. Pozwala to na późniejsze uniknięcie błędów związanych z utrzymaniem i rozwojem takiego środowiska co jest jednym z największych zagrożeń związanych z taką architekturą testów. "Data Driven Test Automation Frameworks" jest to dokument zawierający kilka propozycji w jaki sposób można zorganizować sobie to środowisko w sposób pozwalający zminimalizować te zagrożenia. Niestety opis ten zawiera tylko rozwiązania oparte o dane.

środa, 16 maja 2007

Prywatne EuroSTAR :-)

Oprócz amerykańskich konferencji poświęconych jakości oprogramowania STAREAST i STARWEST funkcjonuje ich europejska wersja pod nazwą EuroSTAR. Najbliższa odbywa się pod hasłem "Defining the Profession". Organizatorzy uważają, że do rozwikłania zagadki tego hasła prowadzą odpowiedzi na poniższe pytania:
  • Czy uważasz siebie za testera i profesjonalistę? Czy inni uważają Cię za takiego?
  • Co pozwala Ci na takie stwierdzenie?
  • Czy istnieje podstawowy zbiór umiejętności? Czy są to umiejętności techniczne czy społeczne, a może dwojakie?
  • Jaka jest Twoja jedna, najbardziej cenna umiejętność? Czy potrafisz ją objaśnić innym?
  • Czy kwalifikacje mogą określać profesjonalnego testera?
  • Czy Twoja organizacja wnosi dobre praktyki do profesji?
Ponieważ próba odpowiedzi na te pytania wydała mi się wyzwaniem, postanowiłem zmierzyć się z nim. Ale postanowiłem to zrobić na ogólnym poziomie nie wchodząc w szczegóły, chyba że jest to uzasadnione.
Czy uważasz siebie za testera i profesjonalistę?
Kto może nazwać siebie testerem...? Czasami jako testera określa się osobę zawodowo zajmującą się weryfikowaniem czy to co miało być zrobione zostało rzeczywiście zrobione! Jednak w mojej opinii nie jest to definicja kompletna. Tester bowiem, to osoba, która nie tyle zajmuje się weryfikowaniem czy to co zaplanowane zostało zaimplementowane - jest to produkt bardzo ważny ale pośredni pracy testera. Tester to osoba, która z pełną świadomością przepuszcza oprogramowanie przez specjalnie w tym celu zaprojektowane procedury, których celem jest weryfikacja czy został osiągnięty określony i zdefiniowany poziom jakości i która to osoba do projektowania procedur testowych korzysta w wielu technik! Gdy poziom jakości nie jest określony i zdefiniowany formalnie to i tak bardzo pomocne jest nieformalne określenie tego parametru.

Mówi się, że dobry tester jest w stanie przetestować wszystko... i rzeczywiście kilka lat pracy w zawodzie formułuje specyficzne podejście charakteryzujące się "testowaniem" otoczenia. Jak słusznie zauważył James Bach, istotne jest umiejętne posługiwanie się sceptycyzmem i krytycyzmem co w mojej ocenie jest wyższym stopniem wtajemniczenia w ten zawód. Łatwo jest bowiem popaść w bezproduktywne narzekanie, że system nie jest doskonałej jakości a bardzo trudno jest ustrzec się przed domniemaniem pewnych oczywistości. I tak np. łatwo jest powiedzieć, że dany obszar funkcjonalny jest źle napisany bo zostało do niego zaraportowanych dużo defektów ale dużo trudniej jest tak skonstruować testy aby przy minimalnym, potrzebnym nakładzie pracy (w sensie czasu i zasobów) przetestować dokładnie ten obszar a następnie efektywnie zweryfikować efekt prac naprawczych.

Jak można zdefiniować profesjonalistę...? Uważam, że profesjonalista to człowiek skupiony na celach, potrafiący je osiągać korzystając z dostępnych środków oraz dobierać nowe środki w sposób optymalny. Ale jednocześnie profesjonalista to taki ktoś, kto dążąc do realizacji tych celów, potrafi dać swój wkład w środowisko pracy... to np. taka osoba, która widzi szerszy kontekst swojej działalności. Osoba, która biorąc cokolwiek od innej osoby (wiedzę, informację, zasoby, czas, itp) potrafi uczynić to we właściwy sposób i jednocześnie dać coś w zamian. To ktoś w towarzystwie kogo przebywając jednocześnie uczymy się, ktoś do kogo ma się zaufanie. To ktoś kto ma misję!

Dla mnie taką misją jest "minimalizowanie ryzyka związanego z realizowanym produktem/projektem". To minimalizowanie realizuję poprzez dostarczanie innym uczestnikom procesu, z jednej strony informacji na temat jak można przy zastanych zasobach i historii projektu zrealizować efektywnie testy a z drugiej strony wiarygodną informację na temat poziomu jakości tego produktu w odniesieniu do czynników zewnętrznych takich jak jakościowe oczekiwania klienta, otoczenie biznesowe, przeznaczenie systemu, itp. W ten sposób chronię zarówno swojego pracodawcę przed utratą renomy a z drugiej strony chronię odbiorcę przed stratami spowodowanymi wadliwym działaniem systemu.

Często spotykam się z mniej lub bardziej jawny antagonizowaniem testera i programisty. Dla mnie takie ujęcie jest zupełnie bezprzedmiotowe. Nie ma znaczenia tak naprawdę kto "bardziej zbawia świat". Znaczenie ma jaki się ma stosunek do wykonywanego zawodu. Testowanie dla osoby zainteresowanej tym zawodem i świadomej możliwości jest takim samym wyzwaniem jak zaprogramowanie testowanego systemu. Co więcej, antagonizowanie działu testów z działem rozwoju w poważny sposób zakłóca komunikację między tymi dwoma działami co w konsekwencji najczęściej powoduje z jednej strony reglamentację wiedzy na temat stosowanych rozwiązań a z drugiej strony nadmierny nakład pracy związanej z testami oraz zbyt detaliczne raportowanie defektów.

Testowanie jako odrębna dziedzina daje duże możliwości wielokierunkowego rozwoju i zdobywania wiedzy weźmy choćby pod uwagę automatyzację testów, projektowanie testów, standaryzację testów, itp.
Czy inni uważają Cię za takiego?
Nie jestem w stanie odpowiedzieć na to pytanie! Nie znam myśli innych ludzi. Ale mogę odwrócić to pytanie i sformułować je tak "co powoduje, że myślisz o innych jak o profesjonalnych testerach?" Jako profesjonalnego testera określam taką osobę, która potrafi pomóc kierownikowi projektu lub innej osobie odpowiedzialnej za realizację przedsięwzięcia określając, jak i które obszary powinny być testowane w zależności od takich czynników jak czas, historia produktu/projektu oraz historia testów, dostępne zasoby, jakość tych zasobów, itd. Jednym zdaniem, według mnie profesjonalny tester to taki, który potrafi trafnie i wiarygodnie odpowiedzieć na pytanie "jak powinien być przetestowany" system, program, moduł czy jednostka. "Trafnie" oznacza tutaj sposób pozwalający w świadomy sposób wyeliminować ryzyko czyli taki, który umożliwi znalezienie istotnych defektów. Wymaga to z kolei umiejętności klasyfikowania defektów nie tylko z punktu widzenia systemu ale także całego projektu.

Do znajdowania, opisywania i klasyfikowania defektów, dysponuje jednocześnie całym wachlarzem narzędzi takich jak techniki testowania, znajomość kontekstu biznesowego, historii system oraz samego systemu.

Nie chcę przez to powiedzieć, że tester jest odpowiedzialny za całość przedsięwzięcia a jedynie chcę podkreślić fakt, iż do obowiązków testera nie należy tylko samo testowanie ale także osadzanie wiedzy o testowanym systemie w jego kontekście w takim zakresie w jakim jest to dla niego osiągalne w zależności od jakości komunikacji w projekcie, zakresu odpowiedzialności (analityk testów, wykonawca testów, lider/manager testów, lider/manager do spraw jakości procesów).
Co pozwala Ci na takie stwierdzenie?
Przystępując do nowego projektu, jako jeden z moich "prywatnych" celów wyznaczam sobie rolę źródła pomocy kierownikowi projektu w realizacji zadań projektowych. Nie każdy kierownik projektu, jest świadom tego, że "oszczędzając czas i zasoby" na testach tak naprawdę oszczędza na zapobieganiu ryzyka. Dostarczenie oprogramowania z dużym opóźnieniem do testów i następnie wymaganie zrealizowania pierwotnego planu testów, w żaden sposób nie zaowocuje dobrymi rezultatami. W najgorszym wypadku, raport z testów może pokazywać, że wszystkie funkcjonalności zostały przetestowane. Ale żaden raport nie pokaże jakiej jakości były te testy. Nie odpowie na pytanie czy mała liczba defektów jest wynikiem znakomitej pracy programistów, czy testów dokonywanych w pośpiechu i pobieżnie. Dlatego uważam, ze każdy odpowiedzialny kierownik testów dużo uwagi powinien poświęcać monitorowaniu realizacji harmonogramu projektu aby wcześnie reagować na ograniczanie czasu przeznaczonego na testy jak najwcześniej. Jednocześnie powinien być świadom, iż skracanie czasu testów oznacza w swojej istocie zmniejszenie zakresu testów a więc zwiększenie ryzyka związanego z produktem.
Czy istnieje podstawowy zbiór umiejętności? Czy są to umiejętności techniczne czy społeczne, a może dwojakie?
Groucho Marx powiedział kiedyś "Zamierzam żyć wiecznie lub umrzeć próbując". Z całą pewnością istnieje podstawowy zbiór umiejętności wyróżniający testera spośród innych inżynierów. Przede wszystkim - u dojrzałego testera - jest to świadomość "że świat nie jest taki piękny jak się wydaje a nawet jeśli jest to należy to sprawdzić".

Same umiejętności podzieliłbym na kilka poziomów: warsztatowe, produktowe techniczne, produktowe nietechniczne oraz społeczne.

Umiejętności warsztatowe to przede wszystkim biegła znajomość technik projektowania przypadków testowych. To jest warunek sine qua non bycia testerem. To właśnie od tego zależy to czy wykonujemy testy w sposób kontrolowalny, wiarygodny, weryfikowalny i jednoznaczny. Skonstruowanie i uruchomienie przypadku testowego bez jednej z tych cech często okazuje się pracą bezcelową, nie przynoszącą odpowiedzi na podstawowe pytanie.

Umiejętności produktowe techniczne to wszystkie te informacje, które są związane ze sposobem w jaki dany produkt powstaje. Mam na myśli tutaj technologię, sposób implementacji danych funkcjonalności, znajomość ograniczeń technicznych systemu, itp.

Umiejętności produktowe nietechniczne to generalnie znajomość i zrozumienie celu, dla którego powstaje produkt. Innych funkcji oczekujemy przecież od sytemu księgowego a innych od systemu przetwarzania sygnału telewizji cyfrowej, inaczej będzie działał wygaszacz ekranu na komputerze a zupełnie inaczej na dekoderze telewizji cyfrowej. Bez znajomości kontekstu w jakim osadzony jest produkt trudno jest mówić o "dobrym testowaniu".

Umiejętności społeczne to przede wszystkim umiejętności komunikacji i współpracy. Bardzo istotne jest z punktu widzenia testera zrozumienie chociażby tak prostego faktu, że defekty w oprogramowaniu nie wynikają ze złej woli programisty lub uporu architekta ale z faktu, że każdy z nas jest człowiekiem i popełnia błędy. I oczywiście odwrotnie, ważne jest aby osoba odpowiedzialna za całość przedsięwzięcia była świadoma, że testowanie jest sztuką szacowania opartym na krytycznym podejściu do oprogramowania dostarczonego do testów oraz na sceptycznym podejściu do deklarowanej jakości tego systemu, zakresu zmian, możliwych efektów pobocznych, itp.. (Nad wyraz często spotykam się z sytuacją, w której raporty defektów są po prostu ignorowane lub przetwarzane wsadowo co tak naprawdę przynosi gorszy efekt niż po prostu pozostały by one w statusie początkowym).

Te cztery warstwy "zanurzone" są w czymś co nazwałbym "intuicją testera". Rodzi się ona i rozwija się z czasem i doświadczeniem (udziałem w różnych projektach, w różnych organizacjach, w różnych kontekstach biznesowych itp.). Pozwala ona testerowi na wydajne czerpanie z wszystkich czterech warstw w zależności od etapu procesu testowego (analizy wymagań, projektowania przypadków testowych, wykonywania testów lub raportowania defektów, oraz od etapu produkcji oprogramowania.

Jest ona również bardzo istotna w procesie wyjaśniania wszelkich niejasności jakie powstają w trakcie czytania dokumentacji. Warto tutaj dodać, iż w sytuacji kiedy reputacja testerów jest umniejszana jako "tych co nie programują" to wtedy, bardzo skuteczną bronią jest stawianie odpowiednich pytań przez testerów. Jeśli charakter zadawanych pytań będzie zdradzał ignorancję testera lub niezrozumienie działania i celu systemu, negatywna postawa programisty utrwali się. Jeśli natomiast pytania testera przyniosą tę korzyść programiście, że zwrócą mu lub jej uwagę na szczegóły, które są istotne a nie zostały uwzględnione w analizie, bardzo szybko testerzy staną się ośrodkiem wiedzy na temat całościowego działa testowanego systemu. Testerzy - w naturalny niejako sposób - stają się jedynym ośrodkiem w procesie wytwarzania oprogramowania, który posiada w miarę całościową wiedzę na temat rzeczywistego działania produktu. Wynika to właśnie z faktu konieczności zrozumienia zasady działa i celowości całego systemu a nie tylko jej fragmentu. Konieczność ta, z kolei jest warunkiem istotnym do prawidłowego przetestowania systemu.
Jaka jest Twoja jedna, najbardziej cenna umiejętność? Czy potrafisz ją objaśnić innym?
James Bach w jednej ze swoich prezentacji zadaje pytanie; "jaka jest Twoja misja?", "Czy potrafisz opisać ją w 5 minut?" Moją misję zdefiniowałbym jako; "wsparcie kierownictwa projektu w zakresie określania i eliminowania zagrożeń związanych z dostarczeniem wadliwego oprogramowania". Chodzi o to aby mieć świadomość, że kiedy kierownik projektu przychodzi do nas z pytaniem "na kiedy mogę mieć to przetestowane", to tak naprawdę zadaje on pytanie "w jaki sposób - mając do dyspozycji określony czas i zasoby - mogę się dowiedzieć jak najszybciej jakie ryzyko niesie ze sobą wyprodukowane oprogramowanie". To tester musi wiedzieć co, jak długo i w jaki sposób przetestować tak samo jak programista musi wiedzieć co, jak i jak długo będzie programował.

Na tej podstawie, jako swoją najbardziej cenną umiejętność w tym zawodzie określiłbym otwartość. Otwartość rozumianą jako rozumienie zarówno potrzeb projektu jak i klienta oraz znajdowanie kompromisu pomiędzy tymi dwoma żywiołami.
Czy kwalifikacje mogą określać profesjonalnego testera?
Na tak postawione pytanie nie da się chyba odpowiedzieć... wszystko zależy od ludzi. Posiadanie certyfikatów nie dowodzi niczego choć na pewno jest pomocą w poszukiwaniu pracy oraz w zdobywaniu zawodowej pewności siebie, co także jest istotne. Czy tester z kilkuletnim doświadczeniem powinien robić certyfikat z testowania? Jeśli chce "ulepszyć" swoje CV to na pewno tak, ale jeśli chce się czegoś nauczyć to nie ma to sensu bo dowie się o podstawowym zakresie stosowania technik, które zna biegle (a jeśli ich nie zna to nie wykonywał pracy testera).

Na pewno doświadczenie jest tym co bardzo pomaga w realizacji zadań testowych. Ale to nie jest, żadna myśl odkrywcza gdyż doświadczenie jest wszędzie przydatne. Jeśli natomiast jest to pytanie o profil wykształcenia oraz wynikającego w konsekwencji doświadczenia zawodowego to nie potrafię na to odpowiedzieć. Spotykałem wielu testerów. Byli wśród nich i absolwenci filozofii jak i absolwenci fizyki czy informatyki. Ale nie umiem powiedzieć czy wykształcenie ma jakikolwiek wpływ na to czy jest się dobrym lub złym testerem. Z całą pewnością znajomość i wiedza z zakresu inżynierii oprogramowania, programowania, czy generalnie informatyki jest czymś niezbędnym. Z moich obserwacji wynika, że testerzy o informatycznym profilu wykształcenia doskonale sobie radzą z problemami czysto technicznymi takimi jak zrozumienie działania skomplikowanej funkcjonalności ale z drugiej strony często spotykałem tutaj tendencje do poprawiania a nie testowania tej funkcjonalności co zżerało czas i zasoby. I nie chodzi mi tutaj o to, że doszukiwali się źródeł problemu ale o to, że często zamiast poświęcać czas na identyfikację defektów poświęcali czasz na poszukiwanie odpowiedzi na pytanie "jak to naprawić" co jest powinnością programisty.

Ludzie o wykształceniu nie technicznym są znacznie bardziej wyczuleni na defekty. Powoduje to, że czasami przesadzają z oceną wagi defektu oraz zajmują sztywniejsze stanowisko w procesie weryfikacji naprawionych defektów. Często także - powodowani swoją niepewnością wynikającą ze świadomości braku wykształcenia informatycznego - komplikują zagadnienia w fazie analizy co utrudnia im znacznie zrozumienie podstawowych kwestii.

Nie wiem, która opcja jest lepsza... Ale wiem, że za każdym razem kiedy pracowałem w zespole testerów, to tworzył się inny niż u programistów świat... świat, w którym ludzie otwarci są na wiedzę i dzielenie się nią, w którym czują się spojeni misją, którą mam nadzieję każdy z nich potrafi sobie zdefiniować. Świat który jest jednak mocno sceptyczny. Z drugiej jednak strony powstaje wiele patologii takich jak tworzenie "mitycznej jakości" lub zbyt szczegółowe podejście do zagadnień testowych co powoduje niepotrzebne wydłużenie cyklu testowego.

Reasumując, definiowanie profesji testera z całą pewności jest pożądane. Dobrze, że powstają firmy certyfikujące i standaryzujące. Dobrze, że jest mnóstwo wolnych strzelców i ludzi pracujących na własnymi metodykami. Taka dychotomia jest symptomem tego, że jest to jeszcze bardzo młoda dziedzina. Ale bez względu na to czy pracujemy w środowisku extreme, agaile, V, W, iteracyjnym czy w modelu kaskadowym, z całą pewnością powinniśmy w naszych codziennych obowiązkach testera zapewniać spełnienie podstawowych warunków takich jak kontrolowalność, wiarygodność, weryfikowalność i jednoznaczność przy optymalnym stosowaniu technik testowych.

poniedziałek, 23 kwietnia 2007

Czarne scenariusze

Pamiętam kiedy w Polsce telefonia komórkowa dopiero kiełkowała i powstawały pierwsze maszty, a ja byłem na studiach. Rozmawiałem wtedy z jednym z moich znajomych na temat przypuszczalnej szkodliwości spowodowanej emisją fal z aparatu telefonicznego (były to czasy, kiedy dość dobrze szła sprzedaż nalepek ochronnych przed promieniowaniem emitowanym przez telefony komórkowe :-) ). Ponieważ znajomy zajmował się profesjonalnym montażem stacji "trafo" wytłumaczył mi to bardzo ładnie, że fale są o niskiej częstotliwości, i że nie groźne dla ludzi itd, itp.

Podszedłem do tego sceptycznie. Jednak sceptycyzm mój został zweryfikowany przez postęp technologii. Dzisiaj jestem zwykłym użytkownikiem telefonii komórkowej i nawet nie rozważam jej w kategoriach "zwolennik - przeciwnik".

Zdziwiłem się, kiedy kilka dni temu przeczytałem informację na temat teorii mówiącej o szkodliwym wpływie telefonii komórkowej na człowieka.

Rozmawiając z moim znajomym na temat szkodliwości telefonu komórkowego popełniłem klasyczny błąd skupiając się jedynie na relacji telefon-człowiek a nie na relacji "system telefonii komórkowej" - "ekosystem człowieka"... czyli spłaszczyłem zagadnienie do jednego przypadku a nie uwzględniałem całej klasy. Defekt, który w tamtym czasie był do przewidzenia, wydawał się prawdopodobnie mało istotny, że nikt nim się nie przejmował (mi i mojemu rozmówcy nawet nie przemknęło to przez myśl). Korzyści płynące z nowej technologii wydawały się tak ogromne, że - jak przypuszczam - nikt tak naprawdę nawet nie chciał się zajmować sceptycznym ujęciem problemu.

Telefony komórkowe i inne elektroniczne zabawki mogą stać się przyczyną wielkiego głodu na świecie. A w tym wszystkich - jak donoszą naukowcy - chodzi o pszczoły, które nie potrafią znaleźć powrotnej drogi do domu gdyż fale emitowane przez telefony komórkowe zaburzają system nawigacyjny pszczół. Nie potrafiąc znaleźć drogi powrotnej do ula, daleko od swoich rojów pojedyncze pszczoły giną. A jeśli nie ma pszczół to nie ma zapylania i klęska głodu gotowa... Zjawisko nazywa się Colony Collapse Disorder (CCD)

Powyższa teoria jest jedną z wielu, próbujących wyjaśnić zjawisko CCD. Mnie jednak zastanawia, jakie szanse mieli ludzie testujący system telefonii komórkowej zbudować podobny scenariusz testowy... wydaje mi się, że nie wielkie, jeśli nie postał specjalny zbiór przypadków testowych mający testować potencjalne "czarne scenariusze". I przyszło mi do głowy, że przynajmniej utrzymywanie listy potencjalnie "czarnych scenariuszy" i korygowanie jej wraz z rozwojem produktu może niespodziewanie przynieść bardzo dobre rezultaty odnośnie generalnie rozumianej jakości poprzez umożliwienie szybkiej reakcji na negatywne efekty niezaprojektowane przez architektów, których w innych okolicznościach nie da się wykluczyć.

środa, 11 kwietnia 2007

Nieznane niewiadome

Zostałem kiedyś poproszony przez moją firmę o zrobienie prezentacji dla wszystkich pracowników na temat jakości. Generalnie.., w jaki sposób widziałbym podejście do planowania projektów względem testów i co tak naprawdę oznacza "jakość" dla naszej organizacji.

Ponieważ zawsze uważałem, że obopólne porozumienie na linii programiści - testerzy jest kluczem do sukcesu, zacząłem zastanawiać się jak wyjaśnić programistom co to jest "czarna skrzynka" i jak myśli o niej i w niej tester.

Najfajniej byłoby - pomyślałem sobie - znaleźć jakiś błyskotliwy cytat opisujący czarną skrzynkę. Zacząłem grzebać po Internecie poszukując czegoś ciekawego. Odwiedziłem "Wikicytaty" i rozpocząłem poszukiwania od haseł typu "czarna skrzynka" lub "skrzynka". Jednak nie mogłem trafić na nic naprawdę mocnego.

"To musi być coś" - powtarzałem sobie - " co pobudzi ich wyobraźnie a jednocześnie da im do myślenia". I wtedy przypomniałem sobie dyskusję jaką przeprowadziłem pracując w zupełnie innym miejscu z jednym z testerów. Cytat pochodził od Donalda Rumsfelda i brzmiał:
"[…] wiemy, że - jak wiadomo - są rzeczy, o których wiemy, że o nich wiemy. Wiemy też, że są znane niewiadome, to znaczy, że są rzeczy, o których wiemy, że nic o nich nie wiemy. Ale są również nieznane niewiadome - takie, o których nie wiemy, że o nich nie wiemy […]"(1)

"Skoro ja to zapamiętałem to i oni przyswoją to na jakiś czas" pomyślałem sobie. Tak przy okazji to uważam te słowa za w dużej mierze oddające świat, horyzont wiedzy oraz oczekiwania i przeczucia testera testującego czarną skrzynką.

Rzeczy "o których wiemy, że o nich wiemy" to wymagania, specyfikacja i historia systemu oraz wszelkie inne informacje bardziej lub mniej oficjalne.

Rzeczy niewiadome to chociażby defekty, zmiany do wymagań lub specyfikacji i te wszystkie informacje, które do nas nie dotarły. Każdy tester jest świadom, że jego zasób wiedzy na temat testowanego systemu jest ograniczony.

Na przykład we wczesnych fazach projektu bardzo często pojawiają się rzeczy, które w żaden sposób nie są zdefiniowane przez architekta lub programistę. Dowiadujemy się o ich istnieniu przy projektowaniu testów, kiedy schodzimy na bardzo niski poziom. Fazą, która wprost obfituje w odkrywanie rzeczy, o których wiemy, że nic o nich nie wiemy jest testowanie dokumentacji. Nie wiemy także jakie defekty spotkamy po drodze ale wiemy, że one są.

Ten punkt jest także bardzo dobry do rozpoczęcia testów eksploracyjnych. Jeśli jesteśmy w stanie zdefiniować obszary, o których wiem, że nic nie wiemy i rozpoczniemy ich eksplorację testową to otrzymamy w większości przypadków bardzo ciekawe wyniki.

"Nieznane niewiadome" to wszystkie te rzeczy, za które tester się wstydzi (głównie "oczywiste" defekty wychodzące w testach polowych lub akceptacyjnych). To także te wszystkie zmiany w projekcie (bardzo często spontaniczne i nie do końca przemyślane), które powodują zmianę architektury co tak naprawdę powinno oznaczać rozpoczęcie testów od samego początku. Świadomość że nie wiemy o tym o czym nie wiemy bywa czasami przyczyną powtarzania testów.

(1)D. Rumsfeld, Departament Obrony USA, 12 lutego 2002 roku, "[...]as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know[...]"

piątek, 6 kwietnia 2007

Testowanie rzeczywistości

Dzisiaj przekonałem się na własnej skórze, że (czasami) warto jest testować rzeczywistość. Przez wiele lat chodziłem do jednego i tego samego dentysty. Fachowiec powtarzał, że "aby wyleczyć to musi boleć". Więc bolało jak cholera! Do tego stopnia, że zacząłem unikać dentysty jak tylko mogłem. Ergo, nastąpił paraliż projektu, bo chodziłem tylko wtedy, kiedy rzeczywiście ząb bolał na maksa a to generalnie oznaczało leczonko kanałowe. A to z kolei jeszcze bardziej zwiększało moją niechęć i obawy.

I tak przez lata, wmawiając sobie, że ten dentysta mnie zna, robi co może aby jak najmniej bolało chodziłem do niego. Jednak ostatnio - całkiem przypadkowo - w nagłej potrzebie zmieniłem lekarza. I oczywiście świat się zmienił. Borowanie nie boli, stres jest mniejszy, generalnie jest luks malina.

Tylko ja trochę żałuję, że wcześniej nie rozpocząłem testów lekarzy dentystów. Ale z drugiej strony - jeśli leczenie zębów i obawę przed bólem uznać za system krytyczny - to była to decyzja o podstawach jak najbardziej racjonalnych...

wtorek, 3 kwietnia 2007

The Braidy Tester : Did I Remember To

The Braidy Tester : Did I Remember To - lista heurystyk do wykorzystania w trakcie testowania eksploracyjnego

Testy eksploracyjne - czytanka

Polecam bardzo artykuł (lub rozdział książki) Jamesa Shorea "Exploratory testing". Bardzo mi się spodobał sposób w jaki wyjaśnił zastosowanie heurystyk w testach eksploracyjnych.

Moda na jakość

Mam wrażenie, że na rynku pojawia się mocno niezdrowy trend w kontekście jakości oprogramowania. Firmy zmuszone zajmować jak najwcześniej dany sektor rynku, decydują się na wypuszczanie oprogramowanie o znacznie zaniżonej jakości.

Z jednej strony jest to pokierowane rozsądną przesłanką, że wczesne zajęcie rynku pozwoli na opanowanie go w dużej ilości a ewentualne defekty można bardzo szybko naprawić aktualizacją. Z drugiej jednak strony powstaje problem, który nazwałbym "mitem wczesnego zajęcia rynku".

Nie jestem specjalistą od marketingu ale zastanawiam się na ile słaba jakość tych produktów ogranicza rynek...? Zastanawiam się czy klient - słysząc od znajomych lub czytając w Internecie o słabej jakości danego produktu - zrezygnuje z nowoczesnej technologii i postanawia przeczekać aż nowinka "dojrzeje"?

Najgorszy scenariusz to taki, że klient zapamięta nazwę firmy i po pewnym czasie zakupi implementację u innego dostawcy, "tak na wszelki wypadek". W najlepszym wypadku - po prostu wstrzyma się o zakupu bo uzna to za naciąganie. Taki paradoks musi w efekcie przynieść ogromną presję na działy testów. Firmy chcąc zajmować rynki bardzo wcześnie będą wymuszały skracanie harmonogramów testów.

Ekstremalnie krótki czas dostarczenia systemu na rynek musi - domyślam się - obarczać ogromnym obciążeniem zespoły jakości mające szansę na sprawdzenie jedynie podstawowych funkcjonalności (pomijam przypadki kiedy testowanie jest zupełnie eliminowane z harmonogramów). Rodzi to poważne konsekwencje... np. skupienie się tylko na funkcjach technicznych (np. odpowiedzialnych za możliwość przeprowadzenia przyszłej aktualizacji), pozostawia pod znakiem zapytania sensowność produkowania czegoś co nawet w minimalnej nawet mierze po prostu nie działa.

Znowu prowadzi mnie to do paradoksu opisanego powyżej. Klient jest wściekły bo nie działa zasadnicza funkcja lub działa bardzo niepoprawnie a z drugiej strony ma zupełnie w nosie to że mechanizm zapewniający mu możliwość aktualizacji jest w pełni bezpieczny i niezawodny.

Częściowo problem czasu poświęcanego na "bezproduktywne" testy (rozumiane także jako proces utylizowania produktów testów a więc implementowanie poprawek w oprogramowaniu) można rozwiązać poprzez XT. Ale choć nie wiem jak lekkich metodyk użyjemy i tak potrzebny jest okres czasu po zakończeniu produkcji oprogramowania, który sprawdzi czy dostarczony efekt jest zgodny z oczekiwanym.

piątek, 30 marca 2007

Recenzja na SJSI

Na stronach SJSI pojawiła się moja recenzja książki "Teoria i praktyka testowania programów". Jest to dokładanie ta sama recenzja, którą można przeczytać na tym blogu (tutaj).

czwartek, 29 marca 2007

Ranking defektów

Postanowiłem dzisiaj sprawdzić czy da się znaleźć w Internecie listę lub ranking najbardziej ciekawych defektów. Niestety nic takiego nie znalazłem, ale przyszło mi do głowy, że można by taką listę dzielić na kilka kategorii. Oto te które przyszły mi do głowy (oczywiście chodzi o defekty zaraportowane):
  • nieistniejący defekt
  • defekt związany z czasem
  • UI defekt
  • najgroźniejszy defekt (showstoppers)
  • nic nie znaczący defekt
  • defekt bezpieczeństwa
  • najgłupszy defekt
  • najtrudniejszy defekt do znalezienia
  • znaleziony, nienaprawiony defekt
Może ktoś ma więcej pomysłów...

wtorek, 20 marca 2007

Szara skrzynka pełna plusów i minusów

Termin "szara skrzynka" pojawia się mniej lub bardziej formalnie na stronach książek, w internecie lub pismach branżowych. Z moich obserwacji nie istnieje żadna zestandaryzowana definicja tej techniki. To bardzo dobrze! Dla mnie oznacza to mniej więcej następujący proces:
  1. Analiza dostępnej dokumentacji i danych historycznych (jeśli istnieją)
    Wszelka dokumentacja zaczynając od wymagań, poprzez dokumenty techniczne a na rozmowach z architektami kończąc.
    Jeśli jest to kolejna wersja systemu lub projekt integracyjny to nie powinno być problemów z uzyskaniem takich danych. W przypadku nowego projektu, warto jest poczytać o podobnych rozwiązaniach.

  2. Weryfikacja statusu implementacji rozwiązania
    Jeśli faza kodowania jest bardzo wczesna to nie ma nawet sensu zaglądać do kodu bo zmieni się on jeszcze wiele razy. Warto natomiast obserwować rewizje komitowane do systemu kontroli wersji... mówi to bardzo dużo o łatwych i trudnych implementacyjnie obszarach

  3. "Przejście" po kodzie i zidentyfikowanie fragmentów ryzykownych
    Na tym etapie - jeśli oczywiście kod jest wystarczająco "dojrzały" - wystarczy po prostu przeglądać go i identyfikować takie elementy jak: "duże" w sensie linii kodu funkcje, nieuporządkowane fragmenty (gdzie stosuje się np. różne konwencje standardu kodowania), "dużo" wykomentowanego kodu, "dziwne" nazwy zmiennych, wartości wpisywane na stałe (tzw. hardkodowanie), itp. (Warto jest utrzymywać plik z listą kontrolną takich "gadżetów").

  4. Porównanie znalezisk z wymaganiami
    Należy dokładnie wiedzieć, jakich funkcjonalności dotyczą potencjalnie niebezpieczne obszary i w jaki sposób widoczne są w "runtime".

  5. Pierwsze podejście do testów - plan ogólny
    Spisanie sobie ogólnego planu zawierającego także wstępną listę przypadków testowych

  6. Analiza dokumentów z procesu produkcji oprogramowania
    Chodzi tutaj generalnie o analizę raportów z testów jednostkowych, inspekcji kodu, jak również obserwację częstotliwości komitów do repozytorium.

  7. Uszczegółowienie planu testów
    Dopisanie brakujących przypadków testowych.

  8. Dokładna analiza "trudnych" fragmentów
    Ten etap znajduje zastosowanie przeważnie w kolejnych cyklach testowania, kiedy okazuje się, że klasyczne podejście do testów jest niewystarczające. Chodzi o zidentyfikowanie - na podstawie defektów - obszarów najbardziej "zarobaczonych" i przyjrzenie się sposobowi w jaki jest on zaimplementowany w kodzie. Następnie należy zaprojektować przypadki testowe odpowiadającemu zastanemu stanowi. Najczęściej oznacza to duże obłożenie warunków brzegowych oraz zagęszczanie klas równoważności.

  9. Ponowne uszczegółowienie planu testów
Tak naprawdę to dotarcie do punktu nr. 5 daje bardzo duże efekty. Ale np. korzystanie z takiej dokumentacji jak raporty z testów jednostkowych lub protokoły z inspekcji kodu nadwyraz wydajnie pozwalają sprytnemu testerowi identyfikować groźne obszary (ale to temat na całą książkę) i wcale nie muszą być wykorzystywane w sekwencji przedstawionej powyżej.

Zastanawiając się na wadami i zaletami takiego podejścia, następujące punkty przyszły mi do głowy:

Plusy

  1. Testowanie czarną skrzynką opiera się na domniemaniu, że kod napisany jest zgodnie z zasadami inżynierii oprogramowania a praktyka pokazuje, że tak jest często ale nie zawsze i nie w pełnym zakresie.

  2. Termin "inżynieria oprogramowania" nie oznacza z punktu widzenia testów absolutnie nic. Przysłowiowe "Hello world" może być zakodowane w jednym języku na milion sposobów i każdy z nich będzie spełniał różne wymagania co pociąga za sobą różne podejścia przy projektowaniu testów.

  3. Analiza kodu pozwala na identyfikację potencjalnie ryzykownych miejsc. Oczywiście ma to swoje ograniczenia. W przypadku systemów czasu rzeczywistego nie zidentyfikuje się w ten sposób defektów związanych z zależnościami czasowymi ale na pewno pozwoli zaoszczędzić czas na "walcowaniu" całości poprzez większy nacisk na miejsca ryzykowne.

  4. Pozwoli inżynierowi do spraw testów zrozumieć architekturę samego rozwiązania (z mojego doświadczenia wynika, iż wewnętrzne szkolenia poświęcone implementowanej architekturze są naprawdę rzadkością!?) co w sposób znakomity usprawnia proces projektowania testów poprzez uprzednie dostarczenie wiedzy na temat wysokopoziomowej struktury testowanego rozwiązania.

  5. Nie ma konieczności czytania całego kodu. Ponieważ nie sprawdzamy poprawności działania każdej struktury/obiektu/klasy czy usługi. Na potrzeby testów behawioralnych potrzebne są nam fragmenty przetwarzające logikę biznesową.

  6. W sytuacji gdy zmuszeni jesteśmy zatrudniać ludzi, którzy testowanie widzą jedynie jako etap pozwalający przejść do programowania, może być to doskonałe narzędzie do wykorzystania ich potencjału jak również motywowania.

  7. Eliminuje ryzyko testowania rozwiązania wbrew jego logice. To znaczy gdy nasze przypuszczenia co do implementacji są drastyczne różne od założeń implementatora. To ryzyko może być groźne w sytuacji kiedy mamy czas tylko na pobieżne testy w celu określenia jak bardzo jest dany obszar niebezpieczny. Po testach dymnych może wyglądać, że rozwiązanie działa dobrze a w środowisku rzeczywistym pojawi się katastrofa.

Minusy

  1. Praca nad kodem może łatwo przerodzić się w zabawę z kodem trwającą bez końca. Może to prowadzić do kompletnej indolencji testowej przy jednoczesnym ogromnym obłożeniu zespołu pracą

  2. Kod bardzo często jest w postaci sote a wiec bez komentarzy. Dodatkowo, jeśli w danym środowisku wykorzystuje się komponenty dostawców zewnętrznych, komponenty generyczne lub inne kompleksy integrowane, których implementacja poprzez interfejs jest skomplikowana to czytanie takiego kodu staje się niemożliwe bez głębszej wiedzy.
    Ten problem jest częściowo niwelowany przez "Plus" nr. 5

  3. Osoby zatrudniane na stanowisko testera często nie posiadają kompetencji rozumienia kodu - "bo przecież nie potrzeba". Ale zawsze w zespole testowym znajdzie się osoba, która trochę programowała lub ma zacięcie w tym kierunku. Należy to wykorzystać, zlecając jej analizę kodu pod względem identyfikacji potencjalnych ryzyk. Czasami wystarczą pobieżne oględziny i odrazu widać miejsca, z którymi programista strasznie ciężko walczył. Pomocą tutaj mogą być raporty z przeglądu kodu - jeśli takie praktyki są prowadzone.

  4. Rozpoczęcie projektowania testów jest możliwe tylko gdy faza kodowania jest mocno rozwinięta i można korzystać zarówno z kodu jak i z raportu o zmianach wersji (co często bywa pomocne przy identyfikowaniu "kłopotliwych" obszarów).

  5. Istotnym ograniczenie jest znajomość języków. Jeśli trafimy na projekt napisany w zupełnie obcej nam technologii to nie jesteśmy w stanie efektywnie korzystać z tej techniki.
Powyższy opis procesu nie stanowi całości ale to chyba punkty, które mnie najbardziej interesują i których usystematyzowania odczuwałem potrzebę.

środa, 14 marca 2007

Słownik testowy

Kiedyś na starych stronach SJSI dostępny był słownik testowy. Wersja, do której się odnoszę nosiła numer 1.0. Zaskoczyło mnie w niej, że brakuje polskiego tłumaczenia definicji takich angielskich terminów jak "pass/fail", "evaluate", "valid/invalid", "input", "release notes" czy "severity". A przecież są to zupełnie podstawowe terminy z dziedziny testowania. Ale nawet przy tych brakach było on bardzo pomocny! Ciekawe dlaczego został zdjęty?

niedziela, 11 marca 2007

Lektura obowązkowa czyli o praktykach teoretycznych

Państwowe Wydawnictwo Naukowe wespół z wydawnictwem MIKOM wydało w 2006 książkę "Teoria i praktyka testowania programów" autorstwa Bogdana Wiszniewskiego i Bogdana Berezy-Jarocińskiego. Pozycja wyszła w serii "Biblioteka Programisty".

Wydanie

Wydanie nie zaskakuje niczym szczególnym. Biały papier, naćkany drobną czarną czcionką z wąziutkimi marginesami. Gęsto poszatkowane rozdziały. Na 460 stronach zamieszczono 10 a właściwie 12 rozdziałów plus bibliografia i skorowidz. Całość zamknięta tekturowymi, polakierowanymi okładkami i sklejona jedynie klejem. Standard estetyki poligraficznej na polskim rynku wydawniczym.

Zaskoczyło mnie - chyba nie mile - to, że prace pani Anny Bobkowskiej, pana Łukasza Garsteckiego i pani Magdaleny Sławińskiej zostały niejawnie wplecione do książki. Ale cóż, skoro zgodzili się sami twórcy to rozumiem, że autorzy wymieni pod tytułem książki mieli w tym jakiś cel, który niestety dla mnie pozostanie nieodgadniony.

Co od ilustracji to jakość nie jest porażająca ale nie odbiega od standardu wydania. I chyba dobrze bo jak mniemam oszczędności na jakości pozwoliły - w opinii zarządu wydawnictwa - wydać książkę w przystępnej cenie.

Treść

Właściwie są to dwie książki, których rozdziały zostały poprzekładane! Jedna napisana przez postać znaną mi jako weteran szkoleń o tematyce związanej z inżynierią oprogramowania oraz tłumacz książki Rona Pattona "Testowanie oprogramowania". Druga to napisana bez polotu, przeładowana akademickim żargonem opowieść o tym na ile sposobów można zastosować narzędzie gdb.

Sami autorzy stwierdzają, że książka jest pisana z myślą o "[...] studentach informatyki, którzy zgłębiają zagadnienia jakości [...] zawodowych informatykach [...], planistach przedsięwzięć informatycznych [...], kierownikach projektów". Niestety szkoda, że adresatem nie są ludzie profesjonalnie zajmujący się kontrolą jakości oprogramowania. Nie jestem również przekonany czy znani mi kierownicy projektów mieliby cierpliwość przeczytać ten miks. A ponieważ książka jest skierowana do tak szerokiego grona, efektem ubocznym jest np. autorytatywnie brzmiące zdanie:

"Praktycznie wytworzenie jakiegokolwiek programu bez testowania jest działaniem jałowym, ćwiczeniem wykonywanym na papierze (strona19)."
Z punktu widzenia teorii można się z tym zgodzić. Jednak z punktu widzenia rzeczywistego przedsiębiorstwa testowanie jest taką samą aktywnością jak każda inna i podlega takim samym procesom i prawidłom (przede wszystkim zasadność, celowość i ekonomiczności). Zdanie to zdziwiło mnie w świetle wcześniej przeczytanej definicji głównej przyczyny macoszego traktowania jakości:
"Kontrola jakości - w tym także test - również sporo kosztuje, jednak sama z siebie nie tworzy produktów, za które ktokolwiek jest gotów zapłacić. Właśnie z tego powodu pokusa oszczędzania na testowaniu jest tak silna i tak rozpowszechniona (strona 14)."
... zastrzegając, że w mojej opinii jakość jest tym produktem. To że firmy mają problem z jej mierzeniem (postrzeganiem) to już zupełnie inne zagadnienie. Które zręczni kierownicy testów mogą wykorzystać uwzględniając zasadę, że zmierzone jest to co się mierzy.

Nie zgadzam się także z autorami w kwestii definicji celu testowania. Takich definicji może być wiele natomiast autorzy książki informują tylko o jednym i to w sposób jakby to był cel jedyny.

"Testując, usiłujemy wywołać awarie systemu, aby umożliwić znalezienie i usunięcie powodujących je błędów[...] (strona 14)."

Traktowanie błędu jako wskaźnika jakości nie jest dobrą miarą, kiedy staje się jedyną. Raport z defektu to tylko jeden z produktów testowania.

Rozdział pierwszy książki autorstwa obydwu panów traktuje przekrojowo problematykę procesów i systematyki testów. Na początku następuje ogólnikowy w zamierzeniu opis czynności rozciągający się od konfiguracji środowiska po opis weryfikacji wyników wykonanych testów. Następnie autorzy przechodzą do zgrabnego opisu zasadności i natury procesu w cyklu wytwarzania oprogramowania.

Po opisie modeli kaskadowego, V, W, ewolucyjnego i przyrostowego autorzy przechodzą do budowania świata idealnego, w którym następuje weryfikacja wymagań, projektu i ocena kodu. Następnie wspominają dokładniej o systematykach testów od jednostkowych do akceptacyjnych i od obciążeniowych do funkcjonalnych.

Wszystko to kończą próbą zdefiniowania co to jest defekt oraz opisem modelu testowania, moim zdaniem nie wnoszącego kompletnie nic nowego do prezentowanej treści.

To, czego mi zabrakło to zaprezentowanie kilku wybranych podejść do jakości z omówieniem różnic. Autorzy mogli np. wykorzystać poziomy świadomości organizacyjnej zdefiniowane przez Beizera (którego wymieniają w bibliografii) lub wykazać te różnice opisując różne konteksty testowania (outsourcing, oddzielne zespoły, kontrola i zapewnianie jakości, itd).

Skoro książka jest zaadresowana do studentów, zabrakło mi tutaj informacji o celach i zasadach klasyfikacji defektów czyli tak zwanych taksonomiach.

Nie należy zapominać w tym miejscu o rozdziale "Literatura", który jest bardzo ciekawy i pouczający.

Książka naukowca

Zacznijmy od części trudniejszej autorstwa pana Wiszniewskiego. Szczerze mówiąc dużo nerwów i cierpliwości kosztowało mnie przedzieranie się przez liczne wzory i formuły, których armia studentów będzie musiała nauczyć się na pamięć. Dodatkowo zadanie utrudnione było poprzez - moim zdaniem - nadużywanie terminologii naukowej, ale rozumiem, że celem było uzyskanie jak największej precyzji pojęć!? Dla mnie jednak nazbyt często brzmiało to niejasno.

Na początku autor opisuje liczne modele (działania programu, błędu czy środowiska). Następnie przechodzi do opisu implementacji testu (dodam iż chodzi o testy, które powszechnie nazwalibyśmy testami "białej skrzynki") wykorzystując jako przykład narzędzie gdb. I choć wcześniej książka prezentuje nam modele V i W, w tym miejscu – nie wiem dlaczego – autor postanowił oprzeć się o model kaskadowy!?

Omawiając czarną i białą skrzynkę autor sprawia wrażenie jak by namawiał to generowania jak największej liczby przypadków testowych nie wspominając ani razu jak zarządzać efektywnie tak dużymi zbiorami. Z drugiej strony brakowało mi opisu technik pozwalających minimalizować zasoby procedur testowych.

Wśród zawieruchy słownictwa i wzorów pan Wiszniewski zwraca uwagę na - moim zdaniem - bardzo ważną kwestię kontekstów użycia danych. Jednak nie wiązałbym jej tylko z testami na kodzie – tak jak uczynił autor – ale także w testach behawioralnych.

Na koniec mamy rozdział 8, którego zadaniem jest pokazanie czytelnikom jak wygląda praktyczne zastosowanie omawianych wcześniej problemów. Ten rozdział jest praktycznie w całości napisany przez niejawnych autorów książki wymienionych wyżej w tym tekście.

Książka szkoleniowca

Część napisana przez pana Berezę-Jarocińskiego nie jest przesiąknięta precyzyjnym językiem nauki, co zdecydowanie ułatwia czytanie i jednocześnie nie generuje strat na precyzyjności. Autor stara się opisać różne aspekty projektu informatycznego takie jak różnice pomiędzy zapewnianiem a kontrolowaniem jakości, zarządzanie testowaniem, kierowanie projektem, narzędzia wspierające testerów i kierowników testów. Dosyć szczegółowo opisuje proces planowania testów wraz z opisem ról i organizacji oraz głównych prawideł rządzących zespołem ludzi (nie tylko testerów). Poświęca także, kilkanaście akapitów motywacji testerów, co jest chyba unikalne pośród polskiej literatury fachowej.

Zabrakło mi tutaj informacji o zagrożeniach jakie niesie niedodefiniowanie roli zespołu testów. Owszem autor wspomina tu i tam, że taka lub inna czynność czy odpowiedzialność powinna być jasno zdefiniowana. Ale brakuje mi tutaj wskazówek czysto praktycznych na temat komunikacji z kierownikami projektów czy zarządem, próby wytworzenia własnego systemu kryteriów wypuszczenia produktów, gdy nie istnieją oficjalne, definiowania misji i celów zespołu testowego, itd., itp.

Przy opisie problematyki defektów zabrakło rozróżnienia na defekty i incydenty. Przy zastosowaniu czarnej skrzynki - gdzie źródło problemu często nie jest możliwe do zidentyfikowania - możemy mówić o incydentach, które następnie mogą, ale nie muszą być zaklasyfikowane jako defekty. Trudno jest czasami stwierdzić czy dany symptom jest objawem defektu czy objawem funkcji zaimplementowanej zgodnie z wymaganiami. Konsekwentnie, incydenty powinny podlegać regularnym przeglądom, co z kolei staje się problematyczne w środowiskach wielo-projektowych.

Następnie autor dostarcza nam kilka metryk. Większość z nich jest jednak oparta o defekty, co jak zostało powiedziane wyżej, nie jest jedyną miarą jakości.

Rozdział 9 to opis narzędzi typu CAST. Tutaj wszystko szło dobrze do momentu, gdy zacząłem czytać fragment poświęcony automatyzacji testów. Uderzył mnie fakt, iż najistotniejszy element automatyzacji testów, jakim jest automatyzacja weryfikacji wyników testów została zupełnie pominięta. A to właśnie ten aspekt automatyzacji jest najbardziej zapalny i jednocześnie owocny. To przecież możliwość uzależniania wykonania przypadku TC1a lub TC1b od wyniku wykonania przypadku TC1 daje dopiero potężne narzędzie do ręki analityka testów. Bez takiego wsparcia testy automatyczne to tylko automatyczny generator danych, które następnie i tak muszą być przetworzone ręcznie.

Ostatni rozdział merytoryczny poświęcony jest standardom, normom i certyfikacji. Można się z niego dowiedzieć kilku ciekawych rzeczy na temat konferencji branżowych organizowanych w Polsce i Europie co chyba szczególnie interesujące powinno być dla studentów oraz osób rozpoczynających swoją przygodę z testowaniem oprogramowania.

Uwagi końcowe

Uważam, że ta książka - mimo swych oczywistych wad - jest cenna. Po pierwsze, dlatego że jest jedną z nielicznych. Po drugie, dlatego że napisana została przez polskich autorów uwzględniających polskie realia prowadzenia projektów. A po trzecie, dlatego że napisanie książki o tematyce jakości oprogramowania oraz wydanie jej jest dla mnie symbolem i potwierdzeniem rozwoju tej branży w Polsce.

Książce można oczywiście wiele zarzucić jednak "jak się nie ma, co się lubi to się lubi, co się ma". Być może wśród czytelników znajdzie się ktoś, kto spróbuje napisać to lepiej, przejrzyściej i prościej. Jednak w jakiś tam sposób będzie to zasługa tej właśnie książki.

Brakowało czegoś, co nazwałbym "bardziej przyjaznym interfejsem". Porównując tą pracę do podobnych anglojęzycznych robi mi się smutno. Używanie wzorów powinno być naprawdę uzasadnione, słownictwo powinno ułatwiać a nie utrudniać zrozumienie treści tym bardziej, iż książka traktuje o jakości... jakości odbioru także.

Choć zaciemnia pewne terminy (np. przy opisie technik czarnej skrzynki przez domniemanie zakłada dostęp do kodu (sic!)) i rozmywa znaczenie innych, książkę tę poleciłbym dokładnie temu gronu, do którego zaadresowali ją autorzy. Doświadczonym inżynierom testów radziłbym traktować to jako swojego rodzaju "lekturę obowiązkową" bo "nie wypada" a nie jako źródło nowych i świeżych idei.

poniedziałek, 5 marca 2007

TiddlyWiki - notes i encyklopedia

Od dawna brakowało mi narzędzia do zarządzania notatkami. Typowe pliki tekstowe nie są zbyt atrakcyjne zwłaszcza gdy mówimy o kategoryzowaniu (a przecież drzewo kategorii nigdy nie jest zafiksowane).

A dzisiaj chyba znalazłem odpowiedź. Narzędzie nazywa się TiddlyWiki (http://www.tiddlywiki.com/) i działa tak jak system "Wiki" włącznie z tagowaniem. Wykonałem dzisiaj parę prób i naprawdę zapowiada się super tym bardziej, że jest to po prostu plik w JavaScripcie więc można go sobie zmodyfikować do własnych potrzeb.

Pomoc do tego narzędzia (nie jest wcale fantastyczna ale na początek wystarczy) znajduje się na stronach http://danielbaird.com/tiddlywikiguides/userguide-sample.html.

środa, 28 lutego 2007

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

wtorek, 27 lutego 2007

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.

poniedziałek, 26 lutego 2007

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.

czwartek, 22 lutego 2007

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

środa, 21 lutego 2007

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.

czwartek, 15 lutego 2007

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.

wtorek, 13 lutego 2007

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.

poniedziałek, 12 lutego 2007

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

sobota, 10 lutego 2007

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ść.