Koszty i wartość automatyzacji

Podkreślam, że pisząc „automatyzacja” mam na myśli projektowanie i uruchamianie skryptów na interfejsie graficznym aplikacji.

Czy my naprawdę potrzebujemy dowodów na koszty i wartość automatyzacji?

Doświadczenia jednej osoby nie mogą być wyrocznią w określaniu skuteczności i opłacalności automatów. Nawet fakt, że wiele osób miało podobne do moich niepowodzenia w automatyzacji nie jest żadnym dowodem. Ciągle jest to niewielka próbka. Pamiętając, że tezy niepoparte dowodami można obalić bez dowodu, musimy sięgnąć po badania, publikacje i źródła.

Z drugiej strony wśród zwolenników automatyzacji widać raczej dogmatyczne, żeby nie powiedzieć religijne, podejście. Wartość automatyzacji jest niekwestionowalna. Prawdopodobnie wynika to z tego, że jest duże zapotrzebowanie na automatyzację, która widoczna jest chociażby w liczbie ogłoszeń o pracę. Czy jest to jednak poparte danymi i doświadczeniami danej organizacji? Wydaje się, że nie. Wiele organizacji buduje swoją automatyzację od podstaw, bazując na tzw. juniorach. Nie mają więc bazy wiedzy, a jedynie informację z rynku o potencjale automatyzacji. Management czasami podejmuje nieracjonalne decyzje i inwestuje wysiłek w metody i metodologie, niekoniecznie przynoszące zwrot z inwestycji. Metody takie są zazwyczaj dobrze reklamowane, więc marketingowo skuteczne. Wielu managerów utożsamia automatyzację z redukcją wysiłku w testach manualnych, a co za tym idzie albo ze zwolnieniem pracowników albo wypełnieniem luki związanej z niemożnością ich pozyskania. Decyzje managerów nie mogą więc stanowić ostatecznego dowodu na wartość automatyzacji.

Potrzebujemy więc analizować dane ze wszystkich możliwych źródeł, aby pomóc organizacjom podejmować właściwe decyzje biznesowo-rozwojowe.

Czy istnieje niepodważalny dowodów na (nie)opłacalność automatyzacji?

Nie ma współczesnych i wiarygodnych badań kosztów wdrożenia i utrzymania testów automatycznych. Głównym tego powodem są nakłady na przygotowanie i poprowadzenie takich eksperymentów. Należałoby w projekcie informatycznym równolegle prowadzić testy manualne i testy automatyczne na interfejsie, aby pokazać nakłady czasowe i budżetowe na przeprowadzenie obu testów. Co więcej, należałoby te testy prowadzić w bardzo długim czasie i przy dużej liczbie nowych wersji oprogramowania. Wynika to z tego, że testy automatyczne są bardzo kosztowne w pierwszym okresie wdrożenia. Wymagają dużego wysiłku w przygotowaniu środowiska i ludzi do pracy. Prawdziwy zwrot pojawia się więc później niż w przypadku testów manualnych. W swojej książce "Implementing Automated Software Testing", wydanej przez Addison Wesley w 2009 r. Elfriede Dustin, Thom Garrett i Bernie Gauf zdefiniowali różnego rodzaju metryki. Jedną z nich jest zestawienie kosztów testów manualnych i AST (ang. automated software testing).

Źródło: http://www.methodsandtools.com/archive/archive.php?id=94

Powyższy wykres pokazuje, że koszty AST (rozumiane jako koszty każdego automatycznego weryfikowania) w początkowych etapach mogą być większe od testów manualnych.

Aby wykazać, czy testowanie automatyczne na interfejsie graficznym jest opłacalne, sięgnę do paru źródeł, które w mniej lub bardziej bezpośredni sposób o tym piszą. Zacznę od tezy, a później postaram się ją podeprzeć źródłami.

Teza 1: Automatyzacja jest bardzo kosztowna ponieważ znajduje się w późnym etapie wytwarzania oprogramowania.

Wiele źródeł, w tym między innymi sylabus ISTQB mówi o tym, że testowanie powinno występować możliwie najwcześniej. Wtedy to defekty są znajdywane i naprawiane najtaniej. Skąd wywodzą się te wnioski? Powtarzamy wyniki badań mówiące, że najwięcej defektów pojawia się w fazie definiowania wymagań (56%) oraz w fazie projektowania (27%), a jedynie 7% defektów wynika bezpośrednio z kodowania. Dodatkowo największe obciążenia dla projektu wynikają z kosztów naprawy defektów wymagań (82%) i projektu (13%). Źródło tych informacji to badania Jamesa Martina, opublikowane w „An Information Systems Manifesto” w 1984 roku. Autor badał model wodospadowy i poszukiwał nowego modelu wytwarzania oprogramowania, co doprowadziło go do zdefiniowania podejścia iteracyjnego w RAD (ang. Rapid Application Development) w 1991 roku.

Dane te to jedno z wielu źródeł informacji potwierdzające regułę 1-10-100, nazywaną często kosztem jakości (ang. Cost of Quality). Zgodnie z nią znalezienie i naprawienie defektu w specyfikacji jest od 10 do 20 razy tańsze od znalezienia i naprawienia defektu w kodzie źródłowym. Znalezienie i naprawienie defektu przed wydaniem oprogramowania jest około 10 razy tańsze od naprawienia go już po wydaniu. Te relacje zobaczymy również w badaniach Boehma z 1980 roku i w wydanej rok później książce „Software engineering economics”.

Badania objęły szereg projektów zarówno małych, jak i dużych, a ich zestawienie widoczne jest na powyższym diagramie. Kolejne potwierdzenie przychodzi wraz z „Applied Software Measurement: Global Analysis of Productivity and Quality” autorstwa Capersa Jonesa. Głębszą analizę źródeł zostawiam już osobom zainteresowanym.

Płynie z tego jasny wniosek, że testowanie automatyczne jest często nieopłacalne, ponieważ znajduje się przy końcu procesu wytwarzania oprogramowania, kiedy to aplikacja ma już ustabilizowany interfejs graficzny. Można więc potwierdzić, że testy automatyczne nie mają wartości jeżeli chodzi o znajdywanie defektów, a jedynie do kontrolowania potencjalnej regresji jakości. Czy jednak nakłady na testy regresywne powinny być aż tak znaczące?

Pojawia się tutaj jeszcze jeden ważny aspekt, o którym warto wspomnieć. Większość prowadzonych badań na projektach informatycznych ma 30 i więcej lat. Nie dotyczą więc one projektów współczesnych i agile'owych. Nie jest to jednak do końca prawda. W Agile'u redukujemy koszty zapewnienia jakości w poszczególnych iteracjach i dostajemy szybką informację zwrotną od właściciela produktu. Mimo to koszt awarii na produkcji (dla końcowego odbiorcy) jest taki sam bez względu na to, jaki model wytwarzania oprogramowania został zastosowany.

Teza 2: Automatyzacja na interfejsie graficznym powinna być zredukowana w stosunku do innych typów testów.

Pierwszy raz ta teza została sformułowana dobitnie przez Mike'a Cohna przy okazji przypomnienia ważności testów warstwy integracyjnej. Przyjęło to nazwę "piramida testów". W ogólnym zarysie chodzi o podkreślenie, że testy jednostkowe są tańsze w stworzeniu i szybsze w uruchomieniu w stosunku do drogich i wolno uruchamianych testów na interfejsie graficznym. Oczywiście Cohn mów tu o testach automatycznych.

Koncept ten był wielokrotnie dyskutowany, a ciekawy głos pojawił się ze strony Martina Fowlera, który podkreśla, że jeśli uda Ci się stworzyć wysokopoziomowe testy, które będą niezawodne, szybkie oraz łatwe w modyfikacji, to automatyzacja może się opłacać. Idąc w skrajności również zastosowanie narzędzi nagrywająco-odtwarzających będzie miało wartość jeśli wygenerowane testy będą łatwo modyfikowalne i szybkie. Jest to niestety mało prawdopodobne.

Obecność testów automatycznych była również analizowana w pracy Briana Maricka i rozwinięta przez Lisę Crispin w tzw. kwadrantach testowania Agile.

W ich publikacjach wyczytamy, że choć testy automatyczne na interfejsie mają swoją wartość, to są to jedne z wielu stosowanych metod. 

Jeśli zaufamy praktykom, to kilka wniosków nasuwa się samo:

• testy automatyczne ze względu na koszty i czas tworzenia nie powinny być testami dominującymi w procesie kontroli jakości,
• automatyczna kontrola jakości zaczyna się na poziomie kodu,
• nie warto próbować uzyskać 100% pokrycia funkcjonalnego na GUI.

Czy w związku z tym możemy generalizować i powiedzieć, że we współczesnych metodach wytwarzania oprogramowania neguje się przesadną wiarę w testy automatyczne na GUI? Tak, ale w metodach zwinnych czy też DevOps ogólnie neguje się całość testowania (postrzeganego z perspektywy testera). Wystarczy zajrzeć do Manifestu Agile, Scrum Guide, czy też do zasad kultury DevOps, aby dostrzec, że miarą sukcesu projektu informatycznego jest działające i zaakceptowane oprogramowanie. Jakość to nie jest liczba uruchomionych testów i uzyskane pokrycie, ale właśnie poziom zadowolenia końcowego użytkownika.

Teza 3: Skuteczne testy automatyczne to osobny projekt informatyczny.

Projekt informatyczny to ciąg zdarzeń, który prowadzi do wytworzenia oprogramowania. Jeśli za takie oprogramowanie przyjmiemy również testy automatyczne na interfejsie, to możemy postawić znak równości między projektem automatyzacji a projektem informatycznym.

Prowadzi to do wielu wniosków, między innymi takich, że dobry projekt powinien mieć dobre zarządzanie, budżet i programistów, którzy stworzą kod. Dlaczego tego kodu nie powinni tworzyć testerzy oprogramowania albo początkujący programiści? Dlatego, że generuje to tzw. dług technologiczny (ang. Technical Debt) zdefiniowany przez Philippe'a Kruchtena.

Dług technologiczny zaciągamy zawsze, kiedy w projektach informatycznych idziemy na skróty. Kiedy budujemy rozwiązania nieskalowalne i kiedy przeciwstawiamy sobie pojęcia wysokiej jakości i szybkiej dostawy. Koszty te zazwyczaj nie są widoczne "teraz" w projekcie informatycznym, ale będą musiały zostać „spłacone” prędzej czy później. Wikipedia wskazuje na następujące powody powstawania długu: brak podejścia procesowego, brak elastyczności przy budowaniu oprogramowania, brak dokumentacji. Tak niestety wygląda większość projektów automatyzacji, gdzie samo pisanie skryptów automatycznych jest procesem adhocowym i nieudokumentowanym.

Aby uniknąć zaciągnięcia długu, który w dłuższym okresie może doprowadzić do niepowodzenia automatyzacji możemy wdrożyć wiele dobrych praktyk:

• testy automatyczne powinny być pisane przez doświadczonych programistów,
• kod powinien być samodokumentujący się lub też opisany specyfikacją,
• czas i budżet na projekt powinny być zdefiniowane,
• itd.

Podsumowując postawione tezy możemy uznać, że jest wiele publikacji, które pokazują koszty i wartość automatyzacji. Ludzie, którzy negują sens wdrożenia i prowadzenia automatyzacji testów interfejsu graficznego oraz sceptycy współczesnego definiowania automatyzacji mają wiele argumentów, które wspierają ich punkt widzenia. Z drugiej strony jest bardzo wiele publikacji pokazujących, jak dobrze i jak skutecznie wdrażać automatyzację, jakich zasad się trzymać i jak stosować podejście projektowe.

Należy również pamiętać, że rezygnacja z automatyzacji na GUI nie oznacza redukcji jakości oprogramowania. W kolejnym artykule postaram się pokazać, co może być tańszą i efektywniejszą od automatyzacji metodą zapewnienia i kontroli jakości.

Autor: Radek Smilgin

PS. W ramach uzupełnienia polecam zapoznanie się z materiałami, które co prawda opierają się na doświadczeniach pojedynczych osób, ale są to analizy uznanych autorów:

• James Bach: „Test Automation Snake Oil” (http://www.satisfice.com/articles/test_automation_snake_oil.pdf)
• Alan Page: „The „A” Word” (https://leanpub.com/TheAWord).