ROI automatyzacji. Niepoliczalne

Zanim przejdziemy do uzasadnienia, zacznijmy od sprawdzenia, jakie opcje mamy, gdy chodzi o opłacalność automatyzacji. Podczas analizy tematu „ROI Automatyzacji” doszedłem do wniosku, że realistyczne i warte rozważenia scenariusze to:

1. Automatyzacja się opłaca i można to udowodnić. 
2. Automatyzacja się nie opłaca i można to udowodnić. 
3. Zyski z automatyzacji są niepoliczalne.

Ponieważ są one wzajemnie wykluczające się, to tylko jedna z tych opcji może być prawdziwa. 

Na początek musimy określić, czym jest ROI? Jest to popularna miara pokazująca dochodowość inwestycji. Można ją policzyć jako stosunek kosztów inwestycji do uzyskanych korzyści. Na potrzeby testów zakładamy, że zainwestowane w metodę kontroli jakości środki mogą się nam zwrócić. 

Poniżej znajdziecie część webinaru „Automatyzacja dla managerów” poświęconą ROI z automatyzacji:

Testy manualne vs. testy automatyczne

Bardzo ciekawy koncept rozważania opłacalności testów manualnych oraz automatycznych wyróżnili w publikacji „That's No Reason to Automate!” Mark Fewster oraz Dorothy Graham.

Pokazano w niej, że testy manualne to taki obszar, jakiego nie opłaca się automatyzować, a testy automatyczne to taki obszar, którego nie da się wykonać w sposób manualny. Tu możemy dodać małą gwiazdkę, ponieważ część testów automatycznych da się wykonać ręcznie, ale przy ograniczonych w projekcie zasobach finansowych i ludzkich oraz przy ograniczeniach czasowych lepiej jest je zautomatyzować. Do takich testów należą:

1. Testy wydajności, ze względu na mnogość wygenerowanych wirtualnych użytkowników i zapytań, które automat zrobi znacznie szybciej.
2. Testy konfiguracji przez mnogość konfiguracji i nużącą powtarzalność testów, których wykonywanie może prowadzić do wypalenia.
3. Testy równoległe, kiedy to różne procesy muszą wydarzyć się w tym samym czasie, czego nie da się łatwo zrobić ręcznie.
4. Testy wymagające precyzji czasowej z dokładnością do milisekund, jw. 
5. Testy jednostkowe, których uruchomienie ręczne jest niepraktyczne i czasochłonne.

Każde z powyższych, uruchomione ręcznie, w większości przypadków będzie dużo bardziej kosztowne niż zrobione przy pomocy automatów. Tak więc zarówno dla testów manualnych, jak i automatycznych w tych obszarach liczenie zwrotu z inwestycji nie ma większego sensu, co wyjaśnię dalej. Co do tych obszarów większość projektów nie będzie miała wątpliwości, którą formę uruchomienia testów wdrożyć. 

Najciekawszym jednak z perspektywy analizy jest obszar środkowy, gdzie znajdują się testy, które da się wykonać manualnie, ale które można również zautomatyzować. To właśnie tutaj projekty stają przed najtrudniejszym pytaniem - która forma testowania będzie bardziej opłacalna? Pewnym uproszczeniem w opracowaniu Fewstera i Graham jest to, że rozważa on jedynie obszar uruchomienia testów, w związku z tym pomija w dużej mierze techniki statyczne jak przeglądy (w których nie uruchamiamy oprogramowania), analizatory statyczne (które pozbawione są oczekiwanych rezultatów), testowania A/B połączonego z monitorowaniem występowania awarii na produkcji oraz wszystkich innych technik i metod w obszarze zapewnienia jakości (QA) oraz dobrych praktyk zapobiegania defektom. 

Fewster i Graham analizują więc wybór testowania ręcznego i automatycznego mniej więcej od napisania pierwszej linijki kodu po testy preprodukcyjne. Tylko w tym czasie projektowym traktowania testów manualnych, jako jedynej alternatywy dla testów automatycznych, oraz testów automatycznych, jako zamiennika testów manualnych może być poprawne. Ponieważ jest to dla większości projektów pik wydatków na kontrolę jakości, zawężenie analizy do tego obszaru jest w pełni uzasadnione. 

Niestety wiele projektów patrzy jeszcze bardziej wąsko i błędnie zakłada, że w tym obszarze nie ma żadnej alternatywy. Dlatego decydują się tylko na testy automatyczne, lub - jeśli prowadzą testy manualne - to dążą do pełnej automatyzacji. 

Nie ma sensu liczyć ROI

Wybór metody testów manualne kontra automatyczne to wybór, który musi bazować na relacji trzech czynników w ramach trójkąta jakości. Wybrana metoda musi mieć najlepszą relację kontroli jakości do ceny i czasu wykonania. 

Jeśli jednak mówimy, że ta relacja jest najlepsza to znaczy, że zanim zaczniemy projekt, musimy określić, co da nam więcej korzyści w relacji do kosztów i dodatkowo w akceptowalnym czasie. Stąd wniosek, że czyste ROI automatyzacji może nie być możliwe do zmierzenia. Innymi słowy, nie jesteśmy w stanie określić nawet przybliżonego zwrotu z inwestycji w żadną z metod i może nie jest to po prostu potrzebne. Do tego wniosku doszła Graham po publikacji wraz z Fewsterem książki: „Experiences of Test Automation”. W swoim artykule „Is it dangerous to measure ROI for test automation?” pisze:

„W naszej książce jest wiele historii sukcesów automatyzacji, w których zwrot z inwestycji (ROI) nie został dokładnie obliczony, więc być może zwrot z inwestycji (ROI) nie jest tak istotny, jak mogłoby się wydawać”.

Mamy pewność, że jeśli automatyzacja lub (testy manualne) są jedyną formą kontroli jakości, to nie ma sensu liczyć ich wartości, ponieważ i tak nie ma alternatywy. Musimy więc je uruchomić, aby kontrolować pracę programistów. Z drugiej strony, jeśli w jakimś obszarze mogą funkcjonować przynajmniej dwie metody kontroli jakości, to poprzez policzenie ROI jesteśmy w stanie określić, która z nich przyniesie nam największe korzyści. Pytanie, jakie musimy sobie zadać, to która z metod jest tańsza, szybsza i skuteczniejsza w osiągnięciu naszych celów?

Licząc więc ROI dla automatyzacji robimy to tylko po to, by porównać je z innymi metodami. 

Tutaj musimy jeszcze pokonać dwie pułapki porównania „metoda A vs. metoda B”. Pierwsza została sformułowana przez Jamesa Bacha w „Test Automation Snake Oil” i mówi o tym, iż lekkomyślnie zakładamy, że możemy policzyć koszty i korzyści testów manualnych vs. testów automatycznych. Bach pisze: „[…] w rzetelnym porównaniu bierze udział tak wiele szczegółów i ukrytych czynników, że najlepszym sposobem na ocenę problemu jest odniesienie go do szeregu rzeczywistych projektów oprogramowania.”. Co możemy rozumieć jako: póki sami nie sprawdzimy na prawdziwym projekcie obu metod, póty nie będziemy wiedzieli, co się opłaca, a co nie.

Druga pułapka to ślepa wiara w to, że istnieje jedna metoda kontroli jakości w projekcie, która zapewni pełną skuteczność w realizacji celów. Rzadko kiedy będzie to jedna metoda. Powinniśmy rozważyć różne metody oraz to, które z nich i w jakim procencie powinny być w projekcie stosowane. Nigdy nie będzie to 100% automatów lub 100% testów manualnych. Stosowane metody będą względem sobie komplementarne.

Liczenie kosztów i korzyści automatyzacji 

Na potrzeby analizy ROI możemy przygotować dwie tabele: kosztów i korzyści. Przykład.
KOSZTYKORZYŚCIKoszty i korzyści możemy analizować w trzech momentach trwania procesu testowego:

1. Planowanie z estymacją przyszłych kosztów oraz potencjalnych korzyści.
2. Monitorowanie w trakcie trwania stosowania metod kontroli jakości z podsumowaniem już poniesionych kosztów oraz nakładów, jakie jeszcze muszą zostać poniesione; potencjalne uzyskane korzyści oraz zakładane przyszłe korzyści.
3. Retrospektywa na koniec projektu z danymi o wszystkich poniesionych kosztach oraz korzyściach osiągniętych do tego momentu. 

Podczas gdy planowanie, monitorowanie i retrospektywa kosztów automatyzacji są relatywnie proste, tak już oszacowanie korzyści jest niemalże niemożliwe. Możemy oczywiście łatwo wymienić potencjalne korzyści, ale przetransformowanie ich w wartości finansowe ma zbyt wiele założeń, co czyni ją prawie niemożliwą do policzenia. Przyglądając się elementom katalogów korzyści automatyzacji zauważymy, że można je traktować jako czynniki do porównania z innymi metodami lub jako niepoliczalne:

1. Oszczędność czasu, szybsze uruchamianie testów – ta korzyść musiałaby być liczona jako liczba zaoszczędzonych godzin pracy w stosunku do innej metody kontroli jakości; krótszy czas uruchomienia testów zazwyczaj okupiony jest innymi nakładami, np. dużą inwestycją w zbudowanie i utrzymanie testów (automatyzacja testów) lub w analizę po uruchomieniu (automatyczna weryfikacja).
2. Poprawa jakości - testy automatyczne są bardziej powtarzalne i dokładniejsze niż testy manualne, co przekłada się na wyższą jakość oprogramowania. Czy będziesz w stanie określić, co oznacza wyższa jakość oprogramowania oraz jaką korzyść finansową nam to przyniesie?
3. Redukcja kosztów, gdy automatyzacja testów pozwala na zmniejszenie nakładów pracy testerów manualnych - wymaga to określenia ile mniej testów manualnych przeprowadziliśmy i czy jest to rzeczywiście koszt mniejszy od kosztu przygotowania i prowadzania testów automatycznych.
4. Lepsza kontrola, szczególnie po wprowadzeniu zmian – regresja oprogramowania jest szczególnie podatna na weryfikację automatyczną, ale testy regresji zazwyczaj są „ślepo” wykonywane bez analizy tego, co mogło zostać zepsute; musielibyśmy być w stanie policzyć przed czym zostaliśmy ustrzeżeni dzięki ich uruchomieniu.
5. Mniejsza rotacja pracowników z powodu ciekawszych i mniej powtarzalnych zadań – musiałoby to uwzględnić analizę kosztów odejścia pracowników z powodu tego, że zostają przymuszeni do testowania manualnego. 

W katalogu korzyści pomijamy te wpadające do koszyka testów, które można jedynie wykonać automatycznie, jak „automatyzacja pozwala na równoczesne uruchamianie wielu testów, co zwiększa wydajność procesu testowania”, czy „automatyzacja pozwala na przetestowanie większej liczby przypadków niż testy manualne, co zapewnia większe pokrycie testami”. 

Jak widzimy korzyści całego testowania są niemalże niemożliwe do zaplanowania z wyprzedzeniem, nic więc dziwnego, że nie możemy tego zrobić również dla automatyzacji. Co więcej, będą one również ciężkie w monitorowaniu, bo wymagają od nas wielu założeń. Przykład znalezienia awarii zanim pojawi się ona na produkcji jest oczywistą korzyścią procesu testowego; jeśli jednak chcemy dzięki niej pokazać przewagę jednej metody nad inną, to musimy założyć, że: 

• inna metoda nie byłaby w stanie znaleźć tej awarii,
• awaria nie zostanie wyeliminowana w inny sposób zanim trafi na produkcję,
• są jakieś policzalne koszty, jakie poniesie twórca oprogramowania za pojawienie się awarii na produkcji,
• itd. 

Korzyści opisane jako: „szybciej”, „taniej”, „lepiej” czy „mniej” wskazują, że wymagamy drugiej metody z jaką musielibyśmy się porównać. 

Podsumowanie

Wybierając jeden z trzech przedstawionych na wstępie scenariuszy najbardziej przychylam się do „Zyski z automatyzacji są niepoliczalne”. Musimy pogodzić się z tym, że nie da się policzyć zwrotu z inwestycji dla żadnej z metod kontroli jakości, a automatyzacja nie jest tu wyjątkiem. Koszty możesz policzyć z dużą dokładnością na koniec projektu, ale już korzyści automatyzacji możesz określić jedynie z pewnym przybliżeniem i z mnogością założeń. 

Żeby spróbować określić czy jest jakaś „lepsza” metoda kontroli jakości, musisz sprawdzić skuteczność przynajmniej dwóch z nich w trakcie trwania realnego procesu. W ostatecznym rozrachunku wyjdzie Ci, że są obszary, które lepiej jest automatyzować i inne, gdzie można taniej testować manualnie. Do tego powinieneś jeszcze rozważyć czy nie ma innej niż automatyzacja i ręczne testowanie metody kontroli jakości, która skuteczniej osiągnie twoje cele jakości. 

Powyższy artykuł jest opracowaniem powstałym na podstawie analiz dla prezentacji „Automatyzacja testów dla Managerów” złożonej z części wykładowej oraz części Q&A.