Mity i grzechy automatyzacji testowania oprogramowania

Maciej Kirkicki Starszy Konsultant, PwC Polska 19/06/18

A może by tak zautomatyzować testowanie oprogramowania?

Z tym pytaniem często przychodzą osoby odpowiedzialne za budżet w projektach informatycznych, szukając w automatyzacji szansy na redukcję kosztów testowania tworzonego produktu.

Niestety w większości przypadków decyzja o rozpoczęciu pracy nad automatyzacją testów oprogramowania nie jest oparta na żadnej analizie aktualnych procesów w firmie, a co za tym idzie są popełniane błędy, które powodują, że kierownicy w ogóle się zniechęcają do automatyzacji.

Mit 1: Automatyzacja testów wykrywa więcej błędów

Nie jest to prawda. Automatyzacja testowania oprogramowania nie wykrywa błędów. Automat testowy daje nam informację o tym, że system zachowuje się poprawnie przy standardowym użyciu. Jest to sprawdzenie, czy system zachowuje się zgodnie z oczekiwaniami. Nawet jeśli napotka anomalię, wymagana jest analiza i powtórzenie przypadku manualnie, celem zidentyfikowania przyczyny i poprawnego zgłoszenia błędu. Automat testowy daje nam więc informację, że system zachowuje się poprawnie przy standardowym użyciu.

Grzech 1: Oczekiwanie skryptów, które znajdą błędy

Wynika on oczywiście bezpośrednio z mitu opisanego powyżej. Powszechną praktyką jest wymuszanie na zespole takiej konstrukcji testów, które będą znajdowały usterki w systemie. Wynika to z braku pełnej informacji. Skrypt automatyczny to program, który sprawdza inny program. Tak więc żeby znaleźć błąd, należy przewidzieć jego wystąpienie. Jest to zasada działania wszystkich programów komputerowych: wykonanie listy instrukcji wg zadanych kryteriów. Jeśli więc jesteśmy w stanie przewidzieć błąd na etapie tworzenia skryptu testowego, to czemu nie możemy przewidzieć go na etapie tworzenia naszej aplikacji?

Mit 2: Wszystko powinno być zautomatyzowane

Jest to błędne założenie. Większość systemów jest tak rozbudowana i posiada taką mnogość funkcjonalności, że nie da się ich wszystkich pokryć testami automatycznymi. Należy również dodać, że każda funkcjonalność może mieć szereg odchyleń od standardowego zachowania, sterowanych danymi wejściowymi, co zwielokrotnia ilość przypadków testowych do stworzenia. Również koszt takiego przedsięwzięcia może przewyższyć koszt stworzenia aplikacji.

Grzech 2: Dążenie do pokrycia testami automatycznymi wszystkich systemów

Jak zostało wyżej opisane – nie jest to optymalne podejście do procesu testowego. Można nawet stwierdzić, że jest wręcz nieefektywne. Bardzo szybko zespół automatyzujący skupi się na zadaniach mało ważnych, byleby tylko pokryć cały obszar, którym się zajmuje.
Powoduje to zatarcie informacji o faktycznym stanie systemu: spośród setek testów wykonywanych cyklicznie, tak naprawdę tylko kilka daje nam obraz tego, co się tam dzieje. Reszta zagląda w zakamarki systemu, które nigdy nie zostaną użyte albo będą to pojedyncze przypadki, które mają marginalny wpływ na działanie całości systemu informatycznego.

Mit 3: Automatyzacja testów to jednorazowy koszt i szybkie ROI

Jest to całkowita nieprawda. Pisanie skryptów automatycznych to proces bardzo zbliżony do procesu tworzenia aplikacji, którą testują. Wymaga więc przygotowań, budżetu i czasu. Należy również uwzględnić koszty utrzymania skryptów automatycznych: wraz ze zmianami w systemie, zmianom ulegają też testy. Nie jest to więc koszt jednorazowy. Poza tym automatyzacja testów zagwarantuje szybki zwrot nakładów tylko jeżeli będzie przemyślana i dobrze zaplanowana.

Grzech 3: Pochopne wdrażanie automatyzacji w projekcie i redukcja testów manualnych

Pokłosiem mitu nr 3 jest praktyka polegająca na wytypowaniu jednej lub kilku osób, które mają natychmiast dostarczyć zestaw testów rozwiązujących problemy systemu. Niemal zawsze efektem takiego nieprzygotowanego działania są kolejne nowe problemy.
Bardzo często osoby zarządzające projektem decydują się na taki krok po obejrzeniu zachęcającej prezentacji narzędzia, które pozwala na szybkie stworzenie skryptu. Problem polega na tym, że prezentacje dotykają przypadków trywialnych i osoba prezentująca nie zdradzi ile czasu poświęciła na analizę problemu, który teraz rozwiązuje w ciągu kilku minut. Oszacowany na podstawie takiej prezentacji koszt wdrożenia może się okazać kilkukrotnie zaniżony w stosunku do końcowej wartości. To wszystko przy jednoczesnym spadku skuteczności testów manualnych, których ilość zmniejszamy w nadziei, że skrypty automatyczne rozwiążą wszystkie problemy.
Testy automatyczne redukują koszt testów manualnych w jednym tylko przypadku: dana funkcjonalność musi już być stabilna i wymagać tylko cyklicznego sprawdzania czy nadal działa (tzw. testy regresji). W każdym innym przypadku jest to koszt równoległy do testów manualnych i tak powinien być rozpatrywany.

Jak więc sobie poradzić z automatyzacją testowania oprogramowania?

Odpowiedź jest prosta – należy planować. Do wdrożenia testów automatycznych należy się przygotować. Warto rozważyć adaptację istniejących procesów celem wpasowania w nie skryptów automatycznych.

Należy to robić na ogólnym poziomie: na etapie analizy wymagań i przypadków użycia powinno się identyfikować te, które potencjalnie się nadają do automatyzacji, czyli takie, które są już dobrze rozumiane przez zespół i raczej nie będą ich dotyczyły ciągłe zmiany i przeróbki.

Dobrą praktyką jest też rozrysowanie diagramów najbardziej krytycznych funkcjonalności i dążenie do automatyzacji ich w pierwszej kolejności.

Dopóki projekt interfejsu użytkownika nie jest w zaawansowanym stadium rozwoju, należy ograniczać liczbę testów automatyzujących interakcję z tymże interfejsem. Zredukuje to znacząco koszty utrzymania takich skryptów.

Bardzo dobrą praktyką jest adaptacja całości procesu i założeń w trakcie trwania projektu. Pozwala to na optymalizację pracy zespołu. Należy tylko pamiętać, że adaptacji mają podlegać procesy dotyczące całego projektu, a nie tylko automatyzacji testów.