Testy modułowe albo mit pokrycia

Nie sądziłem, że ten post jest konieczny, ale wygląda na to, że dopadł mnie syndrom Blutfelda.

<dygresja>
Tych, którzy nie wiedzą, o co chodzi z Herr Blutfeldem, odsyłam do powieści Jacka Dukaja "Lód". W dużym skrócie Herr Blutfeld, jeden z drugoplanowych bohaterów wyżej wymienionej powieści, nie zabiera głosu w prawie żadnej dyskusji, których w opowieści jest naprawdę mnogo. W czasie, kiedy inni współpasażerowie Kolei Transsyberyjskiej spierają się żywo i efektownie, on woli oddawać się przyjemności jedzenia wszystkiego, co da się zjeść, od czego nabawił się paru dodatkowych podbródków.

Podczas jednego z postojów Herr Blutfeld nie wytrzymuje i wybucha. Okazuje się, że nie jest głupawy ani pozbawiony własnych poglądów - przeciwnie! Nie zgadza się z żadnym ze współpasażerów i uważa wszystkie ich opinie za głupie, nietrafione i kretyńskie. Problem w tym, że za każdym razem kiedy ma się już odezwać i wytknąć towarzyszom błędy w rozumowaniu, dochodzi do wniosku, że nie ma najmniejszego sensu się odzywać ponieważ wszystko, co ma do powiedzenia jest oczywiste! O-czy-wis-te! Nie ma sensu zużywać tlenu i drażnić neurony; tracić energię na tłumaczenie rzeczy tak prostych i po trzykroć oczywistych.

Podczas swojej przemowy nasz bohater ani na chwilę nie przestaje jeść. Priorytety!
</dygresja>

Przechodząc do rzeczy:
Ostatnio w rozmowie z dość kompetentnymi ludźmi usłyszałem taką opinię:

Nasze testy modułowe są dobre ponieważ mamy wysokie pokrycie kodu.

Photo by roxj

Na początku pomyślałem, że kolega sobie zażartował, ale ponieważ mój czujnik sarkazmu nawet nie drgnął, zapytałem czy oby na pewno nie raczył żartować... Niestety nie. Witki mi opadły. Gratulacje! Odkryliśmy pewną miarę jakości testów modułowych! Nie potrzebujemy o nich już żadnych książek, szkoleń ani dobrych praktyk! Wiemy już wszystko!


W dużym skrócie:
Dobre testy będą miały wysokie pokrycie kodu, ale wysokie pokrycie nie zagwarantuje nam, że testy są dobre. Dlaczego? Zastanówmy się, czym jest pokrycie kodu... to że linia kodu jest pokryta podczas testu oznacza, że w ramach wykonania testu ta linia została odwiedzona, nic więcej. Procesor przemielił instrukcje, które stały pod tą linią kodu. Nie ma tu mowy o sprawdzaniu, czy te instrukcje zrobiły to, czego się spodziewaliśmy. Nie ma nawet słowa o tym, czego się spodziewaliśmy.

Dobre testy dokładnie określają czego się spodziewamy, łącznie z tym, co się nie powinno wydarzyć... problem jest taki, że do tego opisu ciężko przypiąć liczbę.
Jest to zaleta, którą mierzenie pokrycia posiada i która jest niestety nadużywana.

Języki a Programowanie

Chodzi mi o to, żeby język giętki
powiedział wszystko, co pomyśli głowa.

-- Juliusz Słowacki

Jakiś czas temu został mi polecony artykuł "Mowa duszy" z Wiedzy i Życia (09/2011), który traktował o zależnościach pomiędzy myśleniem, a mówieniem. Jedna z ciekawych obserwacji dotyczyła osób bilingualnych, płynnie posługujących się dwoma językami, często wychowanych w dwóch kulturach w wyniku np. przeprowadzek. Eksperymenty pokazywały, że osoby te myślały na dwa różne sposoby, kiedy przedstawiło im się to samo pytanie w dwóch językach. Badania aktywności mózgowej pokazywały aktywacje innych obszarów w mózgu w odpowiedzi na pozornie tę samą treść. W moim mózgu pojawiła się iskierka.

Photo by Manjith Kainickara

Druga, równie ciekawa informacja dotyczyła pewnego chłopca z jakiegoś małego plemienia, gdzieś w inaczej cywilizowanym świecie. Badacz opowiadał, że dostrzegł wyjątkową płynność ruchów u jednego z młodych tubylców i postanowił nauczyć go tańczyć, ale jego wysiłki spełzły na niczym. Na czym polegała trudność? Naukowiec poległ, kiedy chłopak nie mógł zrozumieć, co to znaczy, że ma wykonać krok w prawo albo w lewo. Plemię, z którego młodzian pochodził nie znało pojęcia kierunków względnych. W ich kulturze wszystko znajdowało się na północ, wschód, zachód lub południe od punktu odniesienia. W takiej sytuacji dość ciężko opisać np. walca wiedeńskiego, który polega przecież na ciągłych obrotach. Nie chodzi o to, że nie da się tego zrobić, jest to po prostu bardzo trudne. Iskierka w moim mózgu przeskoczyła.

Z powyższych informacji i własnych doświadczeń mogę wysnuć pewien wniosek - warto uczyć się różnych języków, również programowania. Różne języki programowania uczą różnych idei; i nie chodzi o to, że program P napisany w języku A jest nie do napisania w języku B... ale często jest tak, że ten sam program w języku B jest najgorszym koszmarem programisty, podczas gdy w języku A to zaledwie parę prostych linijek kodu. Tak jak pewne tańce nie powstałyby w kulturze absolutnych kierunków, tak niektóre pomysły nie powstałyby w Assemblerze i C.

Do tematu jeszcze pewnie nie raz wrócę, bo czuję, że dotyka czegoś ważnego.

Jakość

Ten tekst jest wynikiem przeczytania książki "Zen i sztuka obsługi motocykla" Roberta M. Pirsinga i prawie roku przemyśleń własnych. Ze względu na brak przygotowania filozoficznego autora, tekst ma niezwykle mierną wartość merytoryczną. Zostaliście ostrzeżeni!

Jakość to subiektywna miara cukru w cukrze.

Photo by BrianScott

Niech powyższa myśl trochę powisi, a ja spróbuję nakreślić pewien obraz.

Znacie to uczucie, kiedy stoi przed wami dobrze znane zadanie? Dla osób sprawnych manualnie może być to opakowanie ładnie prezentu albo zrobienie wełnianego szalika. Jeżeli ktoś ma bardziej specyficzne zainteresowania, to może być to lutowanie dobrze przygotowanego układu albo zrobienie bukietu kwiatów z origami; sadzenie kwiatów w ogrodzie lub, wspomniana wcześniej, naprawa motocykla. Uczucie, o którym mówię rodzi się wtedy, kiedy wszystko idzie jak należy - wszystkie potrzebne elementy są zawczasu przygotowane i mamy dość czasu na całe zadanie - nic nas nie goni, nic nas nie popędza. Ruchy rąk są spokojne, ulubione narzędzia znajomo leżą w dłoni, tworzywo jest giętkie i posłuszne naszej woli. Powoli rodzi się wytwór naszej pracy - dokładnie taki, jaki powinien być. Znacie ten spokój umysłu? W takich warunkach dzieje się "dobra robota" i właśnie wtedy rodzi się wysoka jakość.

Podobne wrażenie możemy mieć, kiedy używamy porządnych rzeczy. Na przykład kiedy instynktownie wiemy co nacisnąć na naszym nowym odtwarzaczu, żeby znaleźć piosenkę, na którą mamy akurat ochotę; albo którą gałką nastawimy głośność radia, zamiast je rozregulować. Przedmioty, z których z łatwością korzystamy dają nam podobny rodzaj spokoju umysłu. Niemniej chciałbym się teraz skupić na jakości pracy, bo z niej wynika zazwyczaj jakość rzeczy.

Opisane powyżej wrażenie jest bezpośrednim przeżyciem jakości, która w mojej ocenie jest brakiem rozdźwięku pomiędzy tym, jak jest, a jak być powinno. To cukrowość cukru i nożowość noża jednocześnie. Nie ma mowy o żadnej konkretnej cesze, a o zbliżeniu do ideału. Pachnie trochę Platonem, ale to jest właśnie moim zdaniem Jakość.

Jest też zupełnie inne uczucie, które wynika z czegoś, co złośliwi nazywją połączeniem praktyki z teorią:

TEORIA jest wtedy kiedy wszystko wiemy a nic nie działa.
PRAKTYKA jest wtedy kiedy wszystko działa a nikt nie wie, dlaczego
U nas w firmie łączymy teorię z praktyką:
NIC NIE DZIAŁA I NIKT NIE WIE DLACZEGO.

-- autor nieznany

Z reguły zaczyna się zupełnie niepozornie - ot, zwykła niemożność skupienia myśli, lekka irytacja, że nie ma czasu nawet na porządne przygotowanie się do pracy. Potem papier rozcina skórę na palcu, który trzeba szybko opatrzyć i akurat teraz zabrakło plastra; albo okazuje się, że nożyczki są tępe i bardziej strzępią niż tną. Do mózgu ciągle puka wskazówka zegara i rosnąca świadomość innych obowiązków powoduje drenaż myśli. Stajemy się rozdrażnieni, efekty naszej pracy odstają coraz wyraźniej od naszych oczekiwań i z chaosu nigdy nie wyłania się porządek. Tym jest właśnie, dla mnie, brak jakości.

Zdaję sobie sprawę, że nie każdy się z tymi opisami zgodzi - są ludzie, którzy czują, żepowinno być inaczej, że prawda tkwi w ruchu, w dynamice, że autentyczna jakość może wynikać tylko z ciągłej zmiany. Każdy ma inaczej, ja mam akurat podejście rzemieślnicze. Jakość jest często subiektywna i, tak jak napisałem powyżej, chodzi o "brak rozdźwięku pomiędzy tym, jak jest, a jak być powinno". Każdy ma swoją wizję sytuacji idealnej, ale ten brak rozdźwięku uspokaja umysł - chyba każdy umysł.

Photo by MarkGrundland

Z powyższej subiektywności wynika jeszcze jedna rzecz -- odpowiedzialność za jakość leży też po stronie odbiorcy. Weźmy na przykład moją ignorancję w kwestii spawania. Nie mam o spawaniu zielonego pojęcia. Gdybyście pozwolili mi porównywać dwa spawy godzinami, to pewnie i tak nigdy nie doszedłbym do wniosku, który z nich jest lepszy. Znam za to osobę, która potrafiłaby dokonać takiego porównania w mig. Ja się na tym po prostu nie znam - nie mam pojęcia, jak być powinno. Potrafię ocenić szybko, czy design telefonu czy programu jest dobry, wiem na co zwracać uwagę, wiem czego się spodziewać po dobrym programie... ale na spawaniu, wybaczcie, nie znam się i pewnie nigdy się nie poznam.

Dlaczego o tym wszystkim piszę? Bo my, początkujący programiści, mamy dość często poczucie, że nie jest tak, jak być powinno; że spokój umysłu z nas ulatuje, kiedy zabieramy się do pracy... Dlatego chciałbym zostawić Was z poniższymi pytaniami:

• Czy kiedy zabierasz się do swojej codziennej pracy masz poczucie niepokoju, że coś się zaraz... khem... popsuje?
• Czy korzystając ze swoich codziennych narzędzi pracy masz wrażenie, że je znasz i że wiesz, czego możesz się po nich spodziewać?
• Możesz coś z tym poczuciem robić i uspokoić swój umysł? Robisz to?
• Czy dbasz o jakość?

Nie zawsze mogę szczerze odpowiedzieć "tak" na te wszystkie pytania... ale się staram!

Design of Everyday Things - recenzja

Zwróćcie uwagę na czajnik masochistów...

Do dzieła Donalda A. Normana podchodziłem z pewną rezerwą. Gdyby nie rekomendacja Joela Spolsky'ego, nigdy nie sięgnąłbym po książkę traktującą o projektowaniu rzeczy codziennych. Albo o psychologii, bo na dobrą sprawę nawet tematyka książki nie jest oczywista, ponieważ wcześniej była wydana pod tytułem "Psychology of Everyday Things". Czyli książka o psychologii, projektowaniu drzwi i telefonów, czy może o czymś więcej?

Ta książka jest definitywnie (o) czymś więcej. Chociaż rzeczywiście głównym tematem są przedmioty codzienne: ich wygląd, funkcjonalność i praktyczność, to centrum uwagi przesunięte jest na relacje pomiędzy tymi przedmiotami, a ich użytkownikami. Przecież takie kategorie jak "użyteczność przedmiotu" mogą rodzić się tylko na styku natury ludzkiej i używanego narzędzia. Książka pokazuje jawnie, jak my, ludzie, odnajdujemy się w rzeczywistości - jak nasze mózgi uczą się otaczającego ich świata, na co zwracamy uwagę i jakie błędy popełniamy najczęściej w interakcjach z przedmiotami.

Autor, wieloletni badacz psychologii poznawczej, jest według mnie wyjątkowo wiarygodny w tym co i jak pisze. Myśli zapisane zostały w sposób jasny, obrazowy i logiczny, bez niepotrzebnych dygresji czy nudnych wywodów teoretycznych. Sama książka jest przykładem dobrego projektowania - układ jest czytelny, struktura dobrze przemyślana i konsekwentna. Humor pojawiający się w tekście jest nienachalny i nie odwraca uwagi od sedna problemu.

Co jednak jest najważniejsze, ta książka zmienia życie czytelnika na zawsze. Naprawdę, to nie jest marketingowy slogan - jeżeli przeczytasz tę książkę, Twoje życie ulegnie zauważalnej zmianie. Po przeczytaniu jej, już nigdy nie spojrzysz na otaczające Cię przedmioty w ten sam sposób. Ma to w pewnym sensie wymiar terapeutyczny, bo przestaniesz obwiniać się za to, że nie wiesz jak obsłużyć swoje radio, telewizor czy firmowy ekspres do kawy. Nawet jeżeli natkniesz się na drzwi, których nie będziesz potrafił w pierwszej chwili otworzyć, będziesz widział(a) jasno i wyraźnie, na czym polega problem, a nawet będziesz miał świadomość co należałoby zrobić, żebyś się więcej nie pomylił.

Anegdotka: mój brat wraz ze swoją żoną mają piękną kuchnie - dizajnerską. Wszystko jest w niej ładne, estetyczne, minimalistyczne. Kiedy wszedłem tam po raz pierwszy, bardzo mi się to spodobało - wszystko było takie nieskazitelnie proste i piękne. Kiedy wszedłem tam kolejnym razem, tym razem po szklankę, a nie tylko w ramach zwiedzania, okazało się, że nie potrafię otworzyć żadnej z szafek. Żadnych uchwytów, rączek, klamek - niczego poza płaską powierzchnią drzwi. Dopiero brat musiał przyjść i uświadomić mi, że na drzwi trzeba nacisnąć (oczywiście należy też wiedzieć, po której stronie drzwiczek należy naciskać). Wtedy było mi trochę głupio, przecież to takie proste a ja, inżynier, nie potrafię tego zrozumieć. Dziś widzę to zupełnie inaczej. Kuchnia jest dla ludzi niewprawionych nieużyteczna. Za to wiem, jak można by to poprawić! Przeczytajcie tę książkę, a też będziecie wiedzieć. ;-)

Co jest szczególnie interesujące, autor pokazuje nam pewien wzór, który wyłania się z historii projektowania użytkowego - wzór, który powtarza się zawsze wtedy, kiedy nasza cywilizacja dokonuje wielkiego odkrycia technologicznego. Cykl ten miał miejsce już przy okazji pojawienia się na naszej planecie pierwszych telefonów, samochodów, odbiorników radiowych, a teraz także komputerów. Pierwsze egzemplarze tych urządzeń miały jedną wspólną cechę - były kompletnie nieużyteczne. Potem stopniowo stawały się coraz przyjaźniejsze w użyciu, aż do uzyskania optimum, kiedy absolutnie wszyscy potrafili je obsłużyć ... a co się działo potem? W wyniku konkurencji na rynku, chęci zadowolenia klientów i potrzeby innowacyjności, zaczynał się proces dokładania nowych, lepszych funkcjonalności... urządzenia puchły, stawały się coraz trudniejsze w obsłudze, coraz mniej dla ludzi i kiedy już tylko wąska grupka zapaleńców potrafiła je dobrze obsługiwać, trzeba było znów zacząć od początku. Już się nie mogę doczekać kolejnej generacji smartfonów!

Jest w tej książce zawarty kolejny aspekt terapeutyczny, tym razem skierowany do projektantów - twórców otaczającej nas rzeczywistości. Ta książka pokazuje, że projektowanie jest trudne. Ilość kompromisów i wyborów, które trzeba podjąć projektując zwyczajny kran, drzwi czy telefon jest zaskakująco duża... a liczba ta rośnie dla rzeczy bardziej skomplikowanych. Radia, telewizory, odtwarzacze multi-multimedialne i w końcu programy komputerowe. Tak więc projektowanie zawsze będzie wymagało kilku-kilkunastu podejść, zanim zrobi się to dobrze. Tak zwyczajnie jest, wzorzec się nie zmienia. Dlatego warto sobie czasem odpuścić - robić swoje, najlepiej jak się potrafi i cieszyć się z każdego małego sukcesu, a potem testować i poprawiać, testować i poprawiać, testować i poprawiać... ad mortem defecatum.

Podsumowując: polecam tę książkę każdemu. Jesteśmy otoczeniu oceanem przedmiotów - ta książka jest całkiem przyzwoitą mapą wskazującą bezpieczne przystanie i niebezpieczne rejony.