Redakcja
Metryki mogą służyć do monitorowania wdrożenia i realizacji strategii testów automatycznych oraz skuteczności i efektywności rozwiązania dla testów automatycznych. Metryki te są niezależne od metryk związanych z systemem podlegającym testowaniu, które służą do monitorowania tego systemu oraz przebiegu jego testowania (funkcjonalnego i niefunkcjonalnego). Metryki dotyczące automatyzacji testów umożliwiają managerom odpowiedzialnym za automatyzację testów i inżynierom automatyzacji testów śledzenie postępów w realizacji celów automatyzacji testów oraz monitorowanie skutków zmian.
Metryki dotyczące rozwiązania służącego do automatyzacji można podzielić na dwie kategorie: zewnętrzne i wewnętrzne. Metryki zewnętrzne służą do pomiaru wpływu rozwiązania na inne działania (zwłaszcza na czynności testowe), a wewnętrzne — do pomiaru skuteczności i efektywności realizacji celów tegoż rozwiązania.
Poniżej wymieniono typowe metryki dotyczące rozwiązania do testów automatycznych.
Metryki zewnętrzne dotyczące:
- korzyści z automatyzacji,
- nakład pracy na tworzenie testów automatycznych,
- nakład pracy na analizowanie incydentów związanych z testami automatycznymi,
- nakład pracy na utrzymanie testów automatycznych,
- stosunek liczby awarii do liczby defektów,
- czas wykonywania testów automatycznych,
- liczba automatycznych przypadków testowych,
- liczba rezultatów zaliczonych i niezaliczonych,
- liczba rezultatów fałszywie zaliczonych i fałszywie niezaliczonych,
- pokrycie kodu.
Metryki wewnętrzne dotyczące rozwiązania do automatyzacji:
- metryki dotyczące skryptów narzędzi,
- gęstość defektów w kodzie testów automatycznych,
- szybkość i efektywność komponentów automatyzacji,
Przyjrzyjmy się bliżej poszczególnym metrykom i ich zastosowaniom.
Korzyści wynikające z automatyzacji
Pomiar i wykazywanie korzyści wynikających z zastosowania automatyzacji są niezwykle istotne. Wynika to z faktu, że o ile koszty (wyrażone liczbą osób zaangażowanych w projekt w danym okresie) są dobrze widoczne, przez co osoby nieuczestniczące w testowaniu łatwo mogą wyrobić sobie zdanie na temat ogólnych wydatków, o tyle uzyskane korzyści nie są już tak oczywiste. Dobór miar służących do określania korzyści zależy od celu danej automatyzacji testów. Wśród typowych korzyści można wymienić zmniejszenie czaso- lub pracochłonności testowania, zwiększenie ilości testowania (tj. szerokości/głębokości pokrycia lub częstotliwości wykonywania testów), zwiększenie powtarzalności, lepsze wykorzystanie zasobów czy zmniejszenie liczby błędów związanych z czynnościami wykonywanymi manualnie. Mierzyć można między innymi:
- zmniejszenie nakładu pracy na testowanie manualne (wyrażone liczbą godzin)
- zmniejszenie czasochłonności testowania regresji
- liczbę dodatkowych cykli wykonywania testów
- liczbowy lub procentowy wzrost liczby wykonywanych testów
- udział procentowy przypadków testowych dla testów automatycznych w całym zbiorze przypadków testowych (z zastrzeżeniem, że porównywanie przypadków testowych dla testów manualnych i automatycznych nie jest łatwe)
- wzrost pokrycia (wymagań, funkcjonalności, strukturalnego)
- liczbę defektów wykrytych na wcześniejszym etapie dzięki automatyzacji (jeśli znane są średnie korzyści wynikające z wcześniejszego wykrycia defektów, można na tej podstawie wyliczyć łączne koszty, których dzięki temu uniknięto)
- liczbę defektów wykrytych dzięki automatyzacji, które nie zostałyby wykryte w ramach testowania manualnego (np. defektów związanych z niezawodnością).
Należy również zaznaczyć, że automatyzacja testów pozwala zwykle zmniejszyć nakłady pracy związane z testowaniem manualnym, a zwolnione w ten sposób zasoby można skierować do wykonywania innego rodzaju testów (także manualnych), na przykład do testowania eksploracyjnego. Defekty wykryte dzięki takim dodatkowym testom można również zaliczyć do korzyści pośrednich wynikających z zastosowania automatyzacją, ponieważ ich wykonanie stało się możliwe dzięki automatyzacji testów (gdyby nie automatyzacja, testy te nie zostałyby wykonane, a tym samym nie udałoby się wykryć dodatkowych defektów).
Nakład pracy na budowanie testów automatycznych
Nakład pracy na tworzenie testów automatycznych jest jednym z najważniejszych składników kosztów związanych z automatyzacją testów. Koszt automatyzacji jest często wyższy niż koszt manualnego wykonywania tych samych testów, co może być przeszkodą w rozszerzaniu zakresu wykorzystania automatyzacji. o ile koszt implementacji konkretnego testu automatycznego zależy w dużej mierze od samego testu, o tyle należy również uwzględnić inne czynniki, takie jak przyjęte podejście do tworzenia skryptów, znajomość narzędzia testowego, środowisko czy poziom umiejętności inżyniera automatyzacji testów.
Zautomatyzowanie większych lub bardziej złożonych testów trwa zwykle dłużej niż zautomatyzowanie testów krótszych lub prostszych, dlatego do obliczania kosztów automatyzacji testów można wykorzystać średni czas tworzenia testu. Aby uzyskać bardziej precyzyjne wyliczenia, można dodatkowo uwzględnić średni koszt dotyczący konkretnego zbioru testów (obejmującego, na przykład, testy dotyczące tej samej funkcji lub wykonywane na tym samym poziomie testów). Innym rozwiązaniem jest wyrażenie kosztów tworzenia testów w terminach wskaźnika określającego nakład pracy niezbędny do manualnego wykonania danego testu (tzw. ekwiwalentu nakładu testowania manualnego — equivalent manual test effort, EMTE). W ten sposób można na przykład stwierdzić, że zautomatyzowanie danego przypadku testowego jest dwa razy bardziej pracochłonne niż wykonanie go manualnie (2 EMTE).
Nakład pracy na analizowanie awarii systemu podlegającego testowaniu (ang. System Under Test - SUT)
Analizowanie awarii SUT wykrytych podczas wykonywania testów automatycznych może być dużo bardziej skomplikowane niż w przypadku testów wykonywanych manualnie, ponieważ zdarzenia prowadzące do awarii w teście manualnym są zwykle znane wykonującemu go testerowi (problem ten można częściowo ograniczyć na poziomie projektowania w sposób opisany w punkcie 3.1.4. oraz na poziomie raportowania w sposób opisany w podrozdziałach 5.3. i 5.4.). Ta miara w tym obszarze może być wyrażona przy użyciu średniej wartości w przeliczeniu na każdy niezaliczony przypadek testowy lub przy użyciu ekwiwalentu nakładu testowania manualnego (EMTE). To drugie rozwiązanie sprawdza się zwłaszcza w sytuacji, w której testy automatyczne różnią się znacznie złożonością i czasem wykonywania.
Niezwykle istotną rolę w analizowaniu awarii odgrywają funkcje logowania dostępne w systemie podlegającym testowaniu i automatyzacji. Funkcje te powinny dostarczać informacji wystarczających do efektywnego przeprowadzenia analizy. W przypadku logowania danych ważne jest:
- synchronizowanie procesów logowania danych w systemie podlegającym testowaniu i automatyzacji,
- logowanie przez automat oczekiwanego i rzeczywistego zachowania,
- logowanie przez automat czynności, które mają zostać wykonane.
Z kolei po stronie systemu podlegającego testowaniu należy logować wszystkie wykonywane czynności (bez względu na to, czy wynikają one z testowania manualnego czy automatycznego). Ponadto zaleca się logowanie wszelkich błędów wewnętrznych oraz udostępnianie ewentualnych zrzutów awaryjnych i śladów stosu (stack traces).
Nakład pracy na utrzymanie testów automatycznych
Nakład pracy niezbędny do ciągłego synchronizowania wersji testów automatycznych z systemem podlegającym testowaniu może być bardzo duży, a w ostatecznym rozrachunku nawet przeważyć nad korzyściami wynikającymi z zastosowania automatyzacji. Było to przyczyną niepowodzenia wielu przedsięwzięć związanych z automatyzacją. Dlatego monitorowanie pracochłonności pielęgnacji jest ważnym procesem, który pozwala zasygnalizować konieczność podjęcia odpowiednich kroków w celu zmniejszenia nakładów pracy lub przynajmniej ograniczenia ich niekontrolowanego wzrostu.
Miarą nakładu pracy związanego z pielęgnacją może być łączna pracochłonność pielęgnacji wszystkich testów automatycznych, które wymagają aktualizacji w związku z każdą nową wersją systemu podlegającego testowaniu. Oprócz tego można posłużyć się średnią wartością w przeliczeniu na każdy zaktualizowany test automatyczny lub wyrazić ją jako część EMTE.
Metryką pokrewną jest liczba lub odsetek testów, w przypadku których niezbędne jest wykonanie prac związanych z pielęgnacją.
Wiedza na temat pracochłonności pielęgnacji testów automatycznych (lub możliwość wyznaczenia tej wielkości w sposób pośredni) może odegrać istotną rolę przy podejmowaniu decyzji o zaimplementowaniu/niezaimplementowaniu określonych funkcjonalności bądź o usunięciu/nieusunięciu określonego defektu. Nakład pracy niezbędny do zaktualizowania przypadku testowego w związku z modyfikacją oprogramowania należy rozpatrywać łącznie z modyfikacją SUT.
Stosunek liczby awarii do liczby defektów
Powszechnym problemem związanym z testami automatycznymi jest fakt, że wiele z nich kończy się niepowodzeniem z tego samego powodu: na skutek pojedynczego defektu w oprogramowaniu. Testy mają oczywiście na celu wskazanie defektów oprogramowania, ale wykrywanie tego samego defektu przez kilka testów jest nieekonomiczne — zwłaszcza w przypadku testów automatycznych, gdzie nakład pracy związany z analizą każdego niezaliczonego testu może być znaczny. Pomiar liczby testów automatycznych, które kończą się niepowodzeniem na skutek określonego defektu, może pomóc zidentyfikować sytuacje, w których może wystąpić tego rodzaju problem. Rozwiązaniem jest wówczas właściwe zaprojektowanie testów automatycznych i właściwy dobór wykonywanych testów.
Czas wykonywania testów automatycznych
Jedną z łatwiejszych do określenia metryk jest czas potrzebny do wykonania testów automatycznych. Na początkowym etapie eksploatacji rozwiązania do automatyzacji może to być mniej istotne, ale wraz ze wzrostem liczby przypadków testowych dla testów automatycznych metryka ta może nabrać stosunkowo dużego znaczenia.
Liczba przypadków testowych dla testów automatycznych
Ta metryka może posłużyć do określenia postępu realizacji projektu automatyzacji testów. Należy jednak wziąć pod uwagę to, że sama liczba automatycznych przypadków testowych nie dostarcza zbyt wielu informacji (na przykład, nie wskazuje, czy wzrosło pokrycie testowe).
Liczba rezultatów zaliczonych i niezaliczonych
Jest to powszechnie stosowana metryka, która służy do śledzenia liczby zaliczonych testów automatycznych oraz testów, w przypadku których nie osiągnięto oczekiwanego rezultatu. Każdy rezultat niezaliczony należy przeanalizować, aby ustalić, czy test nie został zaliczony na skutek defektu w systemie podlegającym testowaniu, czy też w wyniku problemów zewnętrznych, takich jak nieprawidłowe działanie środowiska lub samego rozwiązania do automatyzacji.
Liczba rezultatów fałszywie zaliczonych i fałszywie niezaliczonych
Jak już wspomniano przy kilku poprzednich metrykach, analizowanie niezaliczonych testów może być dość czasochłonne. Sytuacja jest tym bardziej frustrująca, gdy okazuje się, że mamy do czynienia z fałszywym alarmem. Dzieje się tak, jeśli problem leży po stronie automatyzacji lub przypadku testowego, a nie po stronie systemu podlegającego testowaniu. Nie ulega zatem wątpliwości, że liczbę fałszywych alarmów (wiążących się potencjalnie ze zbędnymi nakładami pracy) należy utrzymywać na jak najniższym poziomie. Rezultaty fałszywie niezaliczone mogą powodować spadek zaufania do automatyzacji, ale to rezultaty fałszywie zaliczone mogą okazać się groźniejsze. Rezultat fałszywie zaliczony oznacza, że w systemie podlegającym testowaniu wystąpiła awaria, ale nie została ona zidentyfikowana przez mechanizm automatyzacji testów, przez co zgłoszony został rezultat pozytywny. W takim przypadku potencjalny defekt może pozostać niewykryty. Przyczyną może być nieprawidłowa weryfikacja wyniku, zastosowanie niepoprawnej wyroczni testowej lub nieprawidłowe określenie oczekiwanego rezultatu w przypadku testowym.
Należy pamiętać, że fałszywe alarmy mogą być spowodowane zarówno defektami w kodzie testowym (patrz metryka „gęstość defektów w kodzie testów automatycznych”), jak i nieprzewidywalnym zachowaniem niestabilnego systemu podlegającego testowaniu (np. przekroczeniem limitu czasu). Z uwagi na wysoki poziom inwazyjności przyczyną fałszywych alarmów mogą być również zaczepy testowe (test hooks).
Pokrycie kodu
Określenie pokrycia kodu systemu podlegającego testowaniu przez poszczególne przypadki testowe pozwala uzyskać przydatne informacje. Parametr ten można również mierzyć na wysokim poziomie, na przykład w kategoriach pokrycia kodu przez zestaw testów regresji. Nie istnieje przy tym jedna wartość procentowa wskazująca na wystarczające pokrycie, a pokrycie na poziomie 100% kodu jest osiągalne jedynie w najprostszych aplikacjach. Powszechnie uznaje się jednak, że większe pokrycie jest korzystne, ponieważ ogranicza ogólne ryzyko związane z wdrożeniem oprogramowania. Metryka ta może również sygnalizować wykonanie określonych czynności w systemie podlegającym testowaniu — na przykład spadek pokrycia kodu oznacza, że do systemu dodano najprawdopodobniej kolejne funkcje, a do zestawu testowego automatycznych nie dodano jeszcze odpowiedniego przypadku testowego.
Metryki dotyczące skryptów narzędzi
Istnieje wiele metryk umożliwiających monitorowanie procesu tworzenia skryptów automatyzacji, przy czym w większości są one podobne do metryk stosowanych w odniesieniu do kodu źródłowego systemu podlegającego testowaniu. Na przykład, liczba linii kodu i złożoność cyklomatyczna pozwalają zidentyfikować nadmiernie rozbudowane lub skomplikowane skrypty (sugerując możliwe przeprojektowanie, o ile okaże się to potrzebne).
Stosunek liczby komentarzy do liczby instrukcji wykonywalnych może pomóc w określeniu zakresu niezbędnej dokumentacji i adnotacji skryptu, a liczba niezgodności ze standardami dotyczącymi tworzenia skryptów wskazuje, na ile przestrzegane są obowiązujące zasady.
Gęstość defektów w kodzie testów automatycznych
Podobnie jak kod systemu podlegającego testowaniu, kod testów automatycznych również stanowi oprogramowanie i może zawierać defekty, w związku z czym nie powinien być traktowany jako mniej ważny niż kod systemu podlegającego testowaniu. Oznacza to, że również w tym przypadku należy stosować dobre praktyki i standardy dotyczące tworzenia kodu oraz monitorować rezultaty przy użyciu odpowiednich metryk, takich jak gęstość defektów w kodzie testów automatycznych. Zbieranie metryk jest łatwiejsze w przypadku korzystania z systemu zarządzania konfiguracją.
Szybkość i efektywność komponentów automatyzacji
Różne czasy wykonania tych samych kroków testów w tym samym środowisku mogą sygnalizować problem po stronie systemu podlegającego testowaniu. Jeśli SUT nie wykonuje tych samych funkcji w tym samym czasie, należy podjąć działania wyjaśniające. Objawy te mogą wskazywać na zmienność parametrów systemu, która jest nie do przyjęcia i może jeszcze pogłębić się pod zwiększonym obciążeniem. Trzeba jednocześnie zaznaczyć, że wydajność automatyzacji musi być na tyle duża, aby działanie rozwiązania nie wpływało negatywnie na wydajność systemu podlegającego testowaniu. Jeśli wydajność jest krytycznym wymaganiem stawianym systemowi podlegającemu testowaniu, należy to uwzględnić przy projektowaniu automatyzacji.
Metryki dotyczące trendów
W przypadku wielu opisanych powyżej metryk cenniejsze od konkretnych wartości chwilowych mogą być zaobserwowane trendy, czyli sposób, w jaki wartości te zmieniają się w czasie. Na przykład informacja o tym, że średni koszt utrzymania w przeliczeniu na każdy test automatyczny wymagający aktualizacji jest wyższy niż w przypadku poprzednich dwóch wersji systemu podlegającego testowaniu, pozwala podjąć działania mające na celu ustalenie przyczyn wzrostu kosztów i odwrócenie niekorzystnego trendu.
Koszt pomiaru powinien być jak najniższy, co często można osiągnąć poprzez zautomatyzowanie procesów zbierania danych i raportowania.
Artykuł oparty jest na sylabusie "Certyfikowany tester ISTQB®. Sylabus specjalistyczny. Inżynier Automatyzacji Testów", a merytoryka omawiana jest podczas naszego szkolenia "Przygotowanie do egzaminu certyfikującego ISTQB® Inżynier Automatyzacji Testowania - Moduł Specjalistyczny ISTQB® Test Automation Engineer - Specialist", na które serdecznie zapraszamy. Dla uproszczenia zastąpiono pojęcia z sylabusa pojęciami praktycznymi.
Na najbliższe szkolenie "ISTQB® Inżynier Automatyzacji Testowania - Moduł Specjalistyczny" zapraszamy już w dniach 17-19 kwietnia 2023 r., online.
>> zapisz się na szkolenie <<
