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.