Myśli nieuczesane o automatyzacji testów

Myśli nieuczesane o automatyzacji testów
Warto rozmawiać o testowaniu, warto rozmawiać o automatyzacji. Oto kilka przemyśleń po jednej z takich rozmów.

(Niepoliczalna) wartość i (policzalne) koszty automatyzacji

Obiektywna i policzalna wartość automatyzacji nie istnieje. Tak samo jak nie da się policzyć testowania manualnego. Koszty automatyzacji (i całego testowania) istnieją i są policzalne. W klasycznym ROI łatwo policzyć inwestycję, ale bardzo trudno (lub wręcz niemożliwe) jest oszacować zwrot/korzyści.

Kilka z dostępnych opcji opisano szerzej tutaj

  1. nie ma wyboru, bo możliwa jest tylko automatyzacja – ROI nie trzeba robić,
  2. nie ma wyboru, można testować tylko manualnie – ROI jest niepotrzebne,
  3. mamy obszar, który można i zautomatyzować, i zrobić manualnie – w tym miejscu możemy przyjąć tezę Smilgina, że „Jeśli testowanie manualne jest alternatywną dla automatyzacji metodą kontroli jakości oprogramowania, to tam, gdzie mają one takie same cele, testowanie manualne jest tańszą i skuteczniejszą metodą niż automatyzacja”. Alternatywnym podejściem jest precyzyjne zestawienie obu metod w celu określenia, która z nich będzie w tym konkretnym przypadku efektywniejsza ekonomicznie.

Przy okazji warto pamiętać, że jeśli automatyzacja jest tak samo kosztowna jak testowanie manualne, należy postawić na to drugie. Klasyczne testy mają bowiem większą możliwość wykrycia dodatkowych problemów, których sztywna architektura automatów może nie uwzględnić. 

Nie buduj narzędzi pod jeden projekt

Emilia Lendzion-Barszcz jest autorką prezentacji pt. „Budowa domu jest jak automatyzacja testów”. Co prawda historia skupiała się bardziej na wzorcach projektowych, ale ta analogia do produkcji oprogramowania jest jedną z ciekawszych. W obu przypadkach budujemy jeden produkt, dla jednego klienta. Czasami nasz projekt może być inny i łatwiej będzie go porównać do budowania mostu. Mamy do czynienia z jednym produktem, ale też z wieloma grupami użytkowników (pieszego, rowerzysty, kierowcy).
W obu przypadkach działa jednak to samo ciekawe spostrzeżenie. Zarówno do budowy domu, jak i mostu użyjemy tych samych narzędzi, jakie stosuje się na każdej innej budowie. Nie tworzymy ich specjalnie na potrzeby tej konkretnej budowy. Zupełnie inaczej jest w IT. W obszarze testów często tworzymy dedykowane rozwiązania automatyczne, pisane wyłącznie pod jeden konkretny produkt. Możliwe więc, że się mylimy i powinniśmy skorzystać z gotowych rozwiązań do weryfikacji jakości. Takie narzędzia Radek Smilgin nazywa „automatycznymi weryfikatorami” i do tego koszyka wpadają między innymi rozwiązania AI i agenci. Co ciekawe, w przeciwieństwie do automatyzacji testów, automatyczna weryfikacja opłaca się niemalże zawsze. 

Automatyzacja testów jako usługa 

Automatyzacja testów nie jest produktem, tylko usługą. Jeśli chciałbyś tę usługę pozyskać na zewnątrz, to w modelu TIME and MATERIAL poniesiesz duże koszty, nie mając pewności, że osiągniesz zakładane rezultaty. Jeśli jednak na rynku pojawiłaby się oferta FIX PRICE, czyli taka, w której z góry wiesz, ile automatyzacja będzie kosztować, to jest to oferta warta rozważenia. Wystarczy, że porównasz koszty automatyzacji wewnętrznej kontra zewnętrznej i wybierzesz tę, która będzie tańsza. Nie warto się przy tym oglądać na korzyści, bo one zagwarantowane powinny być w SLA z dostawcą usługi. 

Warto pamiętać, że granica automatyzacji zwykle nie jest technologiczna. Jest finansowa, organizacyjna albo psychologiczna. Zazwyczaj organizacje będą patrzyły na wymiar finansowy.

Wiedza plemienna jako automatyzacja

Co zrobić, gdy proces wydaje się idealny do automatyzacji, ale w praktyce jest pełen nieformalnych wyjątków, decyzji podejmowanych "na wyczucie" i wiedzy, której nigdy nie zapisano? Problem, który tu rozważamy, polega na tym, że najważniejsza dokumentacja w wielu firmach nadal znajduje się w głowie pojedynczych osób. Wiedza plemienna to – w pewnym sensie - legacy code organizacji. Czy da się to jakoś ogarnąć AI i automatyzacją?

Tak, ale musimy pamiętać, że AI świetnie automatyzuje rzeczy jawne. Rzecz w tym, że funkcjonowanie wielu organizacji opiera się na wiedzy niejawnej. Jeśli więc uda się ludzkie doświadczenie i wiedzę zapisać jako kod automatyzacji, to zrób to! Nawet jeśli miałaby to być jedyna forma notacji dla tej wiedzy. Podobne metody stosowano już w przeszłości, gdy wiedzę biznesową spisywano w postaci przypadków testowych. Dziś możemy to powielić przy pomocy automatów. 

Artykuł jest luźno inspirowany panelem dyskusyjnym z udziałem Stefanii Winkel, Emilii Lendzion-Barszcz, Piotrka Wicherskiego i Radka Smilgina pod tytułem „Nowoczesna automatyzacja testów jest realną wartością w codziennej pracy czy kosztownym trendem?” 

Automatyzacja testów w moich projekcie?
Automatyzacja testów w moich projekcie?
0 %
Dobra jest!
66.67 %
Jest
0 %
Jest niedobra
33.33 %
Nie ma
Łącznie głosów: 3

To powinno Cię zainteresować