Blog

Dwa wcześniejsze artykuły (pierwszy i drugi) opisywały rafy, na jakie można natrafić, rozpoczynając automatyzację testów, oraz co można zrobić, by tak się nie stało. Na koniec przyjrzyjmy się, w jaki sposób organizacja, w której działa Zespół zajmujący się rozwojem produktu, może wpłynąć (pozytywnie lub negatywnie) na możliwości automatyzacji testów.

11. Nie mamy czasu na automatyzację

Pokutuje przekonanie, że najważniejsze zadanie Developerów to „dostarczanie”. Wszystko inne powinno zejść na dalszy plan, liczy się tylko to, co „dowiezione”. Bo przecież są terminy, bo przecież „development to koszt”… Kto z nas nie słyszał takich haseł? W praktyce mogą one doprowadzić do stłamszenia wysiłków na rzecz automatyzacji testów z dwóch trywialnych powodów.

Po pierwsze: automatyzacja wymaga inwestycji. Ludzie (Zespoły) muszą mieć czas, by się jej nauczyć. Czasem trzeba ich wesprzeć kosztownym ekspertem, pojawi się konieczność zakupu narzędzi, zbudowania infrastruktury. Kosztujące wiele tysięcy godziny pracy programistów pójdą na tworzenie testów, które przecież „nie dają wartości”… Jeśli Zespoły zostaną poddane presji, by przede wszystkim realizować wymagania kosztem jakości produktu, nawet za cenę wydawania rzeczy nieprzetestowanych, to z automatyzacji nie wyjdzie nic.

Po drugie: pojawia się oczekiwanie interesariuszy i kierownictwa, że automatyzacja testów natychmiast zacznie się zwracać, przynosząc dające się wyliczyć oszczędności. One pojawią się, ale najczęściej nie w ciągu kilku pierwszych tygodni, a nierzadko i miesięcy. Wszystko zależy od stopnia złożoności samego produktu, ilości długu technicznego, z jakim przyjdzie się nam borykać, poziomu umiejętności, z jakiego Zespoły będą startować. Jeśli będzie presja na wykazanie wartości testów automatycznych pod groźbą dekapitacji tych, którzy „wygenerowali straty” zajmując się ich budowaniem, chętnych do tego szybko zabraknie.

12. Nie stać nas na to

Bywa też i tak, że są umiejętności w Zespołach, produkt dobrze poddaje się testowaniu automatycznemu, ale brak infrastruktury, dzięki której można by to sensownie robić. Kilka Zespołów użera się o jeden serwer, środowiska testowe nie odzwierciedlają tych działających na produkcji, brak licencji na narzędzia, brak pieniędzy na szkolenia. Ba, bywa tak, że osoby zajmujące się automatyzacją to dawni testerzy manualni ze słabowitymi komputerami, na których teraz próbują uruchomić całe środowisko testowe i wykonać skrypty…

Jeśli wnioski o inwestycję w infrastrukturę i narzędzia trafiają w próżnię, to warto sobie zadać pytanie, co więcej kosztuje: czas pracy ludzi czy narzędzia, jakich używają. Czy warto tracić czas ludzi, którym płacimy tysiące, na czekanie na dostępność maszyn lub walkę z powolnymi laptopami? Czy warto komplikować testy automatyczne poprzez konieczność radzenia sobie w nich ze współdzieloną infrastrukturą?

Aby jakiekolwiek usprawnienia procesu nastąpiły, potrzebni są ludzie zmotywowani do działania – dotyczy to również automatyzacji testów. Jeśli organizacja nie wesprze wysiłków na rzecz automatyzacji i uzna inwestycję za „stratę” lub „niezbędny koszt”, ta motywacja spadnie. Jeśli dodatkowo każdy dzień będzie ciężką walką o zrobienie czegokolwiek sensownego, wszyscy ci, którzy mogliby organizację pociągnąć na wyższy poziom, po prostu odejdą. A ich następcy być może zaczynać będą całą zabawę od nowa.

13. Jeszcze za wcześnie lub już za późno na automatyzację

I na koniec dwa kuriozalne powody, które doprowadzają do braku sensownej automatyzacji testów w wielu firmach i dla wielu produktów.

Część kierownictwa, liderów, architektów i innych osób podejmujących wiążące decyzje w tych firmach może bowiem być przekonana, że produkt jest już „zbyt dojrzały”, by opłacało się inwestować w tworzenie dla niego testów automatycznych. Są to wyznawcy przekonania, że testy takie mają sens tylko w sytuacji, gdy produkt dopiero powstaje, a zmienność jego cech i funkcjonalności jest największa. Po cóż więc spalać siły i środki na testy produktu uznanego za stabilny i działający, w którym dokonuje się tylko „drobnych zmian”, skoro do tej pory testy manualne jakoś wystarczały?

Oczywiście te zmiany rzadko kiedy są drobne – gdyby tak było, pewnie w ogóle nie opłacałoby się utrzymywać Zespołu, który je wykonuje. Co więcej, duże rozwiązanie z dużą ilością funkcjonalności, w którym nigdy nie było testów automatycznych, można bardzo łatwo… rozwalić, dokonując pozornie drobnych modyfikacji.

Są też zwolennicy dokładnie odwrotnej tezy: nie opłaca się automatyzować testów, póki produkt nie jest stabilny. Dopiero po jego ustabilizowaniu, gdy wiadomo już, jak kluczowe funkcjonalności mają działać docelowo, można wybrać narzędzie i zaimplementować testy. Nie trzeba ich dzięki temu nieustannie przerabiać, bo będą równie niezmienne, jak sam produkt…

Ten sposób patrzenia na testy jest utopijnie naiwny, bo oparty na założeniu, że produkt nie ma błędów i jest w dobrej kondycji, a testy nie ułatwiłyby jego zbudowania. Tymczasem przy dużej złożoności współczesnego oprogramowania połączonej z manualnym testowaniem niekoniecznie będzie ono kiedykolwiek na stabilne. Za to może dojść do punktu, w którym przestanie nadawać się do dalszego rozwoju ze względu na ekstremalną niestabilność i kruchość: cokolwiek w produkcie zmienimy, coś innego się sypnie.

Wariantem tej drugiej filozofii jest utrzymywanie, jakoby automatyzacja testów miała sens tylko dla niektórych produktów (oczywiście zawsze nie takich, jak nasz!), lub dla produktów prostych, dla których łatwo to zrobić (a nasz przecież prosty nie jest!).

Jak zapewnić sukces automatyzacji testów?

Po pierwsze: po prostu zacząć ją robić. Każda organizacja musi znaleźć swoją drogę do tego, każdy produkt wymaga czegoś innego. Nie da się teoretycznie wymyślić dobrego rozwiązania i wdrożyć go raz-a-dobrze, tylko empirycznie trzeba go poszukać.

Po drugie: muszą w to być zaangażowane Zespoły budujące produkt, a nie arbitralnie wybrane „Zespoły automatyzatorów” lub wskazani pojedynczy eksperci.

Po trzecie: nie da się zrobić automatyzacji od razu wszystkiego i od razu w modelu docelowym – bo takowy nie istnieje. Konieczne jest zwiększanie jej poziomu, aż osiągniemy taki, który okaże się wystarczający. To zaś implikuje ewolucyjne zmiany w stosowanym procesie, praktykach i narzędziach.

Po czwarte: testy automatyczne obniżają koszt wytworzenia produktu, nauczenie się jak je robić jest dobrą inwestycją. Przesadne skąpstwo organizacji może zamrozić możliwości Zespołu na niskim poziomie.

Po piąte i najważniejsze: automatyzacja jest po to, by szybko dowiadywać się, czy produkt jako całość działa. Każda decyzja lub rozwiązanie, które od tego celu nas oddala, jest prawdopodobnie błędem.