Dobierz poziom kontroli do projektu
Najpierw określ rodzaj wdrożenia.
Prosta strona zwykle wymaga sprawdzenia treści, linków, formularzy, widoczności w wyszukiwarkach, analityki, zgód, wydajności, domeny i SSL. Checklista wdrożenia strony prowadzi krótszą ścieżką.
Zaawansowany projekt webowy dodaje środowiska, logowanie, uprawnienia, integracje, migracje, konfigurację produkcyjną, monitoring i rollback. Dla niego użyj checklisty gotowości zaawansowanego projektu.
Nie kopiuj najdłuższej możliwej listy. Dodawaj kontrolę wtedy, gdy realna awaria miałaby znaczenie dla użytkownika, biznesu albo zespołu utrzymującego rozwiązanie.
Gotowość funkcjonalna i QA
Przetestuj uzgodnione ścieżki użytkownika, nie tylko pojedyncze ekrany. Uwzględnij główny scenariusz, walidację, stany błędów i działania trudne do cofnięcia.
Każdy znany błąd powinien mieć klasyfikację. Może zostać świadomie zaakceptowany, ale potrzebuje opisu wpływu, właściciela i planu po wdrożeniu. „QA zakończone” niewiele mówi bez informacji o środowiskach, przeglądarkach i scenariuszach.
Mobile, przeglądarki i dostępność
Sprawdź urządzenia i przeglądarki faktycznie używane przez odbiorców. Zobacz kluczowe breakpointy, cele dotykowe, obsługę klawiaturą i treści, które zawijają się inaczej niż w projekcie.
Dla publicznych stron zrób krótki przegląd nagłówków, etykiet, focusu, kontrastu, tekstów alternatywnych i powiększenia. To kontrola przed publikacją, nie zamiennik pełnego audytu dostępności, jeśli jest wymagany.
Treści, formularze i uprawnienia
Przejrzyj finalne teksty, linki, pliki, daty, dane kontaktowe i strony prawne. Wyślij każdy ważny formularz. Sprawdź, gdzie trafiają dane, jaki komunikat widzi użytkownik i kto odpowiada za dalszy kontakt.
W projektach z logowaniem przetestuj reprezentatywne role. Użytkownik powinien widzieć to, czego potrzebuje, i nie mieć dostępu do pozostałych obszarów. Sprawdź rejestrację, odzyskiwanie hasła i sesję, jeśli występują.
Analityka, zgody i SEO
Potwierdź, że zdarzenia analityczne uruchamiają się tylko przy właściwych ustawieniach zgody. Wyznacz właściciela pierwszego przeglądu danych po publikacji.
Dla stron indeksowanych sprawdź title, description, canonical, robots, sitemapę, przekierowania i metadane social. Dla aplikacji prywatnych potwierdź, że poufne trasy nie trafią przypadkiem do indeksu.
Integracje, dane i konfiguracja
Sprawdź produkcyjne konta, endpointy API, e-maile, webhooki, płatności, CRM i zadania cykliczne. Test powinien udowadniać działanie ścieżki produkcyjnej, nie tylko stagingowej.
Przy migracji ustal sposób walidacji, właściciela i moment przełączenia zapisów. Sekrety nie powinny znajdować się w kodzie, a wartości produkcyjne muszą różnić się od testowych tam, gdzie to wymagane.
Domena, SSL, backup i przekierowania
Potwierdź właściciela DNS, finalny hostname, HTTPS, certyfikat oraz przekierowania ze starych adresów. Sprawdź, czy backup istnieje, jest dostępny dla właściwych osób i obejmuje dane lub konfigurację trudne do odtworzenia.
Backup bez właściciela odtworzenia jest tylko nadzieją.
Wdrożenie, monitoring i rollback
Moment go-live nie służy do odkrywania, kto odpowiada za deployment.
Nazwij osobę wdrażającą, właściciela decyzji release i interesariuszy potrzebujących informacji. Ustal okno, dostępy, kolejność oraz kroki weryfikacji.
Przed publikacją określ trigger rollbacku lub odzyskiwania: niedziałające płatności, logowanie, niespójność danych albo krytyczna ścieżka użytkownika. Wiadomo też, kto może podjąć decyzję i ile ma na to czasu.
Akceptacja i kontrola po publikacji
Zapisz akceptację zakresu oraz znanych problemów. Akceptacja nie usuwa ryzyka — potwierdza, że właściwe osoby je rozumieją.
Po wdrożeniu sprawdź publiczną domenę, główne ścieżki, formularze, analitykę, role, integracje, logi i monitoring. Zaplanuj drugą kontrolę po pojawieniu się realnego ruchu albo wykonaniu zadań cyklicznych.
Jeśli po publikacji zmienia się właściciel, przejdź przez checklistę przekazania projektu. Przy kolejnym projekcie zacznij wcześniej od oceny gotowości do startu.