wszyscy znaczy nikt

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

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

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

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

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

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

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

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

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

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

Letarg

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

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

Wartści graniczne - przegląd

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

Kiedy nie przestać testować...

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

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

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

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

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

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

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

Wszystkiego najlepszego.

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

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

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.

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.

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