TABLE OF CONTENTS:
Czy można realizować automatyzację testów oprogramowania bez konkretnego planu? Co powinna zawierać dobrze przygotowana strategia? O automatyzacji testów oprogramowania, jej plusach i minusach oraz korzyściach dla biznesu rozmawiamy z Michałem Zaczyńskim, Ekspertem ds. Testowania Oprogramowania.
Trudno rozpatrywać korzyści biznesowe w oderwaniu od przedmiotu automatyzacji, technologii, w której jest stworzony produkt, czy konkretnych narzędzi. Testowanie oprogramowania zawsze przynosi profity.
W przypadku prostej strony www bez skomplikowanej logiki biznesowej, stworzonej dzięki wykorzystaniu popularnej platformy, możemy poznać wyniki testów nawet w ciągu kilku godzin, używając komercyjnych narzędzi do automatyzacji. Natomiast w przypadku bardziej skomplikowanych przedmiotów testów oprogramowania oraz mnogości wykorzystywanych narzędzi do automatyzacji testów czy budowania własnych, skrojonych na miarę frameworków ten czas znacząco się wydłuża – nawet do 2-3 miesięcy.
Warto jednak zaznaczyć, że dla biznesu nie jest to czas stracony. Każdy napisany test automatyczny to oszczędność czasu przeznaczanego na manualne sprawdzanie, dzięki czemu można go wykorzystać na inne, bardziej zaawansowane działania.
Jako długoterminowe korzyści można wymienić te najważniejsze jak feedback o jakości aplikacji, możliwość częstszego testowania, uwolnienie zasobów czasowych testerów manualnych, którzy mogą się skoncentrować na niepokrytych do tej pory testami automatycznymi obszarach, czy też powtarzalność samych testów automatycznych. To wszystko powoduje znaczącą poprawę samego procesu testowego, a finalnie skutkuje lepszej jakości produktem, oczywiście przy założeniu naprawy zgłoszonych defektów.
Nie, nie jest wymagana i w wielu przypadkach nie ma biznesowego uzasadnienia jej przeprowadzania. Ma to szczególnie miejsce w przypadku projektów krótkoterminowych, w których wprowadzenie automatyzacji mogłoby zająć więcej czasu niż sam rozwój produktu. Innym przykładem mogą być projekty ściśle związane ze sprzętem, gdzie wymagane są działania manualne np. w celu wymiany chipa, przepięcia kart rozszerzeń itd. W tym wypadku koszt utworzenia urządzeń, które byłyby używane podczas testów automatycznych, jest zbyt duży w stosunku do korzyści. Kolejnym przykładem może być projekt koncentrujący się tylko na części graficznej aplikacji (UI), która ulega bardzo częstym zmianom. W tym przypadku również szczególnej analizie należy poddać fakt, czy koszt utrzymania takich testów nie przerośnie potencjalnych korzyści.
Zdecydowanie solidna analiza biznesowa oraz zdefiniowanie na jej podstawie realistycznych celów, które chcemy osiągnąć dzięki automatyzacji.
Strategia automatyzacji testów powinna zawierać między innymi:
Wydaje się, że niemożliwym jest przeprowadzenie automatyzacji testów, pomijając któryś z powyższych kroków. Nawet, jeśli prowadzimy projekt bardzo podobny do już zrealizowanego, wykorzystujący te same technologie i zasoby, to podświadomie i tak analizujemy możliwości rozwoju.
Warto też pamiętać, że brak strategii również może być strategią.
Wynikają one bezpośrednio z kroków wchodzących w skład strategii, zdefiniowanych we wcześniejszym pytani i są to:
Strategia jest dobra, kiedy pozwala osiągnąć zdefiniowane cele przy akceptowalnej wartości ROI. Te dwie informacje bez wątpienia potwierdzają, że wybrana droga automatyzacji jest właściwa.
W kontekście najnowszych trendów można zauważyć próbę zdobycia rynku przez różne narzędzia wykorzystujące AI i stosujące podejście codeless. Nie zdominowały one jeszcze rynku, ale na pewno stają się coraz popularniejsze. Wydaje się, że główną przeszkodą w ich używaniu jest koszt licencji, często uzależniony od tworzonej liczby testów. Na pewno warto też wspomnieć o frameworku Playwright (open source), o którym coraz więcej słychać w testerskiej społeczności.
Dobrych praktyk jest wiele, ale wydaje się, że wszystkie można skupić w jedno – traktuj automatyzację testów oprogramowania, jak każdy innych projekt deweloperski, kierując się tymi samymi zasadami. Dzięki takiemu podejściu nie będziesz na nowo rozwiązywać starych i dobrze znanych problemów, niezależnie od tego, czy tworzysz aplikację, czy “tylko” piszesz testy automatyczne.
