Redakcja
Dla wielu testerów czarnoskrzynkowych metodyka Agile wydaje się rewolucją, która może zmieść ich z rynku. Pojawiły się informacje, że firmy stosujące zwinne i lekkie procesy tworzenia oprogramowania redukują liczbę testerów zastępując ich programistami. Podobno kod zawiera mniej błędów więc i pracy przy testowaniu jest proporcjonalnie mniej. Podobno dużo się automatyzuje i brak umiejętności programistycznych wyklucza udział w projektach Agile. Podobno.
Z czasem, gdy teoria zmierzyła się z rzeczywistością wiele z teorii zostało obalonych. Ludzie jednak ciągle opowiadają sobie mity o testowaniu w Agile. Jakie jest ono więc naprawdę?
W ostatnim numerze Software Development pojawił się interesujący artykuł pod tytułem "Agile Testing Fact and Fiction". Pokazuje on jak testowanie w agile wygląda w praktyce i obala fikcję jaka narosła wokół tego tematu.
Doświadczony menedżer George Wilson wyjaśnia wszelkie wątpliwości co do roli testerów: "Projekty Agile to doskonała okazja dla QA do objęcia liderskiej pozycji w procesie testowania". Testerzy powinni przejąć kontrolę zamiast sadowić się na tylnym siedzeniu i patrzeć jak kierują programiści. To grupa QA rozumie różnice między pojmowaniem klienta i programisty, rozumie wymagania i wie jak je wprowadzić w życie.
Wilson przytacza dziesięć mitów, które łatwiej obalić niż zdefiniować:
- Testy jednostkowe wystarczą. TDD (Test Driven Development) wystarczy. Brzmi to jak "jeden naród - jedna partia". Od zawsze wiadomo, że metody aby były skuteczne muszą być łączone, mieszane i najważniejsze dopasowane do produktu. Naturalnie nie da się wyeliminować wszystkich błędów przy pomocy jednej techniki testowania.
- Można użyć testy jednostkowe do budowania testów regresyjnych. Niektórzy idą dalej i twierdzą, że testy unitowe zastępują również testy akceptacyjne. Oczywiście można próbować ale testy jednostkowe mają za cel udowodnić, że kod zachowuje się tak jak został napisany, a test regresyjny sprawdza czy kod po zmianie zachowuje się jak zostało to określone w wymaganiach. Jak mawiał mój dziadek jak coś jest do wszystkiego to jest do niczego.
- Testerzy są niepotrzebni. Nie prawda. Jakie technologie i techniki nie zostałyby zastsosowane zawsze potrzebna jest ostatnia linia kontroli, która sprawdzi produkt zanim zostanie on wysłany do klienta. Czy ktoś wyobraża sobie, że samochód wybudowany na linii produkcyjnej całkowicie obsługiwanej przez roboty może zostać przekazany do klienta bez sprawdzenia?! Czy można oddać klientowi kod napisany przez programistę i sprawdzony tylko przez roboty?!
- Test jednostkowe powodują, że testy manualne nie są już potrzebne. Prawdziwe częściowo. Dzięki TDD testerzy nie muszą już walidować pojedynczych pól czy też sprawdzać czy kliknięcie na ikonkę spowoduje reakcję. Tą przykrą i nudną część pracy eliminują roboty (testy jednostkowe). Testerzy mogą wreszcie skoncentrować się na złożonych scenariuszach, spojrzeć na aplikację okiem klienta i sprawdzić czy dostanie taki produkt jaki oczekiwał.
- Testy akceptacyjne są niekonieczne. Bzdura. Praca z klientem w projektach Agile po prostu zmienia swój cel. Nie dajemy klientowi aplikacji do testowania. Rozmawiamy z nim aby zrozumieć, w których miejscach wymagania nie zostały zrealizowane zgodnie z jego pierwotnym wyobrażeniem.
- Automatyzacja jest niemożliwa. Oczywiście we wczesnych fazach projektu trudno jest automatyzować testy. Dopiero w trakcie trwania projektu, gdy aplikacja staje się stabilna można budować testy automatyczne. Można już jednak od początkowych linii kodu próbować uchwycić typowe ścieżki pracy użytkowników lub testerów. Dzięki standardowym logom możemy obserwować jak aplikacja jest używana i wynik obserwacji zastosować do tworzenia automatyzacji.
- Programiści mają wystarczającą wiedzę by testować. "Jeśli testowanie byłoby takie łatwe, każdy by to robił" - twierdzi Wilson. Jest jednak znacząca różnica między testerem a programistą. Programista waliduje funkcjonalność. Tester z kolei, ma szerokie spojrzenie na aplikację i sprawdza jakość.To właśnie tester zadaje pytanie "A co jeśli... ?"
- Testy unitowe muszą pokrywać 100% specyfikacji projektowej. Jeśli ten mit miałby być prawdziwy wymagania użytkownika, bez względu na model tworzenia oprogramowania, musiałyby być znane zanim powstanie kod. W rzeczywistości w projekcie informatycznym jedyne co jest pewne, to to, że albo wymagania się zmienią albo pojawią się nowe funkcjonalności. Trzymanie się kurczowo zasady pełnego pokrycia wymagań prowadzi w rzeczywistości do ciągłych modyfikacji kodu - refactoring-u.
- TDD można stosować w każdym projekcie. Jak pokazuje praktyka dla dużych projektów wysiłek testowania należy rozdzielić pomiędzy testerów i programistów. Część projektu może być prowadzona przez TDD, jednak druga część, gdzie TDD nie jest stosowane powinno mieć silniejsze wsparcie testerów.
- Programiści i testerzy są jak olej i woda. Istnieją i zawsze istniały napięcia w rodzaju "my i oni". Jednak współpraca oparta na takich relacjach nie przynosi korzyści końcowej jakości produktu. Aby urzymać możliwe napięcia w ryzach Wison radzi by:
- w dyskusji koncentrować się na celach, a nie na odpowiedzialności, za części procesu,
- zaangażować testerów do zbierania wymagań i procesu TDD
- maksymalizować ponowne użycie produktów testowych z fazy dewelopmentu
- pomóc przystosować się testerowi do jego nowej roli w TDD
- wspólnie zastanowić jak programiści i testerzy mogą wspólnie korzystać z nowych metod tworzenia oprogramowania i narzędzi testerskich.
Chcesz dowiedzieć się więcej o roli testera w Agile? Zapraszamy na nasze szkolenie Testowanie w Metodykach Agile
