IEEE 29119 - standard testowania oprogramowania

Na stronie http://www.softwaretestingstandard.org można znaleźć opis normy IEEE 29119 odnoszącej się do testowania oprogramowania w organizacjach. Od września 2013 jego trzy pierwsze części stanowią oficjalny dokument (na pewno ucieszy to sprzedawców certyfikatów).

Samego dokumentu niestety nie widziałem. Natomiast na wspomnianych stronach można znaleźć bardzo ciekawą specyfikację technik testowych (link). Moją ciekawość wzbudziła standaryzacja technika "Random testing" i "Error guessing".

Zastanawiające jest także dlaczego norma nie wymienia jako typu testów, testów regresyjnych. Znaleźć można natomiast "Conversion testing" co jest dla mnie nowością i nazwa nie mówi mi absolutnie nic. Łączę jednak intuicyjnie te testy z testami migracji danych.

Testy wydajnościowe i obciążeniowe zostały zgrupowane w "Performance-Related Testing," co nie ukrywam, ma w mojej ocenie swoją rację bytu. Ciekawy jestem również gdzie poukrywały się testy "high availability" i jakbym miał zgadywać to pewnie w "Disaster Recovery Testing".

W zakresie przypadków testowych, norma proponuje "Keyword-Driven Testing" co znaczy po polsku (tłumacząc ze strony):

"Testowanie słowami kluczowymi (Keyword-Driven Testing) jest sposobem opisywania przypadków testowych wykorzystującym zawczasu przygotowany zestaw słów kluczowych. Są to nazwy zbiorów akcji, których wykonanie jest wymagane do realizacji konkretnego kroku przypadku testowego. Korzystanie ze słów kluczowych zamiast z języka naturalnego w opisywaniu kroków testowych powoduje ich łatwiejsze zrozumienie, utrzymanie i automatyzację".

Trudno się nie zgodzić z takim twierdzeniem.

Na koniec można się także dowiedzieć, że norma IEEE 29119 definiuje model oceny procesu testowania (Process Assessment Model for software testing) oparty o normę ISO/IEC 33063.

Osobiście bardzo się cieszę, że proces testów doczekał się osobnej standaryzacji. Jestem przekonany, że pomoże to różnym organizacjom we wdrażaniu systematycznego, jednolitego i skalowalnego procesu testów. Oczywiście warunkiem jest zachowanie testerskiego sceptycyzmu w stosunku do normy i zdrowego rozsądku w jej implementacji.

"Nie chcę być członkiem klubu, który chce abym był jego członkiem"

Julius Henry "Groucho" Marx wśród wielu swoich powiedzonek ukuł jedno z moich ulubionych: "I don't want to belong to any club that will accept people like me as a member". Kiedy czytałem maila wysłanego do mnie z adresu "sjsi@sjsi.org" sparafrazowałem w głowie to powiedzenie w sposób następujący "Nie chcę być członkiem klubu, który chce abym był jego członkiem".

Przypuszczam, że list został wysłany przez "Stowarzyszenie Jakości Systemów Informatycznych". Piszę "przypuszczam" bo jest wiele powodów braku mojej pewności.

Poniżej przytaczam pełnego e-maila z wyjątkiem listy adresów e-mail, które SJSI raczyło mi dostarczyć.

Od: Komitet programowy
Data: 27 maja 2013 14:23
Temat: Zaległe składki SJSI
Do: (jawna lista adresów email wycięta przez TZ)
W chwili obecnej SJSI posiada w swoich strukturach wielu nieaktywnych członków zwyczajnych (osoby nie uczestniczą w pracach SJSI, nie płacą składki członkowskiej, nie ma z nimi kontaktu - dane kontaktowe są nieaktualne). Na spotkaniu Zarządu SJSI, które miało miejsce w Łodzi w dniu 2013.03.23, podjęto decyzję o uporządkowaniu listy członków zwyczajnych.
Do wszystkich członków SJSI zwracamy się zatem z prośbą o uregulowanie składki członkowskiej za rok 2013, co rozumiemy jako chęć pozostania w strukturach Stowarzyszenia. Osoby, które tej składki nie uregulują do końca maja 2013, oraz nie zapłaciły jej w latach 2011-2012 zostaną skreślone z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia.
Przydatne odnośniki:
- Statut Stowarzyszenia Jakości Systemów Informatycznych
- Dane do przelewu
Sebastian Małyska
Member of SJSI Board
e: s.malyska@sjsi.org | skype: sebam6
SJSI – Polish Association of the International Software Testing
Qualifications Board
Str. Poznanska 16 (r. 4), 00-680 Warsaw, Poland
http://www.sjsi.org

Członkiem stowarzyszenia zostałem bardzo dawno temu. Dokładnej daty nie pamiętam ale z całą pewnością było to przed rokiem 2008. Po zapłaceniu pierwszej składki w wysokości - chyba - 50 złotych - i rocznej hibernacji stwierdziłem, że nie chcę być członkiem stowarzyszenia. W statucie przeczytałem, że jeśli nie zapłacę następnej składki to po prostu zostanę usunięty z listy członków po dwóch latach (Paragraf 15, pkt.1, ppkt.3). A więc efektywnie od roku 2011 formalnie i zgodnie ze statutem nie byłem członkiem Stowarzyszenia. Niestety nie pamiętam czy podejmowałem próby rezygnacji w trybie paragraf 15, pkt. 1, ppkt. 1 więc się na to nie powołuję.

Z drugiego akapitu maila dowiaduję się, że zostanę skreślony "z listy członków Stowarzyszenia Jakości Systemów Informatycznych na mocy paragrafu 15, pkt.1, ppkt. 4 Statutu Stowarzyszenia". Zajrzałem więc do tego dokumentu i dowiedziałem się, że zostanę usunięty z listy członków SJSI za "zachowanie nie licujące z godnością członka Stowarzyszenia lub sprzecznego z celami Stowarzyszenia".

I tak oto stanąłem przed logicznym problemem: jak mogę zostać usunięty z listy członków Stowarzyszenia, którego członkiem formalnie nie jestem. Ta zagadka mnie rozbawiła bo paradoksalnie wskazuje na bałagan i brak jakości w Stowarzyszeniu, którego statutowym celem jest jakość.

Ponieważ nie życzę sobie aby ktoś publicznie pomawiał mnie o brak godności i długi postanowiłem napisać ten wpis i email (wysłany osobno) do Komitetu Programowego protestując przeciwko takiemu prowadzeniu komunikacji.

Studiując listę adresów dostarczoną mi przez SJSI zorientowałem się, że jakość jest bardzo umowna w tym kręgu, gdyż ze składkami zalegają prezes i dwóch wiceprezesów co jest po prostu czymś obrzydliwym i wskazuje na zaistnienie okoliczności, w których wskazany przez Sekretarza Stowarzyszenia podpunkt 4, punktu 1 paragrafu 15 powinien znaleźć zastosowanie, w przypadku gdyby to nie były pomówienia lub pomyłka - jak to mówią „ryba psuje się od głowy”. Mam nadzieję, że to jednak jest pomyłka i przeoczenie wynikające z "ręcznej" pracy nad listą adresów.

To co mnie jeszcze uderzyło, to brak jednoznacznego wskazania skąd mail pochodzi. W adresie nadawcy jest SJSI. W stopce znajduje się także skrót SJSI rozwinięty jako „Polish Association of the International Software Testing Qualifications Board” a adres pocztowy podany jest w formacie angielskim. Jedyne wskazanie na wprost jest w postaci linka do statutu stowarzyszenia.

Jestem testerem oprogramowania z wieloletnim stażem i na co dzień wiem jak trudno jest zdefiniować jakość i jak łatwo jest ją "pogubić". Dumny jest z wykonywanego przeze mnie zawodu! Tym bardziej jest mi przykro, że Stowarzyszenie, które powstało w celu „wspierania członków Stowarzyszenia w zakresie edukacji dotyczącej testowania i zapewnienia jakości” poległo na tak prostej rzeczy i zapomniało o ludziach. A przecież jakość w systemach informatycznych istnieje przede wszystkim przez ludzi i dla ludzi – parafrazując kolejną postać historyczną.

Reasumując, bardzo się cieszę, że takie stowarzyszenie istnieje i stara się działać w zakresie jakości oprogramowania. Jednak namawiałbym członków i osoby odpowiedzialne za tę organizację aby mniej skupiali się na „sprzedaży słowników” – bo za coś takiego uważam ISTQB – a bardziej skoncentrowali się na realnych wyzwaniach i potrzebach w zakresie testów.

Testowanie oprogramowania – jako jedna z gałęzi informatyki – staje przed wieloma wyzwaniami. Jest coraz więcej platform mobilnych, coraz więcej urządzeń. Integracja oprogramowania i urządzeń postępuje bardzo szybko. Oczekiwania użytkowników rosną w miarę rozwoju – zwłaszcza w zakresie systemów czasu rzeczywistego lub „prawie rzeczywistego”. Funkcjonalność jest implementowana w coraz większym rozproszeniu. Coraz więcej oferowanych jest usług złożonych (np. w "chmurze").

Kilkuletnie doświadczenie z ISTQB wskazuje, że skupianie się na nazewnictwie artefaktów nie przyniesie tutaj żadnej ulgi a sprzedaż certyfikatów nie doprowadzi do rozwoju wiedzy i doświadczenia oraz umiejętności radzenia sobie z rosnącym skomplikowaniem rozwiązań informatycznych. Uważam, że zawód testera polega na umiejętności rozwiązywania problemów "testerskich" i ten kierunek sugerowałbym Stowarzyszeniu.

PS: Dzisiaj przyszedł z SJSI email w tonie bardziej pojednawczym wymuszonym, jak wynika z treści przez reakcję adresatów pierwotnej korespondencji.

Forum jakości systemów informatycznych

Sześć firm i organizacji zajmujących się jakością systemów informatycznych w Polsce organizuje "Forum jakości systemów informatycznych". Wydarzenie odbędzie się  pomiędzy 21 a 22 maja 2013 roku w hotelu "Courtyard by Marriott Warsaw Airport" w Warszawie. Pełna informacja dostępna jest pod linkiem http://www.computerworld.pl/konferencja/jakosc2013.

Pierwszy dzień konferencji podzielony został na dwie części: sesję plenarną oraz dwie sesje tematyczne. Sesje tematyczne zajmują się albo zarządzaniem jakością albo zarządzaniem projektem (nie wiem dlaczego organizatorzy zdecydowali się nazwać to z angielska "project management"?) pochylając się następnie nad samym testowania.

Zamknięcie dnia planowane jest 50 minutową dyskusją na temat "Jakość w świecie IT - ideał i cel czy tylko pusty slogan?"

Drugi dzień zaczyna się od sesji plenarnej aby około południa przerodzić się w warsztaty.

Tematyka wydaje się bardzo szeroka, od standardów poprzez metodyki testowania i zapewniania jakości, po zagadnienia związane z przywództwem i rynkiem pracy.

Zdecydowanie jest to inicjatywa, którą warto popierać. Wydarzenia tego typu sprzyjają poszerzaniu wiedzy, zbieraniu inspiracji i weryfikowaniu własnych przekonań zawodowych. I chyba nie jest łatwo zorganizować takie spotkanie (nawet w tej chwili cztery prezentacje mają jeszcze nieustaloną tematykę).

Życzę organizatorom i prelegentom sukcesu i mam nadzieję, że wydarzeń tego typu będzie pojawiać się w Polsce więcej. Może pora uświadomić sobie, że testowanie nie jest oddzielnym "kościołem" ale jednym z etapów łańcucha wytwórczego oprogramowania a zapewnianie i zarządzanie jakością jednym z koniecznych instrumentów pozwalających zapewnić firmom świadome dostarczanie produktu a klientom realizację ich wymagań.

Plan minimum

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

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

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

rzemiosło / umiejętność / sztuka

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

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

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

wszyscy znaczy nikt

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

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

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

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

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

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

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

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

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

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

Letarg

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

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

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.

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

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.

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

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.

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

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

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

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.

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

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

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?