O interakcjach niekoniecznie mile widzianych
Blog > Komentarze do wpisu
Rozważania o testowaniu cz3

Na temat pracy testera panuje wiele mitów. Jednym z popularniejszych przekonanie, że projektowanie testów jednostkowych jest jednym z głównych zadań testerów. W zależności od firmy różnie to może wyglądać, ale z reguły te testy piszą i wykonują /czyli odpalają skrypt/ developerzy.

Testy jednostkowe to sprawdzanie poprawności klas, funkcji, ogólnie mówiąc klocków. Bierzemy klocek lego do ręki i sprawdzamy czy jest ok. Tę pracę wykonują developerzy bo w gruncie rzeczy jest to praca developerska. Najlepiej pamiętać jednak o dwóch zasadach – 1) robić je jak najprostsze /jeśli test można rozbić na dwa osobne to należy to zrobić/ oraz 2) pisać je w innym języku niż testowane oprogramowanie /developerzy uwielbiają grzeszyć wrzucając w ramach testów jednostkowych kod, który jest do przetestowania/. Jest jeszcze trzecia zasada /do której niestety prawie nikt się nie stosuje/ - 3) pisz testy jednostkowe przed testowanym kodem.

Efekt jaki uzyskujemy z testów jednostkowych można porównać do studenta zdającego egzamin.

Testy jednostkowe to egzamin w formie testu wyboru… jednokrotnego. Ot seria pytań, skończona liczba odpowiedzi i albo jest dobrze albo źle. Co ważniejsze, sam egzaminujący może szybko sprawdzić pracę i udzielić odpowiedzi co jest nie tak.

Klasyczne testowanie funkcjonalne to egzamin w postaci pytań otwartych – gdzie student musi wykazać się wiedzą, a sprawdzenie tego przez egzaminującego trwa i nie zawsze jest to idealnie ocenione, co więcej - inny egzaminujący może to ocenić w zgoła odmienny sposób.

Dobre klasyczne testowanie to egzamin otwarty, gdzie zamiast oceny student otrzyma pełną recenzję egzaminu (często dłuższą od jego pracy). Recenzję, z której dowie się o tym, co mógłby poprawić, usprawnić i jeszcze sugestie na przyszłość.

Studenci uwielbiają testy wyboru. Są szybkie i proste. Jednak dopiero podczas pisemnej otwartej pracy można poznać realnie nie tylko wykutą wiedzę ale i te prawdziwe doświadczenie studenta, a przez dawanie mu odpowiednich informacji zwrotnych – wykształcić z niego wartościowego człowieka.

Z testowaniem jest podobnie. Testy jednostkowe są szybkie, ale nie wnoszą prawie nic do utrzymania tego co nazywamy jakością oprogramowania. Po prostu sprawdzają, czy developer nie pomylił się w drobnostkach.

Wartość pracy testerów tkwi jednak w umiejętnym testowaniu na wyższym poziomie i sztuce raportowania i sugerowania usprawnień.



poniedziałek, 17 lutego 2014, trucie-dupy

Polecane wpisy

Komentarze
Gość: k3rni, *.dynamic.chello.pl
2014/02/17 22:21:06
Nieco upraszczasz. TDD czy BDD daje ci więcej rzeczy: wskaźnik zgodności ze specyfikacją (bo testy dokładnie to sprawdzają - czy kod wykonuje to co specyfikacja każe, szczególnie w BDD) oraz azbestowe gacie na wypadek wysypania się czegoś, czyli tzw. dupochron. Jeśli testy przechodzą - wiemy że dany element/moduł działa, zepsuło się coś innego.

Nie uważam natomiast żeby pisanie testów w innym języku było produktywne; owszem jeśli testujesz bibliotekę przez jej API to może ci to pozwolić wykryć niespodzianki. Ale to już z definicji nie będą unittesty - tylko testy funkcjonalne lub integracyjne. Dodatkowo tworzysz koszt mentalny przerzucania się developerów z jednego języka na drugi oraz koszt czasowy postawienia środowiska testowego w innym.

Fajnie byłoby pisać testy przed kodem. Niestety mało który PM uwzględni to w czasie projektu, a Klient jak o tym usłyszy to zazwyczaj się zastanawia za co płaci. Sorry, taki mamy klimat ;)
-
2014/08/31 10:45:39
Poczułem się jakbym do szkoły wrócił @.@ TO juz nie do końca zrozumiała dla mnie porównywarka ubezpieczeń oc jest bardziej przyjemna niż testy i egzaminy itp :) Ale i tak pozdrawiam!