Testy manualne vs. testy automatyczne

Ponieważ w całym webinarze „Automatyzacja dla Managerów” starałem się nie wyrażać własnych opinii, to jedną tezę, którą postawiłem, postanowiłem wyraźnie nazwać „Tezą  Smilgina”. Zabieg ten ma na celu pokazanie, że nie wywodzi się ona bezpośrednio z opinii ekspertów, na jakich powołuję się przy reszcie tez. W mojej próbie naukowego podejścia do automatyzacji testów spotykam się z dużym niezrozumieniem i pozamerytoryczną krytyką. Nie mogę się jednak do większości z niej odnieść, ponieważ nie niesie żadnej argumentacji wykraczającej poza „bzdura” i „u mnie działa”. Dlatego też podczas webinaru, jak i na koniec tego artykułu proszę o merytoryczną krytykę i dyskusję te z osób, które są zainteresowane porozmawiać o tym czy, gdzie, kiedy i jaka automatyzacja  się opłaca.

W poprzednim artykule (jak i webinarze) mówiłem o niepoliczalności ROI automatyzacji, a także wszystkich innych metodach kontroli jakości. Na potrzeby tej analizy ważne jest, aby uznać, że nie da się jednoznacznie policzyć zwrotu z inwestycji w kontrolę jakości, a skuteczność metod najlepiej zweryfikować przez ich sprawdzenie w projekcie IT. 

Teza Smilgina brzmi:

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.

Do tej tezy jest kilka założeń:

1. Alternatywa - testy pochodzą z obszaru „testów manualnych, które da się zautomatyzować” (zgodnie z poniższym rysunkiem). Teza nie dotyczy przypadku testów niemożliwych (nieopłacalnych) do uruchomienia ręcznego, a tym bardziej nie dotyczy testów manualnych nie wartych automatyzacji. W tym obszarze możemy dokonać wyboru czy lepiej będzie automatyzować, czy testować ręcznie. 
   
   
2. Kontekst - teza ta ma zastosowanie do większości popularnych typów projektów IT, ale nie do wszystkich. 
3. Cel – założenie jest takie, że automatyzacja i testy manualne mają mieć ten sam cel, np. potwierdzanie działania lub znajdywanie defektów. 

Z czego wywodzę tezę. 

1. Automatyzacja jest bardzo złożonym procesem. Wymaga: narzędzi, bibliotek, frameworków, skryptów, infrastruktury uruchomienia, programisty testów itd. Mamy wiele czynników, które zapisujemy po stronie kosztów.
   
   Pisze o tym Mark Fewster w “Common Mistakes in Test Automation”
   
   
   Dodatkowo pamiętajmy, że czym większa złożoność testu, tym większe koszty jego implementacji, a czym więcej automatyzacji mamy, tym więcej elementów pojawia się do utrzymania.
   
   Z drugiej strony testy manualne są skrajnie proste w obszarze projektowania i infrastruktury.
   
   Stosując Brzytwę Ockhama, czyli zasadę, zgodnie z którą w wyjaśnianiu zjawisk należy dążyć do prostoty, wybierając takie wyjaśnienia, które opierają się na jak najmniejszej liczbie pojęć i założeń, dochodzimy do wniosku, że najlepsze rozwiązanie to najprostsze rozwiązanie. Wskazuje to na testy manualne jako preferowaną metodę. 
2. Koszty (czas) działają na korzyść testów manualnych (przy przyjętych wcześniej założeniach). Powszechnie wiadomo, że czas na projektowanie i utrzymanie testów automatycznych jest dłuższy od czasu potrzebnego na te czynności w testach manualnych. 
   
   Częściowe potwierdzenie znajdujemy również u Fewster/Graham w publikacji „That's No Reason to Automate!” 
   
   
   
   Czytając literalnie obrazek powyżej, większość kosztów (czasu) testów manualnych nawet w zestawieniu z bardzo dojrzałą automatyzacją, będzie bardzo niewielkich. Znaczącym wyjątkiem jest tu oczywiście koszt (czas) uruchomienia testów. 
   
   Testy automatyczne są droższe w przygotowaniu, ale tańsze w uruchomieniu. Duża inwestycja w przygotowanie skryptów skutkuje tym, że czas uruchomienia testowania automatycznego będzie szybszy od uruchomienia testów manualnych. Jeśli więc w jakimś projekcie istnieją silne wytyczne dla szybkiego uruchomienia testów automatycznych, to testy wpadają do obszaru „tests not possible to run manually” i powinny zostać zautomatyzowane. 
   
   Możemy również zauważyć, że poczynione w 2009 roku założenia potwierdziły się do roku 2022, kiedy to The World Quality Report 2022-2023 pokazał, że koszty utrzymania testów to od 30% do 50% budżetu na testy.

Dodatkowe dowody na poparcie mojej tezy, które wywodzę z własnej pracy, obserwacji projektowej oraz własnego doświadczenia zawodowego to:

1. Praca testera manualnego jest tańsza (statystyka / ankiety).
2. Testowanie manualne osiąga skuteczność wykrywania defektów od pierwszej minuty (doświadczenie / eksperyment).
3. Testowanie manualne wykrywa wszystkie defekty, które może znaleźć automatyzacja (doświadczenie). 
4. Pierwsze sprawdzenie oprogramowania przed automatyzacją jest manualne (doświadczenie).

Już chociażby przyznanie się do tego, że część dowodów to moje własne doświadczenie, każe z zasady powątpiewać w ich wartość. Dlatego też jestem gotów publicznie bronić mojej tezy w imię lepszego, wspólnego zrozumienia automatyzacji. Jeśli ktoś chce ją krytykować, to zachęcam do:

• DEBATA – przyjmę zaproszenie na debatę z ekspertem od automatyzacji, który zechce wykazać, że się mylę,
• AUDYT – podejmę się analizy danych z dowolnego projektu, który uważa, że w jego środowisku moja teza nie jest prawdziwa,
• EKSPERYMENT – wezmę udział (po stronie testów manualnych) w dowolnym eksperymencie, którego celem będzie wykazanie, że moja teza nie jest prawdziwa.

Stawiam tylko jeden (trudny) warunek: wszystkie te działania muszą być udostępnione publicznie tak, by rzeczywiście dawały szansę na wyrobienie sobie zdania przez wszystkich. 

Moją wypowiedź z webinaru odnośnie tezy znajdziecie tutaj: