eXtreme TESTING – XT – Bądź jak Jeremy Clarkson

Kiedy Jeremy Clarkson testuje nowego Forda Fieste w klasycznym Top Gearowym stylu, gdy pościg po centrum handlowym i desant plaży razem z marines staje się częścią zaplanowanego scenariusza testowego… mam tylko jedną myśl: jakie to musi być niebanalne uczucie mieć możliwość wykonania tak ekstremalnych testów. Skąd w ogóle takie pomysły? Odpowiedzi udziela sam Jeremy, ponieważ zarzucono mu że testy, które przeprowadza są mało praktycznie i i właściwie bezsensowne, postanowił pokazać test praktyczny i test przydatny w codziennym życiu. Możesz dowiedzieć się jakim samochodem najlepiej wybrać się na zakupy, a jakim na jazdę ekstremalną po plaży :> Teraz każdy już wie, dzięki tym testom, chociażby to, że Corvetta zdecydowanie na jazdę po centrum handlowym się nie nadaje – wiedza życiowa i praktyczna.

Skąd w ogóle ten temat? Jeżeli od kilku miesięcy Twoja praca to właśnie testowanie, to naturalnym tego następstwem jest przeniknięcie charakteru nowymi cechami, jak chociażby kojarzenie wszystkiego co da się przetestować z pracą. I choć ekstremalne testowanie aplikacji mogłoby w pierwszej chwili kojarzyć się z testami obciążeniowymi chociażby to jednak chcę napisać o konkretnej metodologii XT eXtreme Testing.

Testy Jeremiego są niesamowite, ekstremalnie różniące się od standardów, przy tym skuteczne. I dokładnie takie są testy oprogramowania i aplikacji webowych w metodologii XP – eXtreme Programming, metodologii która w samej inżynierii oprogramowania odniosła znaczący sukces i znalazła rzesze zwolenników.

XP eXtreme Programming

Podstawowe zasady XP: write test first, pair programming, ścisła współpraca z odbiorcą, częste tworzenie kolejnych wersji aplikacji.

Zasady tworzenia oprogramowania w metodologii XP według Kena Becka:

  • simplicity(prostota)
  • communication (komunikacja) – tworzenie oprogramowania oparte na komunikacji między: programistami, analitykami i testerami
  • feedback (sprzężenie zwrotne) – uwagi klienta powinny być maksymalnie szybko uwzględniane
  • aggressiveness (ofensywność, przebojowość)

XT jest częścią XP, stąd wymienione cechy XP dotyczą również eXtreme testing. Przesłanie XT jest jedno i bardzo oczywiste (przynajmniej dla testera) – życie ułatwiamy, testowanie przyspieszamy…
Naturalnym odruchem byłoby postawienie w tym miejscu pytania: po co właściwie testować aplikacje tworzone w duchu XP, skoro pierwsza zasada XP brzmi: ‚pisz pierwsze testy’?

I tu wyraźnie nakreśla się rola programisty, który pisząc testy jako pierwsze, ogranicza je do testów sprawdzających poprawność tworzonych klas (JUnit). Bywają sytuacje, kiedy parcie na testy jest silne, a zespół projektowy dąży do jak największego procentu pokrycia kodu testami. Jest to oczywiście dobre podejście, jednak w dużych projektach, kiedy do funkcjonalności dochodzi logika biznesowa to testy ‚akceptacyjne’ nabierają równie ważnego znaczenia. Do testów akceptacyjnych należy dorzucić testy integracyjne, wydajnościowe, bezpieczeństwa. I w tym właśnie rola zespołu testerów.

W XP aplikacja cały czas ewoluuje, stąd duży nacisk w tej metodologi kładzie się na testy akceptacyjne (odbiorcze). Po każdej iteracji aplikacji developerzy testują kod, testerzy przeprowadzają testy typu „grey box” (pomiędzy „white i black box”). Tester XP głównie sprawdza zachowanie się całej aplikacji metodą „czarnej skrzynki”, ale w przypadku buga powinien mieć możliwość analizy kodu (white box).

Zasady XT eXtreme Testing

Projektowanie testów należy zacząć jak najwcześniej, najkorzystniej już podczas analiz projektowych, porzucić należy wszelkie założenia co do wzajemnego zrozumienia, każdy problem maksymalnie uszczegółowić.

Równouprawnienie
zazwyczaj testy są porzucane i zostawiane na sam koniec, a project menagerowie zgadzają się na ograniczanie czasu poświęconego na testy – XT przestrzega przed takimi praktykami, nakazuję prostą zasadę: bez pozytywnego przejścia wskazanych testów nie ma odbioru kolejnej iteracji aplikacji.

100% (sto pro tests :> )
dążenie do 100% pokrycie przypadkami testowymi (TC) całości systemu.

jasny cel
Nie można przetestować wszystkich możliwych przypadków zachowań aplikacji, należy z góry określić te przebiegi, które muszą bezwzględnie zachowywać się poprawnie; należy dopuscić nieprawidłowe zachowanie się aplikacji w pewnych sytuacjach.

minimalizacja zmian
W XT nie należy (jak ma to miejsce w XP) codziennie testować. Celem jest utrzymanie testów i stabilnej wersji aplikacji.

akceptacja
testy akceptacyjne są ustalone z góry, jeżeli podczas testowania zostały wykryte nowe błędy, to taka iteracja aplikacji jest akceptowana, wprowadzanie zmian i poprawek jest już kolejną iteracją.

testowanie parami

różnych pary testerów np. doświadczony – niedoświadczony, znający problem biznesowy – nowicjusz itp.

prostota dokumentacji testowej = współpraca w zespole
należy wzmocnić współpracę testerów i developerów poprzez częste spotkania oraz wzajemne przeglądy testów (testerzy sprawdzają testy developerów, developerzy uczestniczą w przygotowywaniu testów akceptacyjnych)

maksymalna automatyzacja testów

raport stanu testów
Tworzenie maksymalnie często odświeżanej i dostępnej dla wszystkich prezentacji bieżącego stanu testów, najlepiej w postaci graficznej. Na tej prezentacji należy wskazać, które
testy już przeszły (oznaczamy je np. kolorem zielonym), które się „zawaliły” (na czerwono), których jeszcze nie można sprawdzać (na żółto). Im większa liczba zielonych, tym zespół jest lepiej zmotywowany i zmobilizowany.

Podstawowa zasada: XT ma sens tylko i wyłącznie wtedy gdy programiści pracują w trybie XP.

Życie?
Nawet przy najpełniejszej analizie zadania zawsze pozostają niedomówienia i niedookreślenia, które należy wyjaśnić na jak najwcześniejszym etapie prac. Przy dłuższych projektach zatraca się jasność sytuacji, nie wszystko jest już tak klarowne jak w etapie planowania, a dokumentacja często nie jest tak bogata jak być powinna. Pomimo kilku wad metodologia XT uwzględnia chyba wszystkie z trzech priorytetów testowania aplikacji: KOSZT, CZAS, JAKOŚĆ.

Życie?
Nawet jeżeli wyniki testów Fiesty są pozytywnie oszałamiające i tak nigdy nie pojeździsz po centrum handlowym, nie wspominając już o plaży wśród marines.

http://www.joemonster.org/filmy/12691/Top_Gear_Clarkson_testuje_Fieste

http://www.youtube.com/watch?v=wGJPE0KkB5o

źródła:
Beck, K., Extreme Programming Explained: Embrace Change, Addison-Wesley Publish Co; 1999
eXtreme Testing – Lucjan Stapp

Reklamy

komentarze 2 to “eXtreme TESTING – XT – Bądź jak Jeremy Clarkson”

  1. Hej beciu, wiesz, że STO PRO jest zarejestrowaną marką handlową? powinnaś używać STO PRO™

  2. Aw, this was a very good post. Finding the time and actual effort to produce a really good article… but what can I say… I put things off a whole lot and don’t seem to get nearly anything done.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

%d blogerów lubi to: