Wyzwania automatyzacji testowania
Wrażliwość testów
Część I

Zapotrzebowanie na oprogramowanie rośnie z roku na rok. Kolejne wersje przeglądarek internetowych, aplikacji, systemów operacyjnych pojawiają się na rynku w każdym miesiącu. Do tego doliczmy jeszcze aktualizacje systemów… W efekcie mamy sytuację, w której ilość danych rośnie niemalże lawinowo i nie widać żadnego przewidywalnego końca. Testowanie należy przyspieszyć. Pojawia się więc potrzeba, by zwiększyć automatyzację procesu testowania stron internetowych i aplikacji webowych.

Z roku na rok coraz więcej firm i producentów decyduje się na umieszczenie swoich ofert w chmurze. Coraz częściej korzystamy z narzędzi w technologii SaaS, bo są dostępne, wygodne i nie wymagają instalowania dodatkowych oprogramowań. Ponadto są na bieżąco aktualizowane przez producentów.

I właśnie tu pojawia się wyzwanie dla automatyzacji testowania. Zespoły działające w myśl Continuous Development, posługujące się metodykami Agile czy DevOps wypuszczają nowe releasy, czy update’y w bardzo szybkim tempie. Problem polega na tym, że testuje się tylko update czy releas, a nie całość, więc ryzyko wystąpienia błędu jest duże.

Zespoły decydują się więc albo na modyfikowanie istniejących testów automatycznych, by dostosować je do nowych wymagań, albo na tworzenie nowych. Oba te rozwiązania wymagają dużego nakładu czasu i energii.

Analiza raportu

Zapytani o główne przeszkody, jakie stają przed osiągnięciem pożądanego poziomu automatyzacji, 61% respondentów WQR 2018 przyznało, że mają problem ze wdrożeniem automatyzacji, ponieważ ich aplikacje za bardzo się zmieniają w kolejnych wersjach. Prowadzi to do konieczności wprowadzenia licznych modyfikacji przy okazji kolejnego wydania, ponieważ ustalone przypadki testowe czy rozpisany wcześniej test automatyczny nie są już aktualne.

Co więcej, wrażliwość większości dostępnych narzędzi do automatyzacji sprawia, że utrzymanie testów znacznie zwiększa koszty projektowe.

Przyczyna wrażliwości testów automatycznych

Najogólniej rzecz ujmując, utrzymanie testów automatycznych polega na dostosowaniu skryptu testu do zmian, jakie nastąpiły w aplikacji. W wielu przypadkach polega to na podaniu nowych identyfikatorów elementów w skrypcie automatycznym, które uległy zmianie na skutek modyfikacji w UI testowanego systemu (System Under Testing; SUT). Przyczyną tych zmian mogą być na przykład dynamiczne treści na stronie takie jak przyciski CTA, pop-upy czy reklamy, ale także modyfikacji w samej aplikacji w ramach jej nowej wersji.

Problem polega na tym, iż wiele starych frameworków testów automatycznych jest niezwykle sztywna i spolaryzowana w tym sensie, iż każda zmiana w strukturze UI skutkuje negatywnym wynikiem testu. Tester automatyczny, który jest odpowiedzialny za utrzymanie, musi zidentyfikować, co jest powodem negatywnego wyniku testu: czy błąd w aplikacji, czy po prostu błąd w skrypcie testującym, który nie może zidentyfikować odpowiedniego elementu (selektora).

Jedynym rozwiązanie tego problemu jest manualne sprawdzenie wszystkich testów oraz kroków testowych tak, aby odpowiednio zdiagnozować czy problem dotyczy skryptu testowego, czy może testowanej aplikacji. Sposób ten jednak nie dość, że długotrwały, to kosztowny i obarczony wysokim poziomem popełnienia błędu (przeoczenie) przez testera manualnego.

Podsumowanie

Z problemem wrażliwości testów automatycznych można sobie jednak poradzić. Skomplikowany i czasochłonny proces tworzenia wystarczy usprawnić tak, by zajmował jak najmniej czasu. Jesteście ciekawi, w jaki sposób można to zrobić? Dowiecie się tego w części II tego wpisu już za tydzień. Do przeczytania!