Problemy z automatyzacją testów Część I

Automatyzacja testów to temat bardzo aktualny i na czasie, zwłaszcza w środowiskach wykorzystujących dobrodziejstwa metodyk Agile czy DevOps.

Automatyka sprawdza się doskonale w wykonywaniu testów dymnych lub testów regresji. Okazuje się także pomocna w opracowywaniu danych testowych i wykonywaniu założeń testowych, w angażowaniu dużej ilości danych lub w przypadku danych znajdujących się na różnych platformach. Testy automatyczne mogą przynieść zespołowi wiele korzyści, ale tylko, gdy potrafi zarządzać nimi w sposób efektywny i skutecznie radzić sobie z typowymi wyzwaniami automatyzacji. Przy odpowiednim wykorzystaniu możliwości automatów można zwiększyć produktywność grupy i podnieść jakość produktów.

Jednak zanim zaczniemy automatyzować, przyjrzyjmy się najczęściej pojawiającym się problemom i wyzwaniom związanym z tym procesem.

Oczekiwania

Nierzadko zdarza się, że firma ma nierealistyczne oczekiwania wobec testów automatycznych. Skąd te błędne przeświadczenia wynikają, to temat na oddzielną dyskusję. Zdarza się, że oczekiwane jest zaprojektowanie automatów w ciągu paru tygodni dla produktu rozwijanego np. przez parę lat. Testy takie robione w pośpiechu z pewnością nie przyniosą przewidywanych rezultatów i tak szybko, jak się na nie zdecydowano, tak szybko się z nich zrezygnuje.

Priorytetem testowania automatycznego nie jest znajdowanie błędów, o czym wiele osób zapomina. W momencie, w którym pisane są skrypty, cały program został już poddany testom manualnym i najważniejsze błędy zostały wykryte. Automaty służą temu, by potwierdzić, że w kodzie nie nastąpił regres jakości i stanowią uzupełnienie testów manualnych. W sytuacji, w której proces testowy został błędnie określony, produkt jest jakościowo słaby, nie mamy dobrych praktyk programistycznych, żadne testy automatyczne nie zagwarantują polepszenia jakości kodu.

Ci, którzy chcą zautomatyzować 100% testów, muszą niestety obejść się smakiem. Nie jesteś w stanie zautomatyzować każdego pojedynczego przypadku testowego, zwłaszcza w obszarach takich jak kompatybilność czy interfejs użytkownika, gdzie większość testów przeprowadzanych jest manualnie.

Niektórzy twierdzą, że automatyzacja może być przeprowadzona tylko przez testerów manualnych lub jakichkolwiek innych technicznych testerów, ponieważ wiele narzędzi testowych już wspiera nagrywane skrypty testowe i odtwarza je łatwo i szybko. To mit. W rzeczywistości automatyzacja wymaga umiejętności technicznych niezbędnych do precyzyjnego zaprojektowania i utrzymania struktury automatyzacji, jak i scenariuszy testowych i umiejętności tworzenia odpowiednich rozwiązań. Zbudowanie automatu wymaga dużej wiedzy z zakresu projektowania i implementacji. By spełnić te wymagania, osoba podejmująca się wyzwania automatyzacji musi mieć solidne umiejętności programistyczne i rzetelne narzędzie do automatyzacji.

Z drugiej strony niektórzy uważają, że tylko programiści potrafią całkowicie zarządzać i przeprowadzać testy automatyczne. Ale w jaki sposób programiści mogą poprawnie pisać skrypty testowe z punktu widzenia testera, biorąc jednocześnie pod uwagę potrzeby użytkownika końcowego? Niezbędna jest tu wiedza i doświadczenie testerskie.

Koszty

Choć tendencja do automatyzacji testów jest bardzo popularna w przypadku zespołów korzystających z metodyk Agile czy DevOps, to jednak koszty związane z konfigurowaniem pakietu testów automatycznych uniemożliwiając wielu grupom skorzystanie z tej technologii w projektach. Początkowa faza automatyzacji jest zazwyczaj dość kosztowna.

Przed przedstawieniem automatów zespołowi zarządzającemu projektem, należy poddać analizie, zaprojektować i zbudować „szkielet” automatyzacji testów, w którym należy zawrzeć elementy takie jak chociażby biblioteki funkcji wielokrotnego użytku. Wziąć pod uwagę należy również koszty samego sprzętu i oprogramowania. Nie można pominąć kosztów licencjonowania i udostępniania, jeśli planuje się korzystanie z płatnego narzędzia.

Mimo iż na rynku dostępne są bezpłatne narzędzia typu open source, to jednak trzeba poświęcić dużo wysiłku na naukę, doskonalenie i utrzymanie ich. Pamiętajmy także o kosztach ukrytych. Chociaż po przeprowadzeniu kilku cykli testów regresji, następuje spory zwrot kosztów, to przekonanie interesariuszy, by zdecydowali się na taką inwestycję, jest dużym wyzwaniem. Dlatego wiele osób rezygnuje z automatów, ze względu na ograniczenia budżetowe, nawet jeśli zgadzają się z wykonalnym celem i wysokim ROI.

Nie zapominajmy, że napisanie skryptów automatycznych zajmuje o wiele więcej czasu, niż napisanie testów manualnych. Uruchomienie testów manualnych często może zabrać tyle samo czasu, co automatycznych. Utrzymanie automatów jest natomiast ok. 20 razy droższe od utrzymania testów manualnych. Zdarza się, że organizacje decydujące się na automaty, zatrudniają dodatkowych testerów automatycznych, którzy będą przez jakiś czas pracować ramię w ramię z testerami manualnymi.

Odpowiednie narzędzie

Wybór odpowiedniego narzędzia do automatyzacji testów to kolejne wyzwanie. Według Bogusława Osucha w kontekście narzędzi i zespołów mogą pojawić się problemy z następującymi kwestiami:

• Zespołowi brakuje fachowej wiedzy, by w jak najefektywniejszy sposób wykorzystać dostępne narzędzie
• Zespół nie wie, czy narzędzie, którego potrzebuje/wymaga istnieje w rzeczywistości
• Chcą/potrzebują narzędzia, które w danym momencie nie jest dostępne na rynku
• Wybrane przez zespół narzędzie nie oferuje 100% pokrycia testowego na wymaganych obszarach
• Koszt narzędzia przekracza budżet

Jak podkreśla Osuch, problem jest poważny. Powołując się na dane statystyczne z World Quality Report 2014-2015, ponad 50% liderów branży IT przyznaje, że brak im odpowiednich narzędzi do automatyzacji podczas opracowywania środowisk testowych dla swoich zespołów.

Na rynku dostępnych jest wiele narzędzi do testowania, od darmowych, w typie open source takich jak Selenium i Katalon Studio, po płatne, jak SauceLabs czy TestComplete, które obsługują różne typy testowania i technologie. Każde narzędzie wspiera określone sytuacje. Sprzedawcy często opowiadają, że posiadają narzędzie uniwersalne, do wszystkich typów testów. Wywołuje to błędne koncepcje i zamieszanie, w efekcie ciężej jest wybrać odpowiednie dla nas narzędzie. Ponadto wiele z nas nie wykonuje odpowiednio rzetelnego researchu przed podjęciem decyzji o wyborze narzędzia, zwykle skupiając się na tych, które w danym momencie są najbardziej popularne. Decyzja podejmowana jest szybko i na podstawie niewystarczającej oceny. Firmy, zamiast wdrażać rozwiązania adekwatne do potrzeb, decydują się na narzędzia popularne, modne, dobrze rozreklamowane, jednocześnie (teoretycznie) łatwe w obsłudze; co często wiąże się z drogim wsparciem komercyjnym i niespełnieniem faktycznych wymagań.

Nie należy zapominać o tym, że dostateczna ocena obejmuje zdefiniowanie zestawu kryteriów wymagań dotyczących narzędzi na podstawie AUT i doświadczeń ekspertów, którzy już mieli do czynienia z danym narzędziem. Niestety spełnienie tego wymogu często nie jest możliwe. Bez względu na to, jakie rodzaje procesów i metodologii testowych wykorzystujemy, jeśli narzędzie nie będzie spełniało naszych wymagań technicznych i biznesowych, zrezygnujemy z niego. Ostatecznie automatyzacja zakończy się niepowodzeniem i nie będzie już stosowana w zespole lub ponowna implementacja testów automatycznych będzie utrudniona, przez poprzednie niepowodzenie.

Oczywiście problemy, jakie można napotkać przy automatyzacji testów, nie stanowią zbioru zamkniętego. Cały czas pojawiają się nowe wyzwania i trudności, co ściśle związane jest z ciągłym rozwojem technologii. Jeśli jesteście ciekawi, jakie inne problemy można napotkać w procesie automatyzacji testów, to zapraszamy do drugiej części wpisu już za tydzień. 🙂