blog.testowka.pl

A mury runą, runą, runą…

opublikowany przez 13, Lip, 2012, w kategoriach Agile, Automatyzacja, CI, Programowanie, Scrum, Testowanie, XP, Zarządzanie

…i pogrzebią stary świat…

Tak wiem, że Kaczmarski miał niewiele wspólnego z wytwarzaniem oprogramowania. O jaki mur chodzi? Mur, który od lat budowaliśmy pomiędzy tzw. programistami i tzw. testerami. Często powstawały nawet fizyczne mury i bariery – chociażby odległość liczona w tysiącach kilometrów.

Od dawna już wiadomo, że zarządzanie poprzez konflikt (tutaj konflikt między testerami, a programistami) jest jedynie (o ile w ogóle) efektywne w krótkich okresach czasu – długofalowo niszczy motywacje i powoduje mnóstwo problemów wynikających z komunikacji. Programowanie (wytwarzanie oprogramowania) jest grą zespołową – zespół to nie tylko programiści. Zespół to też testerzy, zespół to także klienci, to czasem też docelowi użytkownicy – stawianie murów pomiędzy nimi powoduje jedynie wzrost złożoności i zwiększoną ilość problemów.

Cały ruch Agile czy metodyki takie jak Scrum, XP, Crystal heroicznie walczą z podziałami i sprowadzają się do zapewnienia odpowiednich interakcji pomiędzy ludźmi wytwarzającymi oprogramowanie. W efekcie powstają produkty wysokiej jakości.

Dlatego proszę oprócz fizycznych, technicznych i psychologicznych barier usuńmy też wszelkie inne spory i kłótnie. Męczą mnie już dyskusje na temat tego jakie testy powinien pisać/wykonywać tester a jakie programista? Czy to  na prawdę ma znaczenie?! Jeśli będziemy pracować razem, to prawdopodobnie osiągniemy dużo lepsze rezultaty. Co złego się stanie jeśli programista siądzie w parze z testerem i razem coś zakodują, albo przetestują?

Testowanie (czy to manualne, czy automatyczne) jest nieodłącznym elementem programowania. Bez testowania (jakiegokolwiek) oprogramowanie najprawdopodobniej nigdy by nie powstało. Bez programowania nie było by co testować. Cała idea inkrementalnego wytwarzania oprogramowania opiera się o nie dzielenie procesu wytwarzania oprogramowania na testowanie i kodowanie – robimy te rzeczy równolegle i ciągle.

Pisanie testów automatycznych jest równoznaczne z tworzenie tzw. kodu produkcyjnego. Gdy byłem na szkoleniu z Clean Code u Uncle Bob’a (Robert C. Martin) z wielkim oburzeniem mistrza spotkało się moje stwierdzenie, że rzadko tworzę kod produkcyjny, gdyż zajmuję się głównie automatyzacją testów. Testy automatyczne są kodem produkcyjnym – często dużo ważniejszym i bardziej wartościowym niż kod funkcjonalności aplikacji.

Nie stawiajmy więc sztucznych barier pomiędzy testowaniem a programowaniem – obydwie te czynności mają na celu dostarczenie produktu wysokiej jakości i na tym powinniśmy się skupić.


2 Comments for this entry

  • Konlin

    „Testy automatyczne są kodem produkcyjnym – często dużo ważniejszym i bardziej wartościowym niż kod funkcjonalności aplikacji.”

    Co konkretnie miałeś na myśli w tym stwierdzeniu? Może jakiś przykład?

  • streser

    Faktycznie to może wymagać wyjaśnienia. Ogólnie przy założeniu, że nie mamy siatki bezpieczeństwa w postaci zespołu testerów, to czy nasz kod działa jest weryfikowane w przeważającej większości przez nasze testy automatyczne. To jaka będzie jakość tych testów jest kluczowym czynnikiem tego jaka będzie jakość naszego oprogramowania. Wbrew pozorom testy zmieniają się raczej rzadziej niż kod funkcjonalności, ale nadal zmieniają się często, więc wprowadzanie modyfikacji w nich powinno być robione jak najmniejszym kosztem.

    Są ważniejsze (wg mnie) dlatego właśnie, że to one pozwalają nam na bezpieczny rozwój aplikacji. W dzisiejszych czasach dużo większą wartość od samej funkcjonalności aplikacji zdaje się mieć możliwość stałego rozwoju i modyfikowania tej funkcjonalności.

Skomentuj