Gdy algorytmy szukają błędów. Search-Based Software Testing spotyka LLM
W 24. odcinku podcastu i audycji radiowej „AI pod CTRL-ą” Paulina Cecko i Michał Sierlecki zabierają słuchaczy na kieleckie spotkanie społeczności AI@Kielce, które odbyło się 21 października 2026 roku przy ul. Sienkiewicza 25 w Kielcach. Gościem specjalnym odcinka jest Bernard van der Esch – ekspert backendu (PHP, Symfony, Python), inżynier automatyzacji AI oraz członek zespołu Open Mercato w Fast White Cat SA. W audycji prześwietlamy rewolucyjny paradygmat w inżynierii oprogramowania: połączenie Search-Based Software Testing (SBST) z dużymi modelami językowymi (LLM). Dowiemy się, dlaczego proste polecenie „napisz mi test” leads jedynie do bezmyślnego generowania wtórnego kodu pod tzw. „zielony pasek”, a traktowanie generowania testów jako problemu optymalizacyjnego i przeszukiwania przestrzeni stanów pozwala odnaleźć najgroźniejsze błędy krawędziowe.
Dzień dobry Państwu. Witamy bardzo serdecznie w piątkowe popołudnie na fali 101,4 MHz Polskiego Radia Kielce, a także w sieci na stronie podcasty.radiokielce.pl rozpoczynamy kolejny odcinek audycji AI pod CTRL-ą. Przy mikrofonie Michał Sierlecki. I Paulina Cecko. Kłaniamy się Państwo bardzo nisko. W naszej audycji nieustannie przyglądamy się temu, jak sztuczna inteligencja zmienia nasz świat. Od medycyny, przez prawo autorskie i sztukę, aż po sam rdzeń cyfrowej cywilizacji, czyli inżynierię oprogramowania. Dziś pozostajemy bardzo blisko naszego regionu i lokalnej społeczności pasjonatów technologii. Dziś zabieramy Państwa na kielecki deptak, a konkretnie pod adres Sienkiewicza 25 w naszym mieście, gdzie 21 października odbyło się kolejne niezwykle owocne spotkanie regionalnego środowiska AI Małpa Kielce.
Dla przypomnienia AI Kielce to dynamicznie rozwijająca się grupa zrzeszająca programistów, badaczy, przedsiębiorców i entuzjastów uczenia maszynowego z całego województwa świętokrzyskiego, którzy spotykają się regularnie, by dyskutować o najnowszych trendach w AI, a także wymieniać doświadczeniami i realizować wspólne projekty. Tym razem motywem przewodnim kieleckiego spotkania było pytanie, które spędza sen z powiek współczesnym liderom technologicznym. Co się dzieje, gdy naiwne generowanie kodu przez modele językowe zderzymy z rygorystycznymi matematycznie metodami wyszukiwania błędów? Naszym i Państwa gościem w studiu będzie dziś prelegent tego wydarzenia, Bernard van der Esch. Zanim jednak oddamy głos naszemu gościowi, jak co odcinek oddajemy pole naszemu niezawodnemu cyfrowemu asystentowi.
Czas na przedstawienie sylwetki eksperta i stały słowniczek AI. Dzień dobry. Przedstawiam sylwetkę dzisiejszego gościa audycji. Bernard van der Esch to inżynier back-endu z bogatym doświadczeniem praktycznym, określający siebie jako back-end developer who likes building things. W swojej codziennej pracy inżynierskiej specjalizuje się w języku PHP oraz frameworku Symfony, projektując zaawansowane interfejsy API, rozproszone systemy back-endowe oraz złożone integracje systemowe. Jest kluczowym członkiem zespołu rdzennego Core Team projektu Open Mercato w spółce Fast White Cat.
Bernard wyróżnia się pragmatycznym podejściem do inżynierii oprogramowania i automatyzacji procesów programistycznych. Jako pasjonat eksperymentowania z nowoczesnymi narzędziami AI oraz technologiami LLM aktywnie bada granice autonomii agentów programistycznych oraz możliwości łączenia algorytmów ewolucyjnych z modelami generatywnymi w celu podnoszenia niezawodności tworzonego oprogramowania. Słowniczek sztucznej inteligencji. Definiujemy, przypominamy, tłumaczymy.
Klasyczne algorytmy SBST miały trudność z przechodzeniem przez głęboko zagnieżdżone, skomplikowane warunki biznesowe w kodzie. Z kolei duże modele językowe posiadają głębokie zrozumienie semantyki kodu, lecz generują testy w sposób przewidywalny i podatny na wtórność oraz halucynacje. Połączenie SBST z LLM umożliwia wykorzystanie modelu językowego jako inteligentnego przewodnika, który generuje semantycznie poprawne testy, podczas gdy algorytm SBST steruje poszukiwaniem najmniej oczywistych przypadków brzegowych. Problem wyroczni testowej. Test Oracle Problem. Tradycyjne wyzwanie w automatyzacji testów, polegające na trudności w automatycznym i jednoznacznym określeniu, czy odpowiedź lub wynik zwracany przez system, zwłaszcza nieterminowy lub niedeterministyczny system oparty na AI, jest poprawny czy stanowi błąd.
Nowoczesna metryka oceny jakości kodu i testów tworzonych przez AI. Mierzy odsetek wygenerowanego kodu, który musiał zostać zmodyfikowany lub całkowicie zastąpiony przez inżynierów w określonym oknie czasowym . Posłuchajmy zdania eksperta. W naszym studiu jest już Bernard van der Esch, senior backend developer i członek core teamu Open Mercato w Fast White Cat SA. Witamy bardzo serdecznie, Bernardzie. Dziękuję, też witam, Naomi.
Zacznijmy od odczarowania rzeczywistości, w której wielu programistów żyje od czasu premiery chat GPT. Wystarczy wpisać proste polecenie, np. napisz mi testy unitowe do tej klasy. Model wypluwa kilkadziesiąt linii kodu, odpalamy komendę, widzimy piękny zielony pasek w konsoli i czujemy się bezpiecznie. Ty w swojej prelekcji na spotkaniu AI małpa Kielce postawiłeś bardzo mocną tezę, że musimy jak najszybciej przestać ufać testom napisanym przez AI pod tzw. zielony pasek. Dlaczego z zewnątrz wygląda to świetnie, a w rzeczywistości bywa pułapką? I w ogóle czym jest Search-Based Software Testing, czyli SBST, jak to szumnie brzmi? W skrócie, Search-Based Software Testing polega na takim generowaniu testów.
To jest rzecz, na którą badania już się zaczynały w latach 70., kiedy jeszcze nikt nie myślał o LLM-ach. Te testy są generowane losowo, tworzą bardzo dużo czasami absurdalnych przypadków, o których programista mógł nie pomyśleć. I dzisiaj, w czasach, gdy ludzie generują testy przez AI, ta losowość nas trochę ratuje przed tym, że AI o czymś zapomni albo poleci sobie banana w jakąś dziwną stronę. Bo dzięki temu, że tych testów generuje tyle, tak jakby wszystkie możliwe rzeczy mamy pokryte na bazie kodu, więc to się lepiej nadaje do testów regresyjnych. Zgadza się, że nie wszyscy słuchacze są techniczni, no to testy regresyjne to są takie, które z reguły tworzymy już po wytworzeniu kodu, po to, żeby zabezpieczyć go przed jakimiś przyszłymi zmianami, że jak ktoś kiedyś będzie poprowadzał jakieś zmiany w kodzie,
To nie zepsuje rzeczy, które już w nim były. Jak wyznaczyć taką bezpieczną granicę autonomii dla agenta AI aktywnie szukającego błędów, by wyeliminować ryzyko wprowadzenia niestabilnych testów, no i ograniczyć ten szum informacyjny, fałszywe alarmy w codziennej pracy zespołu programistycznego? Przede wszystkim tworzyć przemyślane SDLC do swoich projektów, tak jakby reguły tego, jak się nasz agent powinien zachowywać. Ale zacznę od takiej ogólnej może odpowiedzi. Gdy pracujemy z agentami, to taką granicą tego, co na pewno nie możemy im pozwolić działać bez naszej zgody, to są wszystkie operacje, których gdzieś tam nie możemy w przyszłości odwrócić.
I dzisiaj jest to wąskim gadłem często przy A jakie konkretnie wzorce architektoniczne, praktyki projektowe w systemach backendowych, np. przy użyciu frameworka Symfony, zwiększają testowalność algorytmiczną ułatwiającą agentom AI, a także algorytmom SPST skuteczną eksplorację przestrzeni, stanów i odnajdywanie ukrytych defektów? Nie no, tutaj się nic nie zmieniło tak naprawdę. To, co było dobrym wzorcem w czasach, gdy tworzyliśmy kod zupełnie ręcznie, jest dobrym wzorcem dzisiaj i to, że Nasze klasy w kodzie mają pojedynczą odpowiedzialność, zasada open-close. Właśnie wszystkie inne, które dotychczas stosowaliśmy, jak najbardziej mają zastosowanie.
Chcemy też, żeby nasze systemy były możliwie podzielone na konkretne obszary. Wtedy testujemy daną cechę w danym obszarze i to do siebie nie przenika. I to sprowadza nas do absolutnego sedna Twojej prelekcji i wywodu. Pozwolę sobie zacytować Twoje słowa, które stały się zresztą myślą przewodnią całego spotkania w Kielcach. Inżynier coraz rzadziej pisze kod. Coraz częściej projektuje proces, w którym kod powstaje, a potem sprawdza, czy ten proces daje kod zgodny z intencją. Jak ta zmiana roli inżyniera wygląda w praktyce? Clou tego wywodu też spowoduje, że dużo firm, które myślały, że mogą oczyścić się z szeregu programistów, bo wszystko zrobi AI, pewnego dnia obudzą się trochę z ręką w nocniku, bo nie będą miały ludzi albo nie będą mieli zaufania ludzi, którzy potrafią takie rzeczy robić, bo skoro wyrzucili dużo osób, to czemu nie następne?
Też dziękuję. AI pod CTRL-ą. A teraz wzorem naszych poprzednich odcinków przechodzimy do stałego punktu programu. Czas na syntezujące podsumowanie, przegląd prasy i internetu. Oddajemy głos naszej sztucznej inteligencji, która przeanalizowała najnowsze światowe publikacje naukowe i literaturę przedmiotu w tematyce Search-Based Software Testing spotyka LLM. Przedstawiam przegląd prasy i najnowszych doniesień naukowych. Publicacja Large Language Models for Software Testing.
Wprowadzenie ewolucyjnej archiwizacji wygenerowanych testów oraz ulepszonego operatora repopulacji z chciwym próbkowaniem przestrzeni, Greedy Repopulation Strategy, pozwoliło na oszałamiające zwiększenie pokrycia typów błędów, nawet o 11 punktów procentowych na Navi QAE, dając inżynierom pełny obraz podatności systemu AI. Dziękujemy za ten wyczerpujący przegląd naukowy. Jak wyraźnie widać, tematyka, którą poruszyliśmy podczas spotkania środowiska AI Małpa Kielce i dzisiejszej audycji w Radiu Kielce, to nie jest odległa teoria akademicka, ale absolutny front walki o jakość oprogramowania w największych koncernach technologicznych na świecie.
Dokładnie tak. Dla przypomnienia, jeśli chcą Państwo dołączyć do kolejnych dyskusji, wymieniać się doświadczeniami i rozwijać lokalne projekty AI, zachęcamy do śledzenia kalendarza i profilu społeczności AI Małpa Kielce. Następne spotkania już wkrótce. Słuchajcie nas w każdy piątek o godzinie 13.10 na 101,4 MHz Polskiego Radia Kielce oraz o dowolnej porze na podcasty radiokielce.pl, Spotify, Apple Podcasts i Deezerze. Za realizację dzisiejszego odcinka dziękujemy naszemu realizatorowi dźwięku, a przy mikrofonie żegnają się z Państwem Paulina Cecko i Michał Sierlecki. Do usłyszenia za tydzień. Trzymajcie technologię pod kontrolą.
Pokazano wszystkie 14 dopasowań. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Podajemy informacje o audycie i przedstawiamy gościa Bernarda van der Escha, senior backend developer'a z Open Mercato.
Przedstawiamy kluczowe pojęcia z zakresu automatycznego testowania oprogramowania i modeli językowych.
Bernard van der Esch omawia temat Search-Based Software Testing i jego zastosowanie w praktyce.
Bernard van der Esch omawia problemy związane z zaufaniem do testów napisanych przez AI i propozycje rozwiązania.
Bernard van der Esch omawia wzorce architektoniczne i praktyki projektowe, które ułatwiają testowanie algorytmiczne.
Bernard van der Esch omawia zmianę roli inżyniera i wpływ na przyszłość pracy programistów.
Podsumowujemy dyskusję i dziękujemy gościowi za wizytę w studiu. Przedstawiamy przegląd najnowszych badań naukowych na temat testowania oprogramowania za pomocą LLM.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.