Od developmentu do regresji: jak podnieść wartość testów dzięki AI

Testowanie aplikacji chmurowych bywa bardziej czasochłonne niż sama implementacja, a wartość solidnych testów jest nieoceniona. W fazie budowania rozwiązań powstaje wiele zasobów cennych dla testów, które często giną, zanim testowanie się rozpocznie. Sprawdźmy, jak podejść do problemu agentowo na przykładzie wdrożenia Salesforce CRM.

W tradycyjnym procesie SDLC osoba odpowiedzialna za implementację dostaje funkcjonalność do wdrożenia (np. w formie user story), czyta wymagania, a następnie realizuje swoje zadanie w ramach własnego środowiska developerskiego (sandbox). W tym celu analizuje kryteria akceptacji, definiuje cele, doprecyzowuje niejasności z właścicielami procesu, sprawdza dokumentację, implementuje rozwiązanie, tworzy proste dane do weryfikacji efektów swoich prac, „przeklikuje” się przez rozwiązanie w ramach swojego sandboxa, wreszcie publikuje zmiany w repozytorium.

Następnie przychodzi faza testów, w której osoba odpowiedzialna za ich przeprowadzenie powiela część tych kroków, już w sposób ustrukturyzowany i udokumentowany. Rozpisuje przypadki testowe, podpina je do zadania, tworzy dane testowe, odtwarza wiedzę o procesie, przechodzi scenariusze na dedykowanym środowisku (np. QA) i zgłasza błędy. Później powstają również testy automatyczne, które pilnują regresji podczas dalszego rozwoju.

Niektóre opisane kroki (weryfikacja na wydzielonym środowisku, odmienna perspektywa na kryteria akceptacji) wnoszą istotną wartość i nie chodzi o to, żeby się ich pozbyć. Jednak część z nich (dane i przypadki testowe, skrypty automatyzujące) wynika wprost z czynności podejmowanych w trakcie developmentu, a jednak zwykle nie jest później wykorzystywana. Jest to zrozumiałe, gdyż trudno wymagać, żeby ta sama osoba umiała zarówno pisać kod obsługujący logikę biznesową, jak i złożone przypadki testowe. W tym miejscu pojawia się przestrzeń na skorzystanie z ogromnej wartości, jaką wnosi AI, czyli konwertowania powstałych informacji na dowolną strukturę wyjściową.

Zejdźmy nieco z poziomu idei do warstwy konkretów. Implementując złożony system, jakiego przykładem z pewnością jest Salesforce CRM, poruszamy się w konkretnym środowisku developerskim i mamy do dyspozycji rozmaite narzędzia. Poniżej przykładowy toolset, który pozwoli nam wdrożyć omawiane podejście i polepszyć jakość dostarczanego oprogramowania:

Sprzedawca energii posiada dynamiczną stronę rekordu oferty. Strona wyświetla inny układ oraz informacje dla poszczególnych danych (np. osobne pola dla B2B oraz B2C). Na podstawie precyzyjnych wymagań należy skonfigurować dynamikę tego widoku.

Taki przykład idealnie obrazuje wagę regresji w rozwoju oprogramowania, ponieważ widoki stron kluczowych obiektów są jednymi z bardziej „pływających” i dynamicznie rozwijanych wymagań.

Podział zadań i praca równoległa

Na bazie samych wymagań, dzięki łączności z narzędziem projektowym, agent AI będzie w stanie utworzyć przypadki testowe oraz rozpocząć rekonesans procesu w przeglądarce poprzez Playwright CLI. Sprawdzi, jak wygląda interfejs, zdefiniuje powtarzalne kroki, spisze raport ze swojego ruchu, w którym odniesie się do naszego zadania, dając również cenne wskazówki do implementacji. Dzięki Salesforce CLI agent z łatwością utworzy również rekordy testowe na naszym środowisku developerskim. Tu warto zaznaczyć niewątpliwą zaletę tego, że pracujemy w kontekście repozytorium – wszystkie metadane (typy pól, relacje między obiektami) z perspektywy agenta są „na wierzchu”, dzięki czemu generowanie danych testowych odbywa się sprawnie i z wysoką dokładnością.

W tym samym czasie osoba pracująca nad funkcjonalnością może rozpocząć dostosowywanie układu strony do pierwszych wymagań. Personalizowanie widoków w Salesforce odbywa się na zasadzie „point & click” w przeglądarce – ustawiamy layout, dostosowujemy filtry i konfigurujemy proste reguły. „Pod spodem” taka strona to plik z metadanymi w formacie XML, z którego agent AI może później odczytać, co znajduje się na stronie, wesprzeć implementację i dostosować dane testowe.

Konwersja wiedzy na zasoby

Wraz z postępem prac agent lepiej rozumie proces i przekłada tę wiedzę na zasoby projektowe: tworzy w Jira przypadki testowe powiązane z wdrażanym user story, załącza uniwersalne dane testowe i programuje deterministyczne skrypty automatyczne. Dzięki temu tester startuje z wyższego poziomu i może skupić się na eksploracji: ocenie doświadczenia użytkownika, scenariuszach brzegowych oraz ryzykach biznesowych.

Prezentowane podejście nie jest rewolucją, lecz rozwinięciem istniejących standardów. Normą jest, że programiści/stki dostarczają kod pokryty testami jednostkowymi, zawierającymi także cenne dane testowe. My idziemy krok dalej: rozszerzamy te działania o testy automatyczne, powtarzalne workflow agentowe zintegrowane z zasobami projektowymi i zachowanie wartości generowanej w trakcie developmentu. Problemem otwartym wciąż pozostają ryzyka pracy agentowej, które należy kontrolować: halucynacje AI, nadmierne uproszczenia czy degradacja jakości. Dlatego algorytm powinien być iteracyjnie dopracowywany na każdym projekcie niezależnie, a współpraca człowieka z AI wciąż pozostaje kluczowa.

Paweł Zaleśny
Senior Salesforce Business Consultant
PwC Polska

Dołacz do naszej sieci talentów

Dowiedz się więcej

Od developmentu do regresji

Jak podnieść wartość testów dzięki AI?

Wspólny mianownik developersko-testerski

Techniczne aspekty ciągłego testowania aplikacji

Równoległe wdrażanie funkcjonalności i testów - przykład z życia

Podział zadań i praca równoległa

Konwersja wiedzy na zasoby

Autor artykułu: