Jak przetestować aplikację przed startem: praktyczny plan przedstartowy
Żeby przetestować aplikację przed startem, wypisz kilka ścieżek, które użytkownik musi móc przejść, przejdź każdą z nich jako zupełnie nowy użytkownik na laptopie i na telefonie, a następnie sprawdź sposoby, w jakie może pójść źle: puste dane, błędne dane wejściowe, drugie konto, wolne połączenie. Wszystko, co dotyczy pieniędzy lub prywatnych danych, testuj ze szczególną uwagą, a po publikacji powtórz główne ścieżki na żywym adresie URL. Na koniec obserwuj kogoś, kto nigdy nie widział aplikacji, jak próbuje z niej korzystać.
Do tego nie potrzebujesz zespołu QA ani frameworka testowego. Potrzebujesz listy, godziny lub dwóch i dyscypliny, by faktycznie ją przejść.
Krok 1: Spisz ścieżki, które mają znaczenie
Ścieżka to zadanie od początku do końca, z którym użytkownik przychodzi. Większość aplikacji ma od trzech do sześciu takich, które naprawdę się liczą. Dla aplikacji rezerwacji:
- Rejestracja i potwierdzenie konta
- Znalezienie zajęć i rezerwacja
- Anulowanie rezerwacji
- Zapłata za karnet na zajęcia
- Personel: sprawdzenie dzisiejszych rezerwacji
Jeśli napisałeś historyjki użytkownika, ich kryteria akceptacji są już twoimi przypadkami testowymi. Jeśli nie, napisz po jednej linijce dla każdej ścieżki z opisem, jak wygląda „sukces”.
Ułóż je według priorytetu. Ścieżki, które zarabiają pieniądze lub z których korzysta każdy użytkownik (rejestracja, logowanie, podstawowa czynność), testuje się najpierw i najdokładniej.
Krok 2: Przetestuj ścieżkę idealną jako nowy użytkownik
„Ścieżka idealna” to przebieg zgodny z zamierzeniem. Testuj ją tak, jak doświadczyłby jej obcy człowiek:
- Użyj okna prywatnego przeglądania, żeby nie być zalogowanym i nie mieć zapisanych danych.
- Użyj świeżego konta z prawdziwym adresem e-mail, do którego masz dostęp.
- Zacznij od strony głównej lub linku, a nie od strony, którą zapisałeś w zakładkach podczas budowy.
Nowi użytkownicy nie mają danych. Wiele błędów pojawia się dopiero wtedy, gdy lista jest pusta, profil nie ma zdjęcia albo nic jeszcze nie zostało kupione. Twoje własne konto, pełne danych testowych, je ukrywa.
Krok 3: Spróbuj to zepsuć
Teraz powtórz każdą ścieżkę i celowo zrób coś źle.
| Spróbuj tego | Co sprawdzasz |
|---|---|
| Wyślij formularze puste lub tylko ze spacjami | Wymagane pola są egzekwowane, z jasnym komunikatem |
| Bardzo długi tekst, emoji, imiona z akcentami | Układ się trzyma, dane zapisują się poprawnie |
| Złe formaty: litery w polu telefonu, data z przeszłości | Walidacja zarówno na stronie, jak i na serwerze |
| Dwukrotne kliknięcie przycisku wysłania | Brak zduplikowanych zamówień i rezerwacji |
| Przycisk wstecz w przeglądarce w połowie procesu | Brak uszkodzonego stanu i utraty danych |
| Odświeżenie każdej strony | Dane są zachowane; brak pustej strony ani błędu 404 |
| Wyloguj się, a potem naciśnij wstecz | Prywatne strony się nie pokazują |
| Dwie karty edytujące to samo | Ostatni zapis nie kasuje po cichu pierwszego |
Odświeżanie warto wyróżnić: jeśli aplikacja działa, gdy klikasz po niej, ale odświeżenie głębszej strony pokazuje błąd 404, zobacz jak naprawić błędy 404 po wdrożeniu.
Krok 4: Przetestuj uprawnienia na dwóch kontach
To najważniejszy test dla każdej aplikacji z kontami i ten, który najczęściej się pomija.
Utwórz dwóch zwykłych użytkowników, A i B, oraz (jeśli aplikacja je ma) administratora.
- Jako A utwórz rekord. Zaloguj się jako B. Czy B może go zobaczyć, edytować lub usunąć? Nie powinien, chyba że tak zaprojektowano.
- Jako A skopiuj adres URL jednego ze swoich rekordów. Zaloguj się jako B i otwórz ten adres bezpośrednio.
- Jako zwykły użytkownik spróbuj otworzyć strony administracyjne, wpisując ich adresy.
- Wyloguj się całkowicie i spróbuj tych samych adresów URL.
Jeśli znajdziesz tu problem, nie startuj, dopóki nie zostanie naprawiony. Sprawdzenie musi odbywać się na serwerze, a nie tylko przez ukrywanie przycisku. Nasza lista kontrolna bezpieczeństwa dla aplikacji budowanych przez AI idzie głębiej.
Krok 5: Testuj na prawdziwych urządzeniach
Otwórz aplikację na prawdziwym telefonie, a nie tylko w wąskim oknie przeglądarki.
- Czy możesz dotknąć każdego przycisku bez przybliżania?
- Czy klawiatura nie zasłania pola, w które piszesz?
- Czy tabele i szerokie treści się przewijają lub zawijają, zamiast wypychać stronę na boki?
- Czy tekst jest czytelny bez rozsuwania palcami?
Jeśli możesz, wypróbuj co najmniej jeden iPhone (Safari) i jeden telefon z Androidem (Chrome). Zwłaszcza Safari ma własne dziwactwa przy datach, wideo i elementach o stałej pozycji.
Krok 6: Testuj pieniądze i e-mail od początku do końca
Każda funkcja, która obciąża karty lub wysyła e-maile, wymaga pełnego przejścia.
Płatności. Użyj trybu testowego swojego dostawcy płatności i testowych numerów kart. Sprawdź udaną płatność, odrzuconą kartę i anulowaną kasę. Upewnij się, że zamówienie lub subskrypcja pojawia się w twojej aplikacji po płatności, a nie tylko w panelu dostawcy. Jeśli aplikacja polega na webhookach (wiadomościach, które dostawca płatności wysyła do twojego serwera), sprawdź, czy docierają do opublikowanej aplikacji, a nie tylko w środowisku deweloperskim. Następnie przed startem przełącz się na klucze produkcyjne i zrób jeden mały, prawdziwy zakup, który potem zwrócisz.
E-maile. Zarejestruj się prawdziwymi adresami u dwóch lub trzech różnych dostawców. Sprawdź, czy e-maile docierają, nie trafiają do spamu i czy każdy link w nich wskazuje na żywą domenę, a nie na adres podglądu.
Krok 7: Sprawdź szybkość i błędy
- Otwórz narzędzia deweloperskie przeglądarki (kliknij prawym → Zbadaj) i sprawdź kartę Konsola na każdej głównej stronie. Czerwone błędy warto naprawić, nawet gdy nic nie wygląda na zepsute.
- Wczytaj stronę na telefonie przez transmisję komórkową, a nie przez Wi-Fi. Jeśli pierwszy ekran ładuje się kilka sekund, najpierw sprawdź rozmiary obrazów.
- Uruchom darmowy audyt, na przykład Lighthouse w narzędziach deweloperskich Chrome, by szybko ocenić wydajność i dostępność.
Krok 8: Testuj opublikowaną aplikację, a nie tylko podgląd
Podgląd i opublikowana aplikacja to nie to samo środowisko. Zanim powiesz komukolwiek o starcie, powtórz główne ścieżki na żywym adresie URL:
- Czy wszystkie zmienne środowiskowe i sekrety są ustawione dla opublikowanej aplikacji?
- Czy używa właściwej bazy danych, z danymi, których się spodziewasz?
- Czy przekierowania po logowaniu i linki w e-mailach używają żywej domeny?
- Czy odświeżenie głębokiej strony ładuje się poprawnie?
Krok 9: Obserwuj, jak ktoś inny z niej korzysta
Daj jednej lub dwóm osobom cel („zarezerwuj zajęcia jogi na sobotę”), a nie instrukcje. Obserwuj, nie pomagaj i zapisuj, gdzie się wahają. To najszybszy sposób na znalezienie mylących sformułowań i ukrytych przycisków. Większą wersję tego opisuje jak przeprowadzić test beta.
Gdy trafią na błąd, zapisz go porządnie: kroki, oczekiwany wynik i rzeczywisty wynik. Nasz przewodnik jak napisać dobry raport o błędzie pokazuje format.
Używanie AI do pomocy w testowaniu
Jeśli budujesz z AI, możesz poprosić je o pomoc w planowaniu i przeprowadzaniu testów:
Wypisz główne ścieżki użytkownika w tej aplikacji i dla każdej z nich przypadki brzegowe, które najprawdopodobniej się zepsują: stany puste, błędne dane wejściowe, uprawnienia i odświeżanie. Ułóż to w listę kontrolną, którą mogę przejść.
Zaloguj się jako dwóch różnych użytkowników testowych i sprawdź, czy użytkownik B może zobaczyć lub zmienić cokolwiek, co utworzył użytkownik A, w tym otwierając bezpośrednio adresy rekordów A. Przed naprawą czegokolwiek zgłoś, co znalazłeś.
Raport testowy AI traktuj jako pierwszy przegląd. Ścieżki dotyczące pieniędzy i uprawnień nadal przeklikaj sam.
Testowanie w Mythex
W Mythex polecenie /test uruchamia App Testing: agent steruje przeglądarką na twoim podglądzie na żywo, klika po stronach, robi zrzuty ekranu i zgłasza zepsute ścieżki na czacie. Najlepiej działa przy konkretnej ścieżce, na przykład „przetestuj rejestrację i rezerwację zajęć”. Napraw to, co znajdzie, za pomocą /fix lub zwykłej wiadomości, a potem uruchom /test ponownie. App Testing korzysta z podglądu, więc po publikacji sam sprawdź główne ścieżki na opublikowanym adresie URL. Zobacz App Testing w dokumentacji oraz nasz przewodnik jak debugować aplikację zbudowaną przez AI na wypadek, gdy coś zawiedzie.
Częste błędy
- Testowanie wyłącznie jako ty. Twoje konto administratora z dużą ilością danych ukrywa błędy stanów pustych i uprawnień.
- Testowanie wyłącznie na laptopie. Dla wielu stron większość odwiedzających przychodzi z telefonu.
- Pominięcie drugiego konta. Wyciek danych między użytkownikami to najpoważniejszy błąd, z jakim aplikacja może wystartować.
- Ufanie podglądowi. Żywa aplikacja ma inne ustawienia; testuj też ją.
- Naprawianie błędów bez ponownego testowania sąsiednich części. Poprawka jednego formularza może zepsuć inny, który używa tego samego kodu.
Lista kontrolna przed startem
- Główne ścieżki spisane i uszeregowane według priorytetu
- Każda ścieżka przechodzi jako zupełnie nowy użytkownik w oknie prywatnym
- Puste, błędne, długie i zduplikowane dane wejściowe są obsłużone
- Odświeżenie działa na każdej stronie
- Użytkownicy nie mogą zobaczyć ani zmienić nawzajem swoich danych, nawet przez adres URL
- Strony administracyjne zablokowane dla zwykłych użytkowników i niezalogowanych odwiedzających
- Działa na prawdziwym iPhonie i telefonie z Androidem
- Płatności przetestowane: sukces, odrzucenie, anulowanie, a aplikacja aktualizuje się potem
- E-maile docierają, nie trafiają do spamu i linkują do żywej domeny
- Brak czerwonych błędów w konsoli na głównych stronach
- Główne ścieżki powtórzone na opublikowanym adresie URL
- Co najmniej jedna osoba z zewnątrz wypróbowała aplikację, gdy ją obserwowałeś
Pytania
Ile testów potrzebuje mała aplikacja przed startem?
Tyle, by mieć pewność, że główne ścieżki działają dla zupełnie nowego użytkownika na telefonie i laptopie, że użytkownicy nie widzą nawzajem swoich danych i że wszystko, co dotyczy pieniędzy, działa od początku do końca. Dla większości małych aplikacji to kilka skupionych godzin, a nie tygodnie.
Czy do MVP potrzebuję automatycznych testów?
Niekoniecznie. Ręczne testowanie podstawowych ścieżek wyłapuje większość błędów blokujących start. Automatyczne testy zaczynają się opłacać, gdy często zmieniasz aplikację i chcesz szybko wiedzieć, że nie zepsułeś czegoś, co wcześniej działało.
Czy testować na podglądzie, czy na żywej aplikacji?
Na obu. Dokładnie testuj w podglądzie, a potem powtórz główne ścieżki w opublikowanej aplikacji, bo brakujące zmienne środowiskowe, inna baza danych lub ustawienia routingu mogą sprawić, że wersja na żywo zachowa się inaczej.
Kto poza mną powinien przetestować aplikację?
Przynajmniej jedna osoba, która jej wcześniej nie widziała. Daj jej cel, a nie instrukcje, i obserwuj bez pomagania. Twórcy nieświadomie omijają ścieżki, które się psują.