Jak przetestować aplikację zbudowaną z AI, gdy nigdy wcześniej nie testowałeś oprogramowania
Praktyczny przewodnik po testowaniu aplikacji zbudowanej z AI, gdy nie masz doświadczenia w QA. Gdzie klikać, co celowo zepsuć i jak rozpoznać, że jest na tyle dobra, by ją udostępnić.
Zbudowałeś aplikację z AI. Działa na szczęśliwej ścieżce — wpisujesz imię, klikasz przycisk, widzisz ekran sukcesu. I co teraz? Czy jest gotowa, żeby wysłać ją trzem testerom? Twojemu zespołowi? Twoim klientom?
Jeśli nie masz zaplecza programistycznego, testowanie wydaje się jedną z tych rzeczy, które robią „prawdziwi programiści” — z frameworkami, asercjami i potokami CI. Dobra wiadomość: większość testowania tym nie jest. Większość testowania, zwłaszcza gdy wypuszczasz coś małego i nowego, to jedna osoba klikająca z intencją. To potrafisz zrobić. Ten wpis jest o robieniu tego celowo, żebyś znalazł błędy, zanim znajdą je Twoi użytkownicy.
Celem nie jest testowanie aplikacji zbudowanej z AI jak profesjonalista. Celem jest testowanie jej jak paranoiczny przyjaciel, który szczerze chce, żeby zadziałała.
Sztuczka z dwiema listami
Zanim cokolwiek klikniesz, usiądź na dziesięć minut z pustym dokumentem i napisz dwie listy.
Lista A — szczęśliwe ścieżki. Jakie są trzy albo cztery rzeczy, które użytkownik ma robić z tą aplikacją? Dla typowego SaaS-a to może być: zarejestruj się, utwórz pierwszy projekt, zaproś jednego współpracownika, wyeksportuj wynik. Dla aplikacji typu katalog: wyszukaj, filtruj, kliknij pozycję, zapisz ją. Trzy albo cztery prawdziwe przepływy, prostym językiem.
Lista B — nieszczęśliwe ścieżki. Co jeśli użytkownik zrobi coś prawie dobrze, ale nie całkiem? Wpisze swój e-mail z literówką. Naciśnie przycisk wstecz w połowie przepływu. Otworzy dwie karty i edytuje to samo w obu. Wyśle pusty formularz. Wklei zawartość dokumentu Worda — z formatowaniem i wszystkim — w pole tekstowe. Zamknie laptop i otworzy go ponownie dziesięć minut później. Spróbuje zaprosić współpracownika, używając adresu e-mail, który już istnieje w systemie.
Lista szczęśliwych ścieżek to to, pod co optymalizował Twój kreator aplikacji z AI. To to, co AI w głowie testowało, pisząc kod. Lista nieszczęśliwych ścieżek to miejsce, gdzie mieszkają błędy, bo prawie nikt — ani AI, ani Ty, gdy pisałeś prompty — nie myślał o tych przypadkach.
Kiedy faktycznie testujesz, przejdź najpierw przez Listę A, żeby potwierdzić, że podstawy działają. Potem spędź większość czasu na Liście B. To na Liście B jest wartość. Lista B to też miejsce, gdzie odkrywasz, czego naprawdę chcesz od aplikacji, gdy sprawy idą nie tak, co często wymusza wyjaśniającą rozmowę z kreatorem z AI („kiedy formularz jest na wpół wypełniony, czy ma ostrzegać, czy zapisywać automatycznie?”).
Trzy rzeczy do celowego zepsucia
Gdy masz już swoje listy, oto trzy kategorie, które wyłapują większość prawdziwych błędów w aplikacjach zbudowanych z AI.
Puste i dziwne dane wejściowe. Wyślij formularz bez wypełniania niczego. Wyślij go z wypełnionym jednym polem. Wpisz nazwę długą na 500 znaków. Wpisz nazwę z emoji. Wklej URL w pole, które oczekuje nazwy. Spróbuj pola e-mail z „test”, z „test@”, z „test@example”, z adresem „a@b.co” — czy akceptuje prawidłowe krótkie adresy? Kreatory aplikacji z AI często dodają walidację, ale walidacja może być błędna w obie strony — zbyt restrykcyjna (odrzuca prawdziwych użytkowników) albo zbyt luźna (przyjmuje śmieci).
Cofanie się i ruchy na boki. Większość aplikacji działa dobrze, jeśli przechodzisz przez nie jak posłuszna wycieczka. Psują się w chwili, gdy ktoś zaczyna eksplorować. Kliknij przycisk wstecz. Kliknij ponownie do przodu. Odśwież stronę w środku przepływu. Otwórz tę samą stronę w dwóch kartach i edytuj na obu. Wyloguj się i zaloguj ponownie. Jeśli masz przycisk „cofnij”, kliknij go trzy razy z rzędu. To nie są przypadki brzegowe. Tak prawdziwi ludzie używają oprogramowania.
Dane po fakcie. Zbuduj to, co buduje Twoja aplikacja. Projekt, post, rekord, cokolwiek. Potem wróć jutro. Czy wciąż tam jest? Czy formatowanie przetrwało? Jeśli to zedytujesz, czy edycja się zapisuje? Jeśli to usuniesz, czy naprawdę zniknęło, czy wraca po odświeżeniu? Kreatory aplikacji z AI często idealnie ogarniają przepływ „utwórz”, a zapominają, że wszystko, co tworzysz, musi przetrwać i dać się później edytować.
Jak wygląda „wystarczająco dobre”
Nigdy nie przetestujesz aplikacji zbudowanej z AI do perfekcji. Oprogramowanie jest zbyt poplątane, a Twój czas zbyt cenny. Pytanie nie brzmi „czy jest idealne” — tylko „czy jest wystarczająco dobre dla następnej grupy ludzi, którą przed nim postawię”.
Oto przybliżona hierarchia, którą możesz pożyczyć.
Wystarczająco dobre na demo: szczęśliwa ścieżka działa bez wykrzaczania się. Przyciski prowadzą tam, gdzie powinny. Możesz pokazać nagranie ekranu, niczego nie wycinając.
Wystarczająco dobre dla przyjaznych użytkowników: nieszczęśliwe ścieżki nie gubią danych. Formularze mówią, co jest nie tak, zamiast po cichu zawodzić. Odświeżenie strony niczego nie psuje. Troje znajomych może z tego korzystać bez pisania do Ciebie po pomoc.
Wystarczająco dobre dla płacących użytkowników: aplikacja obsługuje użytkowników, których nigdy nie spotkałeś. Ich przeglądarki, ich dane, ich nawyki. Masz sposób, żeby widzieć, kiedy coś się psuje (podstawowe śledzenie błędów wystarczy — nie potrzebujesz wymyślnego panelu). Potrafisz naprawić i wdrożyć ponownie, nie psując tego ludziom, którzy już korzystają.
Większość twórców wypuszcza na poziomie „przyjaznych użytkowników”, a potem podnosi go w miarę napływających opinii. To słuszne. Błędem jest próba przeskoczenia z „wystarczająco dobre na demo” prosto do „wystarczająco dobre dla płacących użytkowników” bez kroku pośredniego. Przyjaźni użytkownicy znajdują rzeczy, które znaleźliby prawdziwi użytkownicy — ale się o nie nie złoszczą. Wykorzystaj tę różnicę.
Kiedy poprosić AI, żeby testowało za Ciebie
Twój kreator aplikacji z AI może pomóc w testowaniu, ale musisz być konkretny co do tego, czego chcesz. „Dodaj testy” to słaby prompt. Wygeneruje kod, który wygląda jak testy i prawdopodobnie przechodzi, a tak naprawdę nie sprawdza niczego, na czym Ci zależy. Większość tych autogenerowanych testów potwierdza, że 1+1 to wciąż 2.
Lepszy prompt: „Właśnie spróbowałem wysłać formularz rejestracji z pustym polem e-mail i się wykrzaczył. Znajdź, gdzie to jest obsługiwane, i dodaj sprawdzenie, które pokazuje przyjazny błąd zamiast tego.” Konkretny błąd, konkretna naprawa, konkretny rezultat. AI jest w tym dobre. Jest słabe w „upewnij się, że moja aplikacja jest wolna od błędów”, bo to nie zadanie — to życzenie.
Drugą rzeczą, w której kreatory z AI są dobre, jest odtwarzanie Twojego błędu. Jeśli opiszesz, co zrobiłeś, czego oczekiwałeś i co się stało, kreator zwykle potrafi prześledzić kod i zaproponować naprawę. Dyscyplina, której potrzebujesz, to dyscyplina jasnego spisania tych trzech rzeczy. Większość zgłoszeń błędów od początkujących to jakaś wersja „nie działa”. Większość naprawialnych zgłoszeń błędów to „kliknąłem X, oczekiwałem Y, dostałem Z”.
Testowanie to czytanie, nie tylko klikanie
Jeszcze jedno. Nie musisz rozumieć każdej linijki kodu w swojej aplikacji zbudowanej z AI, żeby dobrze ją przetestować. Ale powinieneś przynajmniej rzucić okiem. Otwórz plik, który AI właśnie zmieniło. Przeczytaj funkcję, którą dodało. Nie musisz wiedzieć, co znaczy każde słowo kluczowe — musisz wiedzieć, czy funkcja zdaje się robić to, o co prosiłeś.
Wiele błędów w aplikacjach zbudowanych z AI to nie „kod jest zepsuty”. To „kod robi coś trochę innego, niż chciałeś”. Pole zapisuje się w złym miejscu. Przycisk aktualizuje jedno, ale nie powiązaną z tym rzecz. Przycisk „usuń” ukrywa zamiast usuwać. Nie wyłapiesz tego bez przeczytania, co faktycznie zostało zbudowane.
Traktuj kod jak coś, co możesz audytować, a nie coś, co musisz pisać. To różnica między aplikacją zbudowaną z AI, której ufasz, a taką, o której tylko masz nadzieję, że działa.
Wersja prosta
Jeśli nie zapamiętasz nic innego: napisz dwie listy, psuj rzeczy celowo i zdecyduj, na którym poziomie „wystarczająco dobre” wypuszczasz. Większość błędów w aplikacji zbudowanej z AI nie jest subtelna. Siedzą na liście nieszczęśliwych ścieżek, której nikomu nie chciało się spisać.
Jeśli chcesz małą pracę domową: wybierz jedną aplikację, którą zbudowałeś, i spróbuj czterech rzeczy — wyślij pusty formularz, odśwież w połowie przepływu, zedytuj rekord i sprawdź go jutro oraz poproś znajomego, żeby z niej skorzystał bez Twojego nadzoru. Cokolwiek się zepsuje, to Twoja prawdziwa lista błędów. Wszystko inne to prokrastynacja.