Jestem testerem. Jak AI nie zabrało mi pracy?
W dzisiejszym dynamicznym środowisku oprogramowania testerzy tak manualni, jak i automatyzujący odgrywają kluczową rolę w zapewnianiu jakości produktów. Jednak złożoność aplikacji i szybkie tempo wytwarzania oprogramowania stawiają przed nimi nowe wyzwania. W takim kontekście sztuczna inteligencja (SI/AI) staje się nieocenionym narzędziem, które może pomóc testerom w efektywnym i skutecznym wykonywaniu ich obowiązków. W tym artykule chciałbym zaprezentować, w jaki sposób tester może wspomóc się takimi narzędziami i dlaczego to dalej będą tylko narzędzia i nie zastąpią człowieka. Przynajmniej przez jakiś czas. Przyjrzymy się również jak technologia C# i xUnit zintegrowana ze SpecFlow, BDD i Azure DevOps może wspierać testerów automatyzujących, a także jak SI może przyczynić się do optymalizacji procesu testowania.
Zintegrujmy się!
C# xUnit jest popularnym frameworkiem do testowania jednostkowego w języku C#. Może być skutecznie wykorzystywany w procesie automatyzacji testów, szczególnie w połączeniu z narzędziami takimi jak SpecFlow i podejściem BDD (Behavior-Driven Development). SpecFlow umożliwia pisanie testów w języku naturalnym, co ułatwia zrozumienie wymagań i scenariuszy testowych przez wszystkie zainteresowane strony, nie tylko “techniczne”, ale i mniej technicznych Business Analityków czy też Product Ownerów. Integracja tych narzędzi pozwala testerom manualnym i automatyzującym na tworzenie czytelnych i zwięzłych testów, które odzwierciedlają zachowanie aplikacji. Przyjrzyjmy się takiej sytuacji: jesteśmy początkującymi testerami, mamy pewne kryteria akceptacji dla funkcjonalności i chcemy ją przetestować. Udało nam się sprawdzić manualnie działanie systemu, wszystko wydaje się okej, ale musimy napisać test, używając składni Gherkin, który to testerzy automatyzujący będą wykorzystywać później jako bazę dla ich implementacji. I tu pojawia się problem, ponieważ nie znamy tej składni, ale hej! A jakby tak ułożyć promptu… Od początku:
Nasze {Kryteria Akceptacji} to:
Endpoint POST tworzy tablicę o podanej nazwie.
Pole “nazwa” może mieć od 1 do 100 znaków.
Piszemy zatem prompt:
Stwórz testy graniczne (a co!) z użyciem BDD i składni Gherkin na podstawie podanych kryteriów akceptacji:
{Kryteria Akceptacji}
Po chwili testy są wyplute przez openAI i wyglądają nawet dobrze. Przykładowo:
“Scenario: Create a new board with a name of 1 character
Given the API is available
When a POST request is made to “/boards” with the following data:
| name | login |
| key | {{apiKey}} |
| token | {{token}} |
Then the response status code should be 200 OK ”
OpenAI wzięła pod uwagę graniczne wartości – 0, 1, 100, 100+, wygląda dobrze. Jednak dla wartości poza klasą równoważności poprawnych wynik testu był ten sam – 200 OK, a powinien być 400 Bad Request. I tu pojawia się problem, AI popełniło błąd, który oczywiście łatwo naprawić, jeśli jest się osobą z pewnym doświadczeniem, nawet jako początkujący testerzy. Niestety na tym przykładzie dostrzegamy, że dalej potrzebujemy pewnej wiedzy domenowej. Widać jednak, że podając odpowiednie informacje, możemy uzyskać poprawny wynik — np. dzięki podaniu przykładów granic, dla jakich potrzebujemy wygenerować scenariusze sprecyzowanie tego, że testy dla klas równoważności mają być zebrane w jeden scenariusz. Poprawne „nakarmienie” AI jest w stanie dać dużo bardziej wymierne rezultaty, jednak dalej jest ryzyko, że zostaniemy opacznie zrozumiani. Przez to możemy dołożyć czasu review innym osobom w zespole lub po prostu sobie.
Tabula rasa — a gdy pomysłów na scenariusze brak?
Idąc dalej, czy osoba totalnie świeża jest w stanie wspomóc się SI, aby rozpocząć pracę jako tester, choćby na stanowisku stażowym? Myślę, że jak najbardziej. Jednak jako senior dla takiej osoby musimy pamiętać, że stażysta ten może popełnić dużą ilości błędów nie tylko przez brak doświadczenia, ale i przez zaufanie pokładane w AI i niewspółmiernie rosnącą pewność siebie. Załóżmy, że stażysta wie już conieco o testowaniu, zerknął choćby w ISTQB i zna różnicę między testami regresji, retestami czy testami akceptacyjnymi. Dostaje w końcu zadanie, które sprawia jej trudność — ma do przetestowania endpoint, a nigdy nie wykonywała testów API. Zadajmy więc najprostsze pytanie SI — jak przetestować endpoint? Dostaniemy tak naprawdę sporo teoretycznej odpowiedzi, ale zero konkretów. Możemy jednak dążyć do szczegółów już na podstawie wiedzy zebranej w poprzednim zapytaniu. AI podpowiada, aby przygotować dane wejściowe, dane wyjściowe, dane graniczne i czy rezultaty odpowiedzi zgadzają się z implementacją. Dopytajmy zatem — jakie rezultaty odpowiedzi może zwrócić endpoint API. Dowiemy się o kodach statusów, formacie JSON, o parsowaniu i podstawowych testach, które możemy napisać już w Postmanie. Wydawałoby się, że całą tę wiedzę możemy odszukać za pomocą wyszukiwarki, jednak nigdy nie będzie to tak płynne, jak w przypadku AI. Dopytywanie o poprzedni kontekst pytań, które to AI zapamiętuje, też jest niezwykle użyteczne – zamiast wyszukiwać odpowiedzi dla generycznych danych, nasze dane — już podane w poprzednich promptach, pozostają w pamięci danej rozmowy i możemy je przywoływać, generując testy oparte o te właśnie dane. Skraca to czas tworzenia tych testów tylko na podstawie zdobytej wiedzy, ponieważ możemy uzyskać już gotowe skrypty, które o wiele łatwiej zrozumieć i — w razie potrzeby — dopracować. Jesteśmy w stanie podać kryteria akceptacji i poprosić o wygenerowanie testów względem odpowiedzi negatywnych i pozytywnych. Możemy nawet wkleić nasze kryteria akceptacji, aby SI prześledziło warunki i dokonało przeglądu wymagań. Jako stażysta bądź junior możemy mieć niesamowite wsparcie w AI. Pomimo tego warto zasięgnąć przeglądu seniora, od czasu do czasu. A jak już jesteśmy na przeglądzie — to co z przeglądem testów i kodu?
Bez przeglądu pani nie pojedzie!
SI może być wykorzystana do przeprowadzania tak analizy statycznej kodu, jak i wspomnianych już testów BDD. Dzięki temu możliwe jest wykrywanie potencjalnych problemów i błędów, a także identyfikowanie nieprawidłowych wzorców lub nieoptymalnych rozwiązań. SI może automatycznie sprawdzać poprawność składni testów i kodu, co przyspiesza proces przeglądu i minimalizuje ryzyko ludzkich błędów, choć nie minimalizuje ryzyka, że samo SI popełni jakieś błedy. Programy, których już teraz używamy do pisania kodu posiadają przecież statyczną analizę kodu, która to jest właśnie niczym innym, jak SI. Gdy poprawiamy kilka podobnych wartości z rzędu, już na trzeciej podobnej wartości pojawi nam się podpowiedź: “Naciśnij Tab, aby zaakceptować zmiany”. Gdy chcemy stworzyć warunek “if” wystarczy, że dwa razy wciśniemy Tab, aby ukazała się cała część kodu. Żółte podkreślenia dla “warningów” czy czerwone dla “errorów” to już standard, podpowiedzi możliwych rozwiązań — również. Wklejanie scenariuszy napisanych z użyciem Gherkina i korespondującego z nim kodu implementacji jest jak najbardziej możliwe, synchronizacja integracji narzędzi takich jak Specflow i xUnit jest jak najbardziej sprawdzalna, a to, czego my nie dostrzeżemy — może dostrzec i podpowiedzieć, co jest nie tak. Co, jednak gdy podpowiedź ta mogła być dobra względem składni, jednak nasz kod dalej nie działa?
My name is Optimus Prime!
Czy jesteśmy w stanie wkleić cały nasz kod w OpenAI? Raczej tak, choć zależy od tego jak bezpiecznie czujemy się z takim narzędziem i jak wrażliwe dane udostępniamy. Pamiętajmy jednak, że niektóre z danych możemy anonimizować, choć wiadomo — składnia naszego kodu lub pewne wzorce mogą gdzieś się zawieruszyć. SI może nam podać zmieniony kod, opisać które rzeczy zostały usunięte i dlaczego, zaproponować inne metody, refaktorować kod. Może to być nie tylko wspaniałe narzędzie do optymalizacji naszego kodu, ale i do nauki dla inżynierów na naprawdę najróżniejszych poziomach kwalifikacji. Jak wiemy jednak nie każdy lubi się uczyć algorytmów czy składni na pamięć, a i tutaj AI przychodzi z pomocą. Jako programujący testerzy jesteśmy w stanie zapytać sztuczną inteligencję o drobnostki, które mogą nam pomóc usprawnić proces wytwarzania scenariuszy testowych. Nie musimy się posiłkować Google lub Stack Overflow, wyszukiwać optymalnych rozwiązań bądź przeklikać kilku stron w poszukiwaniu odpowiadającej nam metody. Nie pamiętasz jak opóźnić wykonanie zadania? Promptuj. Potrzebujesz kodu porządkującego dane od najmniejszego do największego? Promptuj. Co oznacza, że klasa dziedzicząca jest zapieczętowana? Na wszystkie te pytania SI odpowie szybko i na podstawie danych, które posiada, odfiltrowując wymarłe wątki lub słabe odpowiedzi użytkowników o różnej wiedzy.
Gorzej, gdy informacja, którą dostaniemy okaże się niskiej jakości. Tutaj jak widać musimy albo zaufać SI, albo ciągle sprawdzać, regenerować odpowiedzi, dopytywać ze szczegółami, gnębić małego bocika ile tylko możemy. Inaczej AI może dokonać szkód, pomimo najszczerszych chęci pomocy. W każdym z wymienionych przypadków używamy tego narzędzia dość instrumentalnie, spróbujmy jednak innego podejścia.
Deus ex machina
Testowanie wymaga kreatywnego myślenia i identyfikacji różnych przypadków testowych. AI może wspomagać testerów oferując podpowiedzi dotyczące scenariuszy testów. Na podstawie wcześniej wykonanych testów i analizy aplikacji, SI może sugerować dodatkowe testy, które mogą być istotne dla pokrycia większej liczby przypadków użycia.
AI może być trenowana na podstawie istniejących danych testowych, aby nauczyć się wzorców i reguł związanych z testowaniem danej aplikacji. Na podstawie tego treningu, wyciskającego siódme poty, SI może generować nowe scenariusze testowe, które są zgodne z oczekiwanym zachowaniem aplikacji. Dodatkowo AI może przeglądać dokumentację, wymagania funkcjonalne i inne źródła informacji o aplikacji, aby zrozumieć jej funkcjonalności. Na podstawie tych informacji, AI może generować scenariusze testowe, które obejmują różne przypadki użycia i testują różne funkcje aplikacji, a więc nie tylko te funkcjonalne, ale i skupione na bezpieczeństwie czy wydajności. AI może również współpracować z ludzkimi testerami, aby zbierać informacje na temat aplikacji i scenariuszy testowych. Na podstawie tego współdziałania, AI może uczyć się preferencji testerów i dostosowywać generowane scenariusze testowe do ich potrzeb. Jeśli zaś damy AI dostęp do danych dotyczących interakcji użytkowników z aplikacją (np. dzienniki zdarzeń, dane analityczne), może analizować te dane i wyciągać wnioski na temat częstości, typów i sekwencji interakcji. Na tej podstawie AI może generować scenariusze testowe, które odzwierciedlają rzeczywiste wzorce interakcji użytkowników. A co z UI?
Oczy szeroko zamknięte
Póki co AI są w stanie generować obrazy, jednak nie jest łatwo znaleźć odpowiedni program do analizy dostarczonych obrazów. Istnieją przesłanki, że GPT-4 będzie umiał opisać obraz, lecz na razie dostarczanie filmików aplikacji, części UI (jak przyciski, tabele) nie weryfikuje jakości, przydatności i tego, że użyte elementy UI odpowiadają wymaganym odczuciom użytkowników. Cała sfera User Experience pozostaje poza zasięgiem testów, które to na razie muszą być wykonywane przez ludzi. Haptyczne oddziaływanie na odczucia użytkownika, dynamika pionowego scrollowania/poziomego przesuwania ekranu lub ich zmiany, animacje przycisków czy też określenie całości brandingu jako spójnego. AI jest nam w stanie odpowiedzieć na pytanie względem interpretacji danych kolorów, zaokrąglania rogów przycisków czy też ilości haptycznych feedbacków, jednak nie zmierzy nam holistycznego odbioru danej aplikacji.
AI/CI/CD
Przejdźmy do pomocy około testowych. Azure Pipelines to platforma do ciągłej integracji i dostarczania oprogramowania stworzona przez Microsoft. SI może być wykorzystana do automatyzacji procesu wdrażania testów w Azure Pipelines. Może to obejmować generowanie raportów z wynikami testów, monitorowanie postępu testów, a nawet automatyczne wykonywanie czynności naprawczych w przypadku błędów. Co więcej, platforma Azure oferuje własne zaawansowane możliwości w zakresie uczenia maszynowego i uczenia głębokiego. Szybkie i łatwe tworzenie, trenowanie i wdrażanie modeli uczenia maszynowego jest możliwe dzięki korzystaniu z usług Azure Machine Learning i Azure Databricks. Na platformie Azure można korzystać z popularnych narzędzi, takich jak Jupyter i Visual Studio Code, oraz z frameworków, takich jak PyTorch, TensorFlow i Scikit-Learn. Jesteśmy również w stanie tworzyć modele danych szybciej dzięki narzędziom tak o niskim kodowaniu, jak i bez kodu, takim jak automatyczne uczenie maszynowe i interfejs drag-and-drop. Platforma Azure zapewnia łatwą integrację tych narzędzi, umożliwiając skoncentrowanie się na tworzeniu zaawansowanych modeli bez konieczności głębokiego zrozumienia kodu. Osoby z małą ilością doświadczenia w kodowaniu mogą wykorzystać wszystkie te funkcjonalności i struktury do wdrożenia się w środowiska chmurowe, choć dalej jest wymagana pewna znajomość domeny i sposobów wykorzystania CI/CD w procesie testowania. Idąc dalej, SI może również wspierać testerów automatyzujących w przeprowadzaniu testów wydajnościowych, także w chmurze z użyciem narzędzia Blazemeter. Dzięki analizie wielu czynników, takich jak obciążenie systemu, zużycie zasobów czy czasy odpowiedzi, SI może automatycznie generować raporty i identyfikować potencjalne słabe punkty, które mogą wymagać optymalizacji.
Open AI czy Open Pandora Box?
Sztuczna inteligencja stanowi niezwykle potężne narzędzie dla testerów tak manualnych, jak i automatyzujących. Jej wykorzystanie w kreacji scenariuszy manualnych lub też nawet w połączeniu z technologią xUnit zintegrowaną ze SpecFlow i BDD może znacząco przyspieszyć i usprawnić proces testowania. Dzięki SI testerzy automatyzujący mogą skoncentrować się na kluczowych aspektach testów, podczas gdy część rutynowych zadań jest wykonywana automatycznie. W rezultacie można osiągnąć wyższą jakość testów, skrócić czas wytwarzania oprogramowania i zwiększyć efektywność pracy zespołu testującego. Brzmi to naprawdę dobrze i przyszłościowo, jednak jak zwykle nowe rozwiązania — przedstawiają sobą nowe ryzyka. Kierownicy zespołów mogą próbować optymalizować koszty poprzez cięcie ilości pracowników, skoro pomaga im SI. Zatrudnianie tzw. Prompterów, którzy to mają mieć umiejętność korzystania z SI nie zawsze będzie się wiązała z ich pełnym zrozumieniem danej dziedziny IT a co za tym idzie – jakość dostarczanego oprogramowania może zmaleć. Wtedy to mogą powstać prompterzy — specjaliści, z większą wiedzą domenową, którymi to pracodawcy mogą zechcieć zastąpić zespoły złożone z ludzi. Czy to nastąpi? Czy po prostu znowu rynek powiększy się o nowych specjalistów, projekty będą większe i jeszcze bardziej skomplikowane, a testerzy, programiści i inne role pozostaną na miejscu, tylko pracując ze wsparciem SI będą mogli pracować wydajniej? Na razie SI nie zabrało mi pracy i jeszcze długi czas nie zabierze — jednak każdy musi pamiętać, że IT to dziedzina, gdzie trzeba nadążać za technologiami, ponieważ prędzej czy później te technologie nas dogonią. Gdy będą gryźć nasz ogon, to może być już za późno.
