TABLE OF CONTENTS:
To jest właśnie ten dzień, w którym Twój zespół decyduje się, aby rozpocząć automatyzację testów. Dokonaliście analizy tego co da się zautomatyzować, co jest sens automatyzować, z jakimi systemami chcecie się zintegrować. Tym samym dotarliście do najważniejszego pytania – jak to zrobić? Rynek narzędzi do automatyzacji testów bardzo się rozwinął w ostatnich latach. Mamy dostępne klasyczne „korporacyjne” / gotowe narzędzia do automatyzacji. Pojawiła się również nowa gama narzędzi opartych o sztuczną inteligencję. Nadal jednak aktualne są rozwiązania oparte o budowę własnego frameworku. Świat narzędzi do automatyzacji bardzo szybko się zmienia zarówno w zakresie gamy produktów jak i ich funkcjonalności. My prezentujemy dziś stan na kwiecień 2022.
Która metoda jest więc najlepsza, żeby zautomatyzować testy oprogramowania w Twojej firmie? Spróbujmy porównać wady i zalety każdego z podejścia do pozyskania narzędzia do automatyzacji na podstawie wybranych cech.
| Cecha | Własny framework testowy | Narzędzia korporacyjne | Narzędzia z AI |
| Dopasowanie do potrzeb | idealnie dopasowany | niepełne | niepełne |
| Odporność na zmiany aplikacji | mała | mała | bardzo duża |
| Zastosowanie w innych projektach | bardzo małe (bez zmian w kodzie) | duże | duże |
| Integracja z innymi narzędziami poprzez API | pełna | częściowa | częściowa |
| Możliwość rozwoju o nowe funkcjonalności | bardzo duża | ograniczona do producenta | ograniczona do producenta |
| Wymagana wiedza techniczna do tworzenia testów | konieczna | częściowa | ograniczona do minimum |
| Czas tworzenia automatycznych testów | długi | średni | krótki |
| Koszt licencji | darmowy | wysoki | darmowy/średni |
Klasyczne narzędzia do automatyzacji testów są znane w większości dużych firm i obecne na rynku już od wielu lat. Często oparte o metodykę tworzenia testów Record&Playback, a także w oparciu o słowa kluczowe. Dzięki temu, aby rozpocząć pracę z narzędziem wymagana jest przeważnie tylko jego początkowo konfiguracja, a następnie zaprogramowanie akcji, których natywnie nie dostarcza samo narzędzie. Dzięki temu czas tworzenia automatycznych testów można określić jako średni i wielu przypadkach dłuższy niż w przypadku narzędzi z AI.
Konieczne może być również posiadanie chociaż niewielkich umiejętności programowania. Niewątpliwie, jedną z największych zalet tych narzędzi jest ich generyczność, a więc możliwość zastosowania do wielu typów aplikacji. W zdecydowanej większości umożliwiają one również integrację z systemami zewnętrznymi. Warto jednak pamiętać, że integracja jest możliwa tylko z tymi systemami, o których pomyślał wcześniej producent narzędzia.
Tym samym docieramy do dwóch największych wad tych narzędzi. Wspomniana wcześniej generyczność powoduje, że rzadko kiedy te narzędzia są idealnie dopasowane do stawianych wymagań, a dodanie do nich nowych funkcjonalności zależy tylko od decyzji ich producenta. Pomimo dużej liczby oferowanych funkcjonalności dalej możemy mieć problem ze zmianami interfejsu graficznego i tym samym będziemy zmuszeni do modyfikacji testów automatycznych.
Bardzo często czynnikiem determinującym zakup czy rezygnację z narzędzi korporacyjnych jest ich cena. Licencje przeważnie są dostępne w formie subskrypcji czasowych, a ich cena jest dość wysoka, co w przypadku dłużej trwających projektów powoduje, że stają się znaczącym elementem budżetu zespołu testowego.
Framework’i z AI to nowa gama narzędzi, podbijająca od trzech lat rynek automatyzacji testów. Mają być odpowiedzią na opisane wyżej wady narzędzi korporacyjnych. I faktycznie, ich główną zaletą jest możliwość samo-adaptacji do zmieniającego się interfejsu graficznego aplikacji. Narzędzia z AI zachowują również pewien stopień generyczności, dzięki czemu możemy je zastosować w wielu różnych projektach.
Kolejną dużą zaletą jest brak konieczności tworzenia kodu, przez co są one bardzo przyjazne dla osób z niewielkimi kompetencjami programistycznymi. Dodatkowym atutem jest bardzo krótki czas tworzenia zautomatyzowanych testów. Niestety w pewnym zakresie posiadają one wady narzędzi korporacyjnych. Pomimo ich elastyczności dalej rzadko kiedy idealnie spełniają stawiane przez nas wymagania, a w przypadku integracji czy dodania nowych funkcjonalności wciąż jesteśmy zdani na dobrą wolę ich producenta. Ponadto, przy dłużej trwającym projekcie i rosnącej liczbie utworzonych testów, cały framework testowy staje się coraz trudniejszy w utrzymaniu i pomimo atrakcyjnej ceny za licencję, z biegiem czasu wymagany jest coraz większy nakład pracy w utrzymanie testów, co może prowadzić do zawyżonego kosztu utrzymania całego narzędzia.
Największą zaletą budowy własnego narzędzia jest idealne dopasowanie do naszych potrzeb i wymagań. W tym wypadku nie musimy już iść na żadne ustępstwa niezależnie od tego, jaki typ aplikacji chcemy testować, na jakim poziomie oraz w jaki sposób ma wyglądać chociażby raport z testów.
Zakres integracji z innymi narzędziami czy dodanie nowych funkcjonalności zależy tylko od nas i można je określić w praktyce jako nieograniczone. Efektem ubocznym jest to, że w tym momencie framework testowy staje się tak bardzo dopasowany do testowanej aplikacji, że trudno go wykorzystać w innych projektach bez dokonywania zmian. Dodatkowo, bez zastosowania mechanizmów sztucznej inteligencji, podobnie jak w narzędziach korporacyjnych, nasze własne narzędzie może być mało odporne na zmiany w interfejsie użytkownika.
Tworzenie własnego narzędzia wiąże się z koniecznością posiadania zdolności programistycznych, co zależnie od zespołu może być wadą lub zaletą. Istotną wadą budowy własnego framework’a testowego jest również początkowy dłuższy czas tworzenia testów automatycznych. Ten stan często trwa do momentu osiągnięcia dojrzałości własnego narzędzia, a później w dłuższej perspektywie, czas tworzenia nowych testów automatycznych jest porównywalny z tym z narzędzi komercyjnych. Niewątpliwą zaletą jest brak opłat za licencję narzędzia do testów automatycznych, co pozwala zbilansować wymagany dodatkowy początkowy nakład pracy w jego rozwój. Warto również podkreślić, że dobrze zaprojektowany framework testowy jest najtańszy w utrzymaniu w kontekście rozrastającej się liczby zautomatyzowanych testów.
Czasami trafiają do nas klienci ze konkretną wizją tego, w jaki sposób chcą automatyzować testy. Tutaj zdarza nam się wskazywać ryzyka wybranego podejścia. Natomiast bardzo często zwracają się do nas klienci, którzy wiedzą, że muszą automatyzować testy ze względu na czas i budżet, ale nie mają pojęcia jak to zrobić. Bazując na kompetencjach naszych architektów oraz analityków testów jesteśmy w stanie ocenić obecny proces testowy, wskazać obszary do automatyzacji, a finalnie – zarekomendować optymalne narzędzia. Nie skupiamy się na jednej, preferowanej przez nas technologii, a dążymy do zarekomendowania wersji optymalnej.
Przykładem może być np. wykorzystanie Katalon Studio w projekcie dla jednego z największych polskich banków, który został wybrany ze względu na możliwość automatyzacji testów w metodyce BDD (Behaviour Driven Development). Dzięki temu, dalsze tworzenie nowych scenariuszy automatycznych możliwe było nawet dla osób nieposiadających specjalistycznej wiedzy programistycznej. Dodatkowo pożądanym atutem narzędzia było jednoczesne wsparcie testowania aplikacji webowych jak i mobilnych.
Zupełnie inne podejście zastosowaliśmy w projekcie dla Voestalpine, gdzie stworzyliśmy swój własny framework testowy. Podyktowane to było koniecznością zapewnienia komunikacji ze specjalistycznymi urządzeniami kolejowymi, a także umożliwieniem wykonywania zautomatyzowanych testów już na poziomie poszczególnych modułów systemu.
Jak widać, nie ma jednoznacznej odpowiedzi na pytanie, który framwork wybrać. Wszystko zależy od stawianych wymagań, testowanej aplikacji, umiejętności zespołu i zakładanego budżetu. W Solwicie mamy doświadczenie w pracy z każdym z opisanych powyżej typów narzędzi.
Każdego dnia przeprowadzamy tysiące testów automatycznych. Jesteśmy Platynowym Partnerem ISTQB i zatrudniamy 100 testerów certyfikowanych na poziomie Advanced i Foundation. Realizujemy testowanie aplikacji mobilnych, webowych oraz systemów.
