Jak sprawdzić aplikację stworzoną przez AI? Testy przed publikacją

25 października 2026 · własne przykłady i materiały EXAITY

Aplikację stworzoną przez AI sprawdzaj przez konkretne zadania. Wpisz dane, policz oczekiwany wynik, zapisz, odśwież stronę i spróbuj odtworzyć kopię. Dopiero wtedy wiesz, czy działa cały proces, a nie sam przycisk.

Ładny ekran potrafi ukryć bardzo prosty błąd. W moim ćwiczeniu planer przyjął cenę 49,90 zł, wyświetlił poprawnie wyglądający wynik i pomylił się o 10,80 zł. W drugim teście zapewnił, że zapisał plan. Po odświeżeniu pola były puste.

Pokażę, jak znaleźć takie problemy, opisać je Codexowi lub Claude Code i potwierdzić poprawkę. Jest też aplikacja do pobrania, wyniki testów i checklista do własnego projektu.

Jak sprawdzić kod wygenerowany przez AI, jeśli nie jesteś programistą?

Zacznij od tego, co aplikacja ma robić dla użytkownika. Kalkulator ma liczyć, formularz ma zapisywać właściwe dane, a eksport ma dać plik, który da się otworzyć i wykorzystać.

Przyjmij trzy poziomy sprawdzania:

• Test funkcji: czy pojedyncza operacja daje poprawny wynik?
• Test połączeń: czy zapis, odczyt, plik i ewentualne API współpracują?
• Test całej ścieżki: czy użytkownik od otwarcia strony do końca zadania dochodzi bez pomocy?

Czytanie kodu i automatyczny przegląd przez AI też się przydają. Nie zastępują jednak wykonania tych samych kroków w działającej aplikacji. „Powinno działać” w odpowiedzi asystenta jest hipotezą do sprawdzenia.

Zanim zaczniesz klikać, zapisz oczekiwany wynik

Nie testuj według zasady „zobaczę, czy coś się stanie”. Zapisz: dane wejściowe, czynność i wynik, który uznasz za poprawny.

Dla planera kosztów treści wygląda to tak:

Tak samo opiszesz formularz zapisu, listę klientów czy generator dokumentów. Kluczowe jest to, żeby oczekiwanie pochodziło z Twoich zasad działania, a nie z przypadkowego wyniku programu.

Własne ćwiczenie: trzy błędy, które da się przeoczyć

Wykorzystałem własny planer z porównania Codexa i Claude Code. Do oddzielnej kopii dodałem zapis planu i kopię JSON, a następnie celowo wprowadziłem trzy usterki: obcinanie kwoty przy przecinku, pozorny zapis i zbyt szeroki układ telefonu.

To ćwiczenie do nauki testowania. Te błędy nie są oceną pierwotnego wyniku Codexa ani porównaniem jakości modeli.

W zestawie jest 13 asercji dotyczących kwot, zakresów, zapisu i kopii danych. Osobno wykonałem próby w przeglądarce: obliczenie, zapis po odświeżeniu, eksport/import, błędne dane, Enter oraz widok 390 px.

1. Kwoty, przecinek i błędne dane

W polskim formularzu cena „49,90” jest zupełnie normalna. W celowo zepsutej wersji programu użyłem odczytu opartego o parseFloat. Z takiego tekstu powstała liczba 49, bo przecinek kończy poprawny dla tej funkcji fragment liczby.

W efekcie 12 postów kosztowało na ekranie 588,00 zł zamiast 598,80 zł. Przy kropce problem mógł pozostać niewidoczny. Dlatego test obejmuje oba zapisy.

W poprawionej wersji wejście jest sprawdzane, a kwoty przeliczane na całkowite grosze. Wynik wraca do formatu złotówek dopiero przy wyświetlaniu.

To nie koniec. Sprawdź pustą cenę, zero postów, wartość ujemną, zbyt duży zakres i trzy miejsca po przecinku. Ustal też, co ma się stać po zmianie pola. Stary wynik nie powinien udawać aktualnego.

W moim formularzu po wpisaniu błędnej ceny wynik znika i pojawia się komunikat. Po wpisaniu 49.90 oraz naciśnięciu Enter znów otrzymałem 598,80 zł.

2. Zapis sprawdza się po odświeżeniu, nie po komunikacie

Drugi błąd był prostszy: przycisk pokazywał „Plan zapisany w tej przeglądarce”, ale niczego nie zapisywał. Dopóki karta pozostawała otwarta, można było go nie zauważyć.

1. Wpisz rozpoznawalną nazwę, np. „Plan październik; PL”.
2. Oblicz i zapisz plan.
3. Odśwież stronę.
4. Sprawdź wszystkie pola, nie tylko nazwę.
5. Oblicz ponownie i porównaj wynik.

W wersji z błędem po przeładowaniu nazwa i liczba postów zniknęły. W poprawionej wróciły: 12, 49,90, 1000 i koszt 598,80 zł.

Zapis miejscowy, konto i kopia to różne rzeczy

Ten demonstrator używa localStorage. Dane zostają w danej przeglądarce i dla danego adresu strony. Nie pojawią się automatycznie na drugim urządzeniu. Jeśli potrzebujesz synchronizacji kont, zapisz taki warunek osobno.

Testuj pod stałym adresem lokalnego serwera. Dla plików otwieranych bezpośrednio przez file:// działanie localStorage nie jest jednolicie określone.

Kopia zapasowa jest sprawdzona dopiero po odtworzeniu

Pobrałem JSON, zmieniłem nazwę planu i wczytałem pobrany plik. Wróciły oryginalne wartości. W kopii zachował się również średnik i polskie znaki w nazwie.

Przy własnym projekcie wykonaj taką próbę w oddzielnym środowisku lub na testowych danych. Sprawdź też błędny plik, brak miejsca na zapis i awarię magazynu danych. Aplikacja powinna wtedy pokazać konkretny problem, zamiast ogłaszać sukces.

3. Telefon i klawiatura: czy da się ukończyć zadanie?

W trzeciej celowej usterce nadałem stronie minimalną szerokość 920 px. Przy widoku 390 px trzeba było przesuwać całą stronę w bok. Po usunięciu tego ograniczenia i dopasowaniu układu pola mieszczą się w wąskim widoku.

To był test szerokości przeglądarki, nie fizycznego telefonu. Przed wydaniem własnego projektu powtórz główną czynność również na urządzeniu, którego używają odbiorcy.

• Czy klawiatura ekranowa nie zasłania przycisku?
• Czy pola mają etykiety, a nie tylko znikające podpowiedzi?
• Czy długi tytuł, adres i komunikat mieszczą się bez rozjeżdżania układu?
• Czy da się przejść klawiszem Tab i zobaczyć, gdzie jest fokus?
• Czy powiększenie tekstu nie blokuje obsługi?

W ćwiczeniu potwierdziłem obliczenie formularza klawiszem Enter. Samo to nie sprawdza całej dostępności. Klawiaturę, etykiety i powiększenie potraktuj jako osobne scenariusze.

4. Uruchom projekt od zera

Kod może działać w otwartym środowisku autora dzięki plikom lub ustawieniom, których nie ma w paczce. Dlatego odbiór obejmuje również uruchomienie według instrukcji.

Poproś AI o przygotowanie krótkiego README: wymagana wersja środowiska, komendy startu, opis konfiguracji i sposób uruchomienia testów. Następnie przejdź te kroki w nowej kopii projektu.

• Zależności: czy projekt podaje używane pakiety i ich wersje?
• Konfiguracja: czy wiadomo, jakie zmienne trzeba uzupełnić?
• Pliki: czy obrazy, style i moduły są w paczce?
• Błędy: czy uruchomienie bez wymaganej konfiguracji daje zrozumiały komunikat?
• Wydanie: czy sprawdzono wersję, którą naprawdę otrzyma użytkownik?

Dołącz plik blokady zależności, jeśli projekt korzysta z menedżera pakietów. Sprawdź też zgłoszone podatności i licencje użytych bibliotek. Nie zmieniaj wszystkich wersji na oślep tuż przed publikacją; po aktualizacji powtórz testy.

5. Konta, dane i integracje, jeśli aplikacja ich używa

Planer w tym artykule jest lokalnym ćwiczeniem bez logowania i backendu. W aplikacji firmowej dochodzą inne pytania.

Czy każdy widzi tylko swoje dane?

Użyj dwóch własnych kont testowych: A i B. Utwórz rekord na A, a następnie sprawdź w środowisku testowym, czy konto B oraz użytkownik wylogowany nie mogą go odczytać, zmienić ani pobrać.

Kontrola dostępu musi działać po stronie serwera przy żądaniu. Ukryty przycisk administratora i napis „brak dostępu” na ekranie nie są wystarczającym sprawdzeniem uprawnień.

Co się dzieje, gdy API nie odpowiada?

Sprawdź brak sieci, przekroczenie czasu odpowiedzi, odrzucenie danych i ponowne kliknięcie. Zamówienie, płatność czy wiadomość nie powinny powstać dwa razy po ponowieniu. Takie próby wykonuj na testowych integracjach.

Sukces pokazuj dopiero po potwierdzeniu operacji przez właściwy system. „Wysłano” wyświetlone przed odpowiedzią serwera może wprowadzić użytkownika w błąd.

Gdzie są klucze i prywatne dane?

Klucze serwerowe i hasła nie powinny trafiać do publicznego kodu przeglądarki ani paczki dla użytkownika. Sprawdź też logi, przykładowe pliki konfiguracji i komunikaty błędów. Wartość testowa i prawdziwy sekret muszą być rozróżnione.

Walidacja formularza pomaga użytkownikowi, ale w aplikacji z backendem dane trzeba sprawdzać również na serwerze. Przy płatnościach, uprawnieniach i danych klientów zaplanuj techniczny przegląd tych mechanizmów przed wydaniem.

Jak zlecić AI poprawkę, żeby dało się ją zweryfikować?

Zamiast „napraw aplikację” opisz jeden odtwarzalny błąd. Podaj dane, oczekiwanie i to, co faktycznie zobaczyłeś.

W planerze kosztów jest błąd odczytu kwoty.
Kroki: 12 postów, cena 49,90, budżet 1000, kliknięcie Oblicz.
Oczekuję: koszt 598,80 zł i pozostały budżet 401,20 zł.
Otrzymuję: 588,00 zł i 412,00 zł.

Znajdź przyczynę i zaproponuj najmniejszą poprawkę.
Dodaj test, który wykrywa ten błąd przed zmianą i przechodzi po zmianie.
Sprawdź też zapis 49.90, pustą i ujemną kwotę oraz 3 × 0,10.
Nie zmieniaj niezwiązanych funkcji.
Uruchom odpowiednie testy. Podaj ich rzeczywiste wyniki oraz czego nie udało się sprawdzić.

Co ma znaleźć się w odpowiedzi po poprawce?

Przyczyna, zmienione pliki, wykonane polecenie testowe i wynik. Do tego potwierdzenie, że ponownie wykonałeś swoją pierwotną ścieżkę w aplikacji.

W moim zestawie ten sam test wykrył problem przed zmianą i przeszedł po zmianie. Wynik 13/13 oznacza komplet tych konkretnych asercji. Nie jest oceną wszystkich możliwych zachowań programu.

Po naprawieniu zapisu powtórz obliczenia i eksport. Po zmianie CSS sprawdź komputer i telefon. Taki powrót do wcześniejszych scenariuszy to test regresji: upewniasz się, że poprawka nie zepsuła czegoś obok.

Checklista przed publikacją aplikacji z AI

Zaznaczaj punkty dopiero po wykonaniu odpowiedniej próby. Jeśli czegoś nie ma w projekcie, odnotuj „nie dotyczy” w arkuszu i krótko wyjaśnij dlaczego.

Kiedy uznać wersję za gotową?

Gdy działa główne zadanie, obliczenia i dane są zgodne z kryteriami, a krytyczne błędy zostały zamknięte. Zapisz wersję kodu, datę testu i wynik każdego scenariusza.

Zachowaj też działającą poprzednią wersję i sposób odtworzenia danych. Przy aplikacji z bazą samo cofnięcie plików może nie odwrócić zmiany struktury danych. Plan przywrócenia powinien uwzględniać oba elementy.

Po publikacji wykonaj krótki test głównej ścieżki na właściwym adresie. Jeśli przygotowujesz aplikację na Androida, dalszy etap opisuję w poradniku publikacji aplikacji w Google Play.

Najczęstsze pytania o sprawdzanie kodu z AI