Dlaczego powinniśmy zacząć myśleć inaczej o testowaniu oprogramowania?

Funkcjonując w branży testowania oprogramowania i szerzej w IT, nietrudno natknąć się na licznie występujące rozważania na temat przyszłości testowania; czy to manualnego, czy zautomatyzowanego, czy to przyszłości pod znakiem sztucznej inteligencji, czy też machine learningu. Mnogość tekstów na ten temat jest naprawdę oszałamiająca.

My zaczęliśmy zastanawiać się, co jest przyczyną ilości tego typu publikacji. Jakie czynniki wpływają na to, że temat przyszłości testowania jest tak chętnie poruszany. W tym poście postaramy się odpowiedzieć na to pytanie i choć pewnie nie uda nam się wyczerpać całej tematyki związanej z przyszłością testowania, to jednak temat wart jest podjęcia próby opisu, bo o testowaniu oprogramowania powinniśmy zacząć myśleć inaczej już w tym momencie.

Na dynamikę zmieniającego się krajobrazu projektowania, tworzenia i utrzymania oprogramowania nie wpływa jeden czynnik, np. postęp technologiczny. Źródła tak energicznych zmian należy doszukiwać się na wielu, różnorodnych płaszczyznach. Wziąć pod uwagę należy, chociażby:

• Rewolucję cyfrową

W świecie biznesu technologie cyfrowe często zmieniają sposób funkcjonowania przedsiębiorstwa, jak czytamy w artykule The Digital Revolution is not about technology – it’s about people. Organizacje wiedzą, że jeśli mają pozostać na rynku, muszą poddać się digitalizacji. Firma BCG przeanalizowała, w jaki sposób firmy odnoszące sukcesy zmieniły swoje modele biznesowe i operacyjne, gdy przechodziły na technologię cyfrową. Wszystkie mają dwie charakterystyczne cechy: tworzą produkty i usługi, które są wbudowane w technologie cyfrowe, i wykorzystują kanały cyfrowe do interakcji z docelowymi odbiorcami i klientami. Wszystko to sprawia, iż globalny rynek wymaga zwiększenia zarówno ilości wypuszczanych produktów, jak i szybkości ich wydawania.

• Rosnącą popularność Agile i DevOps

Tendencje w branży QA i testowania oprogramowania powiązane są ściśle z innymi przemianami w obszarze IT. Pojawiające się nowe skłonności na rynku sugerują, że obecne rozwiązanie testowe nie są wystarczające dla zmieniających się dynamicznie potrzeb, które powiększyły się w ostatnich latach, chociażby o konieczność wykonywania testów na urządzeniach mobilnych, testów opartych na tłumie (crowd testing) czy tych zautomatyzowanych. Nowe, adaptujące się trendy w testowaniu wymagają świeżych metod. W odpowiedzi na to zapotrzebowanie pojawiły się Agile i DevOps.

W najogólniejszym rozumowaniu te procesy, jak pisze Jason Arbon, nazywane także metodykami, skupiają się na stałej współpracy między zespołami (programistycznymi, testerskimi, biznesowymi, etc.) w trakcie całego cyklu życia projektu. Podkreślają konieczność komunikacji, współpracy i integracji między grupami oraz ciągłe dostarczanie wyników pracy. W praktyce dla testerów oznacza to, iż nie poddają oni aplikacji czy strony internetowej analizie, gdy produkt jest ostatecznie skończony przez zespół programistów, a testują go cały czas, przez cały cykl tworzenia, aż do ostatecznego wypuszczenia produktu na rynek. Nacisk na Continuous Integration (Nieustanna Integracja), Continuous Delivery (Nieustanna Dostawa), Continuous Testing (Nieustanne Testowanie) oraz na Continuous Monitoring (Nieustanne Monitorowanie) prowadzi do konieczności przedefiniowania sposobu pracy testerów. Koniecznością stała się implementacja nowych metod, które w sposób skuteczny i efektywny dopełniałyby procesy spod znaku Continuous.

Metodyki te decentralizują sposób testowania oprogramowania i proponują zastosowanie mniejszych jednostek (grup) do przeprowadzenia całości procesu. Takie rozwiązanie oferuje większą swobodę poszczególnym zespołom w wyborze najskuteczniejszych metod, technik rozwoju oraz w podejściu do kontroli jakości i analizy oprogramowania. Opierając się na danych zebranych w World Quality Report 2017-18, popularność Agile i DevOps zwiększa się, ponieważ uznawane są przez zespoły programistyczne za ważne czynniki utrzymujące tempo równe cyfrowej transformacji. Jednocześnie w Raporcie czytamy, że nie zostały one jeszcze zaadaptowane przez kluczowych graczy na rynku.

• Coraz częstsze wykorzystywanie możliwości chmury

Technologia Cloud Computing (nazywana potocznie chmurą) zmieniła sposób, w jaki aplikacje czy systemy operacyjne są obecnie monitorowane, rozwijane i wykorzystywane. Powodem jej rosnącej popularności jest możliwość zapewnienia przystępnych zasobów dla użytkowników i programistów w następujących formach:

• Moc obliczeniowa (Computing Power)
• Przechowywanie (Storage)
• Zasoby krytyczne (Critical Resources)

Cloud computing odnosi się do dostarczania zasobów komputerowych jako usługi. Termin ten ogólnie nawiązuje do trójwarstwowego modelu obliczeniowego lub stosu chmur, który obejmuje SaaS (Software As A Service; Oprogramowanie jako Usługa), PaaS (Platform As A Service; Platforma jako Usługa) i IaaS (Infrastructure As A Service; Infrastruktura jako Usługa), który można uzyskać z odmiany dostawców rozwiązań w chmurze lub hostowane wewnętrznie za pośrednictwem chmury prywatnej. Przetwarzanie w chmurze może również obejmować dostarczanie innych rodzajów zasobów IT jako usługi; w tym: przechowywanie jako usługa, bazy danych jako usługa, bezpieczeństwo jako usługa i backend jako usługa.

Operowanie danymi w chmurze powoli staje się przyczółkiem w głównych sektorach usług IT na całym świecie ze względu na swoją niezależność lokalizacyjną, elastyczność i dynamiczny charakter.

• Zwiększające się różnorodności i ilości urządzeń oraz przeglądarek internetowych

W obecnym krajobrazie technologicznym praktycznie każda strona internetowa ma swój mobilny odpowiednik. Ponieważ aplikacja testowana na platformie internetowej może nie działać poprawnie w wersji mobilnej, zaistniała potrzeba wytworzenia specjalistycznego rodzaju testowania dostosowanego do aplikacji mobilnych.

Przed wypuszczeniem projektu na rynek, zespół musi sprawdzić zgodność aplikacji mobilnych na smartfonach i tabletach działających na różnych systemach operacyjnych. Proces komplikuje różnorodność i wielość scenariuszy do prześledzenia.

Jaki ma to wpływ na testowanie oprogramowania?

Podczas gdy inżynieria oprogramowania i jego infrastruktura stały się znacznie łatwiejsze i skalowane dzięki ulepszeniom w językach programowania, narzędziach, procesach i przetwarzaniu danych w chmurze, o tyle testowanie oprogramowania nie odnotowało podobnego wzrostu w zakresie swojej wydajności, efektywności i skuteczności. Testowanie oprogramowania wciąż wymaga uwagi i przełomowych rozwiązań technicznych.

Struktury testowania interfejsu użytkownika (User Interface, UI) Selenium, Appium i Webdriver, stworzone zostały w 2004 roku. Większość opatentowanych systemów testowych takich, jak TestPlant czy HP UFT dostępne są w branży równie długo, o ile nie dłużej. Co więcej, nawet najnowsze produkty, jak platforma testowa Espresso lub Square KIF, wyglądają i funkcjonują w strukturach bardzo podobnych do poprzedników stworzonych na początku XXI wieku. Od ponad 10 lat znane paradygmaty automatyzacji testów wykorzystujące identyfikację obrazu, nagrywanie i odtwarzanie czy manualne kodowanie selektorów, często oparte na DOM czy identyfikatorach dostępności (accessibility identifiers) zostały poprawione tylko w niewielkim stopniu i przeniesione na bardziej nowoczesne platformy – twierdzi wspomniany wcześniej Jason Arbon. 

Główny problem leży zatem w ogromnej (i wciąż zwiększającej się) ilości danych, które testerzy muszą obsługiwać w ograniczonym czasie. Samo to sprawia, że tradycyjne metody testerskie (testy manualne i manualne tworzenie zautomatyzowanych skryptów testowych) przestają być wystarczające. Zmiana podejścia staje się absolutną koniecznością.

Poza tym istnieje zasadnicza rozbieżność między inżynierią oprogramowania a testowaniem. Napisanie prostej funkcji albo dodatku do produktu, wymaga dużej ilości testów weryfikujących poprawności. W wysoko-jakościowych aplikacjach więcej czasu inżynierskiego przeznaczane jest na testowanie zamiast na implementację. Potrzebne są także dodatkowe testy i  walidacja, ponieważ nowa funkcja może wpływać na zachowanie innych, starych funkcji.

W związku z tym wysiłek, który należy podjąć, by przetestować każdą nową funkcję, obejmuje testy wymagane do wyeliminowania ryzyka dla wszystkich zagrożonych funkcji. Sprawia to, że trud przeanalizowania całej sieci rośnie wykładniczo. Większość obecnie wykorzystywanych metod testowania dodaje więcej metod manualnych lub ręcznego tworzenia kodu dla większej liczby skryptów regresji. Zwiększa to jedynie wskaźnik liniowo proporcjonalny do wysiłku/kosztu testów. Nawet testy oparte na danych dostarczają liniowo odsetek pokrycia testowego.

Oznacza to, że każdy produkt programowy „traci” przez powiększającą się lukę między kompleksowością wymagającą przetestowania a zdolnością do zapewnienia pokrycia testowego. Coś musi ulec zmianie, by umożliwić wygenerowanie lepszego (skuteczniejszego) pokrycia testowego.

Zależność pokrycia testowego od czasu oraz sposób tworzenia się luki testowej.
Linia niebieska oznacza funkcje, linia zielona zaś testy.
Kompleksowość testów wzrasta wykładniczo wraz z pojawianiem się nowych funkcji. Pokrycie testowe rośnie liniowo, ponieważ testy mogą być dodawane tylko pojedynczo.

Źródło: J. Arbon, AI for Software Testing, 2017, s. 4.

Dlaczego należy podjąć odpowiednie działania?

Obecnie użytkownicy końcowi wykazują się o wiele niższą tolerancją na błędy w produktach im dostarczonych. Jednocześnie zwiększają swoje wymagania co do ich jakości. Ponadto sami oczekują dostarczenia gotowego produktu w czasie krótszym niż kiedykolwiek wcześniej.

W ciągu ostatnich kilku lat organizacje zdały sobie sprawę, że aby pozostać konkurencyjne na rynku, ich zespoły zajmujące się tworzeniem oprogramowania dla przedsiębiorstw będą musiały dostarczyć oprogramowanie do modernizacji starszych systemów, zwiększyć wydajność operacyjną i zaangażować klientów w innowacyjne rozwiązania. Ponieważ popyt na aplikacje przewiduje trzykrotny wzrost od 2018 do 2020 r., trudno wyobrazić sobie, w jaki sposób firmy zdołają dotrzymać kroku konsumentom.

Zapotrzebowanie na programistów jest zatem bardzo wysokie. W skali ekonomii globalnej brakuje wykwalifikowanych developerów, a sytuacja będzie się pogłębiała w ciągu najbliższych lat. Tak duże zapotrzebowanie, oznacza, że w niedalekiej przyszłości będziemy wytwarzali jeszcze więcej kodu, który wymagać będzie przeanalizowania.

Trudność polega na tym, że choć niewiele zmian dokonano w dziedzinie testowania oprogramowania, to świat inżynierii oprogramowania bardzo przyspieszył dzięki narzędziom i procesom, o których pisaliśmy.

Zmiana sposobu myślenia, a co za tym idzie i podejścia do testowania oprogramowania, nie jest sugestią; jest absolutną koniecznością, jeśli chcemy utrzymać obecne tempo rozwoju technologii lub zwiększyć je w przyszłości. Wydaje się, jakby branża testerska zapadła w technologiczną hibernację. Najwyższy czas ją wybudzić i wyposażyć w narzędzia odpowiednie i gotowe sprostać pędzącemu rozwojowi programowania i technologii w ogóle.