Radek Smilgin
Teza 1: Automatyzacja jest bardziej opłacalna, jeśli prowadzona jest przy pomocy narzędzi, które można stosować w wielu projektach, a nie tylko w jednym.
Tezę można wywieść z następujących elementów:
- Kod automatyzacji jest dodatkiem do całości kodu, jaki zostanie napisany w projekcie.
- Koszt automatyzacji musi zostać poniesiony przez projekt.
- Koszt automatyzacji nigdy nie jest pomijalnie mały.
- Koszt narzędzia automatycznej weryfikacji może być pomijalnie mały.
Wniosek: jeśli narzędzie testowe (automatyzację) napiszemy na potrzeby pojedynczego projektu, to koszt jego przygotowania może nam się nigdy nie zwrócić czy to w postaci szybszego wykonania testów, czy też lepszej jakości weryfikowanego produktu. Jeśli jednak do automatyzacji użyjemy gotowego rozwiązania, frameworku czy też biblioteki, to szansa na pozytywny zwrot z inwestycji rośnie.
Teza 2: Automatyzacja jest skuteczna w znajdowaniu defektów regresji.
Wiele źródeł (w tym ISTQB®) podaje, że największą stopę zwrotu gwarantuje inwestycja w automatyzację monitorowania regresu oprogramowania.
Teza 3: Duża część uruchomień testów automatycznych wykonywanych jest bez wyraźnego celu.
Tę tezę możemy wywieść bezpośrednio z tezy poprzedniej, gdzie mówimy o testowaniu automatycznym jako narzędziu monitorowania regresu. Testy nie są więc ukierunkowane na potwierdzenie, że coś działa. Nie są również nastawiane na wykrywanie konkretnych defektów. Mają jedynie określić czy coś, co działało wcześniej, ciągle działa.
Możemy przyjąć, że celem projektowym jest kontrola regresu oprogramowania, jednak w wielu przypadkach test jest uruchamiany nawet, jeśli obszar testowany nie został zmodyfikowany. Po prostu po dowolnej zmianie uruchamia się wszystkie testy. Tak działa to w CI/CD, gdzie automatyzacja często nie jest ukierunkowana i jest ślepym uruchomieniem testów. Zakładając, że uruchomienie testu jest wartościowe, kiedy test dostarcza nową, nieznaną nam wcześniej informację, to jest to celowe.
Teza 4: Automatyzacja testów unitowych pozwala zredukować koszty regresji w kodzie
Znacząca część defektów projektu to te wprowadzane do kodu źródłowego podczas pierwszego kodowania. Stanowią one wg badań (85%) wszystkich defektów, jakie są wprowadzane do systemu w trakcie jego produkcji.
Jednocześnie większość defektów jest znajdywanych na późniejszych etapach testów, np. systemowych. Ryzyko regresu i koszty jego pojawienia się najlepiej mitygować na poziomie testów jednostkowych. To jest prawdziwe shift-left.
Teza 5: Większość projektów automatyzacji testów GUI nie ma szans na pozytywne ROI.
Abstrahując od faktu, że ROI jest niemalże niemożliwe do policzenia, to automatyzacja testów GUI jest prawdziwym shift-right. Defekty, które są wprowadzane w fazie kodowania, znajdywane są na samym końcu. Wskazuje to na niewielką opłacalność przy dużych kosztach implementacji. Potwierdzają to eksperci jak np. Alan Page w „The A Word”: „Zaryzykuję i powiem następujące stwierdzenie. W przypadku 95% wszystkich aplikacji oprogramowania, bezpośrednie automatyzowanie GUI jest stratą czasu. Dla porządku, najpierw wpisałem 99% powyżej, a potem się wycofałem.”
Teza 6: Automatyzacja testów wymaga ciągłego ponoszenia kosztów jej utrzymania. W innym przypadku nastąpi jej degradacja.
Wywodzę tę tezę z:
- koszt automatyzacji jest ciągły. Raz podjęta decyzja o automatyzacji wymaga jej nieustannego utrzymania zgodnie ze zmianami kodowymi,
- nieutrzymywana automatyzacja będzie traciła na swojej skuteczności przy każdym update’cie oprogramowania do jakiego została napisana.
Jeśli organizacja przerwie utrzymanie automatyzacji, to powrót do niej będzie bardzo trudny albo wręcz niemożliwy.
Jeśli macie jakieś swoje w miarę ugruntowane tezy automatyzacji testów prosimy o ich wpisanie w komentarze.
Możecie wysłuchać 6 tez automatyzacji z webinaru "Automatyzacja dla Managerów":
