13 powodów nieudanej automatyzacji testów, część 3 - Code Sprinters

13 powodów nieudanej automatyzacji testów, część 3

Dwa wcześniejsze artykuły (część pierwsza i część druga) 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ę na ile 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 zespołów developerskich 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 biznesu i managementu, ż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, na 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 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 przez konieczność radzenia sobie w nich ze współdzieloną infrastrukturą?

Aby jakiekolwiek usprawnienia zadziałały, potrzebni są ludzie zmotywowani do działania, dotyczy to również automatyzacji testów. Jeśli organizacja nie wesprze tego procesu 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 ci, którzy mogliby organizację pociągnąć na wyższy poziom odejdą, a ich następcy być może zaczynać będą całą zabawę od nowa.

13. Już za późno / jeszcze za wcześnie 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ęść managementu, leaderó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ę dorabiać do niego automaty testujące. Są to wyznawcy przekonania, że testy automatyczne 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 wielką 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ż jakie funkcjonalności należy przetestować, dużo łatwiej wybrać narzędzie i zaimplementować testy. Nie trzeba ich też 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 rozwiązania połączonej z manualnym testem niekoniecznie jest ono „stabilne” i bardzo często w praktyce nie nadaje się do dalszego rozwoju. 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: zacząć ją robić, po prostu. Każda organizacja musi znaleźć swoją drogę do tego, każdy produkt wymaga czegoś innego. Nie da się teoretycznie wymyślić dobrego rozwiązania, tylko empirycznie trzeba go poszukać.

Po drugie: muszą w to być zaangażowane zespoły budujące produkt, a nie arbitralnie wybrane zespoły „automatyzeró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ć jej możliwości na niskim poziomie i uniemożliwić zwinne działanie.

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.

LinkedIn

SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 2001. Praktyk Agile, ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem.

Inne artykuły tego autora