Jak przetestować aplikację przed startem produkcyjnym — środowisko testowe, płatności testowe, testy automatyczne?

Kolejność prac: siedem kroków przed startem produkcyjnym

Testowanie przed startem ma siedem kroków i każdy kończy się artefaktem: adresem, listą scenariuszy z wynikiem albo zapisem w bazie. Kolejność nie jest dowolna — płatności testowej nie sprawdzisz bez danych, a danych nie wgrasz bez osobnego środowiska.

1. Środowisko testowe. Osobny adres i osobna baza, oddzielone od produkcji. Artefakt: działający adres, który zamawiający otwiera u siebie. Akceptuje: wykonawca zgłasza, zamawiający potwierdza, że wchodzi. Blokuje: bez osobnej bazy każdy test dopisuje śmieci do danych, które zobaczą klienci.
2. Dane testowe. Konta, rekordy i przypadki brzegowe wgrywane do środowiska testowego jedną komendą. Artefakt: odtwarzalny zestaw danych. Akceptuje: wykonawca. Blokuje: gałąź testowa bazy startuje bez danych z produkcji — dokumentacja Supabase pisze to wprost (odczyt 31 sierpnia 2026).
3. Płatności w trybie testowym. Klucze testowe operatora zamiast produkcyjnych, karty testowe zamiast prawdziwych. Artefakt: zamówienie zapisane z powiadomienia operatora — raz po udanej płatności, raz po odrzuconej. Akceptuje: zamawiający, oglądając zamówienie w panelu. Blokuje: bez tego kroku pierwsza prawdziwa wpłata jest pierwszym testem.
4. Ścieżki krytyczne automatem. Logowanie, funkcja główna, płatność — trzy scenariusze przechodzące po każdej zmianie. Artefakt: raport z uruchomienia, z datą i liczbą przypadków. Akceptuje: wykonawca, a zamawiający dostaje wynik. Blokuje: poprawka bez testu regresji potrafi cofnąć aplikację o tydzień.
5. Test na telefonie. Prawdziwe urządzenie, nie tylko emulacja w przeglądarce. Artefakt: lista uwag z telefonu, z modelem i wersją systemu. Akceptuje: zamawiający. Blokuje: emulacja nie pokaże klawiatury zasłaniającej pole ani zachowania aplikacji dodanej do ekranu początkowego.
6. Próba odtworzenia kopii. Odtworzenie bazy z kopii na środowisko testowe, z pomiarem czasu. Artefakt: data próby, punkt odtworzenia i czas, po jakim aplikacja znów działała. Akceptuje: zamawiający. Blokuje: u nas kopia bez próby odtworzenia nie liczy się jako kopia.
7. Przełączenie na produkcję. Klucze produkcyjne, domena docelowa, jedna prawdziwa płatność na małą kwotę. Artefakt: transakcja przeprowadzona od kliknięcia do zapisu i obejrzana przez człowieka. Akceptuje: zamawiający. Blokuje: klucz testowy zostawiony w konfiguracji — operator nie przyjmie wtedy prawdziwej płatności.

U nas każdy z tych kroków domyka bramka maszynowa: lint, testy, parytet. Bramka istnieje po to, żeby wynik nie zależał od tego, czy komuś chciało się sprawdzić. Druga zasada z naszej praktyki: autor to nie weryfikator — kto pisze, ten nie zatwierdza własnej pracy.

Osobne środowisko kosztuje. Gałąź testowa bazy u dostawcy, którego używamy, jest płatna od planu Pro i rozliczana godzinowo: 0,01344 USD za gałąź na godzinę (cennik Supabase, odczyt 31 sierpnia 2026). Plan darmowy hostingu dopuszcza 100 wdrożeń na dobę i jedno budowanie naraz, plan Pro — 6000 wdrożeń (dokumentacja Vercel, aktualizacja 25 sierpnia 2026).

Ścieżki krytyczne: co sprawdza automat, a co człowiek?

Trzy ścieżki decydują o starcie: rejestracja, funkcja główna i płatność; tabela niżej dokłada trzy kolejne warte sprawdzenia, ale start wstrzymują tylko te pierwsze. Automat pilnuje, żeby przechodziły po każdej zmianie; człowiek ogląda to, czego automat nie widzi — sens tekstu na ekranie, kolejność pól, wygląd na telefonie.

Automat do przeglądarki powinien obsługiwać trzy silniki naraz — Playwright uruchamia testy w Chromium, Firefoksie i WebKicie, domyślnie równolegle i bez okna (dokumentacja projektu, odczyt 31 sierpnia 2026). Wydanie 1.62.1 jest na licencji Apache-2.0 i wymaga Node.js co najmniej 20 (dane pakietu w rejestrze npm, odczyt 31 sierpnia 2026).

Płatność testowa ma jeden warunek, który u nas rozstrzyga wszystko: zapis powstaje z powiadomienia operatora, nie z powrotu przeglądarki. Wiersz poleceń Stripe przekazuje zdarzenia z konta wprost na komputer wykonawcy, a komenda stripe listen --forward-to zwraca sekret podpisu, którym aplikacja sprawdza nadawcę (dokumentacja Stripe, odczyt 31 sierpnia 2026).

Karty testowe są jawne: 4242 4242 4242 4242 przechodzi, a 4000 0000 0000 0002 zwraca odrzucenie z kodem generic_decline (dokumentacja Stripe, odczyt 31 sierpnia 2026). Data ważności — dowolna przyszła, kod CVC — dowolne trzy cyfry.

Scenariusz z kartą odrzuconą testuje się tak samo poważnie jak udany: to on pokazuje, co widzi klient, gdy bank powie „nie”, i czy aplikacja nie otworzy mu wtedy dostępu na wszelki wypadek.

Gdzie testowanie się wykłada?

Pięć awarii wraca w każdym projekcie, który wystartował za wcześnie. Żadna nie jest awarią narzędzia — wszystkie biorą się z kroku zrobionego na skróty, żeby zdążyć na datę ogłoszoną klientom.

• Testy na danych produkcyjnych. Wygodne, dopóki test nie wyśle prawdziwego maila do prawdziwego klienta albo nie skasuje jego rekordu. Dane osobowe w testach to przetwarzanie jak każde inne — opisaliśmy to przy RODO w aplikacji.
• Płatność zaliczona po przekierowaniu. Aplikacja otwiera dostęp, bo użytkownik wrócił z bramki, a nie dlatego, że przyszło powiadomienie o wpłacie. Mechanikę subskrypcji i powiadomień rozłożyliśmy na części w tekście o płatnościach od środka.
• Testy tylko na komputerze wykonawcy. Aplikacja śmiga na jednym laptopie z szybkim łączem i wtyczkami do debugowania. Klient otwiera ją na czteroletnim telefonie, w windzie. Prawdziwe urządzenie wykrywa to, czego emulacja nie pokaże.
• Kopia bez próby odtworzenia. Kopia jest, ale nikt nie sprawdził, ile trwa powrót i co dokładnie wraca. To jedna z zasad, które obowiązują od pierwszego dnia: kopię sprawdza się odtworzeniem, nie istnieniem pliku.
• Dane testowe bez rozmiaru. Lista, która przy trzech rekordach wygląda idealnie, przy tysiącach potrafi się cicho uciąć na limicie API bazy. Ten limit opisaliśmy w zasadach bezpieczeństwa.

Po przełączeniu na produkcję zostaje jeszcze jedna próba: czy aktualizacja dociera do telefonów. Aplikacja instalowana z przeglądarki potrafi utknąć u części użytkowników na starej wersji — co z tym robić, opisaliśmy w tekście o życiu aplikacji po starcie.

Po czym poznać porządną robotę?

Siedem rzeczy zamawiający może dostać przed startem, każda w postaci dokumentu, adresu albo zrzutu. Zdanie „przetestowaliśmy” nie jest żadną z nich.

• Adres środowiska testowego, który otworzę dziś — za logowaniem albo hasłem, nie publicznie. Ochrona wdrożeń podglądowych jest u naszego dostawcy hostingu dostępna we wszystkich planach (dokumentacja Vercel, aktualizacja 21 sierpnia 2026).
• Lista scenariuszy z wynikiem i datą — co sprawdzono, na czym i kiedy.
• Ślad płatności testowej w bazie — udanej i odrzuconej, zapisany z powiadomienia operatora, nie z przekierowania.
• Raport z testów automatycznych — z nazwami trzech ścieżek krytycznych i liczbą przypadków.
• Data ostatniej próby odtworzenia kopii i czas, jaki zajęła — dwie liczby zamiast zapewnienia, że kopie są.
• Wynik testu na prawdziwym telefonie — z modelem urządzenia i wersją systemu.
• Lista kluczy przełączonych na produkcyjne — operator płatności, poczta, integracje. Jedna pozycja zapomniana zatrzymuje pierwszą wpłatę.

Jeśli na trzy z tych pytań pada odpowiedź „sprawdzimy po starcie”, testowanie zostało przeniesione na klientów. To działa dokładnie raz — do dnia, w którym ktoś zapłaci i nie dostanie tego, za co zapłacił.

Czego ten tekst nie rozstrzyga?

Nie opisuje odbioru ani gwarancji: okno na uwagi, akcepty i to, co dzieje się po zgłoszeniu do odbioru, mają swoje miejsce w kolejności prac całej budowy. Zakres, do którego porównuje się wynik testów, powstaje wcześniej — przy spisywaniu pierwszej wersji.

Nie liczy też kosztu budowy ani nie wybiera operatora płatności; ten rachunek prowadzimy osobno, w porównaniu operatorów dla pierwszej wersji. Co mierzyć już po starcie, żeby wiedzieć, czy aplikacja jest używana, opisaliśmy w tekście o zdarzeniach zamiast odsłon.