Redakcja
Wstęp
Nic nie jest dane nam raz na zawsze. Raz zdobyta wiedza wietrzeje, deprecjonuje się. Standardy się zmieniają, tworzone są nowe teorie, podejścia, metodologie. Umiejętności raz zdobyte ulatują. Stanąć w miejscu to tak jakby się cofnąć. Nie ćwiczony umysł jest jak nie ćwiczone ciało – sztywne i skostniałe, niezdolne do podjęcia wysiłku, niezdolne do nagłego zrywu. Testerzy nie są tu wyjątkiem.
Aby spełniać dane nam zadania musimy się kształcić i rozwijać. Musimy stawać się lepszymi testerami. Istnieje wiele dróg rozwoju – możemy czytać książki i blogi znanych autorów i konsultantów korzystając z ich doświadczenia i chęci dzielenia się wiedzą. Możemy też uczestniczyć w szkoleniach prowadzonych często przez doświadczonych, pracujących w branży od wielu lat testerów i managerów.
Ale nie tylko. Od jakiegoś czasu głośną ideą na świecie są testerskie doja, a ich ucieleśnieniem jest społeczność Weekend Testing. Osoby takie jak Ajay Balamurugadas, Markus Gaertner, Michael Larsen, Albert Gareev czy Anna Baik pomagają szlifować swoje umiejętności żądnym wiedzy testerom wg zasady: testuj, ucz się, dziel się wiedzą. Tutaj wiedza teoretyczna przekuwana jest w praktyczną. Każdy może uczestniczyć – wystarczy chcieć.
Testerskie dojo nie ogranicza się wyłącznie do medium jakim jest Internet. Wręcz przeciwnie. Możliwość współpracy jest tutaj ważnym aspektem pozwalającym rozwijać umiejętności interpersonalne. Można organizować je na różnych spotkaniach, a jeśli uda się przekonać Waszego test managera, także w miejscu pracy. Mnie to się udało i od jakiegoś czasu organizujemy je w mojej firmie. Podobne sesje planujemy podczas spotkań grupy PTaQ – Poznań Testing and Quality Group - lokalnej społeczności testerskiej (www.ptaq.org).
W tym artykule przedstawię garść porad i opiszę w jaki sposób Testing Dojo przeprowadzane są w Cognifide.
Testerskie dojo – od czego zacząć?
Wystarczy trochę chęci. Chęci zdobywania nowych doświadczeń i wiedzy, ale także chęci dzielenia się tą wiedzą z innymi. Co potrzeba? Możesz o tym przeczytać w kilku miejscach (www.methodsandtools.com/archive/archive.php?id=114, www.cognifide.com/blogs/quality-assurance/whats-a-testing-dojo), ale pamiętaj, że nie trzeba sztywno trzymać się zasad. Kartka i długopis owszem, raczej się przydadzą, ale niekoniecznie musisz „zatrudniać” do pracy ludzi, aby wypełnić wszystkie wymienione tam role – szczególnie, gdy zespół nie jest duży. Podczas naszych dojo udawało mi się wcielać w kilka ról naraz – wybierać misję, prowadzić dojo i notować jego przebieg. Traktuj je raczej jako wskazówki, a nie zbiór nakazów i reguł.
Testing Dojo najczęściej mają jakąś misję. Przetestowanie aplikacji („Test this!”), nauka nowych technik, wypróbowanie narzędzi („evaluate tool”). Każde z nich może wyglądać różnie i mieć inny cel, ale z każdego należy wyciągać wnioski. Dojo często jest poprzedzone wstępem, prezentacją, częścią teoretyczną, które służą przypomnieniu bądź przekazaniu nowej wiedzy. Dojo, jako część praktyczna, jest dopełnieniem i utrwaleniem wiedzy poprzez ćwiczenia. Zdarza się, że obie części nie są przeprowadzane jedna po drugiej, lecz po jakimiś czasie – bywa, że trudno jest zebrać zespół na dłuższy czas, łatwiej jest wygospodarować godzinę niż dwie. Tak było z naszym pierwszym dojo dotyczącym heurystyk testowych, w którym podczas części teoretycznej zdefiniowaliśmy termin „heurystyka” i omówiliśmy kilka przykładów. Podobnie było z innym dojo zapoczątkowanym przez Lab (mikroprojekt mający na celu zdobycie lub rozszerzenie wiedzy w wybranym obszarze). Następnie wiedza teoretyczna została przekazana grupie w ramach serii prezentacji, a seria Testing Dojo służyła utrwaleniu wiedzy i jej praktycznemu wykorzystaniu. Pamiętajmy też, że dojo to nie egzaminy, tylko luźne spotkania, których celem jest też zabawa – dlatego posiłkowanie się „ściągami” nie jest zabronione (testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf).
Nic jednak nie stoi na przeszkodzie, aby wszystko odbywało się podczas jednego spotkania – wszystko zależy od czasu jaki możecie przeznaczyć na spotkanie. W mojej firmie dojo organizowane jest podczas niektórych z cotygodniowych QA Meetingów, czyli spotkań całego zespołu testowego. Udaje nam się przeznaczać na nie około 30-60 minut w zależności od misji i celu spotkania.
Rysunek 1: Whiteboard pochodzący ze wstępu do Testing Dojo na temat heurystyk testowych.
Jeśli nie macie żadnego pomysłu na dojo – nie przejmujcie się. Misja „przetestuj to” zakłada, że zbieracie się po to, aby przetestować jakąś aplikację i szlifować posiadane już umiejętności. Drugie dojo przeprowadzone u nas w firmie wykorzystywało właśnie ten schemat. Testowaliśmy aplikację generującą kod kreskowy (www.barcodeart.com/artwork/netart/yourself/yourself.swf), gdzie celem było zdefiniowanie algorytmu jego tworzenia. Testować można nie tylko „zewnętrzne” aplikacje – spotkanie możecie wykorzystać, aby przetestować aplikację tworzoną w Waszej firmie. Testowanie własnych aplikacji ma dodatkowy cel. Jest okazją do wymiany doświadczenia, pokazania jak różnią się nasze techniki i podejścia. Mogą pomóc zredukować liczbę testów, wykryć redundancję czy w końcu pomóc tworzyć standardy, np.: użyteczności.
Ilustracja 2: Błąd wykryty w testowanej aplikacji
Jeśli macie problemy z przekonaniem Waszych przełożonych do przeznaczenia czasu na takie spotkania – wykorzystajcie trzeci typ misji - „evaluate tool”. Może wspólna praca nad wypróbowaniem jakiegoś narzędzia potencjalnie przydatnego w firmie przekona ich o wartości dojo. Być może warto przed spotkaniem poprosić jedną osobę o krótką prezentację na temat narzędzia – wtedy podczas samego dojo będzie można skupić się na jego użyteczności, a nie na np.: konfiguracji.
Nie samym testowaniem człowiek żyje, więc chciałbym wspomnieć także o innym aspekcie takich ćwiczeń - „Learn by Play” - gry i zabawy logiczne przy komputerze czy przy kartce papieru też mogą być owocne. W końcu logiczne myślenie i rozwiązywanie problemów to jedne z najważniejszych umiejętności testera. Je też możemy ćwiczyć.
Samo dojo najczęściej rozpoczyna się od prezentacji misji – przedstawiamy przedmiot testów i określamy cele. W zależności od ilości uczestników i dostępnych laptopów dzielimy się na grupy, najczęściej dwuosobowe. Dzięki temu skupiamy się także na komunikacji i współpracy. W metodykach miękkich dość popularny jest peer developement – czemu zatem nie zadbać o popularyzację peer testingu? Podczas testów uczestnicy zadają pytania, na które prowadzący stara się odpowiadać, zadawanie odpowiednich pytań to kwintesencja testowania. Tego też uczy Testing Dojo. Znalezione błędy, istotne kwestie, które zostały poruszone, wnioski, uwagi zapisujemy na tablicy. Sesję kończymy chwilę przed wyznaczonym czasem, aby mieć jeszcze możliwość przedyskutowania wyników, określenia czy spotkanie pozwoliło nam nauczyć się czegoś nowego.
Ilustracja 3: Analiza algorytmu generowania kodu kreskowego podczas Testing Dojo.
I co dalej ?
Możemy zwiększać korzyści jakie płyną z przeprowadzenia Testing Dojo przez wyciąganie odpowiednich wniosków i wykorzystywanie doświadczenia zdobytego w jego trakcie. Dzielmy się nim i uzyskaną wiedzą – skorzystamy na tym wszyscy.
Po każdej sesji prowadzący tworzy sprawozdanie z przeprowadzonych ćwiczeń i umieszcza je na Wiki. Zbiera także wszystkie artefakty, które powstały w jego trakcie – zdjęcia tablicy, notatki. Jest to dokumentacja wewnętrzna, więc nie możemy jej udostępniać na zewnątrz, ale na jego podstawie tworzone są posty, które mogą być publikowane np. na blogu.
Jeśli w trakcie dojo testowaliśmy własną aplikację, zgłośmy błędy wykryte podczas testów. Przedyskutujmy je z Project Managerem lub Tech Leadem. Spróbujmy wciągnąć ich w dyskusję i wykorzystać ich doświadczenie oraz feedback do nauki i ulepszenia naszych dojo.
Skąd brać pomysły?
Pomysł to najczęściej połowa sukcesu. A więc, skąd je brać? Można sięgnąć do archiwum Weekend Testing – niemal co tydzień odbywają się kolejne spotkania, w których uczestniczą także testerzy z Polski. Wspomniany wcześniej Markus Gaertner prowadzi stronę „Testing challenges” - pokaźny zbiór wyzwań testerskich gotowych do użycia na każdym dojo. Coraz częściej na niektórych konferencjach przeprowadzane są Testing Dojo. Przykładem może być Agile Testing Days 2011, na którym Markus prowadził Testing i Coding Dojo. Zebrane doświadczenie z uczestnictwa w spotkaniu można później wykorzystać przy organizacji własnego.
Zakończenie
Przedstawiłem tutaj podejście jakie udało się nam wypracować w firmie w ciągu ostatniego roku, od kiedy Testing Dojo stało się stałym elementem naszej praktyki. Nie oznacza to, że jest ono idealne i doskonałe, nie oznacza to także że będzie pasowało do Waszego modelu pracy. Spróbujcie, zmieniajcie, modyfikujcie, a na pewno Wam się uda. Nie zrażajcie się niepowodzeniami – nie od razu Rzym zbudowano.
Owocnych sesji, czego sobie i Wam życzę.
Autor:
Łukasz Morawski pracuje jako QA Engineer w firmie Cognifide. Testowaniem zajmuje się zawodowo od 8 lat. Przez wiele lat zajmował się automatyzacją z użyciem Test Complete, AutoIt, a ostatnio także Selenium/Webdriver. Jest entuzjastą Weekend Testing i Testing Dojo. Uczeń w szkole Miagi-Do School of Software Testing.
Źródła:
1. Aleksander Lipski, "Becoming a better software tester" – prezi.com/os0bpbxjfzjh/becoming-a-better-software-tester (prezentowana na I spotkaniu PTaQ),
2. Zbyszek Moćkun, Łukasz Morawski, „Knowledge acquisition and sharing” - ptaq.org/images/ptaq1/ptaq_knowledge_sharing.pdf (prezentowana na I spotkaniu PTaQ),
3. Markus Gaertner, "Testing Dojos" – www.methodsandtools.com/archive/archive.php?id=114,
4. Weekend Testing – weekendtesting.com,
5. Markus Gaertner's Testing Challenges – www.testing-challenges.org,
6. www.barcodeart.com/artwork/netart/yourself/yourself.swf,
7. testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf
