170 testów na zielono, a system i tak by nie ruszył. Jak sprawdzamy aplikację przed pilotażem
We wrześniu 2026 przed pilotażem jednego z naszych systemów mieliśmy komplet zielonych wyników: 170 na 170 testów na żywej bazie, 44 z 45 testów przeglądarkowych (jeden świadomie pominięty) i obchód 46 ekranów w czterech rolach bez żadnego błędu. Gdybyśmy na tym poprzestali, pierwszy dzień pilotażu skończyłby się katastrofą. Oto dlaczego testy kodu to dopiero połowa gotowości — i jak wygląda druga połowa.
Co wykazał audyt, którego nie robią testy
Po testach automatycznych robimy audyt gotowości: przechodzimy system tak, jak przejdzie go firma w pierwszym tygodniu, i sprawdzamy nie kod, tylko konfigurację i dane. Tym razem lista blokerów wyglądała tak — i żaden z nich nie był błędem w kodzie:
- poczta nie wychodziła na zewnątrz — serwer nie miał ustawionej skrzynki nadawczej, więc wiadomości lądowały w lokalnej pułapce testowej; w kolejce czekało ponad 300 maili, a reset hasła, zaproszenia do zespołu i linki do podpisu nie dotarłyby do nikogo
- 5 z 7 monterów nie miało ustawionej dostępności — kalendarz uczciwie pokazywał więc zero wolnych terminów
- żadne z 15 kont nie miało adresu bazowego, od którego system liczy najbliższego montera
- dane firmy były zastępcze (testowy NIP i adres), a usługi nie miały cen
Zaślepki: funkcje, które wyglądają na gotowe
Druga kategoria to miejsca, w których interfejs obiecuje więcej, niż robi. Audyt znalazł cztery: przycisk „Zapłać” w portalu klienta pokazywał tylko komunikat, choć mechanizm płatności po stronie serwera był gotowy; akcja SMS w automatyzacjach była po cichu pomijana, bez ostrzeżenia; jeden przycisk był nieaktywny bez wyjaśnienia; a na stronie produktu roadmapa zapowiadała jako przyszłe funkcje, które już działały. Żadna z tych rzeczy nie wywala testów — ale każda podkopuje zaufanie użytkownika w pierwszym tygodniu.
Robot, który klika wszystko
W drugim systemie, Safe-Pro, poszliśmy krok dalej i napisaliśmy robota nawigacyjnego. Loguje się kolejno jako każda z czterech ról — administrator, kierownik, technik, księgowy — na ekranie telefonu i komputera, i przechodzi przez każdy dostępny ekran: łącznie około 215 widoków w jednym przebiegu. Nie sprawdza logiki biznesowej. Sprawdza, czy ekran się otwiera, czy nie ma błędów i czy każdy link prowadzi tam, gdzie powinien.
| Znalezisko | Skutek dla użytkownika | Naprawa |
|---|---|---|
| Ekran wskaźników KPI zwracał błąd zapytania | pusta strona u kierownika | poprawione zapytanie do bazy |
| Asystent AI widoczny bez skonfigurowanego klucza | przycisk, który nic nie robi | asystent ukrywa się, gdy nie jest dostępny |
| Księgowy bez linków do zadań | ślepe zaułki w rozliczeniach | wspólny komponent linku z kontrolą uprawnień |
| 547 powiadomień o usuniętych zadaniach | linki prowadzące donikąd | sprzątanie istniejących + wyzwalacz na przyszłość |
| Pasek akcji na telefonie ukrywał „Wyślij do akceptacji” | technik nie widział głównej akcji | pasek pokazuje akcję następną w procesie |
Ostatni wiersz jest pouczający: dodanie nowego statusu zadania przesunęło listę przycisków, a pasek mobilny pokazywał tylko dwa pierwsze. Na komputerze wszystko wyglądało dobrze, testy przechodziły, a technik na telefonie nie miał jak wysłać protokołu. Dziś pasek wybiera akcję na podstawie tego, co w procesie powinno wydarzyć się dalej, a nie kolejności na liście.
Nasza lista gotowości do pilotażu
| Warstwa | Co sprawdzamy | Jak |
|---|---|---|
| Kod | logika, uprawnienia, obieg dokumentów | testy automatyczne na kopii bazy i w przeglądarce |
| Nawigacja | każdy ekran w każdej roli na telefonie i komputerze | robot nawigacyjny, analiza nieużywanego kodu |
| Konfiguracja | poczta, powiadomienia, klucze integracji, kopie zapasowe poza serwerem | audyt ręczny + wysyłka próbna na prawdziwą skrzynkę |
| Dane startowe | dostępność ludzi, adresy, ceny, dane firmy, wzory dokumentów | lista braków przekazana firmie z terminem |
Warstwa czwarta jest zawsze wspólna — część danych może uzupełnić tylko firma. Dlatego efektem audytu nie jest „wszystko gotowe”, tylko konkretna lista: co poprawiamy my, co uzupełniacie Wy i do kiedy. Taki dokument przed pilotażem oszczędza tydzień nerwów po nim.
Co z tego wynika dla Ciebie
Jeśli wybierasz wykonawcę systemu, zapytaj nie tylko „czy macie testy”, ale „co sprawdzacie przed pierwszym dniem pracy na systemie”. Dobra odpowiedź zawiera słowa: konfiguracja poczty, dane startowe, każda rola na telefonie. Zła odpowiedź brzmi: „wszystkie testy przechodzą”.
Najczęstsze pytania
Ile trwa audyt gotowości przed pilotażem?
Przy systemie średniej wielkości — od jednego do kilku dni roboczych, w tym przebieg robota nawigacyjnego (kilkanaście minut na pełny przebieg) i ręczne sprawdzenie konfiguracji. To ułamek czasu, który zjadłby chaotyczny pierwszy tydzień pilotażu.
Czy firma musi coś przygotować przed pilotażem?
Tak — dane startowe: listę pracowników z rolami i dostępnością, adresy baz, cennik usług, dane firmy do dokumentów i wzory protokołów. Po audycie dostajecie konkretną listę braków, więc wiadomo, czego dokładnie brakuje.
Czy testy automatyczne zostają po wdrożeniu?
Tak. Uruchamiamy je przy każdej zmianie w ramach utrzymania, więc poprawka jednej funkcji nie psuje po cichu innej. Robot nawigacyjny działa okresowo i po większych zmianach interfejsu.