Tym razem na ImagineBlog pierwszy wpis testerki Empathy, Beaty “Bety” Frączek. Z odrobiną humoru:)

W idealnym świecie oprogramowanie nie zawiera błędów. W idealnym świecie Edward Murphy jest optymistą, a nie sfrustrowanym inżynierem. W idealnym świecie testy mają swój koniec.

Obszar metodyk zwinnych – agile methodology – jest światem stosunkowo młodym i nowym. W świecie IT metodyki zwinne zdobywają coraz większą popularność. Jak w powieściach Terrego Prachetta, są czymś w rodzaju nieobliczalnego i nieznanego Świata Dysku. Agile jest pojęciem samym w sobie rozległym, obejmującym zasięgiem metody, metodyki i procedury. Korzenie zwinności mają swój początek w Manifest Agile.

Warto skupić się wokół intrygującego aspektu testowania, na które agile rzuciło nowatorskie spojrzenie. W polskich realiach pozycja testera w cyklu wytwarzania oprogramowania jest traktowana często niecałkiem poważnie. Testerzy nie są sławni, nie podążają ścieżkami oszałamiającej kariery, nie są decyzyjni w procesie pojektowania oprogramowania. I w tym miejscu agile składa ukłon w stronę testerów. Wskazuje nową ścieżkę, którą powinni dążyć wytrwale jak Frodo w drodze do Mordoru.

Przypowieść o zwinnym testerze

Testowanie to zajęcie szczególne: nieustające polowanie na błędy, niegasnąca dociekliwość i podejrzliwość w poszukiwaniu bugów. Warto posiadać pod ręką testera, który może okazać się linią obrony przed klientem, biorącego na swoje barki ciężar niedziałającego oprogramowania i z uporem maniaka twierdzącego, że wszystko co możliwe zostało przetestowane.

Ktoś stwierdził, że testerami powinny być osoby będące pewnego rodzaju „pasjonatami zniszczenia”, czyli osoby, którym wykrycie błędu daje im satysfakcję, a szczególną przyjemność czerpią ze znęcania się nad przekazanym do testów oprogramowaniem.

Doświadczeni programiści rozpoznają dobrych testerów i czynią wszystko by z nimi współpracować. Wielu innych niestety lekceważy weryfikację własnego kodu, uważają, że release jest wolny od błędów i można go od razu przekazać klientowi. Nie wolno zapominać od czego zwykle wszystko się zaczyna: “Programista tworzy kod, wierząc, że nie zawiera on błędów”.

Prawdopodobnie najważniejszą cechą testera są odpowiednie zdolności komunikacyjne. Do nich warto dodać empatię. Dlaczego? Bo każdy ma swoje lęki i fobie. Klient obawia się, że system może nie spełniać jego potrzeb. Programiści obawiają się, że nie powiedziano im, czego tak naprawdę chcą użytkownicy, i że będą musieli przebudowywać cały system. Tester, z natury cieszący się z błędów, powinien rozumieć obawy każdej grupy i umieć zapobiegać rodzącym się konfliktom. Poczucie humoru może okazać się wartościową cechą w stresujących sytuacjach. Pod żadnym pozorem nie wolno krzyczeć na programistę, zabrania się dopisywania w komentarzach do zadań wykrzykników, należy zapomnieć, gdzie na klawiaturze znajduje się Caps Lock.

Mimo to, w tej uprzejmej atmosferze trzeba zachować pewność siebie. Tester nie może dać się zbić z tropu słysząc „to nie bug, to ficzer”. Pewność siebie nie bierze się znikąd, musi być oparta na wiedzy i kompetencjach. Programiści zwykle próbują wyjaśniać błędy na różne sposoby. Należy tego oczekiwać. Tester musi słuchać każdego, ale jednocześnie pozostawać sceptycznym zanim samemu nie sprawdzi, jak jest naprawdę.

Testowanie jest trudnym zajęciem, potrafi być monotonne i nudne. Ponieważ natura testowania jest związana z powtarzaniem szeregu czynności, dobry tester szuka sposobów na ułatwienie sobie pracy. Dlatego jest on otwarty na nowości techniczne i korzysta z dostępnym narzędzi.

Mity dotyczące testowania

A ponieważ ideały istnieją tylko w idealnym świecie, to nie ma idealnego testera w świecie realnym. Dlatego warto zmierzyć się z fundamentalnymi prawami testowania, które śmiało można nazwać mitami. Opierając się na artykule George’a Wilsona “Agile testing fact and fiction” i jego opracowaniu “Testowanie w Agile“, spróbujmy te mity obalić.

1. Testy jednostkowe ponad wszystko. Testowanie Agile obala jeden z podstawowych mitów dotyczących testowania: należy tylko wykonywać testy jednostkowe – testowanie w ramach podejścia TDD wystarczy. Podejście TDD (Test Driven Development – programowanie sterowane testami) jest dobrym początkiem, jednak głównie dla tych, którzy nie znają innych możliwości. Okazuje się jednak, że najwięksi orędownicy programowania zwinnego dostrzegają potrzebę posiadania w swoim arsenale szerokiej gamy technik testowania, w tym testów typu białej i czarnej skrzynki, testów regresyjnych, obciążeniowych i odbiorczych.
2. Nie potrzebujemy już testerów ani narzędzi do automatyzacji. To nieprawda. Jak powiedział Wilson: testerzy odgrywają inną, ale równie ważną rolę, jak programiści i dlatego powinni zajmować równorzędną pozycję w strukturze organizacyjnej projektu. Żadne ‘kombajny’ do automatyzacji znanych firm nie zastąpią testera.
3. Testy jednostkowe eliminują potrzebę przeprowadzania testów ręcznych. Podejście TDD może zmniejszyć ilość pracy ręcznej wykonywanej podczas testów funkcjonalnych, ale nie wyeliminuje potrzeby dalszych ręcznych lub automatyzowanych testów typu czarnej skrzynki. Choć testowanie ręczne jest czasochłonnym sposobem znajdywania błędów, koszty ich nieznalezienia są jednak często znacznie wyższe.
4. Automatyzacja jest niemożliwa. Automatyzacja na wczesnych etapach projektu realizowanego zgodnie z metodyką Agile jest trudna, ale w miarę ewolucji systemu stabilizuje się. W ten sposób wdrożenie automatyzacji, która pozwala zapanować nad zmianami, staje się prostsze.
5. Testy jednostkowe odpowiadają 100% specyfikacji projektowych. Niezależnie od metody programowania, przed opracowaniem kodu trzeba znać wymagania. Ważnym czynnikiem jest to, że testy należy opracować przed ich zastosowaniem względem kodu. W przeciwnym razie programistów czeka wprowadzanie wielu zmian w kodzie, czyli tzw. refaktoryzacja (refactoring).
6. Programiści i testerzy są jak oliwa i woda, nie da się ich połączyć? Pomiędzy programistami i testerami od zawsze istniały podziały typu „my i oni”, ale nie musi to być przyczyną konfliktów. Relacje muszą być jak zdrowa symbioza zapewniająca współpracę korzystną dla obu stron. Jeśli tester programistę zrozumie, pocieszy, podtrzyma na duchu, nie będzie żartował z jego kodu, to wówczas dobra współpraca będzie gwarantowana.

Podsumowując: skoro w programie zawsze jest jeszcze jeden błąd, nie warto ryzykować, warto mieć pod ręką testera. A najlepiej zwinnego.

Beata Frączek

Tagi: agile, Aplikacje internetowe, Beata Frączek, Testowanie, współpraca z klientami, Wydajność

Ten wpis został opublikowany Piątek, luty 19th, 2010 o 17:02 i jest zaszufladkowany do kategorii Aplikacje internetowe, Testowanie. Możesz śledzić wszystkie odpowiedzi do tego wpisu poprzezkanał RSS 2.0. Możesz dodać odpowiedź lub trackback ze swojej strony.