Jakość do Poznania czyli wrażenia z Testwarez 2012

Chwała!

Na początku przedostatniego łykendu października (22-23) miałem okazję być oddelegowany do udziału w konferencji poświęconej jakości oprogramowania - Testwarez. Tegoroczna edycja tego wydarzenia organizowanego przez SJSI odbyła się w Poznaniu, w salach konferencyjnych hotelu Mercure. W ciągu dwóch dni w planach był szereg prezentacji (część w dwóch równoległych ścieżkach), warsztaty oraz walne zgromadzenie wspomnianego stowarzyszenia. W tej relacji, na początek przegląd prezentacji na które się wybrałem, na koniec zaś zostawię sobie ocenę organizacji i ogólną konferencji jako takiej. Zapraszam.

Tłumne zgromadzenie inspiruje, czyli o lekko bajeranckim testowaniu krotek słów kilka

Chwała!

Jak uważni, stali Czytelnicy wiedzą, ledwo co byłem na Najlepszej Z Konferencji. Jednakże któż by przypuszczał, że tak szybko nadarzy się okazja do praktycznego i zarobkowego wykorzystania inspiracji z tego wydarzenia?

Tym razem nadarzyło się wykorzystać zasiane ziarno pomysłów przez Bartka Kuczyńskiego, znanego też pod mianem Koziołka. I właściwie, najbardziej w tym wszystkim zaskakujące było, że sam wcześniej na to nie wpadłem.

 - No dobra, ale może wreszcie ktoś wyjaśni o co się rozchodzi? - zapytacie Państwo. No więc, detalicznie i szczegółowo rozchodzi się o rozwiązanie następującego problemu. Otóż, dostałem do sprawdzenia mechanizm czegoś, co można nazwać generowaniem raportu dla instytucji zewnętrznej. Raport ten jest zestawieniem sumarycznym danych zebranych z kilku tabel, przy różnych również warunkach wyboru odpowiednio od typu rozpatrywanego "głównego obiektu".

Księżycowe zmiany zależne

Chwała!

Ostatnio chciałem zmienić sobie w projekcie mavenowym zależności od Selenium do najnowszej wersji 2.0 beta 3. Sprawdziłem w nexusie, że jest taka wersja w repo, więc żwawo zmieniam wpis w pliku pom na:

    org.seleniumhq.selenium
    selenium
    2.0b3

Import, i... i jakaż to siurpryza, nie działa! No, żesz Ty, jak Cię w pierwszą krzyżową kopnę mavenie jeden! Ale też nie pomogło. Dopiero dokładniejsze sprawdzenie dokumentacji doprowadziło do eureki, iż od wersji beta 2 należy wpis w pomie zmienić na poniższy:

    org.seleniumhq.selenium
    selenium-remote-control
    2.0b3

I teraz świszczy, hula aż miło popatrzeć.

P.S. Pewnie uważni Czytelnicy zauważyli małą zmianę. Po jej uzasadnienie odsyłam tutaj.

VIII Spotkanie Szczecińskiej JUG - trema debiutanta

Sława!

Prawie rok po poprzednim spotkaniu (mam nadzieję, że na następne aż tak długo czekać nie będzie trzeba), 22. dnia kwietnia, odbędzie się kolejne, już ósme spotkanie. Tym razem, jak można zauważyć w zapowiedziach, produkować się będzie moja nieskromna osoba. Debiut całkowity na JUG, co gorsza ostatnie publiczne wystąpienie miałem, o ile pamiętam, dobre pięć lat temu z kawałkiem (ściślej mówiąc w trakcie obrony pracy magisterskiej). Biorąc pod uwagę, że wystąpienia takie (w moim odczuciu) nie są moją mocną stronę, więc trema jest nie mała.

Czego się możecie spodziewać? O ile mi się uda zrealizować własne zamierzenia (czyt. nie zeźre trema, czasu wystarczy, w gardle nie zaschnie, nic się, odpukać, nie zepsuje, etc.) chciałbym P.T. Uczestnikom Spotkania zaprezentować możliwości podbudowy testowej o wdzięcznej i dźwięcznej nazwie TestNG (co można wywnioskować z tytułu spotkania ;)), przy czym przyjmując założenie, że przynajmniej większość wspomnianych Uczestników miała styczność z JUnit, nie zamierzam dokonywać porównywania tych dwóch podbudów wprost, licząc na wyciąganie wniosków samodzielnie. Znaczy się, nie spodziewajcie się przykładów jak to samo zrobić w tym i w tamtym. Myślę, że ze względu na specyfikę tych podbudów, a także znaczne podobieństwa i różnice, nie ma to większego sensu i mogłoby raczej co najwyżej zamotać niż wyjaśnić.
Zamierzam również pokazać trochę kodu w działaniu, mimo, że Paweł Szulc na ubiegłorocznej Javarsovii był bardzo zadowolony z efektu wstawiania zrzutów ekranowych do prezentacji, ale w tym wypadku jednak nie będzie jakiś mocno czasochłonnych kompilacji (co innego przekompilowanie i umieszczenie jakiegoś potężnego serwisu sieciowego, tu zrzuty ekranowe pomagają oszczędzić mocno na czasie ;)). Jeśli zostanie czasu nie widzę przeszkód w odpowiadaniu na wątpliwości Słuchaczy przez szybkie podkodowanie tego i owego.
Czego zaś na pewno nie będzie? Niestety, nie uda mi się zaprezentować jednej, bardzo ciekawej i potężnej funkcjonalności dostarczanej przez TestNG ze względów... technicznych (w myśl zasady, że szewc bez butów chodzi, to ja sprzętowo do tyłu jednak jestem...). Jednakowoż coby nie zniechęcać, to co to jest wspomnę na prezentacji dopiero. Dodam tylko, że ten „pominięty” temat to jest dobry materiał na osobną prezentację.
Nie będzie też obcowania z prawdziwym guru, gdyż tak jak P.T. Czytelnikom pewnie wiadomo, prezentacja ta powstawała przez tak zwane „rozpoznanie bojem” i raz, że codziennie się dowiaduję czegoś nowego, a dwa, że mogę się nie zdążyć dowiedzieć przed prezentacją. Szczególnie jeżeli chodzi o jakieś bardziej wymyślne i zaawansowane „sztuczki i kruczki”.
Podsumowując, serdecznie zapraszam, mając jednocześnie nadzieję, że uda mi się spełnić zarówno Wasze jak i moje, własne oczekiwania. A ponieważ zostało jeszcze trochę czasu, to jeśli ktoś ma jakieś uwagi, zachcianki i inne roszczenia co do prezentacji to może je umieścić w komentarzach. Obiecuję, że się nad nimi zastanowię, natomiast nie obiecuję pozytywnego rozpatrzenia. ;)

Uprzednio żyżnego pola ryżowego kłopoty

Sława!

Nie tak całkiem odległy czas temu świat obiegła kolejna informacja o kłopotach w samochodach marki Toyota. Tym razem "bohaterem" całego zamieszania była tajemnicze, jak na razie, zablokowanie się pedału gazu w jednym z egzemplarzy modelu Prius. Całe to zamieszanie pewnie przeszłoby obok mnie niezbyt zauważone, gdyby nie jeden drobny fakt.

Mianowicie głównym podejrzanym tej awarii było (nadal jest?) oprogramowanie obsługujące pedały w tymże nowoczesnym pojeździe (taki analog do lotniczej technologii fly-by-wire). Ten fakt oraz późniejsze stanowisko producenta (w skrócie: "to niemożliwe, testowaliśmy") wywołało szereg komentarzy osób związanych z wytwarzaniem oprogramowania i jego testowaniem. Myślę sobie, że każdy mający coś wspólnego z tymi czynnościami znajdzie w nich interesujące spostrzeżenia, a szczególnie w:

• artykule Davida M. Cummingsa w L.A. Times, gdzie Autor poprzez przykład z własnego doświadczenia (misja Mars Pathfinder) zwraca uwagę, że nieumiejętność powtórzenia danego błędu, nie oznacza, że on nie wystąpił lub, że nie wystąpi kolejny raz. 
• Oraz dwa wpisy Jamesa Bacha na jego blogu - Porady dla prawnika i Analiza całej tej historii, w których to Autor wykorzystuje ten przykład do pokazania różnego rodzaju pułapek, które czyhają w procesie produkcji i testowania oprogramowania.

Miłej lektury!

Cierpliwości cnotą obdarzeni wynagrodzeń zostali...

Sława!

Ponieważ tak się złożyło, że od jakiegoś czasu "technicznie" zajmuję się tak mało medialnymi, a do tego raczej dość dobrze powszechnie znanymi, rzeczami, o których to już tysiące, albo i miliony, słów powiedziano, to i nie dziwota, iż ostatnie wpisy takie raczej kulturalne. A, że i raczej szykują się prędzej kolejne w tej m(an)ierze (przynajmniej do czasu, aż, lelum polelum, mi radocha z komputra wróci ;)) niż o berach, bojkach i innych bitach, to coby smak przełamać, taka lekka wstaweczka wiadomościowa się dziś trafi.

Otóż, po miesiącach niecierpliwego oczekiwania, udostępniona została pierwsza z prezentacji jakie zostały zarejestrowane podczas tegorocznej Konferencji. Prelegentowi, kamerzystom, montażystom, dźwiękowcom i wszystkim innym osobom maczającym palce w Produkcji składam niniejszym podziękowania i gratulacje za wysokiej jakości materiał. Pozostałych natomiast szczerze namawiam do zapoznania się. Warto!

Parę słów o kontekstem gnanym testowaniu

Sława!

Najnowszy wpis na blogu Jamesa Bacha przypomniał mi, że już dawno miałem wspomnieć parę słów o, nazwijmy to szumnie metodologią, testowaniu gnanym kontekstem (Context-driven-testing). Idea stojąca za tym podejściem jest chyba najbliższa moim intuicyjnym wyczuciom na czym testowanie powinno polegać, i staram się jakoś lepiej lub gorzej wprowadzać sobie w życie, i może coś z tego wyjdzie. Całość opiera się na siedmiu podstawach, które pozwolę sobie przetłumaczyć (pewnie nie najlepiej, ale co mi tam, najwyżej ktoś mądrzejszy mnie poprawi i szlag trafi cały zachwyt ;)):

1. Wartość każdego postępowania (podejścia, praktyki) zależy od jego kontekstu.
2. W danym kontekście są dobre praktyki, ale nie ma tej najlepszej.
3. Ludzie pracujący razem, są najważniejszą częścią w kontekście każdego projektu.
4. Rozwój projektów, w miarę czasu, często nie podąża przewidywalnymi ścieżkami.
5. Produkt jest Rozwiązaniem. Jeśli zadany problem nie jest rozwiązany, produkt nie działa.
6. Dobre testowanie oprogramowania jest wymagającym (i stawiającym wyzwania) procesem intelektualnym.
7. Tylko rozsądkiem i wprawą, zaprzątniętymi razem podczas całego projektu, jesteśmy zdolni do wykonania właściwych czynności we właściwym czasie, aby skutecznie testować nasze produkty.

Tylko tyle, i aż tyle, bo jak pokazuje nie raz bliższa lub dalsza praktyka, nie wszystkim poszczególne punkty wydają się prawdziwe, a szkoda.

Po więcej informacji (w języku angielskim) zapraszam na stronę http://www.context-driven-testing.com/ , gdyż na prawdę warto się zapoznać. Nawet jeżeli uznacie, że sobie można o kant czterech rozbić.

VII spotkanie Szczecin JUG - parę słów komentarza

Sława!

Krytykować jest łatwo, więc dlaczego by się krępować? Sami widzicie, że nie ma co. Więc przystępuję do Dzieła Zniszczenia. Dzieło Zniszczenia zacznę od słów podziękowania i gratulacji dla szczecińskiego ZDiTM za świetny rozkład jazdy tramwajów, dzięki czemu zaoszczędziłem jakieś 20-25 minut wstępu, pewnie nudnego jak zawsze ;)

Jak już dotarłem na miejsce spotkania, na moje szczęście (bo kto lubi teorie? ;)) kończyła się część teoretyczno-wprowadzająca i kolega Michał powoli przechodził do clou programu, czyli Selenium i Jameleon.

Niestety jak na mój gust, za bardzo przegadane, za mało przykładów "na żywo" (I nie mówię tu nawet o pisaniu testów na żywca, ale aż prosiło się o przykłady testów ciut bardziej wykorzystujących możliwości narzędzia). Także wydaje mi się, że za mało pokazał czystego Selenium, i dopiero w porównaniu z nim, podejście oparte o Jamelona.

Dlaczego tak mi się wydaje? Po reakcjach publiki, która trochę nie bardzo chyba załapała o co w tym Jameleonie jest fajnego (lub nie). Bo bądźmy szczerzy, da się taki sam efekt (mniejszym lub większym kosztem) uzyskać podpinając Selenium RC pod JUnit lub TestNG. A Jameleon na pierwszy rzut oka wygląda trochę dziwnie, i łatwo się zrazić do niego, na zasadzie "a po co mi taka kobyła?". I takiego porównania jak to samo wygląda w jednym i drugim podejściu, i jakie korzyści i jakie wady przynosi stosowanie jednego i drugiego narzędzia mi generalnie zabrakło. Ale poza tym to było całkiem, całkiem, i nawet, o dziwo, trochę pytań było po prezentacji.

Więc, mimo wszystko, brawa (tym bardziej, że łatwo się piszę komentarze, jak samemu się nic nie prezentuje).

P.S. Oczywiście znów nic nie wygrałem ;)

P.S. 2 - W związku z P.S. poprzednim i naciskami Leszka, może by się skusić na prezentacje? Tylko o czym by tu...

Recenzja: Perfect Software and other illusions about testing.

Sława!

Trochę trwało, bo i zajęć różnorakich innych było, ale wreszcie się udało zakończyć lekturę dość świeżej pozycji autorstwa Geralda M. Weinberga pod tytułem „Perfect Software and other illusions about testing”. Pozycja ta, zgodnie z tytułem odnosi się do zagadnień związanych z testowaniem oprogramowania, a jej autor posiadający ponad półwieczne doświadczenie w szeroko pojętej branży programistycznej jest cenionym konsultantem i autorem książek o równie szeroko rozumianym wytwarzaniu oprogramowania.

Wracając do książki. Pisząc krótko jest to napisany bardzo przystępnym językiem i okraszony anegdotkami z życia (z których najbardziej zapadła mi w pamięć ta, okraszająca tezę, że nie ma złych programów, gdzie testerzy używali programu, w zamierzeniach autora mającego służyć do obliczeń fizycznych, jako niezawodnego narzędzia do... wywalania w kosmos systemu operacyjnego) swego rodzaju poradnik o używaniu testów (wszelakich jako całości). Poradnik do tego bardzo nietechniczny, głównie bazujący na naturze ludzkiej i konsekwencjach z nią związanych, i to ją przeważnie ustawiający jako źródło sukcesów i porażek.

Natomiast bardziej szczegółowo, mamy do czynienia ze 169 stronami podzielonymi na 18 rozdziałów na których Autor m.in. rozprawia się z różnorakimi mitami dotyczącymi testowania, wskazuje na pokusy czyhające na osoby w proces ten zaangażowane (zarówno powodowane ludzkim lenistwem, jak i dążeniem do perfekcji), a które mogą proces ten pogorszyć czasem dość znacząco, na możliwe różnice w motywacjach i celach poszczególnych członków projektów IT i na inne przeszkody w osiągnięciu celu głównego, czyli tworzone oprogramowanie działa, klienci walą drzwiami i oknami z wyrazami podziękowania, a wytwórcy nie dość, że się nie pozabijali wzajemnie to jeszcze ze sobą rozmawiają ;). Każdy z rozdziałów podzielony jest na wstęp prezentujący poruszany problem, przykłady w raz ze wskazówkami na ominięcie kłopotów, podsumowanie oraz listę najczęstszych pomyłek, błędów i wypaczeń związanych z zagadnieniem. Całość, napisaną jak już wspomniałem bardzo przystępnie, czyta się przyjemnie i szparko, a materiał daje nieźle do myślenia i mam nadzieję, że wyniesione nauki przydadzą się w życiu. Tak czy siak, polecam. Wszystkim jako lekturę nie tylko do poduszki, a wydawcom pod rozwagę, bo z przyjemnością zapoznał bym się jeszcze raz, tym razem w ludzkim języku.

Gerald M. Weinberg  - Perfect Software And Other Illusions About Testing

Dorset House Publishing, 2008, 200 stron

Rozdziały:

1. Why do we bother testing?
2. What testing cannot do
3. Why not just testing everything?
4. What's the difference between testing and debugging?
5. Meta-testing
6. Information immunity
7. How to deal with deffensive reactions
8. What makes a good test?
9. Major fallacies about testing
10. Testing is more than banging keys
11. Information intake
12. Making meaning
13. Determining significance
14. Making a response
15. Preventing software testing from growing more difficult
16. Testing without machinery
17. Testing scams
18. Oblivious scams